Newsgroup: it.comp.appl.access
Titolo: ADP: enigma prestazionale

ADP formato 2000 (eseguito perň da A 'XP)
SQL Server 7.0 installato sul Server.
Da un client accedo attraverso maschera continua a 10.000 records di una
tabella sul Server.
L'origine dati della maschera suddetta č una tabella, non una vista o SP.
Ora, se imposto attraverso i menů di scelta rapida di Access un criterio
d'ordinamento su un qualunque campo a video (anche indicizzato) le
prestazioni decadono drasticamente.
A parte l'operazione di riordino piuttosto lenta, le performances di
gestione della form diventano inaccettabili al termine del processo.
In una situazione analoga si comportano benissimo delle banali tabelle ODBC
collegate al Server.
Cosa sbaglio o mi sfugge?
Saluti: Cristiano.


Ciao Cristiano
E se fossere 1.000.000 di record ?
A mio parere una maschera che ha come origine record tabelle di grosse
dimensioni dovrebbe farlo accedendovi con un record alla volta (cosa
fattibile creando dei bottoni di navigazione record personalizzati) e
generare interrogazioni diverse al server per quanto riguarda l'ordinamento
e la ricerca.
I Driver ODBC sono un'ottimo strumento di traduzione tra Jet di access e la
fonte di dati esterna, e di fatto l'applicazione utilizza Jet.
Proprio per questo non ha la possibilità di vedere o interpretare molti
oggetti del server  (funzioni, stored procedure, viste) e soprattutto non
interpreta i messaggi di errore e si limita a dire "ODBC chiamata non
riuscita."
In breve io ho eliminato i bottoncini di filtro e ordinamento automatico in
maschere di questo tipo, bottoncini che per loro natura sono più appropriati
in un foglio elettronico che in un database.
Ciao Giorgio

 in un foglio elettronico che in un database.
Tuttavia resta la stranezza che ho "denunciato": non mi spiego come una form
continua .ADP possa avere problemi di prestazioni che non riscontro con
connessioni ODBC o perfino JET con pochi clients connessi al server.
Può essere legato alla configurazione un pochino bizzarra su cui ho fatto il
test, o risulta pure a te?
Cristiano

 ha scritto nel messaggio
news:FoRSa.192359$Ny5.5...@twister2.libero.it...

Ciao Cristiano
Se faccio la prova su una maschera continua che attinge a tutti quei record
oltre ad accusare una riduzione di prestazioni mi va in Out of Memory Access
(ho 384Mb di memoria non sono tanti ma neanche pochi)
Forse puoi provare ad aprire un recordset con cursore lato client e
assegnarlo al Form, ma ti tocca aspettare il caricamento di tutti i record.
Per quanto riguarda l'interfaccia ti assicuro che il cliente non nota molta
differenza tra i due metodi. Nelle applicazioni sviluppate con Jet
utilizzavo quelle funzionalità ;-)
Ciao Giorgio.

 utilizzavo quelle funzionalità ;-)
Purtroppo di clienti ne ho decine (non lavoro da solo) abituati a lavorare
in maniera molto diversa: e francamente li capisco.
Ti saluto.

 ha scritto nel messaggio
news:UWTSa.192383$lK4.5...@twister1.libero.it...

forse sono fuori tema, ma io ho notato questo in un database fatto da me in
sql con 3 milioni di record e alla richiesta di ogni client ne restituisce
perche filtrati in origine (Create wiew) circa 300.000 alla volta , client
Access adp - mde , se faccio lavorare più di 10 client  che leggono e scrivo
contemporanemanete nel database, da errore ODBC chiamata non valida, ecc
ecc, Server con 1 GB ram  mono processore P IV  win 2k server controlle r
dominio , (con server bi processore il problema non si pone)
Ciao Carlo

 ha scritto nel messaggio
news:jZfTa.2177$Df5....@news1.tin.it...

Ciao Carlo
Penso che sia un problema di time out, potresti provare ad allungarne il
tempo modificando (nei clients) il valore nel registro di windows alla
chiave
HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines\ODBC
QyeryTimeout
o se hai Jet 3.5
HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\3.5\Engines\ODBC
QyeryTimeout
Ciao Giorgio.