Newsgroup: it.comp.lang.visual-basic
Titolo: Contatore Access

Ciao a tutti,
ho un problema con il contatore in Access.
Dunque, io ho creato una tabella dove il campo CODICE è un campo primario
contatore.
Quando decido di eliminare un record dalla tabella, mi piacerebbe che il
successivo record creato avesse lo stesso ID di quello cancellato
precedentemente. Invece nel creare nuovi records ho notato che il contatore
viene sempre automaticamente incrementato senza, perciò, tornare più
indietro.
Come fare? C'è modo di poter riempire gli spazi vuoti dovuti alla
cancellazione dei records?
Grazie mille e Buona Giornata.
Fabio
--------------------------------
Inviato via 
http://usenet.libero.it

 cancellazione dei records?
ALTER TABLE test ALTER COLUMN IDtabella COUNTER (2000,50)
Con un db access 97 non funziona pero' ...
ciao
	maxx
-- 
NOSPAM: Rimuovere i trattini dallo username!
Cut hyphens from my username!


Scusa, dove dovrei a inserirla questa riga di codice?
Nel listato VB o in Access?
Grazie ancora, Fa


 Nel listato VB o in Access?
Quando hai bisogno di ridefinire il valore del contatore esegui una 
query con quella sintassi (per cortesia studia la guida prima di postare).
La query la esegui da codice ...


 gli spazi vuoti dovuti alla cancellazione dei records?
Ti dirò di più: il Jet può decidere autonomamente di cambiare i numeri in
determinate situazioni, per cui chi utilizza le sequenze in Access non deve
mai ed in nessun caso mostrarle all'utente finale. Ergo se proprio vuoi
usarle, chiama la colonna ID e non codice, non mostrarla mai nelle maschere,
ed usa codice per una colonna in cui hai effettivamente un codice e non una
sequenza.
-- 
Ale
La RFD originale per it.comp.dotnet su
http://www.sen.it/stoa/articles.asp?id=10
Se vuoi discuterne, vai su it.news.gruppi

 ha
scritto:

Visto che, dopo aver letto la tua risposta, mi pare di capire che tu hai
molta più esperienza di me, mi potresti dare qualche dritta su come te
faresti il programma.
E' un archivio di clienti dove ognuno deve essere identificato da un numero
univoco e per questo io ho subito pensato di usare l'ID. Considera che
l'archivio sarà piuttosto piccolo e quindi anche se creassi una colonna a
parte, i numeri corrisponderebbero, presumibilmente, a quelli dell'ID. Che
benefici ne trarrei?
Grazie e Buon Pomeriggio.


 ha scritto nel messaggio
news:81Z72Z97Z125Y1...@usenet.libero.it...


 presumibilmente, a quelli dell'ID. Che benefici ne trarrei?
Secondo me in questo caso il codice dovrebbe essere alfanumerico e libero. A
volte dalle specifiche del progetto emergono situazioni in cui è conveniente
creare un codice parlante (per fare *un* esempio, se i clienti sono
localizzati in più province, potrebbe avere senso chiamarli PA001, CT005,
ME003, TP012), ma altre volte potrebbe non esserci nemmeno questa
convenienza (se i clienti sono pochi, lascia che sia l'utente finale a
decidere che codici usare).
Usare sequenze rende la tua tabella aprioristicamente non-relazionale; ora
può essere che in determinati casi la cosa abbia un senso (ad esempio quando
devo generare numeri di matricola, ma l'autonumber di Access non è
affidabile per questo genere di operazioni) ma nella stragrande maggioranza
dei casi non ne ha (se non nel facilitare la scrittura di join complessi
coinvolgenti più colonne). Se decidi di appoggiarti alle sequenze per
garantire l'univocità delle righe immesse quasi sempre non stai facendo una
scelta progettuale valida, e quando la fai ricordati sempre che quel numero
non deve mai essere visto (né ovviamente toccato) dall'utente finale.


 Nella Partita IVA...
Quella italiana 11 caratteri (testo perché anche se non sono numeri non ci
fai calcoli), quella comunitaria 12 (si aggiunge uno 0 all'inizio prima
degli 11 caratteri della partita iva Italiana), io propendo per, almeno,
preparare lo spazio per la seconda.


 compatta e ripristina il db),
