This error is from a metafield which should be Int32, but has a value of double. I would suggest you to upgrade to 10.7.1 or later on another site, to see which metafield and which value caused the trouble, and fix that in your site.

Thanks Quan Mai, I'll try that.

Upgrading to Commerce 10 seems to solve the problem.

Did the upgrade to 10.8.0 and went back to a copy of the DB from 8.16.1 so I could go through the migration steps related to 9 again. All steps succeeded incl. "Migrates most used draft: ready to publish, checked in, checked out and rejected draft.. -> Migrating 'CheckedOut' drafts" which failed before.

<p>Hi again Quan,</p> <p></p> <p>I was a little bit too quick marking this as solved. Even though&nbsp;I didn't get the error "value is a System.Double but should be a System.Int32" when doing the migration step <span>"Migrates most used draft: ready to publish, checked in, checked out and rejected draft.. -&gt; Migrating 'CheckedOut' drafts"</span> as before or opening VariationContent in Commerce catalog or when publishing newly created&nbsp;<span>VariationContent&nbsp;I still get a similar error message when running the scheduled job "Draft store migration job". I'll guess this is when migrating "previous versions" stored in DDS to the new catalog versioning system.</span></p> <p><span>Error in Commerce 10.8.0 when running "Draft store migration job":</span></p> <pre class="brush:html;auto-links:false;toolbar:false" contenteditable="false">Message: Value of Weight is 0.007, of type System.Double, but should be an System.Int32 Parameter name: value StackTrace: at Mediachase.MetaDataPlus.Configurator.MetaDataTypes.GetDatabaseValueInteger(Object value, String metaFieldName) at EPiServer.Commerce.Catalog.Provider.CatalogContentVersionStore.GenerateFields(CatalogContentBase content, Int32 objectId, MetaClass metaClass, MetaDataContext context) at EPiServer.Commerce.Catalog.Provider.CatalogContentVersionStore.UpdateContentVersion(IList`1 contents, DataTable workIdMapping, Boolean publishAction) at EPiServer.Commerce.Catalog.Provider.CatalogContentVersionStore.ImportVersion(IList`1 contents, IList`1 commonDraftWorkIds) at EPiServer.Commerce.Internal.Migration.DraftStoreMigrator.Migrate(VersionStatus status, Int32&amp; total) at EPiServer.Commerce.Internal.Migration.ScheduledJobs.DraftStoreMigrationJob.DoMigrate(Object stateInfo) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() at System.Threading.ThreadPoolWorkQueue.Dispatch()</pre> <p><span></span></p> <p><span>What I dont understand here is why it says it should be an System.Int32.&nbsp;</span></p> <p><span>Checking&nbsp;EPiServer.Commerce.Catalog.ContentTypes.VariationContent.Weight it is a double. The same for every version from 7.5 (site originally build on 7.5) &nbsp;to 10&nbsp;</span></p> <p><span><a href="https://world.episerver.com/documentation/Class-library/?documentId=commerce/7.5/8D26F8F9">https://world.episerver.com/documentation/Class-library/?documentId=commerce/7.5/8D26F8F9</a></span></p> <p><span><a href="https://world.episerver.com/documentation/Class-library/?documentId=commerce/8/8D26F8F9">https://world.episerver.com/documentation/Class-library/?documentId=commerce/8/8D26F8F9</a></span></p> <p><span><a href="https://world.episerver.com/documentation/Class-library/?documentId=commerce/9/8D26F8F9">https://world.episerver.com/documentation/Class-library/?documentId=commerce/9/8D26F8F9</a></span></p> <p><span><a href="https://world.episerver.com/documentation/Class-library/?documentId=commerce/10/8D26F8F9">https://world.episerver.com/documentation/Class-library/?documentId=commerce/10/8D26F8F9</a></span></p> <p><span></span></p> <p><span>I rechon I properly needs to go look in the db tables. Could you point me in the correct direction? :)</span></p> <p><span></span></p>

I think that one of your metafields has the same name (Weight), and it is of type Int ...

Thats correct.  Querying the Commerce 8 database of the site or the Commerce 10 database of the upgraded site I get the following results.

SELECT * FROM [dbCommerceManager].[dbo].[MetaField] where Name = 'Weight' 

MetaFieldId Name Namespace SystemMetaClassId FriendlyName Description DataTypeId Length AllowNulls MultiLanguageValue AllowSearch Tag IsEncrypted IsKeyField

194 Weight Mediachase.Commerce.Catalog 0 Weight NULL 26 4 1 0 0 NULL 0 0

SELECT * FROM [dbCommerceManager].[dbo].[MetaDataType] where DataTypeId = 26

DataTypeId Name FriendlyName Description Length SqlName AllowNulls Variable IsSQLCommonType DefaultValue

26 Integer Integer Meta Data Type 4 int 1 0 0 0

But the MetaField with id 194 doesn't belong to any MetaClass as this query returns 0 results:

SELECT * FROM [dbCommerceManager].[dbo].[MetaClassMetaFieldRelation] where MetaFieldId = 194

However when checking the table ecfVersionProperty which is a new table in the Commerce 10 upgraded site. Breaking change in Commerce 9.

SELECT * FROM [dbCommerceManager].[dbo].[ecfVersionProperty] where MetaFieldId = 194

pkId WorkId ObjectId ObjectTypeId MetaFieldId MetaClassId MetaFieldName LanguageName Boolean Number FloatNumber Money Date Binary String LongString Guid Decimal

156 22 40221 0 194 29 Weight no NULL 4500 NULL NULL NULL NULL NULL NULL NULL NULL
451 28 2032 0 194 29 Weight no NULL 1000 NULL NULL NULL NULL NULL NULL NULL NULL
....

....

All the successfully migrated ones. So the "Weight" MetaField with ID 194 belong to MetaClassId 29.

SELECT * FROM [dbCommerceManager].[dbo].[MetaClass] where MetaClassId = 29

MetaClassId Namespace Name FriendlyName IsSystem IsAbstract ParentClassId TableName PrimaryKeyName Description FieldListChangedSqlScript Tag

29 Mediachase.Commerce.Catalog.User VariationClass VariationClass 0 0 2 CatalogEntryEx_VariationClass PK_CatalogEntryEx_VariationClass NULL NULL

My problem is where do I find the data "Value of Weight is 0.007". As it properly is a "previous published" content version of the "VariationClass" it should be located in the DDS tables tblBigTable.

From page 58 in your book "Pro Episerver Commerce" data should be located in CatalogContentDraftStore. Serialized and stored in a big column of type nvarchar(MAX):

" Each version (which was call CatalogContentDraft) is stored in one row, and except the “static” data which is supposed to be on all version (such as content link, code, etc), all properties (aka IContent.Property) are serialized and stored in a big column of NVARCHAR(MAX)."

The columns of type nvarchar(MAX) in tblBigTable are named "String01" to "String10" but doesn't seem to be serialized data.

<p>Which database were you talking about? Because in Commerce 9 after migration all <span>CatalogContentDraft will be deleted&nbsp;</span></p>

Yes but my problem is that I'm not able to migrate previous published versions to new versioning system using the scheduled job "Draft store migration job"

As im upgrading from Commerce 8 the previous published versions are stored in DDS. Store "EPiServer.Commerce.Catalog.Provider.CatalogContentDraft". Data stored in tblBigTable.

I started upgrading from 8 -> 9 and running scheduled job "Draft store migration job" in Commerce 9 resulted in error "value is a System.Double but should be a System.Int32 Parameter name: value". Not to much use.

You recommended me to upgrade to Commerce 10. Running the scheduled job "Draft store migration job" here results in the error "Value of Weight is 0.007, of type System.Double, but should be an System.Int32". A little bit better error message but would have been nice if the error message had the content id included. 

My problem now is finding out which previous published version of CatalogContentBase (content id) stored in DDS Store = CatalogContentDraft that have a "weight" property with the value of "0.007".

I have no Commerce 8 database to look at right now, but that's trange. How many rows do you have if you select from that table with StoreName like '%CatalogContentDraftStore%'?

40757 rows.

I'm able to get all items in the store using this code:

DynamicDataStore draftStore = typeof(CatalogContentDraft).GetStore();
            var items = draftStore.Items<CatalogContentDraft>();

But when I use GetContent() method on CatalogContentDraft it throws a NullReferenceException

So String01 column is null (for those rows)? That's very strange and you might have a faulty database... 

Nope. Generally it has the values "Product", "Variation" or "Bundle". 421 rows have a null value in String01 column.

Using GetContent() method/Content property on CatalogContentDraft mentioned in my previous comment I get the following error:

System.NullReferenceException

Object reference not set to an instance of an object

   at EPiServer.Core.Transfer.Internal.ContentNameTransform.ShouldValidateUniqueness(TransformPropertyEventArgs eventArgs, IContentTransferContext context)
   at EPiServer.Core.Transfer.Internal.ContentNameTransform.ImportEventHandler(Object sender, TransformPropertyEventArgs e)
   at EPiServer.Enterprise.ImportingPropertyEventHandler.Invoke(ITransferContext transferContext, TransformPropertyEventArgs e)
   at EPiServer.Core.Transfer.Internal.DefaultPropertyImporter.ImportProperty(RawContent rawContent, IContent content, RawProperty importedProp, PropertyData propDestination, IContentTransferContext context, TransferImportOptions options)
   at EPiServer.Core.Transfer.Internal.ContentInterfaceImport.ImportProperty(IPropertyImporter currentTranfer, RawContent rawContent, IContent content, RawProperty importedProperty, IContentTransferContext context, TransferImportOptions options)
   at EPiServer.Core.Transfer.Internal.DefaultPropertyImporter.ImportProperties(IContent newContent, RawContent importedContent, IContentTransferContext context, TransferImportOptions options)
   at EPiServer.Commerce.Catalog.Provider.CatalogContentDraft.ConstructContent(ContentReference contentLink, ContentReference parentLink, String language, String masterLanguage, Byte[] serializedRawContent, String baseEntryType, Int32 metaClassId, Nullable`1 catalogId, String routeSegment, VersionStatus status, Nullable`1 startPublish, Guid contentGuid, String name, String existingLanguages)
   at EPiServer.Commerce.Catalog.Provider.CatalogContentDraft.ReconstructContent(ContentReference parentLink)
   at EPiServer.Commerce.Catalog.Provider.CatalogContentDraft.GetContent(ContentReference parentLink)

<p>How's about other String columns? Are there nothing on those?</p> <p>&nbsp;I would suggest you to contact Episerver support service. Getting a hand on your database would help to resolve this issue in matter of hours, or even minutes :)&nbsp;</p>

In the 421 rows as mentioned before the reason why String01 column ha a null value is because it is a previous published version of "NodeContent".

All rows which have  String01 column with values "Product", "Variation" or "Bundle" do also have data in the other StringXX columns.

String02 = ;;no;;da;;de;;nl;;sv;; so must be existing languages

String03 = Current langauge branch

String04 = master language branch

String05 = Name

String06 = NULL value

String07 = Name in URL

String08,09,10 are all NULL value

In Commerce 8 version of the site versioning works fine. I can see the previous published version in the Catalog UI. 

The same goes for Commerce 9 where I'm able to see those few that have been migrated from Commerce 8 structure to Commerce 9 structure when running the scheduled job "Draft store migration job".

contact Episerver support service: OK.

Found the problem. Problem not in the data in DDS store CatalogContentDraft but in the MetaField table. The MetaField "Weight" shouldn't be there at all. 

Looked thorugh commit history and found that we have had an "Weight" property (public virtual int Weight { get; set; }) ealier in the site (added back in 2014 and removed again). This has caused that this metafield were created but when the metafield got removed it appenrently didn't get deleted from the MetaField table :/

Why the "Draft store migration job" uses this metafield when running the migration I don't understand as the "Weight" metafield don't have any relation to the catalog content.

After I deleted the metafield in the MetaField table and re-ran the job it was successful: "Migrated 40723 PreviouslyPublished drafts."