Newsgroup: it.comp.lang.visual-basic
Titolo: Accesso esclusivo db access

Salve, potrei avere un vostro suggerimento procedurale? Programma in vb6 
e ado (db access), utente A apre form per inserimento nuovo record in 
una tabella che ha tra i campi un numero identificativo che non è l'id 
del record, nel frattempo anche utente B si prepara all'inserimento. In 
una procedura, prima del metodo addnew del recordset, vado a leggere il 
progressivo attuale e lo metto in una variabile che riporto all'interno 
della routine di archiviazione, una volta eseguito l'update del record 
con una cn.execute alzo di una unità il progressivo. L'utente B, troverà 
automaticamente il progressivo aggiornato. La domanda è: Posso bloccare 
l'inserimento dell'utente B fino a quando l'archiviazione non sarà stata 
effettuata con update da A e viceversa? Potreste suggerirmi una corretta 
metodologia per gestire questo tipo di accesso condiviso?
 
Grazie



Scusate, al primo mi ha dato errore di invio.
Mi spiace aver postato due volte


Non conosco gli strumenti specifici di access, ma se fai una tabella
semaforo, dove per Tabella inserisci l'utente che sta salvando puoi fare
una cosa simile
 
Verifico se non c'è nessuno che scrive, se ok scrivo il mio utente, poi
verifico che effettivamente l'utente sono io che ha scritto, sennò aspetto.
Finito il lavoro libero la tabella e l'altro in attesa va a fare quel che
deve.


Se ho capito bene, creao una tabella che chiamerò
ad esempio TempUsr con un unico campo di testo,
quando clicco sul pulsante di archiviazione,
Faccio una verifica sul Recordcount della tabella,
se vuota,aggiungo un record con il nome utente, in altri
casi, chiudo la procedura e creo un messaggio di temporanea
indisponibilità, l'utente che termina l'archiviazione corretta,
automaticamente eliminerebbe il record dalla tabella temp...
Spero di aver capito bene, in altri casi dì pure parolacce.
 
Grazie infinite
 
 

 Grazie infinite
 
Mille problemi....ad esempio....
problema al database
Utente A scrive il record...flagga il semaforo...il sistema va in crash
Al riavvio
il flag è rimasto settato....nessuno scrive più su quel record!
Inoltre
Access (non so l'ultima versione ma mi pare abbia mantenuto il passato) 
ha un blocco NON di record ma di "pagina"...ti blocca una "pagina" di 
una certa dimensione quando scrivi un record
 
Tu in buona sostanza chiedi di fare un blocco PESSIMISTICO: il record è 
mio finchè non lo rilascio....è mio!
Va benissimo ma è una pratica che sopratutto con l'avvento di db 
client/server è sempre più soppiantata a favore del blocco OTTIMISTICO: 
il record è di tutti ed è mio SOLO E SOLTANTO per il tempo necessario a 
scrivere le modifiche nel database!
 
Il lock pessimistico è buono quando devi scrivere dati in una sequenza 
temporale molto ben definita ad esempio: voglio ricostruire un indice 
di una tabella....immane casino se nel frattempo qualcuno mi accede 
alla tabella e mi cambia i record che già io sto cambiando!
MA E' molto onerosa in termini di banda e pericolosa se il meccanismo 
di "semafori" non è correttamente implementato!
 
Tendenzialmente con l'avvento di nuovi strumenti di sviluppo e 
l'evoluzione tecnica generale si cerca di limitare gli accessi 
pessimistici il più possibile e di farli fare al "server" tramite 
stored o quant'altro...per non sovraccaricare la rete!
 
LOCK OTTIMISTICO
li hai il problema opposto
A legge i dati di una scheda
B fa altrettanto
A scrive 1000 nel campo prezzo
B scrive 900 nel campo prezzo
A e B schiacciano un tasto per aggiornare il database
Che succede?
Il meccanismo di lock serve il più veloce ad esempio B
e "segnala" ad A che è cambiata la situazione di partenza e che i dati 
da cui LUI partiva non sono più aggiornati...a quel punto è cura del 
programmatore decidere se fargli comunque aggiornare...o ricaricare i 
dati e fargli riprovare a fare la modifica...o farlo uscire dalla 
procedura con un messaggio di errore!
 
TUTTO STO AMBARNDAN COME SI IMPLEMENTA?
in vb6 + ado a seconda del ...provider bada bene...A SECONDA DEL 
PROVIDER (oledb usato)... potevi avere a disposizione un recordset 
settato come lock pessimistico
in 
vb.net
 + 
ado.net
 ...NO NO E ANCORA NO!
Addirittura in 
ado.net
 lavori SEMPRE in modalità disconnessa (non è 
verissimo perchè i vari reader sono connessi...ma è vero per la logica 
CRUD)....
Perchè? Perchè il mono va verso una integrazione della rete!
La "moda" di adesso è di avere logiche disconnesse....applicazioni 
cloud (vuol dire che ti scarichi un gadget da internet e poi o lo usi e 
lo butti o lo installi in un S.O. talvolta custom....android ad 
esempio)
 
Adesso lavori così:
A) Utente...c'ha un "terminale" che non è detto sia un pc...ma un 
tablet o uno smartphone
B) L'utente scarica una app (o un gadget) che fornisce una interfaccia 
(carina, colorata...con un sacco di fuffa per gli occhi) che configura 
il suo "terminale" per accedere ad un qualcosa di remoto
C) C'è un qualcosa remoto che fornisce servizi di accesso ai vari 
terminali
 
Lavorare così implica di NON essere sempre connessi ad un server e 
sopratutto di NON bloccare risorse o farlo il meno possibile!!!
 
