2009-04-07 8 views
31

Ho una strana situazione con alcune tabelle nel mio database che iniziano i suoi ID da 0, anche se TABLE CREATE ha IDENTITY (1,1). Questo è così per alcune tabelle, ma non per gli altri. Ha funzionato fino ad oggi.I valori delle colonne Identity server SQL iniziano da 0 invece di 1

Ho provato a resettare colonna di identità:

DBCC CHECKIDENT (SyncSession, reseed, 0); 

Ma nuovi record iniziano con 0. Ho provato a fare questo per tutte le tabelle, ma alcuni ancora iniziare da 0 e alcuni da 1.

Eventuali puntatori?

(sto usando SQL Server Express 2005 con Advanced Services)

+0

C'è qualcosa che non va nel tuo progetto se riesci a ricomporre il valore costantemente. E perché dovrebbe importare se inizia con 0 o 1?È un autoincremento, non dovrebbe importare quale sia il valore che è unico e assegnato automaticamente. – HLGEM

+2

Cinque anni di ritardo ma, come me, l'OP avrebbe potuto solo sviluppare e testare un insieme di dati noto. Non necessariamente qualcosa di sbagliato nel design. – GeoffM

+0

@HLGEM - ecco perché è più difficile. se si sta compilando un oggetto codice da un record del database, l'oggetto verrà inizializzato con una proprietà "ID" di 0. Quindi, se il popolamento ha esito positivo, sarà diverso dal valore predefinito di 0. 0 non può quindi indicare nessun record trovato o un "nuovo" oggetto. – nuander

risposta

41

Da DBCC CHECKIDENT

DBCC CHECKIDENT (table_name, RESEED, new_reseed_value) 

Se nessuna riga sono state inserite al tabella da quando è stata creata, o tutte le righe sono state rimosse utilizzando la dichiarazione TRUNCATE TABLE , la prima riga inserita dopo aver eseguito DBCC CHECKIDENT utilizza new_reseed_value come l'identità. In caso contrario, la riga successiva inserita utilizza new_reseed_value + il valore di incremento attuale .

Quindi, questo è previsto per una tabella vuota o troncata.

+0

Giusto FYI, l'istruzione DELETE FROM utilizzerà il secondo comportamento, "la riga successiva inserita utilizza new_reseed_value + il valore di incremento corrente". –

+0

DELETE non resetterà i semi .. è questo che intendi? – gbn

+0

@ GBN, è vero, ma quello a cui mi riferivo sta utilizzando DBCC CHECKIDENT (SyncSession, reseed, new_reseed_value); per reimpostare un seed per una tabella dopo che un DELETE assumerà il valore new_reseed_ e lo aggiungerà il valore di incremento corrente per la prima riga. –

2

Questo è logico, visto che hai cambiato (riseminate) il valore di identità a zero?

DBCC CHECKIDENT (SyncSession, reseed, 1) 

sarà reseed vostra colonna di identità, e assicurarsi che il primo nuovo record inizia con 1.

+1

No, non è giusto. Il primo valore usato se si specifica 1 in questo modo sarà 2! –

+0

Ah, a meno che non lo facciate su una tabella vuota, nel qual caso prende il valore specificato. Scuse!!! –

+0

Ho provato questo su tavoli vuoti e ora alcune tabelle partono da 1 e altre da 2. – Muxa

2

Ho lo stesso problema, ripristinando da un backup dopo aver modificato il DB. Ho appena aggiunto un record fittizio e quindi cancellarlo ... quindi impostare RESEED su 0. Sembra funzionare.

1

Prova questo

DECLARE @c TABLE (TanvtechId varchar(10),NewTanvtechId Varchar(10)) 
INSERT INTO @c 
SELECT TanvtechId , Row_Number() OVER (ORDER BY TanvtechId) from Tanvtech 

UPDATE G 
SET G.TanvtechId =a.NewTanvtechId 
FROM Tanvtech as G INNER JOIN @c as a ON a.TanvtechId =G.TanvtechId 
3

Se si passa un valore reseeding DB avrà inizio l'identità da quel nuovo valore:

DBCC CHECKIDENT (SyncSession, RESEED, 0); --next record should be 0 + increment 

Non è necessario passare il valore, però, se non si IDENTITY(a,b) sarà utilizzato invece:

DBCC CHECKIDENT (SyncSession, RESEED); --next record should be the seed value 'a' 

Questo di solito è meglio la pratica, in quanto lascia la ta più vicino al suo stato iniziale creato.

-1
DBCC CHECKIDENT (Table_Name, RESEED, 0) 

Questo è un modo per avviare un id con Zero(0), quindi eliminare tutte le righe da tavolo e di nuovo messo i dati indietro nella tabella.

Problemi correlati