27

After upgrading to Entity Framework 6 we've implemented our own DbExecutionStrategy. In addition to existing SqlAzureExecutionStrategy our strategy also logs exceptions. As turned out, every 15-30 minutes Entity Framework throws internal SqlException System.Data.SqlClient.SqlException (0x80131904): Invalid column name 'CreatedOn'. It's an internal error. Seems like EF does some regular checks if CreatedOn column exists on some table. Is there any elegant way to prevent this exception to be thrown?

Here is a call stack:

   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, ref Boolean dataReady)
   at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, ref Task task, Boolean asyncWrite, SqlDataReader ds)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, ref Task task, Boolean asyncWrite)
   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.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch(Func`1 operation, TInterceptionContext interceptionContext, Action`1 executing, Action`1 executed)
   at System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.Reader(DbCommand command, DbCommandInterceptionContext interceptionContext)
   at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior)
3
  • I'm getting this error as well. Dec 18, 2013 at 17:34
  • Possible duplicate of Entity Framework 4.3. Invalid column name 'CreatedOn'
    – AXMIM
    Feb 10, 2016 at 20:57
  • "... checks if CreatedOn column exists on some table." You can use the SQL profiler from SQL Server Management Studio to find out what SQL EF is sending to your server. In my case, I saw SELECT TOP (1) [c].[CreatedOn] AS [CreatedOn] FROM [dbo].[__MigrationHistory] AS [c], which made it clear that it had something to do with an EF version mismatch. Jan 17, 2017 at 10:32

2 Answers 2

48

In a past Entity Framework used to have a column "CreatedOn" in __MigrationHistory table.

Every time the AppDomain starts it checks if Migration is required the the database. EF actually tries to read "CreatedOn" columns and obviously fails with the exception which gets logged. EF has an ugly try/catch all block around this check and if the exception is thrown (column is missing) then it doesn't try to "migrate" CreatedOn column.

There is no way at the moment to disable that check, except just not to log it...

6
5

In my case, this error was happening because I had changed Visual Studio Debug Exceptions settings to break in all exceptions (or in more exceptions than the default configuration). After resetting all settings of Visual Studio, the error didn't happen anymore, and my application ran normally as expected.

The problem then is that Entity Framework has a try/catch block to handle this error so that the application doesn't stop working when this error happens. After handling the error, it returns the application to a normal state, as you might do also in your own application's try/catch blocks. Thus breaking on these exceptions was making my code stop unnecessarily.

Breaking in all exceptions was necessary while I was debugging a complex program, but I should have had reset the debugging exceptions settings after I didn't need it anymore. Hope this may help someone else going through this same hard to catch environment issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.