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

Desidererei sapere quali sono i vantaggi nell'usare ADO anzichè DAO per la
connessione al DB.
ADO è più efficiente in termini di velocità? Un programma che usa DAO
rischia di funzionare male sulle nuove piattaforme? (XP e future...)
Grazie per l'attenzione.

 (XP e future...)
Possibile (anche se estremamente improbabile), ma con la stessa probabilità
anche ADO potrebbe lavorare male sulle nuove piattaforme, dato che con
l'arrivo di 
ADO.NET
 diventerà obsoleto anche lui.
Io sono dell'idea che se lavori in monoutenza senza passare da internet,
sviluppare con DAO porta solo vantaggi. Certo, se hai altre esigenze, DAO le
risolve meglio, ma a scapito della velocità di esecuzione.
Ciao
*Roby*

  Un programma che usa DAO rischia di funzionare male sulle nuove
piattaforme? (XP e future...)
No, il contrario. Avrai più possibilità di vedere ADO che DAO. Su 
ADO.NET
non mi esprimo..., ma pare che sia un altro mondo ancora. Quel nuovo mondo
che, di fatto, impedirà ulteriore sviluppo/correzione/miglioramento di ADO
(e riempirà di brufoli quel poco di pelle rimasta intonsa).
Si capisce che non amo ADO? Vero, per niente! Sono stato comunque, credo,
molto obiettivo.

 appoggia comunque ad ODBC, passando attraverso OLEDB).
ADO (senza dirlo) si appoggia su ODBC, passando attraverso OLEDB?
Questa, in tutta sincerità, non la sapevo.
Ora (mi pare) capisco perchè mai un DAO su db Access con tabelle collegate
(via ODBC e, naturalmente, Jet) alle "gemelle" SQL Server ha, più o meno, le
stesse prestazioni di ADO.
Mi farò un whisky! Sempre uno in meno di Bill!

 No, il contrario.
Chiedo scusa. Come capita spesso (perchč non l'hanno chiamato PIPPO, invece
di ADO?) ho scambiato i due acronimi. La mia risposta al paragrafo presumeva
ADO al posto di DAO, quindi "Un programma che usa _ADO_ rischia di
funzionare male ..."

 Mi farò un whisky! Sempre uno in meno di Bill!
Anche se ti mettessi a fare una gara non potresti batterlo. Questione di
disponibilità economica. :-)
Ciao
*Roby*

 disponibilità economica. :-)
Naaaaa, solo di fegato. ;-)

 
http://www.4guysfromrolla.com/webtech/063099-1.shtml
Ho letto al volo e ti ringrazio per questa che mi pare una "prova"
(oltretutto quasi "ufficiale") incontestabile.
Rileggerò meglio perchè mi è sicuramente sfuggito qualcosa di importante.
Comunque, la frase finale "Well, I hope this has educated a few of you, and
convinced you to connect to your SQL and Access data stores a bit
differently!" mi conforta (oddio, se così si può dire) perchè io la applico
(non uso ADO per Access, assolutamente).
Quello che mi distrugge (senza sorprendermi, vedasi il mio VBDAOADO sul SC,
fatto allo scopo) e la tabella "Performance Comparison", tutta su ADO, mi
par di capire:
SQL+OLEDB (suppongo DSN-Less) iterazione x 1000 records 2900 ms, con DSN
5400 ms
Access+OLEDB (suppongo DSN-Less) iterazione x 1000 records 100 ms, con DSN
950 ms
Scommetto quel che volete che DAO DSN-Less verso Access fa non più della
metà.
Ora mi si dirà (ma già lo so, però non mi basta, anzi, non me ne frega
proprio un bel niente) che sono tecnologie diverse, con scopi diversi e la
velocità è in secondo (io dico almeno quinto) piano.
Va bene, ma chiedo: Quelli che hanno scritto DAO/Jet sono ancora in M$? No,
non credo proprio. Aggiungo: Quelli che hanno scritto ADO+OLEDB ci sono
ancora sicuramente. Questi, secondo me, dovrebbero andare da quelli di
DAO/Jet a imparare a fare le aste e, solo quando sapranno fare i quadratini
(quattro aste correttamente disposte), forse, avranno capito che se si è
fatto 30 si può far 31 e, senza supponenza nè boria, se anche si è fatto 31
si può anche pensare di poter fare 32.
ADO? Bene, ma voglio, proprio per quanto si è già ottenuto con altre
tecnologie, completezza (e qui siamo ancora alle aste), stabilità (solo
qualche quadratino bitorzoluto) e velocità. Quest'ultima non ha nulla a che
vedere con quanto di già conquistato. IMHO, mi vien da scrivere, IMHO un
caxxo, è così e basta, ADO è come la magnesia S.Pellegrino di un
quarantennio fa!

 si può anche pensare di poter fare 32.
