Posts

Showing posts from July, 2012

Duplication of KPI's within PPS

Image
Has anyone ever come up with the of duplication of KPI related information after dragging and dropping two seperate KPI's within a scorecard......... well! I have. Now the issue is quite simple, I define two separate KPI's called KPI1 and KPI2. I define KPI1 in the following manner:

After this step I define KPI2 in the following manner:

Once I perform the following operations I basically define a scorecard dropping a dimension (eg: Brand) for this purpose and then drag KPI1 and then KPI2 (Note: KPI2 is the sibling of KPI1). The scorecard gets generated in the following fashion:
Now if you notice the scorecard the Actual and Target is repeated for KPI2 even though KPI2 has the names defined as Test1 and Test2 respectively and the default values for KPI2 is empty for all rows of the slicing dimension. This issue is due to the fact that PPS did not recognize KPI2 as a valid sibling of KPI1 (This is indeed an issue with PPS and needs to be changed as soon as possible in the futur…

SQL Server Best Practices

Recently was discussing with a colleague of mine as to the best practices in SQL. So this post is dedicated to that chat. The first thing we discussed about is the usage of NOLOCK's for tables in non highly transactional based databases with a wide user audience. Now the question of dirty reads does come to mind but at the end of the day the Read Uncommited transaction allows multiple end users to query the underlying table. NOLOCK is nothing more than a table hint that allows the query to be performed in a read uncommited fashion but is still a great practice to follow even while creating views. I have been using NOLOCK's for a large period of time (and sometimes implement it out of habit for my views i.e. SELECT C1,C2 FROM V1 (NOLOCK) as well which does not make any sense but is more of a force of habit except for my last post where I removed it on purpose) but I recently came across another table hint called READPAST but I am strictly avoiding this topic as this prevents…