Uso degli ADO in Visual Basic 6 di Nicola Pietralunga (Prima parte)
Presentiamo in queste pagine il tutorial relativo all'uso degli ADO in Visual Basic 6.0
scritto da Nicola Pietralunga l'8 Aprile 1999.
Chi volesse porre domande sull'argomento può rivolgersi direttamente all'Autore di cui riportiamo
l'indirizzo email: nicola@omeganet.it oppure inserire
un annuncio nella rubrica 'Chiedilo agli esperti'.
Come si legge dal comunicato dell'Autore, la riproduzione del testo e dei files che lo accompagnano
deve essere necessariamente preceduta dall'autorizzazione dello stesso, tranne naturalmente nel caso
di uso personale. |
4. Gli ADO in generale
Come accennato gli ADO, presenti in VB6 nella versione 2.0, sono i più recenti oggetti per l’accesso ai dati sviluppati da Microsoft, che dichiara espressamente di volerli sostituire agli oggetti esistenti DAO ed RDO.
Gli ADO si fondano sulla tecnologia OLEDB e ne rappresentano un’astrazione per permettere l’uso più confortevole di OLEDB in linguaggi ad alto livello quale Visual Basic.
OLEDB è la tecnologia Microsoft del futuro per l’accesso ai dati che, ambiziosamente, vorrebbe dare una risposta completa alle problematiche dell’accesso alle informazioni distribuite, in qualunque ambiente esse siano conservate: dai grandi DataBase relazionali ai messaggi di posta elettronica, dalle pagine web (magari filtrate dal Microsoft Index Server, il motore di ricerca di Microsoft) ai fogli elettronici di Excel.
OLEDB accede alle singole fonti dati attraverso un cosiddetto Provider.
Ad oggi sono stati sviluppati da Microsoft:
- un provider per ODBC utilizzabile per tutte le fonti dati per le quali esista un driver ODBC (ovviamente le prestazioni non sono granchè dato che è necessario attraversare un livello in più prima di arrivare al motore di DataBase);
- un provider nativo per il motore Jet, per l’accesso ai dati contenuti in DataBase MDB; è quello che viene maggiormente preso in considerazione in questo tutorial;
- un provider nativo per SQL Server;
- un provider nativo per Oracle;
- un provider nativo per Index Server;
- un provider nativo per Microsoft ADSI (Active Directory Service Interfaces).
Altri provider sono stati sviluppati da terze parti.
A causa della varietà delle fonti dati alle quali è possibile accedere, gli ADO presentano numerose opzioni che possono confondere lo sviluppatore abituato ad accedere ai classici DataBase relazionali. Oltre a ciò gli ADO sono composti da un numero di oggetti sensibilmente inferiore rispetto ai DAO.
Questo da un lato rappresenta un vantaggio perché l’Object Model è particolarmente immediato da comprendere, d’altro canto, poiché la sofisticazione degli ADO non è inferiore a quella dei DAO, fare le stesse cose con meno oggetti significa avere per ciascun oggetto un numero decisamente superiore di proprietà e metodi.
A ciò si aggiungono due caratteristiche:
- Gli ADO sono completamente "destrutturati" rispetto a quanto accadeva per i DAO, nel senso che oggetti inferiori (per esempio l’oggetto Recordset) non richiedono la manipolazione preventiva degli oggetti superiori nella gerarchia (sempre continuando l’esempio, l’oggetto Connection); nei DAO invece la gerarchia era molto rigida e non si poteva avere un Recordset senza prima avere istanziato il Workspace ed il Database;
- Gli ADO espongono tutta una serie di eventi che permettono di lanciare elaborazioni di tipo asincrono, cioè andando a fare qualcos’altro mentre la manipolazione dei dati viene completata.
Tutto questo IMHO rende particolarmente "sdrucciolevole" il terreno per chi voglia iniziare ad esplorare gli ADO. Penso che sia perciò necessario non lasciarsi influenzare dai comunicati di Microsoft che decantano la maggiore semplicità degli ADO rispetto ai vecchi oggetti di accesso ai dati.
Un’altra considerazione si impone, rivolta all’utilizzatore dei DAO: alla data della stesura del presente documento gli ADO rappresentano un’alternativa meno efficiente dei DAO per l’accesso ai DataBase MDB. Ciò essenzialmente a causa del minore livello di performance dell’OLEDB Provider per il Microsoft Jet rispetto alla manipolazione dello stesso tramite DAO, nonché per la mancanza degli strumenti più avanzati di definizione dei dati (creazione di Tabelle e Query, Relazioni, ecc.) e di quelli per la gestione delle sicurezze e per le operazioni più intimamente legate ai file MDB (scordatevi quindi la possibilità di gestire con ADO utenti e gruppi, come anche la compattazione e la riparazione di un database MDB).
A questo punto perché mai uno sviluppatore sano di mente dovrebbe usare gli ADO per accedere ai DataBase MDB?
Anzitutto quanto ho detto sopra è mitigato dal fatto che certe operazioni di definizione dei dati sono comunque fattibili utilizzando la parte DDL (Data Definition Language) del linguaggio SQL (CREATE TABLE ecc.) ovvero i JOIN per quanto riguarda le relazioni. In secondo luogo il grosso vantaggio degli ADO è che l’accesso ai DataBase MDB, se ben programmato, può essere convertito, con pochissime modifiche al codice, per passare su un altro motore di DataBase (p.es. SQL Server o Oracle) garantendo quindi una grandissima scalabilità.
Infine le cose dovrebbero notevolmente migliorare con l’adozione di ADO 2.1 e l’uscita di Office 2000, prevista entro il secondo trimestre del 1999. Oggi gli ADO 2.1 sono presenti nel pacchetto SQL Server 7.0 ma ne viene sconsigliato l’utilizzo con Visual Studio per l’accesso ai DataBase MDB (…ci attende probabilmente un nuovo Service Pack del VB6 :’-( ). |
Indice | Avanti (L'Object Model)
|
