59 votes

System.Data.Linq.ChangeConflictException: ligne introuvable ou modifiée

Je suis en train de supprimer un gridview ligne à l'aide de LINQ (Pas de LINQDataSource). lorsque la sélection est modifiée, le contrôle detailsview de liaison est changé aussi. Je peux ajouter une nouvelle entrée dans la base de données, mais quand j'ai ajouté ce code pour supprimer un bouton à l'intérieur de l'updatePanel, j'ai eu une exception:

try
{           
    var query = from i in db.QuestionModules 
                where i.QuestionModuleID == QuestionModuleID 
                select i;

    QuestionModule o = query.First();
    db.QuestionModules.DeleteOnSubmit(o);
    db.SubmitChanges();
}

c'est l'exception-je obtenir:

System.Data.Linq.ChangeConflictException: Row not found or changed. at
System.Data.Linq.ChangeProcessor.SubmitChanges(ConflictMode
failureMode) at
System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
at System.Data.Linq.DataContext.SubmitChanges() 

j'ai eu ce problème pendant environ une semaine, et peu importe ce que je fais, ses encore là, et l'enregistrement ne marche pas supprimés. toutes les idées sur quoi faire?

69voto

Mark Points 5924

OK - il semble que (dans mon cas au moins) la réponse était de mettre tous les biens non colonne de clé primaire UpdateCheck à jamais dans le fichier DBML. Faire cela a immédiatement résolu le problème de "Ligne non trouvée ou modifiée".

Étant donné la rumeur selon laquelle Microsoft est en train de faire taire Linq-To-Sql en faveur de Entity Framework, on peut se demander si ce type de bugs sera corrigé?

51voto

SemMike Points 595

Vous obtenez probablement cette erreur parce que l'un de vos champs a quelque chose de différent dans le concepteur Linq To SQL et dans la base de données réelle.

Dans mon cas, c’est parce que l’un des champs était nullable dans la base de données et non nullable dans le concepteur, ce qui le rendait nullable dans le concepteur et résolvait le problème immédiatement.

15voto

Mark Points 5924

Je vais avoir le même problème, et suis tombé sur ce blog, qui stipule essentiellement que Linq-to-Sql a eu un problème dans l'accès concurrentiel optimiste où:

  1. Haute précision de type datetime champs sont utilisés. La solution est de mettre UpdateCheck jamais pour que la colonne de votre fichier DBML
  2. GridView colonnes qui sont invisibles sont l'accès à une propriété sur l'objet de données (cette seconde raison n'a pas de sens, mais il semble être à la mode sur ce blog).

Je n'ai pas essayé ces solutions encore, mais après revenir ici une fois que j'ai.

13voto

Le problème pourrait également être simplement que la définition DBML de la table n'est pas cohérente avec le statut de la définition de la base de données. Je viens de retirer le modèle DBML et de le réinsérer dans la base de données, et cela a fonctionné.

J'espère que ça aide quelqu'un.

6voto

Travis Points 158

Semblait travailler dans ma situation. J'ai été la construction d'une mémoire qui n'ont jamais soumis de ligne qui ont eu plusieurs relations de clé étrangère pour les lignes dans les autres tables. Le InsertOnSubmit semblait fonctionner, mais un autre DeleteOnSubmit me donnait cette ligne ne trouve pas d'erreur. Je n'étais pas le remplissage de tous les champs dans la ligne que j'ai soumis, donc je ne sais pas si cela à quelque chose à voir avec cela, mais le marquage de tous de la table principale de la non-colonnes de clé primaire éliminé le message d'erreur.

Une autre pensée: - je considérer que le marquage d'une colonne UpdateCheck politique comme "Jamais" signifie qu'il n'est pas utilisé comme base pour les optimistes concurency vérification. Cela impliquerait que les deux utilisateurs peuvent écrire sur une ligne donnée avec des données différentes dans toute la colonne et les conflits ne seraient pas détectés...ce qui veut dire que le dernier utilisateur de soumettre la ligne serait de remplacer les valeurs de la précédente utilisateurs de soumission. J'ai recueilli de divers lecture en ligne qu'une solution partielle à ce problème est d'utiliser la méthode Refresh immédiatement avant la soumission de synchroniser toutes les modifications. Bien sûr, sans pesimistic de verrouillage sur la ligne il n'y a aucune garantie que la ligne ne sera pas toujours être changé entre l'Actualisation et de la Soumettre, mais dans la plupart des scénarios impliquant un grand nombre de bases de données ce serait rare.

Mise à jour: Sur la poursuite de l'examen, je pense que j'ai découvert un scénario qui peut affecter d'autres, alors j'ai pensé que je voudrais partager juste au cas où. Il s'avère qu'au moins une partie de la difficulté que j'ai eu avec SQL, LINQ est liée à des déclencheurs. Il semble que si vous soumettez une ligne à l'aide de SQL, LINQ et votre DBA a des déclencheurs conçu pour écrire des informations sur certaines colonnes de la ligne puis le SQL, LINQ modèle par défaut "Toujours" de déterminer que la ligne a été modifiée depuis votre dernière écriture. J'avais soumis partiellement peuplée de lignes et de notre DBA déclencheurs sont à combler certaines des colonnes de sorte que lorsque j'ai essayé de modifier la ligne dans notre code, on a senti un changement conflit sur la base des colonnes remplies par le déclencheur. J'étudie maintenant la meilleure façon de gérer cela, mais la modification de ces déclencher renseigné les champs à utiliser un UpdateCheck de la politique de la "Lors de Changé" ou "Jamais" travaillé pour moi. Espérons que cela aide.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: