Category Archives: MicroStrategy

MicroStrategy 9.2 is available

MicroStrategy 9.2 is available

Key Features

* Mobile – Ipad/Iphone

* Import/Migrate objects from any BI tool

* Google Map in Dashboard

* Encrypted inputs in Command Manager

* Incremental load in IntelligentCube

I’m Studying and working on POC/Demo on each features….will upload one by one soon…..if any one doing the same, email me….lets share the knowledge

MicroStrategy best practices – part 2

1. In Dev/UAT, Cache should be disabled server level itself and should not be enabled at any other level.

2. If there is any upgrade of I-Server, Metadata must be updated accordingly.

3. For a fresh setup, Dev should be duplicated into UAT/PROD rather than creating fresh blank MDs in UAT/PROD. If not done, objects won’t be get migrated using OM as both metadata would be having different Schema GUIDs. Schema GUID can be found only using OM.(I have seen some violation of this rule)

4. MD Database backup should be performed on the production environment before changes are made.

5. When a new table is added to the development warehouse and the project’s Warehouse Catalog, a logical table is created. This table can be used as a source table for an existing attribute/fact or a new attribute/ fact. When this object is ready to be transferred to the production environment, the system administrator first need to confirm the existence of the table in the production warehouse. The table should not be added to the production project’s Warehouse Catalog. Doing so will create a new Object ID for a logical table of the same name. The system administrator should use MicroStrategy Administrator – Object Manager to copy the schema object. The logical table from the development project will be copied to the production project as a dependent. If an existing schema object is in the production project, select ‘Replace’ in the Conflict Resolution Dialog.

6. Only one session of MicroStrategy – Object Manager should be open at one time.

7. Object Manager requires the destination project to have the same or newer metadata version than the source project

8. Use Multi-process mode for ODBC connectivity to the warehouse/metadata/statistics for all database/ODBC driver configurations.

9. During initial stages of project development, Attributes should be created with Automatic mapping. May be after 2-3 months, it should be changed to manual. It can be controlled using Options of WH Catalog.

10. If you use local MSTR installation to access client metadata, both must be on same version.

11. Have only one child at the lowest level else report that contains Children will ignore filters of parent(s).

12. There MUST not be any M-to-M relationship between any two attributes. Such a relationship should be broken down using Fact less fact table or a relationship table. PDF describe it in detail.

13. Metadata on OS/390 and Sybase should be avoided as MD Doctor is not certified.

14. Always take a 100% backup of metadata before running ScanMD or MD Doctor. No users should be connected to the project undergoing a fix.

15. Retain a copy of the MDDoctor.log generated by MD Doctor for any instance where the utility was run in “fix mode”.

16. Attribute lookups and relationships should generally not use fact tables.

17. Partition mapping tables for warehouse partitioning may never be used as attribute lookup or relationship tables.

18. All attributes name given in a Freeform SQL reports should be unique.

19. For a large schema, schema reading should be disabled in WH Catalog (to save time).

20. A new dependent able should not be added using WH catalog in PROD, as OM take care of it “now”. In fact doing this would add GUID inconsistency for lifetime of meatadata.

21. Use MicroStrategy (Datadirect) ODBC drivers even if you have product’s own drivers. (There are rare of rare instances (Some SQL issues) when MicroStrategy would ask you to use DBMS drivers)

22. Have a DSN naming convention.

23. Overlapped objects, Lines and rectangles, Relative paths for images, Line Breaks within text fields and Word-wrapping in grids would not be shown in Excel export of a RS document.

24. Schema objects should be created in a 2-tier connection when creating in bulk.

25. Perform a Schema update immediately before object migration.

26. Rename Administrator account to avoid hacking or better delete the account with login name Administrator.

27. Create at least three administrator level accounts to manage administrator account in case the password is lost.

28. When deleting a user, delete the profile too.

29. Avoid using Custom Groups as much as possible.

30. Not to overdo performance at the cost of correctness of report.

31. Login/password used in DNS used in MicroStrategy I-Server configuration should be a top secret. Person with bad intent can mess up metadata w/o any chance of recovery unless having backups.

32. No changes must be made into Prod server directly. There should be only object transfers into PROD environment.

33. Only in case of migration having gone bad and system can not be reverted back to the old system, change to PROD environment to make it at par with DEV/QA/UAT should be made.

34. Very limited person should have access to License Manager.

35. You can play around with Named User license ;-).

36. MicroStrategy doesn’t come to know about license violations if the I-Server restricted to access internet. (and if you are NOT doing it, don’t think that MicroStrategy, Inc. won’t come knocking your door to pay up, if there is prolonged license violations.)

how to change the group by in the SQL

In some cases, ordering/changing the group by will make alot difference in terms of performance; DB like DB2, Redbrick, Sybase are good examples for this.

we had a requirement in DB2, where Db2 asked us to change the group by order to make the SQL works better.

Solution:

  • In the project configuration (project level) –> Report Definition –> SQL Generation –> attribute weights –> <add the attributes in order the way you like to force it in the select clause so that group by will change automatically>
  • By combining “Attribute Weights” and the “Max Columns in Index” settings, a user can designate any attribute to be included in the index.

MicroStrategy Prompting Issue

(After a long gap, a short post)

When running a  (Saved with default answers) Ad hoc report that has been re-prompted, the metrics on the resulting report will be displayed in alphabetical order rather than in the order they were selected. 

A possible workaround to this issue is to click and highlight one of the selected metrics , then re-execute the report.

As usual, we are touch base with MicroStrategy (its known issue in 9x, please contact MicroStrategy Tech Support 😛 )

IBM India’s Cognostrategy

This is some what’s insider information, but may be something that MicroStrategy re-sellers should be knowing or should find out in due course of time. This is specific to India. MicroStrategy can not compete any BI tool to a the most price sensitive market of world, India. Even free is not something that people would easily go for, due to extremely low awareness about MicroStrategy BI in India. Sales is India doesn’t really affect much to MicroStrategy in the sense, it is not directly involved in selling the product here but only and only through authorized resellers, that to with a division of region of sales among them. But so far from last 7 years, sales of MicroStrategy is dismal. An recent consolidation in BI landscape has made things very tough for re-sellers, though I fail to understand why any damn company would go for Cognos/BO, even though they can’t beat MicroStrategy in any aspect, but price.

But how much the high price is hurting to adaption of MicroStrategy, I came to know while speaking with a friend only last week. First, MicroStrategy has around 30 clients in India, one of them having HQ right across my apartment. 😎 . Low penetration is mainly because of selective marketing by resellers but MicroStrategy, Inc has tried their hands. Now IBM is exploiting the high license cost of MicroStrategy in sales like anything. These guys (sales representative of Cognos) admit in front of client that MicroStrategy is highly scalable and better analytic capable than Cognos, but why to pay such a high price when you can have Cognos for BI and SAS for analytic, and is working great for them (IBM Cognos). Seriously a high price paid by MicroStrategy.

MicroStrategy really can’t do much about this evil marketing. Though I must say having two different tools would increase the cost of “experienced professionals” to handle them. Something that MicroStrategy reseller can counter argue. But after having lost Netizza, SPSS, Unica, etc. it is going to a tough market for them. also new kids on block like TableU are also giving them tough challenge in department BI sales, not here in India though.

All I can advice MicroStrategy is that you are the best BI. You can be the best BI, winning all accolades for the blah blah BI report, Nigel etc, done by independent authorities, but your scalability, features would be still used by least %age in industry due to very high cost of license and high cost of processionals (and tough search of them too). Just bring down your prices and see yourself sweeping the market.

Critical part of this blog is based on discussion with person who taught me MicroStrategy.