Discussione:
Accesso concorrente
(troppo vecchio per rispondere)
orsomannaro
2012-07-04 08:25:16 UTC
Permalink
Qualche hanno fa ho realizzato un'applicazione con Acess2000. Questa
applicazione e' composta da front-end (contenente forms, queries, ...)
+ back-end (contenente le tabelle).

Oggi al back-end (situato in una cartella condivisa della rete) si
collegano piu' front-end (tre utenti contemporanei) e questo crea
notevoli rallentamenti quando due utenti cercano di aprire la stessa
maschera.

Sapete dirmi se ci sono delle impostazioni che posso modificare o
comunque delle migliorie che posso apportare per risolvere questo
problema?


Grazie.
Stefano
2012-07-04 08:36:30 UTC
Permalink
Post by orsomannaro
Qualche hanno fa ho realizzato un'applicazione con Acess2000. Questa
applicazione e' composta da front-end (contenente forms, queries, ...)
+ back-end (contenente le tabelle).
Oggi al back-end (situato in una cartella condivisa della rete) si
collegano piu' front-end (tre utenti contemporanei) e questo crea
notevoli rallentamenti quando due utenti cercano di aprire la stessa
maschera.
Sapete dirmi se ci sono delle impostazioni che posso modificare o
comunque delle migliorie che posso apportare per risolvere questo
problema?
Grazie.
Se non ho capito male, tutti i clients, accedono alla rete ed eseguono
lo stesso BE (es. tutti eseguono il file f:\lavoro\be.mdb)
Se è così, crea una cartella locale su ogni client e copia li il FE.
Dovrebbe velocizzare il lavoro in quanto ognuno apre il proprio mdb e
utilizza solo le tabelle collegate.

Io ho un'applicazione per le non conformità utilizzata
contemporaneamente da 10 utenti e vi è un rallentamento praticamente
inesistente.

Ciao.

Stefano
Karl Donaubauer
2012-07-04 16:38:38 UTC
Permalink
Post by Stefano
Post by orsomannaro
Qualche hanno fa ho realizzato un'applicazione con Acess2000. Questa
applicazione e' composta da front-end (contenente forms, queries,
...) + back-end (contenente le tabelle).
Oggi al back-end (situato in una cartella condivisa della rete) si
collegano piu' front-end (tre utenti contemporanei) e questo crea
notevoli rallentamenti quando due utenti cercano di aprire la stessa
maschera.
Sapete dirmi se ci sono delle impostazioni che posso modificare o
comunque delle migliorie che posso apportare per risolvere questo
problema?
...
Se non ho capito male, tutti i clients, accedono alla rete ed eseguono
lo stesso BE (es. tutti eseguono il file f:\lavoro\be.mdb)
Solo per chiarirlo per l'OP: Certo non intendi "BE" qui ma "FE".
Post by Stefano
Se è così, crea una cartella locale su ogni client e copia li il FE.
Dovrebbe velocizzare il lavoro in quanto ognuno apre il proprio mdb e
utilizza solo le tabelle collegate.
Io ho un'applicazione per le non conformità utilizzata
contemporaneamente da 10 utenti e vi è un rallentamento praticamente
inesistente.
--
Ciao
Karl
*********
Access FAQ: www.donkarl.com/it
o***@gmail.com
2012-07-04 20:21:25 UTC
Permalink
Post by Karl Donaubauer
Post by Stefano
Se non ho capito male, tutti i clients, accedono alla rete ed eseguono
lo stesso BE (es. tutti eseguono il file f:\lavoro\be.mdb)
Solo per chiarirlo per l'OP: Certo non intendi "BE" qui ma "FE".
Tutti gli utenti eseguono il FE le cui tabelle sono collegare al BE che si trova in una cartella di rete condivisa.


Avevo valutato la migrazione da jet a un db server tipo postgres/mysql ma la cosa non sembra cosi' immediata, anzi...
Karl Donaubauer
2012-07-04 20:46:03 UTC
Permalink
Post by o***@gmail.com
Post by Karl Donaubauer
Post by Stefano
Se non ho capito male, tutti i clients, accedono alla rete ed
eseguono lo stesso BE (es. tutti eseguono il file f:\lavoro\be.mdb)
Solo per chiarirlo per l'OP: Certo non intendi "BE" qui ma "FE".
Tutti gli utenti eseguono il FE le cui tabelle sono collegare al BE
che si trova in una cartella di rete condivisa.
Avevo valutato la migrazione da jet a un db server tipo
postgres/mysql ma la cosa non sembra cosi' immediata, anzi...
Il problema che hai descritto non sembra un problema del backend
ma dell'uso dello stesso singolo frontend. Hai capito la dritta di Stefano
di dare ad ogni utente il suo proprio frontend per evitare il problema?

