Réinitialiser la graine d'identité après la suppression des enregistrements dans SQL Server


682

J'ai inséré des enregistrements dans une table de base de données SQL Server. La table avait une clé primaire définie et la valeur de départ de l'incrémentation automatique est définie sur «Oui». Cela est principalement dû au fait que dans SQL Azure, chaque table doit avoir une clé primaire et une identité définies.

Mais comme je dois supprimer certains enregistrements de la table, la graine d'identité de ces tables sera perturbée et la colonne d'index (qui est générée automatiquement avec un incrément de 1) sera perturbée.

Comment puis-je réinitialiser la colonne d'identité après avoir supprimé les enregistrements afin que la colonne ait une séquence dans l'ordre numérique croissant?

La colonne d'identité n'est utilisée comme clé étrangère nulle part dans la base de données.


4
"dans SQL Azure" - "chaque table doit avoir une clé primaire" - true - "et Identity Defined" - false. L'identité et la clé primaire sont des concepts orthogonaux. Une colonne d'identité ne doit pas nécessairement être le PK d'une table. Une clé primaire ne doit pas nécessairement être une colonne d'identité.
Damien_The_Unbeliever

D'ACCORD. Mon concept pourrait être faux. Mais maintenant, j'ai défini la structure de la table avec PK et Identity Seed. Si je dois supprimer certaines lignes, comment pourrais-je réinitialiser la graine d'identité dans un ordre croissant numérique correct
xorpower

29
Je dirais toujours que si vous vous souciez des valeurs numériques réelles générées dans une colonne d'identité, vous les utilisez à mauvais escient. Tout ce que vous devez faire avec une colonne d'identité, c'est qu'elle génère automatiquement des valeurs uniques (ouais!) Et que vous pouvez stocker ces valeurs dans une colonne numérique (ce bit n'est pertinent que pour déclarer des colonnes contenant ces valeurs). Vous ne devriez les montrer à personne, donc peu importe les valeurs qu'ils prennent.
Damien_The_Unbeliever

vous pouvez utiliser dbcc check identifier comme mentionné, mais veuillez noter que la clé primaire n'est pas obligatoire pour sql db v12
Satya_MSFT

Réponses:


1100

La DBCC CHECKIDENTcommande de gestion est utilisée pour réinitialiser le compteur d'identité. La syntaxe de la commande est:

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

Exemple:

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

Il n'était pas pris en charge dans les versions précédentes d'Azure SQL Database, mais il est désormais pris en charge.


Veuillez noter que l' new_reseed_valueargument varie selon les versions de SQL Server selon la documentation :

Si des lignes sont présentes dans le tableau, la ligne suivante est insérée avec la valeur new_reseed_value . Dans la version SQL Server 2008 R2 et versions antérieures, la ligne suivante insérée utilise new_reseed_value + la valeur d'incrément actuelle.

Cependant, je trouve ces informations trompeuses (tout simplement fausses en fait) car le comportement observé indique qu'au moins SQL Server 2012 utilise toujours new_reseed_value + la logique de valeur d'incrément actuelle. Microsoft contredit même son propre Example Ccontenu sur la même page:

C. Forcer la valeur d'identité actuelle à une nouvelle valeur

L'exemple suivant force la valeur d'identité actuelle dans la colonne AddressTypeID de la table AddressType à une valeur de 10. Étant donné que la table contient des lignes existantes, la ligne suivante insérée utilisera 11 comme valeur, c'est-à-dire la nouvelle valeur d'incrément actuelle définie pour la valeur de la colonne plus 1.

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

Pourtant, tout cela laisse une option pour un comportement différent sur les nouvelles versions de SQL Server. Je suppose que la seule façon d'être sûr, jusqu'à ce que Microsoft clarifie les choses dans sa propre documentation, est de faire des tests réels avant utilisation.


24
La syntaxe serait ... DBCC CHECKIDENT ('[TestTable]', RESEED, 0) GO
Biki

2
Il semble que cela DBCC CHECKIDENTsoit pris en charge à partir de la prochaine version (V12 / Sterling): azure.microsoft.com/en-us/documentation/articles/… Bien que, pour cette situation particulière, je recommanderais toujours TRUNCATE TABLE :)
Solomon Rutzky

