Redefinir semente de identidade após excluir registros no SQL Server

Eu inseri registros em uma tabela de banco de dados do SQL Server. A tabela tinha uma chave primária definida e a semente de identidade de incremento automático é definida como "Sim". Isso é feito principalmente porque no SQL Azure, cada tabela precisa ter uma chave primária e uma identidade definidas.

Mas como eu tenho que excluir alguns registros da tabela, a semente de identidade para essas tabelas será alterada e a coluna de índice (gerada automaticamente com um incremento de 1) será alterada.

Como posso redefinir a coluna de identidade depois de excluir os registros para que a coluna tenha sequência em ordem numérica crescente?

A coluna de identidade não é usada como chave estrangeira em nenhum lugar do banco de dados.

O DBCC CHECKIDENTcomando de gerenciamento é usado para redefinir o contador de identidade. A sintaxe do comando é:

DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]

Exemplo:

DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO

Não era suportado em versões anteriores do Banco de Dados SQL do Azure, mas agora é suportado.

Observe que o new_reseed_valueargumento varia de acordo com as versões do SQL Server, de acordo com a documentação :

Se houver linhas na tabela, a próxima linha será inserida com o valor new_reseed_value . Na versão SQL Server 2008 R2 e versões anteriores, a próxima linha inserida usa new_reseed_value + o valor atual de incremento.

No entanto, acho essas informações enganosas (na verdade, simplesmente erradas) porque o comportamento observado indica que pelo menos o SQL Server 2012 ainda usa new_reseed_value + a lógica atual do valor de incremento. A Microsoft até contradiz o que Example Cencontrou na mesma página:

C. Forçando o valor atual da identidade para um novo valor

O exemplo a seguir força o valor atual da identidade na coluna AddressTypeID na tabela AddressType a um valor 10. Como a tabela possui linhas existentes, a próxima linha inserida usará 11 como o valor, ou seja, o novo valor de incremento atual definido para o valor da coluna mais 1.

USE AdventureWorks2012;  
GO  
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);  
GO

Ainda assim, isso deixa uma opção para um comportamento diferente nas versões mais recentes do SQL Server. Acho que a única maneira de ter certeza, até a Microsoft esclarecer as coisas em sua própria documentação, é fazer testes reais antes do uso.

DBCC CHECKIDENT ('TestTable', RESEED, 0)
GO

Onde 0 é o identityvalor inicial

Deve-se observar que, se todos os dados estiverem sendo removidos da tabela por meio da DELETE(ou seja, sem WHEREcláusula), desde que a) as permissões permitam eb) não houver FKs fazendo referência à tabela (que parece ser caso aqui), o uso TRUNCATE TABLEseria preferido, pois é mais eficiente DELETE e redefine a IDENTITYsemente ao mesmo tempo. Os seguintes detalhes são obtidos da página MSDN para TRUNCATE TABLE :

Comparado com a instrução DELETE, TRUNCATE TABLE possui as seguintes vantagens:

• Menos espaço no log de transações é usado.

  A instrução DELETE remove as linhas uma por vez e registra uma entrada no log de transações para cada linha excluída. TRUNCATE TABLE remove os dados desalocando as páginas de dados usadas para armazenar os dados da tabela e registra apenas as desalocações da página no log de transações.

• Normalmente, menos bloqueios são usados.

  Quando a instrução DELETE é executada usando um bloqueio de linha, cada linha da tabela é bloqueada para exclusão. TRUNCATE TABLE sempre bloqueia a tabela (incluindo um bloqueio de esquema (SCH-M)) e a página, mas não cada linha.

• Sem exceção, zero páginas são deixadas na tabela.

  Depois que uma instrução DELETE é executada, a tabela ainda pode conter páginas vazias. Por exemplo, páginas vazias em um heap não podem ser desalocadas sem pelo menos um bloqueio de tabela exclusivo (LCK_M_X). Se a operação de exclusão não usar um bloqueio de tabela, a tabela (heap) conterá muitas páginas vazias. Para índices, a operação de exclusão pode deixar páginas vazias para trás, embora essas páginas sejam desalocadas rapidamente por um processo de limpeza em segundo plano.

Se a tabela contiver uma coluna de identidade, o contador dessa coluna será redefinido para o valor inicial definido para a coluna. Se nenhuma semente foi definida, o valor padrão 1 é usado. Para manter o contador de identidade, use DELETE.

Então, o seguinte:

DELETE FROM [MyTable];
DBCC CHECKIDENT ('[MyTable]', RESEED, 0);

Torna-se apenas:

TRUNCATE TABLE [MyTable];

Consulte a TRUNCATE TABLEdocumentação (vinculada acima) para obter informações adicionais sobre restrições, etc.

