Newsgroup: it.comp.lang.visual-basic
Titolo: Perodic-Post: Concorrenza accesso dati...considerazioni personali ADO  vs ADO.net

Periodicamente se non scrico di questo argomento non sono
contento...il fatto è che "evolvo" nelle conoscenze di motori DB e
di .Net...e leggo...e mi confondo...e poi mi illumino....
insomma....meglio scrivere...e cercare un confronto con altri!
Il problema è sempre il solito ...un po più evoluto come scenario!
Stavolta abbiamo un motore DB serio davvero......e il nostro solo
client...che vi accede!
Nello specifico il motore db è postgresql...ma potrebbe essere SQL
server...o mysql....o Oracle.....non cambia nulla!
Trigger...stored...funzioni....stavolta ci sono!
Il client locale raccoglie i dati ....fornisce tutte le scorciatoie
del caso....aiuta le stampe.....il classico client di interfaccia!
Il solito classico caso:
Impiegato1 è sulla tabella "Anagrafica" al record 100 e sta cambiando
l'indirizzo del cliente
Impiegato2 è sulla tabella "Anagrafica" al record 100 e sta cambiando
il magazzino di destinazione merce principale
Ho usato un dataAdapter...e giustamente al primo update va bene
tutto...al secondo...prrrrrr "Violazione di concorrenza"
Quindi ADO.net + npgsql + postgresql....funziona come mamma microsoft
vuole con 
ado.net
!
In pratica dovrei interrogare il db per farmi dare il nome dell'utente
che blocca....mostrare una piccola form a es. Impiegato 2 e dirgli:
"Caro impiegato 2 ...impiegato 1 ha modificato questo....così e
così....che faccio? Modifico anche i tuoi dati...o esco del tutto???"
Almeno Microsoft nei manuali suggerisce ciò!
ORA
io guardo un po a giro che succede negli altri programmi commerciali:
In Banca...al comune....anche al punto blu dell'autostrada...almeno
nelle situazioni che ho potuto sbirciare io...molte operazioni sono
come dico io....l'impiegato compila un form anche GRANDE...arriva ad
aggiornare...e non va!
Quando gli va bene...gli compare un "sistema occupato attendere"(o
simile...ma non:" utente 1 ti blocca ")....quando va male sta zitto!
Il programma di contabilità di mia moglie nello studio dove lavora fa
ancora peggio....sta fermo....dando l'illusione di essere in
bomba...se qualcuno è sul solito record.
POI
ci sono quelli che usano l'approccio "server"....la solita tabellina
di chi blocca chi...o il solito flag....
quando accedi al record ti avverte che il record lo puoi
consultare ....ma se lo vuoi cambiare Impiegato1 no te lo permette....
però per questo approccio scordiamoci soluzioni canoniche
Microsoft...hai bisogno di una logica che testi una tabella o un flag
(vabbe una stored...ci sono...usiamole)...e poi trovare un entry point
prima che scatti il tale adapter....anzi a questo punto fanne a
meno...e lavora di Command che fai meno confusione (almeno per me)
Però...
Come fare il tutto il più possibile gradito all'utonto?
Se gli dico prima "sto record è bloccato....aspetta o fai
qualcos'altro"...sicuramente apprezzerà il fatto di non dover riempire
un form e poi farsi spernacchiare dalla concorrenza
Ma se ha da aggiornare una fattura con il corriere che aspetta....
....
Se due impiegati fanno un pesante dataentry...ad esempio degli annunci
pubblicitari di una agenzia..può darsi che ogni tanto debbano
aggiorare dei dati comuni di un cliente...non far accedere al cliente
perchè bloccato...rallenta psicologicamente il lavoro!
 E per finire....
io penso...che la soluzione...ti dico prima che il record non è
aggiornabile sarebbe perfetta....ma fonte di programmazione extra ad
josa
A) Flag o tabella (il male minore) sul server
B) Meccanismo server che monitorizzi l'update o l'insert o il delete
(ci sono anche questi traumatici eventi a rompere le palle) e
comunichi ai client connessi la nuova situazione (trigger e robe
varie)
C) Infrastruttura del client che recepisca le nuove impostazioni del
record
D) Eventuale sistema di "forzatura" del client (se ho da stampare la
fattura ed ho la pw giusta io ti butto fuori dalla modifica
dell'indirizzo...sopratutto ora che sei andato in pausa con la
maschera aperta!!!)
Però!!!... c'è da aggiungere parecchio!!!
Ora io mi domando e domando a voi....cui prodest???
La concorrenza se ne frega come ho visto....."record bloccato" se va
bene!
Un impiegato apprezzerà il sistema misto-server.....?
Vado incontro a casini? Imho si....pensiamo a 3 impiegati idioti con
la pw di sblocco...che si divertono a sbloccare record durante la
pausa caffè di altri!
Sono conscio che la solzione perfetta non esiste(vedo discussioni
online interminabili di veri e propri ingegneri di Sun Microsft IBM &
co.)...e per quanto ti sforzi...c'è sempre una segretaria -guru del
male- che troverà un metodo idiota per incasinare tutto....
Ma voi che ne pensate.....?
Che approccio hanno i vostri client?
"Aspetta e riprova!"?
o
"Bloccato...non ti provare nemmeno a guardarmi!"?
Thanks!

 "Bloccato...non ti provare nemmeno a guardarmi!"?
