Newsgroup: it.comp.lang.delphi
Titolo: Quale scegliere

Sono divenuto possessore felice di un Delphi XE7 in circostanze che non sto 
qui a raccontare. L'ho installato a fianco del mio Delphi 2007 ed ho 
improvvisamente deciso di fare il passo che ho sempre rinviato: Quella di 
convertire la mia applicazione (che continuo a incrementare con nuove 
funzioni ) all'uso di FireDAC al posto del BDE, dato che in teoria mi pare 
di capire che il percorso di conversione non dovrebbe.
A questo punto, abbandonando il dBase, quale database scegliere ? Lo so che 
ci sono vecchi post dove la domanda è stata posta più volte, ma il tempo è 
passato, FireDAC non esisteva e molte altre cose sono cambiate. Le mie 
esigenze non sono particolarmente sofisticate, perchè l'applicazione è stand 
alone, monoutente e i volumi sono dell'ordine di poche decine di migliaia di 
records. Vorrei che la installazione dell'applicazione non esigesse dei 
prerequisiti e infine non vorrei spendere altri soldi.
Cosa consigliate ? 
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

 Cosa consigliate ?
 
Firebird.
 
Gratuito, leggero e disponibile in modalità embedded che ti permette di 
distribuire l'applicazione, l'engine ed i dati raccolti in un un'unica 
directory purché ci sia un solo utente che usa il db per volta.
 
Lo uso da anni e mi ci trovo benissimo.
 
http://www.firebirdsql.org/
 
 
Per la gestione del database uso FlameRobin.
 
http://www.flamerobin.org/
 
 
Non so se esistono tool di conversione automatici dBase -> Firebird, ma 
ho sempre diffidato di questi strumenti, preferendo sviluppare un mio 
personale strumento ad hoc per sfruttare al meglio le caratteristiche di 
Firebird.
 
Consiglio: essendoci passato anch'io dalla stessa transazione, molti 
anni fa ma ho deviato per Paradox per un breve periodo e poi mi sono 
indirizzato verso Interbase, non cercare similitudini tra dBase e 
Firebird (o qualunque altro motore moderno sceglierai). Semmai ci 
fossero sono pochissime e la loro ricerca potrebbe impedirti d'usare al 
meglio il nuovo motore.
 
-- 
@WarpTen10

 Cosa consigliate ? 
 
