Did LINQ Let Me Down?

No, but now that I have you hater's and lover's of LINQ here I can share my frustrations, however they are not with LINQ. The reason I chose the title of this blog post was because I did think it was LINQ! Just like when I cannot find my keys at home as I am rushing to work, I will in my mind blame my 2 year old son and then discover I left them in my pants from the previous day. All of us like to put the blame on something when we are unsure and in our minds it makes sense to.

In this case I had three tables.


I used LINQ to grab the data, and a collection of Ordered Items was returned along with a collection of ProductGroups and finally Groups associated with that product. As I looped through my Ordered Items after the second OrderedItem I kept getting the following error...Object reference not set to an instance of an object. As I tracked the origin of the error within the WF Rules Engine ruleset being processed I was able to find the method that was throwing the error. Debugging through the code however did not help as the error was thrown each and every time at certain points where LINQ queries (for objects) were being processed. This is where I started blaming LINQ like the analogy I gave above about blaming my two year old son. I tried researching this still no clue. I spent hours trying to understand where my code was going wrong. This is where the problem really started frustrating me. I then started querying the database to find the ProductGroups and Groups that were being pulled and comparing them to what LINQ had in its collections during debug. Since the database had already been created, I knew that there was a history for tables not having relationships (FK's, PK, etc.) so I also verified them. The last time I ran my test and right after I got my pal John Bates to lend me a second pair of eyes, I noticed that the records that were being pulled by LINQ were different then the records I was pulling via SQL Server Studio by one. So I was actually missing a record. Now in LINQ I was actually querying conditions based on the fields within the Group table through the ProductGroups. Come to find out there were some groups that were not in the Group Table that had relationships within the ProductGroup. Through my experience in writing code, I have never experienced anything like this; hence this was what caused me to waste so much time.
So remember, in most cases it is better for experienced developers to anticipate that bugs are a result of their own code. Second, it is ok to question the database. Check the data integrity even though you have some snot nose telling you the data in production is correct and it is your fault with a face of smug. Third, don't blame LINQ...Instead relish all of the time you have forgotten it has saved you in past development efforts.

Currently rated 1.0 by 1 people

  • Currently 1/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: BayerWhite
Posted on: 8/18/2009 at 2:23 AM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (98) | Post RSSRSS comment feed


Comments are closed