Newsgroup: it.comp.lang.delphi
Titolo: Advantage

Ogni tanto rifaccio mente locale alla migrazione che dovrei affrontare per 
portare fuori alcune applicazioni da BDE/dBase. Rinvio sempre il problema 
xchè non c'è una soluzione migliore e non so decidermi e quindi oggi 
propendoi per firebird, domani x Sqlite e dopodomani per IB. Ieri sono 
capitato su un forum dove parlavano di Advantage Database Server, che sembra 
abbia una soluzione free per applicativi desktop, proprio come quelli che 
dovrei convertire io che sono solo locali e senza pretese di diventare 
client server o multiutente.
Magari qualcuno ne ha sentito parlare e ha un'opinione in materia ? Forse è 
un argomento che non interessa molti, ma visto che il forum è più o meno 
dormiente, se ne potrebbe parlare un pò dell'argomento ? 
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 wrote:
 
Tempo fa, tanto tempo fa ebbi a che fare con ADS
credo fosse l'engine db del Visual Object della CA.
non ne feci nulla perchč il compilatore VO andava
malissimo.
Visto che usi Delphi perchč non provi ad usare Tdbf ?
č un componente che si installa nella palette di delphi
č non ha bisogno di Dll o exe esterni e consente
la gestione di tebelle e indici di tabelle dbf in modo
molto semplice.
L'ho usata per fare il porting di alcune applicazioni
da Clipper-ntx a Dephi-Mysql.
 

VO fu una "brillante idea" di CA per gli sviluppatori clipper che dovevano spostarsi su windows. 
Fu non un buco nell'acqua ma una voragine.. va be..
Il commento unanime di chi aveva visto delle demo fu "..tanto vale passare a c++..", il che è quanto dire.
 
Un prodotto che ai tempi permetteva di usare clipper su windows era FiveWin.
Funzionava niente male e aveva una curva di apprendimento praticamente piatta.
Ho scoperto che esiste una sua evoluzione, seguita sempre dallo stesso sviluppatore:
 
https://www.fivetechsoft.com/english/products.php
 
 
ADS (Onestamente, non sapevo esistesse ancora) è l'evoluzione di Advantage xbase server che era un prodotto per usare in qualche modo i dbf in c/s da clipper.
 
Io eviterei in quanto, secondo me, queste sono soluzioni un po tirate per i capelli.
 
A.
 

 propendoi per firebird, domani x Sqlite e dopodomani per IB. 
 
Giusto per "infierire"... :-D
 
Molti db commerciali (non agratis, per capirci) hanno delle versioni free limitate, in genere sulla dim massima del database e su funzionalità avanzate.
C'è sqlexpress di zio billy, db2 di ibm e oracle, che sincremanete non ti consiglio). Poi c'è la versione community di mysql.
 
https://www.microsoft.com/it-it/download/details.aspx?id=42299
 
http://www-01.ibm.com/software/data/db2/express-c/download.html
 
https://dev.mysql.com/downloads/mysql/
 
 
Il resto lascerei perdere.
 
A.
 
 
 
 
 

 oggi propendoi per firebird, domani x Sqlite e dopodomani per IB.
 
Lascia perdere Firebird, lascia perdere IB. Non sono usati praticamente 
da nessuno, non c'e` supporto, non c'e` adeguata documentazione. SQLLite 
e` una soluzione perfetta se hai bisogno di un db locale, semplice da 
usare ed efficiente. Se proprio vuoi usare un RDBMS, ci sono Postgres o 
MySQL (ricordati che per usi commerciali, richiede la licenza). Le 
soluzioni ci sono.
 
-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)

Visto che usi Delphi perchè non provi ad usare Tdbf ?
è un componente che si installa nella palette di delphi
è non ha bisogno di Dll o exe esterni e consente
la gestione di tebelle e indici di tabelle dbf in modo
molto semplice.
L'ho usata per fare il porting di alcune applicazioni
da Clipper-ntx a Dephi-Mysql.
___
Grazie. Andrò a vedere di che si tratta. Non l'avevo mai sentito. 


 propendoi per firebird, domani x Sqlite e dopodomani per IB.
 