PostgreSQL. Anche MySQL e` una scelta, ma io preferisco il primo. Esistono i pgDAC che pero` sono a pagamento. Esiste un OLE DB Provider (che non credo abbia mai funzionato troppo bene con ADO su Delphi - ma e` tanto che non lo uso). Con FireDAC credo che tu riesca ad accederci.

 
"Warp10"  ha scritto nel messaggio news:matpc7$o60$1...@speranza.aioe.org... 
...........
anni fa ma ho deviato per Paradox per un breve periodo e poi mi sono 
indirizzato verso Interbase, non cercare similitudini tra dBase e 
Firebird (o qualunque altro motore moderno sceglierai). Semmai ci 
fossero sono pochissime e la loro ricerca potrebbe impedirti d'usare al 
meglio il nuovo motore.
@WarpTen10
 
Ma tu ora usi Interbase ?


 Ma tu ora usi Interbase ?
 
No, forse non sono stato chiaro.
 
Usavo Interbase e poi son passato a Firebird.
 
-- 
@WarpTen10

 A questo punto, abbandonando il dBase, quale database scegliere ? [...]
 
Esposta in questi termini, cioè senza porre dei requisiti specifici, chiunque ovviamente ti risponderà suggerendo il proprio database preferito, o quello che conosce meglio, che non è detto sia anche il tuo.
 
Aggiungi qualche dettaglio in più, ad esempio il tipo di applicazioni che intendi svilupparci, la piattaforma di tuo interesse, gli aspetti a cui vuoi dare maggiore risalto (prestazioni, portabilità, ecc.).
 
FireDAC deriva da AnyDAC ed è una libreria a mio avviso molto curata e ricca di funzionalità.
 
Ad esempio, io l'ho messo alla prova con SQL Server, e si è comportato decisamente bene.
 
Se vuoi approfondire FireDAC e le sue funzionalità, ci sono parecchi video a riguardo:
https://www.youtube.com/results?search_query=firedac
 
 
Buon lavoro!
  Marco.
 
-- 
MARCO BREVEGLIERI (Software and Web Developer)
#Home: 
http://bit.ly/marcobreveglieri
 
#Blog: 
http://bit.ly/compilaquindiva
 

Ancora prima di pensare al db sul quale ti hanno gia' dato dei suggerimenti, ti suggerisco di riflettere molto bene e fare una accurata analisi dell'impatto sulla tua applicazione di un cosi' radicale cambiamento, sopratutto per quanto riguarda il tipo di oggetto di accesso ai dati che usi materialmente-
Se usi bde, presumo che utilizzando database fileserver  come dbase o paradox,  usi oggetti "tabella" come TTable. 
 
In genere sui db client/server si usano oggetti "query"  (TSqlQuery, TAdoQUery, TFDQuery..) che funzionano su una filosofia di base diversa.
Quindi, ancora prima di pensare al db sul quale ti hanno gia' dato indicazioni, ti suggerisco di riflettere molto bene e fare una accurata analisi dell'impatto sulla tua applicazione di un cosi' radicale cambiamento,
 
A.

 
"Alberto Salvati"  ha scritto nel messaggio 
news:d369d579-6cc3-48f9...@googlegroups.com...
Quindi, ancora prima di pensare al db sul quale ti hanno gia' dato 
indicazioni, ti suggerisco di riflettere molto bene e fare una accurata 
analisi dell'impatto sulla tua applicazione di un cosi' radicale 
cambiamento,
A.
La tua riflessione č giusta, ma mi soprende. La mia decisione č maturata 
anche perchč installando XE7 non ho piů trovato il BDE. Quindi sarei per 
sempre legato alla versione 2007 che utilizzo oggi. E poi leggo 
continuamente incoraggiamenti ad abbandonarlo questo BDE e questo dBase.
Poichč, come ho cercato di spiegare nel mio primo post, le mie esigenze sono 
elementari (applicazioni monoutente, no architetture multi tier, volumi di 
transazioni e di storage limitati), pensavo che anche la trasformazione 
potesse essere piů facile. Si, adesso lavoro con TTable e TQuery. Non c'č un 
ambiente analogo ? 
 
 
---
Questa e-mail č stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

> A questo punto, abbandonando il dBase, quale database scegliere ? [...]
Aggiungi qualche dettaglio in più, ad esempio il tipo di applicazioni che 
intendi svilupparci, la piattaforma di tuo interesse, gli aspetti a cui vuoi 
dare maggiore risalto (prestazioni, portabilità, ecc.).
  Marco.
 
E' guardando una di queste presentazioni di FireDAC dove ne vantavano la 
particolare predisposizione alla migrazione dal BDE che La mia decisione era 
maturata. Inoltre, installando XE7 non ho più trovato il BDE e quindi mi 
sono detto che era arrivata l'ora.
Tanto più che le mie esigenze sono abbastanza elementari, perchè non 
sviluppo applicazioni mutliutente o Client Server, ma applicazioni 
monoutente, con volumi di transazioni e necessità di archiviazione limitata, 
in ambiente Windows.
Mi pareva di aver capito che ci sono database dove si ritrovano i classici 
oggetti TTable e TQuery del BDE.
O è meglio che lasci perdere ? 


 ambiente analogo ? 
 
 
per le Tquery si. 
Quello è un tipo di oggetto che esiste a prescindere dalla tecnologia. Su dbx hai TSqlQuery, su ADO hai TAdoQuery e su FireDac hai TFDQUery.
 
La rogna è per le TTable.
Visto che usi già TQuery non credo servano spiegazioni sulle differenze che esistono tra questa e una TTable. Quindi:
 
1) ora usi BDE con TTable e TQuery presumo su Paradox o dbase, giusto?
 
2) vuoi passare ad un db client/server e mollare BDE per passare a FireDac. Ottimo
 
3) le TQuery, in linea di massima, le sostituisci in modo quasi indolore, salvo qualche peculiarita di BDE...
Non ricordo se era TQuery che aveva il requestlive, ad esempio
 
4) dovresti (notare il condizionale!) evitare di usare oggetti "tabella" su un db client/server. Quindi dovresti (!) *sostituire* le TTable con delle query
 
 
Quindi:
 
Se una una form funziona sfruttando caratteristiche peculiari di TTable, nel sostituire tale oggetto con una TxxQuery, *potresti* aver necessità di cambiare il tuo codice. 
 
Ad esempio, la property IndexName non ha equivalente su un ogegtto Query. E se una tua form ha un qualcosa per impostare l'ordinamento di una griglia che si basa su indexname devi modificare la tua form.
 
Ovviamente, ma non per tutti, queste considerazioni non valgono un tubo se firedac ha qualcosa per un porting indolore.
 
Ma personalmente, prima di rischiare DANDO PER SCONTATO CHE TUTTO FUNZIONI BASANDOMI SU UNA PRESENTAZIONE, ribadisco che IO farei una analisi e delle prove per cercare di capire a cosa potrei andare incontro.
 
 
Pensa anche a cosa usi come primary key ed eventualmente  a come le calcoli.
Hai dei progressivi, tabelle di contatori, campi con immagini e/o altri dati binari, blob, clob etc?  
 
L'aspetto prestazionale è certamente importante, ma non esiste solo quello.
 
A.
 
 
 
 
a.

 O è meglio che lasci perdere?
 
Hai provato ad utilizzare i componenti di FireDAC che sono "omonimi" (salvo il prefisso, ovviamente) di quelli del BDE, tipo la TFDTable?
 
Inoltre, anche se la migrazione è facilitata, conviene che acquisisci dimestichezza comunque sulle funzionalità di FireDAC per evitare problemi di qualsiasi tipo derivanti da assunzioni errate sul funzionamento della libreria.
 
Ciao,


 monoutente, con volumi di transazioni e necessità di archiviazione limitata, in ambiente Windows.
 
A questo punto potresti usare anche un semplice file Access, con accesso ADO. Funziona benissimo per esigenze come le tue. Non ti serve un database C/S, con tutto il peso di un'installazione.

 ambiente analogo ?
 
Usa ADO + Access.
 
 

On 05.02.2015 13:58, Stark wrote:
 > Poichè, come ho cercato di spiegare nel mio primo post, le mie esigenze
 > sono elementari (applicazioni monoutente, no architetture multi tier,
 > volumi di transazioni e di storage limitati), pensavo che anche la
 > trasformazione potesse essere più facile.
 
Parlando di scelta di database, se vuoi un giusto compromesso tra 
leggerezza e usabilità, ti consiglio Firebird. Andrea suggerisce Access, 
ma lo devi aver comprato e ci si interfaccia via ado, tuttavia dici di 
usare tquery e compagnia bella.
 
Vantaggi passando a firebird:
gratuito
maturo
ben supportato dalla community
 
Svantaggi:
mancanza quasi totale di tools gratuiti
mancanza di letteratura (libri blogs e tutorial)
se devi fare operazioni complicate (upgrade di versioni, riparazione db 
corrotto) la cosa diventa assai complicata!
 
Pondera bene le tue scelte.
Se hai domande specifiche su firebird, chiedi pure.
 
-- 
Morde

 spendere altri soldi.
 
SQLite per applicazioni monoutente va benissimo, è leggerissimo ed hai a 
disposizione un set di istruzioni sql che non ti creerà grossi problemi 
anche a scalare in futuro verso altri db engine client-server.
Provato recentemente anche con il db dei cap (completo) la risposta alle 
ricerche è veramente eccellente.
 
Il deploy è ancor più semplice che FB embedded (comunque ottima scelta) 
esendo sufficiente distribuire una dll (sqlite3.dll).
 
-- 
TeeBX VoIP communication platform (coming soon)
http://code.google.com/p/teebx/
 
-----------------------------------------------
Lightweight++ Business Friendly++ Open++

 leggerezza e usabilità, ti consiglio Firebird. 
 
Ma va. A questo punto, molto meglio PostgreSQL.

 esendo sufficiente distribuire una dll (sqlite3.dll).
 
Se puo` interessare, anche per MySQL esiste una versione Embedded (usata e va abbastanza bene).

 corrotto) la cosa diventa assai complicata!
 
