Category Archives: MicroStrategy

MicroStrategy Object Tracking Tool


Deprecated: Function get_magic_quotes_gpc() is deprecated in /home1/microoat/public_html/blog/wp-includes/formatting.php on line 3964
MicroStrategy, SDK,

I have created MicroStrategy Object Tracking Tool (beta) for easy preparation of tracking sheet in a Excel. You can customize it by selecting date (creation, modification, from , to date, select number of object type. This toll is still beta. I made it as there are not way to achieve Version control in MicroStrategy. Looking for your suggestion to improve it and add more features. You can send me your comment by email or this blog. Utmost care is taken that this application doesn’t mess up with your metadata. I’ve used this application with production system in past.

This is a read only application. Using it will cause no changes to your Metadata.

Note:  This application is provided “as is” and I disclaim all warranties, whether express or implied, with respect to all provided items, including all warranties of merchantability, fitness for a particular purpose, accuracy, systems integration, title, satisfactory quality and non-infringement. I do not warrant that use of the provided items or any portion thereof will be uninterrupted or error-free, or that the provided items or any portion thereof will meet any need or requirement of licensee.

The depressing story of the renamed fact


Deprecated: Function get_magic_quotes_gpc() is deprecated in /home1/microoat/public_html/blog/wp-includes/formatting.php on line 3964
MicroStrategy
The fact SALES_AMOUNT has been enjoying a quiet life for the last five years until, one rainy day, the new QA guy called Eureka! and proudly informed everyone that according to the naming conventions the fact name should be SLS_AMT. Of course, he took the liberty of checking the source tables and discovered that they too should be updated to match the aforesaid conventions. Way to go, QA guy!

What do you do? You could swear the QA guy or, if you are more literary inclined you could write him a bitter limerick and post it on the Intranet. Seriously now, how do you go about accommodating this change? I’ll skip the whole ETL part and go directly to MicroStrategy, right after the source tables were updated.

What you can’t do is go to the Warehouse Catalog and update the source tables’ definition. The catalog would just throw a number of dependencies that need to be solved before performing the update. You can’t delete the fact either, as it is being used by several metrics which in turn are being used in reports, and so forth.

The thing to do is to make the fact independent of any table. There are some ways this can be achieved, and one of them is to clear the fact definition and map it manually to “1”. You can actually write anything in the definition field, as long as it is not “SALES_AMOUNT”.


Thus the fact is no longer related to any of its source tables. Now it’s the time to update the tables’ definition in the Warehouse Catalog. After that, just go back to the fact editor and map it automatically to “SLS_AMT” and perform a schema update.

A similar process can be applied to attributes. Rather than mapping an attribute element to “1”, you can try to temporarily map it to any other column in any other table. Most likely the relationships with other attributes will be lost because of this, but they can easily be restored when all work is finished.

Multiple Intelligent Server on single machine


Deprecated: Function get_magic_quotes_gpc() is deprecated in /home1/microoat/public_html/blog/wp-includes/formatting.php on line 3964
I-Server, MicroStrategy

A common question asked (and twisted) and newbie are trapped if answered incorrect. :-)

Answer is Yes in case of All UNIX/Linux (AIX, Solaris, UX, RH Linux, SUSE Linux) and NO for Windows.

One thing to be taken care of. Can’t run both servers on same port number. :-)

Automatic mapping


Deprecated: Function get_magic_quotes_gpc() is deprecated in /home1/microoat/public_html/blog/wp-includes/formatting.php on line 3964
MicroStrategy

Things aren’t always what they seem…

Automatic mapping is a great thing. It enables us to stop worrying about updating an attribute or a fact whenever we bring modifications to the Warehouse Catalog.

Well, my advice is to don’t rely too much on it. The following pictures show two instances of the “Customer” attribute and both of them appear to have CUSTOMER_ID automatically mapped.

However, one of them lacks the ORDER_FACT table, and that is because I mischievously removed it by clicking Modify and then unchecking it from the source tables list.
This ID’s mapping is still automatic, in that that it will use any new table that contains CUSTOMER_ID and it will remove from its definition any table that cease to contain this column. But as far as the table ORDER_FACT is concerned, it will not be used by the attribute until it is checked again in the source table list.

So, when debugging reports which don’t run because a fact appears not to be available at a certain attribute level, do yourself a favor and check if that particular attribute suffers from what I have described above.

Getting Started


Deprecated: Function get_magic_quotes_gpc() is deprecated in /home1/microoat/public_html/blog/wp-includes/formatting.php on line 3964
MicroStrategy

 

Many a newbie MicroStrategy learning fellow gets a little bit confused when confronted with concepts such as attributes, facts, metrics and so on.

The next sketch is a little something that I use to help them map the new notions to their existing SQL knowledge:

SELECT
a11.country_id,
a11.country_desc,
SUM(a12.sales_amt) sales
FROM
TABLE_COUNTRY a11,
TABLE_SALES a12
WHERE
a11.country_id = a12.country_id
AND
a11.country_id = “15”
GROUP BY
a11.country_id
a11.country_desc

Marked blue you can see the “Country” attribute and its two fields – country_id and country_desc.

Green stands for the “Sales” metric, which is no more than a SUM of the “sales_amt” fact, depicted here in bold italic green.

In psychedelic pink you have the metric alias, as specified in the “Column Name used in table SQL creation” field from the “Metric Column Alias Options” menu.

The tables used by the report are shown here in red.

Lastly, I reserved the wonderful orange for the filter. Note that this filter may exist in the report as a standalone filter or as a result from a prompted filter. Either way, the SQL should look the same.