Newsgroup: it.comp.appl.access
Titolo: conflitto di assegnazione contatore

ho un BE con tabelle
ho un FE con maschere, in una di questa maschera, vi è un campo testo che
funge da contatore avendo come valore predefinito il seguente codice " 
=IIf(DCount("[numero_registro_int]";"determine2005")=0;"0000001";Format$(DMax("[numero_registro_int]";"determine2005")+1;"0000000"))
 ".
A volte, però, dato che il numero viene assegnato per prima, capita che un
utente mentre compila un record, alla fine gli viene detto che il numero
gia è stato assegnato perdendo quello che ha digitato.
Ora invece, vorrei inserire la formula succitata invece che su valore
predefinito, su clik del controllo assegnato al campo contatore mettendolo
come ultimo campo di inserimento.
Voi che dite andrebbe meglio o è solo una mia illusione?.
bye
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 bye
Ti dirò, io farei giusto il contrario... all'apertura della form
assegnerei il numero, salvando immediatamente dopo il record (e quindi
anche il numero assegnato), poi continuerei con l'nserimento degli altri
dati, ma in questo caso lo farei in un un record ormai caricato.
L'unico inconveniente starebbe nell'apertura contemporanea della form, ma
mi chiedo : quali e quanti utenti potranno mai aprire la form
contemporaneamente a un altri?... praticamente ne escludi quasi la
possibilità. 
-- 
Ciao
Pablitomf (Maurizio Facciuti)
------------------------------
http://www.sitocomune.com/
http://www.accessgroup.it/
------------------------------


 bye
Calcola il nuovo contatore ed assegnalo al controllo nella routine evento
before_update della maschera, ma solo per i nuovi record (newrecord=true).
Namor
-- 
namor at inwind punto it


 bye
Con Access(JET) come Motore di Database questo inconveniente è
spesso rilevabile.
L'errore più grosso è quello di generare ia Primary Key(come nel tuo caso)
come prima cosa o come Default Value.
1)Nel caso di generazione su NewRecord, il record viene Salvato, ma
se l'utente dovesse cancellarlo in seguito ad errore avresti la certezza
che un'altro utente avrebbe già un progressivo successivo con la conseguenza
di un BUCO dopo la cancellazione.
Questo non sempre è accettabile, e personalmente non pulito.
2)Generazione su Default Value
Questo non salverebbe il Record, ma la possibilità che al salvataggio un
collega abbia già salvato lo stessoprogressivo è grande, e cresce con il
crescere degli utenti.
La cosa più corretta è non generare la PrimaryKey su evento
Before_Update di Maschera.
In questo modo viene generato il codice solo nel momento in cui si salva e
la contemporaneità viene ridotta al minimo.
Ciao
@ALex
@Alex (Alessandro Baraldi)
---------------------------------------------------------------------------
http://www.sitocomune.com/
http://www.mantuanet.it/alessandro.baraldi/
---------------------------------------------------------------------------

 Before_Update di Maschera.