1
Cela n'a pas fonctionné pour moi jusqu'à ce que le "GO" soit dans une autre ligne.
mrówa

1
La syntaxe est signalée à cause du mot clé GO dans la même ligne, je ne sais pas pourquoi. Pouvez-vous le déplacer sur une ligne. J'ai copié et collé cette ligne 50 fois et maintenant je dois revenir en arrière et la réparer.
AnotherDeveloper

4
A parfaitement fonctionné pour moi. Il convient de souligner que lors du réamorçage d'une table, si vous souhaitez réamorcer de sorte que votre premier enregistrement soit ID 1, la commande de réamorçage doit être réamorcée à 0, de sorte que l'enregistrement suivant soit ID 1.
Mike Upjohn

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

Où 0 est la identityvaleur de départ


15
Si la table est vide, comme si vous venez d'appeler TRUNCATE, alors la nouvelle valeur de départ devrait être la valeur pour la prochaine utilisation (c'est-à-dire 1 et non 0). Si la table n'est pas vide, elle utilisera le new_reseed_value + 1. MSDN
kjbartel

2
@kjbartel, Anil et autres: ce n'est pas aussi simple que "si la table est vide". La documentation manquait le cas lorsque la table est vide en raison DELETE, non TRUNCATE, auquel cas elle l'est également new_reseed+value + 1. J'ai écrit un article à ce sujet, montrant le comportement réel via certains tests, et mis à jour le document réel (maintenant que nous pouvons le faire car il est sur GitHub): Comment fonctionne vraiment DBCC CHECKIDENT lors de la réinitialisation de la graine d'identité (RESEED)? .
Solomon Rutzky

87

Il convient de noter que SI toutes les données sont supprimées de la table via la clause DELETE(c'est-à-dire aucune WHEREclause), tant que a) les autorisations le permettent, et b) il n'y a pas de FK référençant la table (qui semble être le cas ici), l'utilisation TRUNCATE TABLEserait préférable car elle est plus efficace DELETE et réinitialise la IDENTITYgraine en même temps. Les détails suivants sont extraits de la page MSDN de TRUNCATE TABLE :

Par rapport à l'instruction DELETE, TRUNCATE TABLE présente les avantages suivants:

  • Moins d'espace de journal des transactions est utilisé.

    L'instruction DELETE supprime les lignes une par une et enregistre une entrée dans le journal des transactions pour chaque ligne supprimée. TRUNCATE TABLE supprime les données en désallouant les pages de données utilisées pour stocker les données de table et n'enregistre que les désallocations de page dans le journal des transactions.

  • Moins de verrous sont généralement utilisés.

    Lorsque l'instruction DELETE est exécutée à l'aide d'un verrou de ligne, chaque ligne de la table est verrouillée pour suppression. TRUNCATE TABLE verrouille toujours la table (y compris un verrou de schéma (SCH-M)) et la page mais pas chaque ligne.

  • Sans exception, aucune page n'est laissée dans le tableau.

    Après l'exécution d'une instruction DELETE, la table peut toujours contenir des pages vides. Par exemple, les pages vides d'un tas ne peuvent pas être désallouées sans au moins un verrou de table exclusif (LCK_M_X). Si l'opération de suppression n'utilise pas de verrou de table, la table (segment) contiendra de nombreuses pages vides. Pour les index, l'opération de suppression peut laisser des pages vides, bien que ces pages soient rapidement désallouées par un processus de nettoyage en arrière-plan.

Si la table contient une colonne d'identité, le compteur de cette colonne est réinitialisé à la valeur de départ définie pour la colonne. Si aucune graine n'a été définie, la valeur par défaut 1 est utilisée. Pour conserver le compteur d'identité, utilisez plutôt DELETE.

Donc, ce qui suit:

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

Devient juste:

TRUNCATE TABLE [MyTable];

Veuillez consulter la TRUNCATE TABLEdocumentation (liée ci-dessus) pour plus d'informations sur les restrictions, etc.


8
Bien que plus efficace dans les bonnes circonstances, ce n'est pas toujours une option. Truncate ne s'exécutera pas sur une table sur laquelle un FK est défini. Même lorsqu'il n'y a aucun enregistrement dépendant, la troncature échouera si la contrainte existe. Tronquer requiert également des autorisations ALTER où Supprimer n'a besoin que de SUPPRIMER.
Rozwel

3
@Rozwel Vrai, mais j'avais déjà qualifié ma réponse en déclarant que les autorisations appropriées doivent être en place. En outre, la question indique spécifiquement qu'il n'y a pas de FK. Cependant, par souci de clarté, j'ai mis à jour pour spécifier la restriction "pas de FK". Merci d'avoir fait remarquer cela.
Solomon Rutzky

1
le seul problème est que tout FK bloquera tronquer. Il est possible (quoique inhabituel) d'avoir un FK contre une contrainte unique qui ne fait pas partie des colonnes PK ou d'identité.
Rozwel

1
@Rozwel Encore vrai, mais il semble raisonnable de supposer à partir de la question qu'il n'y a pas de contraintes uniques étant donné que le PK existe uniquement en raison de la compréhension (correcte ou non) de l'OP qu'il est requis par Azure SQL Database. Quoi qu'il en soit, je suis tout pour réduire l'ambiguïté, j'ai donc mis à jour à nouveau. Merci.
Solomon Rutzky

Ce n'est pas si inhabituel d'avoir une clé étrangère sur une table, et la présence de TOUTE clé étrangère interdit TRUNCATE TABLE. Je viens de découvrir cela à la dure plus tôt aujourd'hui lorsque j'ai essayé d'exécuter TRUNCATE TABLE sur une table qui a une clé étrangère appliquée à deux autres colonnes de la table et un index unique dans la table étrangère.
David A. Gray

83

Bien que la plupart des réponses suggèrent RESEED à 0, mais plusieurs fois, nous devons simplement réamorcer le prochain ID disponible

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)

