Uso degli ADO in Visual Basic 6 di Nicola Pietralunga (Sesta 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. |
9. Aprire la Connection
La prima cosa da fare per poter lavorare con i dati contenuti nel DataBase è ovviamente predisporre la connessione.
L’oggetto Connection rappresenta la connessione fisica con il DataBase e, nel caso di DataBase Client/server, coinvolge una vera e propria connessione di rete.
Anzitutto bisogna notare che la creazione di una Connection non è un’operazione strettamente necessaria per l’utilizzo di un Recordset; infatti, essendo il modello ad oggetti ADO destrutturato, la definizione di un Recordset crea immediatamente una Connection di servizio (qualora non se ne specifichi una già esistente) che seguirà le caratteristiche e la vita del Recordset stesso (ovvero sarà automaticamente chiusa alla chiusura del Recordset).
Vi è però il problema che le connessioni sono un bene prezioso perché utilizzano risorse di sistema ed hanno delle ripercussioni particolari nel caso di DataBase Client/Server. Non bisogna sprecarle!
Ecco perché è sempre meglio gestire la connessione manualmente e magari condividerla, ove opportuno, tra più Recordset.
L’oggetto Connection possiede numerosi Metodi e Proprietà che ne stabiliscono il comportamento (notare che non tutte le caratteristiche sono supportate da tutti gli OLEDB Provider).
Nel tutorial ci concentreremo solo sulle proprietà CursorLocation e ConnectionString.
La proprietà CursorLocation serve per stabilire la localizzazione di default dei cursori (ovvero i Recordset navigabili) che verranno aperti sulla Connection e può assumere il valore adUseClient o quello adUseServer (default).
A seconda del valore viene utilizzata la libreria dei cursori messa a disposizione dal server di DataBase (adUseServer) o quella resa disponibile direttamente dagli ADO (adUseClient); in questo secondo caso i dati vengono trasferiti immediatamente dal Server al Client il quale si occuperà poi in locale di tutte le elaborazioni.
I cursori lato Client sono in genere quelli più completi e, se le elaborazioni sul Recordset dopo l’apertura non sono particolarmente gravose, sono anche quelli più performanti. Infatti l’operazione più impegnativa normalmente è proprio quella di estrazione dei Record richiesti dal DataBase, in modo da comporre il Recordset, e questa viene sempre fatta dal Server; le operazioni successive vengono invece portate avanti sul Client e ciò rende disponibili delle caratteristiche che magari il Server potrebbe non avere ma che la libreria dei cursori locale degli ADO possiede.
Il problema principale dei cursori lato Client è intimamente connesso alla loro natura: poiché i dati vengono trasferiti inizialmente sul Client, l’utente si trova ad operare senza vedere gli aggiornamenti eventualmente operati da altri sugli stessi dati e quindi potrebbero esserci dei conflitti tra aggiornamenti concorrenti che devono essere gestiti da programma.
Bisogna tener presente che, per default, un Recordset aperto su una certa Connection eredita la proprietà CursorLocation della connessione, ma sarà comunque sempre possibile specificare una localizzazione differente per ciascun Recordset aperto, superando in tal modo il default stabilito per la Connection utilizzata.
La proprietà CursorLocation è sempre Read/Write per l’oggetto Connection ma sarà valida solo per i Recordset aperti dopo la sua impostazione; ovvero cambiando il valore avendo già dei Recordset aperti sulla Connection, il nuovo valore non influirà sulla proprietà CursorLocation degli stessi.
Nella form frmProgrammatori l’oggetto Connection viene definito nella sezione Dichiarazioni
|
Private cnAdoTutor As ADODB.Connection
|
e nell’evento Form_Load viene settata la proprietà CursorLocation e viene aperta la connessione
Set cnAdoTutor = New ADODB.Connection
cnAdoTutor.CursorLocation = adUseServer
cnAdoTutor.Open "Provider=Microsoft.Jet.OLEDB.3.51;Data Source=AdoTutor.mdb" |
La vita della connessione dura fino allo scaricamento della form; dopo l’evento Form_Unload l’oggetto cnAdoTutor verrebbe distrutto automaticamente in quanto uscirebbe di Scope (vedi guida in linea del VB6), però è sempre meglio far pulizia, perciò nell’evento Form_Unload è meglio inserire
cnAdoTutor.Close
Set cnAdoTutor = Nothing
|
In questo caso ho usato le connessioni di default lato Server, con l’idea di lasciare aperta la connessione per tutto il tempo in cui rimane aperta la form. Se si decide di adottare questa tecnica potrebbe essere una buona idea aprire la connessione all’inizio del programma e chiuderla all’uscita, eseguendo poi tutte le operazioni su un’unica connessione con il DataBase.
Una valida alternativa consiste nell’aprire la connessione lato Client, aprire il Recordset e poi chiudere immediatamente la connessione per liberare risorse. In questo modo, fatte salve le considerazioni sui cursori lato Client fatte sopra e approfondite più avanti, le risorse utilizzate sul Client e, soprattutto, sul Server sono ridotte al minimo, garantendo una scalabilità molto elevata (possibilità di gestire molte più postazioni contemporaneamente).
Nelle istruzioni riportate sopra vediamo l’aperura della connessione tramite il metodo Open e la sua chiusura tramite il metodo Close. Al metodo Open è stato passato, come argomento, la stringa di connessione che viene conservata nella proprietà ConnectionString dell’oggetto Connection (tale stringa è specifica per ciascun OLEDB Provider utilizzato, io ho usato quella per il Provider nativo per il Jet).
Avrebbe avuto lo stesso effetto settare prima la proprietà ConnectionString e poi richiamare il metodo Open, scrivendo
cnAdoTutor.ConnectionString = "Provider=Microsoft.Jet.OLEDB.3.51;Data Source=AdoTutor.mdb"
cnAdoTutor.Open
|
Tuttavia esiste, com’è noto, un generale beneficio in termini di performance a passare argomenti invece di settare Proprietà; nel secondo caso, infatti, il programma in esecuzione deve risolvere il riferimento all’oggetto cnAdoTutor due volte invece di una sola. Questa problematica verrà trattata meglio più avanti in occasione dei metodi AddNew e Update dell’oggetto Recordset.
Per le altre caratteristiche dell’oggetto Connection e del metodo Open in particolare (passaggio di nome utente e password ecc.) si rimanda all’help in linea sugli ADO. |
Indietro (ADO solo da codice) | Indice | Avanti (Aprire il recordset)
|
