Newsgroup: it.comp.lang.visual-basic
Titolo: Dbase con VB6 ---> ADO o DAO ?

Sto iniziando dei progetti con VB6 che gestiscono dei dati e non so se
utilizzare il solito DAO 3.5 o il nuovo strumento ADO, qualcuno mi sa
consigliare?
Grazie

Erminio,
    Il cosiglio sarebbe di usare ADO, ma dipende molto dal database: se e' e
sara' sempre il jet (MDB), allora forse il DAO ha ancora qualche cartuccia
in piu' da sparare. se invece pensi di dover fare il porting verso qualche
Db server (tipo SQl server o Oracle) allora ti consiglio caldamente ADO,
anche se per ora hai il jet sotto.
Ciao,
Alessandro Scardova
scar...@tin.it
http://space.tin.it/computer/ascardov/

...


tuoi programmi ti serviranno solo sei o sette metodi e proprietà.
Sono d'accordo sul consiglio, non sulla semplicità di utilizzo.
Secondo me bisogna fare due considerazioni:
1) Oggi DAO va meglio di ADO con i database MDB ed ha maggiori funzionalità,
nonostante l'OLE-DB provider per Jet. Per esempio in ADO manca tutta la
parte di definizione del DataBase (puoi solo manipolare i dati in un DB
esistente oppure usare la parte DDL del linguaggio SQL), nè ci sono i metodi
per riparare o compattare un database MDB.
Le prove sul campo indicano inoltre che la velocità dei DAO è tuttora
superiore ad ADO nell'accesso a Database del Client (MDB di Access).
Tutto ciò dovrebbe comunque modificarsi a breve con l'uscita di ADO 2.1 e di
Office 2000.
2) La semplicità degli ADO è IMHO solo apparente, mentre per fare le cose
come si deve in realtà sono più complicati.
Questo perchè è pur vero che settando una manicata di proprietà puoi far
funzionare correttamente il programma, però se usi ADO è per ottenere
presumibilmente vantaggi anche sotto il profilo performance/scalabilità; in
questo caso non puoi prescindere dal crearti la connessione ed il recordset
a mano, settare tutte le caratteristiche ed i vari parametri (tipo,
localizzazione, tipo del comando passato, ecc. ecc.), perchè solo così hai
la certezza che certi parametri "di default" non penalizzeranno il tuo
programma una volta che sarà stato portato da Jet a SQL Server od Oracle.
Inoltre ADO è pensato per accedere a qualunque fonte dati, anche non
relazionale o organizzata in forma di database; per questo motivo alcune
opzioni o scelte di implementazione, che sembrano illogiche, in realtà
servono per gestire l'accesso alle informazioni contenute in file di testo,
in messaggi di posta elettronica, su server Web ecc.
Tutto ciò rappresenta a volte una complicazione per chi deve accedere solo a
dati presenti su database relazionali soprattutto se è abituato ai DAO
(tanto per dirne una, il cursore che gli ADO creano automaticamente è di
tipo ForwardOnly, mentre chi proviene dai DAO si aspetta un Keyset, che è il
corrispondente ADO del Dynaset).
Naturalmente le considerazioni di cui sopra devono essere valutate a seconda
dell'applicazione che si vuole creare, per cui l'una o l'altra potrebbero
avere più o meno peso.
Io ho dovuto recentemente fare la stessa scelta e ho deciso di adottare gli
ADO, essenzialmente perchè avranno il miglior supporto di Microsoft nel
futuro e perchè mi garantisono meglio sotto il profilo della scalabilità.
Ho però avuto alcuni problemini che ho dovuto aggirare; uno dei quali è
tuttora irrisolto (nonostante abbia chiesto per due volte anche qui sul
newsgroup) che riguarda l'uso di cursori lato server all'interno del Data
Environment di VB6.
Ciao a tutti ed in particolare ad Erminio ed Alessandro
<--< Nik >-->
Per rispondermi in E-Mail togliere "deleteme" dall'indirizzo.
To reply me by E-Mail remove "deleteme" from my address.

...
