Newsgroup: it.comp.lang.visual-basic
Titolo: ADO: sempre più casino

Fantastico! proprio quando penso di aver trovato la strada giusta... track!
Nuove sorpresine veramente deliziose.
Gestire i cursori con ADO e provider Jet è un vero casino.
La guida dice che :
Comportamento dell'oggetto Recordset
"Il modulo di gestione di database Microsoft Jet non supporta cursori
dinamici. Il provider Microsoft OLE DB per Microsoft Jet non supporta
pertanto il tipo di cursore adLockDynamic. Quando viene richiesto un cursore
dinamico, il provider restituisce un cursore keyset e reimposta la proprietà
CursorType per indicare il tipo di recordset restituito. Se inoltre viene
richiesto un recordset aggiornabile, ovvero LockType impostato su
dLockOptimistic, adLockBatchOptimistic o adLockPessimistic, il provider
restituirà anche un cursore keyset e reimposterà la proprietà CursorType."
Quindi, se dopo aver provato in tutte le salse i command, dataenvironment
ecc.... uno legge
qui, gli cadono le braccia e anche il resto.
Non è possibile creare recordset aggiornabili con "Provider Microsoft OLE DB
per Microsoft Jet" ??????
----------------------------------------------------------------------------
----------------------------------------
Ma pero' succede anche questo:
Apro un recordset così:
rs.Open "Select * FROM Clienti", MyConnection, adOpenDynamic,
adLockOptimistic
Debug.print rs.cursorType         'stampa 3  (adOpenStatic)
Cioè, io apro come Dynamic e lui reimposta come static, proprio come dice la
guida.
Il fatto è che, però, se apro così  e modifico il recordset e lo aggiorno
con rs.Update funziona.
Se lo apro come adOpenStatic non funziona......MMMMMhhhhh !
Leggere quindi la proprietà cursorType (e forse anche altre) è completamente
inaffidabile.
Qualcuno (che ha avuto l'ardore di leggere tutto) ha qualche spiegazione, o
io sono diventato matto ?
Ciao,
Riccardo Guirrini
Web :          
http://space.tin.it/computer/rguirrin
E-Mail:         
del...@tin.it

Se lo apro come adOpenStatic non funziona......MMMMMhhhhh !
Se non riesci ad aggiornare il Recordset non è un problema di cursore ma di
LockType, probabilmente l'hai impostato su adLockReadOnly (oppure non l'hai
impostato e quindi è così per default).
La confusione deriva probabilmente dal fatto che, usando DAO, ritieni che
cursori ADO con nomi simili abbiano anche comportamenti simili, invece non è
così.
I cursori ADO sono TUTTI AGGIORNABILI, purchè aperti con un LockType di tipo
Optimistic, BatchOptimistic o Pessimistic. La differenza tra i vari tipi sta
nel fatto che con il cursore Dynamic vedi anche i nuovi inserimenti e le
cancellazioni fatti da altri, con il Keyset vedi solo gli aggiornamenti
fatti da altri sui record che compongono il tuo cursore e non riesci ad
accedere ai record eventualmente cancellati da altri ed infine con lo Static
non vedi alcuno dei cambiamenti eventualmente fatti da altri utenti dal
momento dell'apertura del tuo recordset (tu agisci in pratica su una
fotografia del recordset scattata al momento dell'apertura).
Se il cursore è lato client è ovvio perciò che sia di tipo Static (non vede
gli aggiornamenti degli altri utenti) ma sarà comunque aggiornabile purchè
il Locking non sia di tipo ReadOnly.
Inizialmente il fatto che ADO apra un po' i "cursori che vuole lui", senza
rispettare le richieste del programma e senza ritornare alcun messaggio di
errore, lascia sconcertati, ma la necessità di questo comportamento risulta
evidente se pensi che con gli stessi oggetti (e con lo stesso codice) devi
poter accedere ad una eterogeneità di fonti dati, alcune delle quali anche
NON organizzate in forma di database relazionale o con caratteristiche
peculiari (per esempio è evidentemente impossibile aggiornare una fonte dati
quale una tabella in una pagina HTML, però con ADO la puoi aprire e leggere
come un normale database).
Se ADO ritornasse un errore in tutti i casi in cui non riesce a fornire un
cursore esattamente come richiesto, la gestione degli errori e delle varie
possibilità di apertura da codice risulterebbe eccessivamente complicata;
ecco quindi che viene fornito il tipo di cursore più vicino possibile a
quello richiesto.
In questo modo, d'altro canto, chiedendo l'apertura di un cursore
adOpenDynamic all'OLEDB Provider per Jet avrai invece un Keyset, ma quando
cambierai il motore di database e dovrai portare il tuo programma sotto SQL
Server allora avrai il tuo bel cursore di tipo Dynamic senza cambiare una
riga di codice (occhio comunque al dispendio che questo particolare cursore
richiede in termini di risorse; vale sempre il principio che è meglio aprire
il minimo cursore che soddisfa le esigenze del programma).
Un'altra fonte di confusione, come ho accennato, sono le interrelazioni tra
Connection e Recordset (nel senso che il Recordset eredita le proprietà
della sua Connection, in particolare la CursorLocation) e quelle tra le
proprietà CursorLocation, CursorType e LockType del cursore, per cui una
influenza l'altra (è il caso 
p.es
. della CursorLocation = adUseClient che ti
fa aprire solo un cursore Static, o del LockType Pessimistic che ti
costringe ad usare una CursorLocation = adUseServer, se no si trasforma in
Optimistic).
Per tutto ciò conviene sempre
A) usare estesamente il metodo Supports dei Recordset per vedere se le
opzioni che interessano sono supportate dal Recordset che si è
effettivamente riusciti ad aprire, indipendentemente dal tipo di Recordset
che è stato richiesto;
B) fare attenzione a specificare tutte le caratteristiche del Recordset e
della Connection perchè a volte quelle di Default possono interferire
malignamente contro la volontà del programmatore.
Alla faccia della Microsoft che dice che gli ADO sono più semplici da
usare!!
Potenti lo sono, ma facili proprio non direi...
Spero che adesso tutto risulti un po' più chiaro, se no chiedi pure.
Ciao,
   <--< Nik >-->
Per rispondermi in E-Mail togliere "deleteme" dall'indirizzo.
To reply me by E-Mail remove "deleteme" from my address.