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.

«November 2015»

DirectQuery in Power BI Desktop

In the latest Power BI Desktop a new Preview features was released that now allows you to connect using DirectQuery to either SQL Server or Azure SQL Databases.  DirectQuery is a really neat feature that allows you to point to the live version of the data source rather than importing the data into a data model in Power BI Desktop. 

Normally when you want to get an updated dataset in the Power BI Desktop you would have to manually click the refresh button (this can be automated in the Power BI Service), which would initiate a full reimport of your data.  This refresh could take a variable amount of time depending on how much data your have.  For instance, if you’re refreshing a very large table you may be waiting quite a while to see the newly added data. 

With DirectQuery data imports are not required because you’re always looking at a live version of the data.  Let me show you how it works!

Turning on the DirectQuery Preview

Now, because DirectQuery is still in Preview you must first activate the feature by navigating to File->Options and settings->Options->Preview Features then check DirectQuery for SQL Server and Azure SQL Database


Once you click OK you may be prompted to restart the Power BI Desktop to utilize the feature.

Using DirectQuery in Power BI Desktop

Next make a connection either to an On-Premises SQL Server or Azure SQL database.

Go to the Home ribbon and select Get Data then SQL Server.


Provide your Server and Database names then click OK. ***Do not use a SQL statement.  It is not currently supported with DirectQuery***


From the Navigator pane choose the table(s) you would like to use.  I’m just going to pick the DimProduct table for this example and then click Load.  You could select Edit and that would launch the Query Editor where you could manipulate the extract.  This would allow you to add any business rules needed to the data before visualizing it.


Next you will be prompted to select what you want to connect to the data. Again, Import means the data

Read more

The Big Data Blog Series

Over the last few years I’ve been speaking a lot on the subject of Big Data. I started by giving an intermediate session called “Show Me Whatcha’ Workin’ With”. This session was designed for people who had attended a one hour introductory session that showed you how to load data, to look at possible applications … Continue reading The Big Data Blog Series
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.