Newsgroup: it.comp.appl.access
Titolo: Numeri Documento raddoppiati in rete... e SOLO in rete!

Il mio è un problema classico e più volte dibattuto sul ng (ho consultato
Google e vedo che se ne parla, ma le soluzioni non mi sono chiare o non
funzionano).
In pratica, se più utenti inseriscono D.D.T. da postazioni di lavoro
diverse, capita spesso che le numerazioni progressive dei documenti
contengano doppioni!
La routine che assegna la numerazione esegue i seguenti passi:
1) Legge da una tabella "Causali" l'ultimo numero progressivo assegnato al
Documento.
2) Lo incrementa di uno.
3) Salva il nuovo progressivo sia nella tabella "Causali" che nell'apposito
campo della tabella di Testata.
Perchè aprendo più sessioni di lavoro sulla stessa macchina, simulando in
tal modo la concorrenza, funziona tutto benissimo?
Anche configurando la multiutenza con PCAnywhere o Terminal Server _anche in
tal caso girerà tutto in remoto su un unico PC_ non ci sono assolutamente
problemi.
Operando invece in file-sharing su rete windows il problema continua a
perseguitarmi: è come se l'utente numero due leggesse dalla tabella Causali
lo STESSO numero letto dall'utente arrivato prima ... SGRUNT!!
Ho provato con il metodo IDLE a forzare lo scaricamento di eventuali pagine
di dati in cache prima della routine sopracitata, ma non serve a nulla.
Voi come operate in questi casi?
Grazie, Ettore


Devi usare le transazioni, in modo che le tre operazioni diventino come un
unica operazione atomica e non possono essere interrotte da un accesso
simultaneo di un altro utente.
Antonio.

"Antonio Ganci" <


Anzitutto grazie per l'interessamento.
In questo caso però le transazioni sarebbero due (una per il salvataggio su
Causali, l'altra per la tabella di Testata Documento) o sbaglio?
Comunque preferirei utilizzare la transazione come ultima spiaggia: il BE
non è MSDE e i limiti delle transazioni con Jet sono sussurrati anche da
Microsoft.
Avevo avuto l'idea di bloccare in lettura il recordset Causali (in tal modo
il secondo utente resterebbe in attesa), ma poi all'atto pratico non ho
trovato il modo: sembra si possa fare solo con Recordsets di tipo tabella
... ne sai qualcosa?
Grazie, Ettore.

 Grazie, Ettore.
Lascia perdere il modo migliore è utilizzando le transazioni.
A quale DB Accedi?
Antonio.

 A quale DB Accedi?
A un normalissimo .mdb
Ancora grazie per i preziosi consigli:  Ettore.

 ha scritto nel messaggio
news:p1xp9.16107$RO.3...@twister1.libero.it...

Ciao Ettore, ti indico il metodo da me usato sperando possa esserti utile.
1) il campo numero DDT deve essere univoco o come nel tuo caso creare un
indice univoco Causale+Numero DDT,  - 2) Suggerire come numero DDT l'ultimo
+ 1 leggendolo dalla tabella DDT (vedi funzione DMAX()) - 3) alla scrittura
del record intercettare l'eventuale errore 3022 di chiave duplicata (evento
Form_Error) e in caso di errore rileggere il numero DDT con Dmax()
riassegnarlo al controllo e continuare con Response = DATA_ERRCONTINUE .
Ovviamente il numero DDT può non essere quello suggerito inizialmente in
maschera.
Ciao Giorgio.

 maschera.
I ng. sono proprio una miniera d'informazioni ed
esperienze :-)
Allora, ti dirò che avevo pensato a questa soluzione creando un
indice univoco multicampo Causale+Anno (o data) + N° DDT  dato che per
esigenze statistiche i DDT degli anni passati restano in archivio.
L'idea di gestire poi l'eventuale errore da indice duplicato e riprovare
fino al raggiungimento dell'obiettivo è di per sè vincente.
Anche perchè nel gestionale di cui parlo i numeri vengono generati su
"stampa definitiva" del documento e quindi questa soluzione sarebbe
trasparente all'utente.
Però ... ho voluto autocensurare questa soluzione _e riesumarla al limite se
non esistessero alternative_ per due ragioni:
-  Prevenire è meglio che curare (leggi: è un metodo un tantino rozzo)
- Creare indici multicampo in tabelle molto grosse come questa, rallenta le
prestazioni d'aggiornamento dati e gonfia le tabelle quindi va fatto solo in
caso di necessità.
Adesso voglio valutare bene tutte le soluzioni che mi vengono proposte e
scegliere la migliore dopo adeguato test.
Ciao e grazie.
Ettore


Visto che utilizzi un MDB non vedo quali perplessitą nutri per utilizzare le
transazioni, si tratta semplicemente di chiamare le funzioni BeginTrans e
Commit.
Prova e fammi sapere.
Saluti, Antonio.

 Prova e fammi sapere.
Utilizzo sempre la logica transazionale con SQL Server _e senza problemi_ ma
nel momento in cui mi sono arrischiato a farlo con JET, invece che ricorrere
alle classiche gestioni d'errori di multiutenza, ho avuto brutte sorprese.
Tutto bene in monoutenza o con un paio di PC in rete, ma con parecchi posti
in contemporanea succedevano casini e il RollBack non funzionava.
Poi sfogliando qualche libro MS sul JET ho trovato conferme più o meno
esplicite ai limite delle transazioni con JET: i temporanei
_comprensibilmente_ vengono gestiti a livello di Client e in tal modo non
può essere garantita la "duratura" della transazione.
Però il caso di cui stiamo trattando è più semplice e tutto sommato a me
interessa che funzioni l'atomicità della transazione, quindi proverò ...
incrociando le dita.
Ciao: Ettore