Quick Tips: Export Power BI Desktop and Power BI Service Model Data In One-Shot with DAX Studio

Exporting Model Data to CSV 
or SQL Server in One Shot

Update 2021 March:

You can now export the data direct from Power BI Desktop using my tool, Power BI Exporter. Read more here.

In some of my old posts, which are the most popular ones, I explained how to Export data Power BI Desktop or Power BI Service data to different destinations like CSV, Excel and SQL Server. In this quick tip I explain a very easy way to export the model data as a whole to either CSV or SQL Server with DAX Studio.

Daniil from XXL BI well explained this method, but I’d rather quickly explain how it works and add some more information.

After release 2.8 of DAX Studio, you can now quickly export the whole model to CSV and SQL Server in one shot.

Enabling Export All Data in DAX Studio

  • Open DAX Studio
  • Click “File”
  • Click “Options”
  • Click “Advanced”
  • Tick “Show Export All Data button”
DAX Studio Export Power BI Model Data Settings

Export Power BI Model Data to CSV

DAX Studio Export Power BI Model Data to CSV
Continue reading “Quick Tips: Export Power BI Desktop and Power BI Service Model Data In One-Shot with DAX Studio”

What Does XMLA Endpoints Mean for Power BI and How to Test it for Free?

Test Environment from Power BI XMLA Endpoint

XMLA endpoint connectivity for public preview has been announced late March 2019. As at today, it is only available for Power BI Premium capacity users. This sounds like a massive restriction to a lot of people who don’t have a Premium capacity, but they’d love to see how it works. In this article I show you an easy way to get your hands to Power BI XMLA endpoint as quick as possible. Before I start, I’d like to simply explain what XMLA endpoint is and what it really means for Power BI users.

Power BI is Like Onion! It has layers!

Generally speaking, Power BI has two different layers, presentation layer and data model layer. Presentation layer is the visual layer, the one you make all those compelling reports and visualisations. The data model as the name resembles, is the layer that you make your data model in. This layer is the one you can access it via XMLA connectivity.

In a Power BI Desktop file, you can see both layers:

Different layers of Power BI

How XMLA Relates to Different Layers in Power BI?

As you may have already guessed, XMLA is only related to the data model layer and it has nothing to do with the presentation layer. So you may connect to a data model, browse the data model, import data from the model to other platforms like Excel and so forth.

XMLA Is Not New!

Seriously? Yes, seriously. It is not new. It’s been around for many years and perhaps you’ve already used it zillions of times. Whenever you’re connecting to an instance of SQL Server Analysis Services, either Multidimensional or Tabular from any tools like SQL Server Management Studio (SSMS), Power BI Report Builder, Excel, Tableau, etc…, you’re using XMLA connectivity indeed.

Power BI is an Instance of SSAS Tabular

It is true. Power BI runs a local instance of SSAS Tabular model. So, whenever you open a Power BI Desktop file (PBIX), Power BI creates a local instance of SSAS Tabular model with a random local port number that can be accessed on your local machine only. When you close the file, the local instance of SSAS Tabular is shut down and its port number is released.

I first revealed the fact that you can connect to the underlying data model in Power BI Desktop from whole different range of tools like SSMS, SQL Server Profiler, Excel, etc… on Jun 2016. So, we indeed were using XMLA to connect to Power BI data models for a long time. We can even take a step further to import our Power BI data models into an instance of SSAS Tabular. In that sense, we are literally generating XMLA scripts from Power BI to create the same data model in SSAS Tabular. How cool is that?

Sooo… What is new then?

Continue reading “What Does XMLA Endpoints Mean for Power BI and How to Test it for Free?”

Preparing On-premises Data Gateway Implementation Plans for Enterprises

Definitive Guide to On-premises Data Gateway Implementation
Photo credit: Kayla Duhon

If you are a Business Intelligence consultant working on Power Platform, Azure Logic Apps and Azure Analysis Services landscape, you probably know that On-premises Data Gateway cab be one of the most essential parts of your engagements with your customers. In many cases, installing On-premises Data Gateway can be a one-man-band job but in many others, it requires teamwork effort. Either way, it can go smoothly if you already have a well-thought implementation plan otherwise, it can quickly turn into a beast that can exhaust the whole implementation team and the customer for some days.

In this post, I do my best to provide you with some guidelines that can help you with your On-premises Data Gateway implementation planning. This post may look rather long, and some of the points are generic, but it is worthwhile mentioning them. Consider the following points before, during and after the engagement:

  • Understanding the use cases
  • Culture of the engagement
  • Environments (Dev, UAT, Prod)
  • Communication
  • Security
    • Corporate/environmental firewalls
    • Proxy Servers
    • Identity Access Management
  • People
  • Documentation
  • Installation, configuration, and testing

Here is a diagram of the important points that you should consider:

Implementing On-premises Data Gateway
Implementing On-premises Data Gateway

Use cases

You need to understand the use cases of On-premises Data Gateway (Standard Gateway) for your customer. If they need the gateway for their Power Platform, Azure Logic Apps, Azure Analysis Services or all of them. This is important as you either need to have access to your customer’s Power BI Service or Azure Portal or both, or you need to assist your customer to configure On-premises Data Gateway in Azure or in Power BI Service. The next points are:

  • Accessing customer’s Azure Portal and/or Power BI Service: The customer to decide whether to create a new account with sufficient rights for you or give you the credentials of an existing account. It is important to make sure you can access all environments and you have necessary rights to install/configure the gateway
  • You assist/consult a person at customer side with the implementation: you need to make sure you communicate with that person and see if he/she understands the requirements before the implementation date. Send them a calendar invitation beforehand to make sure he/she is present at that date. Always ask for a backup person just in case of an emergency happening to the primary person.
Continue reading “Preparing On-premises Data Gateway Implementation Plans for Enterprises”

Quick Tips: Boolean Conditions when Querying SSAS DMVs

Boolean Comparison in SSAS DMVs, Error: A Boolean expression is not allowed in the context

If you are querying SSAS DMVs you may want to add some conditions in the query.

Something like getting all active relationships, perhaps like below:

select * from $SYSTEM.TMSCHEMA_RELATIONSHIPS where IsActive = 'true'

Running the above query on an instance of SSAS Tabular gives you the following error message:

Error: A Boolean expression is not allowed in the context …

Fixing this is quite easy, run the below query to get active relationships:

select * from $SYSTEM.TMSCHEMA_RELATIONSHIPS where IsActive

Boolean Comparison in SSAS DMVs

And to get inactive relationships run this one:

select * from $SYSTEM.TMSCHEMA_RELATIONSHIPS where not IsActive

Boolean Comparison in SSAS DMVs