Error during browsing the cube

Hi,

I have migrated the anaysis service 2000 cubes to 2005.

In the database i have two cubes say A and B and one virtual cube say C.While migrating the virtual cube C got migrated as a real cube with two linked measure groups for the cubes A and B. I have not processed the cube B.But i have processed the cube A.It succeded and i could browse it once .But when i tried browsing the virual cube C (which migrated as real cube with linked measure group) is not available for browsing .This is because i didnt process the cube B whose measure is also present in C.

But the problem is when i tried to browse cube A which i could browse earlier is giving me error when i try to browse it again.

The error which i found is somethinf like this:Error in the OLAP storage engine:The version of the linked measure group with the name of 'A',on the remote instance has changed.Repeat the operation the resolve the issue.

Please help me to solve this issue ASAP.

Thanks in advance

Regards

Latha

Hi Latha. I have received the same error in the same situation from the SQL Manager when writing my own MDX query. I try the query again (as suggested) and it works. You should try a simple MDX query from SQL Manager and see if the same scenario occurs.

Hope this helps.

PGoldy

|||

Hi,

Since it is a migration from AS 2000 to AS 2005 .

I dont want to make any changes in the query and my AS 2000 cube works fine.

Please tell me, is the error because of the unprocessed cube 'C'(virtual cube migrated with linked measures).

Is it enough if i process the cube C along with Cube A?

Regards

Latha

|||

Hi Latha. Yes, processing the cubes should take care of the error you received.

PGoldy

Error after migrating package from development to staging

I've migrated a package that has worked in our development environment. In both environments (dev & staging) I am in the BUILTIN/Administrators local group which is in the sysadmin server role.

In our staging environment, I execute DTEXEC command from the command line and get the following results.

D:\Reporting>"D:\Program Files\Microsoft SQL Server\90DTS\Binn\DTEXEC.EXE" /SQL "\MSDB\ProcessReportingDatabase" /SERVER USFKL16DB1CI01 /MAXCONCURRENT " -1 " /
CHECKPOINTING OFF /REPORTING V /SET "\Package.Variables[User::RunID].Value";65 /
SET "Package.Connections[RSAnalytics].InitialCatalog";"VR New Test 1 Dec28-FndPrj 1 Dec28"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.1399.06 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

Started: 1:46:43 PM
Could not load package "\MSDB\ProcessReportingDatabase" because of error 0xC0014062.
Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80004005 (Login timeout expired). The SQL statement that was issued has failed.
Source:
Started: 1:46:43 PM
Finished: 1:47:02 PM
Elapsed: 18.797 seconds

In addition to my login, all logins that access this package are in the sysadmin role; and I have gone back and included these logins in msdb's dts_operator role. Has anyone seen this before?

Thanks - Dave

I received the same error. In my case, I was using an environment variable to indirectly point to a configuration file that would update connection strings in my connection managers. It worked fine during development, but when moved to production, that's when the error occurred. After some trial and error, I found that if I removed the indirect configuration and allowed the connection managers to use the default connections I setup, it worked properly. That doesn't explain why it worked in development but not in staging. I have a hunch that the difference is in development the config file was locally on my drive (a C:\... path), but when moved to staging, it was changed to a UNC path on another machine. There is no security on the path or file on the other machine that would block the user (the share is wide open to everyone on the domain for testing purposes), so it might just be the fact that it's a UNC path. I'll have to test it out on Monday. Hope that helps.

Update: I ended up having enough time to try a few things. I tried a UNC path pointing back to my pc using the PC name (not just 127.0.0.1) and it worked ok that way. So it appears it's not necessarily that it's a UNC path. Whenever I attempt to access the remote path from Explorer I'm able to view the config file. I guess I'll start looking into the Component Service configuration on Monday. Although I think it would be easier to try to rethink of how to manage my configuration files so that I can keep them on the local machine.