Uso degli ADO in Visual Basic 6 di Nicola Pietralunga (Seconda 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. |
5. L’Object Model degli ADO 2.0
Il modello ad oggetti di ADO 2.0 è molto semplice, infatti gli oggetti sono soltanto sei (più tre Collection).
- In cima a tutto, spariti il Workspace ed il Database dei DAO, abbiamo l’oggetto
Connection che rappresenta la connessione tra il Client che utilizza gli ADO
ed il Server di DataBase (in pratica il motore, che per i file MDB è il Jet).
Per quanto sopra l’oggetto Connection gestisce anche le transazioni; nel senso che
Begintrans, Committrans e Rollbacktrans avvengono all’interno di un oggetto Connection e
non più all’interno di un Workspace. Da ciò discende che una transazione può avvenire solo nei riguardi di un unico DataBase. E se io devo gestire una transazione che riguarda più DataBase come faccio? Bisogna usare il Microsoft Transaction Server (così Microsoft vende un’altra licenza di Windows NT Server), ma questa è un’altra storia…
- Logicamente dipendente dall’oggetto Connection abbiamo l’oggetto Recordset, che è lo stesso caro, vecchio Recordset dei DAO, ovvero l’insieme dei Record estratti da una tabella o per mezzo di una Query, un comando SQL ecc. dal nostro DataBase.
- L’oggetto Recordset contiene una Collection Fields che è l’insieme degli oggetti Field, ovvero i campi che compongono ciascun Record del Recordset.
- Sempre dipendente diretto della Connection troviamo l’oggetto Command che è, in pratica, ogni comando specifico che vogliamo eseguire nei riguardi del nostro DataBase; p.es. una Query memorizzata, magari con parametri.
- E infatti l’oggetto Command contiene una Collection Parameters, composta da oggetti Parameter, ovvero tutti i parametri o argomenti associati al comando che vogliamo eseguire (Query parametrica o, nel caso per esempio di SQL Server o Oracle, anche Stored Procedure, ecc.).
- Infine la Connection contiene una Collection Errors composta da oggetti Error, ovvero tutti gli errori generati per effetto di un mancato funzionamento dell’OLEDB Provider (impossibilità a stabilire una connessione, comando SQL sintatticamente errato, parametri mancanti o di tipo diverso da quello previsto dalla query parametrica e chi più ne ha più ne metta…).
E’ importante capire subito che, dato questo modello ad oggetti fondamentale, non è detto che ciascun oggetto abbia sempre le stesse caratteristiche; questo perché gli ADO possono essere usati in molti modi diversi e per accedere a fonti dati eterogenee. Tanto per fare un esempio l’oggetto Connection potrebbe non essere in grado di gestire le transazioni perché non supportate dall’OLEDB Provider in uso per accedere a quella certa fonte dati, oppure perché si sta usando una Connection lato client (vedi più avanti) ed un Recordset sconnesso. |
Indietro (ADO in generale) | Indice | Avanti (Il progetto adotutor.vbp)
|
