Hi everyone,
I have created a stored procedure in SQL 2005 which will create (sliced) local cubes using the CREATE GLOBAL CUBE (MDX) statement. This procedure will be started from a SSIS package which is deployed on the same server. A SQL server login with sysadmin permissions can start this SSIS package and create multiple (sliced) off line cubes on the file system.
Everything seems to work fine and no errors where raised during execution. However when I try to open the .cub file in ProClarity 6.2, or even Excel, I get the following message. "File System Error: An error occurred while opening the <file path and name> local cube file."
The strange thing is...., whenever I exectue this package using a domain account with admin permission, the cube file turns out fine.
Furthermore the same package works just fine in our test enviroment. (32 bit virtual server)
The machine that is causing these symptoms is a 64 bit server. Logically I suspected the difference between these enviroments could be a cause. I have tried to narrow the possibilities down to just the creation of off line cubes (and SSAS).
Could security be the cause of this problem? If so, what to do?
Have you checked the file permissions on the .cub file? Try explicitly granting access to the user account that you are running ProClarity or Excel under.|||Also make sure when you try and open local cube you got correct version of AS OLEDB provider installed.
You can get it from http://www.microsoft.com/downloads/details.aspx?familyid=50b97994-8453-4998-8226-fa42ec403d17&displaylang=en
Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Hi everyone,
Thanks a lot for your replies. I have found the cause of the problem. As stated before we use a stored procedure to execute a package. However on a 64 bit server command "dtexec" has two versions. One for 32 bit which is installes on the folder "Program Files (x86)" and a 64 bit version which is installed on folder "Program Files". Is T-SQL adresses dtexec from a stored procedure it will by default use the 64 bit version. This was the cause of the problem and not security or Analysis Services.
To solve this, please execute the "dtexec" by using the full path ("Program Files (x86)") and referring to the version you want to use.
For this reason, this post is not directly related to Analysis Services. Appologies for any inconvenience.
With kind regards,
Wan Chi
