Newsgroup: it.comp.lang.visual-basic
Titolo: Problemino con i cursori di ADO 2.6

Chiedo una piccola consulenza al ng (per me grande).
Mi appresto per la prima volta ad usare ADO 2.6 con Provider =
Microsoft.Jet.4.0 (Access 2000)
La modalità della connessione è ReadWrite ed apro il recordset con
CursorType in modalità adOpenDynamic.
ecco il problema:
1) non riesco ad eseguire il recordcount
2) non riesco ad eseguire il metodo recordset.move NumRecDaSpostare,
RecDiPartenza
Da quel che son riuscito a capire da MSDN il provider non supporta i cursori
dinamici, ma si riferisce al M$ Jet 3.5.1 (Access 97 mi sembra)
Qualche suggerimento?
Devo toranre ad usare DAO 3.6?
--------------------------------
Inviato via 
http://usenet.libero.it

 sembra)
che io sappia li supporta solo lato server, i cursori lato client possono essere
solo statici (ma ti serve davvero un cursore dinamico?)
Salutoni
Sergio

 Devo toranre ad usare DAO 3.6?
Non necessariamente (ma, se usi solo Access, è 1000 volte meglio, come
pulizia e velocità)

 pulizia e velocità)
Prima di tutto mi scollego da usenet poichè il mio pc e tornato on line.
Lupo, in effetti io mi ci sono sempre trovato bene, ma potrebbe essere che
in futuro il sistema che sto
sviluppando utilizzi come DB SqlServer 2K. Cosa mi consigli a questo punto?
DAO o ADO?

 solo statici (ma ti serve davvero un cursore dinamico?)
Penso di si dovendo lavorare in ambiente multiutente, altrimenti come si puo
fare?

 per questa passo :-)
Stesso problema di sopra direi...
Ciao

 si puo fare?
uhm... volevo risponderti in modo chiaro, ma mi accorgo di avere anch'io le idee
confuse... facciamo così: questo è un post in progress, comincio a scrivere e
poi vediamo dove vado a finire...
La scelta sul tipo da cursore da aprire è, ovviamente, funzione di quello che
vuoi fare con i tuoi dati, e con quale strumento intendi poi utilizzarli. Ad
esempio, se apri un recordset per visualizzare i dati in una tabella bound, sei
costretto ad utilizzare cursori statici lato client; se metti i dati in una
flexgrid (che non conosco direttamente, ne parlo solo per quanto letto nel ng),
nella quale i dati li devi caricare riga per riga, apri un cursore lato server,
carichi i tuoi dati e poi chiudi il recordset, e in questo caso direi che è
indifferente, se non per quanto riguarda le prestazioni, il tipo di cursore
utilizzato (comunque, in questo caso penso che sarebbe consigliabile quello di
sola lettura a scorrimento in avanti).
Non ho mai avuto occasione di utilizzare recordset dinamici, anche in
applicazioni multiutente, quindi non saprei dirti in quali casi possano essere
utili/indispensabili (se qualcuno lo sa parli :-) ) ma mi pare di ricordare che
la dinamicità dei dati si limiti alle modifiche dei dati, mentre non vede (a
meno di chiusura/apertura o requery o refresh) i nuovi record introdotti (ma
questo lo fanno anche gli altri cursori).
Conscio di aver confuso le carte in tavola più di quanto le abbia chiarite,
accetta i miei soliti
Salutoni
Sergio

 ha scritto nel messaggio
news:b0oi79$rd7qt$1...@ID-173193.news.dfncis.de...

no, no , aspetta un momento:
io sono partito dalla considerazione di aprire un recordset dinamico xchè
non carico i dati in una grid,
ma li carico 1 record alla volta in una maschera di dettaglio, questo
significa che se ho il recordset dinamico li posso scorrere e modificare on
line senza problemi (almeno credevo), una alternativa potrebbe essere quella
di istanziare un recordset ADO di tipo disconnesso, oppure in alternativa
crarmi un type; ma in questo caso dovrei riaprire il recordset magari
puntando alla chiave primaria lockarmi (brutto termine) il record ed
eseguirne l'update, ho colto giusto?
Dimmi se le sto sparando grosse.

 ha scritto nel messaggio
news:212Z141Z48Z42Y1...@usenet.libero.it...


 Dimmi se le sto sparando grosse.
Se posso permettermi un commento, senza che tu ti offenda, mi pare che tu abbia
le idee un po' confuse sull'interfacciamento con i db.. una buona sessione di
studio su qualche sacro testo (consigliabilissimo l'ottimo balena) potrebbe
essere di giovamento :-)
(anche a me, naturalmente)
Salutoni
Sergio

GarbageFile ha scritto:

Allora, decisamente e senza dubbi, ADO. Scriverai (a parte qualche sintassi
nei comandi SQL Server diversa da quella per Access) una volta sola.
Dimentica DAO per SQL Server. Consideralo assolutamente, invece, se
l'applicativo lavorerà _solo_ con Access. E' molto più veloce.
Il tipo di cursore ha poco a che fare (o, quantomeno, non è condizionante)
col fatto che tu debba lavorare in multiutenza.
Il lato server è, rispetto, al lato client, più veloce in quanto il
recordset resta sul server. Con lato client (e questo giustifica la
lentezza) il recordset viene trasferito integralmente sul client. Io uso
solo il primo (e solo con SQL Server) perchè il secondo è semplicemente
penoso, anche adottando le sempre buone regole (ma non sempre applicabili)
di recuperare pochi records. Ovviamente il primo carica il server di
superlavoro e rischia di impallarlo (nel senso che può richiedere
adeguamenti hardware) all'aumentare delle postazioni concorrenti. Il
secondo, trasferendo ogni volta sul client, genera un maggio traffico di
rete (e lentezza), ma le risorse utilizzate sono praticamente solo quelle
del client e quasi per niente quelle del server.
ADO gestisce (se il provider li gestisce, scusa la ripetizione) i cursori
"dinamici" (per esempio Dynamic e KeySet) solo lato server. Per lato client
li converte automaticamente (e senza generare errori) in static.
Cosa significa "dinamico"? In soldoni vuol dire che, in tempo reale (e
considera bene questa cosa, che nulla c'entra col multiterminale, anche se,
ovviamente lo contempla), il cursore vede tutte le modifiche fatte dagli
altri (il keyset, rispetto al dynamic, mi pare che escluda solo le
eliminazioni fatte dagli altri, o le aggiunte, non ricordo). Più facile da
esemplificafre che da spiegare: Immagina che ti sei composto il tuo bel
recordset di un gruppo di clienti, anche ridotto con una "Where". E' di tipo
"dinamico". Lo stai scandagliando per qualsivoglia motivo, dall'inizio alla
fine. Se in quel frattempo un'altra postazione crea un cliente che rientra
in quel contesto, tu te lo ritrovi nel recordset (vedilo come una
manina/puntatore che sta sul server, non vederlo come una collezione di dati
come sarebbe se fosse lato client), oltretutto ordinato in mezzo agli altri
che prima avevi recuperato. (Questo si può simulare anche da una stessa
applicazione, monoutente, con due procedure separate che, appunto, emulano
il multiterminale). Immagina di aver contato all'inizio (anche con Select
Count(*)...) il numero di records del recordset per, sempre ad esempio, per
una barra di progressione o, peggio, di qualcosa di molto più "vitale".
Ecco, col cursore dinamico quel contatore è clamorosamente falso (ecco
perchè il Recordcount è, convenzionalmente, -1) e tu stai lavorando su un
contatore che non è più corretto, è, cioè maggiore o minore. Bada bene anche
questo caso. Se il nuovo record aggiunto va a finire nell'ordinamento giusto
nella posizione di quello che stai trattando, ti troverai una marea di
errori in caso di variazione/aggiunta, ma non sono errori di ADO o del
database, bensì _tuoi_, se non hai tenuto conto di quel che può accadere.
Insomma, quel che per te pare "Rossi Franco" (così era quando ci sei
arrivato sopra) è diventato "Rossa Sergio". capitomihai? "Putenza
eccccezzzzzionale, veramente", ma... attenzione.
In conclusione, se non hai bisogno di vedere in tempo reale (ripeto, lascia
stare la multiutenza, ti basterebbe ricomporre il recordset quando vuoi per
vedere le "novità") usa cursori dinamici, solo lato server. Se vuoi
prestazioni usa solo, sempre lato server, cursore Static. Se vuoi il massimo
della libertà (ma attenzione agli aggiornamenti, perchè è come se ti
mettessi "fuori linea", atnt'è che ci stanno i recordset disconnessi), ma
anche il massimo della lentezza, usa lato client. Tutto verrà trasformato in
static.
Ufffffff ;-)

 Sergio
Saluti.

> Ufffffff ;-)
 Uhee Lupo sei stato molto esauriente, hai dato molto + di quanto mi
aspettavo solo che sono tornato da un pranzo in compagnia un po avvinazzato,
perciň mi riservo di rifletterci domani.
ad ogni buon conto grazie per l'esauriente spiegazione.

 In conclusione, se [>>>CANCELLARE IL "non"<<<] hai bisogno di vedere in


 > In conclusione, se [>>>CANCELLARE IL "non"<<<] hai bisogno di vedere in
Lupo nom mi stai replicando la performance su il thread del campo numerico
null in access!?
Scherzavo ovviamente,
:-)))

 :-)))
Io no, purtroppo. :-(

 del client e quasi per niente quelle del server.
Con un cursore lato server hai continuamente un traffico di rete in quanto
per ogni singola riga che scorri il cursore del server fa una fetch (prova a
vedere con il SQLProfiler)
Con il cursore lato client hai la generazione del traffico una sola volta
senza roundtrip al server.
Sul cliente puoi gerstire  filtri e ordinamenti ed utilizzare per
l'aggiornamento le storedprocedure o i recordsetdisconnessi con updatebatch.
Inoltre  è anche possibile NON utilizzare cursori (firehorse) che rendono
l'applicazione assoultamente scalabile.
Parlando invece di modifiche effettuate da altri utenti, allora devi
utilizzare un cursore lato server.
E' da valutare se conviene fare un refresh dei dati o tenere occupate
risorse del server.
Ad esempio, tramite un semplice UPDATE SQL segnala all'applicazione se nel
frattempo qualcun altro ha modificato i dati che stiamo aggiornando.
Per rendere un'applicazione scalabile è necessario utilizzare il meno
possibile il server.
Ciao.
