...e se scrivono tutti insieme?

[kumm]

Ciao ragazzi,
ho un database che viene letto per tutto il giorno da circa 50 persone sparse per l'italia.
La sera invece la situazione si inverte... e queste 50 persone scriveranno sul Database + o - nelle stesse fascie orarie...

Io so ke quando uno scrive sul database, agli altri utenti è impossibile fare lo stesso... Cosa potrebbe comportare a quest'ultimi?

Siccome i dati sono molto "delicati", per sicurezza dovrei usare il comando COMMIT per una trans, ma se questa non va a buon fine cosa succede? Viene notificato all'utente che deve ricominciare daccapo? o crede di aver scritto comq?

Illuminatemi... grazie...

[Andrea Simonassi]

Nella tua stessa situazione avevo aggiunto un campo ad ogni tabella a rischio. Il campo conteneva un numero intero. Ogni volta che qualcuno modificava il record questo numero veniva incrementato. In pratica uno legge il record e prende in possesso il numero intero. Quando vado a salvare controllo il valore del campo intero che deve essere uguale al numero letto, altrimenti significa che qualcuno aveva già modificato il record. In questo caso mettevo un raiserror nella sp in modo da avvisare l'utente. Ovviamente la sp di modifica tiene bloccata in scrittura la riga per il tempo dell'aggiornamento ed effettua il commit soltanto se tutto è andato bene.

[kumm]

Grazie Andrea, 6 stato molto gentile a rispondermi, ma al poverino di turno ke cerca di scrivere su una tabella occupata cosa succede?

[Andrea Simonassi]

Gli mandi un amichevole messaggio dipende dalla politica che scegli. Noi avevamo optato per la politica per la quale il primo che aggiorna vince, in modo da premiare gli utenti più veloci.

[kumm]

...ma purtroppo non sono un esperto nel settore e quindi ho qualke dubbio concettuale.....

La cosa dovrebbe funzionare così: quando il primo si connette alla pagina ASP ke gli permetterà di aggiornare il Database, andrà tutto liscio... inizierà la procedura con il COMMIT e se tutto andrà bene il Database sarà aggiornato...

ma:

1. Se invece il COMMIT non va a buon fine cosa succede? Gli viene notificato? Lo devo fare io? O automaticamente riparte un altro tentativo?

2. Quando un altro si collega alla pagina ASP, ma il DB nel frattempo è occupato in scrittura, cosa succede se questo utente tenta anke lui di scrivere? Ritorna degli errori? O deve aspettare ke il primo finisca? Quindi dovrà provare a riconnettersi + tardi?

