Quick math question… If I asked you, “is 8 both greater than 0, and less than 38,” what would be your answer?? Well, if you answered yes, than you would be wrong… At least according to LINQ-to-SQL:
My reaction - “Uhhhhhhh.. WHAT?!?”
I am running Visual Studio 2010 Premium SP1 with the Windows Phone 7.1 SDK. I used the instructions at WindowsPhoneGeek - Using SqlMetal to generate Windows Phone Mango Local Database classes to generate the code files for the database context in my application. The process was easy, and seemed to work flawlessly.
Well, I doubt I need to explain much here… I reread the exception multiple times to make sure that I hadn’t had a random bout of temporary dyslexia hit, but no matter how many times I read this, I read the same thing. I checked all of the database context, and the attribute for the property that throws the exception, and everything appears to be fine.
This is the actual property that is throwing the exception – the only one that is a Decimal on the entire entity
The REALLY weird thing is, the exception isn’t thrown consistently. I can run the application 10 times in a row, with the same exact data flowing into it, performing the same network calls, but for some reason, about 2-3% of the time, I will get the exception listed above. On top of this, the other weird thing is that the application will have already run through the code several times for other objects without any exception. It doesn’t even always fail on the same objects, sometimes it is after processing 2-3 things, others on the 20 or 30th..
Hunting the Bug
I would like to be able to instead have information on a solution or fix, but I can’t provide that. I have tried over and over to produce a test case that will generate the error reliably, and I can’t do it. It only seems to happen when the application is running, and as I had said, it will work once, and then 1 minute later with the same information (application restarted), fail. The only thing that I can think of off the top of my head is that my application relies heavily on the ThreadPool for queuing actions, so that the interface isn’t sluggish. I even tried to do the same in my test cases (I am using TDD with a test harness), and still couldn’t produce the bug. So, I am left to this… I never wanted to post a blog where I didn’t have a solution, but now I have decided to try it to see if you the readers have the answer. If you do, I would be greatly appreciative of any hints or tips to find it, and will come back to edit this post with a solution… For now, this will serve as a placeholder for other lost souls that have tried searching the issue but found nothing – you are not alone… Now, let me go find some math books and brush up on basic math…