Per l'upgrade da FB1.5 a FB2.5 ho fatto un backup del db tramite FB1.5 
ed un restore tramite FB2.5.
 
FB1.5 e FB2.5 installati sulla stessa macchina e switch da uno all'altro 
tramite questi file batch:
 
- Da 1.5 a 2.5 ---
REM Shut down & remove the Firebird 1.5 service
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instsvc" stop
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instsvc" remove
 
REM Update the registry entry to reflect FB2 install
"C:\Program Files\Firebird\Firebird_2_5\bin\instreg.exe" install
 
REM Install & start the Firebird 2 Service (with guardian)
"C:\Program Files\Firebird\Firebird_2_5\bin\instsvc" install -g
"C:\Program Files\Firebird\Firebird_2_5\bin\instsvc" start
---
 
- Da 2.5 a 1.5 ---
REM Shut down & remove the Firebird 2 service
"C:\Program Files\Firebird\Firebird_2_5\bin\instsvc" stop
"C:\Program Files\Firebird\Firebird_2_5\bin\instsvc" remove
 
REM Update the registry entry to reflect FB1.5 install
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instreg.exe" install
 
REM Install & start the Firebird 1.5 Service (with guardian)
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instsvc" install -g
"C:\Program Files (x86)\Firebird\Firebird_1_5\bin\instsvc" start
---
L'unica pecca è che non si possono avere attivi contemporaneamente 
entrambi i motori. O usi l'uno o usi l'altro.
 
Per la corruzione dei dati non so dare indicazioni in quanto non mi è 
mai capitata l'occasione (fortunatamente :) ), ma penso sia 
un'operazione tutt'altro che indolore con qualunque engine.
 
-- 
@WarpTen10


 
Il prossimo database che vorrei usare per un nuovo progetto è proprio 
PostgreSQL, ma per mia curiosità personale, per impararlo, e perchè 
tutti me ne parlano bene.
 
Tuttavia per i requisiti dell'OP penso che sia overkill, in fin dei 
conti con firebird rendi un programma portabile con due soli file: 
fbclient.dll e il database stesso *.fdb
 
 
-- 
Morde

 ed un restore tramite FB2.5.
 
Io per un semplice upgrade dalla 2.1 alla 2.5, mi sono trovato un 
bell'errore sui dati, e me lo sono dovuto smazzare per ore.
Ho dovuto lavorare con gfix e gbak, dopo parecchi try-error
 
Per farla breve, se tutto va bene, basta far girare un batch come quello 
da te quotato.
Ma al primo problema, il supporto disponibile tra documentazione, rete e 
libri, è pressochè zero.
 
 
 
-- 
Morde

 fbclient.dll e il database stesso *.fdb
 
Si`, ma siamo sempre al solito problema: perche` usare una tecnologia di nicchia (Firebird) quando se ne puo` usare una piu` conosciuta, piu` testata (e quindi piu` affidabile), tecnicamente di gran lunga migliore, con piu` (e migliore) documentazione, piu` supporto disponibile in giro (Postgres)? 
Personalmente, mi sono scottato con Firebird molti anni fa, quando ci avevo basato sopra un intero sistema e, per stranissime ragioni, la comunicazione col server falliva regolarmente, in determinati casi. Il debugging era praticamente impossibile, la ragione del problema misteriosa ancora dopo giorni e notti di lavoro; decisione drastica del team: passare a Postgres. Migrato il sistema, senza cambiare una riga di codice Delphi (era basato su ClientDataSet/DataSetProvider), a parte quelle direttamente legate all'accesso dati, il problema e` sparito. Non riuserei Firebird neanche se mi dessero dei soldi.

 ambiente analogo ?
