Getting vehicle NOC (No objection certificate)

During my employment I've worked in 3 different states and need less to say that I have always relied on my bike to commut to office. We all know the fear of being caught by traffic constable/inspector in the other state. But here is way, getting an No Objection Certificate (NOC) for your current registering RTO.

To safely (w/o being harrssed by cops) drive/ride vehicle registered in a different state, there are two method.

1. Carry fuel bills of a petrol pump located in your registering state. An ideal difference between two bills is 2 months. When traffic cops aks your bribe for outside vehicle first things to say "I can legally travel my bike fora year in another state without any NOC". I've said that got away, once I was caught. But even if he insits than show him the bills. He won't tough you.
(BTW, I was stopped 3 times by traffic cops and everytime got away but one thing was : all these cops noted down my registration number.) Those who don't know they actually report an outside vehicle to the head office so as to catch him after one year no-NOC grace period is over.

2. This is legal but tedious way, specially when you have a vehicle on loan. The cost of NOC is zero. yes. There is no fees and Police report is required if your changing the "state". After NOC you can apply for refund of tax (Form DT). In new state you need to file form No 33 for change of address to be recorded in the Certificate of Registration (RC). Once again, process is a bit tedious if there a loan. Agent cost is Rs 800 for NOC. One should forget refund of tax, as officers will make your run from piller to post (in case of intet-state transfer).

I would say, one should go for #1, a very simple and extremely cost effective way of living in different state. #2 for a car costs around 25 thousand (and for bike like 10K) and RTO can make your n number of rounds to office.

Happy driving/riding.

Multiple Intelligent Server on single machine

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

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.

In home town

Left FIC and now working at a new company at Mumbai. Very busy with shifting and setting up the life. No time for blogging or even checking important emails or replies. I shall be back on scene by Month end.
P.S. Wish you all a happy new year. (Couldn't personally reply to mails received)

Getting Started

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.

Compound Metrics and Data Type

All right, so this doesn’t happen too often, but when it does happen… it hurts.

Let’s say you are using a compound metric, something like (([Metric 1] / [Metric 2]) * 100) and the VLDB settings for the report are such that the SQL Engine uses intermediary tables.

What this means is that somewhere in the SQL there will be a “CREATE TABLE…” syntax and that your compound metric’s data type will be declared in it. Now, the million dollar question is - what will be the data type of your compound metric? Surely the SQL Engine will use the settings entered in the Values Formatting Properties window. Well, not really… Those settings are only used by the Analytical Engine for formatting the reports.

In fact, the data type of your compound metric will be the data type of the first metric in the formula – in this case, [Metric 1]. This is also the case when you are using a formula like ApplyAgg("sum(case when #1 = 1 THEN 1.0 ELSE #0 END)", [Fact 1], [Fact 2]). The data type will be that of [Fact 1], because it is the first one that is being referred. This is actually the best way of writing such a formula, as it ensures that the data type will be that of the result fact instead that of the condition fact.

Why is this so important? Think of what happens if [Metric 2] has a greater number of decimals than [Metric 1]. Most likely you will get one of those pesky red colored errors and the report will stop running.

Fortunately there is a simple way of avoiding this. Just set the data type of your compound metric to Float, with a hefty bit length of 48.

In the Metric Editor go to Tools -> Advanced Settings -> Metric Column Options: