L'exigence de clé primaire LINQ to SQL échoue

Question

Je travaille sur une meilleure compréhension de Linq-to-SQL avant de l'utiliser sur un projet réel, donc je joue avec un petit projet parallèle. J'ai une table que j'essaie de mettre à jour via DataContext.SubmitChanges() et elle échoue en raison de contraintes de clé primaire.

Je n'ai aucun contrôle sur la table elle-même (je ne peux pas ajouter une colonne ID réelle), donc j'ai plutôt modifié l'entité Linq pour utiliser 3 colonnes comme une clé complexe. Les insertions échouent toujours, même si les données clés sont uniques à la fois dans l'ensemble de mise à jour et dans les données existantes dans la table, et je suis curieux de savoir pourquoi. Qu'est-ce qui me manque qui force Linq à traiter ces valeurs comme non uniques?

Notez que je n'essaie pas de résoudre le problème de mise à jour lui-même - J'ai déterminé que dans ma situation DataContext.ExecuteCommand() fonctionnera tout aussi bien. J'essaie de comprendre où ma compréhension de Linq (ou de mes données) est fausse.

La structure de la table ressemble à ceci: OPRID (char (30)) DATE (DateTime) PROJECT_ID (char (15)) HEURES (décimal)

Les 3 dernières colonnes sont la clé complexe.

Et voici quelques exemples de données, séparées par des virgules: cschlege, 05/01/2009, 10100, 0,8 cschlege, 05/01/2009, 10088, 1.1 cschlege, 05/01/2009, 10099, 0,8 cschlege, 2009-1-5, 10088, 1.2

Le SubmitChanges() échoue systématiquement sur la dernière de ces lignes, mais étant donné une clé de DATE, PROJECT_ID, HOURS ces lignes doivent être uniques. Il n'échoue pas sur la 3ème ligne, qui a une duplication dans la colonne HOURS, mais seulement quand il atteint le PROJECT_ID en double. Si je supprime PROJECT_ID de la clé complexe, l'insertion échoue sur la 3ème ligne, cependant.

Pourquoi LINQ ne traite-t-il pas ces lignes comme étant uniquement codées?

Answer 1

Ah. La réponse est que je ne suis pas assez attentif aux règles du backing store. Il y a un autre index qui échoue.

Answer 2

Compte tenu de votre explication je suppose que les heures (décimales) est le problème ... Il doit être mappé d'une manière ou d'une autre avec une précision différente.

Si 1,2 tours à 1 alors vous avez un problème avec:

cschlege, 05/01/2009, 10088, (2)

cschlege, 05/01/2009, 10088, (4)

Comme vous l'avez dit, si vous supprimez l'ID de projet vous vous retrouvez avec l'échec de la 3e rangée:

cschlege, 05/01/2009, , (1)

cschlege, 05/01/2009, , (3)

Pouvez-vous simplement insérer la dernière ligne de la DB, puis confirmer est avec 1,2?