Newsgroup: it.comp.appl.access
Titolo: Per numero progresivo documento, prendere da valore memorizzato, oppure verificare 'al volo' ?

Una curiosita' che mi sono sempre ripromesso di chiarire e' la 
numerazione di un documento che debba avere una numerazione progressiva
Supponiamo di parlare di fatture vendita, supponiamo che il 'numero 
documento' sia realmente numerico (e non alfanumerico), e supponiamo che 
si desideri mantenere una numerazione su base annua, che parta da 1 e 
aumenti di 1 per ogni documento creato
Bon
 
METODO A - LETTURA 'AL VOLO'
Vedo che alcuni gestionali usano proporre il nuovo numero documento come 
uno in piu' dell'ultimo, quindi se cancelli gli ultim 4, e ne crei uno 
nuovo, il numero corrisponde sempre a quello corretto
 
METODO B - MANTENIMENTO Di UN CONTATORE
Altri sistemi usano mantenere una memoria permanente dell'ultimo numero 
(o del primo da usare) usato, un 'contatore' che indica l'ultimo numero 
di fattura creata, se sei arrivato al documento 100, ne cancelli 4 e ne 
crei uno nuovo, il sistema proporra' il numero 101, perche' si basa 
appunto sul 'contatore documenti creati'
 
Sostanzialmente si arriva allo stesso obiettivo, per strade diverse
Non riesco bene ad apprezzare se uno dei due possa prevalere SEMPRE 
sull'altro e quindi sia preferibile rispetto all'altro
Voi come fate?
Andate 'al volo' o usate un contatore?
E ciao


fermando la riflessione SOLO al nuovo inserimento
(SOLA aggiunta record), e avendo lo scopo di "non fare buchi":
 
penso proprio che, in multiutenza,
occorre registrare con Dmax +1 all'evento BeforeUpdate
(contando sul fatto che questo evento "blocchi a sè" le registrazioni)
 
poichè Access, con l'autonumber progressivo,
"smazza" tanti numeri nuovi quante sono gli ingressi "simultanei"
(simultanei= NON completati) in registrazione nuove righe sulla tabella
 
e qui allora non è neppure necessario cancellare, basta abbandonare,
per interrompere la sequenza ordinale in aggiunta record.
 
 


Quindi secondo te lettura/scrittura 'al volo'
Si, non parlavo dell'autonumber di Access
La domanda era su db generico, per capire la logica da seguire, se con 
contatore permanente oppure 'al volo'
 
 
 

 contatore permanente oppure 'al volo'
 
utilizzo solo Access,
leggo però che i sistemi SQL Server mantengono (garantiscono ?) la progressione di registrazione (numero inserito al momento della registrazione)
 
e allora, per questo scopo, la risposta (disponibile) del sistema 
determina l'approccio pratico 


io lo calcolo al volo.
fin che la fattura è in fase di compilazione ha numero 0
nel momento in cui l'utente la conferma, calcolo il max numero +1 
dell'anno in corso e per relativo sezionale.
 
questo non mi ha mai causato problemi in multiutenza (inizio a fare una 
fattura dal pcA e dal PC B iniziano a farne una nuova dopo di me e la 
confermano per prima)
 
ciao
BFS
 
 
 
 
 
 
 
---
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com
 
 


Salvi il tutto, e numeri documento, alla fine
Cosa cambia rispetto alla creazione fattura (e numero) all'inizio?
In multiutenza, il numero sarebbe gia' occupato e l'operatore ad altra 
postazione creerebbe comunque un numero diverso, superiore
Il problema dei buchi c'e' comunque (sia che memorizzi a fine 
compilazione fattura, sia che memorizzi ad inizio creazione fattura), se 
sei arrivato alla 100 e cancelli la 90, il buco resta e tocca riempirlo 
a mano
 
 
 
 

Se parliamo di ID, l'autonumber va benissimo. Lo usa il db, non l'utente. La numerazione dei documenti va sempre gestita a mano secondo me, per garantire la correttezza e poter procedere ai cambiamenti, nel caso servano. Ddt 100, cancelli il 99, invece del buco, riemetti quello che era 100, ora 99. Se fosse una pk auguri....

 
 
Cosa vuol dire '..riemetti quello che era 100...' ?
Il 100, se e' stato emesso, resta la' senza toccarlo
Il prossimo che emetterai sara' il 101 ed a manina andrai a cambiarlo in 
99, conguenza data permettendo
Ho capito bene?
 
 

Si certo, data permettendo. Volevo dire che il numero lo puoi anche scegliere. Ipoteticamente potresti anche avere procedure che spostano e rinumerano gruppi di doc. Chiaro che bisogna essere nel legale..... Anche se mi capita che il cliente X mi chieda di rifare una fattura differita magari di 10, 15 gg fa, ovviamente ne ho altre dopo. È comodo, in questo caso, poter scegliere il progressivo.


assegno alla fine il numero proprio per evitare buchi
es. ultima fattura n° 100
 
con il mio sistema:
pc A alle 9.00 inizia a compilarne una
pc B alle 9.01 inizia a compilarne unaltra
 
PC B salva...per primo e prende quindi il n° 101
PC A decide che sta sbagliando e annulla tutto...non si creano buchi 
nella numerazione
 
con il sistema di assegnare subito il numero in fase di creazione:
pc A alle 9.00 inizia a compilarne una prende numero 101
pc B alle 9.01 inizia a compilarne unaltra e prende numero 102
 
 
PC A decide che sta sbagliando e annulla tutto...si crea il buco 101
 
Il problema del buco quando si cancella una fattura gia salvata c'è 
sempre e va gestisto a posteriori, finche non ho contabilizzato le 
fatture, operazione che viene fatta a discrezione dell'utente, posso 
intervenire sui numeri per modificarli
 
ma con il mio sistema sono sicuro che se ho 5 pc che fatturano 
contemporaneamente non avrò mai buchi durante la normale attività di 
compilazione, salvataggio. Il primo che salva prende il primo numero 
disponibile



I buchi, durante la creazione fattura, non ci sono ne' assegnando la 
numerazione dopo (modalita' 1) ne' prima (modalita' 2), se tutto procede 
normalmente, e quindi ogni operatore completa il proprio documento
 
La casistica dell'operatore che a meta' della creazione documento decide 
di rinunciarvi (nella modalita' 2), e' esattamente la stessa cosa di un 
operatore che desideri cancellare un documento appena creato (nella 
modalita' 1)
Se qualcun altro ha gia' fatto dei documenti successivi, il buco resta
 
E bisogna recuperarlo a manina