per le Tquery si.
Quello è un tipo di oggetto che esiste a prescindere dalla tecnologia. Su 
dbx hai TSqlQuery, su ADO hai TAdoQuery e su FireDac hai TFDQUery.
La rogna è per le TTable.
................................................................
Si hai ragione, ma capisco abbastanza la differenza tra il database e la 
tecnologia per l'accesso ai dati. In effetti come database, ho sempre usato 
dBase. In un primo tempo usando estensivamente la TTable, poi ho imparato ad 
usare molto di più le TQuery quando mi sono reso conto che anche con il 
local Sql potevo fare, non dico tutto, ma quasi.
Nel mio database non uso campi di tipo particolare, salvo i campi Memo.
Da quello che ho letto nelle risposte ricevute, potrei scegliere tra 
Firebird e SQLite, che coprirebbero la parte TQuery. Ma Marco mi dice che 
FireDAC ha anche delle Tables (quindi FireDAC non è solo un coso per dare 
accesso a dei database ??).
A meno di non usare Interbase, visto che è gratis mi pare, a meno che non 
sia troppo, e poi non lo nomina nessuno ... 


"Marco Breveglieri"  ha scritto nel messaggio 
news:5360052a-c7e5-498a...@googlegroups.com...
Hai provato ad utilizzare i componenti di FireDAC che sono "omonimi" (salvo 
il prefisso, ovviamente) di quelli del BDE, tipo la TFDTable?
...
  Marco.
 
Se, come dici, FireDAC ha l'equivalente delle TTable, potrei cominciare ad 
esplorare FireDAC (che io credevo non avesse questi componenti database. Ma 
non è che ha anche un "omonimo" TQuery?).
 
Altrimenti, da quello che ho letto nelle risposte ricevute, mi orienterei su 
Firebird o SQLite. Ma c'è il rischio di ritrovarsi tra un pò come con il 
dBase? E quale dei due ? E perchè nessuno consiglia Interbase ? 


Interbase, [...] non lo nomina nessuno ... 
 
Ci sara` un motivo.

 E perchè nessuno consiglia Interbase?
 
E perche` nessuno consiglia JBuilder? E perche` nessuno consiglia C++Builder? 
Perche` sono prodotti che non esistono sul mercato, non sono utilizzati praticamente da nessuno, e su cui nessuno investirebbe un solo soldo.
Anche per Firebird e` la stessa cosa: ti sfido a trovare documentazione e supporto se hai un problema.
 

 da te quotato.
 
I due batch servono solo per passare da un motore all'altro. La sequenza 
che ho fatto è stata:
1 - lancio FlameRobin
2 - backup da FB1.5
3 - esco da FlameRobin
4 - batch da FB1.5 a FB2.5
5 - lancio FlameRobin
6 - restore in FB2.5
 
 
-- 
@WarpTen10

 dBase? E quale dei due ? E perchè nessuno consiglia Interbase?
 
Perché dici "altrimenti"? Guarda che FireDAC, come ti ha già detto Alberto Salvati, *non* è un database: è una libreria di accesso ai dati, cioè una libreria per collegarti e interrogare il database che scegli di utilizzare, qualunque esso sia (purché esista un driver FireDAC, ma ce n'è praticamente per qualsiasi DB).
 
Se vuoi migrare dal BDE, FireDAC è un'ottima scelta, poi il database è un altro paio di maniche.
 
InterBase non te lo consiglierei perché sarebbe inutile per te usare un database commerciale per caratteristiche che non sfrutteresti dato i requisiti che hai posto, ossia un accesso in locale e praticamente esclusivo, non client/server, senza necessità specifiche di sicurezza, backup, gestione utenti, ecc.


 Personalmente, mi sono scottato con Firebird molti anni fa, quando ci avevo basato sopra un intero sistema [...]
 
Capisco la situazione, perchè ho pagato uno scotto simile: ho usato 
C++/Qt con firebird per un progetto di lunga durata: considerando il mio 
know-how e la mia esperienza, me la sono sempre cavata.
 
Un giorno, tuttavia, ho upgradato l'API di Qt (4.8->5.3), e di colpo 
tutte le letture di orari fatti sul db, leggevano il valore 0.
 
Per farla breve: il driver Qt per il DB interbase, col passaggio alla 
major release, ha smesso di leggere i timestamp correttamente.
Ho risolto scaricando i sorgenti Qt, ricompilandomi il driver interbase, 
debuggandolo e fixandolo.
 
Quando ho aperto il bug sul bug-tracker di Qt, mi sono accorto che, 
probabilmente, io ero l'unico sviluppatore che utilizzasse Qt insieme a 
Firebird: un bug di questo tipo è bloccante,ma nessuno prima di me aveva 
segnalato la cosa..
 
E' chiaro che è un caso limite: ma avendolo provato sulla mia pelle, non 
posso che ammettere che firebird risulta essere più limitante di altri 
DB molto più diffusi.
 
 
-- 
Morde

 Firebird
 
E` cosi` con tutto cio` che e` di nicchia, non diffuso, non conosciuto, non usato. Bisogna stare molto attenti, perche` si rischia di ficcarsi in vicoli ciechi. Tempo fa c'erano dei driver dbExpress per Postgres che non funzionavano granche` bene (con i blob, in particolare). Bug che nessuno ha mai risolto perche` non c'era poi una cosi` grande esigenza. Vorrei vedere, d'altronde, chi e` che comprerebbe un'automobile, sapendo a priori che non trovera` facilmente pezzi di ricambio sul mercato.

 Se puo` interessare, anche per MySQL esiste una versione Embedded (usata e va abbastanza bene).
 
MySQL emb. e Firebird emb. sono enormemente più esigenti di SQLite in 
termini di risorse (cpu/memoria) quindi come sempre molto dipende da 
cosa si vuole fare... per dire una cattiveria se ancora oggi c'è chi usa 
access per fare gestionali allora lo stesso si può fare con sqlite ;-) e 
con qualche attenzione si può fare anche l'accesso condiviso.
 
Se interessa anche la portatilità, sempre parlando di embedded e 
considerando l'architettura cpu non il sist. operativo, allora mentre 
MySQL ed SQLite sono cross-platform Firebird non lo è.
 
Attenzione anche al fatto che il licensing di MySQL è piuttosto 
complesso e tutt'altro che di libero uso nel caso di applicazioni 
commerciali.
L'alternativa praticamente drop-in è MariaDB.


 access per fare gestionali allora lo stesso si può fare con sqlite ;-) 
 
Cattiveria verso chi? Access e` sempre stato (e lo e` ancora) perfettamente valido per esigenze come quelle di Stark. Come detto, SQLite e` un'ottima alternativa. 
 
 

 MySQL ed SQLite sono cross-platform Firebird non lo è.
 
Linux e Windows non bastano?
 
http://www.firebirdsql.org/en/about-firebird/
 
 
:)
 
