CreatedOn column in Entity Framework 6

Question

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)

Imperturbation

I'm getting this error as well. – Hookup

Possible duplicate of Entity Framework 4.3. Invalid column name 'CreatedOn' – Nigelniger

"... 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. – Manyplies

Answer 1

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...

Imperturbation

Is it specific exception check or just common? I mean, if OutOfMemory thrown, for example, or any connection exception, would it be understood as CreatenOn column missing, or it properly bubbles up the exception? – Elegy

Since EF is open source, could you point to the ugly try/catch block in the source. Perhaps a community fix and pull request is in order. – Halsey

github.com/aspnet/EntityFramework6/blob/master/src/… See method starting in line 460 – Halsey

github.com/dotnet/ef6/blob/v6.4.4/src/EntityFramework/… – Rowdyism

Checks for the legacy migration column CreatedOn, and if it exists, drops it. – Rowdyism

Such an ugly (and IMPO - incompetent) way to check . The lack of the column is NOT "exceptional" (i.e. is is present under well known common circumstances) and there are alternative ways to check that would not have thrown an initial exception. – Chiekochien

Answer 2

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.

Weingarten