Newsgroup: it.comp.lang.visual-basic
Titolo: contatori in access

In un thread di ieri ho letto che č bene non usare contatori in access.
Domanda stupida: perchč?
(provo a immaginare: perchč incrementa in ogni caso il contatore senza usare
numeri eventualmente lasciati liberi da cancellazioni di record.)

numeri eventualmente lasciati liberi da cancellazioni di record.)
Anche questo volendo, ma spesso i "buchi" sono logicamente ammessi,
quindi non e' il problema piu' grosso.
-- 
ciao, hal

 In generale non e' tanto raccomandabile con qualsiasi database.
Perché mai? Se ci sono è per essere utilizzati.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Perché mai? Se ci sono è per essere utilizzati.
Access 97 , 2000 , mi sembra XP no.
Tabella con 1000 record.
Contatore da 1 a 1000
Porto gli ultimi 100 nella tabella dello storico.
Compatto il db.
Il contatore dovrebbe partire da 1001
Riparte da 901
Inserisco 100 record
Sposto gli ultimi 100 nella tabella storico
Nel campo contatore dello storico,dati univoci, cerco di inserire doppioni.
Messaggio di Warnig
Che faccio ?
Salve
giuseppeD

 Che faccio ?
Questo però non è un problema del campo contatore, ma un problema di 
Access, anzi della compattazione di Access.


 Access, anzi della compattazione di Access.
la chiamerei feature, piu' che problema.
se hai eliminato record in coda, quando compatti access non li considera.
non e' illogico, e qualsiasi soluzione avrebbe pro e contro.
a me e' capitato di servirmene in modo positivo, di questa caratteristica.
il problema e' a monte, proprio nell'uso (specie come chiave) del contatore.
ciao.

Che faccio ?
Appunto :-(
-- 
ciao, hal
oltre a quello che ho gia' descritto nel mio post, che non l'ho letto
sui libri, ma ho dovuto risolverlo da remoto in tempi strettissimi...

 il problema e' a monte, proprio nell'uso (specie come chiave) del contatore.
Ammetto che i database non siano il mio campo, ma mi pare che i campi
contatore siano nati proprio per poterli usare come chiave... o sbaglio?


 contatore siano nati proprio per poterli usare come chiave... o sbaglio?
possono essere comodi, ma p.e. c'e' un limite. se provo a riversare una
tabella in una con struttura identica (backup o qualsiasi altro scopo), il
contatore se lo gestisce il db, io non li posso toccare. ora, se nella mia
c'e' un salto (dovuto a eliminazione del record)
998
999
1001
nella nuova avro'
998
999
1000
se quel campo magari e' un foreign key in un'altra tabella...
ciao

se quel campo magari e' un foreign key in un'altra tabella...
... tiri giu' tutti i santi come e' successo a me :-(
-- 
ciao, hal

 se quel campo magari e' un foreign key in un'altra tabella...
Beh, mi pare sia ancora una volta un problema di Access...
In PostgreSQL posso creare la tabella "di backup" in questo modo:
CREATE TABLE dest_table AS SELECT * FROM source_table.
Così i campi "contatore" vengono copiati pari pari senza problemi di
sorta.
Ed in SQL Server non mi ricordo (è un po' che non lo uso e non ne ho uno
sottomano) se è possibile fare lo stesso, ma è *sicuramente* ottenibile
lo stesso risultato, anche perché sono sicuro che sia possibile (con un
apposito comando) inserire "a mano" i valori in un campo contatore (identity
in SQL Server).


 ... tiri giu' tutti i santi come e' successo a me :-(
Eh, eh... basta utilizzare un db serio :-P


 in SQL Server).
ok, ma allora non e' un 'contatore' nel senso che di solito si da' a questa
parola.
in cobol e poi in clipper, e ora in ado, i contatori me li sono sempre
gestiti a mano, tipo select max(id)+1.
ma quello di access e' comodo proprio perche' ci pensa lui.
nel bene e nel male...
ciao

 contatore siano nati proprio per poterli usare come chiave... o sbaglio?
Vero,
perchè con VB molte funzioni,componenti, anche se sono a disposizione per
poterli usare,
esistono situazioni di lotta all'ultimo codice per un loro impiego, e non
sempre ci si riesce.
Distinguerei casi diversi per un impiego del contatore fornito dal db.
es. Un contatore per un elenco limitato. es. Capitali , Categorie
dove il record, causa numero limitato, anche se non più utilizzato, non
verrà cancellato.
In questo caso il contatore del db, penso, sia accettabile.
Per altri, simulerei le controindicazioni possibili.
Salve
giuseppeD

 verrà cancellato.
non sono sicuro di avere capito. puoi spiegare meglio p.f. ?
grazie

 nel bene e nel male...
Ho l'impressione , e questo post è una ennessima conferma, che per il
programmatore VB la base dati è solo un magazzino,
anche alla rinfusa, basta che li inserisco.
Eppure ogni tanto affiorano post tipo:
"Sto avendo problemi con una tabella Access che un numero di campi piuttosto
elevato, circa 250..........."
"Il mio gestionale prevede, fra le altre la tabella, articoli 113
campi........"
Dopo che il proggetto è in produzione, un colore o un controllo, es.
digitare solo numeri in una casella, ecc.,è possibile effettuare modifiche.
Si si presentano problemi sulla base dati, mi spieghi come effettui le
modifiche senza bloccare o peggio non rischiare di corrompere i dati ?
Salve
giuseppeD

 campi........"
per un paio d'anni ho tentato invano di spiegare il concetto di rdbms a una
persona che, avendo un campo ripetibile, si era fatto un dbf con circa 90
campi campo1..campo90.
ho anche provato a chiedere:
"e se ne devi mettere dentro 91 ?"
"l'ultimo non lo inserisco".
a quel punto mi sono sentito in diritto di rinunciare.
temo che il problema sia a monte del "programmatore vb"...
ciao

 non sono sicuro di avere capito. puoi spiegare meglio p.f. ?
Un elenco del genere:
tabella Coloti
id     Colore
1        Bianco
2        Giallo
3        Verde
4        Rosso
7        Arancione
8        Blu
11     Marrone
14     Azzurro
Penso sia una tabella base.
I vuoti non rappresentano un problema.
Ammettiamo che gli ultimi tre colori, per decisione, non vengono più
utilizzati,
essendo il numero limitato chi è quel pignolo che va a cancellarli ?
Diverso una situazione di gestione delle fatture,
i vuoti hanno il loro peso,
i doppioni non ne parliamo
In questo caso delle simulazioni, in situazioni non percorse prima, penso
sia consigliabile.
Salve
giuseppeD

 essendo il numero limitato chi č quel pignolo che va a cancellarli ?
ehm, io :)
ho una tabella simile con gli utenti (pochi) autorizzati a inserire, un
campo e' cognome+nome (aggiunto ai record che inseriscono, cosi' gli errori
calano parecchio), ma l'identificazione avviene in base al login di rete,
che e' un altro campo. se non e' un login rete diciamo che lo blocca nt, se
non e' nella tabella non inserisce, anzi non entra proprio nel programma.
quelli non piu' autorizzati *devo* rimuoverli.
certo, potrei anche avere un campo bool o 1/0 in cui validarli, ma cosi' e'
molto piu' immediato.
altra cosa sarebbero le ragioni sociali di un archivio d fatture, in cui
magari ti serve avere uno storico anche nei casi di cambi di ragione sociale
o di scomparsa di ditte.
comunque, si', le scelte possibili sono parecchie. l'importante e'
ragionarci.
ciao

 pensa lui.