-- 
@WarpTen10

 Linux e Windows non bastano?
 
Non mi riferivo al solo sistema operativo e comunque ero rimasto 
indietro: sono convinto che fino a qualche tempo fà la versione embedded 
non fosse utilizzabile su linux, ho ricontrollato e nella faq della 2.5 
affermano che la "superserver" può essere utilizzata come embedded.
Medesimo errore per l'architettura, ergo io non l'ho mai detto ;-)


 Medesimo errore per l'architettura, ergo io non l'ho mai detto ;-)
 
Detto cosa, scusa? ;-)
 
-- 
@WarpTen10

 Linux e Windows non bastano?
 
Se ci fosse anche Max OSX sarebbe meglio. Lo supporta? Il sito menziona solo "a variety of Unix platforms."


http://www.firebirdsql.org/en/downloads/
 
 
---
Supported Platforms
 
Firebird 2.5 runs on Windows (32- and 64-bit), various Linux versions 
(32- and 64- bit), Solaris (Sparc and Intel), HP-UX (PA-Risc) and MacOS 
X. Main development is done on Windows and Linux, so new releases are 
usually offered first for these platforms, followed by other platforms 
after a few weeks.
---
 
-- 
@WarpTen10

"Marco Breveglieri"  ha scritto nel messaggio 
news:825abcba-9ca5-48e9...@googlegroups.com...
InterBase non te lo consiglierei perché sarebbe inutile per te usare un 
database commerciale per caratteristiche che non sfrutteresti dato i 
requisiti che hai posto, ossia un accesso in locale e praticamente 
esclusivo, non client/server, senza necessità specifiche di sicurezza, 
backup, gestione utenti, ecc.
Ciao,
  Marco.
 
Ho installato XE7 su un PC che per qualche settimana non avrò disponibile. 
Nel frattempo, cercavo di documentarmi, ma vedo che non è facile capire. Ho 
capito che Database e libreria di accesso sono due cose distinte. Ma mi 
pareva che proprio tu avessi scritto "Hai provato ad utilizzare i componenti 
di FireDAC che sono "omonimi" (salvo il prefisso, ovviamente) di quelli del 
BDE, tipo la TFDTable?".
Quindi ha pensato che FireDAC avesse qualcosa in più. Se non è così, cosa 
volevi dire ?
Per il momento, nella mia mente ho scartato InterBase per quello che mi hai 
detto tu, Firebird per quello che mi ha detto Laforgia e mi sono documentato 
su SQLite, MySql e Postgres.
Per la conversione delle mie attuali applicazioni, sarei tentato da SQLite, 
perchè mi appare il più semplice e risponde alle esigenze di queste 
applicazioni. Ho però qualche dubbio che chi usa SQLite mi potrebbe 
chiarire: Per esempio, non esiste un tipo di campo DATE, nè un tipo di campo 
Memo. Come si fa con dati di questo tipo?
Non risolvo il problema delle TTable, usate abbastanza estensivamente. 
Problema che comunque avrei anche con MySql e Postgres.
La conversione a FireDAC/SQLite  potrebbe rivelarsi eccessivamente pesante 
rispetto al vantaggio di abbandonare una tecnologia obsoleta, ma ancora 
perfettamente funzionante ?
Non lo so, non mi pare di avere ancora abbastanza elementi per decidere.


 ancora perfettamente funzionante ?
 
---
dBase: devo cancellare una fattura
1 - cancello tutte le righe
2 - cancello l'intestazione
 
Database C/S: devo cancellare una fattura
1 - cancello l'intestazione
le righe vengono cancellate automaticamente perché collegate 
all'intestazione tramite foreign key che tu imposti
---
dBase: devo assegnare un ID al nuovo cliente
1 - vado a vedere qual è l'ultimo ID dei clienti assegnato
2 - lo incremento di 1
3 - lo assegno al nuovo cliente
E devo stare attento che un'altra istanza del software non stia facendo 
la stessa operazione nello stesso momento. Se così fosse assegnerei lo 
stesso ID a due clienti diversi.
 
Database C/S: devo assegnare un ID al nuovo cliente
1 - inserisco il nuovo cliente
l'ID viene calcolato tramite uno strumento del motore del database (in 
Firebird si chiamano generators). In questo modo sono certo che non ci 
potranno mai essere due clienti con lo stesso ID.
 
La stessa cosa vale per qualunque nuovo elemento di una tabella 
(clienti, fornitori, fatture, righe di fatture...)
---
dBase: ho bisogno la ragione sociale del cliente di ogni fattura
1 - leggo l'ID del cliente dalla fattura
2 - recupero la ragione sociale dalla tabella clienti
3 - scrivo la ragione sociale in un campo calcolato
o
1 - creo un campo di tipo lookup che va a leggere la ragione sociale da 
una TTable che contiene l'elenco clienti ordinato per ID
 
