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.

«February 2016»

Power BI Publish to Web for Anonymous Access is Here

Earlier this week on Wednesday the Microsoft Power BI made an incredibly exciting announcement and released Power BI “publish to web” as a preview feature. This is HUUUUGE news! This was probably the top requested feature and its finally here thanks to the hard work and dedication of the Microsoft Power BI team!

Read Getting Started with R Visuals in Power BI

Power BI “publish to web” allows you to easily expose a Power BI report to the world through an iframe that can be embedded wherever you like.

To publish your Power BI report to the web, log into your Power BI site.

Find the report that you want to share and click File in the top left.
Power BI publish to web

You’ll see a message pop up box similar to below. Click the yellow button to create the embed code.
Power BI publish to web preview

This is where you’ll see a very important warning!
WARNING: Reports that you expose through the “publish to web” feature will be visible to everyone on the internet! This means NO AUTHENTICATION is required to view the report that is embedded in your application.
warning 2

Once you do that, you’ll receive an embed code that you can then use to expose your Power BI report within your blog as seen below!

As you can see the report maintains all the interactivity features of Power BI. And as your Power BI report updates and changes, those changes will be reflected in your embedded Power BI reports!

Pretty awesome!

Additional Resources

Read the Power BI “publish to web” announcement here.

Read the Power BI “publish to web” documentation here.


Let me know what you think of this feature or if you have any questions. Leave a comment down below.

Read more


Non Empty vs NonEmpty

Hey everyone, in this blog I want to address a very common MDX Question. What is the difference between the NON EMPTY keyword and NONEMPTY function? To take it a step further which one should you use?

Non Empty keyword VS NONEMPTY Function.

The big difference between the NON EMPTY keyword and the NONEMPTY function is when the evaluation occurs in the MDX. The NON EMPTY keyword is the last thing that is evaluated, in other words after all axes have been evaluated then the NON EMPTY keyword is executed to remove any empty space from the final result set. The NONEMPTY function is evaluated when the specific axis is evaluated.

Should I use NON EMPTY keyword or NONEMPTY function?

Ok Mitchell, so you told me when each of these are evaluated but really you haven’t told me anything up until this point. Can you tell me which one I should use already? Well, unfortunately, it depends. Let’s walk through an example of each using the BOTTOMCOUNT function.


In this example I’m returning the bottom ten selling products for internet sales. Notice that I have returned all products that have no internet sales, this is not necessarily a bad thing, maybe you want to return products that don’t have sales.


However if you don’t want to return these products then we can try using the NON EMPTY keyword. In the below example you can see the results when I add NON EMPTY to the ROWS axis.


WHOOOAAA, what happened?? A lot of people would have expected the results here to show the bottom ten products that DID have sales. However, that is not the case, remember that I said the NON EMPTY keyword is evaluated LAST after all axes have been evaluated. This means that first the bottom ten selling products which have $0 in sales are first returned and then the NON EMPTY keyword removes all that empty space from the final result.

BOTTOMCOUNT function with NONEMPTY function.

So let’s try this again, if you want to return the bottom ten products that had sales then we must first remove the empty space before using the BottomCount function. Take a look at the code below:


In this code we first remove the empty space before using the BOTTOMCOUNT function. The result is we return the bottom ten products that had internet sales. Once again neither one is right or wrong here it just depends on what you want in your final result.

NON EMPTY Keyword vs. NONEMPTY Function – Performance

There is a very common misconception that the NONEM

Read more

SQL Internals Reading Data Records Part 5: Variable Offset Array

  • 6 July 2012
  • Author: BradleyBall
  • Number of views: 3566


  Welcome back Dear Reader to Part 5 on our series of how to read a Data Record.    In Part 1 we covered the Tag Bytes.  In part 2 we covered the Null Bitmap Offset.  In Part 3 we covered the Fixed Data Portion of a record.  And in Part 4 we talked about the Null Bitmap. Today we will be discussing the Variable Offset Array.  This part of the record is another optimization, the Variable offset array will only show up IF we have Variable Length Data Types in our Table and if they are not NULL.  If they are all NULL then we will not get an offset array.


“So Balls”, you say, “Why no offset array if it is NULL?”


Excellent question Dear Reader and the answer is in the name itself.  Just about clear as mud, let’s get to the demos and clear this up.




First let’s update our chart so we know what part of the Data Record we are tackling.  Once again these images come by way of Paul Randal (@PaulRandal | Blog) and the MCM Video series on Data Structures and the good people from Microsoft. 



What the Variable offset array does is house the numeric value to the end of the record that we want to read.  So if we have three variable length columns set to a max of 15, 20, and 25 but we only use a portion of them (8 out of 15), (10 out of 20), and (20 out of 25) then we would have unused portions right?  Wrong. 


If we use the meta data and just read the full length of the columns we are getting stuff wrong and wading into columns we do not need to, not to mention in acting like Fixed Length Data our records bloat and there is always wasted space.  This is VARIABLE Length data, we only use what we need, think of this as the Green Data Type.   So all this Recycling is cool and all, but it means that we need to have some data to help us efficiently read this data.  And Voila we get our Variable Length Offset Array.  This tells us what the end of the record is for one record at a time so we go to the end of that record and read forward.


