Newsgroup: it.comp.software.database
Titolo: Informazione per ACCESS

Ho una situazione simile, ho creato la mia tabella, con un campo
conatore e chiave primaria, inserisco i record e il campo contatore mi
incrementa in modo automatico il valore 1 ... 2....3......4
Se elimino ad esmpio il primo record il numero 1 sparisce e la tabella
parte con il record numero 1 ed il campo contatore sul 2, non posso
far scalare tutti i valori in modo da farli ripartire da 1 ?????
Grazie

 ha scritto nel messaggio
news:8fpvmtouqujk7nuvb...@4ax.com...

E' un'impostazione di sicurezza del motore di database per evitare conflitti
in multiutenza.
I buchi che restano non danno problemi, se la cosa che ti preoccupa è
"l'esaurimento" del contatore lascia perdere: è un intero lungo.
Per tua curiosità su 
www.sitocomune.com
 trovi esempi alternativi
all'autonumber di access che evitano buchi nella sequenza.
Io comunque te li sconsiglio: richiedono un intervento di programmazione e
in multiutenza puoi avere problemi.
Ciao.

"l'esaurimento" del contatore lascia perdere: è un intero lungo.
Sull'ultimo SQL Server magazine si parlava appunto di questo problema
con un'applicazione che inserisce e cancella molti record. La
soluzione in puro SQL per la generazione del numero "corretto" da
inserire, riempiendo i buchi, era molto ingegnosa, anche se
computazionalmente pesante.
Il fatto che in SQL Server 2000 il contatore possa essere di 64 bit la
dice lunga sul fatto che non sia scontato che 32 bit siano sufficienti
(anche se la maggior parte delle persone non ne avrà mai bisogno)
-- 
Tieni per te il Papero giusto se vuoi la mia email
Sito Papero 1 -> 
http://utenti.tripod.it/papero
Sito Papero 2 -> 
http://user.7host.com/papero/

 (anche se la maggior parte delle persone non ne avrà mai bisogno)
Ok, ma tu mi parli di un server di database con uno spazio d'archiviazione
enorme.
Nel caso di JET (1 o 2 GB indirizzabili) un contatore a 32 bit basta e
avanza 100 volte.
Insomma, anche solo arrivare al 10% di   2.147.483.647  è un bel risultato
per un'architettura file-server.
Il post in questione non mi pare si riferisse ai campi "identità" di SQLSVR
ma piuttosto ad Access.
Ciao, Simone

avanza 100 volte.
Su questo hai ragione, volevo solo fare notare che in se il problema
esiste. Non esiste in Jet perche' il DB crolla prima.
In realtà potrebbe esistere anche in Jet per un motivo di prestazioni.
Non so che struttura dati usi Jet per le chiavi autoincrementanti. Se
alberi o tabelle hash.
Per curiosità sono andato a controllare i limiti di Jet, e sono
effettivamente di 1 - 2 Gb (a seconda di cosa ci metti dentro).


 effettivamente di 1 - 2 Gb (a seconda di cosa ci metti dentro).
A seconda della versione: 3.5 è 1 GB,  4.0 arriva a 2 GB.
Ciao, Simone

incrementi e conflitti in multiutenza, tu che pensi?
create table P (c int not null primary key )
select case
  when (not exists (select c from P where c = 0) ) then 0
  else ( 
   select min(T1.c)+1
      from P as T1 
    where not exists ( select T2.c from P as T2 where T2.c = T1.c + 1)
  ) end
Elegante e standard. 
Ti dice il primo buco disponibile.
P.S.
Comunque io preferisco entrare in transazione, bloccare la tabella,
scorrere la chiave primaria, cercare il primo buco libero, sbloccare
la tabella. Molto poco elegante, per niente standard, ma decentemente
veloce. La concorrenza la gestisco all'atto dell'inserimento della
riga grazie al vincolo di chiave primaria.
Probabilmente pero' il DB ottimizza meglio un Join per questo genere
di cose.


 riga grazie al vincolo di chiave primaria.
Davvero ingegnosa la prima :-)
Però in entrambi i casi c'è un dispendio computazionale (e di
programmazione nel metodo che preferisci) che rende discutibile l'uso di
campi identità.
Sarò radicale ma io la vedo così: o ti svincoli totalmente dal problema
dell'assegnazione della chiave primaria (lasciando al motore l'onere) oppure
tanto vale ricorrere alle vecchie chiavi alfanumeriche multicampo e a un
tantino di olio di gomito...
Ciao, Simone

Però in entrambi i casi c'è un dispendio computazionale
Su questo hai ragione, pero' da quel che vedo il vero carico di lavoro
non e' nella ricerca del buco libero, ma nell'aggiornamento degli
indici da parte del DB.
Comunque usare gli autonumber in SQL Server e' sensato. In Jet mi pare
proprio di no, e da quel poco che ho visto nemmeno in MySQL (ma quello
non lo considero nemmeno lontanamente un DB relazionale).
Le chiavi alfanumeriche che vanno tanto di moda su chi usa AS400 e
sistemi decisamente "prestanti", io le trovo "pericolose". Gestire un
albero binario fatto di long e' qualcosa di ottimizzabile. Un
confronto tra 2 numeri a 32 bit impieghera' un ciclo di clock. Il
confronto tra stringhe molti di piu'.
Certo, se hai un AS400 invece di un Celeron a 200 Mhz, tanto vale
usarlo, e renderti facile la vita.


confronto tra stringhe molti di piu'.
Sacrosanta verità, d'altro canto lavorando in RPG non si hanno alternative.
Ciao, warp

 confronto tra stringhe molti di piu'.
Non solo AS400, ma in generale tutti i vecchi software Cobol.
La verità è che con quegli strumenti non avevamo alternative :-((
Ciao, Simone

 portato gli autonumber a 64 bit.
All'atto pratico hai senz'altro ragione, però ipotizzando una milionata di
records inseriti (e cancellati) al giorno ci si potrebbe anche arrivare
prima dei 2 GB.
Ma è un discorso puramente teorico: chi oserebbe buttare decine di milioni
di records in una tabella di Access??
Sono cose che si possono fare a titolo di curiosità, esperimento ... ma non
a livelli professionali: rischi la vita!
Ciao, Simone