???
C'è un 'non' di troppo?
Ciao.
Namor
-- 
namor at inwind punto it
questo articolo e` stato inviato via web dal servizio gratuito 


 @Alex (Alessandro Baraldi)
quel "non" mi preoccupa! è stato messo giusto o per errore?
se è giusto, quale è la soluzione migliore?
se è stato messo per errore, seguirò il consiglio.


 ---------------------------------------------------------------------------
in questo caso, però mi viene un dubbio, e cioè che l'utente che registra
i dati non vedrà il numero assegnato perche passerebbe automaticamente al
record successivo o sbaglio? a me invece serve che il numero deve essere
visto per segnarlo come protocollo del documento (record) memorizzato.


 possibilità. 
io non posso fare così in quanto ho delle colleghe, che inseriscono i
dati,  molto ma molto ignoranti e menefreghiste, che spesso, aprono la
maschera, nuovo record, e se ne vanno a papereggiare con altre colleghe,
tenendo impegnato il numero a vuoto. Figurati che per ora ho fatto in modo
che la maschera si chiuda in 3 minuti se non viene utilizzata!, ma non la
considero la soluzione ideale!.


Haaaaaaaa!!!
ERRORE...!
Mi è scappato, concordo con Marco(Namor) ovviamente
ma come mai quel NON sia finito nella frase è cosa da
capire....!
Il senso delle considerazioni non lasciava dubbi...., stò
invecchiando ò è l'artrosi...!
Quì pro quò a parte spero che il concetto sia chiaro, anche
se Marco stesso ha dato la stessa dritta.
Ciao
-- 


 invecchiando ò è l'artrosi...!
Bisogna pensare in grande!
Perche' "NON" tutte e due ? ;<)
--
a.cara

 ha scritto nel messaggio
news:3484uhF...@individual.net...

Ma come faccio a pensare in grande entrambi i difetti
tendono a rimpicciolire, ingobbire, rattrappire.........!
Si vede che sei ancora un ragazzino, ti permetti di schernimi
su queste cose he...!(Quando avrai 70 anni ed io sarò tornato a 25 ne
riparleremo)


 ha scritto nel messaggio
news:crgn4l$ivd$1...@news.newsland.it...

se invece lo assegni con l'evento "DOPO AGGIORNAMENTO" della maschera???
David

 David
Spesso(quasi Sempre) è una PrimariKey, come potresti generarla DOPO
AGGIORNAMENTO....???
IMPOSSIBILE e concettualmente assurdo.


 visto per segnarlo come protocollo del documento (record) memorizzato.
L'applicazione protocollo che usiamo in ufficio, scritta da non so chi in
non so che linguaggio, con back-end Oracle, fa proprio così. Registri tutti
i dati, li ricontrolli, e quando confermi ti dà una finestra popup con il
numero assegnato.
Segno che la generazione del contatore immediatamente prima del salvataggio
del nuovo record è un sistema (forse il più efficiente in questi casi)
utilizzato non solo in access ma anche in altri ambienti.
Se non ti va il popup puoi sempre fare in modo che dopo il salvataggio la
maschera resti sul record appena salvato, consentendo di leggere il numero.
Namor

 Namor
Spesso le applicazioni lavorano con Form non associate checchè molti
soloni,  ne dicano, quando si tratta di sicurezza dei dati....!
Sul NG di access IT di MS tempo fà Giorgio Rancati ha dato una
spiegazione di come un server SQL gestisce al meglio questi problemi.
Ovvio che non fà da solo, il Server fà quanto gi si dice di fare, ma
ha a disposizione le SP che possono elaborare tutto quello che con Access
saresti costretto a fare lato Client nel caso di una ID non counter ma
AlfaNumerico
Con ID intendo la PrimaryKey della tabella...!
Per access invece tutti i testi di un certo livello lo danno per scontato
che
questa sia la soluzione più opportuna esponendolo come metodo corrente
alternativo al Counter, che non sempre serve.
Molti però ho visto che per non avere scocciature usano un counter sempre
anche quando il dato Univoco è e deve essere Univoco di suo:
Codice Fiscale
Partita Iva
N° Fattura
N° DDT
Ecc......!!
Ciao
-- 


 IMPOSSIBILE e concettualmente assurdo.
potrei anche non farla essere una primarikey e creare un altro campo
contatore invisibile.


 contatore invisibile.
Si può fare tutto nella vita anche darsi botte in testa....!
Non crearti un altro problema dove non dovrebbe esserci.
Il mio è un consiglio.
Spesso questi codici hanno tutte le caratteristiche delle PrimariKey,
quindi trovo inutile e poco sensato rinunciare alla PK autocostruita
solo per avere la comodità del Counter.
Seguendo questa logica poi ti tocca girare per le relazioni con un ID
quando sai benissimo che la PK reale è il tuo codice.
Sono scelte dettate spesso dalla capacità tecnica, oppure dalla fretta.
Ciao