Troppi ... in un post :)
Comunque noi adottiamo un sistema molto rustico, ma non sembra dia problemi
(VB6).
Tabella sul DB che mi dice chi blocca chi. Infatti posso salvare solo uno
alla volta. Nel secondo in cui salvo gli altri stanno in loop. Appena
salvato sblocco l'accesso.
Con gestione errori ovviamente.
Inoltre c'� una tabella di Avviso che mi dice appena entro in quel record
che l'utente pippo ci sta lavorando. Se poi vuoi continuare cavoli tuoi.
Non avendo realt� immense, il tutto alla fine funziona.
Qui capita se il programma schianta rimanga il messaggio, ma si parla di 2
volte all'anno per cliente, e c'� la procedura per far sparire il
messaggio.
Certo gestire il tutto con gli strumenti adatti sarebbe meglio, ma se
funziona, raramente uno va a riscrivere cose del genere.

 Thanks!
Ciao, bel post ... un po' lungo (ma da Wodka meno di cos� non ci si pu� 
aspettare ;-) ma interessante.
I gestionali che sviluppo sia come libero professionista sia in azienda 
non portano a particolari problemi di concorrenza, quindi in caso di 
conflitto si avvisa l'utente che un altro generico utente ha modificato 
lo stesso record e per poter salvare � necessario ricaricare i dati (che 
sono sempre in quantit� non eccessiva).
Non usiamo alcuna tabella di lock.
Le soluzioni che per� si possono adottare sono tante e variegate e 
dipendono anche da come sono strutturati i dati, in ogni caso un po' di 
codice da scrivere c'� sempre.
Struttura dati permettendo, una soluzione flessibile potrebbe essere 
quella di suddividere i dati in classi di appartenenza, ad esempio 
anagrafica principale, dati bancari, etc etc, in modo che gli uni non 
implichino dirette conseguenze sugli altri, quindi se un utente modifica 
i primi e uno i secondi (magari) non � necessario bloccare ma 
semplicemente avvisare che sono intervenuti dei cambiamenti e agire di 
conseguenza.
Ma si potrebbe disquisire a lungo sul tema.
ciao
stefano

 funziona, raramente uno va a riscrivere cose del genere.
A me è capitato il classico caso:
bomba del classico emule (perchè in comune forse ci sarà la smart card
e le ACL e quant'altro...ma nel privato anche se sono in 2
impiegati....nei loro pc installano di tutto!).....pc
freezato...record bloccato....nessuno accedeva!
Chiamata....sbloccata...prevista ulteriore procedura  per forzare i
flag di sblocco!
Questa soluzione è comoda....ma deve essere a prova di bomba....a me
per ora non è riuscito renderla così davanti alla assolute invenzioni
di questi geni del male che si chiamano impiegati!

 di questi geni del male che si chiamano impiegati!
Io blocco solo nell'istante dell'insert into testa/righe.
E' difficile che si blocchi.
Comunque alla peggio sbloccano.
Per l'utente di una ditta normale direi che va bene, ed � di semplice
implementazione.
Per il resto quando invece apro un record non blocco nessuno ma do' solo un
messaggio che a quel record ci sta lavorando un altro.

 Ma si potrebbe disquisire a lungo sul tema.
Basterebbe anche salvarsi in memoria tutti i dati inziali, e lanciare
l'update solo per quei campi che sono cambiati dal caricamento.
Ma chi mi dice che poi vada sempre bene?
Carico un cliente c'� l'indirizzo giusto. Il PC-B carica il cliente e
cambia l'indirizzo.
A me mi dice: "scusa ho cambiato l'indirizzo, lo rimetti te com'era?"
Io non vedo modifiche fra la mia "copia" e i dati della maschera e non
aggiorno il campo, con il risultato che rimane un indirizzo sbagliato.
Quello che dici te dovrebbe essere fatto anche a livello di tabelle imho.
Spesso ho tabelle con decine di campi, suddividerle per categorie sarebbe
sicuramente meglio, certo complica leggermente la select di estrazione, ma
per il resto � molto pi� ottimizzato.