Let’s demonstrate it.

We will create two tables and fill in some data. These tables are absolutely the same including the IDENTITY specification. The only difference is their name.

DROP TABLE IF EXISTS [dbo].[To_Be_Deleted]
DROP TABLE IF EXISTS [dbo].[To_Be_Truncated]
GO

CREATE TABLE [dbo].[To_Be_Deleted] (
	Id INT IDENTITY(1,1) NOT NULL PRIMARY KEY
)
GO
CREATE TABLE [dbo].[To_Be_Truncated] (
	Id INT IDENTITY(1,1) NOT NULL PRIMARY KEY
)
GO

INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
GO
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
GO

SELECT 'To_Be_Deleted', * FROM [dbo].[To_Be_Deleted] UNION ALL
SELECT 'To_Be_Truncated', * FROM [dbo].[To_Be_Truncated]
GO

We will also check the current identity value after data is inserted. It’s the same.

SELECT 'To_Be_Deleted',	'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Deleted]') UNION ALL
SELECT 'To_Be_Truncated', 'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Truncated]')
GO

Now is time to remove data from our tables. There is a difference coming: We will empty the first table via the DELETE command and the second one will be emptied using the TRUNCATE command.

DELETE FROM [dbo].[To_Be_Deleted]
TRUNCATE TABLE [dbo].[To_Be_Truncated]
GO

DBCC CHECKIDENT('[dbo].[To_Be_Deleted]', RESEED, 1)
DBCC CHECKIDENT('[dbo].[To_Be_Truncated]', RESEED, 1)
GO

SELECT 'To_Be_Deleted',	'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Deleted]') UNION ALL
SELECT 'To_Be_Truncated', 'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Truncated]')
GO

We will check the current identity value now: It’s the same.

Next, we will again insert some data into our tables. Exactly as before.

INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Deleted] DEFAULT VALUES
GO

INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
INSERT INTO [dbo].[To_Be_Truncated] DEFAULT VALUES
GO

SELECT 'To_Be_Deleted', * FROM [dbo].[To_Be_Deleted] UNION ALL
SELECT 'To_Be_Truncated', * FROM [dbo].[To_Be_Truncated]
GO

SELECT 'To_Be_Deleted', 'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Deleted]') UNION ALL
SELECT 'To_Be_Truncated', 'IDENT_CURRENT', IDENT_CURRENT('[dbo].[To_Be_Truncated]')
GO

If we will check data in both tables, there is the surprise immediately visible:

The table which was emptied using the DELETE command has the first identity value 2 whereas the second table emptied using the TRUNCATE command has the first identity value 1!

This difference is also approved via the IDENT_CURRENT() function.

I know that this behavior isn’t too intuitive at first look. But what is positive (only:) about it is that it’s properly documented at the right place in the DBCC CHECKIDENT() command description:

The current identity value is set to the new_reseed_value. If no rows have been inserted into the table since the table was created, or if all rows have been removed by using the TRUNCATE TABLE statement, the first row inserted after you run DBCC CHECKIDENT uses new_reseed_value as the identity. If rows are present in the table, or if all rows have been removed by using the DELETE statement, the next row inserted uses new_reseed_value + the current increment value.

To be honest, seniors should know, for sure. But juniors are spending hours investigating this based on my experience. There is a good comparison of DELETE vs TRUNCATE on sqlhack.com, but still, the RESEED issue isn’t clearly explained there.

CREATE TABLE dbo.SampleTable
(
    Id INT IDENTITY(0, -1) NOT NULL PRIMARY KEY
)
GO

INSERT dbo.SampleTable
    DEFAULT VALUES
GO 5

SELECT * FROM dbo.SampleTable
GO

Kromě záporného inkrementu může nastavit i zápornou výchozí hodnotu prvního záznamu, například takto:

CREATE TABLE dbo.SampleTable
(
    Id SMALLINT IDENTITY(-32768, 1) NOT NULL PRIMARY KEY
)
GO

INSERT INTO dbo.[SampleTable]
	DEFAULT VALUES
GO 5

SELECT * FROM dbo.[SampleTable]
GO

Záporná výchozí hodnota nám přináší obrovskou výhodu pro scénáře, kdy pracujeme například s rozsáhlými faktovými tabulkami a snažíme se ušetřit velikost uložených dat tím, že dimenzionální klíče budou mít co nejmenší datový typ, např. tiny nebo smallint. Pokud ale například počet členů naší dimenze bude někde mezi 30 a 60 tisíci, napadne nás, že již nemůžeme použít smallint datový typ, protože jeho maximální hodnota je 32,767. To ale není pravda, pokud si uvědomíme, že jeho minimální hodnota je -32,768, takže celkem včetně nuly lze do tohoto datového typu uložit 65,535 hodnot. A právě nastavením identity sloupce s výchozí hodnotou -32768 můžeme celý tento rozsah vyčerpat.

Hodnoty klíčů s negativním znamínkem můžou být pochopitelně ne úplně esteticky přijatelné a je třeba na znaménko myslet i při dotazech. Lehce vylepšit lze uvedenou situaci tím, že jako výchozí hodnotu zvolíme maximum 32767 a negativní inkrement a většina našich hodnot bude v kladném rozsahu.

CREATE TABLE dbo.SampleTable
(
    Id INT IDENTITY(0, -1) NOT NULL PRIMARY KEY
)
GO

INSERT dbo.SampleTable
    DEFAULT VALUES
GO 5

