Newsgroup: it.comp.appl.access
Titolo: Come trattare le concorrenze?

Ciao a tutti
Come da topic: in un database multiutente (fe-be) come trattare al
meglio le concorrenze/transazioni? Esitono tecniche, accorgimenti,
controlli pensati allo scopo? Qualche riferimento? Libri, risorse web,
esempi?
Lo chiedo perche' fino ad ora mi sono sempre arrangiato contando sul
fatto che l'inserimento contemporaneo della stessa tupla in una tabella
da parte di piu' utenti sia piuttosto improbabile; questo pero' puo'
andare bene per soluzioni artigianali: volendo affinare la tecnica da
dove posso cominciare?
grazie
-Z-

Zarquon ha scritto:

In multiutenza nulla è improbabile.......gente che ti lascia l'inserimento a metà x mezzora ti blocca tutto il db.....cmq con qualche accorgimento non dovresti avere problemi. Access già da solo gestisce gli accessi alla stessa tabella da parte di + utenti, ma se vuoi controllare tu stesso devi usare qualche trucchetto. Personalmente io uso questa tecnica: ho tutte le maschere in visualizzazione senza possibilità di modifica (snapshot o recordset readonly) e sia per inserimenti che modifiche apro un'ulteriore form e magari prendo i dati (parlando di modifica) dalla maschera di sola lettura. Modifico o inserisco quello che voglio e, solo adesso, creo ID (se serve) e scrivo sulla tabella (che quindi viene 'aperta' solo in questo momento). Poi puoi usare dei lock ad hoc subito prima della scrittura e unlock subito dopo (ricordati xò di togliere il lock in caso di errore se non ti rimane la tabella bloccata!!!!). La tecnica esposta (quella dei semafori) funziona molto bene (anche contro le corruzioni del db) anche se non rispetta l'atomicità (che però ancora non ho capito bene cosa significhi....ma mi dicono così...). Spero ti sia utile
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it

 cosa significhi....ma mi dicono così...). Spero ti sia utile
Per la mia breve esperienza, lockare righe o tabelle e' la peggior cosa che 
si possa fare
E piu' il umero utenti aumenta, piu' si avverte l'importanza del "lasciare 
sempre libero" il db
Per evitare l'inserimento di tuple doppie credo che il miglior consiglio ti 
si possa dare e' di affidarsi alle risposte del motore db
Se devi inserire una fattura nuova e l'ultima e' la numero 28, tenti di 
inserire la 29 ed attendi risposta dal database
Se va tutto bene vuol dire che sei arrivato prima tu ad inserire la 29-esima 
altrimenti la segnalazione di indice duplicato ti avvertira' che qualcuno e' 
arrivato prima di te
E quindi dovrai rileggere l'ultimo numero fattura esistente e ritentare 
l'inserimento di un numero in piu' dell'ultima, e via di questo passo
Discorso diverso per le transazioni, le sequenze di operazioni che devono 
essere indivisibili, o vengono eseguite tutte oppure devono essere scartate 
nella loro interezza
L'esempio tipico e' dell'accredito di un conto corrente bancario, che dovra' 
essere indissolubilmente legato all'addebito su qualche altro conto
E allora bisogna verificare il db che usi, come permette di definire le 
transazioni
Se usi Access e db su file mdb, vedi le istruzioni 
BeginTrans/CommitTrans/Rollback, tutte le istruzioni all'interno di una 
Begintrans - CommitTrans, meglio se di uno stesso Workspace, vengono 
eseguite tutte insieme o scartate tutte
Ciao
RobertoA

"Zarquon" <> Ciao a tutti

Oltre ai suggerimenti di RobertoA, ti consiglio d'utilizzare il blocco 
ottimistico nelle Forms: è molto veloce in concorrenza.
Ah, nei processi d'aggiornamento Batch scritti a codice ricordati di gestire 
con opportune On Error gli errori di concorrenza (3197 in particolare).
Ciao... 

RobertoA ha scritto:

