Language culture error: "Database mapped field does not

Posted by Community Admin on 04-Aug-2018 16:19

Language culture error: "Database mapped field does not exist"

All Replies

Posted by Community Admin on 22-Nov-2012 00:00

I've just had a peculiar error with the latest version of SF 5.2.3800, just after completing a migration progress from a 3.7sp4 site. I got a "Database mapped field does not exist" error when I tried to log in, preventing me from getting into the Dashboard or any part of the backend:

Database mapped field does not exist.
Parameter name: methodCallExpression
Actual value was p.FieldValue("UrlName_en_gb").Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentOutOfRangeException: Database mapped field does not exist.
Parameter name: methodCallExpression
Actual value was p.FieldValue("UrlName_en_gb").

For the full error see:

At first I wondered whether I had forgotten to set something up during the installation process, but after trying to log in on another computer, I got the same error but with a different culture in the field name ("UrlName_en_ca" instead of "UrlName_en_gb"). That made me think the issue was browser-specific. Turns out that was the case: as soon as I switched the dominant language in my browser to neutral-culture english ("en"), I was able to gain access to the Dashboard again.

Since this hasn't happened before in previous migration attempts, I wonder whether it's a bug in 5.2.3800. It seems like a pretty serious problem—I don't want to have to warn everyone who wants to access the backend that they'll have to change the language settings in their browser. Any ideas?

Posted by Community Admin on 23-Nov-2012 00:00

Hello Dan,

We have replied in the other forum thread you had posted about the same issue, you can check our response there as well, however for your convenience please check below a summary of our findings:

We have tried reproducing it on several projects, using browser locale different than the cultures configured in Sitefinity, however the behavior has been consistently working.

It looks like the sitemap provider is trying to resolve a node for a culture that it doesn't have translation (the browser culture).

Would it be possible to let us know if you have managed to isolate any further steps for reproducing the problem so we can verify this issue locally?

Thank you in advance for the kind cooperation.

Boyan Barnev
the Telerik team

Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

This thread is closed