Vedi anche: http://www.donkarl.com/it?FAQ1.35
--
Ciao
Karl
*********
Access FAQ: www.donkarl.com/it
o***@gmail.com
2012-07-05 14:12:19 UTC
Permalink
Post by Karl Donaubauer
Il problema che hai descritto non sembra un problema del backend
ma dell'uso dello stesso singolo frontend. Hai capito la dritta di Stefano
di dare ad ogni utente il suo proprio frontend per evitare il problema?
Ogni utente ha la propria copia del FE salvata sul proprio PC.



A mio pare il problema potrebbe essere dovuto all'accesso esclusivo ai record.
o***@gmail.com
2012-07-20 08:13:59 UTC
Permalink
Sul Opzioni > Avanzate ho la spunta su:

Apri database utilizzando blocco a livello record


puo' essere questa impostazione a causare quella lentezza in apertura dell maschere?


un'altra cosa che ho notato è che la maschera che sembra essere la più lenta tra tutte ad aprirsi, non è collegata a una tabella ma genero da codire l'sql del recordset: può darsi che sbagli qualcosa nella generazione di RecordSource?
RobertoA
2012-07-04 09:10:17 UTC
Permalink
Post by orsomannaro
Qualche hanno fa ho realizzato un'applicazione con Acess2000. Questa
applicazione e' composta da front-end (contenente forms, queries, ...)
+ back-end (contenente le tabelle).
Oggi al back-end (situato in una cartella condivisa della rete) si
collegano piu' front-end (tre utenti contemporanei) e questo crea
notevoli rallentamenti quando due utenti cercano di aprire la stessa
maschera.
Sapete dirmi se ci sono delle impostazioni che posso modificare o
comunque delle migliorie che posso apportare per risolvere questo
problema?
Grazie.
Per rendere piu' sicura la memorizzazione dati ti consiglio di tenerli su un
database server
Che sia Microsoft, Ibm, Oracle, Pervasive o altri poco importa
Personalmente ti consiglio Postgresql o Firebird
Franchi Graziano & Famiglia
2012-07-09 05:11:30 UTC
Permalink
Problema di access 2000 risolto dopo chiamata a microsoft:

A tutti gli .mdb devi:
strumenti->opzioni->generale

TOGLIERE SPUNTA tieni traccia delle informazioni di correzione

Io uso ACCESS 2000 e da quando ho tolto la spunta va BENISSIMO
Ciao
Graziano
o***@gmail.com
2012-07-09 07:07:19 UTC
Permalink
Post by Franchi Graziano & Famiglia
TOGLIERE SPUNTA tieni traccia delle informazioni di correzione
Grazie della dritta Graziano, ma anche cosi' non ottengo miglioramenti (quando tento di aprire una maschera gia' aperta da un altro utente i tempi di attesa sono enormi).


Grazie comunque.
o***@gmail.com
2012-07-10 13:10:21 UTC
Permalink
A nessuno viene in mente cosa possa essere??
Stefano C
2012-07-10 15:23:26 UTC
Permalink
A mio parere, è molto difficile diagnosticare senza avere sottomano il
codice. Sicuramente l'accesso esclusivo può essere causa del
comportamento che descrivi.

Per quanto mi riguarda, per applicazioni FE/BE, con BE sia .mdb che
server, utilizzo un approccio disconnesso. E' inizialmente più oneroso
da implementare, ma strapaga in termini di efficienza.

Ciao.
Post by o***@gmail.com
A nessuno viene in mente cosa possa essere??
RobertoA
2012-07-10 17:12:27 UTC
Permalink
Post by Stefano C
A mio parere, è molto difficile diagnosticare senza avere sottomano il
codice. Sicuramente l'accesso esclusivo può essere causa del comportamento
che descrivi.
Per quanto mi riguarda, per applicazioni FE/BE, con BE sia .mdb che
server, utilizzo un approccio disconnesso. E' inizialmente più oneroso da
implementare, ma strapaga in termini di efficienza.
Ciao.
Per 'accesso disconnesso' io intenderei che apri una connessione, leggi
qualcosa, chiudi la connessione e continui a lavorare sui dati letti, nel
caso li modifichi dovrai riconnetterti al db ed aggiornarli
Come fai a farlo con Access ?
Credo che Access abbia bisogno di avere sempre sotto le proprie grinfie i
dati, sia che siano su un mdb o su db server
Oppure ho capito male io cosa intendi per 'accesso disconnesso'
Ciao
RobertoA
Stefano C
2012-07-10 18:05:03 UTC
Permalink
Ciao Roberto,