Concordo che è meglio lasciare 'libero' il db il + possibile. Ma con blocco/sblocco solo nella fase di scrittura (non nella compilazione) il freno è millimetrico e la possibilità di scritture contemporanee è veramente minima.....parlano di Access, ovviamente. E' anche vero che la tecnica dei semafori è magari obsoleta, ma in pratica prende l'incarico di fare quello che fa Access quando scrive su una tabella....blocca, scrive, sblocca....(semplificando molto ovviamente). Se poi fai tutto in form non associate e rendi effettivi inserimenti o modifiche in un unica botta alla fine di tutto.....Se due utenti aprono lo stesso record in una maschera associata e dynaset anche solo per visualizzarlo, io ho avuto dei problemi......se poi, x es, fai una ricerca su 2 client (magari la stessa ricerca) e visualizzi su maschere continue, anche solo la concorrenza dello scorrimento record incasina i puntatori.....almeno a me....così ho preso l'abitudine di lavorare con forms nn associate (tipo modalità disconnessa) e 'governare' inserimenti e modifiche...e ho risolto un mare di problemi, anche dei miei utenti che non capivano la classica finestrella 'copia-sovrascrivi-cancella' della concorrenza di scrittura. Ovviamente è un palliativo...



La classica finestra "copia-sovrascrivi-cancella" appare una volta ogni 
morte di vescovo (e spesso nemmeno quella): non è assolutamente un 
*problema*
Inoltre, se ben ricordo, puoi gestire quella situazione utilizzando l'evento 
"su errore" della Form.
Ciao: Oscar 

 Ovviamente è un palliativo...
------------------------------------------------------------
"..parlano di Access, ovviamente.."
Amhh e allora ditelo
Dal mio punto di vista, su file mdb ci va un utente e basta, tassativo, 
meglio ancora se non ci va neanche quello
Se sono due o piu' utenti bisogna usare un 'mistiero' che permetta di 
rendere sicura la memorizzazione dei dati, anche se sembra che esistano 
diversi sistemi basati su file mdb che lavorano tranquillamente senza 
problemi in multiutenza
Non possiamo affidarci alla speranza che vada sempre tutto bene
"..la possibilita' di scritture contemporanee e' davvero minima.."
eeeeeh no, qua non sono d'accordo, la possibilita' di scritture 
contemporanee non deve proprio esistere e questa sicurezza te la puo' dare 
solamente un gestore db serio
Per lo scorrimento maschere continue, da piu' postazioni, non ho capito a 
che problema ti riferisci
Comunque, in generale, sono dell'opinione che una procedura conviene farla 
bene fin da subito, perche' altrimenti, anche se 'funzionicchia', non ci 
tornerai mai piu' a rivederla e migliorarla, perche' ci saranno altre cose 
da fare, meglio spenderci un'altra ora di lavoro e poi non pensarci piu' che 
temere perennemente che qualcosa si scassi per colpa di quella routine messa 
in piedi in quattro e quattro'otto
Ciao
RobertoA


Scusami, ma queste non le avevo lette.
Stai esponendo casistiche alle quali non crederei nemmeno se le vedessi.
Access, fondamentalmente, in multiutenza lavora benissimo e con pochi 
accorgimenti.
Chi ha problemi legati a volumi di dati sostanziosi o multiutenze ampie 
utilizzarą altro BE, ma questo č un altro discorso.
Comunque ti invito a fare degli esempi concreti (usa pure Northwind) che ci 
permettano di riprodurre in rete i presunti problemi che hai esposto.
Ciao: Oscar 


Allora sono sfortunato (oltre che inesperto)!!!!! :-)
Intanto mi adopererò x l'esempio concreto...
Cmq, x chiarire, sappiamo tutti che per volumi sostanzioni di dati (e per essere sinceri anche per altro) meglio SQL server o qualche altro motore db, ma, parlando di Access, io ho avuto quest'esperienza (oltretutto discussa su questo NG): BE su 'server' (x modo di dire, ossia PC un po' + potente degli altri) e 2 client. Apro il programma, lancio la stessa ricerca sui 2 client, me la mostrano, poi scorro i record E BASTA. Causa anche mia inesperienza lo scorrimento era drammatico......MA:
-la maschera era dynaset
-assegnavo la stringa SQL in apertura e visualizzavo
-la tabella su cui effettuo la ricerca contiene circa 450.000 record con circa 40 campi x record (gli indici erano giusti....almeno quelli)
Come ho risolto
-ovviamente la tabellona è rimasta quella.....
-maschera=snapshot
-non lavorando + in memoria ma creandomi una tabella di appoggio LOCALE dove scrivo i risultati della ricerca
Le scritture contemporanee SONO a mio parere una rarità (specialmente se le impedisci da codice.... :-) ), ma visto che mr A le gestisce non danno, come dite voi, problemi eccessivi. 
E' proprio per non fare routine 'arraffazzonate' che mi sono permesso di esporre la mia soluzione. Il commento sulla possibilità che una determinata casistica si possa o meno presentare, è superfluo....se si può presentare bisogna gestirla (IMHO)!!!!!Se no son guai...
La multiutenza di Access credo sia stata sviscerata anche su questo NG in maniera ampia ed approfondita (cosa della quale ringrazio sentitamente). Vien da se che Access funziona bene SOLO fin dove può...e mi sembra anche giusto....se uno deve gestire un applicativo con 50 postazioni contemporanee forse farebbe meglio a considerare l'idea di non usare Access (anche se sembra che ci sia letteratura in merito....). Forse a volte non vale neanche la pena (se non come sfida personale) intestardirsi a realizzare una data cosa utilizzando strumenti non adeguati....Detto questo, senza ovviamente nemmeno l'ombra di una polemica, sottolineo che Access x me è mirabolante!!!!!


 a realizzare una data cosa utilizzando strumenti non adeguati....
