One of the requirements for the dashboards was to support English, Dutch and French. Because the data was loaded from an Analysis Services Cube, I added the extra required translations to the Analysis Services Project: Dutch-Belgium and French-Belgium.

The SharePoint site was already configured to support the 3 display languages:

The Analysis Services Translations were working correctly in every other environment but for some strange reason not in the PPS Components (Analytic Grids, Charts, …)

A very smart guy at Microsoft (Thanks, Wesley ) gave me the tip to use the profiler to have a look at the MDX that PPS sends back to Analysis Services. In the details of the “Query Begin” event I found this MDX:

<PropertyList xmlns=”urn:schemas-microsoft-com:xml-analysis”>
<DbpropMsmdMDXCompatibility>2</DbpropMsmdMDXCompatibility>
<Catalog>Titanium</Catalog>
<LocaleIdentifier>1036</LocaleIdentifier>
<Format>Multidimensional</Format>
<AxisFormat>TupleFormat</AxisFormat>
<Content>SchemaData</Content>
<Timeout>300</Timeout>
</PropertyList>

Okay, it looks like PPS sends the requested locale identifier to Analysis Services. But 1036 is the language code for France and I am in Belgium:

• French – France: 1036
• French – Belgium: 2060
• (More language codes: http://msdn.microsoft.com/en-us/goglobal/bb964664)

But why is Performance Point using the wrong language code? The answer is actually very simple: Because of the installed language packs for SharePoint.

When you have a look at the available language packs for SharePoint (http://technet.microsoft.com/en-us/library/ff463597.aspx), you will see that there is only 1 French language pack, with language ID 1036.

So I solved the problem by adding yet another translation to the Analysis Services Project: French-France.

Enjoy the translations!

SQL Server Management Studio makes it very easy for you to create XMLA-scripts to create or alter cubes, dimensions, etc… But it’s not possible to use Management Studio to create an alter-script that only contains the MDX calculations. Because I needed to resolve a bug in the calculations but the rest of the cube was not ready to be deployed to production yet, I had to create an alter script just for the MDX.

Of course I could have started learning the XMLA-syntax to write a script for this, but I decided to go for the easy way: the BIDSHelper has an option to deploy the MDX to a cube without having to deploy the entire cube.

If you don’t know BIDSHelper, or don’t already have it installed, go to http://www.codeplex.com/bidshelper. This is a must have add-in for all SSAS and SSIS developers!

But as I was allowed to use Management Studio to makes changes to the cubes in the development environment only. So I needed to capture the XMLA script the BIDSHelper executes on the cube, to deploy the same script to the production environment.

That what the profiler is for, not? J

Open the SQL Server Profiler, create a new trace and connect to the analysis services instance. Use a blank template and switch to the tab “Events Selection”. The only event we want to capture here is “Command Begin”.

Click Run.

Now the profiler is ready to capture the XMLA-script, so switch back to Management Studio and use the BIDSHelper to deploy the MDX calculations. When the deploy is finished you can stop the trace.

The profiler should have captured 2 events. The event with subclass “Alter” is the one we need.

Copy the script from the profiler to a new XMLA script in Management Studio.

The last 3 lines (PropertyList) can be deleted.

In the node “ObjectDefinition” you will find your script.

Enjoy!

• Opening Keynote by Wesley Backelant and Ritchie Houtmeyers
• Best Practices for SQL Server Consolidation by Tom Van Mulders
• Breaking the ETL world record with Integration Services by Henk van der Valk
• Designing Effective Aggregations in Analysyis Services 2008 by Chris Webb
• High availability for BI DWH by Patrick Tack
• How New.NET Development technologies could change the live of the SQL DBA guy/girl by Gill Cleeren & Kurt Claeys
• Implementing best practices with Policy Based Management by Nico Jacobs
• Introducing to PowerPivot or How I Learned to Stop Worrying and Love Excel by Chris Webb
• Tracking Changes and Data movement in SQL Server 2008 by Dirk Gubbels
• Handling XML in SQL Server by Nico Jacobs

Have fun!

bing brought me to the following great article, where Mosha explains how you can use MDX to create a custom format:
http://sqlblog.com/blogs/mosha/archive/2008/09/26/displaying-duration-values-mdx-expressions-in-format-string.aspx

When you apply this for a calculated member you get something like this:

    CREATE MEMBER CURRENTCUBE.[Measures].[DurationInDays]
     AS [DurationInDays],
    FORMAT_STRING =  
        IIF([Measures].[Duration] < 1
         ,’”0 days” hh:mm:ss’
         ,’”‘ + cstr(int([Measures].[Duration])) + ‘ days” hh:mm:ss’)
    ,
    VISIBLE = 1;

But this brings us to another problem:
This custom format will only display the correct result if [Measures].[Duration] contains decimal seconds.
For more information about the conversion from seconds to decimal seconds, read the following article on wikipedia: http://en.wikipedia.org/wiki/Decimal_time
In short, you need to divide the number of seconds by 86.400. The resulting number presents the number of days on the left side of the decimal separator and the remaining decimal seconds on the right side.

So the final result will be something like this:

    CREATE MEMBER CURRENTCUBE.[Measures].[DurationInDecimalSeconds]
     AS
        [Measures].[DurationInSeconds] / 86400,
    VISIBLE = 0;  

    CREATE MEMBER CURRENTCUBE.[Measures].[DurationInDays]
     AS [Measures].[DurationInDecimalSeconds],
    FORMAT_STRING =  
        IIF([Measures].[DurationInDecimalSeconds] < 1
         ,’”0 days” hh:mm:ss’
         ,’”‘ + cstr(int([Measures].[DurationInDecimalSeconds])) + ‘ days” hh:mm:ss’)
    ,
    VISIBLE = 1;

If you want this custom format to be displayed in Excel, make sure the connection properties are set correctly to retrieve the number format from the server:

Go to Connection Properties, tab Usage, and check Number Format in the OLAP Server Formatting options.

There is one more thing I would like to tell you about these options: Normally all these options will always be checked by default, but I’ve noticed that when you start from an existing odc-file, this is not the case. So, when you’re used to deliver an odc-file to your users to start analyzing from Excel, you will have to replace this odc-file by an Excel template that connects to the cube, to make sure this option is always on.

There might be a better way to change this behavior for odc-files, but I couldn’t find any. If you know it, please let me know

Enjoy!