Cela vérifiera le tableau et réinitialisera l'ID suivant.


2
C'est la seule réponse qui fonctionne à 100%
Ingénieur inversé

3
Un peu plus court:declare @max int select @max=ISNULL(max([Id]),0) from [TestTable]; DBCC CHECKIDENT ('[TestTable]', RESEED, @max );
Guillermo Prandi

61

J'ai essayé de @anil shahsrépondre et cela a réinitialisé l'identité. Mais quand une nouvelle ligne a été insérée, elle a obtenu le identity = 2. Au lieu de cela, j'ai changé la syntaxe:

DELETE FROM [TestTable]

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

Ensuite, la première ligne obtiendra l'identité = 1.



16

Bien que la plupart des réponses suggèrent RESEEDà 0, et alors que certains voient cela comme un défaut pour les TRUNCATEDtables, Microsoft a une solution qui exclut laID

DBCC CHECKIDENT ('[TestTable]', RESEED)

Cela vérifiera le tableau et reviendra au suivant ID. Ceci est disponible depuis MS SQL 2005 jusqu'à la version actuelle.

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


1
Malheureusement, ce n'est pas vrai. Je viens de vérifier cela pour le serveur MS SQL 2014.
alehro

1
En fait, c'est vrai pour SQL 2014. Je viens de le tester et cela a fonctionné pour moi.
Daniel Dyson

2
Cela fonctionne de manière incohérente pour moi sur SQL 2012. Parfois, il utilise le prochain disponible comme je l'aurais prévu, parfois il semble rester bloqué sur une ancienne valeur de la table. Spécifier la graine fonctionne toujours.
Dan Field du

Ne fonctionne pas pour moi sur SQL 2016 - il laisse simplement la graine d'identité telle quelle. Cela a peut-être fonctionné correctement pour moi une fois, mais cela pourrait aussi être mon problème de doigt. Impossible de le faire fonctionner à nouveau
Ingénieur inversé

Le message indique le succès, Checking identity information: current identity value '[incorrect seed]', current column value '[correct seed]'.mais lors de nouvelles insertions, il utilise toujours la graine incorrecte.
Denziloe

7

l'émission de la commande 2 peut faire l'affaire

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

la première réinitialise l'identité à zéro et la suivante la remet à la prochaine valeur disponible - jacob


2
DBCC CHECKIDENT ('[TestTable]', RESEED) ne réamorce pas à la prochaine valeur disponible
Atal Kishore

