Newsgroup: it.comp.lang.delphi
Titolo: dbExpress e alias di database

Vorrei sapere se e come dbExpress
utilizza gli alias di database (come BDE per capirci).
Ho un progetto che fa pesante utilizzo degli alias (basato su BDE) e
vorrei passare ad impiegare dbExpress.
Quale è la via più semplice (e magari anche indolore??).
ciao e tante grazie.
l.
-- 
* Chi non ha testa abbia gambe *


    Via De Gasperi, 14 - 42019
    Scandiano (Reggio Emilia)

 uno dei server SQL supportati.
per capirci.. esiste qualcosa di paragonabile agli alias che possa
permettere un porting da bde a dbexpress mantenendo in qualche modo
questo concetto?
Non capisco bene se la tua risposta č "scordati di usare gli alias e
roba simile" oppure "non ci sono gli alias ma puoi....".ů
grazie


 roba simile" oppure "non ci sono gli alias ma puoi....".
Quello che non capisco io č questa "predilezione" verso gli alias... :-)
Gli alias sono solo uno dei tanti modi per memorizzare un'insieme di
impostazioni raggruppandole con un nome in modo che siano accessibili a
tutte le applicazioni che intendono farne uso...nulla di piů.
Alcune tecnologie di accesso ai dati, come il BDE, si collegano ad una
base dati attraverso un alias, altre tecnologie invece vogliono un
percorso specifico, e cosě via.
Il problema del porting di un'applicazione BDE a dbExpress non riguarda
gli alias, ma riguarda tutto il resto...č una piattaforma del tutto
diverso, per la quale tuttavia sono stati progettati componenti per
semplificare la migrazione (SQLTable, SQLQuery, SQLStoredProc...).
Se nel BDE si accede al database avente alias "X" usando il componente
TDatabase, in dbExpress si utilizza un componente TSQLConnection che
permette di definire i parametri di connessione al database server e ne
condivide le risorse con tutti i componenti
TSQLTable/TSQLQuery/TSQLStoredProc collegati alla TSQLConnection.
Volendo, č possibile memorizzare le impostazioni di connessione in un
file esterno per poterle richiamare comodamente.


sono ottimi!
L'unica cosa che non mi piace dei ClientDataSet è il fatto che si sia
obbligati a creare gli indici in modo manuale.  Sono dubbioso
sull'effettiva quantità di dati che riescano a gestire e non mi sono
azzardato ad usarli per applicazioni con centinaia di migliaia di
record.  Non ho poi ben capito il senso di dbExpress, è un layer di
interfaccia ai dati, che sfrutta le librerie del produttore.  A questo
punto, per me è stato più comodo usare gli IBX per Interbase e ADO per
Oracle (ma per il quale siamo in procinto di acquistare i DOA). 
Almeno, i componenti in questione sono mirati all'utilizzo con un
particolare DB e quindi si suppone che lavorino al meglio.
-- 
Andrea Laforgia - a.laforgia(at)
libero.it
"There are three kinds of people in this world; 
 those who are good at maths and those who aren't".

percorso specifico, e così via.
Attenzione al fatto che il BDE non necessita obbligatoriamente di un
alias.  Io, per quanto possibile, spesso ho evitato di usare gli
alias, ma ho usato percorsi diretti.


questo concetto?
Il problema non è da BDE a dbExpress, il problema è capire qual è il
DB di partenza e il DB di arrivo.


 record.
premesso che ho visto il dbx solo di sfuggita (attualmente uso d5e...), xche
si è obbligati a fare cio?
Se mi connetto ad un db tipo Oracle o Sybase che ha gli indici, che scopo
hanno gli indici creati da un clientdataset?
A

 Andrea Laforgia - a.laforgia(at)
libero.it
Ciao gabriele (non pensavo di risponedere mai ad a.laforgia!!:)

seri problemi ed ho dovuto utilizzare ADO.. tanto per curiosità)
Il problema è che di questi "a parte" ne ho sentiti parecchi e mi
sembra di ricordare che il driver dbExpress per Oracle non funzionasse
affatto bene...
-- 
Andrea Laforgia - a.laforgia(at)
libero.it
"There are three kinds of people in this world; 


si è obbligati a fare cio?
Perché il CDS (progettato inizialmente per le elaborazioni N-tier) è
stato studiato per lavorare localmente (infatti è un *client* dataset)
e quindi deve tenere i dati in memoria.  Questo, tra l'altro, è
indispensabile nel modello brief-case, uno degli scopi per il quale il
CDS viene utilizzato.  Quindi, non avendo la "visione" diretta dei
dati, perché si possano compiere ricerche veloci è necessario far
costruire gli indici al CDS in memoria.  Ovviamente, lavorando in
memoria, il CDS non può gestire grandi quantità di dati; come dice
Cary Jensen nel suo tutorial:
"[...]I must also admit that this approach is not appropriate for
every application. That a ClientDataSet loads all of its data into
memory makes its use much more difficult when you are working with
large amounts of data. There are work-arounds that you can use if you
point a ClientDataSet to, say, a multi-million record data source, but
doing so sometimes requires a fair amount of coding, thereby
complicating the application".


 particolare DB e quindi si suppone che lavorino al meglio.
