Ciao lxus,
i parametri dopo la connessione riguardano la gestione del cursore.
Partiamo da un esempio:
Private rsProva As ADODB.Recordset
Set rsProva = New ADODB.Recordset
rsProva .CursorLocation = adUseServer
rsProva .Open "SELECT * FROM Tabella1 ORDER BY Colonna1;", cnAdoTutor, adOpenKeyset, adLockOptimistic, adCmdText
La proprietà CursorType stabilisce il tipo di cursore che si vuole utilizzare.
I tipi sono quattro ma non tutti sono supportati da ogni OLEDB Provider (nel caso del Jet manca il primo dell'elenco): ForwardOnly, Static, Keyset e Dinamic in ordine crescente di dispendio di risorse.
* Il ForwardOnly è il cursore di default e permette una sola passata nel recordset, solo in avanti, e ovviamente a fronte delle limitazioni è quello che ha le performance migliori. Va benissimo per esempio per popolare una griglia.
* Lo Static è una specie di fotografia scattata al momento dell'apertura. Può essere usato anche per aggiunte o cancellazioni ma non permette di vedere alcuna modifica effettuata da altri utenti sugli stessi dati. Quando la CursorLocation è adUseClient il cursore è per forza di cose uno Static. E' importante notare che anche lo Static può essere un cursore aggiornabile (l'aggiornabilità o meno dipende solo dalla proprietà LockType), ovviamente potrebbero esserci più di frequente problemi da gestire per aggiornamenti eseguiti sugli stessi dati da altri utenti.
* Il Keyset è un cursore che permette di vedere le modifiche e le cancellazioni fatte da altri utenti sugli stessi dati senza bisogno di fare un Requery; non sono visibili invece le aggiunte effettuate da altri utenti dopo l'apertura del Recordset.
* Il Dynamic è il cursore più dispendioso e più completo. Sono visibili tutte le aggiunte, modifiche e cancellazioni fatte da altri utenti e tutti i tipi di movimenti. Non è supportato dall'OLEDB Provider per Jet.
E' importantissimo tenere presente che, nonostante noi possiamo richiedere uno qualunque di questi quattro cursori, verrà generato sempre il cursore che più si avvicina alla richiesta qualora quello esatto non sia disponibile, e ciò SENZA generare un messaggio d'errore.
Ciò si giustifica con il fatto che tramite ADO è possibile accedere a numerose ed eterogenee fonti di informazione, a volte nemmeno organizzate in forma di DataBase relazionale; il codice utilizzato per accedere ai dati è inoltre praticamente lo stesso in ogni occasione e gli oggetti ADO devono poter essere utilizzati anche da linguaggi molto diversi tra loro (pensate ad esempio all'utilizzo degli ADO in una pagina HTML tramite VBScript o Jscript).
Sarebbe quindi eccessivamente onerosa la gestione degli errori e la logica what/if per accedere ai dati se ogni volta che una caratteristica da noi richiesta non fosse disponibile venisse generato un errore.
Diventa perciò spesso necessario utilizzare il metodo Supports dell'oggetto Recordset che permette di leggere se le caratteristiche che ci interessano sono effettivamente supportate dal Recordset aperto o meno; cioè eseguendo un controllo sulle funzionalità del Recordset posteriore alla sua apertura senza dare nulla per scontato.
La proprietà LockType identifica il tipo di blocco che viene imposto ai record nel Recordset e quindi stabilisce anche le possibilità di aggiornamento.
I tipi di blocco sono: ReadOnly (default), Pessimistic, Optimistic e BatchOptimistic.
* Il ReadOnly permette (ovviamente) solo la lettura. Io lo uso in combinazione con una localizzazione adUseClient ed un tipo di Recordset Static o ForwardOnly per popolare controlli di riepilogo (griglie, combo, report ecc.).
* Il Pessimistic è l'opposto e garantisce che tutte le modifiche ad un record vadano a buon fine, infatti il Record è bloccato per tutti gli altri utenti a partire dalla prima modifica fino alla chiamata dell'Update.
* L'Optimistic permette l'aggiornamento ma blocca il record solo al momento della chiamata dell'Update; è possibile perciò che nel tempo intercorso tra l'inizio della modifica del record (rs!Nome = mstrNome ecc.) ed il comando Update altri abbiano modificato i dati, nel qual caso verrà generato un errore.
* I tre tipi precedenti corrispondono ai diversi tipi di Locking presenti anche nei DAO. Il locking BatchOptimistic, invece, è tipico degli ADO e permette un'aggiornamento di più record in una volta sola; in pratica è possibile modificare un record, spostarsi sul successivo, modificarlo, spostarsi di nuovo ecc. e infine richiamare un unico UpdateBatch che inserirà tutte le modifiche in una volta sola.
Ovviamente in questo caso le possibilità di conflitti sono superiori però questo tipo di locking è molto valido in tutti quei casi dove è consigliato un cursore lato Client (connessione con il Server lenta o intermittente ecc.).
Per utilizzare il locking BatchOptimistic bisogna abilitare la libreria dei cursori lato client (CursorLocation = adUseClient). Inoltre bisogna notare che, sempre nel caso di cursore localizzato sul Client, il locking Pessimistic non è disponibile.
Modificato da marcoin il 26 marzo 2007 16.50 -
