Newsgroup: it.comp.appl.access
Titolo: Utenti Access !!!!!



E' lentissimo con 7 utenti................................................


Quanti utenti posso lavorare in contemporanea su un DataBase Access
97.????


 

Premesso che i Client hanno il S.o. Win 95 e lavorano su un  PII
a 64 mb ram..

mentre la base dati e su un server NT con oltre 1 Gb di ram.






io per ora riesco tranquillamente far lavorare 
circa 20 persone contemporanemante


 


Troll


 



 wrote in 
  message 
8isk40$fqq$1...@nslave2.tin.it
...


...


 wrote in message

8isk40$fqq$1...@nslave2.tin.it
...
io
per ora riesco tranquillamente far lavorare circa 20 persone contemporanemante
 
Troll
 







No, il Front-end  da buon conoscitore di Access va installato sul Client,
per esperienza in programmazione, da strutturata ad oggetti ne ho almeno 13
anni, quindi non dipende da quello.
ciao grazie ugualmente.
warp ha scritto:


 wrote in message 
395205C7...@numera.it
...


...


 CIAO, warp
La mia paura è che se passo il tutto sotto SQL server tramite ODBC mi rallenti ancora di più
i tempi di risposta.
Ciao fammi sapere.


Anzitutto la rete dev'essere portata a 100 mb/s, non dovrebbe essere una grossa spesa per un'azienda
con sette postazioni di lavoro.
A 10 (nel tuo caso poco più) Mb/s con gli .mdb cominciano a esserci problemi già a tre/quattro
postazioni di lavoro "cattive".
Devo dire anche che (problema già sollevato numerose volte su questo ng.) condividendo un .mdb su un
PC NT 4.0 le prestazioni si riducono di molto in concorrenza.
In rapporto a ODBC la risposta è ni: è possibile ottenere ottimi risultati a patto di fare
esperienza con numerosi "trucchi" alternativi alle tecniche da manuale.
Purtroppo è necessario riscrivere buona parte del Front-end Access per ottimizzare il Server,
altrimenti... ciccia!
Comunque ti consiglio di provare gli "upzising tools" per Access '97: per cominciare sono ottimi.


 wrote in message 
3951CCA9...@numera.it
...




 

warp ha scritto:

Anzitutto la rete dev'essere portata a 100 mb/s,
non dovrebbe essere una grossa spesa per un'azienda

con sette postazioni di lavoro.A 10 (nel tuo caso poco più)
Mb/s con gli .mdb cominciano a esserci problemi già a tre/quattro
postazioni di lavoro "cattive".

Non sono solo sette le postazioni sono oltre 100,  io parlavo di utenti
collegati alla mia applicazione in contemporanea,

Devo dire anche che (problema già sollevato
numerose volte su questo ng.) condividendo un .mdb su un

PC NT 4.0 le prestazioni si riducono di molto in concorrenza.

Cosa intendi dire condividendo un MDB su un Pc NT 4.0,  Allora, mi
spiego meglio,

Io ho "N" utenti collegati su un server NT (
una bomba, oltre 2 Gbit
di ram
) , ciò vuol dire che nel server c'è la Base Dati
(.MDB)

mentre su i client che hanno come  S.O  Win 95 è installato
il Front-end (.MDE). Ok,

In rapporto a ODBC la risposta è ni: è
possibile ottenere ottimi risultati a patto di fare

esperienza con numerosi "trucchi" alternativi alle tecniche da manuale.

Potresti insegnarmi qualche trucco, te ne sarei grato.

 

Purtroppo è necessario riscrivere buona parte del Front-end
Access per ottimizzare il Server

sai se VB converte il VBA di ACCESS.

Ciao Tore.


Beh, certo far rifare una rete con 100 postazioni di lavoro per farla viaggiare a 100 mb/s non è
cosuccia da poco!!
Confermo quanto ti dicevo su NT 4.0: se provi a  "spostare" il database back-end su un PC win'98 e
rialleghi i vari Front-ends al medesimo, vedrai che le prestazioni in rete miglioreranno
sensibilmente.
Non ho ancora ben capito perchè, ma le cose stanno così.
Cosa intendi dire con "sai se VB converte il codice VBA di Access"?
CIAO, warp


Il server fa solo da fileserver per la tua applicazione oppure che ne so è
un webserver, un server di posta o altro? E' una macchina ben costruita che
so raid via HW, dischi scsi,ecc?
E sulla rete quanto traffico transita?...
Personalmente dopo aver risposto alle domande proverei 2 soluzioni
1 -  Segmentare la rete con degli switch ed eventualmente server dedicato.
Se non si risolve proverei a passare a SQL SERVER o prodotti analoghi ma
molto dipende dal FE.
Ciao Nicola

Sě, in effetti mi sa che la soluzione piů logica sia quella del server dedicato.
Il server SQL (che tra l'altro non viene regalato oltre le 5 postazioni di lavoro), a parer mio
conviene tirarlo in ballo oltre le 10 postazioni di lavoro impegnative.
In ogni caso come dicevo, per avere un'applicazione che sfrutti i server di database č necessario
riscriverla in maniera pesante (e ridebuggarla); a quel punto bisogna valutare se ne valga la pena.
CIAO, warp