The error itself looks something like this (click on it to see full size pic):
It is a session specific error, so you as admin might not see it.
Now just search for the *.rtm file and delete it. Also delete two other files with same name but different extentions. You're done. As soon as you or the user opens the cube which was displaying this error message again, the models will be recreated automatically.
M
3 comments:
Hi M,
This error isn't necessarily linked to a cube; we're currently experiencing it wrt a relational package.
And for our greater joy, having done a stop service / purge all .rtm files / restart service, we immediately hit the same error again when reaccessing the same package, on a brand new .rtm file.
Any ideas on this one?
Thx, Michael
Hi Michael,
You are correct, *.rtm are generic models, not related to just cubes.
It seems a bit odd that you experience this with a fresh model. After the rtm file is created, does it contain any data or is the file size 0?
From experience I would suggest looking into folder permissions- make sure the user that is running Cognos service has full permisions within the Data folder.
Also, make sure antivirus software did not receive some crazy policy update. I know that maintainance teams are not always in sync with what Cognos software is doing, therefore it is beneficial to exclude the Data folder from being scaned with live scan of some sort.
Last, if this is occuring with all packages, your cryptography data might be corrupt. Stopping services, backing up cryptographic information, deleting all of it and restarting services will recreate it all.
I do apologise for slightly random suggestions, but it is hard to think this through without knowing more details about your setup. In any case, hope this at least guides you in the right direction!
It would be great to hear how you solved it!
M.
Hi M,
You made some great suggestions there! Unfortunately, I wasn't able to try them out - this concerned a server that was completely new to me.
But we did solve the problem... indirectly. A colleague had to republish the "offending" package anyway following a change. Since then, no more UT-DEF-0047.
Conclusion - republishing can be a workaround.
Rgds, Michael
Post a Comment