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

Why Query When You Can LINQ

  • 27 April 2010
  • Author: Ben Evans
  • Number of views: 1722

Why Query When You Can LINQ



LINQ is a abbreviation for Language Integrated Query, Which is just a fancy way of saying in that while in .net code you can write out your queries as if it were as simple as any other statement in you native programming language. For instance back it that distant past of 2006 a c# programmer would create a data table receiving object or some other in memory container. Then if up to standards create a data read and write object for the particular database, which would eventually have a query would be called with it filling the data table. But what if in memory objects, relational databases, and XML files could all be treated the same as OBJECTS! Objects such a magical word to us programmers, it could bring a tear. But it doesn’t stop there, there is in fact some performance gains to think over.

LINQ Performance

Of course the numbers vary based on circumstance and almost any bit of code can show slow performance if written incorrectly. With this in mind Uncompiled LINQ performance is will not wow anyone. It is in fact about 20% slower than traditional queries. But once compiled LINQ can show performance increases up to x6.0. Here is a great LINQ comparison with

Using LINQ

LINQ can integrate with a database in several ways. At heart LINQ is O/RM which means it would best work directly with the database, making each table an object. Each object can then be joined as needed and CRUD operations performed. Okay, I know you DBA’s out there are not to happy with that prospect! But LINQ also supports views and stored procedures. Here is a few examples.

public class Customer
            public string ProductID;

            public string ProductName;

            public string Description;

            public string Quantity;


Vola our object is created know lets use it.

DataContext db = new DataContext();

var q = from p in db.Products
            where p.ProductName == "DTS xChange"
            select p;


Further Reading and Sources

Here are a few articles that have helped me and may interest you.

Intro to LINQ


Good Bye SP's

LINQ vs.

Categories: Blogs
Rate this article:
No rating

Please login or register to post comments.