Hi,

EDIT: This will not work as the migration step uses SqlHelper which does not call SqlDataProvider internally. Sorry for the confusion

You should be able to add commandTimeout attribute to SqlDataProvider to override the command time out, like this

        <add name="SqlDataProvider" type="Mediachase.Data.Provider.SqlDataProvider, Mediachase.SqlDataProvider" connectionStringName="EcfSqlConnection" applicationName="ECApplication" commandTimeout = "120"/>

How much record you have in ApplicationLog table?

Reagrds
/K

I hope you did resolve this issue by a workaround.

For future visitors: We filed a bug for this and it will be resolved by upcoming releases (9.20 or so) - if you run into problem with Migrates promotion information, adjust the commandTimeout as above post.

Regards,

/Q

Hi,

I've found a work-around. In the end I've copied the migration step code into an aspx file and set the timeout in the file.  After running the script on the server, I executed the following:

update tblBigTable set Boolean01 = 1 where string01 = 'EPiServer.Commerce.Internal.Migration.Steps.MigratePromotionInformationStep' and StoreName = 'EPiServer.Commerce.Internal.Migration.MigrationStepInfo'

thanks

@Quan:

Make sure you check all your migration steps. RemoveOrphanedMetaKeysStep don't appear to offer a way to modify the command timeout. If you have a solution to that step, please let me know asap.

How many rows do you have if you run this query? Any duplicated rows?

SELECT K.MetaKey
FROM MetaKey K
LEFT OUTER JOIN
(SELECT P.Number FROM CatalogContentProperty P
INNER JOIN MetaField F ON P.MetaFieldId = F.MetaFieldId
INNER JOIN MetaDataType T ON F.DataTypeId = T.DataTypeId
WHERE T.Name IN ('DictionaryMultiValue', 'EnumMultiValue', 'File', 'ImageFile', 'StringDictionary', 'MetaObject')) U
ON K.MetaKey = U.Number
WHERE K.WorkId IS NULL AND U.Number IS NULL
ORDER BY MetaKey

@Quan

Sorry, I don't have a unmigrated database right now. I did a ugly workaround - I copied the step into my own custom step and just increased the command timeout. I also removed the original step by overriding MigrationManager and MigrationStore - so that my custom step could use the same step order as the original step (104).

I can tell that around 8 000 000 (from 9.5 to 1.5) meta keys was removed in the step. Some batches in the step took just over 30 seconds, even if I reduced the app setting ecf:RemoveOrphanedMetaKeysBatchSize (defaulted to 10 000).

One other work around is to run the script in SSMS to avoid the timeout, and then the migration step would complete with ease.

@Quan

When should I execute the script from RemoveOrphanedMetaKeys? Before all migration steps or after all steps? (I can prevent RemoveOrphanedMetaKeys using my existing MigrationManager/MigrationStore)

Btw, is this script correct? (I removed the @batch part)

;DECLARE @AllOrphans TABLE (MetaKey INT)

INSERT INTO @AllOrphans(MetaKey)
SELECT K.MetaKey 
FROM MetaKey K
LEFT OUTER JOIN
    (SELECT P.Number FROM CatalogContentProperty P
        INNER JOIN MetaField F ON P.MetaFieldId = F.MetaFieldId
        INNER JOIN MetaDataType T ON F.DataTypeId = T.DataTypeId
        WHERE T.Name IN ('DictionaryMultiValue', 'EnumMultiValue', 'File', 'ImageFile', 'StringDictionary', 'MetaObject')) U
ON K.MetaKey = U.Number
WHERE K.WorkId IS NULL AND U.Number IS NULL
ORDER BY MetaKey

DELETE D
FROM MetaMultiValueDictionary D
WHERE EXISTS (SELECT 1 FROM @AllOrphans WHERE MetaKey = D.MetaKey)

DELETE O
FROM MetaObjectValue O
WHERE EXISTS (SELECT 1 FROM @AllOrphans WHERE MetaKey = O.MetaKey)

DELETE F
FROM MetaFileValue F
WHERE EXISTS (SELECT 1 FROM @AllOrphans WHERE MetaKey = F.MetaKey)

DELETE S
FROM MetaStringDictionaryValue S
WHERE EXISTS (SELECT 1 FROM @AllOrphans WHERE MetaKey = S.MetaKey)

DELETE K
FROM MetaKey K
WHERE EXISTS (SELECT 1 FROM @AllOrphans WHERE MetaKey = K.MetaKey)

I think it would make sense to try to run all the migration steps until the timeout exception happens - then run the sql above and then try to run the migration steps again.

It would help to resolve the problem if you run query I gave in the post above against your non-migrated database - if there are duplicated rows then it would make the fix simpler.

Regards,

.Q