Di cosa stiamo parlando? Di applicazioni desktop? Di applicazioni multiutente?
In base a questo la domand può avere una o più risposte. In ogni caso:
 
 - SQLite è una libreria di larghissimo uso (talmente largo che te la ritrovi
   anche su qualsiasi dispositivo Android) pensata proprio per gestire basi di 
   dati embedded (ovvero usate da applicazioni desktop mono utente o per tutti
   quei lavori che richiedono una base dati di appoggio). Ha un limitato
   supporto all'accesso multiutente ed ha un footprint veramente basso. Il
   contro è che non è possibile usarlo in un contesto client/server e che usa
   una dichiarazione dei data type di tipo manifest (ovvero i data type che
   dichiari in fase di creazione della tabella non sono assolutamente
   vincolanti). 
 - Firebird e Borland Interbase hanno il vantaggio di funzionare out of the box
   senza troppi problemi. Non solo, Firebird (non so Interbase) ti permette di
   passare da un database utilizzato sia in modalità embedded (ovvero utilizzato
   direttamente dall'applicazione con una sola connessione attiva) sia in
   modalità client/server (ovvero utilizzato via rete da più connessioni). Il
   contro è che, come diceva Andrea La Forgia, lo usano in pochi, e quindi se
   sei uno di quei pochi che hanno problemi, rischi di non trovare
   documentazione se non quella ufficiale.
 
Le alternative a questa situazione sostanzialmente sono poche. In teoria al
posto di SQLite potresti usare Microsoft Jet (che, almeno fino a Windows 7, è
integrato nel sistema), ma rischi di entrare in un inferno da cui se ne salvano
in pochi (usare Jet senza problemi è pura utopia). Di contro, se vai in
direzione di un'architettura client/server, come alternativa puoi usare MySQL
(anche se te lo sconsiglio) o PostgreSQL (che ti consiglio), così come tutta una
serie di prodotti commerciali che però sono rilasciati in versione gratuita con
limitazioni (quelli citati da Alberto Salvati, per capirci). Insomma, tutto sta
a capire cosa devi fare, dopodiché scegli l'architettura che ti è più comoda 
 
Enrico
P.S. in teoria ci sono anche BerkeleyDB e derivati, ma sono più simili a
key/value database che a RDBMS

Lascia perdere Firebird, lascia perdere IB. Non sono usati praticamente
da nessuno, non c'e` supporto, non c'e` adeguata documentazione. SQLLite
e` una soluzione perfetta se hai bisogno di un db locale, semplice da
usare ed efficiente. Se proprio vuoi usare un RDBMS, ci sono Postgres o
MySQL (ricordati che per usi commerciali, richiede la licenza). Le
soluzioni ci sono.
4ndre4
---
Per le esigenze molto limitate di queste piccole applicazioni quindi la 
scelta dovrebbe cadere su Sqlite. Ma non ho trovato nessun tool per una 
conversione automatica dei dataset. E' vero che potrei scrivere qualche 
programma .. Ma proprio non c'è niente in giro ? Perchè se è così, allora mi 
vengono dei dubbi sulla scelta della migrazione..
Ho letto un pò di Firedac, e ho visto che supporta sia Sqlite che Advantage 
Database Server. Ma Sqlite mi richiede una conversione (e dovrei cominciare 
a capire come definire tutte le date, per esempio..), mentre per Advantage 
la dco dice che non occorre fare quasi nulla manualmente.. 


https://www.microsoft.com/it-it/download/details.aspx?id=42299
 
http://www-01.ibm.com/software/data/db2/express-c/download.html
 
https://dev.mysql.com/downloads/mysql/
 
Il resto lascerei perdere.
A.
---
Capisco che queste sarebbero scelte sicure, ma da quello che leggo, lo 
stesso mysql è persino troppo per le esigenze di queste applicazioni 
totalmente e definitivamente desktop (e probabilmente anche per me, che vado 
verso il disarmo).
Di Sqlite leggo benissimo dappertutto, ma poi non trovo nessuno che lo ha 
adottato come soluzione, per lo meno qui da noi.
Advantage l'ho scoperto adesso perchè leggendo la doc di Firedac, lo cita 
tra quelli supportati e sapevo che era a suo tempo un'alternativa al BDE 
(tipo Absolute, credo..)
Essendo venuto in possesso di un Delphi XE8, pensavo di abbandonare il mio 
Delphi 2007, ma per farlo devo assolutamente convertire queste tre o quattro 
applicazioni, che sono vecchie, ma continuano a funzionare perfettamente.



-----
Come avevo spiegato nel mio post iniziale, queste applicazioni sono 
monoutente e desktop. Quindi da quello che mi dici la soluzione migliore 
potrebbe essere Sqlite se non fosse che non ho trovato alcun tool per la 
conversione automatica dei dati.
Ecco perchè Advantage mi era sembrato conveniente, ma pare che non sia 
consigliato da nessuno... 


 allora mi vengono dei dubbi sulla scelta della migrazione..
 
A scrivere un programmino che estrae uno script SQL di una base dati 
paradox ci metti 2 ore.
 
-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)
"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 
http://tinyurl.com/z6y6gpd
 

