Newsgroup: it.comp.software.database
Titolo: ADO vs DAO

Devo accedere ad un DB Access tramite Delphi 6.
Mi consigliate di appoggiarmi a componenti ADO o DAO?
Quali sono i vantaggi di una dell'altra modalità di accesso
ai dati?
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com
cosa c'entra Visual Basic 
con la programmazione?
(Antonio Cuni, PROGRAMMATORE)

 ai dati?
Vedi 
http://www.soft-land.org/articoli/daomfc.html
Davide
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Vedi 
http://www.soft-land.org/articoli/daomfc.html
grazie mille per la dritta peccato che io non possa usare
MFC :) ma Delphi


 Vedi 
http://www.soft-land.org/articoli/daomfc.html
dove pero' si parla quasi esclusivamente di dao. usato, fra l'altro, con c,
mentre credo che vb nasca al 90% come linguaggio per interfacce a db (specie
access, guarda un po'). tempi di sviluppo e _manutenzione_ molto inferiori
al c, prestazioni non troppo inferiori (con i db non fai number crunching
come in photoshop, devi ragionare sui ms del disco, non sui ns della ram).
per usare delphi prova a chiedere su icld. mi sembra che il db nativo di
delphi sia interbase. non so quanto sia previsto da dao, conoscendo ms, mi
sa molto poco.
dao vs ado (in ordine di apparizione): se ne e' discusso allo spasimo su
iclvb. in sostanza:
dao e' perfetto (a prescindere dal database, il che e' un'altra faccenda) se
usi un mdb access, possibilmente in locale (max lan), possibilmente
monoutente (max pochi: chi dice 5, chi dice 50; a naso, starei sui 5-10).
vantaggi: puoi usare gli indici, puoi caricarti in un datacontrol 4 milioni
di righe con accesso istantaneo (i seek ok, ma a farci delle query in lan
con recordset risultanti cospicui andrei cauto: a me stava per esplodere
l'hub :). credo che ms stia progressivamente abbandonando dao.
ado: pensato per consentire la connessione a qualunque db in qualunque
situazione, anche sull'internet. lavori di sql, ti scordi gli indici (per
quanto non consentito dal db; ado 2.1+ credo supporti il seek, ma solo su
access). il che e' una gran palla. ma hai il vantaggio che dovresti poter
portare il codice paro paro su db diversi. ms -- al momento -- ci punta
molto. sui ng usa ho appena letto che 
ado.net
 e' pero' un bel po' diverso.
tipico ms...
cmq:
prima conseguenza banalissima: il setup di un form vb contenente solo un
datacontrol risulta:
dao: +-6mb
ado: +-12 mb (si porta dietro il mdac_typ.exe, cfr. siti ms).
seconda: se usi ado per un access monoutente in locale invece che dao,
piangi. ma se devi usare interbase (che se non sbaglio, a differenza di
access, ha almeno alcune versoni free), mi sa che vai di ado.
non e' un caso che vb nel mondo ms si sia diffuso tanto...
--
ciao, j.
www.sundaysw.com

access, ha almeno alcune versoni free), mi sa che vai di ado.
ok thx utilizzerò dao tanto sono in locale e monoutente :)


credo che ms stia progressivamente abbandonando dao.
dalla roadmap che sto leggendo ora la M$ inserisce DAO nella
lista dei componenti MDAC obsoleti anche se dà questa
spiegazione:
"
Data Access Objects (DAO): DAO APIs provide access to JET
(Access) databases. This API can be used from Microsoft
Visual Basic®, Visual C, and Scripting languages. DAO 3.5
includes ODBC Direct. It shipped with Microsoft® Office 2000
and Office XP. Its final release was DAO 3.6 and it will not
be available on the 64-bit Windows operating system. 
"
insieme a DB-Library e Embedded SQL (E-SQL)
M$ Jet invece è nella lista dei componenti "deprecated":
"
Jet: Starting with Microsoft Data Access Components (MDAC)
version 2.6, MDAC no longer contains Jet components. In
other words, MDAC 2.6, 2.7, and all future MDAC releases do
not contain Microsoft Jet, Microsoft Jet OLE DB Provider,
and the ODBC Desktop Database Drivers. No new feature
enhancements will be made to Jet. For more details, refer to
the Microsoft Knowledge Base article Q271908, INFO: MDAC
Version 2.6 and Later Do Not Contain Jet or Desktop ODBC
Drivers. 
"
insieme a OLE DB Provider for ODBC (MSDASQL) (come
alternativa propone i drivers nativi per ogni DBMS), OLE DB
Provider for Data Shaping (MSDADS) (alternativa XML), Remote
Data Services (RDS) (alternativa SOAP), Jet Replication
Objects (JRO).
Vedo che vi sono parecchi cambiamenti con le nuove
tecnologie per l'accesso ai dati M$.
I "prodotti" di punta oramai sono: ADO (però + lenta delle
applicazioni  OLE DB e ODBC), ADOMD (?), ADOX, OLE DB (che
però mi sembra un pugno in un occhio...in quanto a facilità
di utilizzo), SQLOLEDB, SQL XML, MSDAORA, ODBC (come mai non
è nella lista dei deprecated?).
Il futuro invece introdurrà 
ADO.NET
 (fornirà OLE DB e i
driver per M$ SQL Server) ODBC .NET ecc.
 
ma a me cosa cambia alla fin fine? :)


 (Antonio Cuni, PROGRAMMATORE)

io uso vb :)
E' la migliore affermazione che avresti potuto fare :)
cmq io VB l'ho provato settimana scorsa ma mi sono sentito
"perso" :)


 E' la migliore affermazione che avresti potuto fare :)
l'unica, direi. ho ancora un nome :)
ciao, a.