Swalke ha scritto:x Archimede: il dbms è access... ...comunque non ci stiamo intendendo... ...credo che tu non abbia capito bene di cosa parlo... ...o forse io non mi sono spiegato bene.
Se la stringa SQL invece di essere quella che mi hai dato tu è:
INSERT INTO Dipendenti (Cognome) VALUES (<nuovo cognome>) WHERE ID = MAX ID
(...scusa se la sintassi non è corretta ma quello che conta è il succo)
...se questa stringa viene lanciata da due utenti contemporaneamente, lo scheduler del server potrebbe mandare in esecuzione i due processi di update come segue (smembramento della queri in istruzioni di basso livello ipotetiche):
A: seleziona max id (valore estratto = 5) e lo mette in memoria allocata per A
B: seleziona max id (valore estratto = 5) e lo mette in memoria allocata per B
A: scrive cognome dove id=5
B: scrive cognome dove id=5 (e sovrascrive i dati di A)
A: max_id++ (max id diventa 6) nella memoria allocata ad A
A: scrive 6 nella memoria condivisa che contiene il valore di max ID
B: max_id++ (max id resta 6) nella memoria allocata a B
B: scrive 6 nella memoria condivisa che contiene il valore di max ID
...e così perdi i dati di A che vengono sovrascritti da b.
Forse parliamo di due cose diverse: io dei problemi che ci sono nella
modifica (UPDATE) di un
record esistente, tu forse stai parlando dell'
inserimento (INSERT) di un
nuovo record. D'altra parte INSERT non supporta la clausola WHERE per cui faccio fatica a seguirti. Ancora una volta, non so cosa sia la
memoria condivisa (un dato nel db, una variabile Application(), ...?) e comunque non mi pare riguardi direttamente il problema (locking sul db e concorrenza in ambito Internet/multiutente).
Di cosa parlo io? Degli update persi. Scenario:
T0: l'utente A seleziona i dati del record 1 ed inizia a modificarli
T1: l'utente B seleziona i dati del record 1 (vede le stesse informazioni che A vedeva
inizialmente) ed inizia a modificarli
T2: l'utente A invia le proprie modifiche (che vengono correttamente registrate)
T3: l'utente A verifica che le proprie modifiche siano state correttamente registrate e va a casa
T4: l'utente B invia le proprie modifiche (che vengono correttamente registrate)
Se in T4 non c'è nessun controllo che i dati del record sono cambiati
dopo T1 l'utente A avrà di che lamentersi.
Per risolvere tale problema (che, come vedi, non implica necessariamente che le operazioni avvengano esattamente nello stesso momento) devi usare un tipo di locking:
1)
pessimistico:
prima di inviare i dati da modificare sulla form dell'utente, seleziono e blocco in qualche modo il recordo in modo che non sia modificabile da altri
2)
ottimistico: in fase di update mi porto dietro i valori originali
di tutti i campi da aggiornare e faccio la modifica solo se i valori attualmente presenti nel db sono uguali ai miei valori originali (UPDATE Dipendenti SET Cognome=<nuovo cognome> WHERE ID = DIP_ID
AND Cognome=<VecchioCognome>)
In un'applicazione Web credo che solo l'opzione 2 (o qualcosa di analogo) sia ragionevolmente implementabile.
Non so se mi sono spiegato.
Alessandro
PS: se sei in procinto di scrivere un'applicazione
seria per il Web (come la tua domanda lascia supporre) forse dovresti anche pensare ad un db altrettanto serio. Per evitare polemiche, apprezzo Access (anche se c'è chi pensa che non sia un
vero RDBMS) ma in ambiente multiuser con elevata concorrenzialità lo considero un po' deboluccio.
Registrazione
): io intendo lock sui records del db.
