Resetowanie sekwencji SQL Server 2012

Jestem w trakcie testowania i wypełniania określonej tabeli, która wykorzystuje SEQUENCEobiekt. W tym procesie testuję zapełnianie tabeli dziesiątkami tysięcy linii wstawiania (ponieważ nie jestem zaznajomiony z tym, jak to programować). Problem, który widzę w tej konkretnej tabeli, polega na tym, że kiedy rozpoczynam kolejny test populacji, SEQUENCEnie resetuje się z powrotem do pierwszego numeru, który chcę (czyli 1).

Kiedy chcę ponownie uruchomić nowy test, usuwam przedmiotową tabelę, a następnie uruchamiam następujące czynności:

DROP SEQUENCE foo.fee;
GO

DROP SCHEMA foo;
GO

Kiedy chcę ponownie uruchomić test, uruchamiam następujące polecenia SCHEMAi SEQUENCEpolecenia, które są uruchamiane w następującej kolejności:

CREATE SCHEMA foo;
GO

CREATE SEQUENCE foo.fee
START WITH 1
INCREMENT BY 1
NO CYCLE
NO CACHE;

GO

Następnie tworzę tabelę:

CREATE TABLE foo.sample_table_with_data
(order_number bigint PRIMARY KEY NOT NULL,
sample_column_one nvarchar(max) NULL,
sample_column_two nvarchar(max) NULL,
sample_column_three nvarchar(max) NULL)

GO

Po zakończeniu uruchomię następujące polecenie wstawiania 50 000 razy:

INSERT INTO [foo].[sample_table_with_data] 
(
    [order_number],
    [sample_column_one], 
    [sample_column_two], 
    [sample_column_three]
) 
VALUES 
(
    NEXT VALUE FOR foo.fee, 
    'Blah', 
    'Blah Blah', 
    'Blah Blah Blah'
)

Teraz absolutnie nie ma problemu z wprowadzaniem danych do tabeli. Wyzwanie, z którym się spotykam, polega na tym, że kiedy usuwam tabelę, upuszczam schemat i sekwencję, a następnie ponownie tworzę tabelę, sekwencję i schemat, który SEQUENCEodbiera od ostatniego numeru w poprzednim wcieleniu bazy danych i nie resetuje z powrotem do jednego.

Na przykład, jeśli ostatnią liczbą w sekwencji jest powiedzmy 634 534, następnym numerem sekwencji w nowej tabeli jest 634 535.

Po usunięciu tabeli i upuszczeniu schematu i sekwencji wykonuję następujące czynności, aby sprawdzić usunięcie sekwencji i schematu:

SELECT * FROM INFORMATION_SCHEMA.SCHEMATA
GO

SELECT * FROM sys.sequences
GO

Jestem zaskoczony, dlaczego tak się dzieje. Czy brakuje mi tutaj innego polecenia, które pomogłoby mi zlokalizować, co dokładnie się tutaj dzieje?

Powinienem zauważyć, że ta tabela należy do bazy danych z 7 innymi tabelami, w których SEQUENCEpoprawnie uruchomiono polecenie.

Jest to instalacja SQL 2012 SP1 Enterprise Edition.

Próbować

ALTER SEQUENCE foo.fee
RESTART

Lub:

ALTER SEQUENCE foo.fee
RESTART WITH 1

http://msdn.microsoft.com/en-us/library/ff878572.aspx

Używanie skryptu z kilkoma drobnymi zmianami:

CREATE SCHEMA foo;
GO
CREATE SEQUENCE foo.fee
START WITH 1
INCREMENT BY 1
NO CYCLE
NO CACHE;
GO
CREATE TABLE foo.sample_table_with_data
(order_number bigint PRIMARY KEY NOT NULL,
sample_column_one nvarchar(max) NULL,
sample_column_two nvarchar(max) NULL,
sample_column_three nvarchar(max) NULL)
GO
SET NOCOUNT ON
GO
INSERT INTO [foo].[sample_table_with_data]
    ([order_number],[sample_column_one],[sample_column_two],[sample_column_three]) 
VALUES
    (NEXT VALUE FOR foo.fee,'Blah','Blah Blah','Blah Blah Blah')
GO 50000
SELECT
    MIN(order_number), 
    MAX(order_number)
FROM foo.sample_table_with_data AS stwd
GO
DROP SEQUENCE foo.fee;
GO
DROP TABLE foo.sample_table_with_data
GO
DROP SCHEMA foo;

... Nie mogę odtworzyć problemu na SQL Server 2012 SP1 (kompilacja 3000) lub nowszy.

Nie mogę również znaleźć elementu Connect ani artykułu z bazy wiedzy wspominającego ten konkretny scenariusz (i było wiele innych SEQUENCEproblemów). Nie oznacza to, że nie istniało przed SP1, ponieważ nie wszystkie poprawki zostały udokumentowane.