Newsgroup: it.comp.appl.access
Titolo: Velocità A97 in rete

Buongiorno.
Ho un'applicazione in A97 che gira su una rete NT4 (con due server e due
domini) di una dozzina di client misti nt4 / w98. Il BE risiede sul server1,
tutto gira con una lentezza notevole; alcune routine pesanti arrivano ad
impiegare decine di minuti. Solo dal server2 (un assemblato P3 1000MHz,
512Mb ram, dischi scasi 10000 rpm,  la velocità è varie volte maggiore, come
se il BE fosse in locale (mentre invece è sull'altro server). Per prova ho
connesso in rete, sullo stesso dominio del server2, un K7 XP 2000+, 512 MB
DDR, disco IDE 60Gb IBM 7200. Mi aspettavo con questo PC di ottenere almeno
la velocità del server2, invece, benchè ci sia un miglioramento rispetto
agli altri client, la velocità resta insoddisfacente. Per dare i numeri,
un'operazione che su un client P3 800 128Ram dura 60", sul server2 ne
impiega 5, sul K7 ne impiega25. L'unica differenza (al di là del processore)
tra il server2 e il K7, sta nella tecnologia scasi del server. Può davvero
essere questa che velocizza Access?
Grazie per l'aiuto
Gianluigi Agostini

 essere questa che velocizza Access?
Se la query va in tablescan certamente si.
Saluti.
Luciano

"Agostini Gianluigi"

In questi casi, se si vuole evitare di riprogettare l'applicazione potrebbe
essere utile riconfigurare la rete con un Terminal Server.
Ciao, Giorgio

 ha scritto nel messaggio
news:al2c22$1m624u$1...@ID-86073.news.dfncis.de...

Ti ringrazio per la risposta, ma non so cosa intendi per *query va il
tablescan*.
Mi puoi chiarire?
Gianluigi Agostini

 Mi puoi chiarire?
Nei DB si usano gli indici per far si che in una eventuale ricerca i record
vengano ritrovati puntando direttamente dove serve. Quando questo non e'
possibile l'unico modo che il motore ha di cercare le occorrenze e' leggersi
tutta la tabella. Questa cosa e' da evitare come la peste bubbonica e l'hiv
messi insieme. E' vero anche che a volte  non esistono altre soluzioni (Es:
SELECT * FROM tabella WHERE campo LIKE '*pippo*', se metti un * all'inizio
l'indice va ovviamente a farsi friggere ma prova a cercare una sottostringa
in altro modo) ed il tablescan te lo sciroppi. In questo caso la velocita'
dell'hd e della cpu diventano fondamentali.
Saluti.
Luciano

 ha scritto nel messaggio
news:al2pok$1mig9f$1...@ID-86073.news.dfncis.de...

Grazie per i chiarimenti.
Il problema è che il software è creato da un'azienda che teoricamente queste
cose le dovrebbe ben sapere e applicare. Si tratta di un software per la
gestione di laboratori chimici, realizzato da un'azienda leader in Italia
nel campo. Siamo passati a una nuova release che doveva garantire migliori
prestazioni della vecchia (che Warp aveva avuto l'occasione di vedere e
criticare: chissà la nuova...); l'azienda fornitrice l'abbiamo messa sulla
graticola, ma lei si difende mostrando i dati che con i nostri BE si
ottengono sulla loro rete, e che noi otteniamo solo dal server2 (maledetto,
questo ci costringe ad ammettere che i risultati sono ottenibili anche in
rete, ma possibile che un k7 2000 512 MB DDR HD IBM 7200 rpm sia mooooooolto
più lento di un P3 1000 (solo perchè scasi), già semplicemente nell'aprire
il db e le maschere, ma anche nel ricollegare le tabelle, etc...?) Non è
un'operazione in particolare ad essere lenta, tutto è moooooolto lento, solo
sul server2 tutto va come se fosse in locale; dovremo dotare tutte le
postazioni di tecnologia scasi? Per dare le misure, il BE è di circa 120 MB,
la tabella principale di circa 100.000 record,  il FE di 25MB, e sulla rete
dell'azienda fornitrice del software (100MBit come la nostra) gira senza
problemi con 10 client.
Grazie per ogni ulteriore consiglio.
Gianluigi Agostini

 problemi con 10 client.
Condivido il consiglio di Giorgio Ferrari: sarebbe meglio _previa nulla osta
dal produttore del software_ prendere in considerazione la rivisitazione
dell'impianto di rete con i Terminal Services di Microsoft che con Win '2000
Server
sono finalmente buoni.
Gira tutto, FE e BE su un unico PC Server (con due belle palle) e attraverso
la rete passa il segnale video delle sessioni aperte.
I vantaggi sono diversi:
. Le prestazioni dell'insieme migliorano molto.
. Diventano altamente improbabili corruzioni o danni sui databases.
. Sul lato client č possibile lavorare con dei catorci.
. La velocitŕ della rete non č determinante _almeno col segnale video
a  256 colori_
. E' possibile lavorare sui programmi in remoto (anche web) con prestazioni
di poco inferiori.
. Si tiene la procedura cosě com'č.
E' la soluzione che ha scelto il tuo "ex concorrente" Barattieri per un
impianto di analoga portata (e un'applicazione diversa ma forse piů
pesante).
Ciao: Silvio

 problemi con 10 client.
IMHO non solo e' tutto ovviamente lento ma siete pure oltre i limiti di
sicurezza di Access. Abbondate con i back up o una mattina potreste
svegliarvi e trovare una brutta sorpresa.
Saluti.
Luciano