Dépannage de l'erreur "Fixation d'une entité de type 'ModelName' a échoué" dans ASP.NET MVC Edit Actions
L'erreur redoutée "attacher une entité d'erreur de type" nom "a échoué" dans ASP.NET MVC survient généralement lors de la tentative de mise à jour d'un enregistrement de base de données qui se trouve dans un état détaché. Ce message d'erreur indique généralement un décalage de clé primaire, suggérant que l'entité est traitée comme nouvelle au lieu d'un enregistrement existant. La solution consiste à gérer correctement l'état de l'entité dans le cadre de l'entité.
Ce problème fait souvent surface lors des actions de poste de modification. L'entité est initialement récupérée, marquée comme «modifiée», mais un appel de méthode ultérieur (avant la mise à jour de l'État) pourrait réaccéder par inadvertance à la même entité, le détachant ainsi.
La clé pour résoudre ceci est d'empêcher le suivi des entités involontaire avant de modifier son état. La méthode AsNoTracking()
de l'entité Framework fournit la solution.
Voici comment résoudre le problème, démontrant l'utilisation de AsNoTracking()
dans une méthode canUserAccessA
modifiée:
<code class="language-csharp">private bool canUserAccessA(int aID) { int userID = WebSecurity.GetUserId(User.Identity.Name); // Disable tracking to prevent state conflicts int aFound = db.Model.AsNoTracking().Where(x => x.aID == aID && x.UserID == userID).Count(); return (aFound > 0); }</code>
En incorporant AsNoTracking()
, la méthode canUserAccessA
récupère maintenant l'entité sans modifications de suivi. Cela empêche l'interférence avec l'état de l'entité pendant la modification après l'action, éliminant efficacement l'erreur "attacher une entité". Cela garantit que l'affectation d'état Modified
ultérieure fonctionne correctement.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!