SELECT * FROM dbo.SampleTable
GO

We can also set value for the first loaded row (SEED) to be negative:

CREATE TABLE dbo.SampleTable
(
    Id SMALLINT IDENTITY(-32768, 1) NOT NULL PRIMARY KEY
)
GO

INSERT INTO dbo.[SampleTable]
	DEFAULT VALUES
GO 5

SELECT * FROM dbo.[SampleTable]
GO

Negative value of the first row has the advantage in case we are working with large tables and we will eliminate table size and storage usage by using the smallest datatype we can. In this case when we will start for example for SMALLINT datatype identity sequence from -32768, we can insert in this column 65,535 values and if your data fits into this range there is no reason to use INT in this case. For sure we should think all the time that (-) sign is presented there, but that´s not an issue for ORMs or properly parameterized queries.

@@IDENTITY

• vrací datový typ numeric (38,0)
• po dokončení INSERT, SELECT INTO nebo BULKCOPY vrací poslední hodnotu identity sloupce v tabulce
• pokud není v tabulce identity sloupec, vrací NULL
• pokud je vloženo více řádků a vygenerováno více identity hodnot, je vrácena poslední hodnota
• pokud dojde k odpálení triggeru, který zvýší identity hodnotu, je @@IDENTITY tato triggerem zvýšená hodnota
• @@IDENTITY se nevrací k předchozí hodnotě, pokud dojde k rolbacku nebo failu insertu – např. dojde-li k failu na IGNORE_DUP_KEY, identity pro danou tabulku se stále inkrementuje
• @@IDENTITY, SCOPE_IDENTITY a IDENT_CURRENT jsou shodné funkce, všechny vrací poslední hodnotu insertu do identity sloupce v tabulce
• @@IDENTITY a SCOPE_IDENTITY vrací poslední identity hodnotu vygenerovanou v kterékoliv tabulce aktuální session. SCOPE_IDENTITY vrací hodnotu pouze ve scope, @@IDENTITY nezávisle na scopu.
• IDENT_CURRENT není limitována session ani scopem, ale pouze konkrétní tabulkou, pro niž nezávisle vrací poslední identity
• @@IDENTITY platí pouze pro aktuální session na lokálním serveru. Nelze ji volat pro linkovaný nebo vzdálený server => je nutné vytvořit na vzdáleném serveru uloženou proceduru, v ní použít @@IDENTITY a volat ji v kontextu vzdáleného serveru
• není vhodné používat v replikacích – replikační triggery mohou ovlivnit identity hodnotu, protože není vráceno identity posledního řádku tabulky, ale identity řádku vloženého triggerem do replikačních tabulek => již existující procedury je nutné přepsat na SCOPE_IDENTITY()

SCOPE_IDENTITY()

•  vrací poslední identity hodnotu v rámci scopu => scopem se rozumí modul: uložená procedura, trigger, funkce nebo batch
• vrací numeric
• rozdíl mezi @@IDENTITY a SCOPE_IDENTITY: (BOL příklad)
  • For example, there are two tables, T1 and T2, and an INSERT trigger is defined on T1. When a row is inserted to T1, the trigger fires and inserts a row in T2. This scenario illustrates two scopes: the insert on T1, and the insert on T2 by the trigger.
  • Assuming that both T1 and T2 have identity columns, @@IDENTITY and SCOPE_IDENTITY will return different values at the end of an INSERT statement on T1. @@IDENTITY will return the last identity column value inserted across any scope in the current session. This is the value inserted in T2. SCOPE_IDENTITY() will return the IDENTITY value inserted in T1. This was the last insert that occurred in the same scope. The SCOPE_IDENTITY() function will return the null value if the function is invoked before any INSERT statements into an identity column occur in the scope.

IDENT_CURRENT()

•  vrací identity poslední operace pro specifickou tabulku a to nezávisle na session a scope
• použití: IDENT_CURRENT( ‘table_name’ )
• vrací numeric(38,0)
• pokud caller nemá práva na tabulku, vrací NULL nebo error
• pokud tabulka neexistuje, vrací NULL
• pokud je tabulka prázdná, vrací první identity seed
• pozor na rozdíl při mazání pomocí DELETE (neruší identity) a TRUNCATE (nuluje identity)
• odrolování transakce nebo chyba nikdy nevrací hodnotu identity => číslo zůstává inkrementované jako by transakce byla commitnuta

IDENT_INCR()

•  vrací velikost incrementu (např. 1)
• použití: IDENT_INCR ( ‘table_or_view’ )

IDENT_SEED()

• vrací počáteční hodnotu, od které startuje increment
• použití: IDENT_SEED ( ‘table_or_view’ )

DBCC CHECKIDENT

•  vrací počáteční hodnotu, od které startuje increment
• použití:
  • DBCC CHECKIDENT  ( table_name  [ , { NORESEED | { RESEED [ , new_reseed_value ] } } ])
    [ WITH NO_INFOMSGS ]
• zjistí aktuální hodnotu identity ve specifické tabulce a provede případně její změnu – umožňuje nastavit novou příští identity hodnotu pro tabulku
• tabulka musí obsahovat identity sloupec
• nelze tímto změnit inicializační seed hodnotu při vytvoření sloupce ani přeseedovat exitující data => na to je nutné vytvořit znovu identity sloupec
• příklad: DBCC CHECKIDENT (“HumanResources.Employee”, RESEED, 30);

DBCC CHECKIDENT ('dbo.SampleTable', RESEED, 0);