LINQ context.SubmitChanges() does not add record to database

This never happens.

If you think that context.InsertOnSubmit(entity) is not adding the entity to your Context then you are doing something wrong.

In my case, I had code like this:


ProductContext context = new ProductContext();
Product product = new Product();
product.Id = productId;
product.Name = productName;
product.Description = productDescription;

context.InsertOnSubmit(product);
context.SubmitChanges();


Totally straightforward, but when I checked the database, the Product table did not contain the new Product record I had created above. But this problem only occurred on our Integration Test server, not on our Dev box (Why?). So began my journey of pain….

I ran the program a few times and noticed that my EntitySet, context.Products, was increasing in number each time I passed through the AddProduct method snippet above, but the database table, Product, as viewed through VS Server Explorer did not have the same number of records as the context. WHY?!!! (Some of you have guessed already.)

I started Googling for help: “InsertOnSubmit fails”; “SubmitChanges does not save”; “LINQ insanity coronary apoplexy” etc. Then spake Thrifty Dave, our noble Team Leader: “Perhaps the Connection Strings are different on the Test box,” suggested Dave between mouthfuls of remaindered Sushi. My pangs of internal anguish commenced immediately. This had the ring of truth as well as the scent of slightly fermented Wasabi paste.

I checked the Connection Strings: yep, the Context on Integration Test was pointing to “ProductTest” database whereas the actual database I was looking at was “ProductLive”. Too simple. There was NO problem with context.SubmitChanges(). I was just looking at the wrong database. *blush* (Respectfully please now imagine a luminous red object larger than the Hindenburg and covered in Wasabi paste).

Moral Of The Story

context.SubmitChanges() always works. If you think its not working, then its your fault. Look elsewehere. Maybe check your ConnectionStrings.

Plausible Deniability

The reported bug was in a Windows Service which utilizes the same database as the main application. On the IntegrationTest server, the Windows Service app.config had its ConnectionString set to “ProductLive” database due to an error in our deployment scripts. My colleague, who wrote the Windows Service told me that data was not being found by the Windows Service and HE was checking “ProductLive”, based on the (faulty) Windows Service app.config.

So I believed what I was told.
But, yes, I should have checked, and I should have realised quicker what was going on

Life Force Depletion: Classified.

Tags: LINQ, Wasabi