DAO o ADO ?

di il
16 risposte

DAO o ADO ?

Buongiorno a tutti,

Vorrei chiedere il vostro parere su questo argomento:
Io sono un programmatore di sistemi embedded, solitamente lavoro in C su micro Renesas e STM32.
Pochi mesi fa il mio capo mi ha chiesto di realizzare dei database in supporto all'attività di produzione e in un primo momento ho pensato che Access fosse sufficiente (intendendo con questo la costruzione dei database con il solo approccio grafico senza programmazione VBA che non ho mai usato).
Nello sviluppare il lavoro mi sono reso conto che invece il VBA è fondamentale, e studiando sono arrivato all'uso degli oggetti DAO e ADO. Ho letto che gli oggetti DAO sono arrivati prima degli ADO e che questi ultimi sono quelli su cui Microsoft vuole puntare per fondare il futuro dei propri pacchetti (Office, SQL e tutto il resto).
La mia domanda è :
dovendo finire il lavoro in tempi brevi, e dovendo quindi scegliere fra il DAO e l'ADO per portare avanti il progetto, su quale tipologia di oggetti puntereste ? Sto leggendo che uno sviluppatore nella mia situazione farebbe bene a puntare su ADO, secondo voi?

Grazie dei vostri pareri.

16 Risposte

  • Re: DAO o ADO ?

    StackPtr ha scritto:


    Pochi mesi fa il mio capo mi ha chiesto di realizzare dei database in supporto all'attività di produzione e in un primo momento ho pensato che Access fosse sufficiente (intendendo con questo la costruzione dei database con il solo approccio grafico senza programmazione VBA che non ho mai usato).
    Se il database deve essere integrato in un sistema "embedded", non so se Access sia la scelta ideale per questo scenario.
    Meglio formati più leggeri, tipo SQLite.

    StackPtr ha scritto:


    Nello sviluppare il lavoro mi sono reso conto che invece il VBA è fondamentale
    Non uso VBA da almeno vent'anni, quindi dubito che lo sia realmente, a meno che tu non ti stia riferendo al fatto che il database, in quanto contenitore di dati, non è completo senza l'affiancamento di un programma, che generalmente viene realizzato usando un linguaggio di programmazione, di cui VBA fa parte (oddio...) però vi sono tantissime altre alternative.

    Da un certo punto di vista, l'integrazione di Access e VBA è tale che il codice può essere contenuto direttamente nel DB, compreso quello di eventuali maschere, ma come predetto vi sono tante altre soluzioni.

    StackPtr ha scritto:


    Ho letto che gli oggetti DAO sono arrivati prima degli ADO e che questi ultimi sono quelli su cui Microsoft vuole puntare per fondare il futuro dei propri pacchetti (Office, SQL e tutto il resto).
    Hai letto documentazione vecchia. ADO (o meglio OLE DB) non rappresenta di certo il futuro, bensì il passato, e viene distribuito ancora su Windows per via della sua capillare diffusione ed ampia adozione nello sviluppo di software; tuttavia, si tratta di un pacchetto che non viene aggiornato né evoluto attualmente.

    Al momento, gli sforzi si concentrano su ADO.NET, ossia sui provider realizzati per .NET Framework e .NET Core (e successivi) di interfacciamento alle librerie client dei database esistenti, mentre ADO è abbandonato, e DAO lo è a maggior ragione.

    StackPtr ha scritto:


    dovendo finire il lavoro in tempi brevi, e dovendo quindi scegliere fra il DAO e l'ADO per portare avanti il progetto, su quale tipologia di oggetti puntereste ? Sto leggendo che uno sviluppatore nella mia situazione farebbe bene a puntare su ADO, secondo voi?
    DAO è vecchio e in disuso.
    Si usa ADO, laddove non è possibile usare altro.

    Ciao!
  • Re: DAO o ADO ?

    Io non ho mai usato ADO...ho una conoscenza limitata di VBA in Access, per tanto finchè il mio limite era entro la gestione dei RECORDSET, DAO va molto bene. Provo a rispondere alla tua domanda citando alcune righe prelevate dal manuale "John Viescas: Guida all'uso Microsoft Access 2000".

    DAO:
    DAO è il più vecchio dei due modelli che puoi utilizzare per recuperare i dati ed esaminare o creare nuovi oggetti dati. Questo modello è più adatto a essere utilizzato nelle applicazioni di database di Access (.mdb, .accdb) perchè fornisce oggetti, metodi e proprietà specifiche adatti ad Access e JET DBEngine. Per utilizzare questo modello è necessario chiedere a Visual Basic di caricare un riferimento a Microsoft DAO 3.6 Object Library.

    ADO:
    Microsoft ha introdotto un set generico di modelli di oggetti basati su motore di dati per fornire riferimenti non solo agli oggetti memorizzati da JET DBEngine, ma anche agli oggetti dati memorizzati in altri database quali Microsoft SQL Server: questi modelli vengono chiamati architettura ActiveX Data Objects (ADO).

    Poichè questi modelli sono stati progettati per fornire un set comune di oggetti nei motori a dati che supportano ActiveX Data Objects, non supportano necessariamente tutte le funzioni che puoi trovare nell'architettura DAO progettata specificatamente per Microsoft JET DBEngine. Per questo motivo, se stai progettando un'applicazione che verrà sempre eseguita con JET DBEngine, è preferibile utilizzare il modello DAO. Se invece prevedi che la tua applicazione un giorno possa raggiungere dimensioni tali da richiedere un motore di dati ActiveX quale SQL Server, è preferibile utilizzare il più possibile l'architettura ADO. Se crei un'applicazione Access come progetto di Access (estensione di file .adp) collegata a SQL Server, è preferibile utilizzare solo i modelli ADO.


    Quello che ti ho scritto per me è (quasi) arabo. Per ulteriori dettagli, attendi risposte da utenti più esperti.
  • Re: DAO o ADO ?

    Bella domanda.

    Lavoro con Access per programmare dalla versione 1.0 (quando i primi l'hanno usato dalla vesione 2.0).
    ADO sicuramente ha un livello di astrazione superiore, in pratica cerca di fare tanto, ma in quel tanto ho trovato spesso problemi, una sintassi un po prolissa, insomma da sempre uso DAO senza aver avuto problemi e mi connetto ai DB via ODBC.
    Ovviamente non è che ad ogni versione posso ricominciare a ritestare tutto (ADO è in continua evoluzione), anche perchè le due sintassi sono piuttosto diverse.
    Tieni conto che ho circa 40 progetti alcuni con 400 e più tabelle.
    Da alcuni anni non uso più DB di Access come Back-End ma SQL Server spesso versione Express (a meno che non si tratti di un programma davvero limitato), oppure db MYSQL.
    Sto lavorando sia a 32 che a 64 bit (tutti i progetti nuovi a 64 bit).
    Sto valutando Office 2021 e il componente DAO sembra non presente e il reference non funziona.
    Non vorrei essere costretto a migrare per forza.
    Al momento non conosco altri programmatori che usano Access2021.
    Se devi programmare oggi usa Access 2010 o 2019.
  • Re: DAO o ADO ?

    Wow, come farsi ammazzare ogni prospettiva in un secondo...

    Grazie mille della risposta, approfondisco il discorso:

    Prima cosa, nessuna integrazione embedded, era solo per dire che il mio lavoro è tutt'altro rispetto alla gestione database.
    Sono in azienda per quello scopo, sono stato offerto volontario per realizzare questi database e ora devo trovare la quadra in qualche modo.

    Mi stavo concentrando sui metodi DAO e ADO perchè devo mettere insieme dati che stanno in files diversi, per esempio ho tre files excel. O li importo in un database Access o li lascio in excel. Comunque sia rimarranno separati, e pensavo di usare appunto DAO o ADO per l'accesso attraverso il magico mondo del RecordSet.

    Sto usando VBA perchè integrato in Access, quali alternative ci sono ?
    ADO.NET mi sembra eccessivo, mi pare di capire che mi conviene usare ADO invece di DAO...
    E comunque non ho il tempo di mettermi a studiare cose nuove, già mi trovo a dover scegliere, appunto, fra DAO e ADO.

    Grazie
    Ciao

    Stefano
  • Re: DAO o ADO ?

    Grazie Osvaldo, grazie Paolo.

    Paolo,
    Io ho l'abbonamento Office 365, ma non riesco a capire la versione di Access che c'è dentro.
    Le informazioni dicono versione 2202, il formato file predefinito dice al massimo Access 2007 - Access 2016.

    Grazie a tutti per l'aiuto.

    Ciao
    Stefano
  • Re: DAO o ADO ?

    Dando per scontato la tua scelta di prodotto, ma le osservazioni di [Alka] sono sicuramente un tassello da considerare, non tanto per il linguaggio che no va scelto per "simpatia" quanto in base alle esigenze e secondario ma importante alle conoscenze...!

    Ipotizzando quindi che JET come Database sia frutto di scelta voluta e già ragionata.
    Personalmente non lo consiglio se non per utilizzi LOCALI ma mai per utilizzi in RETE, in cui mi orienterei su un SQL_SERVER Express è gratuito e completamente un'altro mondo.

    Ipotizando sempre che la scelta di Access non come Database, ma come CLIENT, sia altrettanto ragionata.

    Detto questo, la diatriba ADO-DAO è nata prima di Access..., ed escludento NET che con Access non è usabile, serve capire BENE di cosa si sta parlando.
    Il legame non è VBA(DAO) o VBA(ADO)... perchè con Excel è più diffuso ADO, mentre con ACcess non è un caso che sia più diffuso 99% è con DAO.

    Siccome non ci sono più i progetti ADP che era un tipo di prodotto CUSTOM per SQL_SERVER, l'uso di ADO con Access è una possibilità da valutare, mentre l'uso di DAO è Nativo di prodotto.
    Le Form DataBound si appoggiano su DAO, di Nativo Access lavora con DAO, quindi anche se si può usare ADO, ma poi serve capire come intendi lavorare con gli oggetti DataBound come Form e Controlli... dovresti spiegarci bene di cosa parliamo.

    Quindi salvo voler sviluppare come si faceva con VB6 o meglio in modalità UNBOUND, con Access è un ragionamento inutile.

    Saluti
  • Re: DAO o ADO ?

    Personalmente il problema non lo vedo tanto nella multiutenza, quanto nella facilità di distribuzione.
    Ho avuto anche accdb con 10 accessi concorrenti senza problemi (ma con le tabelle in integrità referenziale).
    Se la 'distribuzione' del programma deve essere moltro semplice, allora meglio usare accdb.
    Per strutture centralizzate ed in crescita, senza dubbio meglio SQL Express.
    Per masse di dati consistenti meglio MYSQL.
  • Re: DAO o ADO ?

    Penso di aver fatto qui una buona sintesi.
    https://www.fesoft.it/Holzl/index.php/articoli-tecnici/45-sviluppare-in-ms-access-per-distribuire-applicazioni-gestionali
  • Re: DAO o ADO ?

    paoloholzl ha scritto:


    ADO sicuramente ha un livello di astrazione superiore, in pratica cerca di fare tanto, ma in quel tanto ho trovato spesso problemi, una sintassi un po prolissa, insomma da sempre uso DAO senza aver avuto problemi e mi connetto ai DB via ODBC.
    Parliamo di sintassi, o di proprietà che si possono usare opzionalmente e a discrezione?
    Comunque sia, se non si conosce né l'una né l'altra, come nel caso di chi ha posto la domanda iniziale, tanto vale usare quella più recente, più supportata e più performante tra le due, ossia ADO (OLE DB).

    paoloholzl ha scritto:


    Ovviamente non è che ad ogni versione posso ricominciare a ritestare tutto (ADO è in continua evoluzione), anche perchè le due sintassi sono piuttosto diverse.
    Anche qui, non è chiaro cosa si intenda per "sintassi": gli statement SQL sono gli stessi, gli oggetti sono ovviamente diversi benché tutto sommato neanche così distanti, ma perché esistono diverse entità nella libreria nate appositamente per l'ottimizzazione dell'accesso ai dati.

    Sul ricominciare da zero posso essere d'accordo, ma ha senso quando si parla di tecnologie nuove: ADO nasce nel 1996, quindi ormai ha più di 25 anni, figuriamoci quanto è vecchio DAO o addirittura ODBC!

    paoloholzl ha scritto:


    Sto valutando Office 2021 e il componente DAO sembra non presente e il reference non funziona.
    E' proprio per questo che non è una buona scelta utilizzare strumenti obsoleti: in questo caso peraltro, parliamo di DAO, ossia la versione precedente di una tecnologia - ADO - che è anch'essa ormai sulla strada dell'obsolescenza.

    paoloholzl ha scritto:


    Non vorrei essere costretto a migrare per forza.
    Di nuovo, mi troveresti d'accordo se si parlasse di uno sviluppatore VB6 che nel 2000 deve riscrivere un programma in VB.NET senza un percorso di migrazione, ma qui stiamo parlando di una tecnologia che ha 30 anni di età.

    Va bene il riutilizzo del codice e delle conoscenze, ma qui parliamo di ere geologiche.

    paoloholzl ha scritto:


    Al momento non conosco altri programmatori che usano Access2021.
    Se devi programmare oggi usa Access 2010 o 2019.
    Anche qui, mi sembra riduttivo dare un suggerimento in base al numero di sviluppatori che si conoscono: dipende dalle prerogative del progetto e ci sono tanti altri aspetti da prendere in considerazione.

    paoloholzl ha scritto:


    Personalmente il problema non lo vedo tanto nella multiutenza, quanto nella facilità di distribuzione.
    Il problema è anche nella multi-utenza, quando viene usata una logica bloccante oppure quando il database Access deve essere condiviso in rete, con un degrado delle prestazioni (essendo "file based") anche importante e un traffico di rete rilevante (se i dati sono tanti) accoppiato all'uso di un formato di dati tendenzialmente fragile (non ridondabile, non backuppabile a caldo, ecc.). Con più utenti, si usa SQL Server (o equivalente), piuttosto.

    paoloholzl ha scritto:


    Per strutture centralizzate ed in crescita, senza dubbio meglio SQL Express.
    Esatto, ma ad oggi sono tutte centralizzate e in crescita, salvo casi molto particolari (dove in quel frangente Access è anche trascurabile o facilmente sostituibile).

    paoloholzl ha scritto:


    Per masse di dati consistenti meglio MYSQL.
    Non so cosa si intenda con "masse di dati consistenti", ad ogni modo MySQL e SQL Server (ma anche InterBase, FireBird e tanti altri) sono perfettamente utilizzabili: la differenza sta nelle feature che offrono e nel modo in cui si è abituati a gestirle.

    Ciao!
  • Re: DAO o ADO ?

    StackPtr ha scritto:


    Sto usando VBA perchè integrato in Access, quali alternative ci sono ?
    Se il programma deve essere necessariamente integrato in (o con) Access, direi che non ci sono alternative.
    Per il resto, non hai parlato molto di quello che devi fare, né col database né con l'ipotetica GUI con cui dovresti interagirvi.

    StackPtr ha scritto:


    ADO.NET mi sembra eccessivo, mi pare di capire che mi conviene usare ADO invece di DAO...
    Non è questione di "eccessività": ADO.NET lo usi se sviluppi con .NET, perché è il sistema di accesso ai dati ottimale previsto per quella piattorma di riferimento.

    StackPtr ha scritto:


    E comunque non ho il tempo di mettermi a studiare cose nuove, già mi trovo a dover scegliere, appunto, fra DAO e ADO.
    Volente o nolente, essendo poi tutto (relativamente) nuovo, se fai sviluppo software anche temporalmente, qualcosa te la dovrai imparare in ogni caso.

    Ciao!
  • Re: DAO o ADO ?

    OK, grazie a tutti per le vostre opinioni.
    In risposta sopratutto ad Alex, cerco di riassumere qui sotto l'attuale stato delle richieste (perchè ogni volta che apriamo l'argomento mi aggiungono cose nuove da fare).

    L'azienda si occupa di assemblare schede conto terzi.
    Quello che succede attualmente è che l'amministrazione riceve l'ordine e lo inserisce nel gestionale. Questo associa un numero di commessa che poi gli serve internamente per i vari passi fino alla fatturazione.
    L'amministrazione inizia a compilare una scheda di produzione (che è materialmente un foglio di carta) indicando la commessa, il codice articolo della scheda da montare, il cliente, la scadenza, il numero d'ordine, quanti pezzi vanno fatti e poco altro.
    Il ciclo di assemblaggio è composto da vari passi compiuti da persone diverse, ogni persona che esegue un passo del ciclo produttivo segna la propria firma e la data su questa scheda di produzione, documento che al termine dei lavori viene archiviato per le tracciabilità necessarie.
    La prima richiesta che ho avuto è stato informatizzare questo foglio di carta.
    Quindi in access ho iniziato a preparare una tabella contenente i nomi dei clienti, una tabella contenente i codici articolo delle schede da montare associati al cliente, una tabella con tutti gli operatori che partecipano al ciclo produttivo.
    Questo sta in un database accessibile solo alla direzione (intendo con questo materialmente un file .accdb).

    Poi devo fare un nuovo database (intendo un secondo file .accdb) contenente solo la scheda di produzione. Ogni record è ovviamente una commessa, ogni record è composto dai campi detti sopra (commessa, articolo, ecc ecc) seguiti da una paccata di campi nome_operatore e data per un totale (per ora) di 67 campi.

    I nomi operatore sono nell'altro database, per cui pensavo ai DAO (o ADO) per andare nell'altro database a prelevare i nomi (prelevare o controllare, qualunque cosa faccia devo accedere all'altro database) per garantire uniformità dei contenuti.

    La seconda cosa che devo fare è la gestione dei componenti mancanti (legata a quanto sopra), in questo caso devo accedere al magazzino (che posso avere in un foglio excel, ed eventualmente da questo importato in database Access) e all'elenco fornitori, sempre (pensavo) usando i DAO ( o gli ADO). Da qui parte tutta una serie di controlli, per esempio più richieste per lo stesso componente necessario in diverse commesse, oppure il sollecito delle consegne per le commesse più vicine a scadenza, ecc.

    In questi giorni ho preso in considerazione la possibilità dell'uso di MySQL e della struttura LAMP (o meglio, WAMP) ma non conosco niente di quel mondo, e comunque penso che per il momento Access sia sufficiente per fare quello che devo.

    Spero di essere stato esaustivo.

    Grazie
    Ciao
    Stefano
  • Re: DAO o ADO ?

    Alka ha scritto:


    StackPtr ha scritto:


    Sto usando VBA perchè integrato in Access, quali alternative ci sono ?

    Se il programma deve essere necessariamente integrato in (o con) Access, direi che non ci sono alternative.
    Per il resto, non hai parlato molto di quello che devi fare, né col database né con l'ipotetica GUI con cui dovresti interagirvi.
    Ho appena aggiunto un post in cui spiego il lavoro, spero sia sufficiente.

    StackPtr ha scritto:


    ADO.NET mi sembra eccessivo, mi pare di capire che mi conviene usare ADO invece di DAO...

    Non è questione di "eccessività": ADO.NET lo usi se sviluppi con .NET, perché è il sistema di accesso ai dati ottimale previsto per quella piattorma di riferimento.

    Intendevo che per quello che devo fare attualmente Access sia sufficiente, oltre al fatto che non so niente di .NET.

    StackPtr ha scritto:


    E comunque non ho il tempo di mettermi a studiare cose nuove, già mi trovo a dover scegliere, appunto, fra DAO e ADO.

    Volente o nolente, essendo poi tutto (relativamente) nuovo, se fai sviluppo software anche temporalmente, qualcosa te la dovrai imparare in ogni caso.

    Concordo pienamente, intendevo dire che non ho tempo per studiare tutto e poi scegliere, speravo in una dritta per indirizzare meglio i miei sforzi.
  • Re: DAO o ADO ?

    StackPtr ha scritto:


    cerco di riassumere qui sotto l'attuale stato delle richieste [...]
    Per me, SQL Server è e rimane l'ideale per "aggredire" lo scenario che hai descritto.

    StackPtr ha scritto:


    In questi giorni ho preso in considerazione la possibilità dell'uso di MySQL e della struttura LAMP (o meglio, WAMP) ma non conosco niente di quel mondo, e comunque penso che per il momento Access sia sufficiente per fare quello che devo.
    Ma perché passare da Access a MySQL, invece che verso SQL Server, che senz'altro è più "friendly" se si conosce Access?
    Non capisco.
  • Re: DAO o ADO ?

    Alka ha scritto:


    StackPtr ha scritto:


    cerco di riassumere qui sotto l'attuale stato delle richieste [...]
    Per me, SQL Server è e rimane l'ideale per "aggredire" lo scenario che hai descritto.

    StackPtr ha scritto:


    In questi giorni ho preso in considerazione la possibilità dell'uso di MySQL e della struttura LAMP (o meglio, WAMP) ma non conosco niente di quel mondo, e comunque penso che per il momento Access sia sufficiente per fare quello che devo.
    Ma perché passare da Access a MySQL, invece che verso SQL Server, che senz'altro è più "friendly" se si conosce Access?
    Non capisco.
    Non so niente di SQL Server, vado a controllare.

    Grazie
    Ciao
    Ste
Devi accedere o registrarti per scrivere nel forum
16 risposte