Join and Post only MicroStrategy Jobs related news, openings in this group
microstrategyjobs@googlegroups.com
Monthly Archives: March 2009
Search by ID v2
So, what’s new?
You can now export direct and recurring dependents of an object. That’s all.
Now for some background…
Direct dependents are the dependents found in MicroStrategy by right clicking on an object and selecting “Search for Dependents…”. The main difference is that Search By ID v2 exports them to an Excel file, whereas Desktop only allows the export to a non user friendly txt file.
Recurring dependents are the objects that use the source object directly or indirectly. If a metric is being used by a prompt and that prompt is being used by a report, then the prompt is a direct dependent and the report is an indirect dependent of the metric. A similar kind of search is offered by the Object Manager, if only as an indirect consequence of its use. Search by ID v2 should be easier to use for this particular feature.
Please be aware that finding and exporting recurring dependents can be a lengthy process.
Complex graph in Dashboard creation in WEB
Complex graph like ‘combination: Dual Axis – Bar – line’ graph cannot be created in Dashboard in WEB.
To achieve the same, create a report in desktop and make as above mentioned graph and save.
In WEB, while creating dashboard, add this data set in dashboard by ‘right click’ data set and add with formatting option. Now the graph which cannot be done in web, can be done in this way.
Scan MD and MD Doctor
While working on metadata, there are chances that MD may get corrupt. Only reason for corruption of MD is MicroStrategy programmers NOT you (No way), unless you have manually fiddled with the metadata. One small change can messed the metadata forever, some time impossible to recover.
There are two types of discrepancies in MicroStrategy
- Logical
- Physical
ScanMD is used to recover from Logical discrepancies, where as MD Doctor is used for Physical discrepancies. Why these discrepancies creep????? Like any software application, there are bugs in MicroStrategy, dandling code (a situation never programmed), etc. such a thing is the main reason behind discrepancies.
Logical discrepancies: Using desktop you can create/delete several objects. Sometime deletion of the objects doesn’t get reflected in metadata and they get deleted in metadata but still available in front-end. Now such a mis-match in case of schema objects is simply killing, because it won’t let you update schema at all. Imagine not having ability to update schema. Using ScanMD is not an easy task. ScanMD shows 95% for false errors as discrepancies. Engine team of MicroStrategy, Inc. needs to update the tool. For one error, you may have to go through 100+ errors. You can verify the error easily by having project opened side by side. NEVER EVER FIX A FALSE ERROR.
Physical discrepancies: There are not just 10 DSS tables that make metadata, there are several more database objects that are created for metadata; e.g., triggers, views. If any of these objects are messed up, you have a physical discrepancy in your project. I’ve never worked on MD Doctor and look forward some information from you.
This blog is not exhaustive and 100% as I certainly do not believe the bugs in MicroStrategy are only source of discrepancies in metadata.
Sluggish Prompts
Last month Jeremy wrote an excellent article on how filters can return unexpected results. My colleague Oznur found a somewhat similar issue and he was kind enough to allow me to share it with you.
So, there was this tiny little report that used an element prompt, and that prompt contained a list of default answers. Nothing fancy so far. However, it has come to my colleague’s attention that this report had turned rogue… How else could we explain that it started returning result sets for attributes that weren’t even chosen by the user when answering the prompt?
Well, there is a simple explanation, though it did required a little bit of outside of the box thinking. MicroStrategy stores the prompt default answers (ID and DESC) exactly as they were the day the prompt was created or modified. But what if something untoward happens to the lookup table, something like modifying the lookup value for a certain ID?
What happens is that while you distinctly remember choosing “Books” you end up seeing the sales for “Beverages”, and that is because the SQL Engine will write the WHERE clause with its mind on the ID not on DESC field. Since you selected “Books” and this lookup value corresponded to “1001”, then the SQL will filter on “1001”. Then, in the last step it will perform a join with the lookup table and get the description of “1001”, which now is “Beverages”.