Newsgroup: it.comp.appl.access
Titolo: gestionale in  multiutenza

Ciao a tutti. Ho un consiglio da chiedervi prima di mettere le mani approfonditamente su un db già in uso......
Da monoutente deve diventare multiutente (3 max 4 accessi, di cui 2 fortemente concorrenti)
Io ho provato in questa maniera:
Access 2003 e win XP
Imposto strumenti-opzioni-avanzate con 'blocco record predefinito=record modificati' e 'apri database utilizzando blocco a livello di record'
2 casi:modifica contemporanea (stesso record) ed inserimento contemporaneo (stesso Id). 
 
Caso1: modifica. 
Sottocaso 1= form associata (basata su query SQL). Apro con lock pessimistico e lascio fare al motore del db. Sembra ok...
Sottocaso 2= form non associata (i dati sono presi dalla form precedente che è in sola visualizzazione). l'UPDATE viene fatto in un sol colpo alla pressione di un bottone. Ho utilizzato le clausole dbFailOnError+dbSeeChanges e gestisco l'errore (3218) che riportano in caso di modifica contemporanea. Devo aggiungere il controllo anche del 3260/3187/3046/3186/3139. Sembra ok.....
Caso2: inserimento
Calcolo il Max id con un recordset e poi TENTO l'inserimento. Se errore chiave duplicata (errore 3022) lo intercetto annullo tutto.
 
In teoria, lascio fare a jet tutto il lavoro....gestisco solo quello che mi rimanda indietro......
Consigli? Nomacci? Errori? Sono aperto ad ogni commento.....
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it


Cientopecciento al caso due
Dal mio punto di vista bloccare il db e' sbagliato, molto meglio 'leggerne' 
le reazioni ed agire di conseguenza
Ciao
RobertoA 

RobertoA ha scritto:

Grazie per il parere. Una sola precisazione: il caso2 riguarda gli inserimenti. Il caso1 la modifica dello stesso record. Tu come la gestiresti se non con i lock da Access? Se non imposto i lock non riesco a generare errori runtime......


 generare errori runtime......
Come non ottieni nessun errore ?
L'errore dovresti ottenerlo se tenti di violare gli indici o i vincoli 
imposti sul db, comunque, indipendentemente dal tipo di apertura del db
Oppure se stai up-datando un record gia' modificato da altri, o se tenti di 
eliminare un record che gia' altri hanno eliminato
Non capisco cosa intendi dire con ".. Se non imposto i lock non riesco a 
generare errori runtime.."
Ad ogni modo, il fatto che tu debba usare un archivio in concorrenza con 
altre postazioni dovrebbe gia' importi di abbandonare i file mdb per un 
sistema piu' veloce e soprattutto affidabile, tipo Sql Server o qualsiasi 
altro db server
Io ti consiglio Firebird o Postgresql, sono eccezionali come funzionalita' e 
pure aggratisse, tanto per dirne una puoi eseguire il backup completo del db 
durante la normale attivita', senza stoppare gli utenti dal loro lavoro, 
oppure puoi impostare dei triger per loggarti le modifiche al db per vedere 
chi ha fatto che cosa e da che postazione, senza una riga di codice 
sull'applicativo
Ciao
RobertoA

RobertoA ha scritto:

In effetti ho l'upgrade a SQL Server in corso.....da mesi oramai.....volevo solo cercare di capire bene come agisce jet 'sotto' con le concorrenze....c'č letteratura in merito a db con svariati accessi contemporanei. Per ora l'applicativo funziona a dovere e nn da noie, ma, + per me che per altro, mi andava l'idea di renderlo + 'professionale', sviscerando quelle parti che magari possono dare problemi in futuro xchč mal sviluppate (da me chiaramente.... :-( ). Va da se che file sharing e client-server sono 2 cose diverse.....
Intanto grazie
