Newsgroup: it.comp.lang.visual-basic
Titolo: useclient useserver

Buon Giorno,
qualcuno mi sa spiegare /rimandare a qualche sito per quanto riguarda la
diffirenza nell'uso di useclient/useserver nell'apertura di un recordset?

 diffirenza nell'uso di useclient/useserver nell'apertura di un recordset?
Semplificando molto.
adUseClient=cursore lato client, tutto il recordset verrà interamente
scaricato in locale
adUseServer=cursore lato server, il recordset risiederà sul Server, solo lo
stretto indispensabile verrà scaricato sul client.
Con access anche i cursori lato server saranno ovviamente lato client.

 Con access anche i cursori lato server saranno ovviamente lato client.
Ecco... questa cosa qui l'ho già sentita, e dal punto di vista razionale la
trovo anche sicuramente vera: il motore del database di access deve
risiedere sulla macchina client, anche se il database si trova su un'altra,
quindi è ovvio che il cursore del recordset è comunque "locale" per
l'applicazione.
Una volta chiarito questo, perchè, anche in access, se apro un recordset
"aduseserver", ci metto meno tempo rispetto al "aduseclient" (a parità di
"adOpenStatic", ovviamente)?
Salutoni
Sergio

 ha scritto nel messaggio
news:2Nvla.27383$iy5.7...@twister2.libero.it...


 non  ho nessun errore ma non vedo nessun risultato?
perchč i controlli possono essere "legati" ai recordset solo se questi hanno
un cursore locale, quindi giocoforza anche statico.
Salutoni
Sergio

 perchè i controlli possono essere "legati" ai recordset solo se questi


 e gli associo dei controlli text funziona tutto
Vuoi che te lo dica?
Non lo so, non ho mai usato adodc, se non per qualche prova. Sospetto che
facendo il databinding sul controllo adodc sia lui a "fornire" i dati, al di
là di quale sia il recordset di appoggio.
Salutoni
Sergio

 ha scritto nel messaggio
news:b765i0$bm78d$1...@ID-173193.news.dfncis.de...


 ha scritto nel messaggio
news:b76b3o$bi4a2$1...@ID-61006.news.dfncis.de...


 un ado DATA CONTROL ?
Perchè i controlli tendono a fare più quello che vogliono loro, più che
quello che vuoi tu.
Salutoni
Sergio

 tutto il db in locale pure se lo apri da un path di rete ...
Io a questa ultima cosa, letta letteralmente, non ci credo, nemmeno se lo
vedo scritto sui documenti ufficiali!
Nè con DAO, nè con ADO. Se ogni volta che accedo a un database Access o ne
apro un recordset, mi si spostassero 40/50 Mb di roba (pari alla dimensione
fisica del database) me ne accorgerei, che ne dite?
Io credo che il motore locale (perchè Access, anzi, Jet, non è
client/server) scarichi quanto gli serve, ma non necessariamente il database
e nemmeno l'intero contenuto del recordset. Abbiate pazienza, ma che senso
avrebbe scaricare più del necessario? Nemmeno ADO lo fa se non glielo dici.
Hanno inventato il lato client per giustificare (sì, perchè molte cose che
non si hanno col lato server non sono affatto giustificabili!) i recordset
disconnessi che, per loro natura, da qualche parte devono stare, sul client
appunto, congelati com'erano quando sono stati recuperati.
Insomma un cursore client costringe a scaricare l'intero recordset in
locale, mentre con cursore lato server non scarica un bel niente, se non il
puntatore (o l'insieme dei puntatori) al record/recordset fisico, anche con
Access. La differenza si vede, ovviamente a favore del lato server.
Il dynamic (sempre lato server, perchè con lato client tutto viene
trasformato in static) è il cursore più veloce in assoluto (ma ... non
sempre, dipende anche da come sono strutturati gli indici e anche,
giustamente, il più "ballerino", nel vero senso della parola) perchè,
proprio perchè deve mostrare tutto ciò che avviene, anche da parte di altri
utenti concorrenti, non può, nè deve, "localizzare/congelare" niente,
nemmeno il set dei puntatori, ma solo il puntatore al record corrente, che
balla come un'awaiana in calore.
Io l'ho capita così e i fatti mi cosano.
Non sono nemmeno convinto che il "cursore" di DAO per Access assomigli al
lato client. Per quanto mi riguarda, in relazione alle prestazioni, mi
sembra più simile al lato server.
Io oltre a questo non riesco ad andare: qualunque sia il cursore, anche con
un motore c/s, non riesco a immaginare altro che una continua comunicazione
fra client e "server" (inteso come macchina che ospita il db fisico), anche
per spostare il puntatore al record seguente, non fosse altro per
individuare (e restituirla, ma solo quella) la parte di file (o la struttura
architettata, ma sempre di bytes si parla) che contiene il record corrente,
come potrei averlo sul client, altrimenti?
Il vantaggio di traffico di rete con un motore c/s si può avere quando si
lancia un comando SQL "cumulativo": Al server si comunica il comando, il suo
motore lo esegue, là, senza impegnare la rete se non per restituire
eventuali risultati. Con Access, che c/s non è, lo stesso comando verrà
presumibilmente "scomposto" dal motore che risiede _anche_ sul client in
tanti comandi "unitari" (per semplicità: record per record) e questo genera
traffico.
Infine, dopo la serie immensa di castronerie, non posso astenermi da una
grande verità (la solita, forse l'unica): perchè qualsiasi cosa (per un
numero ridotto di utenti concorrenti) è più veloce con DAO+Access di
qualsiasi altra con ADO e motore c/s o non c/s?
Ho fatto una prova (vabbè, con due applicazioni distinte sulla stessa
macchina, ma son convinto che darà gli stessi risultati se lo faccio con due
postazioni concorrenti):
Applicazione 1:
Apro con DAO+Access un recordset di due records e mi porto
sul primo record.
Mi fermo con uno Stop o un F9.
Applicazione 2:
Da un'altra postazione faccio la stessa identica cosa e mi porto sul
secondo record.
Lo modifico il secondo record e lo scrivo. Non chiudo nemmeno.
Applicazione 1:
Continuo da dove mi ero fermato (senza riaprire il recordset) e vado sul
secondo record.
Cosa leggerò? I dati vecchi o quelli nuovi?
Leggo i nuovi.
Ipotizzando, come penso, che gli stessi risultati si ottengano con due
postazioni che concorrono a un "server" che ospita fisicamente il database,
siamo tutti d'accordo che "il database NON è stato trasportato in locale"? e
nemmeno il recordset con i suoi dati o, quantomeno, che lo spostamento
provoca una rilettura del record fisico, ma solo di quello?
No? Prooooova!

fisica del database) me ne accorgerei, che ne dite?
Non ti porti dietro _tutto_ il db, ma solo le tabelle coinvolte nella
select.
Provo a spiegarmi:
SELECT campo1, campo2, campo3
FROM tabDati
WHERE campo1 >= 100
fa si' che ti scarichi tutta la tabella tabDati in locale, quindi
applichi il filtro: e' l'esatto contrario di quanto avviene con un db
client-server. Infatti, mentre le Seek e i Find con Access sono
accettabili, se usati con SqlServer o Oracle in db di generose
dimensioni sono semplicemente disastrose.
Access e' semplicemente un file di dati, manipolabile tramite librerie
installate sul client, cosi' come lo erano i dbf, ad esempio.
-- 
ciao, hal

