Newsgroup: it.comp.lang.visual-basic
Titolo: [?2] ADO e SQLsrv: Recset scrollabile

Ripropongo:
Accedo a SQL Server con ADO e SQLOLEDB, apro un recordset con cursore lato
Server e con qualsiasi modalità, ma, siccome l'istruzione SQL contiene una
necessaria "Select DISTINCT..." non lo crea modificabile, ma, maledizione,
nemmeno scrollabile. Finisce per aprirlo senza bookmarks e ForwardOnly.
Se faccio la stessa cosa con cursore lato Client il recordset è con
bookmarks e aperto come Static, quindi scrollabile.
Io avrei scelto il cursore lato Server per una maggior velocità (non deve
trasferire sul Client tutto il recordset di dati), ma come faccio in questi
casi a ottenere un recordset scrollabile? Grazie.

 ha scritto nel messaggio
news:woVr8.131992$%g7.42...@twister2.libero.it...

Ciao Lupo,
non sono in ufficio e non ho modo di verificare, ma se apri il rs in questo
modo :
rs.Open "Select Distinct etc etc", connessione, adOpenStatic
non ottieni un rs scrollabile? Qui a casa con un mdb non ho problemi...
Ciao
 valter

 ha scritto nel messaggio
news:a8pe6u$1di7$1...@newsreader1.mclink.it...

Ciao Valter. No, è esattamente come ho detto. La presenza del DISTINCT fa in
modo che il recset non sia aggiornabile (e questo è comprensibile, oltre che
documentato), ma non capisco perchè me lo apre ForwardOnly, comunque sia la
mia dichiarazione (Static, Keyset, Dynamic), se il cursore è lato server. Se
questo è lato client allora il recordset viene aperto come Static e risulta
scrollabile. Sto impazzendo, anche per il fatto che nella specifica SQL ho
assolutamente bisogno del DISTINCT e fare un cursore lato Client rende
l'operazione lentissima perchè deve trasferire tutti i dati.

 mia dichiarazione (Static, Keyset, Dynamic), se il cursore è lato server.
Potresti postare le statements relative a connessione e apertura del rs?
Ciao
 valter

 > documentato),
Valter, per evitare ogni fraintendimento, è documentato che la DISTINCT
produce recordsets non aggiornabili. Per quanto mi riguarda è chiaro e per
me non è un problema, a meno che per ADO (non certo per DAO) un recordset
non aggiornabile sia anche ForwardOnly...
Ecco le semplici istruzioni (la connessione è normale verso SQLServer con
SQLOLEDB e funziona perfettamente in ogni altro comando di apertura di
recordset):
        Set recordset_finale = New ADODB.Recordset
        lato_cursore = adUseServer
        tipo_apertura = adOpenStatic    'Non cambia nulla con adOpen<KeySet
Dynamic>
        tipo_lock = adLockOptimistic
        recordset_finale.CursorLocation = lato_cursore
        sql="Select DISTINCT CODICE_RUBRICA, COMPETENZA_RUBRICA From
RUBRICA"
        recordset_finale.Open sql, connessione, tipo_apertura, tipo_lock
Il database ha, fra gli altri, un campo KU (non incluso nella Select) che
funge da indice e i campi CODICE_RUBRICA e COMPETENZA_RUBRICA sono entrambi
testo di 8 e 16 caratteri.
Grazie ancora.


[ cut ]
A questo punto mi viene da pensare che ci sia incompatibilità tra il
provider scelto, la
locazione del cursore ed il tipo di blocco sul rs. Ad esempio, visto che
abbiamo appurato
che la DISTINCT non consente l'aggiornabilità del rs, perchè cerchi di
ottenere un
blocco ottimistico e invece non ti limiti ad aprire il rs con un
adLockReadOnly, che
tra parentesi velocizzerebbe il recupero dei dati? Ho l'impressione che ADO
vada un po'
in confusione e ti restituisca il tipo di cursore sbagliato....
Ho usato le medesime istruzioni che hai postato tu, purtroppo ho dovuto
utilizzare
un mdb e quindi il provider jet perchè questo è quello che passa il convento
( leggasi casetta mia ..)
ottengo un recordset NAVIGABILISSIMO, ( MoveLast/First/Next/Previous
eseguite
in rapida successione senza fare una piega) ma ADO mi trasforma il
CursorType 3 ( static )
da me richiesto in un CursorType 1 ( keyset ) senza dirmi nulla... può darsi
che per il provider da te
utilizzato venga invece restituito un CursorType 0 per default... prova a
utilizzare un LockType = 1
( che tra parentesi dovrebbe essere il predefinito ) e fammi sapere...  i
miei test con un mdb non
fanno ..test.. :-)))
in caso negativo domani dall'ufficio continuiamo a sentirci..
Ciao
 Valter

 in confusione e ti restituisca il tipo di cursore sbagliato....
Valter, avevi ragione: E' sufficiente usare (in presenza di un recordset
certamente non aggiornabile, per esempio testando la presenza di " DISTINCT
" nella query sql) un lock adLockReadOnly per produrre un recordset non
aggiornabile (e va bene), ma scrollabile. Una certa logica c'è, ma non ho
trovato documentazione in tal senso nel labirinto di MSDN. Ho solo trovato
indicazioni che dicono che ADO adegua il tipo di recordset (Static, KeySet,
Dynamic) in funzione delle richieste e delle condizioni, senza comunicare
errori proprio perchè molte cose possono dipendere dal Provider e, quindi,
ogni controllo richiederebbe troppo codice.
Io ti ringrazio (anzi, com'è di moda da Fausto in poi, ti ringrazio, ti
ingrazio, ti ringrazio), ma permettimi di affermare, chiedendo scusa a tutto
il NG, che ADO, anzi M$, fa CAGARE?!
Uso M$ da GWBasic, poi Professional Basic, ora VB (da 3 in poi) e, da
qualche anno, ho adottato una mia regola: Mai usare una nuova cosa se non
c'è almeno il SP3. Credevo che bastasse, credevo che ADO (o forse Mdac_Typ)
2.6, visto il numero, fosse ormai esente. Non è così.
Bill beve sempre di più, ormai come un alcolizzato in astinenza perenne e
costante.
Che (continua) delusione!
Scusa lo sfogo e grazie ancora, Valter. Ora scrivo a M$ e li invito a
frequentare per almeno 3 anni una comunità per alcolizzati.


Aspetta un altro po', se giovedì riesco ad andare a Milano per la
presentazione di 
VB.NET
, non vorrei che sostituissero le graziose
signorine dell'accoglienza ( spero..) .con qualche  mostrilla
dell'esercito della salvezza...
Ciao e buon lavoro
 Valter

 Valter, seguirņ i tuoi consigli, tranne ... l'ultimo, nel senso che ho gią
scritto ad almeno due indirizzi, ma pare che rispondano solo robot.
Una domandina da niente: Non avresti mica la mail primata e diretta di Bill?
Anzi, ora ci apro un post.