Unfortunately I discovered a problem in PPS Planning today which caused me a few headaches... thought I would pass it on to you!! The issue occurs when editing/creating a dimension member set... a save will fail if you do an outdent and a delete member immediately afterwards. Let me demonstrate. Let's presume you have a structure something like this: --- Expenses But you want to remove the Salaries level and end up with a structure that looks like this: --- Expenses If you do this: You will get an error when you save similar to the following: In order for it to work correctly, you MUST (in this order): I have logged this problem on Microsoft Connect. Please feel free to vote! https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=375153&SiteID=181
--- --- Salaries & Related
--- --- --- Salaries
--- --- --- --- Base Salary
--- --- --- --- Bonuses
--- --- --- --- Allowances
--- --- --- Tax Expense
--- --- Salaries & Related
--- --- --- Base Salary
--- --- --- Bonuses
--- --- --- Allowances
--- --- Tax Expense
Tuesday, 14 October 2008
PerformancePoint Planning: Error When Deleting Members of a Member Set
Posted by
Kristen Hodges
at
12:14 pm
0
comments
Labels: Bug, PerformancePoint, Planning
Thursday, 18 September 2008
SharePoint Magazine - Part 1 Out Now!
I've commenced a 6-part series on building PerformancePoint dashboards in SharePoint which you can read at SharePoint Magazine.
I'll be releasing a new part each week for the next 6 weeks covering the various aspects of building dashboards - including why bother at all!
Have a read if you're interested. Feedback so far has been excellent.
Posted by
Kristen Hodges
at
10:07 am
0
comments
Labels: PerformancePoint, Sharepoint 2007 (MOSS)
Monday, 25 August 2008
Interesting Read
Great article comparing the PIVOT (SQL 2005+) function with doing it the old-fashioned way! Take a read...
http://www.sqlservercentral.com/articles/T-SQL/63681/
Posted by
Kristen Hodges
at
11:57 am
2
comments
Labels: SQL
Thursday, 3 July 2008
SQL: Concatenating Rows into a Scalar Value
This is an issue which pops up from time to time, often when passing values back to .Net applications.
The Problem
Taking values in rows and creating a single string value containing a delimited list of all those values.
The Old Solution
The method I have used in the past is to use the FOR XML clause and build a string that way. It works.
DECLARE @DepartmentName VARCHAR(1000) |
The Sexier Solution
This idea comes courtesy of Ken Simmons at SQL Tips... so simple and I'm kind of annoyed that I've never tried it myself!
DECLARE @DepartmentName VARCHAR(1000) |
What Were the Actual Results from Testing?
Sadly, the sexier solution under-performs in comparison to the FOR XML solution.
| Method | Milliseconds | BytesReceived | Rows Returned |
| FOR XML | 78 | 9891 | 3 |
| COALESCE | 265 | 10505 | 60921 |
Obviously this lag is due to the number of rows which are returned to the client. Based on the stats, the FOR XML does all it's aggregation and concatenation server-side whereas the COALESCE method does it client-side.
So I guess that means the old way is still the best. Or is it? I wonder in what other circumstances COALESCE could be used? Ok so it under-performed in this instance but I suspect there are other uses which could be of great value. Got any ideas?
Posted by
Kristen Hodges
at
4:36 pm
0
comments
Labels: SQL
Tuesday, 20 May 2008
Reporting Services: Passing MultiValue Parameters
I recently came across an article by Wayne Sheffield on SQL Server Central which contained a very neat idea for passing multi-value parameters from SSRS to a SQL stored proc by using XML.
Because SQL stored procs can't handle arrays, it can't handle parameters with multiple values. There are a few ugly ways around this of course by using delimiters and manipulating strings but that just isn't pretty at all. Wayne's idea is to use XML string parameters.
So SSRS would send a string in the following format:
<root>
<node>
<element>element data</element>
</node>
</root>
It would look something like this:
<customers>
<customer>
<customerid>1234</customerid>
</customer>
</customers>
Wayne has written a bit of code which you can add to your report or create a DLL for which can then be referenced by your report.
Function ReturnXML(ByVal MultiValueList As Object, ByVal Root As String, ByVal Node As String
**************************************************************************
Returns an XML string by using the specified values.
Parameters:MultiValueList - a multi value list from SSRS
Root, Node, Element - String to use in building the XML string
**************************************************************************
Dim ReturnString = ""
Dim sParamItem As Object
ReturnString = "<" & Root & ">"
For Each sParamItem In MultiValueList
ReturnString &= "<" & Node & "><" & Element & ">" & Replace(Replace(sParamItem,"&","&"),"<", "<") & "" & Element & ">" & Node & ">"
Next
ReturnString &= "" & Root & ">"
Return (ReturnString)
End Function
This code would be referenced in your Reporting Services parameter like:
ReturnXML(Parameters!MultiValue.Value, "Customers", "Customer", "CustomerId")
To then use your XML parameter within the stored proc:
Select CustomerId, CustomerName, ActiveFlag
From tCustomer a
INNER JOIN @ipCustomerList.nodes('/Customers/Customer') AS x(item) ON a.CustomerId = x.item.value('CustomerId[1]', 'integer')
Pretty handy no?
Posted by
Kristen Hodges
at
10:49 am
3
comments
Labels: Reporting Services (SSRS), SQL
Thursday, 8 May 2008
Datamining Part II - Terminology
Datamining, like all other IT subjects has it's own lingo. This quick blog post will explain them.
Datamining
Datamining attempts to deduce knowledge by examining existing data
Case
A case is a unit of measure.
It equates to a single appearance of an entity. In relational terms that would mean one row in a table. A case includes all the information relating to an entity.
Variable
The attributes of a case.
Model
A model stores information about variables, the algorithms used and their parameters and extracted knowledge. A model can be descriptive or predictive - it's behaviour is driven by the algorithm which was used to derive it.
Structure
A structure stores models.
Algorithm
My definition here is from the perspective of datamining rather than a general definition. An algorithm is a method of mining data. Some methods are predictive (forecasting) and some are relative (showing relationships). 7 algorithms are included with SQL Server 2005.
Neural Network
An algorithm designed to predict in a non-linear fashion, like a human neuron. Often used to predict outcomes based on previous behaviour.
Decision Tree
An algorithm which provides tree-like output showing paths or rules to reach an end point or value.
Naive Bayes
An algorithm often used for classifying text documents, it shows probability based on independant data.
Clustering
An algorithm which groups cases based on similar characteristics. Often used to identify anomalies or outliers.
Association
An algorithm describes how often events have occured together. Defines an 'itemset' from a single transaction. Often used to detect cross-selling opportunities.
Sequence
An algorithm which is every similar to the association algorithm except that it also includes time.
Time Series
An algorithm used to forecast future values of a time series based on past values. Also known as Auto Regression Trees (ART).
Cluster
A cluster is a grouping of related data.
Discrete
This is more a statistical term than a strictly datamining term however it is used frequently - hence it's inclusion here. Discrete refers to values which are not sequential and have a finite set of values eg true/false
Continuous
Continuous data can have any value in an interval of real numbers. That is, the value does not have to be an integer. Continuous is the opposite of discrete.
Outlier
Data that falls well outside the statistical norms of other data. An outlier is data that should be closely examined.
Antecedent
When an association between two variables is defined, the first item (or left-hand side) is called the antecedent. For example, in the relationship "When a prospector buys a pick, he buys a shovel 14% of the time," "buys a pick" is the antecedent.
Leaf
A node at it's lowest level - it has no more splits.
Mean
The arithmetic average of a dataset
Median
The arithmetic middle value of a dataset
Standard Deviation
Measures the spread of the values in the data set around the median.
Skew
Measures the symmetry of the data set ie is it skewed in a particular direction on either side of the median
Kurtosis
Measures whether the data set has lots of peaks or is flat in relation to a normal distribution
Posted by
Kristen Hodges
at
10:42 am
0
comments
Labels: Data-Mining, SQL
Monday, 5 May 2008
SQL Server Releases
Microsoft have announced that they are changing their approach to releases for SQL Server. This is interesting because SQL Server releases can be a touchy subject for businesses, particularly those with big server farms. Inevitably the development team wants the Service Pack to be installed ASAP whereas the server team is keen to protect their stable server and pretend service packs don't exist. This means a lot of pushing and shoving.
This new approach should help to alleviate the pressure a little but I'm not altogether convinced.
· Smaller Service Packs which will be easier to deploy
I suspect smaller service packs will make server teams less inclined to come to the party because less inclusions on a per service pack basis inherently implies more service packs.
· Higher quality of Service Pack releases due to reduced change introduced
It's all very well to say that the quality is better but that's a very airy fairy 'benefit' which I can't imagine will go down very effectively with server teams as an argument for implementation. It's just not very quantitative which means server teams are likely to ignore it.
· Predictable Service Pack scheduling to allow for better customer test scheduling and deployment planning.
On this point, I demure. This can have a huge impact on getting releases implemented. Presuming of course that you can get your server team to operate on a scheduled release process themselves. It's all very well for the vendor to do it but if the server team doesn't ALSO do it, there's no gain. That said, I believe that such a process SHOULD be followed. I just don't see it as terribly likely. I fervently hope to be disproven.
It's really easy to be cynical about this approach and say 'my organisation will never do this'. Which is the trap I've fallen into here I realise, but the fact of the matter is, good on Microsoft for considering these issues and attempting to find ways to improve them. The approach is right and a positive move. Now the onus is on us to follow in their footsteps. This should be a wakeup call to server and development teams to find more common ground, to develop processes which satisfy everyone's needs and to communicate with each other better.
For more details:
http://blogs.msdn.com/sqlreleaseservices/archive/2008/04/27/a-changed-approach-to-service-packs.aspx
Posted by
Kristen Hodges
at
9:04 am
0
comments
Labels: Server Administration, SQL