Embora a maioria das respostas esteja sugerindo RESEED para 0, muitas vezes precisamos apenas reenviar para o próximo ID disponível

declare @max int
select @max=max([Id])from [TestTable]
if @max IS NULL   //check when max is returned as null
  SET @max = 0
DBCC CHECKIDENT ('[TestTable]', RESEED,@max)

Isso irá verificar a tabela e redefinir para o próximo ID.

Eu tentei @anil shahsresponder e redefinir a identidade. Mas quando uma nova linha foi inserida, ela recebeu o identity = 2. Então, em vez disso, mudei a sintaxe para:

DELETE FROM [TestTable]

DBCC CHECKIDENT ('[TestTable]', RESEED, 0)
GO

Em seguida, a primeira linha receberá a identidade = 1.

Embora a maioria das respostas estão sugerindo RESEEDque 0, e enquanto alguns vêem isso como uma falha de TRUNCATEDtabelas, a Microsoft tem uma solução que exclui oID

DBCC CHECKIDENT ('[TestTable]', RESEED)

Isso verificará a tabela e redefinirá para a próxima ID . Isso está disponível desde o MS SQL 2005 até o momento.

https://msdn.microsoft.com/en-us/library/ms176057.aspx

emitir 2 comando pode fazer o truque

DBCC CHECKIDENT ('[TestTable]', RESEED,0)
DBCC CHECKIDENT ('[TestTable]', RESEED)

o primeiro redefine a identidade para zero e o próximo define o próximo valor disponível - jacob

@jacob

DBCC CHECKIDENT ('[TestTable]', RESEED,0)
DBCC CHECKIDENT ('[TestTable]', RESEED)

Trabalhou para mim, eu apenas tinha que limpar todas as entradas primeiro da tabela e, em seguida, adicionei o item acima em um ponto de disparo após a exclusão. Agora, sempre que eu excluir uma entrada, é retirada de lá.

Truncate A tabela é preferida porque limpa os registros, redefine o contador e recupera o espaço em disco.

Deletee CheckIdentdeve ser usado apenas onde chaves estrangeiras o impedem de truncar.

Redefinir coluna de identidade com o novo ID ...

DECLARE @MAX INT
SELECT @MAX=ISNULL(MAX(Id),0) FROM [TestTable]

DBCC CHECKIDENT ('[TestTable]', RESEED,@MAX)

Essa é uma pergunta comum e a resposta é sempre a mesma: não faça. Os valores de identidade devem ser tratados como arbitrários e, como tal, não há ordem "correta".

Execute este script para redefinir a coluna de identidade. Você precisará fazer duas alterações. Substitua tableXYZ por qualquer tabela que você precise atualizar. Além disso, o nome da coluna de identidade precisa ser removido da tabela temporária. Isso foi instantâneo em uma tabela com 35.000 linhas e 3 colunas. Obviamente, faça backup da tabela e tente primeiro em um ambiente de teste.

select * 
into #temp
From tableXYZ

set identity_insert tableXYZ ON

truncate table tableXYZ

alter table #temp drop column (nameOfIdentityColumn)

set identity_insert tableXYZ OFF

insert into tableXYZ
select * from #temp

DBCC CHECKIDENT (<TableName>, reseed, 0)

Isso definirá o valor atual da identidade como 0.

Ao inserir o próximo valor, o valor da identidade é incrementado para 1.

Use este procedimento armazenado:

IF (object_id('[dbo].[pResetIdentityField]') IS NULL)
  BEGIN
    EXEC('CREATE PROCEDURE [dbo].[pResetIdentityField] AS SELECT 1 FROM DUMMY');
  END
GO

SET  ANSI_NULLS ON
GO
SET  QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE [dbo].[pResetIdentityField]
  @pSchemaName NVARCHAR(1000)
, @pTableName NVARCHAR(1000) AS
DECLARE @max   INT;
DECLARE @fullTableName   NVARCHAR(2000) = @pSchemaName + '.' + @pTableName;

DECLARE @identityColumn   NVARCHAR(1000);

SELECT @identityColumn = c.[name]
FROM sys.tables t
     INNER JOIN sys.schemas s ON t.[schema_id] = s.[schema_id]
     INNER JOIN sys.columns c ON c.[object_id] = t.[object_id]
WHERE     c.is_identity = 1
      AND t.name = @pTableName
      AND s.[name] = @pSchemaName

IF @identityColumn IS NULL
  BEGIN
    RAISERROR(
      'One of the following is true: 1. the table you specified doesn''t have an identity field, 2. you specified an invalid schema, 3. you specified an invalid table'
    , 16
    , 1);
    RETURN;
  END;