Secondo me siamo vittime della maledizione dei linguaggi ad oggetti. C'è
qualcosa che funziona ed è da espandere? Bene, facciamo un wrapper e
espandiamo quello. Per definizione ogni progetto tende a crescere fino a
diventare immantenibile. A quel punto, ciò che c'è è consolidato e anche se
non si sa come funziona viene utilizzato rischiamandolo da fuori.
Con questa filosofia ti ritrovi con una serie di scatole cinesi che si
chiamano l'un l'altra a cascata, probabilmente senza sapere esattamente cosa
fa quella più interna. Chissà quanto codice inutile gira nelle
inizializzazioni degli n-livelli che chiami per passare da ADO a Jet.
Lo stesso problema ce l'hai se utilizzi male l'incapsulamento e
l'ereditarietà. Ti ritrovi a fare i conti con una estrema proliferazione del
codice ed un degrado delle performances.
Peraltro è normale che i gradi di libertà si paghino in termini di velocità.
Molti anni fa, quando il jet era una novità, mi trovai nella situazione di
diver scrivere il codice di una browselist: mentre si digitava in un
TextBox, bisognava riposizionarsi all'interno di una lista composta da
50.000 elementi preordinati e non modificabili.
I tempi con Access sulle macchine dell'epoca erano impossibili. Allora ho
fatto una prova, ho creato un file di testo a struttura fissa ed accesso
casuale, l'ho popolato coi miei record e l'ho utilizzato scrivendomi una
routine in VB per la ricerca dicotomica su file. Beh, i risultato era
estremamente più veloce delle Seek di Access, e poteva essere utilizzato
senza problema anche su computer di fascia bassa.
Che si fa? Torniamo tutti ai files ad accesso casuale?
Ciao
*Roby*

funzionare male ..."
Questa e' controinformazione :-(
-- 
ciao, hal

 Chiedo scusa. Come capita spesso (perchè non l'hanno chiamato PIPPO,


appoggia comunque ad ODBC, passando attraverso OLEDB).
Uhm, questo mi perplime :-(
Ufficialmente, ADO permette di interfacciarsi al provider desiderato,
che puo' essere, fra l' altro, ODBC oppure OLEDB nativo.
Se si usa OLEDB, e gli autori del provider non hanno barato,
ODBC non dovrebbe essere proprio toccata.
Ho appena fatto una prova mettendo sotto trace ODBC.
Usando un provider OLEDB il log e' rimasto vuoto, mentre
si e' riempito alla grande usando un provider ODBC.
Peraltro, l' articoletto di 4GuysForRolla non mi sembra che sostenga
il passaggio obbligato attraverso il layer ODBC.
Anzi, mi sembra dica, invece, proprio il contrario:
<quote>
The answer, young grasshopper, is in the connection string of your connection object. 
Create a connection object like usual: 
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection") 
Then, instead of using a connection string like 
DSN=pubs or DRIVER={MS SQL-Server};UID=sa;PWD=;DATABASE=pubs;
SERVER=myMachine, 
use the following connection string: 
objConn.ConnectionString = "Provider=ProviderName; Data Source=DatabaseSource;
 Initial Catalog=DatabaseName; User ID=UserID; Password=Password" 
</quote>
Cioe' viene suggerito di usare la stringa di connessione nel formato OLEDB.
E mi sembra ancora piu' chiaro qui:
<quote>
Say that you had a DSN-less connection string for a SQL database like so: 
DRIVER={MS SQL-Server};UID=sa;PWD=;DATABASE=pubs;SERVER=myMachine 
To connect directly to OLEDB, your connection string would be: 
Provider=SQLOLEDB; Data Source=myMachine; Initial Catalog=pubs; 
User ID=sa; Password= 
</quote>
-- 
ciao, hal

 Questa e' controinformazione :-(
Mi pare di essere stato abbastanza obiettivo per quello che ho detto.
E' ovvio supporre che ADO possa mantenersi più a lungo (anche su nuove
piattaforme) di DAO.
Ciò non toglie, per completezza di pensiero, che io pensi malissimo di ADO e
che non creda affatto alle supposizioni di cui sopra, sino al punto da
pensare che ADO crolli ben prima di DAO (sic!). Qualcuno, con l'avvento di
ADO.NET
 dice che questo ... sia già avvenuto.
