Newsgroup: it.comp.lang.delphi
Titolo: E IB Lite ?

Con l'idea di abbandonare il BDE, avevo cominciato ad istruirmi sul 
passaggio a SqlLite, viste le mie esigenze non proprio sofisticate. Solo 
qualche giorno fa, mi č capitato di vedere un video su IB Lite, che mi ha 
riproposto l'interrogativo iniziale su cosa scegliere. Avevo escluso IB, 
dato che nessuno qui me lo aveva consigliato; perň non sapevo che ci fosse 
un IB gratis. In piů, non trovo gran che sulla conversione da BDE a SQLite, 
mentre ce n'č su BDE a IB.
Ci sono motivi per preferire l'uno o latro ? 
 
 
---
Questa e-mail č stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 passaggio a SqlLite, viste le mie esigenze non proprio sofisticate. [...]
 
Ma tu devi migrare un database esistente, o crearlo ex novo?
 
-- 
MARCO BREVEGLIERI (Software and Web Developer)
 #Home: 
http://www.marco.breveglieri.name
 
 #Blog: 
http://www.compilaquindiva.com
 
 #DelphiPodcast: 
http://www.delphipodcast.com
 

 Ci sono motivi per preferire l'uno o latro ?
 
Piuttosto che SQLite, io valuterei se passare a IB o Firebird.
E la comparazione la farei tra IB lite e FB embedded.
FB embedded supporta l'accesso multithreaded, che lo rende multiutente e 
multi connessione. IB lite invece è mono utente, mono connessione e mono 
CPU core. [1]
 
Cosa ne pensi?
 
[1] 
http://www.embarcadero.com/products/interbase/interbase-feature-matrix-xe7.pdf
 
 
-- 
Morde

 Piuttosto che SQLite, io valuterei se passare a IB o Firebird.
 
Se parte da zero, usando una versione aggiornata di Delphi - ove è presente FireDAC, per intenderci - magari SQLite è più indicato, visto che
 
1)
probabilmente non c'è bisogno di "caratteristiche enterprise" particolari;
 
2)
si trova più documentazione;
 
3)
un domani (magari non troppo lontano) potrebbe migrare su Android senza particolari problemi, dove SQLite è già presente, mentre Firebird non c'è.



Direi che il punto 3) ha molta rilevanza, non avevo considerato 
un'eventuale migrazione su mobile.
 
-- 
 
Corrado


Direi che il punto 3) ha molta rilevanza, non avevo considerato
un'eventuale migrazione su mobile.
Corrado
--
Ma c'è IB Lite ! E ho un problema di migrazione di database. Avevo già 
cominciato ad affrontare il problema con Sqlite, ma di strumenti gratis non 
ce ne sono e probabilemnte dovrei passare da dBase a csv a Sqlite. Di 
documentazione su Sqlite ce n'è in abbondanza, ma non relativa alla 
migrazione da BDE/dBase 
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 migrazione da BDE/dBase.
 
Per convertire il database, puoi sempre scrivere un piccolo applicativo che faccia questo, se non esiste "in natura": travasare dei dati da un database dBase a SQLite non dovrebbe richiedere chissà quale sforzo, considerando che non hai trigger, stored procedure o altri oggetti complessi nel DB, ma si tratta solo di copiare i dati nella nuova struttura.
 
Di migrazione da BDE a SQLite non si parla perché BDE è una libreria di componenti per l'accesso a database, e SQLite è un database: al massimo devi cercare informazioni sulla migrazione da BDE a un'altra libreria, come FireDAC.


 qualche giorno fa, mi č capitato di vedere un video su IB Lite
 
Lascia perdere. Scordati sia Firebird che Interbase. Sono prodotti di nicchia, che non conosce praticamente nessuno, e per i quali non riceveresti alcun supporto in caso di problemi.
 
SQLite va benissimo, se non hai esigenze troppo grandi. In alternativa, Postgres e` un ottimo database per ambiti professionali, con una curva di apprendimento non troppo ardua. Anche MySQL va bene in molti casi (lo trovo meno buono di Postgres e con piu` "quirks").

 presente FireDAC, per intenderci - magari SQLite è più indicato
 
SQLite non e` mai indicato per partire da zero. Ed il motivo e` semplice:
 
sqlite> create table test (uno integer, due varchar(30));
sqlite> insert into test values (1, "uno");
sqlite> select * from test;
1|uno
sqlite> insert into test values ("due", 2);
sqlite> select * from test;
1|uno
due|2
sqlite>
 
Enrico

 conosce praticamente nessuno
 
Saro` io, ma tra documentazione e internet ho sempre trotato tutto quello 
che mi serviva per gestire un database Firebird
 
Enrico


E ti può interessare io ho convertito
   tabelle BDE-paradox ->Mysql
e tabelle Clipper-Ntx ->Mysql

E ti può interessare io ho convertito
   tabelle BDE-paradox ->Mysql
e tabelle Clipper-Ntx ->Mysql
---
E che problemi hai avuto ?
(E anche a Unicode?) 


Non è la 1a volta che confondi tecnologie di accesso adi dati (bde, dbx, ado, firedac, 
ado.net
, ibx, doa) con database (paradox, db2 oracle, sybase, mysql, firebird etc)
 
Ancora, trovo decisamente preoccupante che la scelta di un db sostitutivo rispetto a quello che usi attualmente dipende non dalle features o altro ma dalla esistenza o meno di un tool comodo per il passaggio dei dati.
 
Solo TU conosci le esigenze che hai adesso le quali, aggiungendo qualcosa per avere una visione da qui ad un paio di anni, sono FONDAMENTALI per capire quale potrebbe essere la migliore alternativa in termini anche ma non solo economici.
 
Infine, se da un lato è ammirevole il farsi domande su questa cosa, spesso *sembra* che tu stia cercando di evitare di fare tu stesso delle prove, fermandoti alla prima difficoltà.
 
Magari sei convinto che su internet trovierai tutto quanto tui è necessario per evitare di tozzare su qualcosa e fare in moodo che il tuo porting vada liscio come l'olio.
 
Bhe, non è cosi.
L'esperienza di altri puo' essere una INDICAZIONE ma niente di piu.
Poi la strada devi percorrerla tu.
 
 
 

"Alberto Salvati"  ha scritto nel messaggio 
news:cb85ff27-635a-4e0f...@googlegroups.com...
Magari sei convinto che su internet trovierai tutto quanto tui è necessario 
per evitare di tozzare su qualcosa e fare in moodo che il tuo porting vada 
liscio come l'olio.
Bhe, non è cosi.
L'esperienza di altri puo' essere una INDICAZIONE ma niente di piu.
Poi la strada devi percorrerla tu.
---
Mentre ti ringrazio per il solo fatto che partecipi alla discussione e mi 
dici cose sensate, nello stesso tempo vorrei difendermi dall'accusa di non 
tentare di percorrere la mia strada per conto mio. Ho invece provato ad 
indagare sulla strada migliore che ad un certo punto mi era sembrata quella 
di SQLite, soprattutto in relazione alle mie esigenze di sviluppatore quasi 
hobbistico. Ho anche iniziato a convertire qualche file dBase, seguendo la 
strada di una conversione a file csv (perchè da una parte ho Delphi con il 
BDE e i files dBase, dall'altra ho FireDAC ma non il BDE).
Procedo con lentezza, anche perchè alcune difficoltà di altro genere mi 
hanno messo in difficoltà (per esempio delle funzioni sulle stringhe che non 
piacciono a XE7).. Nel frattempo, continuando a guardarmi in giro mi sono 
imbattuto su un video di Embarcadero dove la conversione da BDE a IB Lite 
sembrava così semplice e indolore che mi sono tronati i dubbi. Ed ecco la 
ragione del mio messaggio su questo tema...
 
 
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 ...la conversione da BDE a IB Lite sembrava così semplice...
 
Sorvolo sul fatto che BDE è una tecnologia per l'accesso ai dati mentre 
IB Lite è un motore di database per dirti che troverai migliaia di 
esempi *semplici* di conversione perché, nella maggior parte dei casi, 
non sono esempi reali ma strutture dati pensate proprio per far vedere 
quanto sarebbe semplice, con quelle strutture dati, effettuare la 
conversione.
 
Per mia esperienza personale non ho mai adottato soluzioni precotte. Son 
passato da dati in formato dBIII a Paradox a Firebird (con una breve 
intrusione in Access97 di cui mi pento amaramente :) ) ma sempre 
costruendomi delle mie routine di conversione anche perché, ad ogni 
passaggio, s'aggiungono delle caratteristiche nuove del motore di 
database che è bene sfruttare (nomi di campi più lunghi per descriverne 
meglio il contenuto, campi autoincrementali, tipi di dati nuovi, 
gestioni di transazioni, ecc...).
 
Sono arrivato al punto da scrivere, spinto dalla necessità della 
conversione di un software, una procedura di conversione da Access a 
Firebird che tenga conto delle maggiori casistiche (quali sono i campi 
chiave, la costruzione delle foreign key e degli indici, ecc...) per 
permettermi di convertire (quasi) qualunque MDB in un database Firebird. 
E di programmi che convertono da Access a Firebird ce ne sono parecchi 
in giro, ma nessuno faceva quello che volevo io.
 
-- 
@WarpTen10

 piacciono a XE7).. 
 
Quali?
 
A.

 ragione del mio messaggio su questo tema...
 
Secondo me, non puoi cambiare idea ogni volta che vedi un video...
 
Ad esempio, anche il passaggio da BDE a FireDAC (che sono due entità comparabili, visto che confondi ancora "database" con "libreria") è ben documentato; prendi questo punto di partenza, ad esempio:
http://blog.marcocantu.com/blog/migrating_paradox_dbase.html
 
 
E poi, se decidi di cambiare strada e ti trovi di nuovo in difficoltà, cosa fai... cambi idea di nuovo?
 
Tieni in considerazione che ogni tecnologia/libreria/piattaforma generica di accesso ai dati, che sia BDE, dbExpress, FireDAC, ADO, ODBC e così via, ti permette di accedere tranquillamente a più basi dati eterogenee, quindi avendo l'apposito driver e conoscendo come funziona la libreria (che è il punto focale della questione) la tua applicazione di conversione la puoi scrivere come ti pare e piace.
 
Quindi, prendi una decisione in merito alla libreria che intendi utilizzare, magari facendo qualche prova, e inizia a scrivere l'applicazione di conversione.
 
Poi, quando sarai in difficoltà (se lo sarai), posta il problema/dubbio o l'errore che ottieni, assieme al codice e a una panoramica dell'architettura che hai approntato, e saremo ben felici di aiutarti.
 
Cambiare idea di continuo su quale libreria o database adottare, quando l'uno vale l'altro e i problemi/vantaggi sono pressoché gli stessi dati i tuoi requisiti, è una perdita di tempo inutile (per te), a mio avviso.
 
Ciao!
  Marco.


 piacciono a XE7)..
Quali?
A.
---
Avevo dimenticato di rispondere a questa tua domanda. Mi sono ricordato 
perchè ho trovato un altro caso che ti cito. E' una proc che uso 
estensivamente per controllare l'input di un edit ( Key: è il carattere 
digitato; TGoodChars è un set di Char (o AnsiChar, il risultato è lo 
stesso):
 
procedure ChkGoodChars(var Key: Char; GoodChars: TGoodChars; Edit: 
TCustomEdit);
var
  EditText : string;
  LenEditText : integer;
begin
  EditText := Edit.Text;
  LenEditText := Length(Edit.Text);
  if (LenEditText = 0) then begin
    Include(GoodChars, '-');
    Exclude(GoodChars, FormatSettings.DecimalSeparator);
  end;
  if ((LenEditText = 1) and (EditText[1] = '-')) then begin
    Exclude(GoodChars, FormatSettings.DecimalSeparator);
  end;
  if Pos(FormatSettings.DecimalSeparator, EditText) > 0 then
    Exclude(GoodChars, FormatSettings.DecimalSeparator);
  if not (Key in GoodChars) then begin
    Key := #0;
  end;
 
Il messaggio del compilatore è: "Globals.pas E2010 Incompatible types: 
'AnsiChar' and 'Char' 


 'AnsiChar' and 'Char' 
 
...ma hai CAPITO questo errore? Lo hai risolto?
 
A.

"Alberto Salvati"  ha scritto nel messaggio 
news:879c7858-af8e-4701...@googlegroups.com...

---
Sono duro, non l'ho risolto. Ho pensato che il tipo TGoodChars, definito 
come set di Char, sia preso dal compilatore come AnsiChar (infatti ho 
provato a ridefinirlo così e l'errore permane). Allora ho cambiato la 
definizione di Key: Char in Key: AnsiChar. L'errore si trasferisce allo 
statement  "Exclude(GoodChars, FormatSettings.DecimalSeparator);"
Ne desumo che FormatSettings.DecimalSeparator sia un Char. A questo punto 
non so più cosa fare... Immagino abbia tutto a che fare con i cambiamenti 
avvenuti nelle stringhe con Unicode. Mi sono scoraggiato, e sono tornato a 
disintossicarmi sul mio vecchio Delphi Win32. 