Esatto. Solo che i db "seri" ;-) ci pensano sempre loro, ma solo nel 
bene...


 Per altri, simulerei le controindicazioni possibili.
Capisco che, come scrivi in un altro post, nel caso delle fatture (o di 
qualunque cosa abbia un campo con un codice univoco), un campo contatore 
sia superfluo, ma non riesco a vederne la pericolosità.
Pericolosità che sia dovuta al campo contatore (un valore univoco
autoincrementato dal db stesso), non alla (errata) gestione che ne fa
un particolare db (Access in questo caso).


 bene...
diffido per principio e per esperienza di chi e cosa pensa di essere sempre
nel bene.
finisce sempre come con hal.
quello la', non questo qua :)

temo che il problema sia a monte del "programmatore vb"...
Spesso chi non sa programmare viene messo a fare l'analista <g>
-- 
ciao, hal

 nel bene.
Beh, vista l'opzione di cui sopra mi pare che i programmatori di SQL Server 
non hanno pensato di essere sempre nel bene. Cosa che invece mi pare
abbiano fatto quelli di Access...


abbiano fatto quelli di Access...
Come hai giustamente osservato prima, Access NON e' un database serio,
ma e' come il raffreddore: prima o poi ti arriva :-(
-- 
ciao, hal

 ma e' come il raffreddore: prima o poi ti arriva :-(
Ho un sistema immunitario in gran forma ;-)


 Ho un sistema immunitario in gran forma ;-)
si', ma un assegno stronca qualsiasi globulo bianco ligure :)

 > select max(id)+1.
Personalmente ho diffidato del select max della tabella dove risiedono i
dati.
Preferisco una tabella contatore con un solo campo ed un solo record
giuseppeD

"H.P.L." <u...@vaila.ble> ha scritto nel messaggio
news:slrnb9md7...@aidee.softshark...

Riuscire a capire il corretto utilizzo della relazione in un db non è
cosa,mio pensiero, semplice.
La causa ,sempre mio pensiero, è lo snobbare i testi che trattano SQL.
Sto leggendo l'ennesimo libro su SQL e "Cacchio, questa non la sapevo !"
Impostare la Key ,un solo campo ?
E se la Key deve essere composta da due o più campi ?
Conviene effettuare un controllo dall'host e inserire un campo contatore o
impostare la key nella tabbella tra più campi ?
giuseppeD

 impostare la key nella tabbella tra più campi ?
Tabella con una b !
giuseppeD

Grazie a tutti, siete stati molto chiari. Ciao

 si', ma un assegno stronca qualsiasi globulo bianco ligure :)
Fortunatamente il mio capo non è ligure :-P


 La causa ,sempre mio pensiero, è lo snobbare i testi che trattano SQL.
Beh, io non è che li snobbo... è che non sono io ad occuparmi di db...
anche se qualche volta... qualcosina... mi tocca farla.