Ma i DataSet che forniscono normalmente supporto per l'editing non hanno
bisogno di una memoria sulla quale lavorare? Quindi, che sia un
componente IBTable a fare una "cache" (termine forse improprio) dei
record per le tabelle o un ClientDataSet, comunque una copia dei record
viene fatta in memoria...o sbaglio?
La creazione degli indici manualmente non mi dispiace: li ho aggiunti al
componente ClientDataSet che uso globalmente nell'applicazione e riesco
facilmente ad impostare un ordinamento semplicemente indicando l'indice
che voglio utilizzare.
Per quanto riguarda il senso dell'esistenza del dbExpress, credo che la
Borland volesse semplicemente realizzare un motore di accesso ai
database che fosse multipiattaforma e leggero. IBX è multipiattaforma,
ma è legato unicamente ad InterBase. ADO invece non è presente su Linux.
Io sono partito un po' scettico sulla piattaforma dbExpress e sull'uso
del ClientDataSet, ma devo ammettere che si tratta di una combinazione
veramente funzionale. Nella creazione della nuova versione molto più
complessa di un programma, sono riuscito a scrivere ancora meno codice.
Troppo bello per essere vero. ;-)


 alias, ma ho usato percorsi diretti.
Volevo incentrare l'attenzione sul fatto che non tutte le piattaforme di
accesso ai dati supportano l'uso di alias come avviene per il BDE o per
ODBC.
E' giusto ciò che hai detto, anche se io ho ottenuto diversi effetti
collaterali nell'uso di un percorso diretto. Molto probabilmente, visto
che ne fai un uso esteso, ho sbagliato a configurare il sistema nella
sua globalità...ma ormai mi interessa poco perchè non mi servo più del
BDE.
Ciao!


 scopo hanno gli indici creati da un clientdataset?
Il problema è che i dataset disponibili nel dbExpress sono
unidirezionali: si scorrono solo in un senso. L'utilità di avere degli
indici definiti nella tabella fisica del database si sfrutta solo
quando, attraverso il componente SQLDataSet, si eseguono delle query.
A questo punto, se vuoi fornire un'interfaccia di editing usando ad
esempio una DBGrid, devi usare per forza un ClientDataSet in cui
immagazzinare i dati provenienti da SQLDataSet, poichè quest'ultimo non
include il supporto per l'editing e, come dicevo prima, si può navigare
in un solo senso (da First in avanti con Next).
Il componente ClientDataSet memorizza i dati, ma non acquisisce dal
DataSetProvider (il componente che fa da tramite tra ClientDataSet e
SQLDataSet) la configurazione degli indici, poichè non gli servono dato
che le informazioni contenute nel ClientDataSet sono presenti in memoria
e ordinate secondo indici definiti dall'utente attraverso un'apposita
proprietà.
Forse Andrea Laforgia, riguardo alla scomodità di dover creare gli
indici, si riferiva proprio al fatto che il ClientDataSet non legge
automaticamente gli indici già definiti sulla tabella a cui si accede,
quindi è necessario comunque crearli all'interno dell'IDE di Delphi...ho
indovinato?
Ciao!


 memoria, il CDS non può gestire grandi quantità di dati