hmmm... la compattazione...
nella mia esperienza, succede che se hai inserito 1-6, poi cancellato
5 e 6, se non compatti inserisci da 7, da 5 se hai compattato.
ma access non mi ha _mai_ cambiato il contatore gia' assegnato a un
record.
anche se lupo la pensa diversa, in ms non sono completamente
deficienti, spero. nei relazionali, specie a integrita' referenziale
non gestita automaticamente (nei miei non lo e' mai), quello che dici,
visto che spesso si usa il contatore come chiave, sarebbe
semplicemente suicida. se access cambia un id, cosa ne sa di quali
altri tabelle lo riflettono ?
detto questo, gia' varie volte si e' consigliato di evitare i
contatori come id. l'esempio canonico e': cosa succede se riversi una
tabella in un'altra con la stessa struttura ? i numeri saltati nella
tab 1 verranno assegnati nella tab 2, e visto che i contatori nuovi
non li possiamo decidere noi, le due tabelle avranno id diversi
assegnati agli stessi nominativi.
ciao


 gia' assegnato a un record.
A me (il Jet) sì, ma la tabella non era collegata ad altre tabelle.
All'epoca trovai un documento sulla MS KB in cui si dichiarava chiaramente
che le sequenze generate dal Jet debbono essere sempre usate internamente e
mai mostrate all'utente finale. Comunque ho smesso di usare Jet da anni.
Come si dice, se lo conosci lo eviti, ed a me è toccato conoscerlo in
profondità; sono arrivato una volta, a fine Luglio 2000, a scrivere più di
850 query in 150 ore-uomo, coordinando altri 3 colleghi, in una settimana.


 850 query in 150 ore-uomo, coordinando altri 3 colleghi, in una settimana.
Per fare cosa che non si debba fare con qualsiasi altro database? Se un
database si scassa è del tutto inutile tentare di recuperarlo nella parte
scassata. Di qualsiasi tipo esso sia.

 nella parte scassata. Di qualsiasi tipo esso sia.
Non s'era scassato, c'era una scadenza a fine Luglio e ce ne volevamo andare
in ferie in santa pace.


 850 query in 150 ore-uomo, coordinando altri 3 colleghi, in una
settimana.
complimenti, davvero. ma questo vuol probabilmente dire conoscerne in
profondita' _una parte_. io mi sono limitato a caricarlo di dati,
molti dati, da codice e no, e a vedere quanto reggeva. ha retto piu'
di quanto sperassi. e al momento mi basta. qualsiasi altra soluzione
avrebbe voluto dire essenzialmente regalare molti soldi a qualcuno con
risultati meno certi. quando mi servira' qualcos'altro, vedremo cosa
offre il mercato :)
ciao

 in ferie in santa pace.
E che c'entra questo con Jet?

 E che c'entra questo con Jet?
Scrivere 850 query funzionanti (testate una per una, si trattava di una
serie di analisi su dati già inseriti, con il progetto collaudato
successivamente da un esterno) ed una serie di tabelle per tutta una serie
di operazioni di ricodifica dei dati in una settimana, implica una certa
conoscenza del mezzo, no? Non sarò certo il meglio fico del bigoncio (tant'è
che giusto a me il contatore ha cambiato i numeri di sequenza, Access 97 e
non ricordo che versione del Jet, ma ricordo luogo e data, Aprile 1998, come
minimo c'è un'antipatia reciproca con il dbms) però una vaga idea di come
funzioni credo di averla..


... però una vaga idea di come funzioni credo di averla..
Non ho mai dubitato di questo, sinceramente.
Resto comunque perplesso (e, comunque, a me non è mai accaduto) sul fatto
che l'ID cambi (se non si fanno spostamenti di dati da una tabella a
un'altra).

 db, siamo un po' fuori strada :-)
Per quanto riguarda poi l'inserimento di un cliente senza CF o PIVA puoi
sempre dargli un valore casuale e poi mettere un bool per controllare e
ricordare che i dati non sono esattamente quelli. In questo caso però ci
sono problemi se hai già collegato record dal DB.
In ogni caso se non puoi identificare univocamente un cliente perché
inserirlo se non hai tutti i dati su di lui?.

 altri tabelle lo riflettono ?
Ripeto, ma se cambia il contatore, Jet lo cambia anche nelle tabelle
correlate? Se si usa la integrità referenziale non lo fa da solo?

 cadute di rete o di tensione.
Detto così non è molto bello... :-P
Dati non se ne devono perdere neppure per cadute di rete,
tensione, guasti hw, ecc...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 tensione, guasti hw, ecc...
Sarebbe l'ideale, certo, ma proprio perchè "ideale" ci si può rinunciare in
qualche occasione. :-)
Nessuno dei miei clienti mi hai mai telefonato per dirmi "corri subito, il
programma non parte. Non c'è corrente". ;-)
Ehmmm, ..., vero, in qualche occasione (ma veramente poche) mi hanno
telefonato dicendo "corri subito, il programma non parte, prima è caduta
corrente". Solo ancor più raramente mi è capitato di chiedere "a quando sono
le copie?" e alla risposta "le copie? ah, beh, andava tutto bene e abbiamo
smesso di farle...", che sorridessi o arrossissi di rabbia, la reazione era
sempre quella, calma e mai vendicativa "... che si può fare? ..."

 "corri subito, il programma non parte. Non c'è corrente". ;-)
Succede, succede, ma questa è solo idiozia del cliente...
Può anche succedere che il programma non parta (o si pianti) in
seguito a problemi "fisici", l'importante che non vi sia *mai*
corruzione o perdita di dati...


 non capisco bene cosa tu stia cercando/chiedendo di preciso.
Non chiedevo o cercavo proprio niente. Cercavo di precisare meglio alcuni
argomenti a cui avevi accennato tu in un post precedente.
