why .Update duplicating a record?

Mitchelln11

Active member
Joined
Apr 10, 2020
Messages
39
Programming Experience
Beginner
Do you know why .Update would be duplicating a record?

I am running the REST call to save info to my Parks database, but before I save it, I am checking the park code to see if it's already in the database. Is this even the right code? It does hit the else statement, content just doesn't get updated, but rather creates a new one. Any ideas?
C#:
// Check for duplicates
Park uniqueParkCode = _context.Parks.Where(c => c.ParkCode == individualPark.ParkCode).FirstOrDefault();
if (uniqueParkCode == null)
{
    _context.Parks.Add(park);
    _context.SaveChanges();
}
else
{
    _context.Parks.Update(park); // Adds a new park instead???
    _context.SaveChanges();
}
 
Last edited by a moderator:
I don't know. I run away from Entity Framework like the plague (or COVID-19 depending on which one you fear more).
 
Debug your code. Debugger tutorial in my signature if you need it.

Does it behave as you expected?
It does go to the proper if/else statements and displays what I want it to. It's just that after it hits update, it just doesn't actually update. It's actually creating a new record. Is this potentially an issue with Entity Framework?
 
We avoid it, at least i do, since I refuse to support/use EF due to its enormous amount of unfixed bugs and unacknowledged/acknowledged memory leaks. Despite me telling people this for years, they still use it.

Second, I don't know what your EF code has mapped for you. It's a headache I can do without getting sucked into. Checking every class you have that EF references in some way or another is not how I'd like to spend my Sunday evening. Besides, we aren't on your PC, you are; and that is why microsoft provide a debugger. So forgive my arrogance, but If you use EF, then you deserve the hell it will deliver you. ?

Generally speaking...setting a debugging point will lead you through your code where you can determine what your code is doing in real time. Debugging is the only way to find out why its doing it.

Sorry I can't be of more help.
 
Forgive my ignorance, but why do you avoid it? What do you use instead?
It was Microsoft's attempt at taking away mindshare from NHibernate. The attempt was poorly executed... the first time, and the succeeding four times after that. The current iteration is better now, but still buggy as @Sheepings noted above. And in general, I'm a MS fan boy because I used to work for the Evil Empire for almost two decades, but there are some bit of MS technology that I steer clear off, and EF is one of them.

I prefer to use OODBMS (Object Oriented Database Management Systems) and NoSQL databases.
 
Did someone say NHibernate? Now that is a disaster! I personally love EF and even more so EF Core. I suggest all of the above watch the EF Core and EF Core In Depth series.

5-part series / intro:


10-part series / advanced:

 
Yes, NHibernate can be a disaster because of all the knobs, switches, and manual overrides. The learning curve is steep. I believe that this is what Microsoft wanted to address with its various EF attempts. Recall that the first version of EF required a visual drag and drop approach to designing the entities -- a complete 180 form NHibernates text configurations.
 
Back
Top Bottom