Power Map Is Released

Power Map was released as part of Office 2013 SP1. You can read the announcements here:



One important point to note here is that Power Map will only be available to Office 365 customers. If you have a standalone version of Excel, or have a regular (ie not Office 365) Professional Plus license, you will no longer be able to use Power Map. See:


I quote:

If you have a subscription for Microsoft Office 365 ProPlus, Office 365 Midsize Business, or for the Office 365 Enterprise E3 or E4 plans, you’ll have access to Power Map as part of the self-service business intelligence tools. To determine which subscription you have, see Office 365 ProPlus and Compare All Office 365 for Business Plans.

If you have Office 2013 Professional Plus or a standalone version of Excel 2013, you’ll be able to download and use the Power Map Preview for Excel 2013 until May 30, 2014. After that date, the preview will no longer work in any non-Office 365 subscription version of Excel.

So, yet more evidence that you need an Office 365 subscription and a streamed installation of Office to get all the latest BI functionality.

UPDATE: Meagan Longoria has the details on what’s new in this release here:



Allocation in Power Query

Now that the brave new world of self-service BI is upon us, old-school corporate BI types like me need to sharpen our Excel skills – and anyone learning Excel will, sooner or later, end up on Bill Jelen (aka Mr Excel)’s site. I found his latest podcast on splitting the value of a contract over N months particularly interesting not only because I had to deal with a similar problem with a client only a few weeks ago but also because the problem of allocation in Power Query is something I’ve been meaning to blog about for a while. In this post I’m going to take the same data that Bill and Mike Girvin (whose book on Excel array formulas I got for Christmas!) used in the podcast and show how to achieve the same results they did but in Power Query and Power Pivot.

My starting point is an Excel sheet with two tables named Contract and Month, shown below:


It’s not exactly the same layout as in the podcast but that’s deliberate – I want to keep my source data and my output (which could be a PivotTable, cube formulas or a Power View sheet) separate.

Next, I import the Month table into Power Query using the From Table button and then click on the Add Index button to add an index column, so that the query output is as follows:


I don’t need to load this anywhere though, even though I’m going to use its output in the next query, so I leave both of the boxes in the Load Settings section of the Query Editor unchecked and go back to the worksheet:


Next, I import the Contract table and add an index column in the same way:


I can now add a custom column to calculate the monthly amount by dividing Contract Amount by Months In Contract:


Now comes the interesting bit. I insert another custom column and this time the M expression to paste into the dialog is:

Table.FirstN(Month, [Months In Contract])

In each row this column contains a table containing the first N rows of the Month table, where N is the value from the [Months In Contract] column. The output is this:


I then just need to click on the expand icon next to the column header of the Custom column to repeat each contract row for all the months it applies to, rename the columns and set the column types appropriately, and I’m ready to load into the Excel Data Model:


Here’s the full M code for both queries:

--Month Query


    Source = Excel.CurrentWorkbook(){[Name="Month"]}[Content],

    InsertedIndex = Table.AddIndexColumn(Source,"Index"),

    ReorderedColumns = Table.ReorderColumns(InsertedIndex,{"Index", "Month"})



--Contract Query


    Source = Excel.CurrentWorkbook(){[Name="Contract"]}[Content],

    InsertedIndex = Table.AddIndexColumn(Source,"Index"),

    RenamedColumns = Table.RenameColumns(InsertedIndex,{{"Index", "ContractID"}}),

    ReorderedColumns = Table.ReorderColumns(RenamedColumns,{"ContractID",

                            "Months In Contract", "Contract Amount"}),

    InsertedCustom = Table.AddColumn(ReorderedColumns, "Allocated Amount",

                            each [Contract Amount]/[Months In Contract]),

    InsertedCustom1 = Table.AddColumn(InsertedCustom, "Custom",

                            each Table.FirstN(Month, [Months In Contract])),

    #"Expand Custom" = Table.ExpandTableColumn(InsertedCustom1, "Custom",

                            {"Index", "Month"}, {"Custom.Index", "Custom.Month"}),

    RenamedColumns1 = Table.RenameColumns(#"Expand Custom",{{"Custom.Index", "MonthID"},

                            {"Custom.Month", "Month"}}),

    ChangedType = Table.TransformColumnTypes(RenamedColumns1,{{"Allocated Amount", type number},

                            {"Contract Amount", type number}, {"MonthID", type number},

                            {"Months In Contract", type number}, {"ContractID", type number}})




Last of all, I need to go into the Power Pivot window and do two things:

  • Use the Sort By Column functionality to sort my Month column by MonthID
  • Format my Allocated Amount column using a dollar sign

And I’m ready! I can now create a PivotTable containing my allocated values:


Maybe it’s a little bit more long-winded than Bill or Mike’s examples but I don’t think it’s any more complex. And of course, now the data is in the Excel Data Model I have a lot more flexibility on how to present the data. For example I can use Power View with no remodelling or formula changes necessary:


One last point: I know it’s good practise to use a separate Date table with Power Pivot. I didn’t do so here because I wanted to keep as close to the original example as possible. And because I’m lazy.

You can download the demo workbook here.

“Expert Cube Development” Second Edition Available Soon!

Within a matter of days, “Expert Cube Development with SSAS 2012 Multidimensional Models” will be published. It’s the second edition of the very successful (19 5* reviews on Amazon US as of now) book on SSAS cube development that Marco, Alberto and I wrote a few years ago, updated for SSAS 2012.