Database C/S: ho bisogno di vedere la ragione sociale del cliente di 
ogni fattura
1 -  con una JOIN tramite due campi chiave (ID del cliente nella fattura 
ed ID cliente nell'elenco clienti) faccio recuperare al database la 
ragione sociale del cliente
---
dBase: per usare il tuo software in rete le tabelle devono essere 
disponibili in una cartella condivisa
 
Database C/S: per usare il tuo software in rete hai solo bisogno di 
sapere qual è l'IP del PC dove gira il server di database. Niente 
cartelle condivise. Questo è l'ambiente classico d'uso di FB e di altri 
database C/S.
---
Database C/S: transazioni
l'utente cambia idea all'ultimo momento e non vuole memorizzare le 
operazioni che ha portato avanti fino a quel momento.
Rollback.
---
 
Altre persone di questo NG potrebbero farti altri esempi.
 
Dovrai riscrivere tutto, ovviamente, ma otterrai grandi vantaggi e meno 
problemi.
 
-- 
@WarpTen10

> ancora perfettamente funzionante ?
 
Dimenticavo gli eventi.
 
Nel db succede qualcosa (nuovo cliente, nuova fattura, modifica riga 
della fattura...) puoi scatenare un evento che può essere intercettato 
tramite un componente apposito all'interno della tua applicazione e fare 
qualcosa come aggiornare l'elenco clienti, l'elenco fatture, le righe 
della fattura...
 
Firebird li ha e mi pare esistano in altri db.
 
-- 
@WarpTen10

 Non lo so, non mi pare di avere ancora abbastanza elementi per decidere.
 
Senz'altro abbandonare una libreria deprecata dal 2001 è una buona idea, però onestamente mi è sfuggita la "scintilla" che ti ha spinto a fare questa migrazione ora.
 
Solo per usare XE7?
 
Se XE7 ti fornisce delle feature imprescindibili per il tuo software (ad esempio, vuoi portarlo su 64 bit, o su altre piattaforme), allora è uno scoglio necessario, dato che il BDE è stato (finalmente) rimosso da XE7, altrimenti se non hai questa esigenza, puoi rimanere su una versione appena precedente di Delphi e compiere questa migrazione con più calma, gradualmente, pezzo per pezzo.
 
Altri consigli non saprei darteli perché non so quali sono i tuoi "margini di manovra" e solo tu puoi sapere l'impatto e il vantaggio di determinate scelte che sono del tutto personali.


 Memo. Come si fa con dati di questo tipo?
 
Leggere no, eh? :)
 
https://www.sqlite.org/datatype3.html
 
https://www.sqlite.org/lang_datefunc.html
 

 database C/S.
 
Il non avere le cartelle condivise è una di quelle cose che GISUTAMENTE rende felici i sistemisti.
 
A.

 Il non avere le cartelle condivise è una di quelle cose che GISUTAMENTE rende felici i sistemisti.
 
E visto che, qualche volta, i sistemisti siamo noi ci auto-rendiamo 
felici. :)
 
-- 
@WarpTen10

On 08.02.2015 22:53, Warp10 wrote:
 > Firebird li ha e mi pare esistano in altri db.
 
Io li ho usati: dopo due settimane di problemi, li ho disattivati..
 
Gli eventi vengono propagati attraverso porte, che comporta la gestione 
dei firewall, e questo aggiunge un onere in più per te.
 
Oltre a questo, ogni client apre una connessione in ascolto per 
verificare se dal socket arrivano dati, e devi tenerne conto se non vuoi 
che il firewall locale ti lasci a piedi.
 
Alla fine ho risolto usando una tabella dove registro gli eventi, e dei 
thread lato client che fanno polling. Non pulitissimo, ma funzionale, e 
tutto relegato alla connessione col database.
 
Per documentarti sugli eventi:
http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf
 
 
-- 
Morde

 Giusto.  Ma meglio aggiungere che :
 
Sbagliato. Concordo sui tuoi 1), 2) e 3), ma aggiungo che i dati che finiscono su documenti che hanno un valore contingente a quanto vengono prodotti vanno SEMPRE ridondati. 


Per mia fortuna li ho usati senza problemi in una configurazione all-XP.
 
So già che appena passeranno a 7/8 inizieranno i problemi, ma mi sto già 
premunendo. :)
 
-- 
@WarpTen10

 bradipamente lento.
 
Se il software era scritto coi piedi, che c'entra Oracle?

 Se il software era scritto coi piedi, che c'entra Oracle?
 
Nulla.
 
Ma se il software era scritto coi piedi presumo che anche la struttura 
dati in Oracle seguisse la stessa metodologia. E quindi sia lodato chi 
ha scelto di dismettere il tutto.
 
-- 
@WarpTen10

 Per mia fortuna li ho usati senza problemi in una configurazione all-XP.
 
All-XP e without-firewall, ovviamente.
 
-- 
@WarpTen10

 bradipamente lento.
 
Oracle non è assolutamente "lento".
Se una app che usa Oracle è lenta alcuni dei motivi possono i seguenti:
 
1) applicazione scritta in modo cinofallico
2) database progettato in modo cinofallico
3) istanza oracle che gira su un sapientino
4) istanza oracle configurata in modo cinofallico
Quest'ultima speiga come mai un esperto oracle si GIUSTAMENTE pagare bene, visto che data la complessita', difficilmente puo fare altro.
 
