MSOLAP Provider: Internal error: An unexpected error occured (file 'mddscells.cpp', line 333, function 'MDDSCells::MoveToCellProperty')

问题 MSOLAP Provider: Internal error: An unexpected error occured (file 'mddscells.cpp', line 333, function 'MDDSCells::MoveToCellProperty')

  • Tuesday, May 15, 2012 9:52 AM
     
     

    I am using the pivot table in Excel 2010 (v 14.0.6112.500 32bits) and after having created a pivot table from a XMLA connection with my server using the MSOLAP 3.0 (or the MSOLAP 4.0) provider, I got the following error when trying to open the member selector for the Products dimension used as a report filter:

    Internal error: An unexpected error occured (file 'mddscells.cpp', line 333, function 'MDDSCells::MoveToCellProperty')

    If I use another provider, like Simba 02X http://www.simba.com/odbo-to-xmla.htm no error occurs when opening the selector on the Product dimension.

    The two XMLA exchanges server <-> MSOLAP 3, server <-> Simba are quite different, as both of these providers make slightly different requests so this is not straightforward to find in them the cause of this problem, however Excel or the provider should cope better with what could be an unexpected response from the server and not throw like this. I can provide these exchanges if needed for a fix in the provider.

    If someone has a suggestion on how to fix the behavior for the MSOLAP providers or a workaround that would be greatly appreciated.

    Regards

All Replies

  • Wednesday, May 16, 2012 7:00 AM
    Moderator
     
     

    Hi,

    When run a Multidimensional Expressions (MDX) query by using a calculated member. The query contains an IIF or CASE statement. Then this issues may occur.

    This is because there is an iteration when the branch code runs the IIF statement.

    The resolution is :

    • SQL Server 2008 Service Pack 1

    The fix for this issue was first released in Cumulative Update 9 for SQL Server 2008 Service Pack 1. For more information about this cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:

    2083921 (http://support.microsoft.com/kb/2083921/LN/ ) cumulative update 9 for SQL Server 2008 Service Pack 1

    Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2008 fix release. Microsoft recommends that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    970365 (http://support.microsoft.com/kb/970365/LN/ ) The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 1 was released

    Microsoft SQL Server 2008 hotfixes are created for specific SQL Server service packs. You must apply a SQL Server 2008 Service Pack 1 hotfix to an installation of SQL Server 2008 Service Pack 1. By default, any hotfix that is provided in a SQL Server service pack is included in the next SQL Server service pack.

    • SQL Server 2008 Service Pack 2

    The fix for this issue was first released in Cumulative Update 1 for SQL Server 2008 Service Pack 2. For more information about this cumulative update package, click the following article number to view the article in the Microsoft Knowledge Base:

    2289254 (http://support.microsoft.com/kb/2289254/ ) Cumulative update 1 for SQL Server 2008 Service Pack 2

    Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2008 fix release. We recommend that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    2402659 (http://support.microsoft.com/kb/2402659]/ ) The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 2 was released

    Quote from:

    http://support.microsoft.com/kb/2152148


    Jaynet Zhang

    TechNet Community Support

  • Friday, May 18, 2012 2:14 PM
     
     

    Did you get any solution for this?

  • Monday, May 21, 2012 12:56 PM
     
     

    I am not using SQL Server 2008 but another XMLA capable server, and I am developing the XMLA connector with Excel. This is why I am interested in a fix on Excel side, or pointers on how to avoid this bug by following some rules in the XMLA response. 

    You said:

    When run a Multidimensional Expressions (MDX) query by using a calculated member. The query contains an IIF or CASE statement. Then this issues may occur.

    This is because there is an iteration when the branch code runs the IIF statement.

    The fact is that this error happens even with very simple MDX queries like "SELECT FROM Cube WHERE Measure" without CASE or IIF statements. I didnt understand the "there is an iteration when the branch code runs the IIF statement", an iteration over what? What can I change to avoid that?

    If I understand your suggestion there was a patch server side for SQL Server to fix this, what is the goal of this patch? What was the change in the behavior of the server which could be reproduced in another server?

    I would prefer a fix on client side since this is clearly Excel that fails and not the server, even if this error is due to a part of the XMLA specification not honored by the server (I would also be happy with this cause if you tell me which XMLA specification part is concerned by this message).

    Regards

    Olivier

  • Thursday, May 31, 2012 9:20 AM
     
     

    I experience exactly the same error message in Excel, also when using an XMLA provider that is not SQL Server.

    I have noticed that the error only occurs with Excel 2010. Using the same XMLA server, everything works well with Excel 2007.


    -Chamb

  • Thursday, May 31, 2012 9:37 AM
     
     

    I am seeing the exact same issue.

    Could we get a fix for Excel from Microsoft? A MSSAS fix is useless for us since we are using a different OLAP provider.

    Thanks!