LinqToSql referenced entities will throw NullReferenceException

Question

I have a very interesting problem on my LinqToSql model. On some of my tables i have a references to other tables and in LinqToSql this is represented by a EnitiyRef class, when you are trying to access the references table LinqToSql will load the reference from the database.

On my development machine everything worked fine (the references were loaded perfectly) but last night i uploaded the changed to our production server and started getting NullReferenceExceptions when trying to access the reference on my tables.

Sample code:

var sale = db.Sales.Single(s => s.ID == 1);
string username = sale.User.Name;    // User is a reference to a User table
                                     // LinqToSql will automatically load the
                                     // row and access the fields i need.

// On my server the sale.User throws an exception that its null (User) but the user
// is definitly in the database (there is even a FK constraint from Sale to User)

At first i thought that it my DataContext got GC'd but i double checked everything with no result (besides it works on my box).

(Everything is the same on the server and my box, same dll's, same db schema etc...) (I actually copied the entire DBF file over to my server so its the exact same schema)

Answer 1

Have you turned the context logging on and compared the results on your dev box to those on your production box?

Answer 2

If you move your source to the production server and compile it there, try regenerating the generated source for the DataContext. You can do this by running "run user defined tool" from the context menu of your DataContext source file.

If both share the same binary, make sure the database definition is exactly the same in both databases. A small difference like one column being nullable on your production server but not nullable on your devbox can make all the difference.

Answer 3

In order to find and resolve an issue like that it would be helpful with a stacktrace and perhaps a profiling on the database.

The problem could perhaps be a security issue. Have you tried to log in with the same credentials in Management Studio as your application uses and do a select on the table.

That would at least give you an idea about security or a linq issue.

Answer 4

Examine DataContext lifetime. There may be stale cache at work here

For example:

1. Context1 : Load Sale with ID == 1. Examine its User property and observe null User.
2. Context2: Load Sale with ID == 1. Modify User property by adding a new User. Commit.
3. Context1: Load Sale with ID == 1. Examine its User property. Yup, still null (it's cached!!).

Answer 5

One possibility is that you connection string used by your DBML is still pointing to a database server other than Production.

This happened to us whenever a LinqDataSource was used directly in an ASPX page, and thus the DataContext was using the default constructor, which was pointing to a connection string based on the database that the last developer used to import the DBML.

What we did was create a DataContext object that inherited from the generated DataContext and overrode the default constructor with the correct connection string from our web.config.