Error in migration from Episerver 8 to 9

Vote:
 

Hi Episerver,

I am currently upgrading an application from Episerver 8.11 to 9.12 and Commerce 8.16 to 9.24.

During the EPiServer Commerce Migration of CatalogEntryEx_Product I encountered an SqlException: 'System.Data.SqlClient.SqlException (0x80131904): Cannot create a row of size 10351 which is greater than the allowable maximum row size of 8060.

After a few hours of debugging, I found that this happens in the stored procedure [mdpsp_avto_CatalogEntryEx_Product_ListSpecificRecord]. We solved this issue by adding option (ROBUST PLAN) to the stored procedure, afterwards the migration completed.

I know this error occurs because we have a large amount of product attributes(400+), but I still thought I would share this bug.

11:10:21 AM: Migrates published Catalog Content has failed with exception 'System.Data.SqlClient.SqlException (0x80131904): Cannot create a row of size 10351 which is greater than the allowable maximum row size of 8060. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) at System.Data.SqlClient.SqlInternalConnection.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, Boolean& dataReady) at System.Data.SqlClient.SqlDataReader.TryHasMoreRows(Boolean& moreRows) at System.Data.SqlClient.SqlDataReader.TryReadInternal(Boolean setTimeout, Boolean& more) at System.Data.SqlClient.SqlDataReader.Read() at System.Data.Common.DataAdapter.FillLoadDataRow(SchemaMapping mapping) at System.Data.Common.DataAdapter.FillFromReader(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 startRecord, Int32 maxRecords, DataColumn parentChapterColumn, Object parentChapterValue) at System.Data.Common.DataAdapter.Fill(DataTable[] dataTables, IDataReader dataReader, Int32 startRecord, Int32 maxRecords) at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable) at Mediachase.Data.Provider.SqlDataProvider.<>c__DisplayClass16_2.b__0() at EPiServer.Data.Providers.SqlTransientErrorsRetryPolicy.Execute[TResult](Func`1 method) at Mediachase.Data.Provider.SqlDataProvider.WithRetry[TResult](Func`1 action) at Mediachase.Data.Provider.SqlDataProvider.LoadTable(DataCommand command) at Mediachase.Data.Provider.DataService.LoadTable(DataCommand command) at Mediachase.MetaDataPlus.Common.DBHelper.ExecuteDataTable(String connectionString, CommandType commandType, String commandText, Int32 commandTimeout, DataParameter[] commandParameters) at EPiServer.Commerce.Internal.Migration.Steps.MigratePublishedContentStep.ListPropertyData(MetaClass metaClass, String language, Int32 objectTypeId, Int32 count, DataTable propertyData, DataTable contentExData, DataTable idsToDelete) at EPiServer.Commerce.Internal.Migration.Steps.MigratePublishedContentStep.MigrateCatalogContent(MetaClass metaClass, IList`1 languages) at EPiServer.Commerce.Internal.Migration.Steps.MigratePublishedContentStep.Execute(IProgressMessenger progressMessenger) ClientConnectionId:b886afb1-a8a0-4d6a-9d2c-64fe008e1776'.

#162433
Oct 14, 2016 14:59
Vote:
 

Great catch! Throw it into development support and I'm sure they will fix it

http://world.episerver.com/support/

Although they scan forum off and on it's not bullet proof :)

#162450
Oct 14, 2016 17:02
Vote:
 

Hi,

yes, if you can spare the time, please send this to developer support as a bug report. A reason to channel it through developer support is that you can provide a description of this catalog design containing that many fields, without exposing it on the public forum. Examples of different catalog designs is valuable input to future system designs. And the workaround can be valuable for support to know about. 

I can't promise we'll accept the bug, most catalog designs come nowhere near this amount of fields for the same meta class, and using the ROBUST PLAN option could have performance implications for all those that don't need it. And once the migration is done, this sproc will be removed since it is not used in the remodeled catalog system. But as mentioned, we are interested in knowing more about different catalog designs.

Thank you!

#162559
Oct 14, 2016 21:19