violation de la contrainte de clé primaire, uniquement lors du déploiement de la BD via vsdbcmd

Question

J'utilise VS 2010 Premium RTMRel (10.0.30319.1) et SS2008. J'ai une base de données qui se construit AOK et a un post déploiement script qui charge quelques données échantillons. Lorsque je construis et déploie cette base de données via l'interface utilisateur VS, elle fonctionne parfaitement. Lorsque j'essaie de le déployer via vsdbcmd, il échoue sur la population de données avec des erreurs comme celles-ci :

** * SQL01268 C:\source\mydatabase.sql (5197,0) Fournisseur de données .Net SqlClient : Msg 2627, Level 14, State 1, Line 227 Violation de la contrainte PRIMARY KEY 'pk_customers'. Impossible d'insérer une clé dupliquée dans l'objet 'dbo.customers'. * *

À des fins de démonstration, j'essaie d'alimenter un enregistrement spécifique dans la table des clients et je surcharge la propriété IDENTITY de la colonne id pour définir une valeur de mon choix. Les lignes pertinentes de mon script post-déploiement sont les suivantes :

SET IDENTITY_INSERT [dbo].[customers] ON
INSERT INTO [dbo].[customers] ([id], [name], [notes]) VALUES ( 10001, N'ABC Co', NULL )
SET IDENTITY_INSERT [dbo].[customers] OFF

Quelqu'un sait-il pourquoi je peux remplacer la colonne IDENTITY (en utilisant SET IDENTITY INSERT ON) via l'interface utilisateur, mais pas via la ligne de commande ?

Et non, il est impossible qu'il y ait déjà un enregistrement dans la table des clients avec id = 10001. Il n'y a aucun autre enregistrement (ou insertion) dans la table.

Je pense que la partie "duplicate key in object" du message d'erreur est complètement fausse, et qu'elle s'oppose à ce que j'essaie de mettre ma propre valeur dans la colonne PK.

La contrainte PK a les valeurs par défaut standard. Si je modifie les valeurs par défaut et que je définis IGNORE_DUP_KEY = ON, le déploiement en ligne de commande fonctionne. Mais je ne veux pas avoir à le faire.

Toute idée ou suggestion est la bienvenue.

Answer 1

OK, c'est embarrassant.

Il s'est avéré que mon script post-déploiement avait une instruction USE qui spécifiait le nom de la BD par défaut (appelée MobileDB). Lorsque je construisais via l'interface utilisateur, j'utilisais également ce nom MobileDB, la configuration de déploiement recréait toujours la base de données, et donc tout fonctionnait bien.

Cependant, lors du déploiement à partir de vsdbcmd, j'ai utilisé un nom de base de données aléatoire (comme ChickenSoup). Ainsi, lorsque la population de données script s'est exécutée, elle a essayé de réécrire dans MobileDB, en touchant les données qui étaient déjà là, et en échouant avec une violation d'une contrainte PK.

Erreur classique de l'utilisateur.