sì intendi bene, con la precisazione che non è necessario in ogni caso
chiudere ogni volta la connessione: aprire/chiudere ha un costo
computazionale; se hai pochi (qualche decina) di utenti puoi di solito
tenere tranquillamente aperte le connessioni. Disconnesso si riferisce
più che altro al fatto che, come hai scritto, recuperi uno o più
records, elabori e trasmetti le variazioni.

Per fare questo esistono gli oggetti ADODB.Connection, e DAO.Workspace e
DAO.Database. Sia con ADO che con DAO è possibile controllare
commit/rollback delle transazioni.

E' una storia un po' lunga, in effetti. Ma illuminante: fa capire fra
l'altro perché gli .adp sono assolutamente da evitare, assolutamente, se
non in casi dove sia consentito "buttare lì" una soluzione client-server
di cortissimo respiro. Se vuoi parlarne (non mi sembra il caso di
appesantire il thread) puoi contattarmi all'indirizzo stefano dot
costa74 at virgilio dot it

So che qualcuno si scandalizzerà, ma se usato bene, con qualche funzione
"wrapper" universale, e cioè riutilizzabile in aeternum, ADO non fa
sentire tanta nostalgia di ADO.net...

Ciao!
Post by RobertoA
Post by Stefano C
A mio parere, è molto difficile diagnosticare senza avere sottomano il
codice. Sicuramente l'accesso esclusivo può essere causa del comportamento
che descrivi.
Per quanto mi riguarda, per applicazioni FE/BE, con BE sia .mdb che
server, utilizzo un approccio disconnesso. E' inizialmente più oneroso da
implementare, ma strapaga in termini di efficienza.
Ciao.
Per 'accesso disconnesso' io intenderei che apri una connessione, leggi
qualcosa, chiudi la connessione e continui a lavorare sui dati letti, nel
caso li modifichi dovrai riconnetterti al db ed aggiornarli
Come fai a farlo con Access ?
Credo che Access abbia bisogno di avere sempre sotto le proprie grinfie i
dati, sia che siano su un mdb o su db server
Oppure ho capito male io cosa intendi per 'accesso disconnesso'
Ciao
RobertoA
o***@gmail.com
2012-07-12 09:48:42 UTC
Permalink
Post by Stefano C
Per fare questo esistono gli oggetti ADODB.Connection, e DAO.Workspace e
DAO.Database. Sia con ADO che con DAO è possibile controllare
commit/rollback delle transazioni.
Temo che il punto sia questo.
Quando apri un recordset in modfica Access (se non erro) lo mette in lock.
Sospetto che il problema sia dovuto al fatto che se una maschera e' basata sulla tabella tProdotti allora quando il primo utente la apre mette tutta la tabella in lock e quindi il secondo utente deve aspettare che il primo chiudi la maschera per poterla aprire lui...
Solo che se le cose stanno cosi' l'unica alternativa e' rimettere mano a tutto...
Stefano C
2012-07-12 17:02:58 UTC
Permalink
Eh... dovresti vedere la proprietà .LockType del recordset... tutta la
tabella no, ma le bound forms sono delle bestie strane...

Hai provato ad eseguire un compatta & ripristina sul BE?
Post by o***@gmail.com
Post by Stefano C
Per fare questo esistono gli oggetti ADODB.Connection, e DAO.Workspace e
DAO.Database. Sia con ADO che con DAO è possibile controllare
commit/rollback delle transazioni.
Temo che il punto sia questo.
Quando apri un recordset in modfica Access (se non erro) lo mette in lock.
Sospetto che il problema sia dovuto al fatto che se una maschera e' basata sulla tabella tProdotti allora quando il primo utente la apre mette tutta la tabella in lock e quindi il secondo utente deve aspettare che il primo chiudi la maschera per poterla aprire lui...
Solo che se le cose stanno cosi' l'unica alternativa e' rimettere mano a tutto...
o***@gmail.com
2012-07-13 05:49:07 UTC
Permalink
Hai provato ad eseguire un compatta & ripristina sul BE?
Ogni volta che faccio il backup del db... :)
o***@gmail.com
2012-08-01 06:59:50 UTC
Permalink
Trovato: dovevo togliere il segno di spunta da:

Strumenti > Opzioni > Generale > Tieni traccia delle informazioni di correzione

ovviamente in tutti i FE (e qui mi ero sbagliato quando per la prima volta ho testato questa soluzione)
Continua a leggere su narkive:
Loading...