TRADOTTO tutto sto cappello
vado a memoria
VB6
open recordset LockOptimistic
Recordset.edit
....tutte le modifiche
recordset.BatchUpdate e gestisci gli errori di concorrenza
 
VB.net
soluzione più rapida
Configura un
DataAdapter
Creati l'interfaccia sulla form che vuoi usando il databinding (cio 
sono mille tutorial on line...se non è una cosa complessa e se è per 
studio fin qui NON HAI SCRITTO UNA RIGA di codice)
in un bottone inserisci
DataAdapter.Update
e poi gestici gli errori di concorrenza in
Evento.RowUpdated
 
Maggiori info
...ed un esempio
http://msdn.microsoft.com/it-it/library/aa0416cz(v=vs.80).aspx#Y2700
 
 
 
Il sistema a semafori funziona benissimo (i database lo usano nel loro 
core) ma è anche pericolosissimo se non è più che sotto controllo! Devi 
prevedere meccanismi non banali di pulizia dei semafori rimasti rossi 
ed abbandonati dall'utente!!!
O più banalmente....arrivo mi siedo comincio a modificare...mi blocchi 
il record...mi chiama a telefono zia Adalgisa...oppure vado in pausa 
per 15 minuti...che fai mi lasci il record bloccato per 15 
minuti????!!!!
 
-- 
----- Italliaaaaa 3227! -----
Sa cosa mi disse a Roma il cardinale Poletti? "Lei fa del bene, perchè 
con il suo personaggio la gente si rilassa e sorride, riconciliandosi 
un poco con la vita." ...Fra poco mi venderanno in farmacia.
(Lino Banfi)
 
 

 minuti????!!!!
 
Concordo che non è ottimale, ma se uno si pone un problema dell'OP è
abbastanza semplice da implementare, basta aver cura di gestire gli errori
al salvataggio, oppure un tool di pulizia dei semafori.
Il blocco lo fai un attimo prima del comando di update e lo toglie appena
non tutti i comandi sono stati lanciati, ovvero qualche decimo di secondo
di norma.

 Il Fri, 16 Dec 2011 09:20:11 +0100, Wodka40° ha scritto:
zac
 
Lungi da me voler fare polemica ma 2 appunti mi sento di farli:
 
1)....usato così come dici è parecchio simile ad una concorrenza 
ottimistica....ed allora tanto vale far fare il "lavoro sporco" al 
motore db...o al limite al provider ado(.net) usato...
 
2)...avere un tool...o un blocco di alcuni decimi di secondo non rileva 
e non aggiunge o toglie nulla alla discussione...per la legge di murphy 
va via corrente un millesimo prima di rimettere il verde al semaforo!
 
IMHO e soltanto IMHO ...a mia esperienza...il semaforo va benissimo in 
situazioni particolari....
ad esempio: programma di gestione carico ...o riempimento container...
ho necessità DI SEGNALARE a quelli che vengono DOPO di me che io sto 
caricando in questa piazzola TIR o sto riempiendo questo container e 
che nessuno può accedere a questa "entità operativa" finchè io non ho 
terminato...ma che possono scegliere un altro container o un altra 
piazzola di carico...oppure aspettare!
Le situazioni di blocco pessimistico attualmente si cerca di ridurle, 
lo ripeto, il più possibile!
 
-- 
----- Italliaaaaa 3227! -----
Please, visits website, but please visit Italy. We’re t’best country in 
the world in terms of: Culture, Landscapes, Arts, History, Cities, 
Villages, Beautiful countryside, seaside, mountains. That is Italy. You 
know, perhaps, you dreaming about. But please, visit or country. We 
will welcome you warmly and with a better organization.
(Francesco Rutelli Video a: 
http://www.martek.it/dblog/mostraVideo.asp?p=/public/dblog/Rutelli1.wmv
 
)
 
 

Marco ha detto questo giovedì :

Se il problema è solo il contatore, basta fare una insert con select 
max e un +1 alla fine.
In questo modo il select max e l'insert avverrà in maniera atomica.
 
Oppure se hai bisogno di visualizzare questo nuovo numero nel client 
PRIMA di confermare l'inserimento, basta fare un insert condizionato al 
where select max sia < del numero da inserire. Se l'insert fallisce 
significa che qualcuno si è inserito.
 
Comunque, se è una cosa critica, mi raccomando imposta un vincolo 
Unique sulla colonna.
 
Alberto
 
 

 lo ripeto, il piů possibile!
 
Sicuramente, con firebird nel caso posso usare i generatori, mi faccio la
select che me lo manda avanti in automatico, e sono sicuro che quel numero
č mio univoco, se la transazione non va a buon fine non torna indietro ma
non importa nella maggior parte dei casi. E non ho bisogno di bloccare
nulla.
 
In uso produttivo, posso dire che con diversi clienti, la gestione del
semaforo in quel modo comporta veramente pochi problemi, e al 99%
risolvibili con una gestione d'errore.
Ovviamente parliamo solo di inserimento dati nuovi, in caso di modifica
credo si debba capire un attimino prima come si vuol farlo funzionare.

 credo si debba capire un attimino prima come si vuol farlo funzionare.
 
Allora siamo tutti bischeri noi utenti 
ado.net
 che lavoriamo 
disconnessi e con concorrenza ottimistica? Anche ai tempi di vb6 la 
concorrenza pessimistica non l'ho mai usata...se non in progetti di 
test...giusto per vedere come funzionava!
 
-- 
----- Italliaaaaa 3227! -----
Anche sul trono più alto del mondo, si sta seduti sul proprio culo.
( Michel de Montaigne )