Come qualsiasi prodotto, Oracle non va bene o male a prescindere.
Che poi io preferisca db2 è un altro discorso.
 
 
A.
 
 
 

 Che poi io preferisca db2 è un altro discorso.
 
Fugace contatto tredici o quattordici anni fa.
 
-- 
@WarpTen10

On 09.02.2015 12:58
 
 >> Oracle non è assolutamente "lento".
 >
 > E lo spero bene per lui.
 
Forse non ti è chiaro che oggi, nel 2014, la potenza di calcolo a 
disposizione dei database è enorme, al punto che una query anche 
mastodontica viene eseguita in pochi millisecondi.
 
Quello che "rallenta" un'applicazione al punto da farti pensare che sia 
colpa del database, può essere:
 
- database progettato in modo inefficiente
- query inefficienti (ed è responsabilità del client)
- infrastruttura inefficiente (reti fisiche e logiche)
- business logic inefficiente (programma che legge in sequenza la 
testata, poi le righe, poi i dettagli, poi questo, puoi quello, senza 
join, dati denormalizzati..)
 
Oggi è assurdo sentire affermare ancora qualcuno che sia il motore del 
DB ad essere lento..
 
-- 
Morde

 ha scelto di dismettere il tutto.
 
Ma se esordisci con un "Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche in futuro." fai capire che e` bene stare alla larga da Oracle. Quando invece quel che volevi dire, probabilmente, e` che bisogna stare alla larga da gente che scrive software coi piedi. Su questo non posso che concordare. Oracle e` un ottimo strumento, uno dei migliori database in circolazione, affidabile e veloce.

 DB ad essere lento..
 
Sopratutto quando e` Oracle di cui si sta parlando. 

 DB ad essere lento..
 
Infatti io ho scritto
---
Sono riuscito ad evitare Oracle finora e spero di riuscire a farlo anche 
in futuro. Un mio cliente sta dismettendo un software, al quale un mio 
software si sarebbe dovuto interfacciare, che si basava su Oracle. 
Doveva essere scritto coi piedi perché non ho mai visto niente di più 
bradipamente lento.
---
Il "Doveva essere scritto coi piedi..." si riferiva al software e non ad 
Oracle.
 
Ed il "E lo spero bene per lui." era ironico.
 
Se Oracle fosse stato la causa dei problemi di lentezza di quel software 
non sarebbe mai diventato Oracle.
 
-- 
@WarpTen10

 non sarebbe mai diventato Oracle.
 
Interessanti queste due frasi dal punto di vista psicologico.


anche in futuro." proprio perché so che è un motore di database 
complesso da far girare al meglio. Richiede personale competente e 
qualificato che, a volte, è assente perché, guarda caso, costa troppo.
 
Se io devo interfacciare con un mio programma con un database Oracle e 
dall'altra parte non ho informazioni di alcun tipo perché la vecchia 
software house non vuole darne (questo era lo scenario che mi si 
prospettava) so già che andrò ad infilarmi in un ginepraio da cui 
difficilmente uscirò vivo. La cosa andava avanti da anni e finalmente la 
soluzione è arrivata.
 
Lunga vita ad Oracle, beninteso, basta che ci sia qualcuno che mi dice 
dove devo leggere le cose e cosa significano.
 
-- 
@WarpTen10


:)
 
-- 
@WarpTen10

 qualificato che, a volte, è assente perché, guarda caso, costa troppo.
 
Alcuni anni fa il percorso di certificazione Oracle costava tra corsi ed esami intorno ai 18.000 euro. 
Lo so in quanto avevo  fatto una valutazione.
 
Considerando cio' e considerando che e' molto difficile che si riesca a fare ALTRO, chi ha quel tipo di qualifica ha tutto il diritto di chiedere certe cifre.
 
Il problema non è tanto di quanto costi oracle in se o di quanto costi uno specialista che ne risolve i casini.
Il problema è fare una  SCELTA CONSAPEVOLE, non basata sul trafiletto letto sull'espresso o sul cugggino che in azienda usa Oracle "che è una bomba".
 
A.


Il cliente presso il quale era installato quel software (e quindi 
Oracle) era il re delle scelte inconsapevoli. :)
 
Quella della scelta di quel software fu solo l'ultima di una lunga lista.
 
-- 
@WarpTen10

 qualificato che, a volte, è assente perché, guarda caso, costa troppo.
 
Un'azienda seria, che si doti di Oracle, si dota anche del personale che serve a gestire quel sistema. Il problema non e` Oracle, e` chi decide di usare Oracle senza avere la minima idea di quali siano i requisiti per usarlo, quali siano le competenze di cui si ha bisogno per gestirlo, e quali siano i costi operativi.

 Alcuni anni fa il percorso di certificazione Oracle costava tra corsi ed esami intorno ai 18.000 euro. 
 
Non serve prendersi una certificazione da 18000 euro per lavorare con Oracle. Io ho lavorato con Oracle per anni e le parti piu` rognose di gestione del sistema se le smazzavano i DBA Oracle. E` chiaro che costavano un occhio della testa all'azienda, ma se hai un business tale da necessitare di Oracle, hai anche i soldi per i consulenti.

 Un'azienda seria, che si doti di Oracle, si dota anche del personale che serve a gestire quel sistema.
 
Francamente, ho lavorato in diverse PMI, e nessuna aveva un DBA: troppo 
costoso metterlo a libro paga: meglio dissanguarsi in consulenze 
puntuali quando il DB si corrompeva o dava problemi inattesi (si nota il 
sarcasmo?)
 
