Newsgroup: it.comp.appl.access
Titolo: perchè ado e perchè non dao chiarimenti

a parte che ADO dicono sia piu prestante che differenze ci sono sostanziali 
nei 2 metodi?
nei riferimenti devo mettere quale ADO?
per aprire un recordset e modificare dati è come con il DAO?
questo codice con ADO per esempio è valido?
Public Sub ImpostaNo()
    Dim db As Database
    Dim rs As Recordset
    Set db = CurrentDb
    Set rs = db.OpenRecordset("select * from anno")
    rs2.Edit
    rs!azzerati = "No"
    rs.Update
    rs.Close
    Set db = Nothing
End Sub
Grazie a tutti.

 End Sub
Proviamo una "conversione":
Public Sub ImpostaNo()
     Dim Cn As ADODB.Connection
     Dim Rs As New ADODB.Recordset
     Set Cn = CurrentProject.Connection
     Rs.Open "select * from anno", Cn, adOpenDynamic, adLockOptimistic
     Rs!azzerati = "No"
     Rs.Update
     Rs.Close
     Set Rs = Nothing
     Set Cn = Nothing
End Sub
In ADO non hai l'oggetto Database ma la Connection, che è più 
flessibile. Un recordset è sempre un recordset, cambia il metodo di 
apertura che è di sua pertinenza, mentre in Dao era db che "spacciava" i 
recordset. Ricordati che qui i recordset vanno istanziati prima dell'uso 
e che dopo che li hai chiusi spesso a riaprirli con Open si offendono, 
meglio una ripassata con New.
Il comando Edit non serve, se il recordset è scrivibile ci scrivi e dai 
l'update e basta. Altre differenze sono di dettaglio: le ricerche 
partono sempre dal record corrente (non esiste FindFirst) e se non trova 
niente arriva a EOF (niente NoMatch) e altre piccole cose alle quali ci 
si abitua in fretta.
Quanto al se Ado è meglio di Dao... beh, sicuramente è più adattabile, 
non fosse altro che grazie al concetto di connessione puoi usare lo 
stesso metodo per accedere a differenti fonti dati ignorando (o quasi) 
da dove arrivano.
IG

 IG
Concordo con tutto quanto hai detto, ma quest'ultima frase non
mi è chiara....!
Anche con DAO si può connettersi a qualsiasi fonte dati senza sapere
cosa sia, basta passare una stringa di Connessione corretta per il DRIVER
ODBC.
MySQL, FIREBIRD, INTERBASE, SQL_SERVER, DBF, EXCEL, ACCESS ecc.....!!
ADO in questo ha le stesse possibilità, ricordiamo poi OLEDB, tando discusso
metodo di connessione, sul quale ancora oggi le maggiori case di gestionali
hanno poco interesse nonostante la pubblicizzazione degli anni 90 della
morte di ODBC(e quando mai).
Una precisazione forse è doverosa per chi lavora con JET, è assurdo usare
ADO.
Per chi lavora con ADP è eccezionale usare ADO.
Ciao
-- 
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

 @Alex (Alessandro Baraldi)
io uso jet quindi continuo con DAO a quanto ho capito.
Però mi chiedo fà proprio cosi schifo jet? ma perchè non lo migliorano?
Booo! illuminatemi grazie. 

 Però mi chiedo fà proprio cosi schifo jet? ma perchè non lo migliorano?
Perchè dovrebbero, visto che puoi utilizzare MSDE o SQL Server (o altri
Server) come base dati.
Se ti fa schifo JET, dato che mi pare tu abbia la Dev di Access 'XP,
sviluppa con MSDE, no?
Ciao.

 Ciao.
se uso MSDE devo usare ADO? 


temo sia troppo traumatico per la mia esperianza con MSDE se mi confermi che 
bastano questi 2 punti potrei pensarci
1 fare l'upsize guidato delle tabelle in ADP
2 includere i file SQL Server quando creo il pacchetto di setup con il 
wizard
basta questo? le form il codice ecc ... resta uguale? le query funzionano 
ancora? grazie mille. 

ALESSANDRO Baraldi ha scritto:
 > Concordo con tutto quanto hai detto, ma quest'ultima frase non
 > mi è chiara....!
 > Anche con DAO si può connettersi a qualsiasi fonte dati senza sapere
 > cosa sia, basta passare una stringa di Connessione corretta per il
 > DRIVER
 > ODBC.
 > MySQL, FIREBIRD, INTERBASE, SQL_SERVER, DBF, EXCEL, ACCESS ecc.....!!
M'è sempre piaciuta l'idea di ridurre al minimo gli strati software. Un 
punto di vista che condivido col vecchio Henry Ford: quello che non c'è 
non si rompe. Restando all'ambito di quello che offre Microsoft come 
tecnologie di accesso ai dati (e, almeno in Access, non hai alternative) 
Ado è quindi più flessibile, in quest'ottica, in quanto possiede 
comunque più driver nativi. Se avessero appoggiato Ado a odbc sarebbe 
stato il non-plus-ultra, ma sappiamo bene che a Redmond gli standard 
vanno indigesti! E del resto non sono i soli a reinventare le ruote: hai 
presente jdbc?
Umhh... pubblicità occulta per l'amico Bill? Per preparare alcune bozze 
di offerta sono un paio di giorni che sono sommerso da brochure 
Microsoft (non sono bravo a inventar balle, quindi le copio), forse 
inizio ad accusare un'intossicazione commerciale... :-)
IG

 IG
Ti capisco, e fortunatamente io non devo farlo non essendo il mio lavoro
ma credo che avrei serissime difficoltà.


 comunque più driver nativi.
Però DAO+ODBC è una configurazione ampiamente rodata e funziona, nonostante
il punto di vista di Henry Ford sia quantomeno saggio.
Ciao.

 ancora? grazie mille.
Se usi i files di progetto l'applicazione dev'essere pesantemente
ristrutturata: le differenze sono tante.
Perņ puoi utilizzare MSDE agganciandoti attraverso ODBC.
E' una soluzione meno scalabile alle ampie multiutenze, ma sicuramente non č
questo il tuo problema.
Usando ODBC č possibile creare applicazioni che girano, senza modifiche, sia
con JET che con MSDE.
Ciao.

 ADO + ODBC Oppure ADO
Errata corrige:
DAO + ODBC  oppure  ADO


mi fai alcuni esempi di cose che cambierebbero se non uso ODBC?
Grazie. 

 mi fai alcuni esempi di cose che cambierebbero se non uso ODBC?
E' sufficiente che tu apra northwind.adp e ci lavori per vedere le abissali
differenze rispetto a un .mdb classico.
Gli .ADP lavorano esclusivamente col SQL del Server.
Ciao.