Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Ricavare il contatore di un campo in VBA

61 views
Skip to first unread message

Pisinho

unread,
Nov 18, 2009, 11:36:23 AM11/18/09
to
Salve,
in Access 2007 e VBA avrei la necessita di ricavarmi il prossimo contatore
che verr� utilizzato in un campo di tipo contatore, questo perch� potrei
avere un ID=5 ma il record
con ID=6 � stato eliminato.

Devo farmi un record d'appoggio in un'altra tabella o esiste un modo per
ricavarlo ?

Grazie mille.

Pablitomf (da casa)

unread,
Nov 18, 2009, 1:40:47 PM11/18/09
to

DMax("[ID]";"[TuaTabella]")+1

ma se il tuo campo ID � stato cancellato, anche se ultimo, l'inserimento
successivo risentir� comunque di questa cancellazione... per cui se il tuo
ultimo ID � 5 perch� � stato cancellato il 6, il prossimo ID pure se la
formula che ti ho suggerito ti restituisce 6, in realt� sar� 7...

per reintegrare gli ID persi (quelli cancellati appunto), devi usare
altro... a riguardo ho messo on-line un demo qu�
http://www.accessgroup.it/HomeArgomenti.asp?ID=62&Oggetto2=Recuperare%20e%20reintegrare%20ID%20persi


CinziaPagani

unread,
Nov 18, 2009, 4:12:14 PM11/18/09
to

"Pisinho" <pis...@gmail.com> ha scritto nel messaggio
news:4b04...@news.x-privat.org...
Ciao Pisinho,
perch� ti serve saperlo prima di inserire il record?
Qui trovi un articolo su come usare @@identity in un DB Access
http://www.riolab.org/index.php?option=com_content&view=article&id=212

--
Cinzia [Office Access MVP]
_______________________
www.riolab.org
http://accessdaziacin.spaces.live.com
----------------------------------------


Pisinho

unread,
Nov 19, 2009, 2:49:49 AM11/19/09
to

> perch� ti serve saperlo prima di inserire il record?
> Qui trovi un articolo su come usare @@identity in un DB Access
> http://www.riolab.org/index.php?option=com_content&view=article&id=212
>
>

Perch� all'inetrno della Form ho altre tabelle che vengono popolate prima di
salvare quella principale e dato che dopo sono relazionate con l'ID
sapendolo prima ogni record lo posso gi� collegare.
Lo so potrei utilizzare un altro campo NON contatore ma ormai ho tutto fatto
cos� e volevo trovare una soluzione.

Ora mi guardo i llink che mi hai fornito.

Grazie mille.

Marco Pizzamiglio

unread,
Nov 19, 2009, 3:07:57 AM11/19/09
to
Pisinho ha scritto:


Secondo me dovresti cambiare il tuo approccio al problema, non si lavora
cos� con i database, ti complichi la vita inutilmente.
E' strano che le tabelle secondarie vengano popolate prima della
principale. Sicuramente non hai messo l'integrit� referenziale sulla
relazione.
Chiaro, se � un caso particolare e motivato e non hai alternative vai
avanti cos�.
Ciao.
-Marco-

--

questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ab...@newsland.it


MA

unread,
Nov 19, 2009, 3:10:39 AM11/19/09
to

"Pisinho" <pis...@gmail.com> ha scritto nel messaggio
news:4b04...@news.x-privat.org...
>
>
E' un'architettura un p� fragile.
Se tu riesci a caire quale sar� il tuo prossimo id
lo usi nelle altre tabelle come chiave esterna,
poi finalmente valorizzi il record
ma alla fine devi cancellarlo?

Altro scatto di contatore, query di update delle chiavi esterne etc...??
Ho un p� di orticaria con questa soluzione

Marco Pizzamiglio

unread,
Nov 19, 2009, 3:20:44 AM11/19/09
to
MA ha scritto:

> Altro scatto di contatore, query di update delle chiavi esterne etc...??
> Ho un p� di orticaria con questa soluzione

Prova ad andare in farmacia e dire "ho un'orticaria da db mal progettato",
sicuramente avranno qualche pomata adatta, ihihihih!!!

Pisinho

unread,
Nov 19, 2009, 3:47:50 AM11/19/09
to

>
> Prova ad andare in farmacia e dire "ho un'orticaria da db mal progettato",
> sicuramente avranno qualche pomata adatta, ihihihih!!!
> Ciao.
> -Marco-
>

Avete tutti ragione ma le tabelle che vengono popolate prima mi servono per
tener traccia di COSTI e RICAVI di una eventuale vendita e che per motivi
pratici di report lascio su tabelle separate da quella che mi contiene tutte
le Pratiche,
� per questo che vorrei sapere prima il prossimo ID che verr� salvato in
modo da poterlo gi� immettere in queste tabelle.