A scrivere un programmino che estrae uno script SQL di una base dati
paradox ci metti 2 ore.
4ndre4
----
Scusa se ti faccio domande stupide, ma per scrivere un programmino che legge 
dei dataset dBase e scrive gli analoghi Sqlite non devo avere disponibili 
entrambi i componenti (TTable e il corrispondente Sqlite) ?
 
In ambiente Delphi 2007, come definisco un dataset Sqlite ? Dico una cazzata 
(se è così, vacci piano..)? 
 

 cazzata (se è così, vacci piano..)?
 
http://docwiki.embarcadero.com/RADStudio/XE8/en/Using_SQLite_with_FireDAC
 


 conversione automatica dei dati.
 
Per la conversione dei dati dovrai sempre scriverti qualcosa, perché dubito che
vi sia qualcose converta da dBase a SQLite (in teoria c'è per Firebird). Più
che altro, come hai notato anche tu, non vi è modo semplice per gestire le date
in SQLite se non tramite un formato definito lato client (per capirci, le
funzioni di data di SQLite convertono la data in formato ISO). Se per te è un
vincolo, guarda Firebird embedded (perché l'essere poco usato non significa che
non funzioni) o MySQL embedded (che prima ho dimenticato di citare e che ha gli
stessi vincoli di Firebird embedded)
 
Enrico

http://docwiki.embarcadero.com/RADStudio/XE8/en/Using_SQLite_with_FireDAC
 
4ndre4
---
Grazie della tua disponibilità, ma ti chiarisco che dispongo di Delphi 2007, 
nel quale non c'è Sqlite e di XE8 (anzi ora di XE10, che mi hanno portato 
dagli US), dove però non c'è il BDE .
Comunque, mi confermi che occorre avere un sistema dove convivono entrambi. 
Ecco perchè cercavo un 'convertitore'. 


 entrambi. Ecco perchè cercavo un 'convertitore'.
 
Ma niente affatto: tu puoi benissimo estrarre gli statement SQL di 
creazione del database da un sistema, usarli per creare il tuo db 
SQLLite, e usare l'altro sistema per accedervi. Cosa te lo impedisce? 
Come detto, ci metti poche ore a scriverti un convertitore.


Ma niente affatto: tu puoi benissimo estrarre gli statement SQL di
creazione del database da un sistema, usarli per creare il tuo db
SQLLite, e usare l'altro sistema per accedervi. Cosa te lo impedisce?
Come detto, ci metti poche ore a scriverti un convertitore.
4ndre4
---
Scusa se continuo a non capire, ma tu dici che, come nel mio caso, in Delphi 
2007 potrei creare e scrivere una dataset Sqlite ? 


Ciao,
  non posso dirti di piu' da quanto detto dagli altri se non un'altra strada 
