Salve a tutti.
Ho un mdb di access 2000.
Vorrei collegare un oggetto ADODC a questo mdb. Per la verità ci sono riuscito, ho anche collegato un datagrid (una sciocchezza)...solo che mi viene un dubbio :
quale connection è la più approriata ?
Microsoft Jet 3.51 OLE DB Provider
Microsoft Jet 4.0 OLE DB Provider
Microsoft OLE DB Provider for ODBC Drivers
...
l'mdb è condiviso in multiutenza su almeno 15 postazioni.
Grazie a tutti.
La seconda che hai detto.
Ti ringrazio, quindi Jet OleDB 4.0 Provider.
Ho gia provato però, sinceramente non vedo molta differenza (in termini di prestazioni) ,quando eseguo delle query, tra DAO e ADO...credo che la differenza sta nel fatto che ti puoi collegare "solo" a databsae diversi, ma a velocità credo che siamo li, se non forse di meno con ADO.
Ti ringrazio.
PS
Mi viene un dubbio...quindi anche se mi collegassi con ADO a MYSQL avrei la stessa velocità cioè uguale ad DAO con ACCESS 2000?
Ciao
Mi pare che ci sia un po' di confusione.
DAO è il più vecchio tra i metodi di accesso a database ed è considerato obsoleto. Tuttavia, poiché nacque proprio per interfacciarsi a database MS Jet - e infatti è il modello usato da Access - in termini di velocità, quando usato con questi database, risulta il più performante. I motivi che ne sconsigliano l'uso sono però ben altri e sono più che altro legati ai problemi di concorrenza negli accessi, oltre al fatto della oggettiva vetustà della tecnologia.
Tra l'altro tu hai parlato di accesso al database tramite un controllo ADODC, escludendo quindi a priori l'uso di DAO. Tieni inoltre presente che anche il controllo ADODC gode meritatamente di pessima fama.
ADO, successore e in pratica soppiantatore di DAO, è il metodo di accesso considerato standard per le applicazioni non .NET. La differenza in prestazioni quando usato con il MS Jet (Access), per altro difficilmente misurabile, è ampiamente compensata da una maggiore flessibilità e sicurezza nelle applicazioni multi-utente.
In rete potrai trovare facilmente descrizioni comparative fra questi due modelli, per esempio qui
Confermo ed aggiungo che usare ADODC è da temerari.
Vecchio e antiquato, da MS è stato dimenticato già da anni (risale al MDAC 2.5), ancor prima di terminare il supporto a VB6.
Oltre a questo: è inutile, pesante, consuma risorse e rispetto all'oggetto ADODB.Recordset può solo creare problemi, senza fornire alcun vantaggio.
Non ha proprio senso utilizzarlo.
Riguardo a DAO, aggiungo che il suo sviluppo finisce con Access 2000, oltre non puoi andare per cui se un domani hai un database Access 2002 o superiore non potrai utilizzarlo, ma devi riscrivere tutto il codice per ADO.
Non so quale vantaggio si abbia nell'utilizzare un database stra-vecchio di 10 anni come access 2000, comunque come si dice: "De Gustibus!"
Ma se usato in una rete LAN con 15 utenti, consiglio una profonda riflessione prima di usarlo.
Io non lo userei mai.
Perdonatemi, e vi ringrazio per le vs informazioni, ma ho ancora un sacco di confusione.
----
Quindi, riepilognando, vediamo se ho capito (probabilmente no)
DAO - Vecchia tecnologia (ma sembra che sia ancora la più valida con db di access fino al 97 o 2000 con vb6sp6)
ADO - "nuova" tecnologia che ti permette di collegare db diversi, tramite la proprietà connection, ma per l'uso che dovrei fare io forse è troppo, così troppo che forse non serve.
Che differenza c'è tra ADODB e ADODC ? potete anche non rispondermi capisco che ci sono quintali di pagine nel web che lo diranno...ma magari per voi si tratta di una manciata di sec a dirlo qui.
In ogni caso :
Oggi 2010 qual'è la miglior soluzione ?
con queste caratteristiche :
Access 2000
Visual Basic 6.0
15 Postazioni Lan
db con un paio di tabelle con oltre 50.000 record
Grazie a tutti.
ADODB e ADODC, nonostante la somiglianza dei nomi, sono due cose completamente diverse. Il primo è il prefisso usato per identificare la libreria degli oggetti ADO (connection, recordset, command ...). Quando in un programma definisci una connessione ADO scrivi:
Dim conn As ADODB.Connection per indicare che vuoi creare una conenssione di quel tipo.
Il secondo è un controllo, inteso come oggetto inseribile in un form, che serve a definire implicitamente una connessione e un recordset (sempre ADO) e a visuaalizzare alcuni pulsanti per scorrere avanti e indietro per il recordset. Il suo scopo sarebbe quello di facilitare il collegamento tra i campi del recordset e i controlli come le TextBox o simili praticamente senza scrivere del codice esplicito (tecnica di binding), ma in realtà sono più i problemi che crea delle fatiche che vorrebbe far risparmiare.
Riguardo poi alla domanda sulla "miglior soluzione", in genere 15 utenti sono considerati troppi per un database Access condiviso; naturalmente tutto dipende dall'intensità e frequenza con cui questi utenti vi accedono. Se l'attività non è banale vale la pena di valutare un altro DBMS.
Ma hai letto il link che ti ha indicato Grumpy?Originariamente inviato da ato
Perdonatemi, e vi ringrazio per le vs informazioni, ma ho ancora un sacco di confusione.
Mi sa di no, perchè lì è scritto tutto quello che serve.
Infatti...Originariamente inviato da ato
Quindi, riepilognando, vediamo se ho capito (probabilmente no)
Vecchia tecnologia significa che NON hai a disposizione tutto quello che ha la nuova tecnologia, e tra DAO e ADO ce n'è un bel po' di differenza.Originariamente inviato da ato
DAO - Vecchia tecnologia (ma sembra che sia ancora la più valida con db di access fino al 97 o 2000 con vb6sp6)
ADO è molto molto di più!Originariamente inviato da ato
ADO - "nuova" tecnologia che ti permette di collegare db diversi, tramite la proprietà connection, ma per l'uso che dovrei fare io forse è troppo, così troppo che forse non serve.
Essendo un argomento davvero vecchio e superato, se vuoi conoscere dettagliatamente le differenze tra DAO e ADO non è possibile farlo in un Forum.
Personalmente è da così tanto tempo che non uso più DAO che i miei ricordi sono molto labili. Per fare una cosa fatta bene dovresti andarteli a studiare entrambi.
Ricordo solo che molto tempo fa ripresi in mano un vecchissimo progetto (in VB3) che usava DAO e mi sono messo le mani nei (pochi!) capelli che mi sono rimasti e quasi cadevo nella disperazione.
ADODB è il vero 'cuore' del motore per l'accesso ai dati.Originariamente inviato da ato
Che differenza c'è tra ADODB e ADODC ? potete anche non rispondermi capisco che ci sono quintali di pagine nel web che lo diranno...ma magari per voi si tratta di una manciata di sec a dirlo qui.
ADODC è un 'wrapper' che all'interno usa ADODB , e oltretutto lo fa male.
Lo fa male perchè ADODC (ADO Data Control) nacque per lo stesso motivo per cui nacque il Data Control (di DAO) e serviva a far credere (da MS) ai pivelli (come me) di allora (era all'era del VB3) che :
Realizzare un'applicazione database è banale:
- Si aggiunge un controllo Data,
- si aggiungono i controlli per i campi (textbox, label, ...)
- con pochi clic si collegano i controlli al controlla Data
Ecco fatto la vostra applicazione database!!!
Poi quando uno aveva imparato ben bene questa procedura, man mano che avanza nella programmazione si accorge che questo pone dei seri limiti allo sviluppo, e si trova a perdere un sacco di tempo per mettere le pezze, che puntualmente non funzionano, ma uno ci riprova e perde ulteriore tempo, etc...
Ed allora (solo allora) ci si accorge che deve rifare tutto perchè con ADODC non ne salti fuori nemmeno se sei un mago della programmazione (figurati un pivellino come me) e quindi ricomincia da capo usando ADODB, e finalmente gli si apre un nuovo mondo.
Strano, mentre scrivo mi torna alla mente che nel tour di presentazione di VB2005 vidi fare la stessa cosa dal buon Santini: trascini la tabella sul form e ti crea tutti i campi. Fantastico da vedere. Ma poi........
Che sia un vizio di MS?
insomma ci siamo capiti. Sono lì per vendere no?
Oggi come oggi?Originariamente inviato da ato
In ogni caso :
Oggi 2010 qual'è la miglior soluzione ?
Francamente iniziare oggi un nuovo progetto con DAO è da folli, tanto quanto iniziare a nuovo progetto utilizzando un linguaggio altrettando obsoleto come il VB6 (è del 1998!!! 12 anni fa!!!).
Se io ti chiedessi se per scrivere una lettera è meglio la macchina da scrivere invece del computer, tu cosa mi rispondi? (la tua risposta la conosco già!).
Certo, potrei utilizzare la macchina da scrivere, ma la domanda è: quanto mi conviene?
Oggi come oggi si dovrebbe usare un linguaggio moderno, avanzato, che metta a disposizione tutto quello che serve. In VB6 fare fare certe cose un po' più avanzate dovevi fare i tripli salti mortali, e a volte proprio non era possibile.
Guarda che ti parla uno che di salti mortali, notti insonni e crash 'a gogo' ne ha passati davvero tanti...
E per nuove non intendo obbligatoriamente il .NET di Microsoft.
Ovvio che la naturale evoluzione del VB6 è il VB.NET, oppure il C# (o entrambi!).
Ma esistono anche altri linguaggi, ad esempio il Java (per citarne uno) da cui il C# ha 'scopiazzato' un bel po'...
Le vecchie tecnologie vanno usate solo ed esclusivamente per manutenere i vecchi progetti esistenti, che non si prevede di migrare alle nuove tecnologie.
Sicuramente non DAO, usare assolutamente ADODB.Originariamente inviato da ato
con queste caratteristiche :
Access 2000
Visual Basic 6.0
15 Postazioni Lan
db con un paio di tabelle con oltre 50.000 record
Io ho un vecchio progetto per la Gestione dello Studio Professionale (Pratiche, Appuntamenti, rapportini, scadenze, memo, ecc.) scritto in VB6, ADODB ed usa Access in una rete LAN di 12-15 utenti concorrenti.
La buona notizia è: non ho mai avuto problemi.
La cattiva notizia è: devi studiarti molto-molto-molto bene come gestire un database Access, e la cosa non è affatto semplice, e non mi sento proprio di consigliarlo, visto quello che mi è costato impararla.
Come dice Grumpy vi sono tanti altri database sicuramente migliori e non serve installare per forza SQL Server Express; PostGres, Firebird, SQLLite, ... possono andare benissimo per 2 tabelle.
Qui puoi vederne una bella sfilza:
www.connectionstrings.com
Ok.
Io in 10 (dieci) anni non ho mai avuto problemi con DAO. Nelle mie applicazioni non ho mai usato delle textbox o altri oggetti (tranne il dbgrid) collegato (binding) ai campi delle tabelle.
Mi limito a:
Addnew
Edit
delete
seek
findfirst
recorsource
vi assicuro che non mi ha mai dato problemi (sempre 15 postazioni archivi anche da 500 MB di access)
A dire il vero, ora che l'archivio è diventato davvero grande, per determinate interrogazioni ci mette vermante un sacco di tempo (anche 4 ore), tipo quando usi:
Select * from tabella where condizioni ( And Non In ( select * from bla bla bla )).....addio
(parlo di tabelle con 300.000 record), si lo so prima ho detto 50.000 ma non lo ritenevo importante in quel contesto.
Allora invece di eseguire la query di cui prima, ora gliela creo, fisicamente, all'interno di access ( con QueryDefs) dopodichè passo direttamente il recordsource all'oggetto data che è collegato con la dbgrid...vi assicuro che i tempi sono molto migliorati, forse perchè lavora direttamente Access, cioè l'oggetto data deve solo collegarsi a quella query che esiste in access.
Quindi, a questo punto, che senso ha usare una tecnologia o un altra visto che il DB è sempre lo stesso e da codice mi limito solo a creare fisicamente la query all'interno di access ?
Sembra che voglia assolutamente fare una campagna per DAO, vi assicuro che non è così , è solo che prima di mettere mano al progetto vorrei avere dei consigli da chi ci è già passato.
Un' ultima cosa:
ADODB lo si usa via codice ?
ADODC è l'oggetto che metto nel form ?
Se decidessi di aggiornare devo USARE ADODB ?
Giusto ?
Ciao
--
Ma hai letto il link che ti ha indicato Grumpy?
Mi sa di no, perchè lì è scritto tutto quello che serve.
---
Non l'ho letto perchè è in inglese, lo conosco ma non è proprio il massimo per me.
No, dicevo, al di la della tecnologia adottata ADO, DAO
se creo una query fisica nel mdb di access, (con QueryDefs) e poi in un form metto semplicemnte un controllo data con il recorsource che punta a quella query cambia qualcosa in termini di prestazioni che eseguire un istruzione sql nel recordsource del controllo data ?
Ciao
Permessi di invio
Rispondi quotando