Entity Framework: "L'instruction Store update, insert ou delete a affecté un nombre inattendu de lignes (0)."
J'utilise Entity Framework pour remplir un contrôle de grille. Parfois, lorsque je fais des mises à jour, j'obtiens l'erreur suivante:
L'instruction Store update, insert ou delete a affecté un nombre inattendu de lignes (0). Les entités peuvent avoir été modifiées ou supprimées depuis le chargement des entités. Actualisez les entrées ObjectStateManager.
Je n'arrive pas à comprendre comment reproduire cela. Mais cela pourrait avoir un lien avec la proximité des mises à jour. Est-ce que quelqu'un a vu cela ou est-ce que quelqu'un sait à quoi se réfère le message d'erreur?
Edit: Malheureusement, je ne suis plus libre de reproduire le problème que je rencontrais ici, car je me suis éloigné de ce projet et je ne me souviens pas si j’ai finalement trouvé une solution, si un autre développeur l’a corrigée ou si j’ai corrigé le problème. Par conséquent, je ne peux accepter aucune réponse.
C'est un effet secondaire d'une fonctionnalité appelée concurrence simultanée optimiste.
Vous ne savez pas comment l’activer/le désactiver dans Entity Framework, mais en gros, il vous dit qu’entre le moment où vous avez extrait les données de la base de données et le moment où vous avez enregistré vos modifications, une autre personne a modifié les données pour le sauvegarder 0 lignes ont été mises à jour). En termes SQL, la clause update de leur requête where contient la valeur d'origine de chaque champ de la ligne et si 0 ligne est affectée, il sait que quelque chose ne va pas.
L'idée sous-jacente est que vous ne finirez pas par écraser un changement que votre application ne savait pas déjà arrivé - il s'agit fondamentalement d'une petite mesure de sécurité introduite par .NET dans toutes vos mises à jour.
Si c'est cohérent, il y a de fortes chances que cela se produise dans votre propre logique (EG: vous mettez à jour les données vous-même selon une autre méthode entre select et update), mais il pourrait simplement s'agir d'une situation de concurrence critique entre deux applications.
J'ai rencontré ceci et cela était dû au fait que le champ ID (clé) de l'entité n'était pas défini. Ainsi, lorsque le contexte est allé sauvegarder les données, il n'a pas pu trouver un ID = 0. Assurez-vous de placer un point d'arrêt dans votre instruction de mise à jour et de vérifier que l'ID de l'entité a été défini.
Du commentaire de Paul Bellora
J'ai eu ce problème exact, causé par l'oubli d'inclure l'ID caché entrée dans la page d'édition .cshtml
Wow, beaucoup de réponses, mais j'ai eu cette erreur quand j'ai fait quelque chose de légèrement différent que personne d'autre n'a mentionné.
En résumé, si vous créez un nouvel objet et dites à EF que sa modification est effectuée à l'aide du EntityState.Modified, il générera cette erreur car elle n'existe pas encore dans la base de données. Voici mon code:
MyObject foo = new MyObject()
{
someAttribute = someValue
};
context.Entry(foo).State = EntityState.Modified;
context.SaveChanges();
Oui, cela semble idiot, mais cela est dû au fait que la méthode en question utilisait auparavant foo, elle avait été créée plus tôt. Désormais, il ne lui est plus passé que someValue et crée foo lui-même.
Solution facile, il suffit de changer EntityState.Modified en EntityState.Added ou de modifier toute la ligne en:
context.MyObject.Add(foo);
Je faisais face à cette même erreur ... :) Puis je me suis rendu compte que j'oubliais de définir un
@Html.HiddenFor(model => model.UserProfile.UserId)
pour la clé primaire de l'objet en cours de mise à jour! J'ai tendance à oublier cette chose simple mais très importante!
A propos: HiddenFor est pour ASP.NET MVC.
Vérifiez si vous avez oublié l'attribut "DataKeyNames" dans GridView . C’est indispensable lorsque vous modifiez des données dans GridView.
http://msdn.Microsoft.com/en-us/library/system.web.ui.webcontrols.gridview.datakeynames.aspx
Le problème est causé par l'une des deux choses suivantes: -
Concurrency Mode: Fixed.. Vous avez essayé de mettre à jour une ligne avec une ou plusieurs propriétés. L'optimisme concurrentiel empêchait alors l'enregistrement des données. C'est à dire. certains ont modifié les données de ligne entre le moment où vous avez reçu les données du serveur et celui où vous avez sauvegardé vos données de serveur.- Vous avez essayé de mettre à jour ou de supprimer une ligne, mais celle-ci n'existe pas. Un autre exemple de personne qui modifie les données (dans ce cas, en les supprimant) entre une récupération, puis enregistrez OR, vous ne faites rien pour essayer de mettre à jour un champ qui n'est pas une identité (c.-à-d.
StoreGeneratedPattern = Computed) et cette ligne ne t existent.
J'ai eu la même erreur parce qu'une partie du PK était une colonne datetime et que l'enregistrement en cours d'insertion utilisait DateTime.Now comme valeur pour cette colonne. Entity Framework insère la valeur avec une précision milliseconde, puis recherche la valeur qu'il vient d'insérer également avec une précision milliseconde. Cependant, SqlServer avait arrondi la valeur à la seconde précision et le cadre de l'entité n'a donc pas pu trouver la valeur de précision en millisecondes.
La solution consistait à tronquer les millisecondes à partir de DateTime.Now avant l'insertion.
J'avais le même problème et @ webtrifusion réponse m'a aidé à trouver la solution.
Mon modèle utilisait l'attribut Bind(Exclude) sur l'ID de l'entité, ce qui faisait que la valeur de l'ID de l'entité était égale à zéro sur HttpPost.
namespace OrderUp.Models
{
[Bind(Exclude = "OrderID")]
public class Order
{
[ScaffoldColumn(false)]
public int OrderID { get; set; }
[ScaffoldColumn(false)]
public System.DateTime OrderDate { get; set; }
[Required(ErrorMessage = "Name is required")]
public string Username { get; set; }
}
}
j'ai eu le même problème, je suppose que cela a été causé par le RowVersion qui était null . Vérifiez que votre Id et votre RowVersion sont not null.
pour plus d'informations, reportez-vous à ce tutoriel
J'ai aussi rencontré cette erreur. Le problème qui s’est avéré a été causé par un déclencheur sur la table que j’essayais de sauvegarder. Le déclencheur a utilisé 'INSTEAD OF INSERT', ce qui signifie que 0 ligne n'a jamais été insérée dans cette table, d'où l'erreur. Heureusement, dans certains cas, la fonctionnalité de déclencheur était incorrecte, mais je suppose que cela pourrait être une opération valide qui devrait en quelque sorte être gérée dans le code. J'espère que cela aidera quelqu'un un jour.
Pendant l'édition, incluez l'id ou la clé primaire de l'entité en tant que champ caché dans la vue.
c'est à dire
@Html.HiddenFor(m => m.Id)
cela résout le problème.
De plus, si votre modèle inclut un élément non utilisé, incluez-le aussi et envoyez-le au contrôleur.
Vous devez inclure explicitement un BoundField de la clé primaire. Si vous ne voulez pas que l'utilisateur voie la clé primaire, vous devez le cacher via css:
<asp:BoundField DataField="Id_primary_key" ItemStyle-CssClass="hidden"
HeaderStyle-CssClass="hidden" />
Où "caché" est une classe dans css dont l'affichage est défini sur "none".
La ligne [DatabaseGenerated(System.ComponentModel.DataAnnotations.DatabaseGeneratedOption.None)] a fait l'affaire dans mon cas:
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.None)]
public int? SomeNumber { get; set; }
J'ai commencé à avoir cette erreur après avoir changé de modèle en premier en code en premier. J'ai plusieurs threads mettant à jour une base de données où certains pourraient mettre à jour la même ligne. Je ne sais pas pourquoi je n'ai pas eu de problème à utiliser model-first, supposons qu'il utilise une valeur par défaut différente.
Pour le gérer dans un endroit en sachant dans quelles conditions cela pourrait se produire, j'ai ajouté la surcharge suivante à ma classe DbContext:
using System.Data.Entity.Core.Objects;
using System.Data.Entity.Infrastructure;
public class MyDbContext: DbContext {
...
public int SaveChanges(bool refreshOnConcurrencyException, RefreshMode refreshMode = RefreshMode.ClientWins) {
try {
return SaveChanges();
}
catch (DbUpdateConcurrencyException ex) {
foreach (DbEntityEntry entry in ex.Entries) {
if (refreshMode == RefreshMode.ClientWins)
entry.OriginalValues.SetValues(entry.GetDatabaseValues());
else
entry.Reload();
}
return SaveChanges();
}
}
}
Appelez ensuite SaveChanges(true) le cas échéant.
@Html.HiddenFor(model => model.RowVersion)
Ma version en ligne était nulle, donc j'ai dû ajouter ceci à la vue Qui a résolu mon problème
J'ai eu cette erreur sporadiquement en utilisant une méthode async. N'est pas arrivé depuis que je suis passé à une méthode synchrone.
Erreurs sporadiquement:
[Authorize(Roles = "Admin")]
[HttpDelete]
[Route("file/{id}/{customerId}/")]
public async Task<IHttpActionResult> Delete(int id, int customerId)
{
var file = new Models.File() { Id = id, CustomerId = customerId };
db.Files.Attach(file);
db.Files.Remove(file);
await db.SaveChangesAsync();
return Ok();
}
Fonctionne tout le temps:
[Authorize(Roles = "Admin")]
[HttpDelete]
[Route("file/{id}/{customerId}/")]
public IHttpActionResult Delete(int id, int customerId)
{
var file = new Models.File() { Id = id, CustomerId = customerId };
db.Files.Attach(file);
db.Files.Remove(file);
db.SaveChanges();
return Ok();
}
Assurez-vous simplement que la table et le formulaire ont la clé primaire et edmx mis à jour.
j'ai trouvé que toutes les erreurs lors de la mise à jour étaient généralement dues à: - Pas de clé primaire dans la table - Pas de clé primaire dans la vue/le formulaire d'édition (par exemple, @Html.HiddenFor(m=>m.Id)
J'ai eu cette erreur lorsque je supprimais certaines lignes de la base de données (dans la boucle) et que je les ajoutais dans la même table.
La solution pour moi était de créer dynamiquement un nouveau contexte dans chaque itération de boucle.
J'ai eu le même problème… .. Dans mon cas, j'essayais de mettre à jour la clé primaire, ce qui n'est pas autorisé.
public void Save(object entity)
{
using (var transaction = Connection.BeginTransaction())
{
try
{
SaveChanges();
transaction.Commit();
}
catch (OptimisticConcurrencyException)
{
if (ObjectStateManager.GetObjectStateEntry(entity).State == EntityState.Deleted || ObjectStateManager.GetObjectStateEntry(entity).State == EntityState.Modified)
this.Refresh(RefreshMode.StoreWins, entity);
else if (ObjectStateManager.GetObjectStateEntry(entity).State == EntityState.Added)
Detach(entity);
AcceptAllChanges();
transaction.Commit();
}
}
}
J'ai aussi eu cette erreur. Dans certaines situations, l'entité peut ne pas être au courant du contexte de base de données que vous utilisez ou le modèle peut être différent. Pour cela, définissez: EntityState.Modified; à EntityState.Added;
Pour faire ça:
if (ModelState.IsValid)
{
context.Entry(yourModelReference).State = EntityState.Added;
context.SaveChanges();
}
Cela garantira que l’entité sait que vous utilisez ou ajoutez l’État avec lequel vous travaillez. À ce stade, toutes les valeurs de modèle correctes doivent être définies. Veillez à ne pas perdre les modifications éventuellement apportées en arrière-plan.
J'espère que cela t'aides.
Eh bien, j'ai le même problème. Mais c'était dû à ma propre erreur. En fait, je sauvais un objet au lieu de l'ajouter. C'était donc le conflit.
Une façon de déboguer ce problème dans un environnement serveur SQL consiste à utiliser SQL Profiler fourni avec votre copie de SQL Server, ou si vous utilisez la version Express, obtenez gratuitement une copie de Express Profiler auprès de CodePlex en suivant le lien ci-dessous:
En utilisant SQL Profiler, vous pouvez avoir accès à tout ce qui est envoyé par EF à la base de données. Dans mon cas, cela équivaut à:
exec sp_executesql N'UPDATE [dbo].[Category]
SET [ParentID] = @0, [1048] = NULL, [1033] = @1, [MemberID] = @2, [AddedOn] = @3
WHERE ([CategoryID] = @4)
',N'@0 uniqueidentifier,@1 nvarchar(50),@2 uniqueidentifier,@3 datetime2(7),@4 uniqueidentifier',
@0='E060F2CA-433A-46A7-86BD-80CD165F5023',@1=N'I-Like-Noodles-Do-You',@2='EEDF2C83-2123-4B1C-BF8D-BE2D2FA26D09',
@3='2014-01-29 15:30:27.0435565',@4='3410FD1E-1C76-4D71-B08E-73849838F778'
go
J'ai copié ceci collé dans une fenêtre de requête dans Sql Server et exécuté. Bien sûr, bien qu’elle ait été exécutée, 0 enregistrement a été affecté par cette requête, de sorte que l’erreur renvoyée par EF.
Dans mon cas, le problème a été causé par le CategoryID.
Il n'y a pas eu d'identificateur de catégorie identifié par l'ID EF envoyé à la base de données, donc 0 enregistrements ont été affectés.
Ce n’est pas la faute de EF, c’est un buggy qui a fusionné "??" déclaration dans un contrôleur de vue qui envoyait un non-sens au niveau des données.
Je suis tombé sur ce problème sur une table dans laquelle il manquait une clé primaire et qui contenait une colonne DATETIME (2, 3) (la "clé primaire" de l'entité était donc une combinaison de toutes les colonnes) ... Lors de l'insertion, l'horodatage avait une heure plus précise (2018-03-20 08: 29: 51.8319154) qui a été tronquée à (2018-03-20 08: 29: 51.832) pour que la recherche sur les champs clés échoue.
Aucune des réponses ci-dessus n’a couvert ma situation et sa solution.
Code dans lequel l'erreur s'est produite dans le contrôleur MVC5:
if (ModelState.IsValid)
{
db.Entry(object).State = EntityState.Modified;
db.SaveChanges(); // line that threw exception
return RedirectToAction("Index");
}
J'ai reçu cette exception lorsque je sauvegardais un objet dans une vue Modifier. Cela s’explique par le fait que, lorsque je l’ai sauvegardé, j’avais modifié les propriétés qui constituaient la clé primaire de l’objet. Par conséquent, définir son état sur Modifié n’a aucun sens pour EF: c’est une nouvelle entrée, pas une entrée précédemment enregistrée.
Vous pouvez résoudre ce problème soit en A) en modifiant l'appel de sauvegarde pour ajouter l'objet, soit en B) ne changez pas la clé primaire lors de l'édition. J'ai fait b).
Si vous essayez de créer un mappage dans votre fichier edmx vers une "fonction Importations", cela peut entraîner cette erreur. Il suffit d'effacer les champs d'insertion, de mise à jour et de suppression situés dans Détails de mappage pour une entité donnée de votre edmx, et cela devrait fonctionner. J'espère avoir été clair.
Lorsque la réponse acceptée indiquait "elle ne finirait pas par écraser un changement que votre application ne savait pas arrivé", j'étais sceptique car mon objet venait d'être créé. Mais ensuite, il s'est avéré qu'un INSTEAD OF UPDATE, INSERT- TRIGGER était attaché à la table et qu'il mettait à jour une colonne calculée de la même table.
Une fois que je change ceci en AFTER INSERT, UPDATE, cela fonctionne bien.
Cela se produira également si vous essayez d’insérer dans une situation de contrainte unique, c’est-à-dire que si vous ne pouvez avoir qu’un seul type d’adresse par employeur et que vous essayez d’en insérer un deuxième du même type chez le même employeur, vous rencontrerez le même problème .
OU
Cela pourrait également se produire si toutes les propriétés d'objet affectées avaient les mêmes valeurs qu'auparavant.
using(var db = new MyContext())
{
var address = db.Addresses.FirstOrDefault(x => x.Id == Id);
address.StreetAddress = StreetAddress; // if you are assigning
address.City = City; // all of the same values
address.State = State; // as they are
address.ZipCode = ZipCode; // in the database
db.SaveChanges(); // Then this will throw that exception
}
Je viens d'avoir le même problème.
J'utilise EF 6, Code First + Migrations. Le problème était que notre administrateur de base de données avait créé une contrainte sur la table qui renvoyait l'erreur.
J'ai eu ce problème quand j'ai accidentellement essayé de mettre à jour l'objet au lieu de sauvegarder!
J'ai eu
if (IsNewSchema(model))
unitOfWork.SchemaRepository.Update(schema);
else
unitOfWork.SchemaRepository.Insert(schema);
quand j'aurais du
if (IsNewSchema(model))
unitOfWork.SchemaRepository.Insert(schema);
else
unitOfWork.SchemaRepository.Update(schema);
Je me suis heurté à cela en utilisant RadGrid de Telerik. J'avais la clé primaire sous forme de colonne gridbound qui était en lecture seule. Cela fonctionnerait bien si la colonne était display = "false" mais readonly = "true" posait problème. Je l'ai résolu en ayant la colonne gridbound display = false et en ajoutant une colonne de modèle séparée pour l'affichage
<telerik:GridBoundColumn HeaderText="Shouldnt see" Display="false"
UniqueName="Id" DataField="Id">
</telerik:GridBoundColumn>
<telerik:GridTemplateColumn HeaderText="Id" UniqueName="IdDisplay">
<ItemTemplate>
<asp:Label ID="IDLabel" runat="server"
Text='<%# Eval("Id") %>'></asp:Label>
</ItemTemplate>
</telerik:GridTemplateColumn>
Pour ceux qui utilisent AutoMapper Si vous mettez à jour une entité qui a des clés étrangères vers une autre entité (ou entités), assurez-vous que la clé primaire de toutes les entités étrangères est définie sur la base de données générée (ou incrémenté pour MySQL).
Par exemple:
public class BuyerEntity
{
[Key]
public int BuyerId{ get; set; }
public int Cash { get; set; }
public List<VehicleEntity> Vehicles { get; set; }
public List<PropertyEntity> Properties { get; set; }
}
Les véhicules et les propriétés sont stockés dans des tables autres que celles des acheteurs. Lorsque vous ajoutez un nouvel acheteur, AutoMapper et EF mettront automatiquement à jour les tables Véhicules et Propriétés. Par conséquent, si vous n'avez pas configuré l'incrémentation automatique sur l'une de ces tables (comme je ne l'ai pas fait), l'erreur d'erreur s'affichera. la question du PO.
J'ai eu cette exception lorsque j'ai attaché un objet qui n'existait pas dans la base de données. J'avais supposé que l'objet avait été chargé depuis un contexte séparé, mais s'il s'agissait de la première visite de l'utilisateur sur le site, l'objet avait été créé à partir de zéro. Nous avons des clés primaires auto-incrémentées, donc je pourrais remplacer
context.Users.Attach(orderer);
avec
if (orderer.Id > 0) {
context.Users.Attach(orderer);
}
Cela m'est arrivé en raison d'une inadéquation entre datetime et datetime2. Étrangement, cela a bien fonctionné avant qu'un testeur découvre le problème. Le modèle My Code First incluait une DateTime dans la clé primaire:
[Key, Column(Order = 2)]
public DateTime PurchasedDate { get; set; } = (DateTime)SqlDateTime.MinValue;
La colonne générée est une colonne datetime. En appelant SaveChanges, EF a généré le code SQL suivant:
-- Region Parameters
DECLARE @0 Int = 2
DECLARE @1 Int = 25
DECLARE @2 Int = 141051
DECLARE @3 DateTime2 = '2017-07-27 15:16:09.2630000' --(will not equal a datetime value)
-- EndRegion
UPDATE [dbo].[OrganizationSurvey]
SET [OrganizationSurveyStatusId] = @0
WHERE ((([SurveyID] = @1) AND ([OrganizationID] = @2)) AND ([PurchasedDate] = @3))
Comme il essayait de faire correspondre une colonne datetime avec une valeur datetime2, il n'a renvoyé aucun résultat. La seule solution à laquelle je pouvais penser était de changer la colonne en datetime2:
[Key, Column(Order = 2, TypeName = "DateTime2")]
public DateTime PurchasedDate { get; set; } = (DateTime)SqlDateTime.MinValue;
Cela peut se produire si vous essayez de mettre à jour un enregistrement avec un identifiant qui n'existe pas dans la base de données.
J'ai eu cette exception et j'ai défini la colonne id en incrémentation automatique dans mon database's table, puis tout a bien fonctionné
Je vais ajouter ceci au cas où quelqu'un rencontrerait ce problème alors qu'il travaillait dans une boucle parallèle:
Parallel.ForEach(query, deet =>
{
MyContext ctx = new MyContext();
//do some stuff with this to identify something
if(something)
{
//Do stuff
ctx.MyObjects.Add(myObject);
ctx.SaveChanges() //this is where my error was being thrown
}
else
{
//same stuff, just an update rather than add
}
}
Je l'ai changé comme suit:
Parallel.ForEach(query, deet =>
{
MyContext ctxCheck = new MyContext();
//do some stuff with this to identify something
if(something)
{
MyContext ctxAdd = new MyContext();
//Do stuff
ctxAdd .MyObjects.Add(myObject);
ctxAdd .SaveChanges() //this is where my error was being thrown
}
else
{
MyContext ctxUpdate = new MyContext();
//same stuff, just an update rather than add
ctxUpdate.SaveChanges();
}
}
Je ne suis pas sûr qu'il s'agisse d'une "meilleure pratique", mais cela a résolu mon problème en faisant en sorte que chaque opération parallèle utilise son propre contexte.
Vous avez cette erreur lorsque vous utilisez SaveChanges (false), puis ultérieurement SaveChanges () dans le même contexte, dans une unité de travail où plusieurs lignes étaient supprimées de deux tables (dans le contexte) (SaveChanges (False) se trouvait dans l'un des suppressions. dans la fonction appelante SaveChanges () était appelée .... La solution consistait à supprimer les SaveChanges inutiles (false).
Cela m'est juste arrivé. J'exécutais Aurora (AWS MySQL) et j'ai essayé d'ajouter des enregistrements à une table. Le champ marqué [Key] dans le modèle a été mappé à un champ auto-incrémenté dans la table ... ou du moins je le pensais. Il a été défini comme clé primaire, mais pas pour l'incrémentation automatique. Donc, le paramétrer pour l'incrémentation automatique a résolu mon problème.
Récemment, j'essaye de mettre à niveau EF5 à l'exemple de projet EF6. Le tableau du projet exemple contient des colonnes de type décimal (5,2). La migration de la base de données s'est terminée avec succès. Mais, la graine de données initiale a généré une exception.
Modèle :
public partial class Weather
{
...
public decimal TMax {get;set;}
public decimal TMin {get;set;}
...
}
Mauvaise configuration:
public partial class WeatherMap : EntityTypeConfiguration<Weather>
{
public WeatherMap()
{
...
this.Property(t => t.TMax).HasColumnName("TMax");
this.Property(t => t.TMin).HasColumnName("TMin");
...
}
}
Les données :
internal static Weather[] data = new Weather[365]
{
new Weather() {...,TMax = 3.30M,TMin = -12.00M,...},
new Weather() {...,TMax = 5.20M,TMin = -10.00M,...},
new Weather() {...,TMax = 3.20M,TMin = -8.00M,...},
new Weather() {...,TMax = 11.00M,TMin = -7.00M,...},
new Weather() {...,TMax = 9.00M,TMin = 0.00M,...},
};
J'ai trouvé le problème, les données d'ensemencement ont des valeurs de précision, mais la configuration n'a pas de paramètres de précision et d'échelle. TMax et TMin champs définis avec un nombre décimal (10,0) dans la table d'échantillons.
Configuration correcte:
public partial class WeatherMap : EntityTypeConfiguration<Weather>
{
public WeatherMap()
{
...
this.Property(t => t.TMax).HasPrecision(5,2).HasColumnName("TMax");
this.Property(t => t.TMin).HasPrecision(5,2).HasColumnName("TMin");
...
}
}
Mon exemple de projet fonctionne avec: MySql 5.6.14, Devart.Data.MySql, MVC4, .Net 4.5.1, EF6.01
Meilleures salutations.
nous avons oublié de mentionner "enctype" en affichant des données de formulaire "multipart". Un autre scénario auquel je viens de faire face ...
Dans notre cas, cette erreur a été causée par le marquage des entités comme modifiées lorsqu'aucune de leurs propriétés "n'a vraiment" changé. Par exemple, lorsque vous affectez la même valeur à une propriété, le contexte peut voir cela comme une mise à jour, contrairement à la base de données.
En gros, nous avons exécuté un script pour repeupler une propriété avec des valeurs concaténées d'autres propriétés. Pour beaucoup d'enregistrements, cela ne signifiait aucun changement, mais il les marquait comme modifiés. La base de données a renvoyé un nombre différent d'objets mis à jour qui ont probablement déclenché cette exception.
Nous l'avons résolu en vérifiant la valeur de la propriété et en assignant une nouvelle si différente.
J'ai eu un problème similaire aujourd'hui, je vais le documenter ici, car ce n'est pas tout à fait l'erreur d'optimisme de concurrence.
Je suis en train de convertir un ancien système en une nouvelle base de données contenant plusieurs milliers d'entités sur lesquelles j'ai dû créer un script pour le nouveau système. Cependant, pour améliorer la santé mentale, j'ai choisi de conserver les identifiants uniques d'origine. Je l'ai donc injecté dans le nouvel objet, puis essayé de le sauvegarder.
Le problème que j’avais, c’est que j’ai utilisé MVC Scaffolding pour créer des référentiels de base et que leur méthode UpdateOrInsert contient un modèle vérifiant si l’attribut Key est défini avant d’ajouter la nouvelle entité ou de modifier son état en modification. .
Comme le Guid était défini, il essayait de modifier une ligne qui n'existait pas dans la base de données.
J'espère que ça aidera quelqu'un d'autre!
A obtenu le même problème lors de la suppression d'un élément de la table (ParentTable) qui était référencé par 2 clés étrangères supplémentaires avec la règle ON DELETE CASCADE (RefTable1, RefTable2). Le problème apparaît en raison du déclencheur "AFTER DELETE" dans l'une des tables de référence (RefTable1). Ce déclencheur supprimait l’enregistrement associé de la table ParentTous les résultats. L’enregistrement RefTable2 avait également été supprimé ..__ Il semble que Entity Framework, bien que le code ait été défini explicitement pour supprimer l’enregistrement ParentTable, supprimait l’enregistrement associé de RefTable1, puis l’enregistrait à partir de RefTable2 operation cette exception a été levée car le déclencheur a déjà supprimé l'enregistrement de la table ParentTable qui, comme résultat, a supprimé l'enregistrement RefTable2.
J'ai eu ce problème avec l'identité Mvc lors de l'enregistrement d'un nouvel utilisateur au lieu de:
var result = await UserManager.CreateAsync(user);
Je faisais:
var result = await UserManager.UpdateAsync(user);