Newsgroup: it.comp.lang.delphi
Titolo: Da paradox a DB2, Interbase ecc...

Salve a tutti,
Qualcuno potrebbe darmi un consiglio circa la "migrazione" di
un'intero pacchetto di progetti (numerosi) da paradox a DB2 e/o
interbase?
Quali sono i "trucchi" per rendere questo processo il meno laborioso
possibile?
C'e' la possibilita' di ottenere un prodotto funzionante sia con db2
che con interbase? 
Ringrazio in anticipo chi volesse darmi una mano.
JH

che con interbase? 
Certo, altrimenti che li avrebbero inventati a fare ? :)
-- 
Andrea Laforgia - walkietalkie(at)
libero.it
"Meglio cieco che negro" (Stevie Wonder)

Certo, altrimenti che li avrebbero inventati a fare ? :)
Dalla tua risposta, credo di capire che, forse, mi sono spiegato male
:)
Io volevo dire se e' possibile fare un pacchetto funzionante sia con
DB2  sia con InterBase...
In tal caso come mi consiglieresti di scrivere il codice?
Con la compilazione condizionale?
Io non ne ho la minima idea...per Interbase posso usare gli IBX, a
quanto ho capito...ma per DB2 immagino debba utilizzare solo i
componenti "standard"...
Allora come faccio a mettere insieme queste due cose??
Ciao e grazie per il link
JH

 Allora come faccio a mettere insieme queste due cose??
Potresti utilizzare ODBC e risolvi, nel senso che
fai riferimento solo a un alias e nient'altro.
Poi, se questo alias e' DB2 o Interbase non e' importante.
Tutto questo, in teoria.
In pratica, temo che la cosa piu' conveniente sia scrivere
due applicazioni distinte ;)
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

DB2  sia con InterBase...
Certo che è possibile, ed esistono anche diverse alternative. Provo
solo ad elencarti quelle che mi vengono in mente.
1) Usare ODBC ( come suggerito sopra) 
	Io te lo sconsiglio vivamente
2) Usare BDE con query sql standard
	la soluzione è semplice e non devi fare praticamente quasi
nulla pero' stai attento che usare il bde per una nuova applicazione
significa sviluppare usando una tecnologia già vecchia e che
(presto??) non verrà piu' supportata
3) Usare DBExpress 
	secondo me è la soluzione migliore, quella verso cui spinge
Borland e, con un po di pazienza, quella che dovrebbe garantirti
meglio per il futuro (dico pazienza perchè essendo componenti nuovi
hanno ancora qualche baco)
4) Usare una tecnica sviluppata da te che ti permetta di crearti a
runtime gli oggetti IBX per interbase, dbexpress per DB2 oppure
altro.., e comandarli tutti allo stesso modo tramite l'interfaccia
IProviderSupport. E' senza dubbio la cosa migliore ma, ovviamente,
anche la piu' complessa, lunga e forse (alla fine) meno efficiente
rispetto alla 2 o alla 3.
Ciao, Rocco.

Prima di tutto, va detto che concettualmente Paradox č
molto diverso da Db2, Interbase e gli altri db client/server 
relazionali.
Interbase č opensource.
Senza troppe pretese il suo dovere lo fa, ma manca di alcune
funzioni che permettono di scrivere meno codice nelle
applicazioni.
Ad esempio, Sybase ha la funzione Coalesce;
questa funzione accetta un numero variabile di parametri
(campi, in genere) e ti restituisce il primo valore diverso
da null che trova.
Questa funzione su interbase non esiste: quindi tocca farsela
a mano nel codice.
Db2 di Ibm costa e non poco, se non vado errato.
Se vuoi una applicazione che possa utilizzare in modo
trasparente entrambi i db a scelta, molte ottimizzazioni
tipiche di uno specifico db non le puoi utilizzare, in quanto
di solito non sono standard.
Quindi, cio' che normalmente faresti fare al db,
ti tocca farlo da codice.
Inoltre, non puoi naturalmente utilizzare vcl specifici di accesso
ai dati.
Se usi Ibx, addio Db2.
Quindi, devi usare vcl standard di delphi (Bde o DbExpress).
Ma, di base, TTable va buttata via.
Bye
AS


 Ma, di base, TTable va buttata via.
Non sarei cosi' drastico.
Sempre nel rispetto dei loro limiti, le TTable vanno 
ancora bene per molte applicazioni.



Secondo me l'unico motivo per usare le TTable è tentare di ottimizzare
certe operazioni con Paradox. Per tutto il resto sono da evitare,
specialmente con i db server.
Ciao, Rocco.

 specialmente con i db server.
Vero, ma non dimentichiamoci che sono ancora molte
le applicazioni basate su Paradox.


In questo sono drastico in quanto mi è toccato il porting
di una applicazione delphi basata su TTable (con Sybase!).
La richiesta primaria era ottimizzare le prestazioni che erano
da suicidio data la mole di dati.
Ho ovviamente dovuto sostituire le TTable con delle tQuery.
Ma, facendo cio', ho dovuto riscrivere gran parte della 
applicazione, basata in modo massiccio su caratteristiche tipiche
di TTable che tQuery non ha.
Dopo questa traumatica esperienza, sono molto restio a usare tTable.
Anche con paradox, preferirei TQuery, se non altro per non essere
poi costretto a modificare la logica di funzionamento della
applicazione qualora a qualcuno venisse l'idea di migliorarla,
potenziarla o modifcarla, o, peggio che mai,
cambiare il database.
Chiedo scusa a tutto il NG se risulto drastico su questo
tema, ma dopo quello che ho passato la sola idea di mettere
in una mia app un TTable mi fa venire i brividi....
Bye
AS


 cambiare il database.
Be', le TQuery, se non vuoi sfruttare lo strato del TDataSet,
ti comportano l'uso dell'SQL e, secondo me, con Paradox e'
un massacro.


 un massacro.
In che senso?
Bye
AS
