SqlDateTime overflow exception in Entity Framework

Question

When calling context.SaveChange(), I get an exception: {"An error occurred while updating the entries. See the InnerException for details."} with an InnerException of "SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM."

Generally this error is pretty easy to fix -- just find the DateTime property whose value was never set (defaulted to MinValue). Unfortunately, I checked all properties on my object, and all of them are set to valid dates/times.

Is there some way to figure out which property EF is referring to when throwing this exception?

Also, I'm only actually checking the object I added to the context right before SaveChanges (and as far as I know, I'm only adding 1). Is there a way to look at all pending data that is about to be saved?

Edit

InnerException.StackTrace:

at System.Data.SqlTypes.SqlDateTime.FromTimeSpan(TimeSpan value)
at System.Data.SqlTypes.SqlDateTime.FromDateTime(DateTime value)
at System.Data.SqlClient.MetaType.FromDateTime(DateTime dateTime, Byte cb)
at System.Data.SqlClient.TdsParser.WriteValue(Object value, MetaType type, Byte scale, Int32 actualLength, Int32 encodingByteSize, Int32 offset, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC[] rpcArray, Int32 timeout, Boolean inSchema, SqlNotificationRequest notificationRequest, TdsParserStateObject stateObj, Boolean isCommandProc)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.ExecuteReader(CommandBehavior behavior)
at System.Data.Mapping.Update.Internal.DynamicUpdateCommand.Execute(UpdateTranslator translator, EntityConnection connection, Dictionary`2 identifierValues, List`1 generatedValues)
at System.Data.Mapping.Update.Internal.UpdateTranslator.Update(IEntityStateManager stateManager, IEntityAdapter adapter)

Edit 2

It may have to do something with my work flow... For example...

• I build object SalaryInformation in the class responsible for building Entity objects
• SalaryInformation has an Employee property on it, but the class that builds it only knows the Employee ID, so it sets SalaryInformation.Employee = new Employee { ID = 1 } (leaving the date fields set to MinValue)
• I pass the SalaryInformation object into a method to be saved
• Inside the save method, I look up the Employee object in the database based on the ID and then assign the returned Employee object to SalaryInformation.Employee
• I then context.AddToSalaryInformation(SalaryInformation) and context.SaveChanges()

I suspect this is leaving a straggler Employee behind in the context with only the ID set, and no Dates, thus the error.

Edit 3

Indeed, workflow was the issue. If I simply say `SalaryInformation.Employee = null;' before assigning the employee object from the database, then the straggler goes away, and no error occurs.

Is this the intended behavior and work around? It seems quite terrible.

Answer 1

You are setting the employee the wrong way. The simplest way to do this is:

SalaryInformation.Employee = context.Employees.Where(e => e.Id == 1).First();
context.AddToSalaryInformation(SalaryInformation);

That means a DB access.

In EF 4, with FK associations, you can do:

SalaryInformation.EmployeeId = 1;
context.AddToSalaryInformation(SalaryInformation);

In EF 1, a workaround is:

SalaryInformation.EmployeeReference.EntityKey = 
    new EntityKey("MyEntities.Employees", "Id", 1);
context.AddToSalaryInformation(SalaryInformation);

But creating a stub, like you do in your second example, requires additional work.

Answer 2

Use the SQL profiler tool and run a trace.

[Edit] You can also try implementing EF tracing as described here.