Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • mcgrph 35 posts 162 karma points
    Jan 02, 2020 @ 11:29
    mcgrph
    0

    Content migration fails (data truncated)

    Happy new year everyone,

    we decided, that it's time to upgrade the Umbraco version of our project from 7.10 to v8. I initially upgraded to 7.15.3 to prepare for the content migration which is now available. But when I try to start the update process (after changing the connection string to our current db) it fails with the following message: enter image description here

    After taking a look into the log file, I've stumbled upon this entry:

    enter image description here

    After some research, it came to my mind, that some years ago we've updated the property dataNvarchar of table cmsPropertyData to nvarchar(max) because of some issues we had with the max-length. This seems to be causing the issue.

    After some googling around, I've stumpled upon this forum topic: https://our.umbraco.com/forum/umbraco-8/99194-umbraco-8-upgrade-taking-long-time

    The hint to try modifying the Umbraco.core.dll seemed like a good approach without having to deal with manually shortening all the data stored in the table. This is where my question starts:

    I think I've found the correct file, where the update mechanism is executed (VariantsMigration.cs), but I cant figure out, where to set or change the size of the property to match our current implementation. Does anyone can point me to it? Any help would be appreciated!

  • Steve Megson 151 posts 1022 karma points MVP c-trib
    Jan 03, 2020 @ 11:57
    Steve Megson
    1

    The column definitions are set through attributes in Umbraco.Core\Persistence\Dtos\PropertyDataDto.cs. Unfortunately I don't think it's possible to specify nvarchar(max) in that way, since the attribute expects an integer length.

    However, the migration will check whether the dataNvarchar column exists before it tries to replace it. If you manually rename the dataNVarchar column to varcharValue before starting the migration, I think that should work.

  • mcgrph 35 posts 162 karma points
    Jan 09, 2020 @ 07:30
    mcgrph
    0

    Thank you. I've tried it and now it seems that the migration doesn't stumble upon this anymore. Going to keep this thread updated, if everything works out.

Please Sign in or register to post replies

Write your reply to:

Draft