Purtroppo noi siamo per la maggior parte dei self-made men, che hanno 
imparato non solo a programmare, ma a fare anche i sistemisti, i DBA, 
gli architetti del software, i consulenti, i managers di sè stessi.
 
 
-- 
Morde

 Purtroppo noi siamo [...]
 
Noi chi?


A titolo d'esempio ti posso dire che il cliente di cui parlo è talmente
serio che ha scelto il CMS col quale realizzare l'indecente sito che
mostra su Internet ad una fiera. La persona che lo ha scelto si stava
dimenticando d'essere andato a quella fiera per scegliere (anche) un CMS
ed ha preso una brochure al volo uscendo. Il CMS di quella brochure è
diventato il CMS col quale viene realizzato il sito.
 
Il cliente è una pubblica amministrazione.
 
-- 
@WarpTen10

 Noi chi?
 
:-D
 

Non parlavo di *usarlo*. Parlavo di fare il DBA..

 Memo. Come si fa con dati di questo tipo?
Leggere no, eh? :)
https://www.sqlite.org/datatype3.html
 
https://www.sqlite.org/lang_datefunc.html
 
 
Grazie del link, ma lě vengono descritte le funzioni Date and Time. Ma sul 
record, che tipo si definisce per una data ? 
 
 
---
Questa e-mail č stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

> Non risolvo il problema delle TTable, usate abbastanza estensivamente.
Che problema?
Senz'altro abbandonare una libreria deprecata dal 2001 è una buona idea, 
però onestamente mi è sfuggita la "scintilla" che ti ha spinto a fare questa 
migrazione ora.
Solo per usare XE7?
Se XE7 ti fornisce delle feature imprescindibili per il tuo software (ad 
esempio, vuoi portarlo su 64 bit, o su altre piattaforme), allora è uno 
scoglio necessario, dato che il BDE è stato (finalmente) rimosso da XE7, 
altrimenti se non hai questa esigenza, puoi rimanere su una versione appena 
precedente di Delphi e compiere questa migrazione con più calma, 
gradualmente, pezzo per pezzo.
Ciao,
  Marco.
Quando pensavo alle TTable come un problema, mi riferivo alla necessità di 
rimaneggiare i programmi per sostituirle con delle Query: Le ho usate spesso 
con filtri e con le relazioni Master Detail.
E si, migrerei per poter usare XE7, non tanto perchè abbia delle features 
imprescindibili, ma perchè l'assenza del BDE mi ha fatto pensare al futuro e 
potrei prendere l'occasione. Certo lo farei con gradualità ...
Grazie comunque per i consigli preziosi !
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

 Non parlavo di *usarlo*. Parlavo di fare il DBA..
 
La certificazione come DBA varia nel costo. Diciottomila euro mi sembrano esagerati. Se mi dai dei riferimenti...
 

 record, che tipo si definisce per una data ? 
 
Ho capito, sei un troll.

 Ho capito, sei un troll.
 
:-D
 

On 09.02.2015 18:48, Warp10 wrote:>
 > Il cliente è una pubblica amministrazione.
 
Mi fa piacere sapere con quali criteri vengono prese certe decisioni, 
soprattutto quando vengono finanziate con i soldi delle tasse dei 
cittadini..
 
Meno male che ora vivo all'estero e le tasse non le pago più in Italia.
 
-- 
Morde


 
Noi di ICLD.
 
-- 
Morde

 Noi di ICLD.
 
Ah ecco, "voi".


Non capisco.
 
-- 
Morde

 cittadini..
 
Fosse solo quello.
 
Non esiste un elenco dei dipendenti.
Non esiste un elenco degli uffici.
Non esiste una tassonomia degli uffici (si sa che ci devono essere tre 
livelli: direzione, servizio ed ufficio, ma non si sa quante direzioni 
ci sono, da quanti servizi sono composte e quanti uffici compongono ogni 
singola sezione).
 
-- 
@WarpTen10

Parliamo di circa 6 anni fa.
 
Non ho un link da passare. Appena ho tempo vado a verificare come stanno adesso le cose.
Avevo fatto il corso dba 1 (5 gg) su 9i pagandolo non poco.
Ricordo che il docente non era un "lettore di manuali" ma uno che faceva il DBA sul campo e ci fece molti esempi su casi reali che si era trovato a gestire.
 
Dopo qualche tempo mi arrivo' una mail con allegata una offerta per il set completo di corsi in aula e vouchers per gli esami e la cifra era grosso modo quella.
Ai tempi esisteva OCA, OCP e poi quella al top del quale mo non ricordo la sigla e l' offerta riguardava prp quella.
 
A.

 Ai tempi esisteva OCA, OCP e poi quella al top del quale mo non ricordo la sigla e l' offerta riguardava prp quella.
 
Stai probabilmente parlando della OCM, che e` una certificazione cha hanno in pochissimi e che tra i mortali non prende praticamente nessuno, anche perche` e` molto difficile da ottenere (richiede una prova sul campo abbastanza "tosta"). E` chiaro che per quella ti fanno pagare fiori di quattrini, ma non serve veramente se si vuol lavorare un DBA Oracle. I commerciali Oracle sono brutte bestie che ci provano sempre a tirarti in trappola; bisogna imparare a conoscerle e sceverare il bene dal male :)

 commerciali Oracle sono brutte bestie che ci provano sempre a tirarti 
 
...bhe, fanno il loro lavoro. 
Sta a chi sta dall'altre parte non farsi incantare.
 
A.