Business Intelligence Blogs

View blogs by industry experts on topics such as SSAS, SSIS, SSRS, Power BI, Performance Tuning, Azure, Big Data and much more! You can also sign up to post your own business intelligence blog.

«September 2015»

Executing DBCC for SQL Server Analysis Services 2016

In the upcoming release of SQL Server Analysis Services 2016, one of the new features you’ll see is the ability to perform a database consistency check against your SSAS cubes and Tabular models. Just like in the database engine side of things, DBCC for SSAS checks for corruption across the entire database or individual objects within the database.

The DBCC command is shaped likes the XMLA Process command so there’s not a lot of complexity to it. Below here, you can see the basic syntax for the SSAS DBCC command. Its worthing noting that the syntax of the command will look the same whether you’re running it against an SSAS multidimensional database or Tabular model.


To run the DBCC command, just open a new MDX query window and use the code seen above. Enter in the IDs of your Database, cube, measure and/or partition.

When you’re running the DBCC command against a Tabular model, there are a couple things I’d like to point out.

In the element for the CubeID, you’ll need to specify the ID of the Model. And in the element for the MeasureGroupID, specify the ID for the table you want to check.

DBCC XMLA command for SSAS

If you want to check the whole database or model for consistency, simply remove the elements the lower elements. For example, if I wanted to check the whole model, I just would leave out the elements for MeasureGroupID and PartitionID.

To find the MeasureGroupID (Table ID) or PartitionID in a Tabular model, just navigate to the Properties for that object.

Find the SSAS Tabular MeasureGroup ID or Table ID

To find the Partition ID in a Tabular model, right click the table and select Partitions. Then highlight the partition you want to check and click the Settings icon.

Find the SSAS Tabular partition ID

If you run SQL Server Profiler against SSAS while executing the DBCC command, you can see the individual checking of the columns, tables, database and more.

SSAS Tabular Profiler trace DBCC

I also ran a trace against my SSAS 2016 OLAP instance to watch each segment of

Read more

SSRS: My Filter is not Working!!!

I rarely use filters in my SSRS reports.  However, this was a client requirement.  When we attempted to use the filter to our surprise it did not work.  The actual problem involved using a table that contained a column that was of a CHAR data type.  After a little digging we realized that the cause of the problem was the column data type. 

Assume you are using the following query as the source for your report, which can be run against the AdventureWorks sample database:

        WHEN Color IS NULL THEN ‘NA’
        ELSE Color
    END AS CHAR(10)) Color,
FROM Production.Product

Noticed that I forced the Color column to a CHAR data type to simulate the actual scenario.  Then after creating the report I opened the properties window of the data set and added a filter on the color column:


Denoting “Black” as my filter value.  When I ran the report to my surprise nothing was returned.


Why not?  I thought for a few minutes and I started to search the web, but I decided just for grins to pad my filter with a few spaces.  I actually padded it up to the number that was specified for the data type length.  In the case of this example it is 5 additional spaces.  I then reran the report and results were retuned:


Why?  The short answer is because CHAR is a fixed length data type and it appears as though SSRS returns the value with padded spaces.  There are a couple of ways to solve this problem.  You could use the TRIM function on the DataSet Properties window. 


Instead of simply specifying the column name as the Expression, in our case Color, you would specify an expression =TRIM(Fields!Color.Value).  Then rerun your report.  This is a simple solution.  In addition, you could include a CAST in your query that changes the data type to a VARCHAR.  Both of these can be done in your query and report design and does not require any schema changes.  You could also take a very intrusive approach and request that your DBA change the data type to varchar.  Regardless of the choice, either should solve the problem.

Talk to you soon,

Patrick LeBlanc, MVP, founder SQL Lunch

Rate this article:

PatrickLeBlanc PatrickLeBlanc

Other posts by PatrickLeBlanc

Please login or register to post comments.