(pero' non gratuita) che supporta delphi 6- seattle 10.
Sono le librerie TurboDB della DataWeb (
www.dataweb.de
) che sono compatibili 
100% con il buon dbe di un tempo (versione full free per valutazione in 30 
giorni).
 
Io sono anni che le uso e mi trovo molto bene, affidabili, veloci, stabili e 
supporto in pochissime ore, sia web che mail.
 
Considerato che hai anche delphi seattle  e che con firedac puoi attaccarti 
a, praticamente tutto, se vuoi stare su qualcosa di free stai su firebird 
anche se e' poco supportato (se e' mono utenza e desktop non dovresti avere 
chissa' quali problemi).
 
Nel mio caso, per ragioni non dipendenti da me, mi sono interfacciato con le 
firedac al db firebird (pochi minuti di applicazione) dove devo solo leggere 
dei dati da un db di circa 3 milioni di record e le informazioni raccolte, 
una volta lavorate, vengono salvate in un db gestito dalle turboDb.
 
L'unico aspetto negativo delle turbodb e' che, fino ad oggi, NON sono 
multipiattaforma, quindi solo windows.
 
Buona scelta
 
Ciao
 
Daniele 
 

Forse è meglio, come dire, formalizzare, alcuni punti che fino ad ora sono stati dati per scontati:
 
1) salvo casi molto particolari, la responsabilita della CREAZIONE (e, più in generale, la manutenzione) di un db non è di delphi o di qualsiasi ambiente/rad/ide ma di uno STRUMENTO APPOSITO fornito in genere dal produttore del motore db.  A volte ci sono anche strumenti di terze parti, ad esmepio TOAD, del quale esistono diverse versioni in funzione del db: mysql, oracle, sqlserver.
Nota che il toad per mysql è free, mentre quello per oracle è a pagamento
 
2) salvo casi molto particolari, la responsabilità del porting di dati da un db ad un altro, ANCHE A PARITA DI STRUTTURA DEL DB, spetta allo sviluppatore.
Esistono strumenti che semplificano sto lavoro ma NON C'ENTRANO NULLA CON RAD/IDE/AMBIENTI DI SVILUPPO etc
 
3) piu' in generale, NESSUNA aTTIVITA DI MANUTEZIONE, TRASFERIMENTO DI DATI ETC DI UN DB E' RESPONSABILITA DI RAD/IDE/AMBIENTI DI SVILUPPO.
Access, da questo punto di vista è una anomalia, in quanto è sia un db (puah!) che un ambiente di sviluppo (doppio puah!)
 
 
Come ho scritto piu' volte, occorre avere ben chiare le distinzioni tra rad, tecnologie di accesso ai dati e database. Lasciando da parte access che, ribadisco, è una anomalia.
 
A) Bde, Ado Dbx, Ado.Net, Firedac, Ibx, Doa sono TECNOLOGIE DI ACCESSO AI DATI e non DATABASE. Lo scopo di una tecnologia di accesso ai dati è ACCEDERE AI DATI di un db, non di creare o manuntenere db etc.
Quindi frasi di questo tipo:
 
"database ado"
"creare un db ado"
"creare un db sqllite con firedac"
 
sonO semplicemente CAZZATE
 
B) Oracle, Db2, MySql, Firebird, SqlServer, Sybase sono DATABASE
 
A.

 Access, da questo punto di vista è una anomalia, in quanto è sia un db (puah!) che un ambiente di sviluppo (doppio puah!)
 
Qualunque RDBMS e` sia un db, che un ambiente di sviluppo, dal momento che un RBDMS di norma supporta il proprio dialetto SQL. Access va benissimo (i tuoi "puah!" lasciano il tempo che trovano, anche perche`, come sempre, non sono motivati tecnicamente) per applicazioni semplici, monoutenti, file-based. Access funziona egregiamente per certi scopi. 
 
 

...piu' in generale, NESSUNA aTTIVITA DI MANUTEZIONE, TRASFERIMENTO DI DATI 
ETC DI UN DB E' RESPONSABILITA DI RAD/IDE/AMBIENTI DI SVILUPPO.
A.
---
OK. Ma se voglio spostare i dati che ho in un database in formato dBase in 
un altro in formato Sqlite con un programmino che legge da una parte e 
scrive dall'altra, devo usare un linguaggio di programmazione o no ?
Allora perchè non mi dite semplicemente come fare  ? Io so che in Delphi 
2007 ho disponibile il BDE (tecnologia di accesso ai dati, ho capito) e 
alcuni componenti che rappresentano i dataset del formato dBase (TTAble,..). 
Posso quindi leggere record per record. Ma dove li scrivo se non ho 
contemporaneamente disponibile il corrispondente 'TTable' Sqlite ?
Mi chiarite questo ? 


 Mi chiarite questo ?
 
