Forum Discussion
direct query vs. import
- Anonymous9 years ago
ammartino44This page will help. But essentially here are the basics
Import - extracts the data from your database and pulls it into the Power BI Desktop
Direct Query - leaves the data in the database and sends queries to pull the information needed.
Other things to note:
Import -
Gives you the full suite of transformation and data manipulation in the Desktop
There is a 1 GB limit to the Desktop if you plan on publishing to the PBI Service
Consumes and pushes the data into the Power BI Azure backend (Azure DB/Blob Storage) (In the Service)
Can only be refreshed up to 8x a day by setting up a scheduled refresh (In the Service)
Direct Query -
Limits your ability to manipulate data in the Desktop (removes the Data section)
Leaves the data in the SQL database
Is "live", no need to schedule a refresh (In the Service)
Both methods require a gateway to be installed, unless you are talking about Azure SQL.
wmorris20 I can't say I've spent alot of time examining the difference in what is being passed to the database when you are comparing the two methods as you have, but the major difference between the connections is frequency and/or where the data lives.
Import pushes the data into Azure (behind Power BI), and only let's you refresh 8x per day. (48x with Premium)
Direct Query - the data stays in the data source. As a user interacts, it is live, no need to refresh.
From what I have analyzed with DQ against SQL, there is additional syntax that is added to SQL queries when doing direct query when I've explicitly executed SQL commands from Power BI. Import just executed the command itself. But I never took a look further in DQ at the actual messages as I interacted with the reports.
Thanks for the response. I have a feeling the Diagnostic Trace isn't exposing exactly what's being sent to the data source. I have SQL Server Profiler running while interacting with a DirectQuery connection, and I see requests each time I interact. I don't see any up front filtering though. For example, if I filter on year with "2017", none of the SQL requests have a WHERE clause containing that. I have Product, Group, and Year with one bar chart of Sales Dollars in my test. If I filter on Year, you'll see three SQL requests - two for the Product and Group filters and one for Sales Dollars sum.
- Anonymous9 years agoNot applicable
wmorris20 That makes sense to me... It pulls back the different objects and allows you to do the filtering on the Report side. If it didn't do that, then it would have to understand the filter context of everything on your report, in your measures, etc. Will it generate an aggregate value if you create a measure summing up the sales of something? Or will that just query all sales?. I should probalby dig into testing this out to determine what is happening.
- Anonymous8 years agoNot applicable