You can pre-order it now from the Packt website, Amazon US or Amazon UK.

Before you rush off to order a copy, there are a three things I’d like to point out:

  1. This is basically the same book as the first edition with updated screenshots, a few bugs fixed, and several sections updated/expanded for SSAS 2012. There are no substantial changes. If you already have a copy of the first edition it’s probably not worth buying a copy of the second edition.
  2. The book only covers SSAS Multidimensional models, it does not cover SSAS Tabular models.
  3. This is not a basic introduction to building SSAS cubes – it’s aimed at intermediate-level SSAS developers who are already familiar with cubes, dimensions and MDX and who want to learn about best practices, design patterns, performance tuning and (most importantly) which features work well and which ones don’t. If you like the material I post here on my blog, you’ll probably like the book.

If you’re OK with that then by all means, go ahead and get your wallet out!

How Many Partitions Per Measure Group Are Allowed in SSAS Standard Edition?

Most people know that the ability to partition a measure group is a feature of Analysis Services Multidimensional Enterprise Edition, but that doesn’t mean that in Standard Edition you are limited to just having one partition per measure group. In fact it is possible to use up to three partitions per measure group in SSAS Multidimensional SE, with some limitations. For a long time I wasn’t sure whether this was legal, as opposed to possible, according to the terms of the SQL Server licence but since this page in Books Online (thanks to Rob Kerr for the link) states that you can have up to three partitions in SE then I assume it is:



If you do decide to use more than one partition in SSAS SE then you do need to understand the risks involved – and the reason I wanted to write this post is because I see a lot of people using more than one partition per measure group in SE without understanding those risks. Strictly speaking, SE is only designed to work with one partition per measure group. It needs those extra two partitions for two pieces of functionality:

  1. To support writeback, because using this feature requires SSAS to create a separate partition to hold writeback values
  2. To support incremental processing, because when you do incremental processing on a partition in the background SSAS needs to create a new partition, process it and then merge it with your existing partition

Therefore if you create more than one partition per measure group in SE you may find that writeback and/or incremental processing will break.

New Free Video On The MDX CurrentMember Function

New modules are being added to my MDX online training course all the time, and now there’s another free video available: a short introduction to the CurrentMember function. You can view it here (registration required):


The previous free video on MDX SELECT statements is also still available here, now with no registration required. If you’d like to subscribe to this course you can get a 10% discount by using the code TECHNITRAIN2014 when registering.

Don’t forget, if you are looking for classroom training in London for MDX, DAX, Analysis Services Multidimensional or Tabular, Power BI, Integration Services or the SQL Server engine check out http://www.technitrain.com/courses.php

Power Query Session From 24HOP Now Available To Watch

The recording of my session, “Power Query: Beyond The Basics”, from yesterday’s 24 Hours of PASS event is already available to watch here:

It’s a brief introduction to the M language that’s used in Power Query and shows some of the things you can do with it. You can download the slides and the demo material (a lot of which I didn’t have time to cover) from here:

All of the other sessions from the event can be found here:

Loading Power Query M Code From Text Files

One of the things that has intrigued me in the Power Query docs for a while now is the Expression.Evaluate() function, which takes some text and evaluates it as a Power Query expression (rather like good old StrToSet() in MDX). I can think of lots of fun things you can do with this, but here’s one very cool example: it allows you to store the M code for your Power Query query in a text file outside your Excel workbook.

Here’s an example. Consider the following Excel workbook, which has a table named FruitSales in it:


I can use this table as a source for the following simple Power Query query as follows:


    Source = Excel.CurrentWorkbook(){[Name="FruitSales"]}[Content],

    GroupedRows = Table.Group(Source, {}, {{"Sum of Sales", each List.Sum([Sales]), type number}})




Here’s the output:


No surprises so far. Next, I copy the code for the Power Query query above and paste it into a text file; in my case I’ve saved my file at C:\PowerQueryQueries\DynamicQuery.txt


Back in Excel, I can now load the code stored in this text file in a new query using the following code:


    //Load M code from text file

    Source = Text.FromBinary(File.Contents("C:\PowerQueryQueries\DynamicQuery.txt")),

    //Evaluate the code from the file as an M expression

    EvaluatedExpression = Expression.Evaluate(Source, #shared)    




The end result is exactly the same as in the previous example, except that in this case the code to read the data from the table and to aggregate it is loaded from the text file and is not stored inside the workbook.

The Source step here is fairly straightforward – it just loads text from a file into Power Query. It’s the next step where the magic takes place: as I said, Expression.Evaluate() takes the text and evaluates it as an expression, but it’s the second parameter which defines the environment that the expression evaluates in that seems to be the key to making this work. The chapter on “Sections” in the Power Query Formula Language specification document has a little bit more explanation of what environments are but I have to admit I’m not 100% clear on how all this ties in to M as it is implemented in Power Query today.

For those of you who can’t afford a Power BI subscription, this technique allows you to share queries between multiple workbooks without a Power BI site. In fact it has some advantages over sharing a query in Power BI because it always reads the definition of the query from the file, and so it will always use the latest version of your query – in Power BI, when you use a shared query you take a copy of the query and it is not updated even if the original author shares a newer version.

%d bloggers like this: