Umbraco-cms: Upgrade from 7.15 to 8.1 fails: "System.FormatException: The string was not recognized as a valid DateTime. There is an unknown word starting at index 0"

[JannesMeyer]

We have a database that was upgraded from Umbraco 6.x to 7.15 over time and now we are trying to upgrade to 8.1.

This migration error happens when Umbraco is trying to parse the values of certain hardcoded property types that it assumes to be DateTime properties in AddTypedLabels.cs:

But in our database these IDs correspond to these property types:

So it inevitably encounters some strings that cannot be parsed as DateTime.

---

_This item has been added to our backlog AB#1757_

[bergmania]

Hi @JannesMeyer

I can't figure out, how you got these aliases on these Id's.

The correct aliases on these Ids is:

Id | Alias
-- | --
32 | umbracoMemberLastLockoutDate
33 | umbracoMemberLastLogin
34 | umbracoMemberLastPasswordChangeDate

What id's do these aliases have in your setup?

[JannesMeyer]

Hi @bergmania

Those aliases are at the following IDs:

I don't know how the database reached this state, but it must have been like that since a long time. I think the project started on Umbraco 4.x, but someone else set it up originally.

[bergmania]

@JannesMeyer,
I have now looked into very old versions of umbraco.

These aliases was introduced in Umbraco 6.2 and the Ids seems to have never changed since.

I think you will need to figure out, why and how you data ended up in this way.

[JannesMeyer]

I can't exclude the possibility that someone else did something weird (such as deleting and re-creating) before I inherited the project.

However, couldn't you query the IDs of the aliases in the migration? Or couldn't you check the dataType of the propertyTypes before you assume that they are dates?

[bergmania]

This is very much an edge case.
I have marked the issue as up-for-graps, and a solution could be to test the alias and Id is as expected, and otherwise load using the alias.

Overall I'm a bit afraid off doing a disservice, by letting the unexpected data pass through the migration. It could end up in another issue later on, that is even harder to find the root cause of.

[umbrabot]

Hi @JannesMeyer,

We're writing to let you know that we've added the Up For Grabs label to your issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post

Thanks muchly, from your friendly PR team bot :-)

[stevemegson]

If the database started out in an older version than 6.2.0, then the standard member properties wouldn't exist unless you added them manually (and of course their IDs would then be whatever was next available).

If the properties don't exist at all then ignoring them in the upgrade shouldn't break anything that wasn't already broken, so we can probably guess that the site isn't using members anyway. If they exist with the wrong IDs then I think everything will cope if the conversion doesn't happen, though it would be nice to handle it. This would also affect anyone who has added extra media/member types with the standard property aliases, which is probably more common that pre-6.2.0 sites being upgraded.

I'll have a look at doing a PR to choose the data types based on alias rather than ID. I suppose there's always a risk that someone is using the standard aliases for their own purposes with incompatible values, but anyone storing dates in a property called umbracoBytes has only themselves to blame.

[JannesMeyer]

Hi @stevemegson

Thanks for your reply. That makes sense.

Our site is using members, and so far we haven't observed anything being broken members-related except for this migration.

[elit0451]

Fixed in #5967