Newsgroup: it.comp.appl.access
Titolo: DAO o ADO

Sto incominciando a imparare ad utilizzare Access 2003 e leggendo vari
testi non sono acora riuscito a capire se è necessario imparare sia
ADO che DAO. Da quanto ho capito ADO è una versione più recente delle
funzioni contenute in DAO anche se incompleta sotto qualche punto di
vista.
Insomma partendo da zero un neo programmatore può ignorare DAO e
studiare solo ADO ?

 studiare solo ADO ?
Dipende da cosa hai intenzione di sviluppare e come.
Se usi Access come FE e JET come BE direi senza ombra di
dubbio che DAO è l'unica cosa da imparare.
Se pensi di passare come BE ad un server SQL ma continui
a sviluppare in Access il FE la cosa è opinabile, ma direi
che forse per flessibilità e scalabilitò potrebbe essere
meglio ADO, ma DAO sarebbe ugualmente necessario.
Ti ricordo che Access usa DAO fino alla versione 2003
come come ObjectType per le Maschere ecc, pertanto le 2
librerie vanno conosciute.
Se invece pensi di passare a progetti ADP allora decisamente
ADO, così come userei ADO se dovessi sviluppare un FE in VB.
A livello di prestazioni come vedi è difficile poter dire quale
sia meglio, in quanto dipende dal contesto.
Ovviamente sono considerazioni personali, e per questo Opinabili.
Ciao
@Alex
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 sia meglio, in quanto dipende dal contesto.
Ciao.

 Ciao.
P.S. ti ricordi il discorso del progetto di formattazione
REPORT con l'uso dell'Oggetto printer..?
Beh nonostante l'oggetto in questione sia estremamente
semplice da usare ci sono grossi problemi sulla scelta
dell'utilizzo.
Se usato sull'Oggetto Reports(NomeReport).Printer viene
effettuata una riformattazione del Report ad ogni modifica
di proprietŕ con il conseguente reset dell'Array di controlli,
costringendoci a rileggere tutto(perdita di tempo esagerata).
Usandolo su Application i problemi sono altri, vale a dire
il caricamento delle personalizzazioni pare non andare.
In ogni caso ci stiamo lavorando visto che la tua idea di base
era ottima.
Ciao.


 era ottima.
Beh, sulle prime credevo fosse più semplice l'implementazione del printer:
sbagliavo   :-)
Comunque quel lavoro già così è notevole e conto d'inserirlo a breve nei
nostri progetti...
Ciao, Oscar

 Ciao, Oscar
Ciao


 wrote in message 
news:5m3gp1p2jkdrefbj2...@4ax.com...

Partendo da zero farei proprio il contrario.
Brunol 



Ok, vi ringrazio per le risposte. 
Il dubbio mi era venuto leggengo un testo su Access dell'Apogeo che
diceva che Microsoft per il futuro puntava tutto su ADO  e che quindi
DAO sarebbe lentamente passata in secondo piano, in quanto la
struttura ADO (ADOX)  è più snella e con caratteristiche di accesso ai
dati universali e altro ancora.
Visto che comunque i miei progetti di utilizzo di Access avranno una
portata limitata mi sembra di capire che con DAO risolvo tutti i tipi
di problemi.
saluti,
leondardo



Per ragioni di compatibilità con la vasta base di applicazioni
realizzate e tuttora gestite con i DAO, questi continuano a essere
supportati in Access 2000.... Ma Microsoft sembra puntare tutto sugli
ADO che sono disponibili non soltanto in Access ma in tutta la gamma
di prodotti software per lo sviluppo offerti da Microsoft...
Si può benissimo continuare  a lavorara con Access 2000 come se fosse
Access 97, ignorando gli Ado e basandosi soltanto sui DAO ma non
sarebbe una scelta strategica, perchè è politica dichiarata di M. di
abbandonare progressivamente i DAO per fare di ADO la struttura
portante di tutti i suoi prodotti.......
Potrebbe non  valere la pena convertire all'uso degli ADO
un'applicazione basata sui DAO  e perfettamente funzionante, ma per
chi sta per realizzarne una nuova e complessa farà bene a considerare
attentamente gli ActiveX data Object

 attentamente gli ActiveX data Object
Hai passato gli ultimi 3-4 anni in un container? ;-)
Questo era il tipo di testo di promozione per ADO dalla parte
di MS negli anni 1999 (release di A00) fino a 2001/2002 (AX).
Certo tanti autori hanno ripetuto queste promozioni.
Invece la grande maggioranza di sviluppatori che in pratica e ogni
giorno lavora con Access non è mai seguita in questa direzione.
C'erano ragioni tecniche che abbiamo discusso mille volte.
In principio era sempre l'integrazione e prestazione migliore di
DAO con JET ed MDB. ADO era ed è solo preferito in contesto
di ADP e ASP classico con JET.
Con il release di A03 finalmente anche MS ha accettato la realtà.
In un nuovo MDB di A03 (in contrario di A00 e AX) il riferimento
a DAO non è solo tornato ma precede questo ad ADO.
Nella prossima versione di Access ci saranno i primi adattamenti
ed aggiornamenti per DAO dopo tanti anni di ignoranza dalla
parte di MS.
Non sono solo conseguenze del mercato di Access ma
anche di .NET. ADO è antiquato anche per il marketing di MS
per il quale da 3-4 anni esiste solo 
ADO.NET
. Il nome più o
meno è una finta perché non ha molto da fare con il classico ADO.
Il succo dalla vista di Access:
DAO è un evergreen e il re per Access/JET/MDB.
ADO è il re per ADP. ADOX era un episodio.
ADO.NET
 puo essere il futuro per tutti applicazioni di MS ma
non è ancora integrato nel mondo di Office. Quindi è interessante
ma non per il lavoro attuale con Access.
-- 
HTH
Karl
*********
Access FAQ: 
www.donkarl.com/it
+ Conferenza Italiana per Sviluppatori di Access (CISA) 

 di MS negli anni 1999 (release di A00) fino a 2001/2002 (AX).
;-))

ma non per il lavoro attuale con Access.
Grazie Karl sei stato molto chiaro è sopratutto hai risolto le mie
perplessità su come affrontare senza troppa dispersione lo studio di
ACCESS
saluti,
leonardo