When this symptom occurs, additional failures happen - such as error messages saying things like "1 of 3 updates failed" due to optimistic concurrency issues.
When I reboot, this problem disappears and I can go about my business. What I'm looking for is whether someone here knows what event / code / error /bad practice can place the LINQ to SQL object model into a state where its basically brain-dead...?
Hi,
Does this happen with LINQ to SQL or with the ADO.NET Entity Framework (with or without LINQ to Entities)? Do you actually have to reboot the computer, killing the process is not enough? (if you're running the app from VS you may need to kill the vshost process). If you could have repro program it would be great...
Pablo Castro
ADO.NET Technical Lead
Microsoft Corporation
The code hasn't changed but the behavior has. I am not running the app (ASP.NET) inside Visual Studio. I haven't tried doing an IISreset, I have just rebooted the PC because I wasn't sure if it was SQL related or ASP.NET related.
I get all kinds of weird issues.
I haven't seen this happening before. One thing that would be interesting to try is to attach a debugger to the ASP.NET worker-process and see what dlls are loaded and from which location. We specifically designed the ADO.NET August CTP setup layout so it doesn't interfere with the May LINQ CTP, but we could have made a mistake or not considered some scenario. With a debugger you could look at whether there is any dll from the ADO.NET August CTP loaded (there shouldn't be any if this is a May-CTP-only project).
Pablo Castro
ADO.NET Technical Lead
Microsoft Corporation
Hi Kevin,
Did you get a chance to look at this? I'm curious to see whether this was caused by the combination of the May and August CTPs or something else. Thanks for any updates.
Pablo Castro
ADO.NET Technical Lead
Microsoft Corporation
