Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Delphi XE2 + Firebird + Zeos lib
92 views
Skip to first unread message
Daniele
Oct 12, 2015, 12:57:08 PM10/12/15
to
Ciao a tutti,
qualcuno ha usato queste librerie e mi puo' dire se sono valide o meno
per la sola lettura dei dati delle tabelle ??
Al momento sono riuscito, con queste, a connettermi al DB e a visualizzare
tutti i record di una data tabella.
Sembra veloce, ma (come sempre) ci sono pareri discordanti sulla loro
efficacia.
Un altro approccio e' sql .... ma questo e' un altro discorso .....
Lo studio continua ......
Grazie
Ciao
Daniele
qualcuno ha usato queste librerie e mi puo' dire se sono valide o meno
per la sola lettura dei dati delle tabelle ??
Al momento sono riuscito, con queste, a connettermi al DB e a visualizzare
tutti i record di una data tabella.
Sembra veloce, ma (come sempre) ci sono pareri discordanti sulla loro
efficacia.
Un altro approccio e' sql .... ma questo e' un altro discorso .....
Lo studio continua ......
Grazie
Ciao
Daniele
Delta11
Oct 12, 2015, 1:10:41 PM10/12/15
to
Il 12/10/2015 18.57, Daniele ha scritto:
> Ciao a tutti,
> qualcuno ha usato queste librerie e mi puo' dire se sono valide o
> meno per la sola lettura dei dati delle tabelle ??
vai tranquillo
> Ciao a tutti,
> qualcuno ha usato queste librerie e mi puo' dire se sono valide o
> meno per la sola lettura dei dati delle tabelle ??
Marco Breveglieri
Oct 12, 2015, 4:56:27 PM10/12/15
to
Il giorno lunedì 12 ottobre 2015 18:57:08 UTC+2, Daniele ha scritto:
> qualcuno ha usato queste librerie e mi puo' dire se sono valide o meno
> per la sola lettura dei dati delle tabelle ??
Ma perché non usi semplicemente la libreria dbExpress con i componenti *TSQLConnection* e *TSQLQuery*?
> qualcuno ha usato queste librerie e mi puo' dire se sono valide o meno
> per la sola lettura dei dati delle tabelle ??
--
MARCO BREVEGLIERI (Software and Web Developer)
#Home: http://www.marco.breveglieri.name
#Blog: http://www.compilaquindiva.com
#DelphiPodcast: http://www.delphipodcast.com
Alberto Salvati
Oct 13, 2015, 3:14:28 AM10/13/15
to
> Ma perché non usi semplicemente la libreria dbExpress
Quoto alla grande.
A.
Alberto Salvati
Oct 13, 2015, 3:16:02 AM10/13/15
to
> vai tranquillo
Le usi quotidianamente?
Com quale versione di delphi?
Su che db?
Usi anche le stored procedure?
A.
Le usi quotidianamente?
Com quale versione di delphi?
Su che db?
Usi anche le stored procedure?
A.
Delta11
Oct 13, 2015, 5:36:57 AM10/13/15
to
adesso con XE7 uso le Fire
--
(..) la rivoluzione non è un pranzo di gala, non è una festa letteraria,
non è un disegno o un ricamo; non si può
fare con tanta eleganza, con tanta serenità e delicatezza, con tanta
grazia e cortesia. La rivoluzione è un atto
di violenza, è l'azione implacabile di una classe che abbatte il potere
di un'altra classe. (Mao Tze-tung)
Alberto Salvati
Oct 13, 2015, 6:23:22 AM10/13/15
to
> ma quando le usavo , anche con le sp, non ho mai avuto problemi
Quanto tempo fa, con che versione di delphi e con quali db?
> adesso con XE7 uso le Fire
A.
Warp10
Oct 13, 2015, 7:46:40 AM10/13/15
to
Il 13/10/2015 09.14, Alberto Salvati ha scritto:
>> Ma perché non usi semplicemente la libreria dbExpress
>
> Quoto alla grande.
In informatica, si sa, se una cosa non si rompe non si cambia.
>> Ma perché non usi semplicemente la libreria dbExpress
>
> Quoto alla grande.
Io ho sempre usato IBX per interfacciarmi ad Interbase prima ed a
Firebird poi.
Mi date un motivo per cui dovrei cambiare?
Attenzione, la mia non è affatto una domanda polemica. Voglio veramente
sapere se esiste un motivo tecnicamente valido (maggiore velocità
d'esecuzione ad esempio) per cui potrei abbandonare IBX per abbracciare
un'altra tecnologia d'accesso a Firebird.
Non ditemi d'abbandonare Firebird perché vi rimando all'inizio della mia
risposta. :)
--
@WarpTen10
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
Alberto Salvati
Oct 13, 2015, 8:54:18 AM10/13/15
to
Come dicevi tu, se una cosa funziona xche toccarla?
Per contro, dovendo iniziare *adesso* un progetto *nuovo*:
1) se hai firedac, conviene usarla
2) se non hai firedac, io andrei di dbx
In entrambi i casi, il vantaggio è poter cambiare db senza cambiare la tecnologia di accesso ai dati. Ancora, *sembra* che codegear stia spingendo parecchio firedac, non fosse altro che è multipiattaforma ed è utilizzabile anche su android, ios e macos, cosa che dbx non può fare.
Ovviamente (ma non per tutti), una scelta, quale essa sia, deve essere fatta CONSAPEVOLMENTE e non sulla base di eventuali "sentito dire" che spesso lasciano il tempo che trovano, sopratutto se vengono da persone che suggeriscono soluzioni che non usano o non hanno mai applicato.
Ad esempio, con delphi 7 (non xe7!) usando il driver dbx per mysql ho avuto dei problemi, se non erro legati alle stored procedure, ora non ricordo di previso.
Dovendo sviluppare in d7 + MySql, ho comprato il driver dbx della devart.
Qualora fosse necessario/opportuno un porting su xe7/8/10/chissa', potrei passare a firedac, DOPO AVER FATTO DELLE PROVE MASSICCE in modo da essere ragionevolmente sicuro di non avere delle regressioni, siano esse in stabilità e/o performance.
A.
Per contro, dovendo iniziare *adesso* un progetto *nuovo*:
1) se hai firedac, conviene usarla
2) se non hai firedac, io andrei di dbx
In entrambi i casi, il vantaggio è poter cambiare db senza cambiare la tecnologia di accesso ai dati. Ancora, *sembra* che codegear stia spingendo parecchio firedac, non fosse altro che è multipiattaforma ed è utilizzabile anche su android, ios e macos, cosa che dbx non può fare.
Ovviamente (ma non per tutti), una scelta, quale essa sia, deve essere fatta CONSAPEVOLMENTE e non sulla base di eventuali "sentito dire" che spesso lasciano il tempo che trovano, sopratutto se vengono da persone che suggeriscono soluzioni che non usano o non hanno mai applicato.
Ad esempio, con delphi 7 (non xe7!) usando il driver dbx per mysql ho avuto dei problemi, se non erro legati alle stored procedure, ora non ricordo di previso.
Dovendo sviluppare in d7 + MySql, ho comprato il driver dbx della devart.
Qualora fosse necessario/opportuno un porting su xe7/8/10/chissa', potrei passare a firedac, DOPO AVER FATTO DELLE PROVE MASSICCE in modo da essere ragionevolmente sicuro di non avere delle regressioni, siano esse in stabilità e/o performance.
A.
Marco Breveglieri
Oct 13, 2015, 9:11:25 AM10/13/15
to
Il giorno martedì 13 ottobre 2015 13:46:40 UTC+2, Warp10 ha scritto:
> In informatica, si sa, se una cosa non si rompe non si cambia.
> [...]
> In informatica, si sa, se una cosa non si rompe non si cambia.
Qui si parlava di iniziare un progetto nuovo, con una edizione di Delphi recente, per leggere solamente dati da un database esistente.
Altrimenti sarei stato d'accordo con te (in linea generale). :)
Daniele
Oct 13, 2015, 10:47:43 AM10/13/15
to
Cia a tutti,
ragazzi .... se prima ero confuso .... ora lo sono di piu' !!!!
Per essere chiari ecco il mio ambiente di sviluppo
Windows 7 pro
Delphi Xe 2
Dopo il cambio gestionale, che usa firebird come database, devo aggiornare 3
programmi.
I tre programmi, per fortuna, devono solo leggere i dati di tre tabelle
La prima contiene i prezzi degli articoli aggiornati quotidianamente.
La seconda contiene gli eventuali prezzi modificati , per esempio dalle
offerte.
La terza contiene le chiusure giornaliere.
Con le Zeos, pronti via e' andato tutto senza problemi...ma:
Prima di sbragare un solo programma devo valutare quale sia il tool MIGLIORE
oggi, per migliore si
intende una tecnologia che, anche cambiando RAD (per esempio RAD 2015
Dallas) il codice, previa leggera manutenzione,
rimanga il piu' possibile inotccabile (non sempre gli open source vengono
aggiornati).
Ovviamente, essendo un principiante prendo molto seriamente in
considerazione le vostre opinioni.
Considerato che non si conosce il domani (oggi e' solo in lettura ... domani
??) e che Embarcadero sta "spingendo" le firedac, mi sposto
su queste ultime ed inizio a sperimentare.
Grazie
Ciao
Daniele
ragazzi .... se prima ero confuso .... ora lo sono di piu' !!!!
Per essere chiari ecco il mio ambiente di sviluppo
Windows 7 pro
Delphi Xe 2
Dopo il cambio gestionale, che usa firebird come database, devo aggiornare 3
programmi.
I tre programmi, per fortuna, devono solo leggere i dati di tre tabelle
La prima contiene i prezzi degli articoli aggiornati quotidianamente.
La seconda contiene gli eventuali prezzi modificati , per esempio dalle
offerte.
La terza contiene le chiusure giornaliere.
Con le Zeos, pronti via e' andato tutto senza problemi...ma:
Prima di sbragare un solo programma devo valutare quale sia il tool MIGLIORE
oggi, per migliore si
intende una tecnologia che, anche cambiando RAD (per esempio RAD 2015
Dallas) il codice, previa leggera manutenzione,
rimanga il piu' possibile inotccabile (non sempre gli open source vengono
aggiornati).
Ovviamente, essendo un principiante prendo molto seriamente in
considerazione le vostre opinioni.
Considerato che non si conosce il domani (oggi e' solo in lettura ... domani
??) e che Embarcadero sta "spingendo" le firedac, mi sposto
su queste ultime ed inizio a sperimentare.
Grazie
Ciao
Daniele
Marco Breveglieri
Oct 13, 2015, 11:26:50 AM10/13/15
to
Il giorno martedì 13 ottobre 2015 16:47:43 UTC+2, Daniele ha scritto:
> Con le Zeos, pronti via e' andato tutto senza problemi...
E allora che problemi ti poni? :)
> Con le Zeos, pronti via e' andato tutto senza problemi...
> Prima di sbragare un solo programma devo valutare quale sia il tool MIGLIORE
> oggi, per migliore si
> intende una tecnologia che, anche cambiando RAD (per esempio RAD 2015
> Dallas) il codice, previa leggera manutenzione,
> rimanga il piu' possibile inotccabile (non sempre gli open source vengono
> aggiornati).
Piuttosto, se puoi, scrivi il codice in modo che prescinda il più possibile dalla tecnologia di accesso ai dati vera e propria, e non dovrebbe essere così difficoltoso se - come hai detto tu - fai principalmente delle letture.
> Considerato che non si conosce il domani (oggi e' solo in lettura ... domani
> ??) e che Embarcadero sta "spingendo" le firedac, mi sposto
> su queste ultime ed inizio a sperimentare.
Ciao,
Marco.
Warp10
Oct 13, 2015, 12:02:07 PM10/13/15
to
Il 13/10/2015 14.54, Alberto Salvati ha scritto:
> Come dicevi tu, se una cosa funziona xche toccarla? Per contro,
> dovendo iniziare *adesso* un progetto *nuovo*:
>
> 1) se hai firedac, conviene usarla 2) se non hai firedac, io andrei
> di dbx
Ed è proprio Firedac la tecnologia che avevo intenzione di usare (previe
> Come dicevi tu, se una cosa funziona xche toccarla? Per contro,
> dovendo iniziare *adesso* un progetto *nuovo*:
>
> 1) se hai firedac, conviene usarla 2) se non hai firedac, io andrei
> di dbx
millemila operazioni di prova massiccia, ovviamente) su un prossimo
progetto Firebird o VattelapeSQL che sia.
Ciò che mi ha sempre bloccato dal farlo è il fatto che sono librerie che
van bene per tutti i principali database e la mia paura è che, proprio
per questo, non permettano di sfruttare le caratteristiche peculiari di
ognuno di essi.
Marco Breveglieri
Oct 13, 2015, 12:25:00 PM10/13/15
to
Il giorno martedì 13 ottobre 2015 18:02:07 UTC+2, Warp10 ha scritto:
> Ciò che mi ha sempre bloccato dal farlo è il fatto che sono librerie che
> van bene per tutti i principali database e la mia paura è che, proprio
> per questo, non permettano di sfruttare le caratteristiche peculiari di
> ognuno di essi.
Ci sono diverse modalità per accedere ad alcune funzioni peculiari del database (bisogna sempre vedere ciò di cui si parla), però in generale questo è lo "scotto da pagare" quando si adottano framework più generici.
> Ciò che mi ha sempre bloccato dal farlo è il fatto che sono librerie che
> van bene per tutti i principali database e la mia paura è che, proprio
> per questo, non permettano di sfruttare le caratteristiche peculiari di
> ognuno di essi.
Per contro, se tu usassi funzionalità molto specifiche di un database, avresti meno portabilità verso altri tipi di basi di dati.
Tutto dipende da quali sono i requisiti e le prerogative iniziali, e anche il DB di cui si parla, oltre all'effettiva necessità di accedere a funzionalità specifiche del DB.
Ciao,
Marco.
Alberto Salvati
Oct 14, 2015, 2:24:06 AM10/14/15
to
> non permettano di sfruttare le caratteristiche peculiari di
> ognuno di essi.
Mi fai un esempio di caratteristiche peculiari?
> ognuno di essi.
A.
Warp10
Oct 14, 2015, 3:02:18 AM10/14/15
to
altro, ad esempio. Motori di database che non diventano mammuth
congelati se devono cancellare millemila record. :)
Se tutti i motori fossero identici come prestazioni e caratteristiche
allora non avrebbe più senso sceglierne uno al posto di un altro.
enrico....@gmail.com
Oct 14, 2015, 4:11:07 AM10/14/15
to
Ciao Daniele,
> Con le Zeos, pronti via e' andato tutto senza problemi...ma:
allora sei già a posto, a questo punto ti direi di continuare con le Zeos visto che ti sei trovato bene da subito e funziona tutto correttamente. Io non uso le Zeos però credo che siano delle buone librerie ed anche consolidate.
> Prima di sbragare un solo programma devo valutare quale sia il tool MIGLIORE
> oggi, per migliore si
> intende una tecnologia che, anche cambiando RAD (per esempio RAD 2015
> Dallas) il codice, previa leggera manutenzione,
> rimanga il piu' possibile inotccabile (non sempre gli open source vengono
> aggiornati).
Secondo un mio personalissimo parere è molto difficile dire quali librerie sono migliori anche per il semplice fatto che ci vorrebbe molto tempo per testarle tutte con lo stesso ambiente e con tutte le operatività. Io utilizzo con molta soddisfazione da anni le FIBPlus, da quello che sento FireDAC è un'ottima libreria performante e gratuita all'interno di Delphi X*.
Ciao da Enrico Giudici
> Con le Zeos, pronti via e' andato tutto senza problemi...ma:
> Prima di sbragare un solo programma devo valutare quale sia il tool MIGLIORE
> oggi, per migliore si
> intende una tecnologia che, anche cambiando RAD (per esempio RAD 2015
> Dallas) il codice, previa leggera manutenzione,
> rimanga il piu' possibile inotccabile (non sempre gli open source vengono
> aggiornati).
Ciao da Enrico Giudici
Marco Breveglieri
Oct 14, 2015, 4:41:37 AM10/14/15
to
Il giorno mercoledì 14 ottobre 2015 09:02:18 UTC+2, Warp10 ha scritto:
> Azioni per svolgere le quali un motore di database sia più rapido di un
> altro, ad esempio. Motori di database che non diventano mammuth
> congelati se devono cancellare millemila record. :)
Il termine "rapidità" (uso appositamente le virgolette) è troppo generico: si parla di minor tempo possibile di accesso ai dati o di qualcos'altro?
> Azioni per svolgere le quali un motore di database sia più rapido di un
> altro, ad esempio. Motori di database che non diventano mammuth
> congelati se devono cancellare millemila record. :)
Poi, molto spesso, la questione della velocità è strettamente legata ai servizi addizionali che il database offre.
Stesso discorso si può fare per la dimensione massima dello storage, che mi pare oggi si possa gestire facilmente per qualsiasi DB in circolazione.
> Se tutti i motori fossero identici come prestazioni e caratteristiche
> allora non avrebbe più senso sceglierne uno al posto di un altro.
Se tu usi una query ed esegui una banale "SELECT * FROM Tabella" usando FireDAC, sarà responsabilità del driver e successivamente del database, in base anche agli indici definiti, individuare il modo migliore di fornirti i dati.
Le vere limitazioni sono quelle legate a una caratteristica peculiare di un singolo database che, essendo tale, non sempre è possibile generalizzare.
Ad esempio, InterBase supporta la gestione di eventi che si possono sollevare da trigger e stored procedure per inviare una segnalazione ai client collegati; in altri database questa feature potrebbe essere assente, e lo è, oppure implementata in modo differente. Detto questo, se vuoi sfruttare quel meccanismo poiché lo ritieni essenziale, devi spesso ricorrere a componenti nativi e specifici (es. la libreria IBExpress).
Riassumendo, nei termini in cui hai posto la questione, secondo me la scelta di usare componenti "generici" muniti di driver come FireDAC o componenti nativi non cambia la questione, perché tu parli di prestazioni e requisiti, e non di caratteristiche.
Ciao,
Marco.
Warp10
Oct 14, 2015, 5:21:10 AM10/14/15
to
Il 14/10/2015 10.41, Marco Breveglieri ha scritto:
> Il giorno mercoledì 14 ottobre 2015 09:02:18 UTC+2, Warp10 ha
> scritto:
>> Azioni per svolgere le quali un motore di database sia più rapido
>> di un altro, ad esempio. Motori di database che non diventano
>> mammuth congelati se devono cancellare millemila record. :)
>
> Il termine "rapidità" (uso appositamente le virgolette) è troppo
> generico: si parla di minor tempo possibile di accesso ai dati o di
> qualcos'altro?
Quello della "rapidità" era solo un esempio.
> Il giorno mercoledì 14 ottobre 2015 09:02:18 UTC+2, Warp10 ha
> scritto:
>> Azioni per svolgere le quali un motore di database sia più rapido
>> di un altro, ad esempio. Motori di database che non diventano
>> mammuth congelati se devono cancellare millemila record. :)
>
> Il termine "rapidità" (uso appositamente le virgolette) è troppo
> generico: si parla di minor tempo possibile di accesso ai dati o di
> qualcos'altro?
>> Se tutti i motori fossero identici come prestazioni e
>> caratteristiche allora non avrebbe più senso sceglierne uno al
>> posto di un altro.
>
> Ma qui si parla di caratteristiche del database, non dei componenti
> per l'accesso ai dati.
sfruttare al 100% tutte le caratteristiche del motore di un database.
> Le vere limitazioni sono quelle legate a una caratteristica peculiare
> di un singolo database che, essendo tale, non sempre è possibile
> generalizzare.
>
> Ad esempio, InterBase supporta la gestione di eventi che si possono
> sollevare da trigger e stored procedure per inviare una segnalazione
> ai client collegati; in altri database questa feature potrebbe essere
> assente, e lo è, oppure implementata in modo differente. Detto
> questo, se vuoi sfruttare quel meccanismo poiché lo ritieni
> essenziale, devi spesso ricorrere a componenti nativi e specifici
> (es. la libreria IBExpress).
ad abbandonare IBX con i quali mi trovi benissimo.
Riscriverei le routine che adotto ora usando IBX per adattarle ad altri
componenti per l'accesso ai dati, ma solo se ha senso farlo. Se ci
guadagno qualcosa.
Ripeto che la mia domanda iniziale non voleva essere polemica.
Sono convinto che FireDAC sia un'ottima tecnologia e chiedo a qualcuno
che l'abbia abbracciata dopo aver usato altro (BDE è escluso, eh! :) )
perché l'ha fatto e quali benefici, a parte la possibilità di usare
qualunque motore di database supportato da FireDAC, lo abbiano indotto a
fare il salto.
Marco Breveglieri
Oct 14, 2015, 9:35:03 AM10/14/15
to
Il giorno mercoledì 14 ottobre 2015 11:21:10 UTC+2, Warp10 ha scritto:
> Ed ecco perché, usando solo Firebird per ora, sono sempre stato restio
> ad abbandonare IBX con i quali mi trovi benissimo.
Ma scommetto che non fai praticamente nulla con i componenti IBX che non potresti fare allo stesso modo con qualsiasi altro componente, come quelli di FireDAC. :)
> Ed ecco perché, usando solo Firebird per ora, sono sempre stato restio
> ad abbandonare IBX con i quali mi trovi benissimo.
> Riscriverei le routine che adotto ora usando IBX per adattarle ad altri
> componenti per l'accesso ai dati, ma solo se ha senso farlo. Se ci
> guadagno qualcosa.
Va anche detto che accedere a FireBird usando i componenti IBX, che sono progettati appositamente per InterBase, costituiscono un rischio sempre maggiore visto che la suite di componenti segue l'evoluzione di InterBase che, pur avendo un antenato in comune con FireBird, divergono sempre più nella loro implementazione e caratteristiche esclusive.
> Ripeto che la mia domanda iniziale non voleva essere polemica.
> Sono convinto che FireDAC sia un'ottima tecnologia e chiedo a qualcuno
> che l'abbia abbracciata dopo aver usato altro (BDE è escluso, eh! :) )
> perché l'ha fatto e quali benefici, a parte la possibilità di usare
> qualunque motore di database supportato da FireDAC, lo abbiano indotto a
> fare il salto.
Per il dettaglio delle feature della libreria, riporto il link alla documentazione ufficiale che contiene parecchi articoli a riguardo:
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Firedac
Vedi anche questa playlist di video con diversi demo:
https://www.youtube.com/watch?v=Fb3IRW9l_1w&list=PLwUPJvR9mZHgjJ0JtSqJ-dv2cGtWr-jtq
Ciao!
Warp10
Oct 14, 2015, 10:36:12 AM10/14/15
to
Il 14/10/2015 15.35, Marco Breveglieri ha scritto:
> Il giorno mercoledì 14 ottobre 2015 11:21:10 UTC+2, Warp10 ha
> scritto:
>> Ed ecco perché, usando solo Firebird per ora, sono sempre stato
>> restio ad abbandonare IBX con i quali mi trovi benissimo.
>
> Ma scommetto che non fai praticamente nulla con i componenti IBX che
> non potresti fare allo stesso modo con qualsiasi altro componente,
> come quelli di FireDAC. :)
Forse (forse un po' più di "forse" :) ).
> Il giorno mercoledì 14 ottobre 2015 11:21:10 UTC+2, Warp10 ha
> scritto:
>> Ed ecco perché, usando solo Firebird per ora, sono sempre stato
>> restio ad abbandonare IBX con i quali mi trovi benissimo.
>
> Ma scommetto che non fai praticamente nulla con i componenti IBX che
> non potresti fare allo stesso modo con qualsiasi altro componente,
> come quelli di FireDAC. :)
Ma allora perché cambiare IBX con FireDAC se ci farei le stesse cose?
Tieni conto che non voglio/posso cambiare Firebird con un altro motore
di database perché non voglio/posso mettere mano ai server sui quali è
installato il server di database e quindi salta tutto il discorso della
multidatabaselità (passamela, per piacere) di FireDAC.
> Va anche detto che accedere a FireBird usando i componenti IBX, che
> sono progettati appositamente per InterBase, costituiscono un rischio
> sempre maggiore visto che la suite di componenti segue l'evoluzione
> di InterBase che, pur avendo un antenato in comune con FireBird,
> divergono sempre più nella loro implementazione e caratteristiche
> esclusive.
So già per certo che il discorso non è "se" ma "quando" passerò a
FireDAC, o a qualcosa che sostituirà FireDAC in un futuro.
Conosciamo tutti fin troppo bene la storia di Delphi per sapere che non
possiamo distrarci un attimo. :)
>> Sono convinto che FireDAC sia un'ottima tecnologia e chiedo a
>> qualcuno che l'abbia abbracciata dopo aver usato altro (BDE è
>> escluso, eh! :) ) perché l'ha fatto e quali benefici, a parte la
>> possibilità di usare qualunque motore di database supportato da
>> FireDAC, lo abbiano indotto a fare il salto.
>
> Oltre al supporto di una vasta gamma di database, c'è anche da tenere
> in considerazione il fatto che sia cross-platform.
>
> Per il dettaglio delle feature della libreria, riporto il link alla
> documentazione ufficiale che contiene parecchi articoli a riguardo:
> http://docwiki.embarcadero.com/RADStudio/Seattle/en/Firedac
>
> Vedi anche questa playlist di video con diversi demo:
> https://www.youtube.com/watch?v=Fb3IRW9l_1w&list=PLwUPJvR9mZHgjJ0JtSqJ-dv2cGtWr-jtq
Marco Breveglieri
Oct 14, 2015, 2:09:07 PM10/14/15
to
Il giorno mercoledì 14 ottobre 2015 16:36:12 UTC+2, Warp10 ha scritto:
> Ma allora perché cambiare IBX con FireDAC se ci farei le stesse cose?
Non sto dicendo che devi farlo. Anzi, sto dicendo che non ti cambia nulla per cui non ha senso sostenere la migrazione a un'altra libreria se ci fai le stesse cose che fai con quella attuale, a meno che non ci sia una condizione che forza il passaggio, ad esempio la necessità di indirizzare altri database, approdare su piattaforme differenti da Windows o per utilizzare funzionalità specifiche della libreria di destinazione che non sono presenti nella prima.
> Ma allora perché cambiare IBX con FireDAC se ci farei le stesse cose?
> Conosciamo tutti fin troppo bene la storia di Delphi per sapere che non
> possiamo distrarci un attimo. :)
Ciao,
0 new messages