Newsgroup: it.comp.appl.access
Titolo: Incrementi non univoci, chiavi e altro

Vi ripropongo la situazione nella quale mi trovo perchè capire come uscirne
mi aiuterebbe non poco anche in altre situazioni...
In sintesi, in una tabella 'tblProtoc' registro almeno (gli altri campi per
ora non servono):
- un campo 'ID' contatore autoincrementante;
- un campo 'Anno' (Testo);
- un campo 'Progressivo' (Intero lungo).
Dalla maschera relativa, dei controlli rilevano il max dei progressivi
dell'anno e lo incrementano di 1. Il numero così ottenuto viene allegato in
una codifica etc.. e di questo chi se ne frega.
L'utente, quindi, non interagisce con il numero progressivo. Inoltre, in
ogni anno non ci può essere più volte lo stesso numero.
Il problema sorge nel momento in cui, da più FrontEnd, gli utenti ignari si
mettono a registrare le loro cose: è molto probabile infatti che vengano
registrati due 'Progressivo' uguali... d'altra parte non posso impostare
l'univocità di 'Progressivo' in tabella dal momento che tale univocità è
solamente relativa all'anno!
Mi avete consigliato di mettere una chiave di fianco ad 'Anno' e di fianco a
'Progressivo' ma... (SUSPENCE)... non funge!
Nella mia ignoranza penso che, nel momento dell'incremento del
'Progressivo', ci sia bisogno di una routine che apre il RecordSet, verifica
il numero maggiore e lo incrementa ma, ahimè, questo non so farlo...
Ptete aiutarmi voi?

 ha scritto nel messaggio
news:KefZ7.11473$%B.42...@twister2.libero.it...

Il problema presumo sorga quando il programma assegna un progressivo e il
record a cui è assegnato non è ancora salvato, per cui se un'altro utente,
prima che il primo abbia salvato il record sul quale sta lavorando, richiede
l'apertura di un nuovo record si trova con il medesimo numero.
Una soluzione sarebbe quella di assegnare il numero solo al momento del
salvataggio del record; quindi l'utente lavora sul record senza il numero e
solo al momento del salvataggio questo gli viene assegnato. Riduci di molto
la possibilità di aggiornamenti contemporanei.
Un altra soluzione  talvolta adottata è quella di una tabella con dei campi
che gestiscono dei contatori, in questo caso assegni il numero ad un record
leggendolo da questa tabella e immediatamente dopo lo aggiorni, in modo da
offrire il contatore aggiornato a chi ne fa una richiesta prima che il
precedente abbia completato le sue operazioni.
Alcuni inconvenienti sorgono se non puoi ammettere buchi nella numerazione.
ciao.


Ora provo secondo quanto mi hai indicato. non mi è molto chiara la tabella
coi contatori ma, come hai arguito, il probelma si propone poi se non sono
tollerati buchi nella numerazione.
Circa la mia idea di creare la routine che controllo il RS bla bla bla che
ne dici?
Come la metteresti su?
Saluti

 ha scritto nel messaggio
news:BOfZ7.11799$SE3.4...@twister1.libero.it...

Il problema non è come farlo, puoi usare un dmax o una query, ma quando
farlo.
a mio avviso va fatto sull'evento after insert della maschera.
in questo modo, l'utente lavora sul record senza il numero (o si potrebbe
visualizzargli quello probabile...) fino al momento in cui passa ad un'altro
record o chiude la maschera, fino a a quando cioè non conferma l'inserimento
del record.
potrebbe essere così:
sub form_afterinsert
    me.numero = ProxProg
end sub
function ProxProg () as long
    dim Rs as recordset, SQL as string
    SQL = "SELECT Max(tuaTabella.Progressivo) AS MaxProg FROM tuaTabella;"
    set rs = currentdb.openrecordset(sql)
    if nz(rs("MaxProg"),0) = 0 then
        ProxProg = 1
    else
        ProxProg = rs("MaxProg") + 1
    end if
    set rs = nothing
end function
ciao.


Sei molto gentile. Ora provo a lavorarci ma purtoppo non posso farlo
sull'AfterInsert perchč il valore va visualizzato ad uso dell'ignaro utente.
Ora vedo. Potrei farlo come hai detto tu ed eventualmente farlo seguire da
un msgbox riportante il codice creato (che comprende il 'Progressivo').
A tra poco


Ok, pare che funga... ora devo fare un pň di betatesting!
Grazie mille! Senza queste poche righe non avrei saputo come fare... Tra le
altre cose, odio l'SQL perchč non azzecco mai la sintassi corretta e mi si
pianta lě tutto