在实体框架6 CreatedOn列

问题描述

升级到实体框架6之后，我们已经实现了我们自己的 DbExecutionStrategy 的。除了现有的 SqlAzureExecutionStrategy 的我们的策略也记录异常。
作为横空出世，每15-30分钟实体框架抛出的SQLException内部
System.Data.SqlClient.SqlException（0x80131904）：无效的列名称CreatedOn
这是一个内部错误。好像EF做一些常规检查，如果一些表存在CreatedOn列。 ？有没有优雅的方式来防止这种异常抛出

下面是一个调用堆栈：

 在System.Data.SqlClient.SqlConnection.OnError（SqlException异常，布尔breakConnection，Action`1 wrapCloseInAction）
在System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning（TdsParserStateObject stateObj，布尔callerHasConnectionLock布尔asyncClose）
在System.Data.SqlClient.TdsParser.TryRun（RunBehavior runBehavior，的SqlCommand cmdHandler，SqlDataReader的数据流，BulkCopySimpleResultSet bulkCopyHandler，TdsParserStateObject stateObj，楼盘布尔dataReady）
在System.Data.SqlClient.SqlDataReader .TryConsumeMetaData（）
在System.Data.SqlClient.SqlDataReader.get_MetaData（）在System.Data.SqlClient.SqlCommand.FinishExecuteReader 
（SqlDataReader的DS，runBehavior runBehavior，字符串resetOptionsString）
。在系统.Data.SqlClient.SqlCommand.RunExecuteReaderTds（的CommandBehavior cmdBehavior，runBehavior runBehavior，布尔returnStream，布尔异步，的Int32超时，裁判工作任务，布尔asyncWrite，SqlDataReader的DS）
在System.Data.SqlClient.SqlCommand.RunExecuteReader（的CommandBehavior cmdBehavior，RunBehavior runBehavior，布尔returnStream，字符串的方法，TaskCompletionSource`1完成的Int32超时，裁判工作任务，布尔asyncWrite）
在System.Data.SqlClient.SqlCommand.RunExecuteReader（的CommandBehavior cmdBehavior，RunBehavior runBehavior，布尔returnStream，字符串的方法）
在System.Data.SqlClient.SqlCommand.ExecuteReader（的CommandBehavior行为，串法）
在System.Data.SqlClient.SqlCommand.ExecuteDbDataReader（的CommandBehavior行为）
在System.Data这.Entity.Infrastructure.Interception.InternalDispatcher`1.Dispatch（Func`1操作，TInterceptionContext interceptionContext，Action`1执行，执行Action`1）
在System.Data.Entity.Infrastructure.Interception.DbCommandDispatcher.Reader（的DbCommand命令，DbCommandInterceptionContext interceptionContext）
在System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands（entityCommand entityCommand，行为的CommandBehavior）
  

解决方案

在过去的实体框架用来在__MigrationHistory表中的列CreatenOn。

每一次的AppDomain开始后，如果迁移需要对数据库它检查。 EF实际上是尝试阅读CreatedOn栏目，显然无法与获取记录例外。 EF拥有一个丑陋的try / catch块全部解决此检查，如果异常被抛出（列缺失），那么它不会尝试移植CretedOn列。

有没有办法此刻禁用检查，但只是没有记录它...

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

解决方案

In a past Entity Framework used to have a column "CreatenOn" 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" CretedOn column.

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

这篇关于在实体框架6 CreatedOn列的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！