DECLARE @sqlString   NVARCHAR(MAX) = N'SELECT @maxOut = max(' + @identityColumn + ') FROM ' + @fullTableName;

EXECUTE sp_executesql @stmt = @sqlString, @params = N'@maxOut int OUTPUT', @maxOut = @max OUTPUT

IF @max IS NULL
  SET @max = 0

print(@max)

DBCC CHECKIDENT (@fullTableName, RESEED, @max)
go

--exec pResetIdentityField 'dbo', 'Table'

Apenas revisitando minha resposta. Me deparei com um comportamento estranho no sql server 2008 r2 que você deve estar ciente.

drop table test01

create table test01 (Id int identity(1,1), descr nvarchar(10))

execute pResetIdentityField 'dbo', 'test01'

insert into test01 (descr) values('Item 1')

select * from test01

delete from test01

execute pResetIdentityField 'dbo', 'test01'

insert into test01 (descr) values('Item 1')

select * from test01

A primeira seleção produz 0, Item 1 .

O segundo produz 1, Item 1. Se você executar a redefinição logo após a criação da tabela, o próximo valor será 0. Honestamente, não estou surpreso que a Microsoft não consiga acertar essas coisas. Eu o descobri porque tenho um arquivo de script que preenche as tabelas de referência que às vezes executo após a recriação de tabelas e outras quando as tabelas já foram criadas.

Eu uso o seguinte script para fazer isso. Existe apenas um cenário no qual ele produzirá um "erro", ou seja, se você excluiu todas as linhas da tabela e IDENT_CURRENTestá atualmente definido como 1, ou seja, havia apenas uma linha na tabela para começar.

DECLARE @maxID int = (SELECT MAX(ID) FROM dbo.Tbl)
;

IF @maxID IS NULL
    IF (SELECT IDENT_CURRENT('dbo.Tbl')) > 1
        DBCC CHECKIDENT ('dbo.Tbl', RESEED, 0)
    ELSE
        DBCC CHECKIDENT ('dbo.Tbl', RESEED, 1)
    ;
ELSE
    DBCC CHECKIDENT ('dbo.Tbl', RESEED, @maxID)
;

Para obter linhas DELETE completas e redefinir a contagem de IDENTITY, eu uso isso (SQL Server 2008 R2)

USE mydb

-- ##################################################################################################################
-- DANGEROUS!!!! USE WITH CARE
-- ##################################################################################################################

DECLARE
  db_cursor CURSOR FOR
    SELECT TABLE_NAME
      FROM INFORMATION_SCHEMA.TABLES
     WHERE TABLE_TYPE = 'BASE TABLE'
       AND TABLE_CATALOG = 'mydb'

DECLARE @tblname VARCHAR(50)
SET @tblname = ''

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @tblname

WHILE @@FETCH_STATUS = 0
BEGIN
  IF CHARINDEX('mycommonwordforalltablesIwanttodothisto', @tblname) > 0
    BEGIN
      EXEC('DELETE FROM ' + @tblname)
      DBCC CHECKIDENT (@tblname, RESEED, 0)
    END

  FETCH NEXT FROM db_cursor INTO @tblname
END

CLOSE db_cursor
DEALLOCATE db_cursor
GO

A reposição de 0 não é muito prática, a menos que você esteja limpando a tabela como um todo.

de outro modo, a resposta dada por Anthony Raymond é perfeita. Obtenha o máximo da coluna de identidade primeiro e depois propague-o com o máx.

Eu tenho tentado fazer isso para um grande número de tabelas durante o desenvolvimento, e isso funciona como um encanto.

DBCC CHECKIDENT('www.newsType', RESEED, 1);
DBCC CHECKIDENT('www.newsType', RESEED);

Portanto, você primeiro força a configuração para 1 e, em seguida, o índice mais alto das linhas presentes na tabela. Descanso rápido e fácil do idex.

É sempre melhor usar TRUNCATE quando possível, em vez de excluir todos os registros, pois ele também não usa espaço de log.

No caso de precisarmos excluir e redefinir a semente, lembre-se sempre de que, se a tabela nunca foi preenchida e você o usou DBCC CHECKIDENT('tablenem',RESEED,0) , o primeiro registro terá identidade = 0, conforme indicado na documentação do msdn

No seu caso, apenas recrie o índice e não se preocupe em perder a série de identidade, pois esse é um cenário comum.

Primeiro: Especificação de identidade apenas: "Não" >> Salvar projeto de execução de banco de dados

Depois disso: Especificação de identidade apenas: "SIM" >> Salvar projeto de execução de banco de dados

Seu ID do banco de dados, PK Iniciar a partir de 1 >>