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)
Boris Lipschitz
  • 9,236
  • 5
  • 53
  • 63
  • I'm getting this error as well. – Shane Castle Dec 18 '13 at 17:34
  • Possible duplicate of [Entity Framework 4.3. Invalid column name 'CreatedOn'](http://stackoverflow.com/questions/12193465/entity-framework-4-3-invalid-column-name-createdon) – AXMIM Feb 10 '16 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. – R. Schreurs Jan 17 '17 at 10:32

2 Answers2

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

TGnat
  • 3,903
  • 8
  • 35
  • 46
Boris Lipschitz
  • 9,236
  • 5
  • 53
  • 63
  • 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? – Evgeny Gorbovoy Sep 27 '18 at 12:43
  • 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. – Rhyous Feb 04 '19 at 14:01
  • 1
    https://github.com/aspnet/EntityFramework6/blob/master/src/EntityFramework/Migrations/History/HistoryRepository.cs See method starting in line 460 – Rhyous Feb 04 '19 at 15:07
  • https://github.com/dotnet/ef6/blob/v6.4.4/src/EntityFramework/Migrations/History/HistoryRepository.cs#L580-L605 – Kissaki Jun 03 '22 at 08:08
  • Checks for the legacy migration column `CreatedOn`, and if it exists, drops it. – Kissaki Jun 03 '22 at 08:18
  • 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. – David V. Corbin Sep 30 '22 at 11:00
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.

Ulysses Alves
  • 2,297
  • 3
  • 24
  • 34