Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Gestione degli accessi: se il programma si pianta?

Ho scritto un programma che tra le altre cose gestisce gli accessi per
il suo utilizzo.
Praticamente ho un server con SQLServer e il mio programma che gira sui
vari client. Quando un utente lancia il programma, questo chiede nome e
password, controlla in una tabella del db se corrispondono e in caso
affermativo registra in un'altra tabella l'avvenuto accesso.
Quando il programma viene chiuso nella stessa tabella registro l'uscita.
Questa la struttura delle due tabelle che interessano
(i dati sono inventati)
operatori
+----------+----------+-----------------+
| login    | password | livello_accesso |
+----------+----------+-----------------+
| marcopaf | filino   | 0               |
| gingomuf | gargiano | 1               |
| birobiro | barufala | 1               |
| test     | test     | 1               |
| admin    | 3jr23mj4 | 2               |
+----------+----------+-----------------+
accessi
+----------+----------+------------------+
| in/out   | login    | data_ora         |
+----------+----------+------------------+
| 1        | admin    | 03/05/2002 15:23 |
| 1        | birobiro | 03/05/2002 15:34 |
| 0        | birobiro | 03/05/2002 16:13 |
| 0        | admin    | 03/05/2002 17:26 |
| 1        | test     | 03/05/2002 19:19 |
+----------+----------+------------------+
Ora per impedire che l'utente usi più copie del programma
contemporaneamente, o che si colleghi da un'altra postazione
dimenticandosi prima di chiudere il programma in quella precedente,
all'avvio controllo anche che lo stesso non risulti già collegato.
Tutto funziona bene finchè il programma funziona bene.
Purtroppo il programma non è esente da bug e la sfiga è molto brava
a trovarli prima di me!
Ora nel caso che il programma si pianti, l'utente non riesce più a
loggarsi, perchè secondo quanto registrato nelle tabelle sta già
usando il programma. Il problema l'ho risolto temporaneamente con un
altro programma, denominato sblocco, che, dietro richiesta di username e
password, inserisce nella tabella accessi la voce di uscita che avrebbe
dovuto inserire il programma stesso se fosse riuscito ad arrivare alla
fine.
L'unico difetto di questa soluzione e che se un utente lancia lo sblocco
quando sta usando il programma, alla fine nella tabella accessi
risulterà un uscita extra, ma questo fino a ieri non mi dava problemi.
Questa invece la situazione a oggi.
Il programma si è evoluto, e fa molte cose. Tra queste durante la sua
attività marchia alcuni record di alcune tabelle come "in uso da parte
dell'utente", questo mediante un apposito campo "usato_da" del record
stesso. Ora in caso di blocco del programma tali record continuano ad
essere considerati in uso, per cui avrei bisogno di ampliare il
programma di sblocco in modo che, oltre a registrare un'uscita, sblocchi
i record utilizzati dall'utente.
Ampliando lo sblocco in tal modo però il difetto descritto sopra diventa
un vero e proprio errore, infatti se un utente facesse lo sblocco con il
programma attivo, i record da lui usati risulterebbero liberi, quindi
un altro utente potrebbe modificarglieli sotto il naso.
Come risolvere il problema?
Io ho pensato ad alcuni modi, entrambi basati sul tentativo di
tenere monitorato lo stato di attività del programma principale, ma non
riescono a garantirmi al 100% da eventuali problemi.
Soluzione A
Un terzo programma detto "controllo" che viene avviato insieme al
principale sulla stessa macchina e che periodicamente controlla la lista
dei processi.
Se da questa vede sparire il programma senza che questo (ad esempio
tramite una connessione TCP) gli abbia comunicato la normale chiusura,
avvia automaticamente lo sblocco.
Problemi
Se il blocco del programma avviene per un problema sulla rete o per un
problema hardware sulla macchina (esempio banale, qualche idiota la
spegne) "controllo" non è in grado di collegarsi a SQLserver per
effettuare le registrazioni.
Soluzione B
Un terzo programma come nella soluzione A, solo che in caso di problemi
non effettua lui le operazioni, ma ordina di farle ad un quarto
programma detto "controllo_server" sempre in ascolto sul server.
In questo caso se cade la rete è "controllo_server" ad effettuare lo
sblocco quando rileva la caduta della connessione.
Problema
Se cade la connessione, non è detto che il programma dall'altra parte si
sia piantato, anzi normalmente se stacco il cavo di rete mentre l'utente
sta inserendo dei dati e lo riattacco prima che questo salvi, il
programma non se ne accorge nemmeno.
Soluzione C
Ampliamento della soluzione B.
Potrei, nel caso che "controllo_server" rilevi la caduta della rete,
iniziare a fargli fare dei ping alla macchina finchè non riprende a
rispondere, quando riprende riprovo a collegarmi a "controllo", se
questo riponde tutto ok, è stata solo un'interruzione temporanea,
altrimenti avvio lo sblocco.
Problemi
Non so come si fanno dei ping da VB.
Ci può essere la seguente situazione patologica.
Il computer è spento, "controllo_server" sta facendo dei ping in attesa
che il pc riparta... ma l'inconveniente è avvenuto poco prima del
termine del turno di lavoro dell'operatore e costui è già con le chiavi
infilate nel cruscotto e il piede sull'acceleratore.
Potranno passare ore prima che quel pc riparta, non posso permettermi
che i record rimangano bloccati così a lungo.
Soluzione D
Quando registro l'ingresso e l'uscita dal programma, registro anche l'IP
della macchina da cui il programma viene lanciato.
Quando si lancia lo sblocco, se la macchina è diversa da quella su cui
risulta in esecuzione il programma, lo sblocco avverte che va eseguito
da quell'altro pc. Se è la stessa, si può controllare nella lista dei
processi se effettivamente il programma è ancora in esecuzione.
Problema
Lo stesso della soluzione C, se il programma si blocca quando
l'operatore sta per terminare il turno, questo non sta a lanciare lo
sblocco, ma prende e se ne va a casa.
Ulteriore problema comune a tutte le soluzioni:
il programma è scritto in VB; andare a vedere se nella lista dei
processi c'è ancora il programma interessato non mi pare una cosa tanto
semplice da farsi in VB.
Grazie in anticipo per le eventuali risposte.
-- 
Samuele Battarra
prova il mio newsreader:
http://digilander.iol.it/battarsa/programmi/news/