3. Siccome queste procedure di aggiornamento saranno ogni sera e le persone saranno + o - 50, non si riskia di arrivare a notte fonda senza aver potuto finire di aggiornare il DB?? (l'ultimo utente farà le ore piccole?!)

Ti prego di avere pazienza... e grazie x l'aiuto fin ora datomi!!

[Andrea Simonassi]

Se vuoi comunicare al client il fallimento usa l'istruzione
raiserror poi dalla pagina asp testi l'insieme error della connection.

Oppure fai si che la stored procedure restituisca un valore diverso da zero in caso di errore, dalla pagina asp testi il valore di ritorno della procedura.

[kumm]

Grazie, mi 6 stato molto utile...

Quindi mi sembra di aver capito ke:

1. La COMMIT se non va a buon fine non mi dice niente ma devo scoprirlo io!

2. Se uno prova a scrivere su una tabella bloccata, restituisce un errore, e dovrò gestirlo io!!

3. Ognuno dovrà fare mille tentativi fino a ke non trova "libero"

.... è il punto 3 ke mi spaventa... riskia di far saltare il progetto...

Cmq grazie.

[Andrea Simonassi]

Se per 'la commit non va a buon fine' intendi dire che fai un rollback si. Se invece non fai tu il rollback ma ad esempio c'è una violazione di chiave primaria viene già restituito un errore ad ADO.


Ti faccio un breve esempio perchè tante volte le parole sono solo di peso.

Metti di avere solo una tabella che contiene solo un campo di tipo varchar (Descrizione) ed un contatore (ID).

SQL Server gestisce di già gli accessi contemporanei in modo automatico oppure usando gli hint tipo rowlock updlock ecc.

Il metodo che ti dicevo io invece serve a questo.

Ho un programma ASP dove uso recordset statici forward only solo per la lettura ed il popolamento di form HTML. Dopo di che il recordset viene distrutto.

Ora l'utente Ulisse dall'ufficio di Itaca ha caricato il record n°100 dal DB nella pagina ASP alle 10:47, un'altro utente, Agamennone, dall'ufficio di Micene, ha caricato nel suo browser lo stesso record alle 10:51. Achille ed Agamennone vedono la stessa pagina ASP. Ulisse va aprendersi un caffè, Agamennone modifica i dati e li salva alle 10:53 tramite la pagina ASP che a sua volta chiama una procedura su MSSQL Server.

Ulisse torna dalla pausa, modifica i dati e alle 10:55 salva i dati sovrascrivendo il lavoro di Agamennone.

Ora ammetti che Agamennone abbia inserito dei dati più dettagliati, in ogni caso sarebbe opportuno che Ulisse sappesse quali dati stia modificando, egli è infatti convinto di modificare i dati originali, mentre invece ha modificato i dati inseriti da Agamennone.

Allora cosa faccio?

Alla tabella aggiungo un campo intero con valore di default=0.

Ripetiamo lo scenario.

Ulisse carica il record n°100 dal DB nella pagina ASP alle 10:47, in un campo nascosto della pagina ASP memorizzo il valore intero che ho aggiunto. Agamennone, carica nel suo browser lo stesso record alle 10:51, entrambe le pagine hanno lo stesso valore per il campo nascosto.

Ulisse va aprendersi un caffè, Agamennone modifica i dati e li salva alle 10:53.

Ulisse torna dalla pausa, modifica i dati e alle 10:55 tenta di salvare, ma la stored procedure glielo impedisce.

Eccoti la sp

Create procedure salvamodifiche @descrizione varchar(30), @id int, @multiuser int
as

declare @mu int
begin trans

select @mu = multiuser updlock from Tabella where [id] = @id

if @mu <> @multiuser
begin
rollback
raiserror(......) /*manda un msg di errore*/
return 1 /* restituisce un codice di errore */
end

set @mu = @mu + 1

update Tabella set descrizione = descrizione, multiuser = @mu where [id] = @id

commit

Senza la guida in linea ho sicuramente sbagliato la posizione del updlock controlla prima.

[kumm]

altro ke guida in linea... vorrei avere te collegato al pulsante F1 ...

6 stato kiarissimo, e la cosa mi sembra molto interessante...

Ora non vorrei annoiarti, ma vorrei scendere ank'io nello specifico x non farti fare + di quello ke serve realmente....

Ogni mattina 50 persone si collegheranno al DB REMOTO tramite ASP per leggere vari dati da varie tabelle e li caricheranno su un "loro DB locale" (identico x struttura al DB REMOTO)
Fin qui tutto bene, xke nessuno ostacola l'altro, giusto? Leggono e basta...!!

Ogni sera, le stesse 50 persone si collegheranno al DB REMOTO tramite un altro ASP che leggerà i dati del "DB locale" e scriveranno tutti questi dati (si tratta di preventivi fatti durante il giorno) IN ALTRE TABELLE DEL DB REMOTO o addirittura in un altro DB REMOTO.
Questo per avere tutti i preventivi del giorno.
Una volta riempito (queste tabelle temporanee), le persone ke gestiscono il DB REMOTO controlleranno tutti questi preventivi e sceglieranno quali caricare nel DB VERO E PROPRIO (quello da cui le 50 persone leggeranno la mattina) e quali scartare. Dopodiké le tabelle temporanee verranno svuotate (o se li tengono come storico... fatti loro!!).

Il mio problema nasce solo dal fatto ke queste 50 persone vorranno scrivere nelle stesse tabelle nella stessa fascia oraria.

Dovrebbe essere + facile di quello ke mi hai spiegato xke qui nessuno sovrascrive il lavoro di nessuno, ma vengono solo AGGIUNTI records...

Come faccio?

[Andrea Simonassi]

Se fai solo delle Insert non devi assolutamente gestire niente, il problema lo avresti solo con le update. MSSQL Server accoda le richieste e le esegue una dopo l'altra senza problemi e senza che l'utente debba aspettare niente.