option explicit
public oppure dim -> db as database
public oppur dim rs as recorset
set db = db.opendatabase("menu.mdb")
set rs = db.openrecordset(tabella ,dbopendynaset)
rs.movefirst
rs.movenext
rs.update
rs.addnew
rs.close
ect
non crei un oggetto data ma gestisci i dati
però dai retta a gibra usa dao anzi passa a versioni piu recenti o farai la mia fine
dimenticare vb6 è un impresa.
Infatti quando passai a VB.NET impazzivo cercando invano il controllo Data XDOriginariamente inviato da garzone
però dai retta a gibra usa dao anzi passa a versioni piu recenti o farai la mia fine
dimenticare vb6 è un impresa.
Non ho approfondito molte cose in vb6 perché passai direttamente al .Net
Quindi nel tuo esempio hai usato DAO per aprire il database?
si il dao importi il dao nei riferimenti
poi crei queste variabili e hai fatto
in questo modo niente controlli
e fai le ricerche con select * from
Veramente io ho scritto ADO.Originariamente inviato da garzone
però dai retta a gibra usa dao
Lascia perdere DAO.
Ma sì, DAO... ADO... DOA...ODA... che differenza fa ?Originariamente inviato da garzone
però dai retta a gibra usa dao
Idee chiare eh?
Originariamente inviato da gibra
Veramente io ho scritto ADO.
Lascia perdere DAO.
ADO ADO ADO ADO
scusate volevo scrivere ADO
Ahah... io avevo sbagliato a leggere, avevo letto ADO al posto di DAO.
Comunque per sicurezza scriverò due paginette di "ADO" XD (senza fare copia e incolla XD) Grazie a tutti!
P.S. Viste le circostanze, vi auguro un buon Natale XD e non dimentichiamo di ADOrnare l'albero per stasera xD
Il consiglio di gibra è senz'altro valido.
Però, secondo me, sarebbe meglio se le scelte fossero effettuate a ragion veduta, cioè dopo aver sperimentato le diverse possibilità.
DAO è un modello per l'accesso ai dati piuttosto vecchio sì, ma se questo sia un motivo per scartarlo a priori lo devi decidere tu. Del resto non è che il suo successore ADO sia nato ieri.
Per l'accesso a database Jet (Access) DAO, esendo nato per questo, offre prestazioni migliori; inoltre non presenta un comportamento che in certi casi può essere fastidioso, cioè il ritardo nell'aggiornamento dei dati.
E' vero che, essendosi fermato alla versione 3.6, non è compatibile con le versioni più recenti di Access; questo può essere un altro motivo per scartarlo, ma può anche non esserlo, come al solito lo devi decidere tu.
E' vero che con ADO si possono gestire meglio i problemi di accesso concorrente, ma le applicazioni monoutente difficilmente hanno questa necessità.
Come vedi ogni scelta è valida, purché sia ragionata e basata sulla valutazione delle differenze. Poi è probabile che alla fine uno dica "aveva ragione lui", ma vuoi mettere... la soddisfazione di averlo sperimentato
Non è propriamente così.Originariamente inviato da Grumpy
Per l'accesso a database Jet (Access) DAO, esendo nato per questo, offre prestazioni migliori; inoltre non presenta un comportamento che in certi casi può essere fastidioso, cioè il ritardo nell'aggiornamento dei dati.
Il problema nasce perchè Microsoft ha modificato il tempo di refresh della cache, che ora ha una latenza di 5 secondi ma, come mostro in tutti i miei progetti di esempio, basta un'istruzione per farlo dopo un aggiornamento dei dati:
Jet.RefreshCache CN
ed i dati saranno aggiornati istantaneamente.
Sì, lo so. Infatti l'ho definito "fastidioso" pensando al tempo che impiegai (forse anche tu?) per risolverlo.
Credo comunque che tu abbia capito il senso del mio commento.
Permessi di invio
Rispondi quotando