Comment ne pas violer cette key primaire lors de la synchronisation avec Azure?

Résumé du projet

Nous créons une cuisine «numérique» où il est possible d'append quels articles sont dans votre réfrigérateur, congélateur, etc. Puis il est possible de voir ces articles sur une application web, de sorte que vous savez ce que vous avez dans votre cuisine lors de vos déplacements.

La database

Au total, il y a trois tables.

Listes

Cela contient ListIDs et les noms de ces lists, comme «Réfrigérateur» ou «Freezer». Donc, c'est essentiellement le «conteneur».

Articles

Ensuite, il y a des objects qui contiennent des types d'objects, par exemple du lait, 1 gallon.

ListItems

Ensuite, il y a ListItems (désolé pour un nom légèrement confus) qui contient des éléments spécifiques . Alors que Items est juste une table d'éléments qui peuvent être ajoutés, ListItems sont les éléments ajoutés . Ainsi, les lignes ajoutées à cette table ont naturellement une key étrangère à la fois pour une table List sur les lists et une key étrangère pour un élément sur la table Items . La key primaire de cette table est une super-key, composée de presque tous ses attributes.

Deux ListItems peuvent faire reference au même élément et à la même list , à condition qu'ils aient des attributes différents. Ils pourraient expirer à des dates différentes ou être de tailles différentes. La seule chose qui rend un élément unique est le nom, comme si vous ajoutiez un 'Ham', il ne replaceait jamais un 'Milk'. Ajouter un autre «lait» serait alors considéré comme le même

Le problème

Voici un exemple. Vous voulez append deux éléments séparés. Le premier est 3 jambons, chacun 200 g qui expire le 28 mai. Le prochain est un autre jambon, celui-ci seul, mais 500g et expire le 31 mai: entrez la description de l'image ici

ListID 1 fait reference à la list appelée Fridge. ItemID 1 se réfère à l'élément qui s'appelle Ham .

Voir le problème? Les foreign keys sont les mêmes.

Il se conserve très bien sur notre database locale, mais lors de la synchronisation avec une database Azure, nous obtenons l'erreur suivante:

{"Violation of PRIMARY KEY constraint 'PK__#A4D1762__44A4C03D49E5E4B8'. Cannot insert duplicate key in object 'dbo.@changeTable'. The duplicate key value is (1, 1).\r\n The data for table-valued parameter \"@changeTable\" doesn't conform to the table type of the parameter. SQL Server error is: 3602, state: 30\r\nThe statement has been terminated."} 

Est-ce une mauvaise design de database ou un problème Azure?

Mise à jour 1

Voici comment le DDL regarde sur la database locale:

 CREATE TABLE [dbo].[ListItems] ( [ListId] INT NOT NULL, [ItemId] INT NOT NULL, [Amount] INT NOT NULL, [Volume] INT NOT NULL, [Unit] NVARCHAR(MAX) NULL, [ShelfLife] DATETIME NOT NULL, CONSTRAINT [pk_ListItems] PRIMARY KEY CLUSTERED ([ShelfLife], [Volume], [Amount], [ItemId], [ListId]), CONSTRAINT [fk_ListItems] FOREIGN KEY ([ListId]) REFERENCES [dbo].[Lists] ([ListId]) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT [fk_ListItems2] FOREIGN KEY ([ItemId]) REFERENCES [dbo].[Items] ([ItemId]) ON DELETE CASCADE ON UPDATE CASCADE ); 

Et la database Azure DDL:

 CREATE TABLE [dbo].[ListItems] ( [ListId] INT NOT NULL, [ItemId] INT NOT NULL, [Amount] INT NOT NULL, [Volume] INT NOT NULL, [Unit] NVARCHAR (MAX) NULL, [ShelfLife] DATETIME NOT NULL, CONSTRAINT [PK_dbo.ListItems] PRIMARY KEY CLUSTERED ([ListId] ASC, [ItemId] ASC, [Amount] ASC, [Volume] ASC, [ShelfLife] ASC), CONSTRAINT [FK_dbo.ListItems_dbo.Items_ItemId] FOREIGN KEY ([ItemId]) REFERENCES [dbo].[Items] ([ItemId]) ON DELETE CASCADE, CONSTRAINT [FK_dbo.ListItems_dbo.Lists_ListId] FOREIGN KEY ([ListId]) REFERENCES [dbo].[Lists] ([ListId]) ON DELETE CASCADE ); 

La ligne PK CONSTRAINT est légèrement différente, mais les attributes sont les mêmes. Est-ce que ceci pourrait être le problème?

Je ne pense pas que l'erreur soit là où vous pensez que c'est. Si le PK sur les ListItems local et Azure nomme les mêmes colonnes (indépendamment de l'ordre), elles sont identiques. Le message d'erreur, cependant, mentionne une définition PK différente (et un nom de table différent):

Violation of PRIMARY KEY constraint 'PK__#A4D1762__44A4C03D49E5E4B8'. Cannot insert duplicate key in object 'dbo.@changeTable'. The duplicate key value is (1, 1).

Il semble y avoir une table dont le nom est "@changetable" – qui ressemble à un paramètre de procédure de magasin pour moi – qui est défini avec une key primaire à deux colonnes. Suivez-le et vous pourrez résoudre le problème.