Newsgroup: it.comp.lang.visual-basic
Titolo: Contatori di Sistema non aggiornati (scritture simultanee su DB)

Ciao ragazzi,
ho il seguente problema:
ho sviluppato uno gestionale che utilizza una tabella sistema (Access 2000)
per menorizzare i "contatori" di vari documenti (DDT, Fatture, etc..).
La tabella ha un solo record i cui campi vengono azzerati a inizio anno
fiscale per risettare i contatori.
Il programma e' utilizzato in rete e per questo può capitare un accesso
simultaneo alla tabella per recuperare e scrivere qualche dato (progressione
contatori, etc...)
Uso classi che recuperano e scrivono valori attraverso recordset ado (ma la
faccenda sarebbe identica utilizzando direttamente il recordset), e capita
alle volte he qualche contatore non si aggiorni.
Secondo me ciò dipende dal fatto che se due utenti si caricano il recordset
(o la classe) della tabella sistema contemporanemanete, questo poi verrà
aggiornato solo da chi dei due updata per ultimo il recordset nullifcando
(sovrascrivendo) le eventuali modifiche ai valori impostate dall'altro
utente già updatate precedentemente.
Come posso rimediare a siffatto problema???????
Spero di essere stato chiaro nella spiegazione.
Attendo fiducioso
Paolo

 utente già updatate precedentemente.
Creati una tabella riservata ai "blocchi logici" contenente anche un solo
campo boolean.
Tutte (!) le procedure che devono recuperare un contatore per incrementarlo,
prima di ogni cosa vanno a vedere se c'è un blocco logico. Se sì aspettano,
se no posizionano il blocco logico (e magari lo riverificano) poi leggono il
contatore, lo incrementano e lo riscrivono. Infine tolgono il blocco logico
per lasciare spazio ad altri che dovranno operare allo stesso modo.

 Come posso rimediare a siffatto problema???????
Io aggiungerei una colonna boolean alla tua tabella di sistema, la chiamerei
tipo bloccato o occupato.
Quando un terminale va a leggere il contatore che gli interessa, deve
verificare che non sia segnato come occupato, se è occupato ritenta fino a
quando non si libera, quando si libera lo segna come occupato e solo quando
ha finito di fare tutte le sue menate lo incrementa e lo sblocca.
Ciao

 ha scritto nel messaggio
news:QeHW8.17175$7N3.3...@twister2.libero.it...

Stavo pensando che può capitarti la sfiga che un terminale segna come
occupato un contatore e poi per qualche motivo va in crash o salta la
corrente, allora ti si blocca l'intero sistema finchè un'amministratore non
va a mettere mano alla tabella liberando il contatore, per ovviare potresti
aggiungere una colonna dove segni qual'è il terminale che sta tenendo il
contatore impegnato, e poi quando con un terminale trovi il contatore
occupato, controlli che non sia proprio lui stesso a tenerlo occupato, se è
così entri lo stesso, aggiorni e liberi.
In questo caso male che ti vada ti rimane bloccato il sistema solo fino a
quando quel terminale andato in crash non ritenta di fare la bolla.
Non so se sono stato chiaro, mi sono accorto di aver fatto un po di casino.

chiarissimo.
Non ci avevo pensato, che pirla che sono.
Grazie

 ha scritto nel messaggio
news:1SGW8.15083$K_4.3...@twister1.libero.it...


Ecco perchè nopn ci avevo pensato, perchè non funziona!!!
Considera che il recordset rimane bloccato quel mezzo secondo o forse meno
che la routine impiega per recuperare incrementare e scrivere il contatore.
Aggiungere un campo e flaggarlo pone gli stessi identici problemi di
aggiornamento.
Se due client accedono insieme, chi tenta di bloccare la tabella flaggando
il campo non sarà visto dall'altro, esattamente come nella mia iniziale
condizione.
Non ti pare?

 ha scritto

