Newsgroup: it.comp.lang.visual-basic
Titolo: ADO ?

Sulla guida di VB6 leggo:
...In generale, per la maggior parte delle applicazioni DAO, soprattutto
quelle che utilizzano ODBCDirect, il livello di sviluppo di ADO risulta
probabilmente ancora prematuro per consentire la migrazione a ADO.
Attualmente infatti ADO non supporta la definizione dei dati (DDL), utenti,
gruppi e così via. Se tuttavia il modello DAO viene utilizzato soltanto per
applicazioni client-server non basate sul modulo di gestione di database Jet
o sull'utilizzo di DDL, è possibile pensare alla migrazione verso il modello
ADO. Microsoft fornirà in futuro un componente DDL ADO per agevolare il
processo di migrazione da DAO a ADO e per fornire supporto DDL generico ai
fornitori OLE DB.
Stavo pensando di migrare da DAO a ADO, ma dopo avere letto queste righe mi
sono scoraggiato non poco.
Vedo anche che ADO non ha niente di oggetti quali WorkSpace ecc...
Penso che sia un dilemma per molti scegliere di passare ad ADO... mi date
qualche motivazione in più ?
Grazie.
Ciao,
Riccardo Guirrini
Web :          
http://space.tin.it/computer/rguirrin
E-Mail:         
del...@tin.it

 .........
Se sviluppi appicazione Client/Server "pure" ADO potrebbe essere la suluzione
migliore (anche RDO non è da sottovalutare).
Se invece le tue applicazioni solo legate al Jet Engine locale, sicuramente DAO
offre molte più possibilità.
Per chiarire i tui dubbi posso consigliarti un testo che sto trovando utilissimo
G.Naccarato, "Visual Basic - La programmazione dei database", Apogeo 1999.
vedi 
http://www.apogeonline.com/catalogo/470.html
ciao

qualche motivazione in più ?
Se vuoi i miei consigli (anch'io ho dovuto scegliere tra DAO e ADO):
1) Diversamente da quanto ti ha risposto Valentina, sono dell'avviso di
lasciar perdere completamente RDO. Sono da considerarsi oggetti ormai
obsoleti in quanto non vengono usati per Access e per tutti gli altri
DataBase gli ADO sono meglio sia come performance che come flessibilità.
Inoltre la stessa Microsoft non ci investe più sopra e quindi non avranno
alcun miglioramento futuro.
2) Se ti serve assolutamente il DDL di Access devi restare su DAO, almeno
per il momento. Le cose dovrebbero cambiare nel prossimo futuro ma è ovvio
che non puoi passare dei mesi a girarti i pollici in attesa che escano gli
strumenti nuovi che la Microsoft ha promesso per migliorare l'efficacia di
ADO verso i database MDB.
Attenzione comunque che la mancanza degli oggetti di definizione dei
database MDB non significa impossibilità assoluta di modificare la struttura
dell'MDB perchè è comunque possibile (e scontato) l'utilizzo del DDL di SQL
(CREATE TABLE, CREATE INDEX ecc. ecc.); ovviamente ci sono molte limitazioni
ed è ingestibile la sicurezza integrata di Access creando utenti, gruppi
ecc.
Poichè non la uso, per me non è stata una grande limitazione; io proteggo il
database con una password e poi gestisco i permessi con un metodo mio
implementato completamente da codice.
3) Le prestazioni di ADO su database Access sono discretamente inferiori a
quelle di DAO, anche quando si usa l'OLE-DB provider nativo per Microsoft
Jet (usando invece quello generico per ODBC la differenza è estremamente
rilevante ovviamente sempre a favore di DAO).
Poichè normalmente quando si usa un database MDB non si va certamente alla
ricerca di prestazioni, questa potrebbe non essere una mancanza grave e
comunque ti permette di andare avanti a sviluppare beneficiando dei
miglioramenti anche prestazionali che ci saranno con le versioni di ADO del
prossimo futuro.
4) Il modello ad oggetti di ADO è concettualmente più semplice di DAO e
questo lo rende più complicato da programmare. :-))
Infatti, anche solo per mantenere lo stesso livello di sofisticazione, fare
tutto con meno oggetti significa che questi devono avere un numero esagerato
di proprietà e di metodi tra i quali è difficile orientarsi bene in un primo
momento; inoltre ADO è pensato anche per accedere a fonti dati non
strutturate come i messaggi e-mail, le pagine web ecc. e quindi fornisce
proprietà, metodi ed opzioni varie anche per questi ambienti, cosa che
distrae non poco chi voglia programmare per Access punto e basta.
5) Per quella che è la mia esperienza il provider OLE-DB nativo per Access è
lungi dall'essere perfetto. Ho riscontrato problemi con il Data Environment
di VB6 ed anche con aggiornamenti di record con molti campi. Ritengo che
siano problemi degli ADO e non del sottoscritto in quanto semplicemente
sostituendo il provider con quello per ODBC tutto funzionava
meravigliosamente.
6) ADO per contro (ed è la sua caratteristica fondamentale) ha una
scalabilità totale. Basta cambiare l'OLE-DB provider e praticamente tutto il
codice che hai scritto funziona anche sotto Oracle o SQL Server beneficiando
al 100% delle maggiori performance del motore di database.
Inoltre una volta imparato l'object model, per accedere a qualunque tipo di
fonte dati usi sempre gli stessi oggetti e comandi e quindi ti trovi sempre
a tuo agio.
7) Nonostante sia più lento di DAO, ADO ha alcuni metodi nuovi che possono
migliorare molto alcune operazioni. Per esempio trovo fantastico l'Update
che può avere come argomenti degli array: se per ipotesi dovessi aggiornare
un record nei campi Nome e Indirizzo potresti scrivere
rsMioAdo.Update Array("Nome", "Indirizzo"), Array("Pietralunga Nicola", "Via
dei Programmatori 12")
gli Array possono contenere, mescolati tutti i tipi di dati che vuoi
(stringhe, date, numeri, boolean ecc.); questo, per record con molti campi,
da una facilità molto migliore di costruzione del comando rispetto al dover
costruire una stringa SQL ed una velocità enormemente più elevata rispetto
al settaggio dei campi uno per uno seguito dalla chiamata di Update.
In conclusione, se hai un'applicazione già avviata o che necessita di
utilizzo di caratteristiche specifiche di Access (DDL, sicurezze) o che ha
bisogno delle massime performance possibili (anche se si tratta di
guadagnare solo qualche decimo di secondo) e che soprattutto sai che userà
sempre e solo i database MDB oggi è opportuno continuare ad utilizzare i
DAO.
Se invece hai un'applicazione nuova e che prevedi sarà possibile in futuro
far migrare su altri database o che comunque dovrà accedere ad altre fonti
dati, secondo me vale la pena usare ADO.
Ciao,
   <--< Nik >-->
Per rispondermi in E-Mail togliere "deleteme" dall'indirizzo.
To reply me by E-Mail remove "deleteme" from my address.