Retaining Object IDs From Copied Objects
The most obvious reason to maintain multiple environments (Development, Test, Production) is so that you can make changes to objects while building/modifying without impacting Production. Once the changes are complete/tested, they can be migrated with MicroStrategy Object Manager into the target project. In order for this theme to work, MicroStrategy relies on the Object IDs to be synced for objects between projects. So what do you do if you just want to test something out or try something crazy? You could always try it in Dev, and if it doesn’t work, migrate it backwards from Test/Prod back to Dev to undo your changes. Today, I’ll show a different trick where you can work on copies of objects, but still retain their original GUIDs without the extra risk.
The trick is something non-intuitive, but is obvious when you think about how Web works. What you can do is make a copy of any object, which will now create a new Object ID. You can make your changes and test them out, and if you want to keep them, but retain the original Object ID, instead of reapplying the changes you can simple Save As on your new object and overwrite the original. Your changes are all applied, but the original Object ID is retained. When you think about the workflow when saving Reports in Web, it always does a Save As, as you get the confirmation that you’ll be overwriting the Report.
This trick can be useful in a few scenarios, specifically if you wanted to test some new changes or perhaps have a less experienced developer work on a copy of a complex/sensitive report without risk of messing it up. You could also take a Report that a user has modified in their My Reports and apply it to the Shared Reports version.
The importance of retaining the Object ID is so that Object Manager can still function for migrations between projects. Additionally, any existing subscriptions are tied to the Object IDs, as well as any dependents that use the object you’re copy/replacing.
I’ve tested this primarily with Reports/Documents, but it also works with all other types of objects with the exception of Prompts.
Hey Bryan, this is a trick we keep using while development all the time.
But it does not work on prompts. MicroStrategy does not let you save as a prompt.. The editor does not have any option of doing that..
I guess it does make sense to not allow save as, because different prompt types are used in different places, and if one would, if available, try to do a save as an object prompt on an element prompt, things would be messed up!
Thanks for the tip! You’re right, it looks like the Prompt interface is slightly different and doesn’t let you save an existing object over an older one. However, you can create a new prompt and the first time you save it, the trick does still work, though that’s definitely less useful.
Yes, you can create a new prompt and achieve the same.
It wont let you change the prompt type altogether though.. I guess it wont let you save an Element prompt on top of an object prompt.. (Besides I know thats kind of foolish!)
Thanks Bryan! A usefull tip, as always 🙂
Bryan,
I applied prompt on my report and when i run the report and checked its SQL its not making any join with Currency Code…. but when i use filter instead of prompt its works fine. What’s the problem behind it why prompt is not making join with Currency Code.
Hi Bryan,
Nice trick…
Thanks,
Prince
Hi Bryan/all,
Does this trick work for a logical table?
Thanks,
Dan
Doesn’t look like it since a LT doesn’t have a Save As option. If you’re trying to use this as a trick to point a LT to a different physical table, then I think you can do that in Architect.
Is there any way we can extract all the object properties such as version id, object ID, name, column, table name into excel sheet