Per me DAO morirà di vecchiaia, ADO per una disgrazia adolescenziale.

 Che si fa? Torniamo tutti ai files ad accesso casuale?
A me questa domanda (retorica, suppongo) non scandalizza affatto.
Credo, infatti, che, _alla fine_, anche il motore di un potente gestore di
database (persino SQL Server) si basi sull'accesso casuale. Complicato fin
che si vuole (e proprio qui sta il punto: con quali prestazioni?), ma
strutturato a record, come una volta: Posizionamento, lettura o scrittura di
"n" bytes, uno in fila all'altro. Come potrebbe essere, ripeto, _alla fine_,
altrimenti?

 Anzi, mi sembra dica, invece, proprio il contrario:
A quanto ho capito io dice che _volendo_ puoi saltare ODBC e usare solo
OLEDB. Ma di default questo non avviene. Comunque non ho fatto prove. Se i
fatti dimostrano il contrario, mi adeguo alla verità rivelata.
Comunque il problema mi tocca poco.Se devo usare ODBC lo uso e basta, senza
passare attraverso troppi layer.
OleDB è una invenzione Microsoft per non usare ODBC che non si sono
inventati loro. La solita mania di onnipotenza. :-)
Questo articolo ironico non parla specificatamente di  OLEDB, ma lo spirito
è comunque quello:
http://www.soft-land.org/cgibin/commenti.pl?doc=commenti/xp&title=Breve+stor
ia+della+programmazione+in+Windows
Ciao
*Roby*

 che non si sono inventati loro.
Errato. Anche ODBC è M$.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

 database (persino SQL Server) si basi sull'accesso casuale.
Si, ma doversi reinventare ogni volta la gestione delle basi dati ad alberi
binari autobilancianti è un po' avvilente. Almeno le fondamenta di base
bisognerebbe poterle sfruttare senza dubbi e remore.
Il problema è semmai quando si comincia a costruire sulle cattedrali invece
che sulle fondamenta. :-)
Ciao
*Roby*

 Errato. Anche ODBC è M$.
Non mi pare:
"ODBC was created by the SQL Access Group and first released in September,
1992. Although Microsoft Windows was the first to provide an ODBC product,
versions now exist for UNIX, OS/2, and Macintosh platforms as well."
http://searchvb.techtarget.com/sDefinition/0,,sid8_gci214133,00.html
Probabilmente ODBC è passato di moda in Microsoft perchè la sigla contiene
la parola OPEN (anche se qualcuno pensa che la O stia per Other :-))
http://www.google.it/search?hl=it&ie=UTF-8&oe=UTF-8&q=%22Other+Data+Base+Con
nectivity%22&lr=
Ciao
*Roby*

 "ODBC was created by the SQL Access Group
La faccenda è intrigante, quindi  ho continuato l'indagine. Dr Dobbs dà una
ulteriore sfumatura a favore di M$:
"In 1990, SAG (Sql Access Group, NdR) took the lead in developing an
SQL-based Call Level Interface (CLI). The CLI SAG is an API for database
access, offering an alternative invocation technique to embedded SQL that
provides essentially equivalent operations. [...] X/Open published the CLI
Snapshot Specification in 1992 as a "work in progress," and it was adopted
for use in commercial software products. Microsoft helped define the X/Open
CLI specification and became the first company to commercialize the CLI
specification by shipping Open Database Connectivity (ODBC) 1.0 for Windows
in 1992."
http://www.ddj.com/documents/s=953/ddj9613a/9613a.htm
Dal documento qui sopra sembra infatti che M$ abbia contribuito allo
sviluppo del prodotto, che era solo una prerelease, e quindi deve prendersi
parte del merito dello sviluppo.
Qui dice che M$ faceva persino parte del SAG, ma sottolinea che non può
prendersi il merito della paternità:
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?ODBC
Ovviamente la M$ dice l'esatto contrario:
"ODBC is the established standard for accessing relational data on many
platforms. This Windows API was first released by Microsoft in 1992 and
later turned over to the SQL Access Group (SAG) standards body"
http://www.microsoft.com/data/davfs.htm
Come al solito: la storia la fanno i vincitori.
Ciao
*Roby*

 Dr Dobbs dà una ulteriore sfumatura a favore di M$:
Ora non ho sottomano la rivista, ma in un articolo proprio su OLE-DB
su un Computer Programming di qualche anno fa, l'autore narrava un
po' di storia di ODBC, attribuendone la paternità alla M$. Stasera,
se riesco, controllo meglio.