Il s'agit de la méthode utilisée par RedGate Data Compare lorsque l'option "Réamorcer les colonnes d'identité" est activée. Je l'ai testé intensivement (je veux dire dans le code SQL, pas dans l'outil RedGate), et cela fonctionne de manière fiable. (Je n'ai aucun lien avec RedGate autre que d'être un utilisateur occasionnel de leurs versions d'essai)
Reversed Engineer

6

@Jacob

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

A fonctionné pour moi, je devais simplement effacer toutes les entrées du tableau, puis ajouter ce qui précède dans un point de déclenchement après la suppression. Maintenant, chaque fois que je supprime une entrée est prise de là.


DBCC CHECKIDENT n'est fonctionnel qu'après suppression. Vous pourriez aussi bien utiliser tronquer. Cependant, si vous avez besoin du reste des données, ne l'utilisez pas. Tronquer également ne donne pas un nombre d'enregistrements supprimés.
user763539

6

Truncate La table est préférée car elle efface les enregistrements, réinitialise le compteur et récupère l'espace disque.

Deleteet CheckIdentdoit être utilisé uniquement lorsque les clés étrangères vous empêchent de tronquer.


5

Réinitialiser la colonne d'identité avec un nouvel identifiant ...

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

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

4

C'est une question courante et la réponse est toujours la même: ne le faites pas. Les valeurs d'identité doivent être traitées comme arbitraires et, en tant que telles, il n'y a pas d'ordre "correct".


15
C'est vrai pour un environnement de production, mais pendant le développement, j'aime me rappeler que certaines entités ont un certain ID, qui sont remplies à partir d'un script d'amorçage. Cela facilite la navigation dans la base de données pendant le développement.
Francois Botha

7
De telles réponses sont complètement théoriques et répondent rarement aux besoins du monde réel. Que diriez-vous au lieu de laver le cerveau des gens avec votre dogme, vous répondez à la question OP ...
Serj Sagan

1
Pas mal ton histoire mec. Mon argument est le suivant: si vous souhaitez spécifier la valeur d'une colonne, ne choisissez pas une propriété sur la colonne qui rend cela difficile. L'odeur du code est la suivante: si chaque fois que vous insérez un enregistrement dans une table, vous spécifiez une valeur pour la colonne d'identité, vous n'avez pas de colonne d'identité. Le point d'identité tout entier est que le serveur crée une valeur pour vous. Donc, si vous remplacez ce temps, vous n'avez rien gagné pour un coût non nul. Aussi, bon travail sur l'argument ad hominem.
Ben Thul

5
Je suis certainement d'accord avec votre affirmation. En regardant la valeur nominale, le PO fait certainement du tort, mais il y a peut-être un besoin plus profond non indiqué dans le message que le PO ne jugeait pas pertinent pour obtenir une réponse à sa question. Répondez donc à la question et donnez des conseils sur les choses à faire et à ne pas faire dans le cadre de la réponse. Soit dit en passant, je n'ai jamais attaqué votre personnage ... ad hominem signifie que je vous ai appelé stupide ou quelque chose ...
Serj Sagan

1
Bien que cela soit certainement vrai dans la plupart des cas, il existe des circonstances dans lesquelles il est légitime de redéfinir une table. Par exemple, je travaille sur un projet entièrement nouveau qui doit partir d'un point certain pour tenir compte des lignes existantes dans le prédécesseur qu'il remplace. Reeseeding pendant le développement est un cas d'utilisation légitime, l'OMI.
David A. Gray

3

Exécutez ce script pour réinitialiser la colonne d'identité. Vous devrez apporter deux modifications. Remplacez tableXYZ par la table que vous devez mettre à jour. En outre, le nom de la colonne d'identité doit être supprimé de la table temporaire. C'était instantané sur une table de 35 000 lignes et 3 colonnes. Évidemment, sauvegardez la table et essayez d'abord cela dans un environnement de test.


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

3
Ce n'est pas tout à fait correct: SET IDENTITY_INSERT est au mauvais endroit. Il ne fait pas le tour du TRONCATE, il fait le tour de l'INSERT INTO (d'où l'identité_ INSERT ). En outre, cela doit être utilisé uniquement lorsque les données doivent être conservées, sinon il est très inefficace par rapport à l'exécution de la seule instruction TRUNCATE.
Solomon Rutzky

1
DBCC CHECKIDENT (<TableName>, reseed, 0)

Cela mettra la valeur d'identité actuelle à 0.

Lors de l'insertion de la valeur suivante, la valeur d'identité est incrémentée à 1.


1

Utilisez cette procédure stockée:

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'

Je reviens simplement sur ma réponse. Je suis tombé sur un comportement étrange dans SQL Server 2008 R2 que vous devez connaître.

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

La première sélection produit 0, Item 1.

Le second produit 1, Item 1. Si vous exécutez la réinitialisation juste après la création de la table, la valeur suivante est 0. Honnêtement, je ne suis pas surpris que Microsoft ne puisse pas corriger ce problème. Je l'ai découvert parce que j'ai un fichier script qui remplit les tables de référence que j'exécute parfois après avoir recréé les tables et parfois lorsque les tables sont déjà créées.


1

J'utilise le script suivant pour ce faire. Il n'y a qu'un seul scénario dans lequel cela produira une "erreur", c'est-à-dire si vous avez supprimé toutes les lignes de la table et qu'il IDENT_CURRENTest actuellement défini sur 1, c'est-à-dire qu'il n'y avait qu'une seule ligne dans la table pour commencer.

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)
;

