uSync import failed: The existing DocumentCultureVariationDto was not found


I’m getting the above error when importing my uSync settings. It looks like it fails on a node in language 2 that hasn’t been published in that language, but is published in another language. When I unpublish the node (which is a step further than “not created”), it seems to work.

What I don’t understand is why this error occurs during the settings import, because to me this seems like it’s related to content rather than settings.

So my more general question is: what exactly does this error mean?

Greetings,
Joppe

Hi ,

Not 100% why it errors (will see if i can recreate).

but to answer why it happens on a settings import.

if you import changes properties in a document type, then there are internal umbraco events that fire and updates properties and content items and this is likely where the error is.

just looking at the code ,the error comes from a method called RenormalizeDocumentEditedFlags

specifically here :

my quick reading of this is - the property contains a definition for a language that isn’t there.

so maybe - on your settings import you are removing languages and that is why the property error throws or your content has been synced with languages that are not installed on the site and the rebalencing is throwing this up.

editing the content will like be fixing this as only the valud languages will be getting saved back.

still not 100% sure - will need to play with it a bit

Update
Just to add -

this code is fired in umbraco when a property goes from being not vary by culture to vary by culture or the other way around. so that’s the change that is firing it,

1 Like

Thanks Kevin for the swift response:
We recently changed some properties in this document type from ‘vary by culture’ to ‘shared’ and vice versa. That might be causing the issue. Is there anything we can do to resolve this?

Greetings,
Joppe

1 Like

Hi,

I am not sure - from the code i think its because one of the languages is missing , so maybe check all the languages that where previously installed are still there.

1 Like

Hi Kevin,

Thanks again for your swift response!

This does indeed seem to be the issue when I look at the value from the database table [dbo].[umbracoLanguage].
This is on the environment where I’m getting the error:
image

When I look at my local environment, where the error does not occur, I see this:
image

So it looks like the IDs for fr-BE don’t match.
Any idea how I can resolve this, without losing the already filled content on the environment where the error occurs?

Greetings,
Joppe

Hi Kevin,

We’re considering doing a live-to-local sync, followed by a clean export on the local Umbraco environment. This should ensure that all files are properly aligned again and that we have the correct language IDs locally.

Before running the export, I’ll make the changes locally that currently can’t be applied on the pre-live environment, so we don’t lose any updates.

Sounds good, right?

Greetings,
Joppe

Did you fix your issue?
Having the same.. @JoppeRuessink

Hi Thomas,

First of all, sorry for my late response — I know how frustrating this error must have been.

The issue was indeed that Umbraco tried to save property values for invalid variations. For example, a field might have been shared at first and later changed to culture-specific (or the other way around), but Umbraco keeps attempting to save all values, including the invalid ones, during each Save & Publish operation. That’s what triggers this error.

The problem likely arose when a DocType was modified (including changes to some property variations), and uSync applied those updates. Normally, uSync should remove or migrate the outdated values, but when many nodes are involved, that process can fail, leaving old data behind — which then causes the error.

We eventually fixed it by working directly on the database. Unfortunately, I no longer have the exact SQL queries… In short, we fetched the current version from the DB, compared the data in the property data table for that version, checked which values matched the content type’s variation settings, and simply deleted the invalid records. I also recall that rebuilding the indexes (External and Internal) was necessary.

Important: Make sure you do this very carefully. You’ll be deleting DB data that can’t be recovered. Always create a backup first.

I think it would be really helpful for the rest of the community if you could share the SQL queries you come up with here. Thanks in advance!

Best regards,
Joppe