So without further ado let’s get right to it.  We’ll use the same code that we used on day 4, and we’ll create our table and one record of data.


       DROP TABLE dataRecord2
CREATE TABLE dataRecord2
                     (myID INT
                     ,myfixedData CHAR(4)
                     ,myVarData1 VARCHAR(6)
                     ,myVarData2 VARCHAR(6)
                     ,myVarData3 VARCHAR(6)
INSERT INTO dataRecord2(myID, myfixedData, myVarData1, myVarData2, myVarData3)
VALUES (7, 'XXXX', null, null, null)


Now let’s do a DBCC IND and get our page numbers.


DBCC IND(demoInternals, 'dataRecord2',  1)



Remember that a page type 10 in an allocation page and we are reading a data page.  So look for the page number that has a PageType=1.  We’ll follow that up with a DBCC PAGE on Page 296, remembering to turn on Trace Flag 3604 so that we get our output to our SSMS window.  *Remember your page numbers may be different than mine. 


DBCC PAGE('demoInternals', 1, 296, 1)



Now that we’ve got our page let’s take a look at it, I’m only going to post the relevant output.

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP    Record Size = 15


Memory Dump @0x0000000010E3A060


0000000000000000:   10000c00 07000000 58585858 05001c             ........XXXX...


You may be wondering where our Variable offset Array is?  And the answer is there isn’t one.  Our initial column had only Null values for our Variable Columns and so our record only took up the space that it needed.  No Variable length columns means no need for a variable column offset array.  So let’s add one more record and see what happens.


UPDATE dataRecord2
SET myVarData2='WWWWWW'
DBCC PAGE('demoInternals', 1, 296, 1)



Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS

Record Size = 27                   

Memory Dump @0x000000000A03A060


0000000000000000:   30000c00 07000000 58585858 05001402 0015001b  0.......XXXX........

0000000000000014:   00575757 575757                               .WWWWWW


We have Several values in our Variable Offset array.  First we have 02 00 then 1500 and finally 1b 00. As you might have guessed these are Hex pairs.  Our first set of Hex pairs will tell us the number of columns for our variable length fields, in this case 0200 which translates to 0x0002 or just 2.  We have three columns but remember we just updated the middle column, so we have to acknowledge the column in front of it but not behind it because we do not yet need this space.  1500 is our next Hex pair which translates out to 0x0015 in this case we are translating Hex to Decimal and not binary, remember to use our handy tool, and this translates to 21.


So how do we get to 21?  2 Bytes for our Tag bytes + 2 bytes for the Null Bitmap offset + 8 Bytes of fixed Length Data + 3 bytes for the Null Bitmap Offset + 6 bytes for our Null bitmap offset array, or simply (2+2+8+3+6), = 21.  And at record 21 there is nothing because our value is null.  Our Remaining value is 1b00 or 0x001b also known as 27.  Remember we inserted six W’s into our variable length field, so just add 6 to 21 and we get 27 the end of our current record.


Just to double check let’s insert some data into our final Variable length row and look at the updates.


UPDATE dataRecord2
SET myVarData3='BBBB'
DBCC PAGE('demoInternals', 1, 296, 1)


Remember just putting out the relevant data.

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS

Record Size = 33                   

Memory Dump @0x000000000A03A060


0000000000000000:   30000c00 07000000 58585858 05000403 0017001d  0.......XXXX........

0000000000000014:   00210057 57575757 57424242 42                 .!.WWWWWWBBBB


Right away we see our values have changed 03 00, 1700, 1d 00, and 2100 are our new values.   We now have 3 columns so we see that reflected in 0x0003 or 3.  Our first value incremented by 2 because of the addition of our 3rd column to 0x0017 or 23, and our second column has incremented as well from 0x001b to 0x001d or 29.  Our new value for our 3rd row is 2100 which translates to 0x0021 or 33.  If we add 4 , for the four B’s we added to column 3, to 29 which is the ending value of column 2 we get 33 (4+29=33).  So one last update and we’ll have gotten rid of all the null’s.


UPDATE dataRecord2
SET myVarData1='SSSS'
DBCC PAGE('demoInternals', 1, 296, 1)

Once again I’m only going to copy out the relative output.


Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS

Record Size = 37                   

Memory Dump @0x000000001398A060


0000000000000000:   30000c00 07000000 58585858 05000003 001b0021  0.......XXXX.......!

0000000000000014:   00250053 53535357 57575757 57424242 42        .%.SSSSWWWWWWBBBB


And now we’ve shifted our values one more time.  The relative values are 03 00, 1b00, 21 00, 2500.  We still have 3 columns 0x0003, but now we see that our first record has grown again to the ending point of our first variable length record to 0x001b or 27.  The ending point of our second variable length record is 0x0021 or 33, and the ending point for our 3rd and final record is now 0x0025 or 37.


And that as they say Dear Reader is that, I hope you enjoyed the read and as always Thanks for stopping by.





Categories: Analysis Services
Rate this article:
No rating


Other posts by BradleyBall

Please login or register to post comments.