0

Pour une suppression complète des lignes et réinitialiser le nombre IDENTITY, j'utilise ceci (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

0

Réinstaller à 0 n'est pas très pratique, sauf si vous nettoyez la table dans son ensemble.

sinon, la réponse donnée par Anthony Raymond est parfaite. Obtenez d'abord le maximum de la colonne d'identité, puis ajoutez-le à max.


0

J'ai essayé de faire cela pour un grand nombre de tables pendant le développement, et cela fonctionne comme un charme.

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

Ainsi, vous le forcez d'abord à être défini sur 1, puis vous le définissez sur l'index le plus élevé des lignes présentes dans le tableau. Reste rapide et facile de l'idex.


-2

Il est toujours préférable d'utiliser TRUNCATE lorsque cela est possible au lieu de supprimer tous les enregistrements car il n'utilise pas également l'espace de journal.

Dans le cas où nous avons besoin de supprimer et de réinitialiser la graine, rappelez-vous toujours que si la table n'a jamais été remplie et que vous l'avez utilisée, DBCC CHECKIDENT('tablenem',RESEED,0) le premier enregistrement obtiendra une identité = 0 comme indiqué dans la documentation msdn

Dans votre cas, reconstruisez uniquement l'index et ne vous inquiétez pas de perdre la série d'identités car il s'agit d'un scénario courant.


3
Pour moi, l'idée est de ne supprimer que certains enregistrements.
Drumbeg

6
C'est tout simplement faux - il n'est pas <i> TOUJOURS </i> préférable d'utiliser tronquer et, en fait, n'est meilleur que dans certains scénarios très limités et spécifiques. Le ciel interdit à quelqu'un de suivre vos conseils et de revenir en arrière.
Thronk

1
@Thronk Pourquoi voulez-vous dire que TRUNCATEcela empêcherait ROLLBACKde se comporter comme prévu? ROLLBACK annule toujours. Même si la base de données est définie sur BULK_LOGGED.
Solomon Rutzky

2
TRUNCATE est une opération DDL et il n'est pas connecté au fichier journal. Sauf si cela fait partie de la transaction (non mentionné nulle part dans la question ou dans cette réponse). Chaque fois que quelqu'un dit que quelque chose est TOUJOURS vrai, il y a fort à parier qu'il a tort.
Thronk

C'est la seule réponse qui note qu'il existe une différence dans le comportement RESEED selon que la séquence a été utilisée précédemment ou non. Un réamorçage de la même valeur sur plusieurs tables vides , où certaines tables ont été précédemment remplies, entraînera des valeurs initiales différentes pour le premier enregistrement inséré dans chaque table.
simon coleman

-4

Première: Spécification d'identité Juste: "Non" >> Enregistrer le projet d'exécution de la base de données

Après cela: Spécification d'identité Juste: "OUI" >> Enregistrer le projet d'exécution de la base de données

Votre ID de base de données, PK À partir de 1 >>

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.