Newsgroup: it.comp.appl.access
Titolo: contatore "inteligente"

ciao a tutti,
avevo bisogno di un campo contatore che riconosce se un record è stato
eliminato e, in caso affermativo, lo occupi con una nuova registrazione.
per es.
id(contatore)     nome
01                    antonio
02                    francesco
03                    tiziana
04                    mario
quando elimino ad es il terzo record:
id     nome
01    antonio
02    francesco
04    mario
e vado a inserirne uno nuovo, voglio che anziche 05, nel campo id compaia
03, perchè manca dall'elenco. Avete qualche idea???
Grazie in anticipo.
                                                        Antonio
P.S.: nel caso volessi far si che anzichè mostrarmi 03 a nuovo inserimento,
mi riducesse di 1 gli id dopo 03 (01 antonio, 02 francesco, 03 mario), come
devo fare?

 ha scritto nel messaggio
news:bidhg7$4pv$1...@fata.cs.interbusiness.it...


 ottenere il risultato
Sì, a che cosa serve di dover riempire a tutti i costi tutti i numeri del
progressivo di una chiave primaria?
Per i puristi del database, la chiave primaria dovrebbe essere costituita
esclusivamente da uno o più campi che comunque compongono il record e che
posti nella chiave lo rendono univoco, solo nel caso che questo non sia
possibile si ricorre ad un contatore che comunque non ha importanza se
rimane con qualche buco.
In questo modo ci sono pochissime situazioni che riesco ad immaginare in cui
bisogna per forza fare queste operazioni di spazzolamento ed aggiornamento
delle chiavi del database.
In ogni caso io procederei in maniera diversa: Avete presente il vecchio DOS
che quando cancellava un file non lo cancellava veramente, ma metteva un '?'
al posto del primo carattere del nome nella tabella dei file? Si può fare
allo stesso modo: Aggiungi un campo flag al record (tipo booleano), che
indichi se il record sia o meno stato annullato, lo definisci come chiave
secondaria duplicabile per velocizzarci le ricerche. Crei tutte le query,
maschere, stampe in maniera da saltare i record virtualmente annullati,
quando ti serve un buco libero, cerchi un record con il Flag_Annullato a
VERO e rimpiazzi i valori di tutti i campi con quelli nuovi.
Ciao.

e se invece io volessi limitare i valori degli ID?
per esempio se volessi avere degli ID per i miei record che partano da
mille?
oppure avendo un ID generato casualmente volessi solo ID positivi ...
che ne dite?

 ha scritto nel messaggio
news:plg1lvc78jiav2si4...@4ax.com...

Per andare a Roma si possono prendere + strade, oltretutto non tutti i
giorni dell'anno ed a tutte le ore risulta la migliore sempre la stessa,
quindi, siccome la curiosità la fa da padrona nel mondo della
programmazione...
Che devi fare?
Che scopo hanno queste numerazioni particolari?
Che tabelle hai?
etc...
Ciao.



Semplicemente fare un DB delle riparazioni del laboratorio che non
inizi da numero di ID tipo 5, 6 o 7 tutto qui, è solo una cosa di
immagine ...


 ha scritto nel messaggio
news:gvd8mvkiegjbgcreq...@4ax.com...

Non dovresti considerare la chiave primaria numerica di un record, come un
modo per contare quante riparazioni hai effettuato fino a quella del record
stesso (ci sono funzionalità apposite), bensì come un campo il cui contenuto
rende riconoscibile il record tra tutti gli altri.
Sforzati di vederlo + come il codice di un articolo di magazzino, anziché il
N° progressivo di una fattura, in questo secondo caso infatti vanno presi
tutta una serie di accorgimenti per mantenerne la sequenza ininterrotta.
Inoltre, a meno che non si tratti di prove che vanno per forza eliminate,
nella maggior parte dei casi conviene considerare un database come un
ripostiglio in cui si inserisce sempre e non si toglie (cancella) mai
(naturalmente vanno valutate le varie situazioni).
Permettimi un'ultima cosa che potrei sicuramente risparmiarti...
Da "rifiniture" come queste si ha un piccolo ritorno di immagine (anche se
magari sono proprio le piccolezze che ti vengono fatte notare), mentre se
l'applicativo che costruisci fa risparmiare tempo e non causa incertezze
nell'impiego (vedi errori o scarsa facilità di utilizzo) ne avrai un grande
ritorno.
Ciao.

 rende riconoscibile il record tra tutti gli altri.
cut
Condordo con questa osservazione.
un id, anche quello definito come tipo "contatore", non serve a contare ma a
identificare.
Se hai la curiosita' di sapere quanti record hai usa Dcount()
Sib

senza dubbio d'accordo sul fatto che un ID identifica e non conta, ma
se il numero che fa da ID è strano identifica lo stesso e a quel punto
mettersi a fare un campo in più da usare come "ID di facciata" diventa
solo un appesantimento, non trovate?
sono d'accordo comunque col fatto che si tratta di una piccolezza, ho
affrontato ben altri problemi su questo lavoro, che è il mio primo
database relazionale, e quindi so che si tratta di un particolare, ma
anche l'occhio vuole la sua parte ... e la facilità d'uso mi sta
mandando ai pazzi a me ...
conferme nelle eliminazioni ... 
finestre di dialogo ...
automatismi ...
 
un bel lavorone insomma ...

 un bel lavorone insomma ...
Se posso consigliarti, procedi con questo metodo di sviluppo: approccio
iterativo ed incrementale.
Parte dalla constatazione che quasi mai si ha chiaramente in mente tutto ciò
di cui si ha bisogno da un programma e spesso si perdono risorse preziose
per sviluppare parti che alla fin fine non erano poi così necessarie, a
scapito di altre esigenze che vengono fuori con le prime fasi di utilizzo di
un programma.
Certo ci sono altri metodi per progettare un'applicazione, tuttavia credo
che questo possa darti buone soddisfazioni in ordine di celerità e
flessibilità.
Procedi in questo modo:
-Scrivi in ordine sparso tutte le cose che la tua applicazione deve fare, in
questo momento non conta come: ad es. quali stampe devono essere generate e
con che struttura, quali sono le ricerche a video, i total, i grafici e le
statistiche che dovranno essere visualizzati, ecc...
-Stabilisci quali sono i punti indispensabili e sviluppa solo quelli, senza
troppi abbellimenti o automatismi non strettamente necessari.
-Progetta attentamente le tabelle su carta e le relazioni che le legano,
descrivi bene le regole che governano il contenuto e/o l'interdipendenza dei
campi che le compongono.
-Pianifica le query di cui avrai bisogno per alimentare le maschere, le
ricerche a video, le stampe, ecc...
-Quando hai terminato l'implementazione dei primi requisiti e durante la
fase d'uso del programma, è molto probabile che la lista che avevi preparato
si sia anche di molto modificata.
-Ripeti la selezione di altri pochi punti prioritari e danne esecuzione...
-E così fino a quando la tua applicazione sarà realmente calzata sulle
necessità per la quale viene impiegata.
-Quando l'applicazione è pressoché terminata, procedi ad effettuare tutti
quegli automatismi, abbellimenti ed aggiustamenti che rendono l'applicazione
amichevole fruibile e sopratutto omogenea nelle sue parti.
Auguri e ciao.

sono molto d'accordo sull'omogeneità ...
per il resto, anche se non conoscevo una formulazione del genere del
modo di lavorare su un programma, devo dire che più o meno sto facendo
così, sgrossa sgrossa fino alle finiture ...