Te l'ho gia` detto come fare: leggi il db con Delphi 2007/BDE e crei lo 
SCRIPT di creazione del database e tabelle per SQLite. Lo script poi le 
esegui con il tool da linea di comando di SQLite. Al DB SQLite cosi` 
creato accederai da Delphi XE10 con FireDAC. Mi spiace, ma piu` semplice 
di cosi` non riesco a spiegarlo.


Mi chiarite questo ? 
 
Con il 'vecchio' programma 
Leggi record per record e li scrivi su un file di testo.
Poi passi al nuovo.
Leggi il/i file/s di testo, riga per riga  e li inserisci con uno statment SQL
nelle corrispondenti tabelle create con Sqlite.
 
questo sopra è un modo per le tabelle dbf puoi usare Tdbf
oppure ADS (se è gratis) e con il programma 'nuovo' puoi 
leggere direttamente i dbf e scrivere sulle tabelle SqliIte.
 
Come ti suggerisce Andrea le tabelle SQLite le puoi
creare con uno script SQL creato con il 'vecchio' programma
ma da quel che ho capito le tue tabelle sono poche
quindi puoi fare come vuoi.
 
Ciao.
 
 
 

..Continui a non capire.. :-|
 
1) La TTable (e la tquery) di bde NON SA  a quale tipo di db si connette e NON DEVE SAPERE  a quale tipo di db si connette.
Ai vecchi tempi con bde usavi, come con Ado, Dbx etc, qualsiasi db:
Sybase, Oracle, SqlServer, etc
 
2) Ci sono tecnologie di accesso ai dati, come dire, generiche, che ti permettono di accedere a diversi database COMPRESE FONTI DATI ODBC: ado, bde, dbx, firedac..
 
3) Ci sono tecnologie SPECIFICHE di accesso ai dati, che sono progettate per UN SOLO TIPO DI DATABASE: Doa e Ibx, ad esempio
 
Poi:
 
 
TTableDbf.open;
 
 
while not TTableDbf.eof do begin
  qryInsert.ParamByName('campo1').AsInteger :=   
       TTableDbf.FieldByname('Acampo1).AsInteger
  qryInsert.ParamByName('Acampo2').AsString :=   
       TTableDbf.FieldByname('campo2).AsString;
  ....
  qryInsert.ExecSql
  TTableDbf.Next;
end;
 
 
Presupposti:
1) aver creato il db di destinazione con tutte le tabelle, a prescindere se sia SqlLite, Db2 o altro
 
2) qryInsert è un oggetto query che ha uno statement sql del tipo INSERT INTO TABELLA (CAMPO1, CAMPO2) VALUES (:ACAMPO1, :ACAMPO2);
 
3) qryInsert può essere:
 
a) una TAdoQuery (alla quale associ una TAdoConnection)
b) una TSqlQuery (alla quale associ una TSqlConnection)
c) una TFdQuery 
etc etc etc
ESATTAMENTE COME TTABLE E TQUERY SONO ASSOCIATE AD UN TDATABASE.
 
INFINE:
NON SPETTA ALL'OGGETTO DI ACCESSO AI DATI *SAPERE* A QUALE DB E' COLLEGATO:
QUELLO E' COMPETENZA DELL'OGGETTO CHE GESTISCE LA CONNESSIONE AL DB.
 
 
A.
 
PS: Di dove sei?
 
 

Te l'ho gia` detto come fare: leggi il db con Delphi 2007/BDE e crei lo
SCRIPT di creazione del database e tabelle per SQLite. Lo script poi le
esegui con il tool da linea di comando di SQLite. Al DB SQLite cosi`
creato accederai da Delphi XE10 con FireDAC. Mi spiace, ma piu` semplice
di cosi` non riesco a spiegarlo.
4ndre4
---
Adesso che mi citi la scrittura di uno script ho finalmente capito. 
Evidentemente non avevo compreso, anzi avevo equivocato il tuo suggerimento 
e per quello non mi ritrovavo. Grazie di avere insistito senza scocciarti. 


TTableDbf.open;
while not TTableDbf.eof do begin
  qryInsert.ParamByName('campo1').AsInteger :=
       TTableDbf.FieldByname('Acampo1).AsInteger
  qryInsert.ParamByName('Acampo2').AsString :=
       TTableDbf.FieldByname('campo2).AsString;
  ....
  qryInsert.ExecSql
  TTableDbf.Next;
end;
A.
---
Un esempio mi ha fatto bene. Ho capito! Grazie (sto a Milano, anzi vicino a 
Mi) 


Ti secca scrivermi in privato?
La mail è quella che uso qua.
 
A.