Come risolvere il problema?
Tralascio le ipotesi proposte perche' mi piacciono molto poco tutte
quante :-(
Non puoi proprio mettere un tuo programma sul server?
Se potessi, questo programma si dovrebbe occupare lui di aggiornare
la tabella di log e pingare periodicamente i client.
I client, dal canto loro, dovrebbero cercare tale serverino e, nel caso
non ricevessero risposta entro un certo tempo, dovrebbero comandare
a sql server di "tirarlo su". Per fare questo potrebbero invocare
la stored procedure xp_cmdshell.
Come ti sembra? Si puo' approfondire?
-- 
ciao, hal

 wrote in message


Credo che sia possibile attivare un trigger anche alla disconnessione di un
utente.
In questo caso, siccome ADO chiude la connessione quando il programma muore,
il server SQL riceve questa notifica.
A questo punto va a vedere quale utente era loggato con lo spid caduto, e
libera tutti i blocchi.
L'unica cosa che i client devono fare è scrivere nella tabella degli spid il
nome utente di connessione (volendo lo si può fare anche con un trigger alla
connessione).
E' tuttavia fondamentale, in questo caso, non usare mai l'assegnazione di
ActiveConnection degli oggetti Ado mediante stringa, ma sempre e solo con
Set ..., altrimenti ogni chiusura di recordset o command farebbe scattare il
trigger.
Ciao
Alberto

 
Approfondiamo pure. Anche se non vedo soluzione al problema sopra.
-- 
Samuele Battarra

 database così non hai problemi se va giù il tuo componente server.
Se potessi usare le transazioni per bloccare i record non avrei nessun
problema. Il fatto è che usando le transazioni, se un utente va in
modifica di un record, tale record viene bloccato in scrittura, come
è giusto che sia.
Ho necessità però, anche nel caso che ci siano dei record bloccati in
scrittura, di poter fare query del tipo "dammi tutte le persone che si
chiamano 'marco'". Se uno dei record bloccati era proprio un Marco, la
query si blocca finchè il record non viene rilasciato, mente io avrei
bisogno che mi restituisse, in questo caso, tutti i marco tranne quello
bloccato.
-- 
Samuele Battarra

 
In questo caso il problema è dovuto al fatto che non ho una connesione
permanente con SQLServer.
Quando vado in modifica mi collego, leggo i dati e mi scollego.
Quando premo "salva" mi collego, scrivo i dati e mi scollego.
Se tenessi la connessione sempre aperta il record rimarrebbe bloccato
troppo a lungo.
-- 
Samuele Battarra

 wrote in message
news:00702.2002...@news.interbusiness.it...


gli accessi e le richieste al database.
Personalmente lascerei stare gli activex e farei un server normale che sfrutti
la rete: meno ci si impelaga con com, dcom, registry imho meglio e'.
-- 
ciao, hal


Pefettamente d'accordo.
Anche con la parte [cut]-tata...
ciao
ugo

 
Questo è più o meno il metodo che uso, solo che non ho un componente
server, ma tutto il lavoro viene effettuato dal programma.
Il problema e che dopo aver impostato il flag, mi scollego dal db,
in quanto l'operazione di modifica dei dati nella maschera potrebbe
durare a lungo. Se dopo di ciò, ma prima di ricollegarmi per salvare
le modifiche, il programma si blocca, il flag rimane nello stato
sbagliato.


 
Il problema e se la rete cade mentre non sono fisicamente collegato.
Quando cerco di ricollegarmi per salvare i dati cosa faccio?
Rinuncio? Così sulla tabella il flag rimane impostato su bloccato.
Rinuncio sapendo che dall'altra parte c'è il server che a rilevato
la caduta della rete e mi ha sbloccato lui i record?
Potrebbe succedere questo: cade la rete, il server lo rileva e sblocca
i record, viene ripristinata la rete, l'utente preme il bottone salva
avviando la scrittura. Vado a scrivere un record che magari nel
frattempo potrebbe aver già modificato qualcun altro.
Se però prima di scrivere e ripristinare il flag, controllo che questo
abbia ancora il valore che gli avevo assegnato... forse o trovato la
soluzione al problema. E' un po' onerosa perchè l'accesso al flag viene
fatto in più punti e mi toccherà riscrivere parecchio codice, ma forse
à la soluzione migliore.


frattempo potrebbe aver già modificato qualcun altro.
Ah, ma tutto questo ti serve proprio per "bloccare"  veramente il record.
Ma che senso ha in un' epoca di applicazioni sempre piu' distribuite
e sempre piu' stateless?
Io non bloccherei mai il record. Tutt' al piu' aggiungerei un campo
con un id incrementabile.
Quando leggo il record prendo nota di questo id.
Se cerco di salvare delle modifiche lo faccio solo se tale id e' ancora
uguale a quello che avevo letto, quindi lo incremento.
Se trovo l' id diverso allora avviso l' utente e rileggo il record con
i valori correnti.
Fine dei problemi, la rete puo' cadere tutte le volte che vuole.
-- 
ciao, hal

hal1961 ha scritto:

Purtroppo devo bloccare per forza i record.
Infatti ogni record rappresenta un cliente, la modifica del record
(ovvero l'iserimento dell'indirizzo del cliente), avviene telefonando
al cliente stesso.
Con la soluzione da te proposta, se qualcun'altro mi avesse cambiato i
dati nel frattempo e rileggessi il record con i valori correnti,
l'operatore si troverebbe ad aver perso i dati digitati e a dover
richiamare il cliente. Una cosa del genere non è accettabile.


richiamare il cliente. Una cosa del genere non è accettabile.
Perche' mai dovrebbe perdere i dati inseriti?
Potresti benissimo fargli leggere i dati da lui inseriti e quelli appena
ritrovati nel database. 
Eventualmente potresti registrare anche l' id dell' operatore che ha 
inserito la modifica, cosi' si possono anche consultare, se occorre.
Francamente non vedo il problema.
-- 
ciao, hal

 
-- 


rabbrividiresti.
Altro che se conosco i clienti!
Ma in questo caso il tuo utente non ha scelta: gli hanno gia' cambiato i dati
sotto il cu10.
E, se non glieli avessero cambiati, tu avresti accettato le sue modifiche, anche
perche' suppongo che se lo hai accolto in Edit significa che gli sono stati
assegnati i permessi di modifica sul record, altrimenti ciccia.
Perche' allora non puoi accettargliele adesso?
Il fatto che tu lo metta a conoscenza che sono cambiati i dati nel frattempo
e' un favore in piu' che gli fai.
-- 
ciao, hal

hal1961 ha scritto:

Scusa ma non riesco ad inquadrare bene il discorso. Vediamo di fare un
riassunto.
Tu dici di non bloccare il record, ma lasciare l'utente libero di
accedervi.
Quando va a salvare il record se non è stato modificato da altri ok,
altrimenti viene avvertito che qualcun'altro ha fatto delle modifiche
e ..?? Da quel che ho capito gli viene impedito di salvare.
In questo caso deve chiudere la maschera e riaprirla nuovamente in
modifica e digitare di nuovo tutti i dati che nel frattempo si è segnato
da qualche altra parte, abbastanza scomodo.
Ho forse dici di lasciarlo salvare ugualmente?
In questo caso viene perso il salvataggio precedente.
Però forse stiamo divagando un po' troppo.
Vediamo di concentrare l'attenzione su ciò che serve.
-- 
Samuele Battarra

hal1961 ha scritto:

Scusa ma non riesco ad inquadrare bene il discorso. Vediamo di fare un
riassunto.
Tu dici di non bloccare il record, ma lasciare l'utente libero di
accedervi.
Quando va a salvare il record se non è stato modificato da altri ok,
altrimenti viene avvertito che qualcun'altro ha fatto delle modifiche
e ..?? Da quel che ho capito gli viene impedito di salvare.
In questo caso deve chiudere la maschera e riaprirla nuovamente in
modifica e digitare di nuovo tutti i dati che nel frattempo si è segnato
da qualche altra parte, abbastanza scomodo.
Ho forse dici di lasciarlo salvare ugualmente?
In questo caso viene perso il salvataggio precedente.
Però forse stiamo divagando un po' troppo.
Vediamo di concentrare l'attenzione su ciò che serve.
Mi sono reso conto che forse non ho spiegato bene le cose.
Il compito di questo programma è quello di raccogliere gli ordini di un
call center.
Quando una persona chiama viene preso solo cognome nome e telefono, in
modo da poter smaltire velocemente eventuali code.
Per effettuare la richiamata, l'utente spinge un bottone e il programma
gli propone in automatico una persona da richiamare, presona che viene
bloccata con il meccanismo finora descritto.
Se non bloccassi, la persona risulterebbe ancora libera e potrebbe venir
proposta ad un altro utente per la chiamata.
Se però il programma si blocca durante la richiamata, tale persona
continua a risultare in uso e non verrà più proposta per la chiamata.
-- 
Samuele Battarra

continua a risultare in uso e non verrà più proposta per la chiamata.
Potresti darti un timeout. Quando carichi il record della persona da chiamare
scrivi in un campo data e ora di lettura e, eventualmente, l' id dell' utente.
Quando, successivamente, vai a rileggere il record controlli l' orario.
Se tale orario e' precedente all' ora corrente oltre un certo periodo (possibilmente
configurabile, in modo da aggiustare il tiro in relazione al flusso del lavoro),
allora carichi tranquillamente il record, sovrascrivendo il campo contenente
data e ora di lettura.
Anche sui client esegui un controllo analogo.
Carichi il record e ti scrivi da qualche parte l' orario di lettura.
Se l' utente non salva le modifiche entro il timeout stabilito, lo avvisi
e vai a controllare sul database se qualcun altro ha caricato il record.
Se nessuno ha caricato il record nel frattempo allora sei a posto.
Se invece lo ha caricato qualcun altro vuol dire che l' utente
ha fatto i c@%%| suoi invece di lavorare: che cosa ne puoi tu?
Il comportamento da tenere in questo caso, imho, va discusso
con chi coordina il lavoro degli utenti:
- neghi comunque il salvataggio;
- salvi il record in una tabella di "errori", da riconciliare successivamente;
- salvi e mandi un messaggio di posta al secondo utente che ha caricato il
record, avvisandolo di non procedere perche' si sta modificando il
record che ha caricato.
Il punto chiave e' il timeout, che e' da stabilire in base a come viene
eseguito il lavoro, ma questo puoi saperlo solo tu.
Il tutto e' imvho ;-)
-- 
ciao, hal

 Il tutto e' imvho ;-)
imho too
ciao
ugo

 ha fatto i c@%%| suoi invece di lavorare: che cosa ne puoi tu?
Non sono daccordo, secondo me nel caso in cui sul client il programma è
ancora attivo con la "chiamata" aperta (record occupato) e il timeout (ad
esempio 1 minuto) è scaduto, il client dovrebbe aggiornare l'orario sul
database continuando a mantenere occupato il record.
A meno che non si vuole impedire all'operatore di dimenticare il programma
attivo con la "chiamata" aperta.
Si potrebbe risolvere comunque il problema aggiungendo un ulteriore campo
"data e ora" sul record, in cui viene registrata l'orario di apertura della
chiamata da parte di quel determinato operatore, in modo che sia possibile
tirare fuori una lista delle "chiamate" aperte da più tempo e magari forzare
l'apertura di quella "chiamata" (probabilmente lasciata aperta).
Per implementare questa tecnica è fondamentale non basarsi sull'ora di
sistema dei vari client e il timeout controllato periodicamente dal client
con il record occupato deve essere leggermente inferiore a quello di
controllo per l'accesso.
Spero di non aver esposto in maniera troppo confusa il mio parere...
...non ho molto tempo... :-(
Ciao
Pasquale Minerva

hal1961 ha scritto:

Non mi sembra che l'utilizzo di un timeout sia semplice, anche per la
difficoltà di sceglierne la durata.
Faccio subito un esempio pratico.
Viene richiamato un cliente, tenendone bloccato il relativo record.
Durante l'inserimento del comune l'operatore incontra dei problemi
(ho il database dei comuni d'italia, il comune inserito deve essere
uno di quelli presenti in archivio), dopo qualche tentativo di
accordarsi col cliente, chiude la comunicazione e inizia a fare delle
ricerche nell'elenco dei comuni per vedere se magari si trattasse solo
di un errore di battitura o di un'incomprensione.
Se nel frattempo arrivassero chiamate, la finestra di quell'ordine viene
lasciata da parte per prendere le telefonate.
Nella peggiore delle ipotesi la finestra potrebbe rimanere li aperta
fino alla fine del turno di lavoro.
-- 
Samuele Battarra

 database continuando a mantenere occupato il record.
Quello che puoi fare è:
Crei una tabella dei client
Ogni volta che un client accede, scrive data ed ora (del server) sulla
tabella
Ogni volta che un client esegue qualunque cosa, o attraverso dei trigger o
direttamente dal client fai un update della tabella aggiornando data ed ora
di ultima operazione.
Ogni tot tempo (diciamo 5 minuti), scheduli una piccola stored procedure che
verifica quali client non stanno facendo più niente sul DB da n minuti (ad
esempio 10 minuti).
Se trova un client che da dieci minuti non sta facendo più niente,
eventualmente controlla se c'è ancora lo spid attivo, altrimenti libera
tutti i record marcati come occupati dal client stesso.
Se vuoi che l'utente possa tenere bloccato un record anche mentre chiacchera
amabilmente, puoi istruire il client a aggiornare la tabella ogni minuto,
purchè nel minuto stesso sia stato premuto almeno un tasto (basta un timer e
una variabile booleana), oppure metti l'opzione 'Tieni Bloccato', e il
client tiene aggiornata la tabella ogni minuto.
Questo ha anche il vantaggio che se un client si pianta, l'utente lo riavvia
e cerca di operare su un altro record, il client stesso, nel momento in cui
va a scrivere sulla tabella dei client si accorge di essere già registrato,
capisce che si deve essere piantato, e teoricamente potrebbe anche
riprendere tutto da dove era rimasto (ma questo dipende dall'applicazione).
Ciao
Alberto

Faccio subito un esempio pratico.
:-)
[cut]
A questo punto mi sembra che valga la pena di approfondire il ragionamento
di Alberto nel post delle 12:17.
-- 
ciao, hal

 tutti i record marcati come occupati dal client stesso.
Perň questa soluzione non mi risolve il problema della rete.
Cioč se un client non sta facendo niente da n minuti, come faccio a
sapere se l'applicazione č defunta, o semplicemente non riesce a
segnalare la sua presenza perchč č caduta la rete?
-- 
Samuele Battarra

segnalare la sua presenza perchè è caduta la rete?
Telefonando?
Cavolo, non cadra' mica sempre la rete !
Altrimenti, se servisse un sistemista ....
-- 
ciao, hal
che il possibile lo hai fatto, l' impossibile lo sai facendo
e per i miracoli ti attrezzerai ;-)


Se ne servissero due...
ciao
ugo

 Altrimenti, se servisse un sistemista ....
Quello c'è già , solo che gli fanno fare di tutto, dal tecnico hardware
alla gestione del sistema informativo.
-- 
Samuele Battarra

alla gestione del sistema informativo.
Mi sa tanto che non e' il solo ;-)
-- 
ciao, hal

 segnalare la sua presenza perchè è caduta la rete?
Dunque:
Tu vuoi che il server valuti se il programma client è piantato o meno,
quando la rete, che collega il server col client, non è attiva.....
Direi che per questo puoi contattare Wanna Marchi ed il suo mago....
Alberto

 Samuele Battarra
Sempre tenendo presente l'implementazione della soluzione con il timeout,
riesci a rilevare la differenza tra i due tipi di inattività.
Provo a fare un esempio:
-------------------------------------------------------------------------
STRUTTURA DATABASE
[DATABASE]
   [Tabella Clienti]
      [CodiceCliente]
      [RagioneSocialeCliente]
      [TelefonoCliente]
      [UltimoAccessoRW] (campo data e ora)
      [IdOperatoreUltimoAccessoRW] (ad esempio campo numerico)
--------------------------------------------------------------------------
CONFIGURAZIONI
Timeout lock di record -interrogazione- = 60 sec.
Timeout lock di record -conferma di lock- = 50 sec.
-------------------------------------------------------------------------
OPERAZIONI BASE DEL PROGRAMMA CHE ACCEDE AI RECORD
(A)Per vedere se un record (o un gruppo di record) è libero controlla se la
data e ora attuale è maggiore di 60 sec. (Timeout lock di
record -interrogazione- ) rispetto a quella letta dal campo
"UltimoAccessoRW" del record in esame.
(B)All'apertura in lettura e scrittura di un record scrive la data e l'ora
di accesso nel campo "UltimoAccessoRW" e il codice dell'operatore (o del
client) nel campo "IdOperatoreUltimoAccessoRW"
(C)Con un oggetto Timer ogni 50 sec. (Timeout lock di record -conferma di
lock- ) aggiorna il campo "UltimoAccessoRW"
----------------------------------------------------------------------
ESEMPIO CON DUE PC CLIENT
CLIENT 1
-Controlla se può accedere al record  1 della "TabellaClienti" alle ore
10.00.00. Il valore del campo "UltimoAccessoRW" è 09.00.00 (1 ora di
differenza nettamente superiore a 60 sec.) (A)
-Quindi Accede al record
-Scrive nel campo "UltimoAccessoRW" il valore "10.00.00" e l'appropriato ID
Operatore nel campo "IdOperatoreUltimoAccessoRW" (B)
-aggiorna il campo "UltimoAccessoRW" ogni 50 sec. (C)
CLIENT 2
-Controlla se può accedere  al record  1  della "TabellaClienti" alle ore
10.00.30. Il valore del campo "UltimoAccessoRW" è 10.00.00 (Aggiornato da
Client1. Differenza 30 sec. inferiore a 60 sec. di "Timeout lock di
record -interrogazione-") (A)
-Non Accede al record
CLIENT 2
-Controlla se può accedere  al record  1  della "TabellaClienti" alle ore
10.01.30. Il valore del campo "UltimoAccessoRW" è 10.00.50 (Aggiornato da
Client1 con l'oggetto Timer (C). Differenza 40 sec. inferiore a 60 sec. di
"Timeout lock di record -interrogazione-") (A)
-Non Accede al record
Alle 10.01.35 CLIENT 1 viene disconnesso dalla rete e non può più aggiornare
il campo "UltimoAccessoRW" ogni 50 sec.  (C)
Intercetta l'errore di scrittura sul database e comunica all'utente il
problema.
CLIENT 2
-Controlla se può accedere al record  1 della "TabellaClienti" alle ore
10.02.00. Il valore del campo "UltimoAccessoRW" è 10.00.50 (70 sec. di
differenza superiore a 60 sec.) (A)
-Quindi Accede al record
-Scrive nel campo "UltimoAccessoRW" il valore "10.02.00" e l'appropriato ID
Operatore nel campo "IdOperatoreUltimoAccessoRW" (B)
-aggiorna il campo "UltimoAccessoRW" ogni 50 sec. (C)
... e cosi via...
----------------------------------------------------------------------------
----
Per implementare questa tecnica è fondamentale non basarsi sull'orario di
sistema di ciascun client ma su un orario univoco in rete.
Ovviamente è solo un banale esempio ho tralasciato molti particolari e
magari non calza perfettamente con la tua problematica però secondo me ci si
può lavorare su. E ' facile trovare dei difetti a questa tecnica ma è
altrettanto facile completare la struttura implementando ulteriori controlli
che perfezionino la gestione.
Forse mi sono dilungato un po' troppo...  :-)
...ma spero che l'esempio risulti chiaro e ti sia di aiuto.
Ciao
Pasquale Minerva

 [SNIP]
Uno dei thread da lurkare piu' interessanti degli ultimi tempi! ;)
Lokar
P.S. Complimenti per la soluzione ai tempi di accesso suggerita.

 
Un difetto, o forse semplicemente una dimenticanza, l'ho già trovata.
Come si deve comportare il programma quando a finito il suo lavoro
sul record e lo deve sbloccare? Come hai scritto tu non fa niente,
lasciando il record bloccato fino allo scadere del timeout.
Una soluzione potrebbe essere quella di impostare, sull'uscita, una
data sicuramente precedente.


 data sicuramente precedente.
Un altra è quella che ho menzionato sopra...
La struttura che ho rappresentato nell'esempio non pretende di essere la
soluzione completa a questo genere di problemi, ma invece un'idea di base da
cui partire per implementare una vera e propria soluzione.
Ciao
Pasquale Minerva