???
Non capisco le limitazioni a cui ti riferisci: ho lavorato un lustro della 
mia vita in un ente (pubblico) in cui le applicazioni sviluppate in Access 
erano condivise sempre da decine di clients.
La base dati non era un .mdb (usavamo SQL Server 7.0/2000), ma che importa? 
Qui si parla di Access principalmente come RAD per creare applicazioni.
Ciao: Oscar

Access funziona bene SOLO fin dove può...e mi sembra anche giusto....se uno 
deve gestire un applicativo con 50 postazioni contemporanee forse farebbe 
meglio a considerare l'idea di non usare Access (anche se sembra che ci sia 
letteratura in merito....). Forse a volte non vale neanche la pena (se non 
come sfida personale)
--------------------------------------------------------------------------
Certo che potressimo usare qualcos'altro
Bastesse che trovessimo un altro ambiente milliore
E tutti passeressimo a quest'ultimo
Ciao
RobertoA


Colpa mia, Oscar.....mi sono espresso male. Io parlavo di Access/jet. Versione 2003 SP3 + hotfix (dovrei essere a posto!!!!),si, il blocco era ottimistico, no, non ci penso neppure a caricare 450.000 records in una forms!!!!! Dicevo solo che la banca dati su cui svolgere il lavoro ha quelle dimensioni....Rispondo anche a RobertoA: ciao Omonimo, non sto assolutamente denigrando Access (non sia mai!!!!!). Parlando di Access/Jet dico solo che nella pianificazione del lavoro, bisogna tenere conto dei limiti dello strumento che uno decide di usare......Io nn sono un programmatore (faccio il libraio) e conosco solo Access (a parte ASP e ho appena cominciato nel mondo .net) e nella mia piccola esperienza Access mi ha risolto un mare di problemi. Solo che 'forse' sono arrivato al punto che Jet (e solo lui beniteso) non ce la fa +.....Infatti, nella nuova versione su SQL server express 2005 (in fase di test) non ho dovuto usare questi' trucchetti' per far girare tutto velocemente in multiutenza, ne semafori, ne tabelle locali di passaggio, ne nulla. Ma, si sa....il primo amore č duro a morire.....



Mhmm: sarà così, ma insisto nel dirti che non credo affatto esistano 
problemi del genere.
Anche se i records fossero milioni nel DataBase.
Comunque comportamenti del genere non sussistono con le versioni precedenti: 
che ha di speciale la 2003?
Avevi attivato l'autocorrect e il Front-End era in formato .MDB?
Ciao: Oscar

Oscar Manfredini ha scritto:

Niente Autocorrect e si, l'FE è  .mdb (ma a parte la compilazione del codice, che differenza fa?). Vien da se che se avessi fatto errori di struttura o programmazione, e qua si trovasse il bandolo della matassa, mi va + che bene migliorare l'applicazione! Preferisco aver sbagliato io piuttosto che credere erroneamente di aver toccato il limite di jet......intanto grazie per il confronto



Beh, per capire se la struttura dell'applicativo sia migliorabile (e il 
problema sussista) si dovrebbero fare dei test reali con quella base dati...
Ciao: Oscar 

> Niente Autocorrect e si, l'FE č  .mdb (ma a parte la compilazione del 

Se vuoi, e non sono troppo invadente, posso mandarti un link dove scaricare tutto l'applicativo. 
O fartela 'vedere/provare' in terminal services (anche se cosě vedi sono come funziona....ovviamente!!!), dimmi tu. Sempre disponibile a imparare cose nuove (e migliori sopratutto)
