Newsgroup: it.comp.appl.access
Titolo: Utilizzo simultaneo Tabelle Collegate

Ciao a Tutti
 
Ho un database aziendale di cui una parte delle tabelle sono collegate ad un db in rete.
 
Ad ogni avvio del programma ogni utente si scarica in locale l'applicativo e crea i collegamenti con le tabelle in rete.
 
Se un utente modifica un record su una tabella collegata, l'altro utente vede in real time la modifica?
Come si può gestire la simultanea modifica dello stesso record tra utenti diversi che utilizzano le stesse tabelle collegate?
Grazie

Non ho ben capito la questione dello scarico in locale... normalmente si distribuisce un client cheblinka le tabelle e poi parte...
In ogni caso la risposta alla tua domanda non è banale.
Se hai aperto una maschera basata su una tabella che può essere editata in MultiUtenza la risposta non solo è NO finché non ricarichi l'origine dati ma si devono considerare tutti gli aspetti di accesso concorrente...
Il problema non è solo che se crei il nuovo record gli altri potrebbero non vederlo subito ma soprattutto che se 2 o più vogliono modificare il medesimo record...ne esce un pasticcio... solo l'ultimo salva.
Per questo si gestisce la modalità di scrittura pessimistica...in quanto la modalità ottimistica tende a creare problemi.
Ci sono poi problematiche legate alle PK in caso di transazioni annidato con relazioni 1-m da dover gestire...
Insomma l'utilizzo in multiutenza è impegnativo e richiede qualche esperienza in più 
Ciao
@Alex


Riprendo la risposta d Alex in quanto è corretta e personalmente ho combattuto almeno 1 settimana per venirne a capo di questo problema.
In internet troverai che sulla carta si può fare di tutto con tabelle collegate da Access su SQL Server e modifiche concorrenti, in realtà i meccanismi non funzionano bene oppure non funzionano del tutto.
Ne sono uscito con un mix di tecniche:
- lato SQL-Server crea SEMPRE una colonna in piu chiamata TS di tipo Timestamp, anche se non la metti come chiave non ha importanza, e puoi impostare comunque la tua colonna chiave di tabella (es.ID, Cod, ecc.); questa colonna è fondamentale per far capire ad SQL Server come identificare precisamente il record oggetto di modifiche;
- detto questo, i meccanismi di Access per il blocco record esclusivo in modifica non funzionano; inoltre in questo scenario di modifiche concorrenti, non funzionerà neanche la condivisione del file Access tra piu utenti;
- quindi la concorrenza l'ho risolta installando lo stesso client Access nei rispettivi PC degli utenti; ciascuno ha il suo file access client, con le proprie tabelle locali e collegate, inoltre le modifiche concorrenti ad un campo di tabella collegata diventano possibili grazie al suddetto timestamp gestito da SQL Server;
- infine, siccome personalmente volevo controllare finemente chi può modificare un record, ho implementato un sistema di utenti, permessi e lock sui record, cioè, al login dell'utente vengono letti il codice utente e i permessi read/write della maschera o del singolo campo; con un pulsante "Modifica" viene controllato il permesso di modifica dati, viene controllato se la riga è in "Lock" da un altro utente, e quindi viene aperta una finestra non associata (o associata a una copia locale "TabellaTmp" della tabella su SQL Server) in cui vengono caricati i dati del record per essere modificati, infine la riga viene messa in Lock dall'utente; alla chiusura della finestra temporanea (dove i dati sono stati modificati) avviene lo scarico verso SQL Server dei dati aggiornati (una banale query di UPDATE) e il rilascio del Lock.
 
 
 
 
 
 
 
 


Comunque IMHO non serve aprire una finestra separata quando si pone il lock su false. 
E a mio parere per impostare il lock hai due possibilità:
1) aggiungere ad ogni tabella un campo lock che valorizzi 0 di default (lock true)
Quando un utente vuole fare modifiche il valore lo imposti con l'id utente. 
e quando le modifiche sono state salvate lo fai tornare a 0.
2) crei una tabella nuova lock con dei campi idTabella, idUtente, idRecord, TS
Quando un utente vuole fare modifiche aggiungi un record
e quando le modifiche sono state salvate valorizzi il campo TS di tipo timestamp, 
così hai anche una cronologia delle modifiche.
A me il secondo metodo piace molto di più.
In entrambi i casi prima di entrare in modalità modifica si deve controllare che il campo sia = 0 
o che non ci sia un record nella tabella lock
 
Che ne pensate?