2013-10-28 26 views
20

Dopo l'aggiornamento a Entity Framework 6 abbiamo implementato la nostra DbExecutionStrategy. Oltre alla già esistente SqlAzureExecutionStrategy, la nostra strategia registra anche le eccezioni. Come si è visto, ogni 15-30 minuti Entity Framework lancia SqlException interna System.Data.SqlClient.SqlException (0x80131904): Invalid column name 'CreatedOn'. Si tratta di un errore interno. Sembra che EF esegua alcuni controlli regolari se la colonna CreatedOn esiste su qualche tabella. C'è un modo elegante per evitare che questa eccezione venga lanciata?Creato in colonna Entity Framework 6

Ecco uno stack di chiamate:

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) 
+0

Anche questo errore si verifica. –

+0

Possibile duplicato di [Entity Framework 4.3. Nome colonna non valido 'CreatedOn'] (http://stackoverflow.com/questions/12193465/entity-framework-4-3-invalid-column-name-createdon) – AXMIM

+0

"_... controlla se la colonna CreatedOn esiste su ** alcuni ** table._ "Puoi utilizzare il SQL Profiler di SQL Server Management Studio per scoprire cosa sta inviando SQL EF al tuo server. Nel mio caso, ho visto 'SELECT TOP (1) [c]. [CreatedOn] AS [CreatedOn] FROM [dbo]. [__ MigrationHistory] AS [c]', che ha chiarito che aveva qualcosa a che fare con un EF versione non corrispondente. –

risposta

31

In un passato Entity Framework utilizzato per avere una colonna "CreatenOn" nella tabella __MigrationHistory.

Ogni volta che si avvia AppDomain, controlla se è richiesta la migrazione del database. EF in effetti prova a leggere le colonne "CreatedOn" e ovviamente fallisce con l'eccezione che viene registrata. EF ha un brutto tentativo/cattura tutto il blocco attorno a questo controllo e se l'eccezione è lanciata (colonna mancante), allora non prova a "migrare" la colonna CreatedOn.

Non c'è modo al momento di disattivare tale controllo, ad eccezione solo di non registrare che ...

2

Nel mio caso, questo errore stava accadendo perché avevo cambiato di Visual Studio eccezioni di debug impostazioni di rompere in tutte le eccezioni (o in più eccezioni rispetto alla configurazione predefinita). Dopo aver ripristinato tutte le impostazioni di Visual Studio, l'errore non si verificava più e la mia applicazione funzionava normalmente come previsto.

Il problema è che Entity Framework ha un blocco try/catch per gestire questo errore in modo che l'applicazione non smetta di funzionare quando si verifica questo errore. Dopo aver gestito l'errore, restituisce l'applicazione a uno stato normale, come si potrebbe fare anche nei blocchi try/catch della propria applicazione. Pertanto, l'interruzione di queste eccezioni da parte di ha provocato l'interruzione inutile del mio codice.

L'interruzione di tutte le eccezioni era necessaria mentre eseguivo il debug di un programma complesso, ma avrei dovuto ripristinare le impostazioni delle eccezioni di debug dopo che non ne avevo più bisogno. Spero che questo possa aiutare qualcun altro a superare lo stesso difficile problema ambientale.

Problemi correlati