Qui mi sono perso... :((
Cosa intendi x ricerche veloci?
Intendi ricerche eseguite lato client su un dataset restituito da un server
db a seguito della esecuzione di una query, o cosa?
Inoltre, il modello tsqldataset|tadodataset-
tdatasetprovider-TCLIENTDATASET- tdatasource potrebbe quindi non essere
utilizzato nella improbabile ipotesi che io decida di mostrare in una dbgrid
100.000 records?
E, nel caso, quale è l'alternativa? Nel caso di dbx, tsqldataset è
unidirezionale e quindi non associabile ad una dbgrid, giusto?
Devo trovare un po di tempo x procurarmi la trial di d7 e smanettare un
po... :(((
Tnx x le risposte.
A

unidirezionale e quindi non associabile ad una dbgrid, giusto?
I dataset unidirezionali non consentono scorrimenti all'indietro, sono
utili, ad esempio, nella generazione di report, ma se vuoi scorrere
all'indietro devi avere un meccanismo che "ricordi" i record su cui si
è già passati e il CDS fa esattamente questo.


database che fosse multipiattaforma e leggero. 
Il che è una lodevole iniziativa, ma nella mia esperienza poche volte
è capitato di dover scrivere un programma che girasse trasparentemente
rispetto alla piattaforma.  Scrivendo programmi su comissione,
generalmente sai già a che DB lavorerai.


 Oracle, c'è poco da scalare ;-)
concordo.
Bye
A
"Le probabilità che un evento si verifichi sono inversamente proporzionali
alla sua desiderabilità."

 generalmente sai già a che DB lavorerai.
Sono d'accordo...ma se non si fanno programmi su commissione? ;-)
Scherzi a parte, sono impegnato nella realizzazione di un gestionale.
InterBase è *la scelta* dal punto di vista del database adottato, ma
l'uso di dbExpress può essere utile per poter eseguire, su richiesta,
ovviamente dietro lauto compenso, una versione alternativa per SQL
Server (ad esempio) per chi ha già una propria infrastruttura che lavora
con questo DB e volesse integrarla.
_Teoricamente_, basterebbe ridefinire le proprietà del componente
SQLConnection e dei componenti SQLDataSet per effettuare un porting
InterBase --> MS SQL Server della mia applicazione...
Ciao!


 InterBase --> MS SQL Server della mia applicazione...
Hai detto bene: teoricamente.
Di fatto, sarebbe comunque una forzatura, date le differenze esistenti tra i
due motori db.
La tua app userebbe M$Sql come se fosse interbase, a prescindere da
differenze di dialetto sql.
Se poi ci sono delle stored procedure?
Bye
A

 due motori db.
Su questo hai ragione ma per come la vedo io potresti realizzare un tuo
framework
indipendente e poi lo specializzi a seconda del db senza dovere avere delle
classi
dedicate per oracle per interbase per sqlserver ecc....
Cmq... sempre punti di vista:))!
ciao
gabriele

con questo DB e volesse integrarla.
Esatto, ma questo significa, per l'appunto, prevedere di portare il
programma su altre piattaforme.  E` deciso in fase di progettazione.
Io non credo (ma è una mia convinzione personale, dettata dalla mia
esperienza) che il trasporto sia così indolore;  è un pò come quando,
con il BDE, si spacciava l'idea che, per portare un programma da un DB
all'altro, bastava cambiare l'alias ;-)


 Se poi ci sono delle stored procedure?
Le stored procedure hanno un nome...se le creo con lo stesso nome, mi
sono già risparmiato del lavoro. Poi, di più non posso dire perchè non
l'ho mai fatto...credo solo di aver scelto la strada più rapida nel caso
mi venga richiesta una cosa simile.


 all'altro, bastava cambiare l'alias ;-)
Infatti, in un altro messaggio ho usato la parola "teoricamente" nel
senso che credo di aver scelto la strada più aperta, poi ovviamente,
trattandosi di elementi totalmente differenti, qualche operazione sarà
da fare. Sono d'accordo con te.


 l'ho mai fatto..
il nome è l'ultimo dei problemi.
Il problema è che probabilmente vanno riscritte.
Bye
A

 Il problema è che probabilmente vanno riscritte.
Beh, questo è ovvio. Che la struttura del database debba essere
ricostruita in SQL Server è un dato di fatto...io mi riferivo a ciò che
deve essere modificato dal lato dell'applicazione a fronte del
cambiamento del DB.


due motori db.
Diciamo che dbExpress è stato studiato con un forte orientamento verso
il cross-DB; nondimeno è venuto fuori con Delphi 6, la prima versione
di Delphi in cui l'attenzione era fortemente focalizzata sulla
portabilità in senso generale (vedi l'introduzione della CLX).  
dbExpress è stato concepito perché offra un'interfaccia astratta
rispetto al motore sottostante.
Ovviamente, anche tralasciando dbX e sfruttando IBX o DOA o MSQLDAC
potresti fare la stessa cosa, ma in questo caso (come dice Gabriele),
il "framework" dovresti costruirlo tu.
Comunque ritengo sia bene discutere di questi argomenti, una volta
tanto, più che come colorare una label su un form;  i confronti tra
tecniche diverse, a mio avviso, aiutano tutti a crescere.  
Purtroppo quella dei programmatori è una delle categorie in cui spesso
si brancola nel buio, augurandosi di star facendo bene.


 cambiamento del DB.
servirebbe un livello di astrazione decisamente elevato.
Si ritorna alla idea del framewrok
Bye
A

 Si ritorna alla idea del framewrok
Non era mia intenzione realizzare un framework. L'applicazione ha una
sua struttura ben definita e deve essere realizzata abbastanza
agevolmente e velocemente.
In questo ambito, volevo solo minimizzare il numero effettivo di
cambiamenti da portare all'applicazione nel caso in cui la si voglia far
girare con un database diverso da quello nativo scelto, cioè InterBase.
Tutto qua.
