Sql Server 2005 violation de clé primaire sur une colonne d'identité

Question

Je rencontre un problème étrange, et j'ai besoin d'aide pour essayer de le comprendre.

J'ai une base de données qui a une colonne ID (définie comme int null, Identity, commence à 1, incrémente de 1) en plus de toutes les colonnes de données d'application. La clé primaire de la table est la colonne ID, pas d'autres composants.

Il n'y a pas d'ensemble de données que je puisse utiliser en tant que «clé primaire naturelle» puisque l'application doit permettre plusieurs soumissions de données identiques.

je une procédure stockée, qui est la seule façon d'ajouter de nouveaux enregistrements dans la table (autres que la connexion au serveur directement en tant que propriétaire db)

Alors que QA testait l'application ce matin, ils à entrer un nouvel enregistrement dans la base de données (en utilisant l'application comme il était prévu, et comme ils l'ont fait pendant les deux dernières semaines) et a rencontré une violation de clé primaire sur cette table.

C'est de la même manière que je fais les clefs primaires depuis environ 10 ans maintenant, et n'ai jamais couru à travers ceci.

Des idées pour résoudre ce problème? Ou est-ce un de ces problèmes de rayons cosmiques qui apparaissent une fois de temps en temps.

Merci pour tout conseil que vous pouvez donner.

Nigel

Edité à 13h15 HAE 12 Juin pour donner plus d'informations

Une version simplifiée du schéma ...

CREATE TABLE [dbo].[tbl_Queries](
[QueryID] [int] IDENTITY(1,1) NOT NULL, 
[FirstName] [varchar](50) NOT NULL, 
[LastName] [varchar](50) NOT NULL, 
[Address] [varchar](150) NOT NULL, 
[Apt#] [varchar](10) NOT NULL 
    ... <12 other columns deleted for brevity> 
[VersionCode] [timestamp] NOT NULL, 
CONSTRAINT [PK_tbl_Queries] PRIMARY KEY CLUSTERED 
(
    [QueryID] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] 

(également supprimé les déclarations de valeur par défaut) La procédure stockée est la suivante:

insert into dbo.tbl_Queries 
    ( FirstName, 
     LastName, 
     [Address], 
     [Apt#]...) values 
    ( @firstName, 
     @lastName, 
     @address, 
     isnull(@apt, ''), ...) 

Il ne regarde même pas la colonne d'identité, n'utilise pas IDENTITY, @@ scope_identity ou quelque chose de similaire, c'est juste un fichier et oubliez.

Je suis aussi confiant que possible que la valeur d'identité n'a pas été réinitialisée et que personne d'autre n'utilise l'accès direct à la base de données pour entrer des valeurs. La seule fois dans ce projet que l'insertion d'identité est utilisée est dans le déploiement de base de données initiale pour définir des valeurs spécifiques dans les tables de recherche.

L'équipe de contrôle qualité a réessayé après avoir reçu l'erreur et a réussi à soumettre une requête. Depuis, elle tente de la reproduire et n'a pas réussi jusqu'à présent.

J'apprécie vraiment les idées des gens.

Answer 1

pensée aléatoire basé sur l'expérience

Avez-vous des données avec synched, par exemple, Comparer Red Gate Data. Cela a une option pour réanimer les colonnes d'identité. Cela a causé des problèmes à utiliser. Et un autre projet le mois dernier.

Vous pouvez également avoir des ID explicitement chargés/synchronisés.

Answer 2

Bien que je n'ai pas d'explication quant à une cause potentielle, il est certinalement possible de changer la valeur initiale d'une colonne d'identité. Si la graine était abaissée à l'endroit où la valeur suivante existerait déjà dans le tableau, cela pourrait certainement causer ce que vous voyez. Essayez de courir DBCC CHECKIDENT (table_name) et voir ce qu'il vous donne.

Pour plus d'informations, consultez this page

Answer 3

Sons comme la graine d'identité a été corrompu ou remis à zéro en quelque sorte. solution la plus simple sera de réinitialiser la graine à la valeur actuelle max de la colonne d'identité:

DECLARE @nextid INT; 
SET @nextid = (SELECT MAX([columnname]) FROM [tablename]); 
DBCC CHECKIDENT ([tablename], RESEED, @nextid); 

Answer 4

Peut-être que quelqu'un d'insérer des enregistrements de journalisation dans le serveur en utilisant directement un nouvel ID explicity, puis lorsque le champ d'incrémentation automatique d'identité atteindre ce numéro une violation de clé primaire s'est produite.

Mais le rayon cosmique est algo une bonne explication;)

Answer 5

Juste pour très, très sûr ... vous n'utilisez pas IDENTITY_INSERT dans votre procédure stockée êtes-vous? Une certaine logique comme ceci:

declare @id int; 
Set @id=Select Max(IDColumn) From Sometable; 
SET IDENTITY_INSERT dbo.SomeTable ON 
Insert (IDColumn, ...others...) Values (@id+1, ...others...); 
SET IDENTITY_INSERT dbo.SomeTable OFF 
. 
. 
. 

Je me sens collant juste en le tapant. Mais de temps en temps vous rencontrez des gens qui n'ont jamais vraiment compris ce qu'est une colonne Identité et je veux m'assurer que c'est exclu. En passant: si c'est la réponse, je ne vous en tiendrai pas rigueur si vous supprimez simplement la question et n'admettez jamais que c'était votre problème! Pouvez-vous dire que j'embauche des stagiaires tous les étés?

Answer 6

Utilisez-vous des fonctions telles que @@ identity ou scope_identity() dans l'une de vos procédures? si votre table a des déclencheurs ou plusieurs inserts vous pourriez obtenir en arrière la valeur fausse identité pour la table que vous voulez

Answer 7

Espérons que ce n'est pas le cas, mais il y a un bug connu dans SQL 2005 avec SCOPE_IDENTITY(): http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=328811

Answer 8

La violation de clé primaire ne provient pas nécessairement de cette table.

L'application touche-t-elle d'autres tables ou appelle-t-elle d'autres procédures stockées pour cette fonction? Y a-t-il des déclencheurs sur la table? Ou la procédure stockée elle-même utilise-t-elle d'autres tables ou procédures stockées? En particulier, une table ou un déclencheur d'audit peut provoquer cette erreur.