locked
sharepoint list-Culture ID 1164 (0x048C) is not a supported culture RRS feed

  • Question

  • Hi i am also having this problem when trying to edit site columns at MOSS2007.
    Culture ID 1164 (0x048C) is not a supported culture. Parameter name: culture
    i Have read the forum online and the solutions that a lot of person seems to have is "to replace the Microsoft.SharePoint.ApplicationPages.dll having new version 12.0.6529.5000"
    My version is 12.0.6520.1000
    How do i obtain 12.0.6529.5000?

    the other solution that the online forum seems to suggest is to reinstall the .net framework. do you mean replacing and reinstalling the entire suite 2.0, SP2, 3.0. 3.5 SP1 ?

    Can i get more clarification on what the solution is and how to solve it ?

    Thanks

    • Edited by EK Tan Thursday, January 20, 2011 11:15 AM edit
    Thursday, January 20, 2011 11:12 AM

All replies

  • Hi EK Tan,

     

    Thank you for sharing your problem.

     

    Please check the following two threads and I think you’ll find the solution:

    http://serverfault.com/questions/133227/sharepoint-2007-problem-after-feb-2010-cu;

    http://social.technet.microsoft.com/Forums/en/sharepointadmin/thread/237a82a6-8f45-435a-bdcc-72ce9e63cf0f.

     

    hope this could help you.

     

    Regards.

    Friday, January 21, 2011 4:19 AM
  • Hi Peng Lei, thanks. However after reading, i am still puzzled. I am using version 12.6520.1000, how do i get the dll file with version 12.6529.5000 ? and also on another forum, they suggest that it's the .net framework issue, i do not know which answer is relevant ?
    Monday, January 24, 2011 5:13 AM
  • here is a snapshot of my error message after trying to edit a site column.
    Culture ID 1164 (0x048C) is not a supported culture.
    Parameter name: culture   at System.Globalization.CultureTableRecord.GetCultureTableRecord(Int32 cultureId, Boolean useUserOverride)
       at System.Globalization.CultureInfo..ctor(Int32 culture, Boolean useUserOverride)
       at System.Globalization.CultureInfo..ctor(Int32 culture)
       at Microsoft.SharePoint.SPFieldCurrency.GetCombinedNumberFormatInfo(NumberFormatInfo nfiFmt, Int32 currencyLocaleId, SPNumberFormatTypes displayFormat)
       at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.GetCurrencyItemString(Int32 lcidCurrency)
       at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.PopulateCurrencyList(DropDownList ddl)
       at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.OnLoad(EventArgs e)
       at System.Web.UI.Control.LoadRecursive()
       at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
    Wednesday, January 26, 2011 4:07 AM
  • Browse to c:\program files\common files\microsoft shared\web server extensions\12\TEMPLATE\1033\XML\
    Make sure you make a back up copy of the RGNLSTNG.XML
    Edit the RGNLSTNG.XML file and remove the below entries from the file
    <Locale ID="1164" Name="Dari">  </Locale>

    <Currency ID="1164" />

    Go to c:\program files\common files\microsoft shared\web server extensions\12\CONFIG\ and see if you have RGNLDFLT.xml . If yes then make a backup copy of the file RGNLDFLT.XML

     ->  Edit RGNLDFLT.xml and remove following entry:

    <liddefault lid="1164" caltype="1" tzid="48" time24="0" currencylid="1164" isrtl="1" iseastasia="0"/>

     -> Perform an iisreset

    -> Try editing a column and you should be able to edit it now.

     

    Sunday, October 2, 2011 1:18 AM
  • These steps are NOT recommended as they require to change a file coming with SharePoint which is unsupported.

    Moderator, please unpropose as answer!

    The correct way to deal with this problem is to install the latest CU which will bring a newer version of the Microsoft.SharePoint.ApplicationPages.dll.

    Then you have to ensure that the DLL in all web site directories has been successfully updated. Sometimes the dll does not get replaced in one web application and then you end up with a state like listed above.


    Stefan Goßner
    Senior Escalation Engineer - Microsoft CSS
    This post is provided "AS IS" with no warrenties and confers no rights.
    Sunday, October 2, 2011 4:01 PM
  • Not recommended. Fine. However what could possibly go wrong if we edit it (when we have a back up of the file).

    And regarding the version of Microsoft.SharePoint.ApplicationPages.dll, what should be the version it should be on. I'm not sure if the file is version specific. Since we have encountered the same issue when the version was 12.0.6562 (June 2011 CU), for all the virtual directories. We made sure the version was up to date for all the virtual directories. June doesn't seems to be a very old version.

    Sunday, October 2, 2011 6:36 PM
  • Hi Vishwas,

    not recommended and not supported.

    You asked what can go wrong: if you are not going to install any further fixes on this system in the future: most likely nothing.

    But if you plan to install future CUs: a lot of things!

    The installer which is responsible to patch the files when installing CUs can easily identify the version of a dll by looking at the included version information.

    But text files do not have such attributes. So the installer looks at a combination of file size, date/time and hash of the file content to determine the version of the file. If the file has been changed, then the installer cannot identify the file version correctly and can only go for the last modified date.

    The problem comes in if (e.g.) August CU would bring an updated version of the file. You might have a patch level of June CU and then update the file in September because you did not have time to evaluate August CU.

    When you now install August CU later, then the installer sees, that the file is already newer as the file in the CU - which means the file will not be replaced. So you end up with a (modified) June CU file which should have been updated to August CU.

    We had customers who had files from various different patch levels in their installation folder. You can imagine that this can lead to various different unpredictable errors in the system.

    Back to your question: what can go wrong if we keep a backup?

    If you keep the backup AND ensure that you are replacing the changed files with the backed up file before installing an future patches you would be fine.

    But believe me: no customer does that in a reliable way.

    We had several customers who had to do a complete reinstall of their SharePoint installation to get all the files cleaned up to a consistent state.

    Cheers,
    Stefan


    Stefan Goßner
    Senior Escalation Engineer - Microsoft CSS
    This post is provided "AS IS" with no warrenties and confers no rights.
    Monday, October 3, 2011 11:14 AM
  • Hi

    I'm in the middle of upgrading from 2007 to 2013, and have just applied the last of the service packs etc. to 2007 in readiness for migration.

    I'm seriously wishing I hadn't now as I not only have the above problem, but it's also preventing search from running and won't allow me to edit / view the column in site management.  I've had to move the site to a newly created SSP and so have had to try and recreate some Metadata properties, but due to the crawler not working, I cannot see the columns to map too.

    I've had to reset the search as they were started on the Friday and were found to still be running today - MONDAY!

    The Microsoft.SharePoint.ApplicationPages.DLL version I have running on all my systems is file version 12.0.6602.1000.

    And all the systems are running SP3.

    Any help is appreciated.

    Thanks

    David


    • Edited by DiaGeordie Wednesday, May 14, 2014 7:59 AM clarity
    Monday, May 12, 2014 11:36 AM
  • Hi

    I solved the problem, after taking a closer look at the GAC, and in particular the version of Microsoft.SharePoint.ApplicationPages.DLL it expected to see.

    The result was I discovered the GAC hadn't been updated during the recent SP3 upgrade, so I found GACUtil.exe (and it's config file); placed them plus the DLL into a temp folder and ran GACUtil / u Microsoft.SharePoint.ApplicationPages     then GACUtil /I Microsoft.SharePoint.ApplicationPages.DLL, on all the SharePoint servers.  The problem was resolved. :)  All the crawlers were restarted.

    Note to self check the GAC has been updated next time, hope the above helps anyoneelse with a similar problem.

    Thanks

    David

    Wednesday, May 21, 2014 2:50 PM