No, se il recordset lo apri esattamente quando serve. E poi, come ti dicevo,
è bene controllare che il _proprio_ blocco (come correttamente specifica
David) sia effettivamente presente, rileggendo dopo averlo scritto. Può
essere un gioco di istanti, ma se leggo e trovo il mio nome (postazione,
utente, numero, quello che vuoi), anche gli altri troveranno il mio nome e
... aspettano.

 ... aspettano.
Mi sfugge sicuramente qualcosa,
ma io continuo a pensare che se l'accesso è simultaneo, il tentativo di
blocco di un utente (in qualsiasi modo esso venga fatto) ,  non verrà visto
dall'altro, non c'è niente da fare.
Così mi pare almeno.
Non trovate?

 Non trovate?
No, rileggi con attenzione (e nel "rileggi" c'è tutto quello che ti sfugge)

 Non trovate?
Allora prendi in considerazione un blocco del/dei record mentre tieni aperto
il recordset
adLockPessimistic
Blocco pessimistico record per record - Il provider esegue le operazioni
necessarie per assicurare la corretta modifica dei record, in genere
vincolando i record nella fonte dati in fase di modifica.
In questo modo non si pone più il problema dell'accesso simultaneo direi..

 dall'altro, non c'è niente da fare.
Vedi sopra

 ha scritto nel messaggio
news:vT1X8.21978$7N3.4...@twister2.libero.it...


 perchè uso classi che recuperano valori da recordset disconnessi
Se il recordset è disconnesso non potrai mai farcela.
La mia è un'affermazione (tanto ormai non mi c..a più nessuno, è solo per
far ridere e "provocare")
Comunque sia, emulando David, la mia "logica" (applicata) è questa (con
recordset in linea, ovviamente):
1) l'utente 1 legge e trova libero (se trova occupato cicla sempre su questo
punto)
2) l'utente 2 legge e trova libero (se trova occupato cicla sempre su questo
punto)
In qualsiasi ordine:
3) l'utente 2 scrive il suo "marchio" sulla tabella dei blocchi
4) l'utente 2 scrive il suo "marchio" sulla tabella dei blocchi
In qualsiasi ordine:
5) l'utente 1 legge (anzi, rilegge) se il suo "marchio" è stato depositato.
Se sì procede e nessuno potrà mai toglierglielo finchè non lo toglie, alla
fine, lui. se no, ripete tutto dal punto 1
6) l'utente 2 legge (anzi, rilegge) se il suo "marchio" è stato depositato.
Se sì procede e nessuno potrà mai toglierglielo finchè non lo toglie, alla
fine, lui. se no, ripete tutto dal punto 1
Solo per l'utente che ha depositato il suo "marchio":
7) Legge la tabella del contatore, lo incrementa e lo riscrive.
8) Toglie il suo marchio liberando così gli altri
Se il recordset è disconnesso potresti (se la logica del tuo programma lo
consente) applicare questa tecnica (se ti va ovviamente) prima di
disconnettere.

 La storia continua......
Rifai la classe.
A parte il fatto che quando vai a leggere il contatore dei DDT non te ne
deve fregare niente delle fatture accompagnatorie, da quello che hai scritto
mi sembra di capire che ogni volta leggi e riscrivi tutti i contatori.
Invece ti conviene aprire solo quello che ti serve, e poi finchè non lo hai
aggiornato tenerlo aperto.
Per risolvere il problema secondo me devi radicalmente cambiare il sistema
con cui svolgi le operazioni.
Però sai, fare analisi a distanza non è facile, ed io sicuramente non sono
l'asso di briscola in questo, non faccio l'analista di mestiere.
Ciao

 con cui svolgi le operazioni.
[cut]
Ma come faccio ad uplodare un solo campo del recordset???
Quando il recordset viene updatato riscrive tutti campi no?
Ciao

 ha scritto nel messaggio
news:agk8p4$22c$1...@lacerta.tiscalinet.it...

o fai un'update su un record solo con un cn.execute
oppure
apri un recordset con un record solo tramite una query che di identifichi in
maniera univoca il record con la chiave
rs.movefirst
rs("nomecampo")=variabile
rs.update