To demonstrate this I’ve knocked up a few rows with variations in case of the same text, a null value and an empty string.

Creating a dimension based on this table in SSAS gives the following error when we try to process it – “Errors in the OLAP storage engine: A duplicate attribute key has been found when processing: Table: ‘dbo_FreeText’, Column: ‘Comment’, Value: ”. The attribute is ‘Comment’”.

This is due to the NullProcessing property on the dimension attribute, for which the default setting is Automatic. This specifies that the Null value is converted to zero (for numeric data items) or in this case a blank string (for string data items). This means that we’ve now got a null value which is converted to an empty string and an empty string, resulting in duplicate key values. If we set NullProcessing to Preserve this will fix this, giving us two distinct key values. If your database or this particular field is case sensitive you’ll then likely run into a second issue with a very similar error message – “Errors in the OLAP storage engine: A duplicate attribute key has been found when processing: Table: ‘dbo_FreeText’, Column: ‘Comment’, Value: ‘Some comment’. The attribute is ‘Comment’”. This comes down to a difference in case sensitivity between the underlying database and Analysis Services, which by default is case insensitive. In SSAS this is set at the attribute level. If you select the Comment attribute and expand they KeyColumns group you’ll find the collation property, under which you’ll find a case sensitive check box.

Once you’ve checked this the dimension should now process successfully. When we browse the comment attribute you’ll notice two “blank” values (null and empty) and multiple values for “some comment”. This example assumes that these are different discrete values. If this isn’t the case this should be handled in ETL i.e. converting null values to empty strings and standardising on case.

The following example (based on AdventureWorks) uses IN to return all the departments which are in the research and development, or quality assurance groups. Below is the full list of departments:

Now to get only the departments that are in the groups research and development or quality assurance. We need to use the IN operator in the WHERE clause to restrict the rows returned:

This gives us the following result:

We can also include NOT with the IN operator, which logically returns false when the value matches an item in the list and true otherwise. So we could get all departments that aren’t in the above groups:

We can also use sub-queries with the IN operator. For example we might want to get a list of employee id’s that have been assigned to a department within the Quality Assurance group:

After looking into this for a while I came across a solution, although it’s not one I feel completely comfortable with.

1. Go to Windows > Control Panel > Region and Language

2. Update the Format to “English (United States)”

3. Click Apply

4. Update the Format back to your original language, in my case “English (Australia)”

5. Click Apply

6. Click OK

In this case I was developing a monthly report which returned summarised information by account code for input into a finance system and included several detail sections for auditing and reconciliation. The summary table required a sequence number, which reflected the row number of the table. I had no joy scoping the row number function to the table or group, so started thinking about alternative solutions. The report contained multiple sections using the same source query, so returning multiple queries was inefficient and created duplicate code. Given the tablix is grouped by account code, it’s effectively returning a distinct list of account codes. Therefore, the row/sequence number is actually the row number of the account code in a distinct list of the account codes. Once you start looking to utilise this, it’s actually fairly simple to get the desired row numbers.

For this example I created a simple table of sample data containing two columns – Account Code and Amount.

I then created a simple tablix grouped by account code – displaying the account code, amount, and a distinct count of the account code. Looking at the output below it’s pretty easy to recognise that the row number is a cumulative sum of the distinct count of account codes.

Conveniently there’s a function in SSRS to do just that! RunningValue - http://msdn.microsoft.com/en-us/library/ms159136.aspx. Running value accepts three parameters…
expression - the expression or field to aggregate,  in this case the account code field.
function - the aggregate function to apply, in this case count distinct.
scope - the name of the dataset, data region, etc… in this case the tablix.
Having not renamed the tablix, I replaced the distinct count field with the following expression…

…and there we have it, row numbers in a tablix group.

Conveniently it’s easy (enough) to set the colours using MDX in the cube calculation script. SSAS defines colour values using a somewhat strange system, there’s a great post from Boyan Penev explaining this – Colour Codes in SSAS.

To set the colour of the Amount measure in the Adventure Works cube to a lovely shade of pink, you’d add the following line to the cube calculation script…

With the resulting err… lovely pink measure when browsed from Management Studio.

So I had a think and put together some T-SQL, with some success (it didn’t have a syntax error or run forever). After a few changes I had broken the string up into a table of words, with a bit to indicate whether or not each record is a valid word. In this case, I just defined a word as a string of characters containing only a-z or A-Z, followed by any other character (or no character). This could easily be adjusted to include other characters though, for example ‘ to allow we’re, haven’t, etc.

Essentially the logic behind the CTE is…

1. You have two integers a and b – one indicating the start of the current word (a), the other the possible length of the word (b).
2. If the character at a isn’t an alphabetic character, then this isn’t the start of a word. So we need to move a to the next character.
3. If the character at a + b (one character after the end of the possible current word) isn’t an alphabetic character then we’ve found a word. So we should mark the string starting at a of length b as a word. In this case we set a = a + b + 1, and reset b = 1. If a + b is an alphabetic character, then we haven’t reached the end of the word yet and we need to increment b by 1.

Below is the T-SQL I used, applied over this post.

Initially I had little joy trying to replicate the issues with Adventure Works, but found the source of the problem after chatting to Bhavik Merchant about it. The problem arose due to two main reasons…

1. Effective and expiry dates were being managed externally of the Dimension Merge SCD component.
2. The default for the last records expiry date in the Dimension Merge SCD is the SQL Server datetime maximum value, while the warehouse was using 2199-12-31.

So, in the initial load the records where being inserted with an expiry date of 2199-12-31 which from the Dimension Merge SCD components point of view means the records aren’t current until the end of time. For the second load the Dimension Merge SCD would assign an expiry date of 9999-12-31 to the same source records, making them more recent than those inserted in the first load. So the second load would result in all the records being output again with the different active to date. Since the effective and expiry dates were then managed externally this resulted in two identical records being inserted into the destination table.

The “fix” was simple. Either change the default for the last records expiry date in the data warehouse to 9999-12-31, or set the last records expiry date in the Dimension Merge SCD to the same value being used in the data warehouse. The screenshot below shows where to change this value in the component.

To resolve this you can simply select your language from the language drop down in the cube browse window.

Having had very little experience in .NET programming I searched around a bit and found a few less the elegant solutions, but was surprised just how simple it was to do in the end. In fact there’s a class to do it… OleDbEnumerator

There’s a couple of methods of interest in the class – GetElements() which returns a data table containing information about the installed OLE DB providers, and GetRootEnumerator() which returns a data reader with information about the installed OLE DB providers.

In a windows forms application, populating a data grid view is as simple as one line:

The resulting data grid view is shown below.