Newsgroup: it.comp.lang.vo-clipper
Titolo: MySql e AUTO_INCREMENT

Ciao a tutti,
ho un piccolo problema con la colonna AUTO_INCREMENT.
Prendiamo in esame una classica tabella fatture. Se io emetto una fattura
che viene numerata automaticamente da mySql con il numero 35 (ad esempio) e
poi la elimino, mi aspetto che la prossima sia di nuovo la n° 35 e non la
36, come in effetti succede.
Ho come l'impressione di dover fare una sorta di PACK della tabella dopo la
cancellazione, ma come? ho provato con optimize table ma non risolve il
problema.
Qualche suggerimento?
                                    Francesco Leo

 ha scritto nel messaggio
news:bo65cl$rqn$1...@fata.cs.interbusiness.it...



Già, me se facessi così perderei la più grande comodità (a mio parere) che
ha mySql, e cioè quella di poter inserire record senza bloccare la tabella,
visto che l'autoincrement fa il lavoro al posto mio.
Forse una soluzione, oltre a quella esposta da te, potrebbe essere questa:
A) Creare una tabella temporanea uguale all'originale settando
l'autoincremente al valore desiderato (lo si può fare in fase di creazione)
B) Copiare tutti i record dalla vecchia alla nuova tabella
C) Eliminare la tabella vecchia
D) Rinominare la nuova tabella.
Non so se può funzionare, mi è venuta in mente or ora.
Il problema si pone per il recupero dei numeri di fattura.
Con i dbf, se cancellavo l'ultima fattura, portavo automaticamente il
numeratore indietro di uno. Era una funzione comodissima per i clienti. Ora
come faccio?  Devo inserire manualmente il numero come dici tu.
Ciao.
                                                        Francesco Leo

 auto_increment.
Brrr... non oso pensare a quello che potrebbe succedere alla coerenza
interna di un database dopo una simile operazione...
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 ha scritto nel messaggio
news:bo65cl$rqn$1...@fata.cs.interbusiness.it...


 ha scritto nel messaggio
news:bo65cl$rqn$1...@fata.cs.interbusiness.it...


Non conosco così a fondo MySQL, pero' ho un po' di esperienza con 
gli MDB di Access.
In Access dopo la tua operazione, richiamando il metodo
CompactDatabase il valore ritornerebbe a 35.
Pero' CompactDabase richiede l'apertura esclusiva del DB e non credo
sia una strada molto praticabile.
Personalmente, in tutti i posti dove sono stato a lavorare, ho visto
utilizzare una o piu' tabelle (gestite a manina) con un record
contenente i progressivi dei documenti, dove questi progressivi
rappresentano un numero di protocollo.
HTH
Antonello


===============================================
Antonello Negrone - Biella - Italy
www.anc-software.it


In effetti anche io ho usato finora questo metodo con i dbf, ma è
sicuramente più macchinoso che usare l'auto incremento di un campo.
Con i dbf dovevi bloccare il file usato per i contatori, prelevare il numero
progressivo, assegnarlo al documento, salvare il documento, aggiornare, se
non ci sono stati problemi, il contatore e quindi sbloccare il file.
Da quanto ho visto finora con mySql, (anche se non con le fatture) io
utilizzo il campo auto_increment senza preoccuparmi di nulla e,soprattutto,
senza bloccare niente in quanto il tutto avviene in maniera automatica.
Ciao
                                        Francesco


Sicuramente con i dbf non lo farei nemmeno io ma mySql è un tantino diverso.
Tanto per dirne una con i dbf il recno cambia secondo gli indici utilizzati,
a meno che io non ricordi male....
Ciao.
                        Francesco

 Danilo Giuliani
Questa è da provare, anche se forse posso ottimizzare un recupero
semi-manuale delle fatture e tagliare la testa al toro.
Grazie.
                                                Francesco

senza bloccare niente in quanto il tutto avviene in maniera automatica.
Anch'io con access uso i campi autoincrement per attribuire un valore
univoco, ad esempio, ai record dei movimenti di magazzino. 
Lo trovo comodissimo. 
Pero' la differenza è che in quel caso non mi danno problemi aventuali
"buchi" nella numerazione.
Mi spiace non poterti dare un aiuto pratico con MySQL.
Ciao


 utilizzati, a meno che io non ricordi male....
Ricordi male. RECNO() è la posizione fisica, ORDKEYNO() quella logica.


 ha scritto nel messaggio
news:bod57o$moc$1...@fata.cs.interbusiness.it...


 Tabella con i contatori per le numerazioni controllate, sia DBF sia SQL.
Io ho quasi sempre utilizzato un apposito campo nella tabella
interessata e mi sono trovato bene, sia con i DBF che con SQL.
