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

Limiting Table Access for Reporting Part 1

  • 28 July 2010
  • Author: briankmcdonald
  • Number of views: 2995

End users may have a need to do some form of reporting of data from source systems. Opening up the database tables to end users normally isn’t the best practice, but different situations often require different implementations right? In this blog series, I am going to show you one method of limiting access to the tables containing your data, while also providing the needed data for your’ end users.


For part 1 of this two part series, I am going to show you how you can create a schema that will be used to add your objects to (in my case Views). Next I’ll show you how you can add a view to the schema. Before getting started into this series, let’s make sure we’re all set up to follow along. I will be using the AdventureWorks database. If you already have it, great! If not, you can find it on Next, you will need to be able to alter objects in the AdventureWorks database. If it is your local test box (which most of the time it will be), then you should be all set! J


Let’s fire up SQL Server Management Studio (SSMS) and open a new query. In this first step, we are going to create a schema that will be used to assign our views to. This will make it easier to manager what objects your “reporting” users will be accessing.


Script 1: Create Schema

USE AdventureWorks





Next, let’s create a sample view that can be used to limit columns that the report user can access. Be sure to add it to the Reporting schema that we just created. If you are new to views, basically a view is a database object which allows you to use it as you would a table. They are very useful when you need to join multiple tables together, filter results or limit the ability to see columns in base tables. Script 2 below retrieves a limited amount of columns from the Employee and Contact tables.


Script 2: Create a View

CREATE VIEW Reporting.vw_Employee




      , [C].[FirstName] + ' ' + [C].[LastName] AS EmployeeName

      , [E1].[Title]

      , [E1].[HireDate]


      [AdventureWorks].[HumanResources].[Employee] E1

      JOIN [AdventureWorks].[Person].[Contact] C ON E1.ContactID = C.ContactID



Now let’s make sure that we are getting results as shown in figure 1 below.


Figure 1: Select From Your New View

Select from view


I think we have a good base on creating schemas and adding views to them. In my next blog, I will show you how to create a new SQL Server login and grant access only to the views under the Reporting schema.


Until next time, “keep your ear to the grindstone” – Good Will Hunting




Brian K. McDonald, MCDBA, MCSD
Business Intelligence Consultant – Pragmatic Works Consulting

Email: | Blog: BI Developer Network

Convert with DTS xChange  | Develop with BI xPress  | Process with TaskFactory | Document with BI Documenter

Categories: Blogs
Rate this article:
No rating


Other posts by briankmcdonald

Please login or register to post comments.