e gli associo dei controlli text funziona tutto
Il cursore lato server non permette recordset disconnessi (quindi non
chiude mai la connessione) e non porta sul client _tutti_ i record
estratti con la SELECT: ecco perche' per combo, list e griglie e'
necessario un cursore client-side, mentre per valorizzare le textbox
in un record va bene anche il cursore server-side.
Il cursore lato client in realta' e' una cache locale (quindi si
consumano risorse di memoria sul client) che viene caricata da da un
cursore forward-only e read-only.
Il metodo Sort del recordset, per esempio, e' applicabile solo su
cursori lato client, mentre non funziona se si apre lato server.
Peraltro, se dall'altra parte c'e' un db come si deve, conviene
piuttosto rifare la query impostando il nuovo ORDER BY, che il
guadagno in performance e' assicurato.
-- 
ciao, hal

 fa si' che ti scarichi tutta la tabella tabDati in locale
No, non credo nemmeno a questo.
Se la mia tabella piů grossa, per esempio i movimenti di magazzino, venisse
trasferita integralmente, me ne accorgerei, eccome. Lo escludo. Non ho
prove, ma lo escludo!

 prove, ma lo escludo!
lupo, per prova dal lap tempo fa ho lanciato una query tipo select *
sull'mdb del desktop, via hub.
la tabella aveva 4.5 mln di righe.
l'hub stava per fondere, e il prg e' esploso...

prove, ma lo escludo!
Lupo, pensaci bene: 
D_1. quale processo gira sul pc dove si trova l'mdb condiviso per
mandarti i dati?
R_1. Nessuno.
D_2. se e' vera la 1, dove gira il processo che seleziona i dati?
R_2. Sul client.
D_3. come fa il processo sul client a selezionare i dati?
R_3. scorre tutti i record per riconoscere quelli che soddisfano i
criteri di selezione.
D_4. come fa il processo sul client a scorrere tutti i record?
R_4. si porta in locale _tutta_ la tabella.
Non c'e' via di scampo...
...quasi quasi mi faccio uno shampoo ;-)
-- 
ciao, hal

 ...quasi quasi mi faccio uno shampoo ;-)
Le obiezioni sono piů che lecite, senza ironia.
Le risposte, secondo me, IMHO, a mia capocchia, non mi sfagiolano, troppe
certezze, allora:
Perchč ADO (ho detto ADO) lato Client č imparagonabilmente piů lento di DAO
lato niente?
No, non ditemi che č il metodo di trasferimento degli _stessi_ dati che č
piů lento...

più lento...
E invece te lo dico lo stesso ;-)
ADO, in quanto indipendente dal database, mette, tra il client e il db
Access uno strato in piu'.
D'altra parte, hai mai provato ad usare DAO con un db diverso da
Access? Una vera schifezza :-(
-- 
ciao, hal