Giriamo allora una domanda, facciamo conto che ho una pratica all'interno
l'operatore deve immettere dei costi e dei ricavi variabili , a priori non
posso sapere quanti sono i costi e di conseguenza i ricavi anche se un MAX
lo sappiamo dalle esperienze,
o faccio un'unica tabella chiamata Pratica con i normali dati ed in pi� 10
Campi Costi e 10 Campi ricavi e salvo tutto alla fine oppure non mi viene in
mente niente.

Avete da darmi qualche dritta o esempio da guardare?

Grazie comunque a tutti per le risposte.

SAluti

Paolo opg

unread,
Nov 19, 2009, 4:04:26 AM11/19/09
to
"Pisinho" <pis...@gmail.com> wrote in news:4b04...@news.x-privat.org:

lo puoi gia' collegare con cosa?
con un record che non esiste ancora?

e se 'colleghi' le secondarie ma poi per qualsiasi motivo (crash di
sistema, tanto per dirne una) non riesci a inserire il master?

database con cadaveri a gogo...
manutenzione da incubo...

due utenti in azione nello stesso momento, ottengono lo stesso id
'temporaneo', inseriscono nelle secondarie con lo stesso id, e poi chi
inserisce il master con quell'id?
e gli insert fatti dall'altro?
aggiorni tutte le secondarie?
e come fai, dato che lo stesso id e' stato utilizzato per gli inserimenti
di due utenti diversi?

con qualche accrocchio e controlli vari magari ce la fai, se fai le cose
per bene, lo fai in automatico, senza impazzire e a zero rischi.

inserire prima il master non credo nemmeno sia una 'best practice', tanto
e' scontato che si parte dalle fondazioni, a costruire, e non dal
tetto...


la soluzione e' rifare il giro come si deve.
:-/

--
Paolo opg

BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

Pisinho

unread,
Nov 19, 2009, 4:16:34 AM11/19/09
to

>>
>
> lo puoi gia' collegare con cosa?
> con un record che non esiste ancora?
>
> e se 'colleghi' le secondarie ma poi per qualsiasi motivo (crash di
> sistema, tanto per dirne una) non riesci a inserire il master?
>
> database con cadaveri a gogo...
> manutenzione da incubo...
>


Come detto prima avete ragione per tutti questi motivi, avevo pensato alla
creazione di un GUID da salvare nelle tabelle e collegarle con questo non
pi� con l'ID contatore.

Grazie mille, per tutto.

Marco Pizzamiglio

unread,
Nov 19, 2009, 4:25:33 AM11/19/09
to
Pisinho ha scritto:


Ci sono diverse possibili soluzioni.
Sconsiglio i 10 campi costi + 10 ricavi, se te ne servono di meno � uno
spreco, se te ne servono di pi� devi modificare la struttura della
tabella. Meglio usare una tabella a parte (una sola, non due) in cui
metterai i costi con segno negativo e i ricavi positivi, cos� poi stai un
attimo a fare i totali.
Puoi caricare comunque il record relativo alla pratica e poi i relativi
costi e ricavi. Se poi dall'analisi costi/ricavi decidi di non aprire la
pratica basta un flag per marcarla come "eliminata".

Paolo opg

unread,
Nov 19, 2009, 5:23:58 AM11/19/09
to
"Pisinho" <pis...@gmail.com> wrote in
news:4b05063f$1...@news.x-privat.org:

>
>
> Avete tutti ragione ma le tabelle che vengono popolate prima mi
> servono per tener traccia di COSTI e RICAVI di una eventuale vendita e
> che per motivi pratici di report lascio su tabelle separate da quella
> che mi contiene tutte le Pratiche,
> � per questo che vorrei sapere prima il prossimo ID che verr� salvato
> in modo da poterlo gi� immettere in queste tabelle.
>
> Giriamo allora una domanda, facciamo conto che ho una pratica
> all'interno l'operatore deve immettere dei costi e dei ricavi
> variabili , a priori non posso sapere quanti sono i costi e di
> conseguenza i ricavi anche se un MAX lo sappiamo dalle esperienze,
> o faccio un'unica tabella chiamata Pratica con i normali dati ed in
> pi� 10 Campi Costi e 10 Campi ricavi e salvo tutto alla fine oppure
> non mi viene in mente niente.
>
> Avete da darmi qualche dritta o esempio da guardare?
>
> Grazie comunque a tutti per le risposte.
>
> SAluti
>
>

non hai girato la domanda, l'hai cambiata ^^

l'importante e' inserire prima la testa e poi il dettaglio.

oltre al suggerimento di marco, puoi valutare la gestione dello 'stato
pratica'.

inserita
accettata
eliminata
annullata
completata
chissacosaltroata

tutte le pratiche restano nella stessa tabella e con il campo in piu',
guadagni la possibilita' di capire quante sono quelle che comportano
lavoro senza darti soldi.

poi avrai la tabella con costi e ricavi, collegati alle pratiche.

comunque, inserisci la testata PRIMA delle righe di dettaglio...

0 new messages