Locale Identifier Bug - by Boyan Penev

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


24
0
Sign in
to vote
ID 721372 Comments
Status Closed Workarounds
Type Bug Repros 8
Opened 1/28/2012 6:54:24 PM
Access Restriction Public

Description

The "XML for Analysis parser: The LocaleIdentifier property is not overwritable and cannot be assigned a new value." message gets shown in Excel (drill-through only), Cube Browser (BIDS and SSMS) and SQL Server Profiler.
Sign in to post a comment.
Posted by nlievain on 6/25/2013 at 2:46 AM
Hi, I just meet this problem today (excel 2010 32 bits, SSAS 2K8 R2)
I did the test on multiple computer, some were working some other not

And i found the non working computer had a excel add in installed "palo for excel"
On an msdn post ( http://social.msdn.microsoft.com/Forums/sqlserver/en-US/6356f21c-c60b-4ceb-ac6b-8203b9981b18/office-2010-drillthrough-xml-for-analysis-parser-error-the-localeidentifier-property-is-not ) i red that this issue happen with old version of "olap pivot table extensions" but has been solved with the latest version. (this add in was not installed on any computer here)

I try to install the last version on this add in and...it works!
I guess some add ins (palo and / or others) install some old files overwriting some official excel files (olap drivers?).


By installing the last version of "olap pivot table extension" it make my drillthrough actions working.
Hope it will help
Posted by Microsoft on 4/13/2012 at 11:59 AM
Thanks for reporting this issue. We have confirmed the problem and passed this along to the Excel team. Excel will be looking at this as something they will address in some future release of the product.

Thanks,
Analysis Services Product Team
Posted by Udumuth on 4/6/2012 at 12:20 AM
"We took a US operating system (tried Vista, Windows Server R2 and Windows 7). Changed Regional Settings to English (Australia)"

This is the wrong way. You have to install windows (I tried win 7) with non US regional settings and then you'll get an error.
If you apply US regional settings once (on installation or after that) everything works fine.
Posted by nrc73 on 2/23/2012 at 10:29 PM
I also live in Australia and have gone through an identical process as Boyan has. Very frustrating bug. There are a number of scenarios where chnage the OS Locale setting to US is not possible due to wider impact. Continued investigations appreciated.
Posted by Boyan Penev on 2/21/2012 at 4:26 PM
Thanks for reactivating it! Darren Gosbell and I have been looking into this and trying to compare the relevant registry entries on two PCs - one which has the issue and one which does not (because we've flicked the rgional settings to US and back). So far no luck, but we can definitely see that all else equal (same SOE image), this setting does the trick for some reason. Still investigating. I'll post more info if we get anywhere...
Posted by Microsoft on 2/3/2012 at 6:43 PM
Internally it is open. We are having difficulties to make the Connect Item 721372 (this one) to transition from Closed to Active state.

So if you could reactivate 721372 yourself then please do so.

The repro we have, actually is not very interesting. When starting Excel and then changing Regional Settings before creating any pivot table, results in that error during Drill Through. If the pivot table is created after the language change then things work.

The pivot table browsing itsef works fine, only Drill Through is broken. Similar case happens with Cube Browser. The parts written in managed code like metadata tree view on the left work fine. The OLEDB based OWC Pivot Table is broken. We have some thoughts about it and will take a look. Still, this state is easily solvable by restarting Excel or Visual Studio.

The most interesting case when everything is broken till a transition to English US has been done - we still need to repro it and we are working in that direction. Thanks!

Posted by Boyan Penev on 2/3/2012 at 6:00 PM
Since you can reproduce...can we please open it again??
Posted by Boyan Penev on 2/3/2012 at 5:59 PM
It is quite common here in Australia with SOEs set up to install Windows with Australian settings. 3 out of my last 5 clients are experiencing the issue on all standard config workstations. These are a large federal department, a large state department and a large Telco.
Posted by Microsoft on 2/3/2012 at 3:36 PM
Thanks. The error is raised when the language associated with Session does not match with the language associated with the request. We do have a repro, even on non Win7 OS, but the way we succeeded to repro was *really* tricky and we are evaluating what exactly the bug is.
Posted by Boyan Penev on 2/2/2012 at 8:59 PM
Once you change to US settings the bug disappears :) So, I guess you should try by isntalling Windows (best with 7) with Australian settings - select Format English (Australia), or UK, or something else. Then install Office and try again. As I have mentioned in my post about this issue, if one has the problem and switches to English (US) and then back to English (Australia) the problem disappears, which is very strange indeed. This proves that if you install with English (US) and then switch to Australia the issue will probably not appear.
Posted by Microsoft on 2/2/2012 at 7:05 PM
Hello Boyan,

There might be misunderstanding on our side about how to reproduce the issue properly. Here is what we did. We took a US operating system (tried Vista, Windows Server R2 and Windows 7). Changed Regional Settings to English (Australia) and then connected to a database with drill-through action running on the build 10.50.1600.01 or later. The OLEDB provider on the machine with the English(AU) regional settings was also 10.50.1600.01 or later.

Cube Browser and Excel 2010 showed the result of the action. The trace showed the request to change LocaleIdentifier like below.

DRILLTHROUGH MAXROWS 1000 Select ([Measures].[Tax Amt],[Dim Product].[Size Range].&[70]) on 0 From [AS Adventure Works DW] RETURN [Fact Internet Sales].[Sales Amount],[Fact Internet Sales].[Tax Amt],[$Dim Product].[Product Key],[$Dim Product].[Size Range],[$Dim Product].[Weight],[$Dim Product].[Style]
<PropertyList xmlns="urn:schemas-microsoft-com:xml-analysis">
<Catalog>Analysis Services Project1</Catalog>
<ShowHiddenCubes>True</ShowHiddenCubes>
<SspropInitAppName>Microsoft Visual Studio</SspropInitAppName>
<Timeout>3600</Timeout>
<LocaleIdentifier>3081</LocaleIdentifier>
<ClientProcessID>1800</ClientProcessID>
<Format>Tabular</Format>
<Content>SchemaData</Content>
</PropertyList>

In one case we switched to Australian regional settings before even installing SQL Server on the machine. Do you see anything different with your repro steps?
What happens after the workaround (switch to English(US) and back to English(Australia))? Do you ever see the problem again?