1

i got thrown into a small .NET migration project that is using the Entity Framework and MS SQL Server 2005. when persisting data that is not working with db schema (e.g. a string is too long), I am getting an exception System.Data.UpdateException that says "String or binary data would be truncated". But there is no information to which field it relates. does someone has a clue how to get this?

thx

here the stacktrace:

   at System.Data.Mapping.Update.Internal.UpdateTranslator.Update(IEntityStateManager stateManager, IEntityAdapter adapter)
   at System.Data.EntityClient.EntityAdapter.Update(IEntityStateManager entityCache)
   at System.Data.Objects.ObjectContext.SaveChanges(SaveOptions options)
   at System.Data.Objects.ObjectContext.SaveChanges()
   at HAM.Inventory.Data.Repository.DocumentRepository.Save(Document document) in D:\ludewigg\Documents\Projects\HAM\src\VBS-HAM-Inventory\Main\HAM.Inventory.Data\Repository\DocumentRepository.cs:line 177
   at HAM.Inventory.Business.Managers.DocumentManager.Save(Document document) in D:\ludewigg\Documents\Projects\HAM\src\VBS-HAM-Inventory\Main\HAM.Inventory.Business\Managers\DocumentManager.cs:line 75
   at HAM.Inventory.MigrationClient.Common.Migration.SaveItem(ItemBase item) in D:\ludewigg\Documents\Projects\HAM\src\VBS-HAM-Inventory\Main\HAM.Inventory.MigrationClient\Common\Migration.cs:line 143
   at HAM.Inventory.MigrationClient.Common.Migration.SaveAndClearItems(List`1 items) in D:\ludewigg\Documents\Projects\HAM\src\VBS-HAM-Inventory\Main\HAM.Inventory.MigrationClient\Common\Migration.cs:line 76

and the inner exception:

at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   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)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at System.Data.Mapping.Update.Internal.DynamicUpdateCommand.Execute(UpdateTranslator translator, EntityConnection connection, Dictionary`2 identifierValues, List`1 generatedValues)
   at System.Data.Mapping.Update.Internal.UpdateTranslator.Update(IEntityStateManager stateManager, IEntityAdapter adapter)
fischermatte
  • 3,327
  • 4
  • 42
  • 52

1 Answers1

0

Look at the StateEntries property. It should have all the failing objects.

leppie
  • 115,091
  • 17
  • 196
  • 297
  • the object I know, but which field? – fischermatte Nov 30 '10 at 09:24
  • @user524906: Well you would have to look for that, and make sure there are no strings that are too long. – leppie Nov 30 '10 at 09:26
  • @user524906: Attach the SQL profiler, that should be quite easy to spot. Or turn on the datacontext's log. – leppie Nov 30 '10 at 10:01
  • haven't tried yet the datacontext log, but playing around with the profiler. i copied the query from there to SSMS in order to see the resulting error. but SSMS never finishs executing the query!! weird, it seems SSMS cant handle "exec sp_executesql" statements... – fischermatte Nov 30 '10 at 10:40
  • do i have to rewrite the query? the sql statement is "exec sp_executesql N'insert..., N'@0 uniqueidentifier,@1,..." – fischermatte Nov 30 '10 at 10:57
  • @user524906: You need to validate your data, and make sure the offending string is not too long. – leppie Nov 30 '10 at 11:01
  • 1
    well, thanks a lot so far! you are right, validation would be the best approach. anyway, for this case i was just looking for a quick and simple way to determine the field/column that raises the exception. – fischermatte Nov 30 '10 at 12:16