Skip to main content

Do you want to look good on paper? Data can do that with a DATE TABLE.


Data, especially in the time of quarantine, can make you look REALLY good on paper. Or, on the screen I should say-- or in this case in a table.

And if I am being honest- putting all my cards on the table (you're welcome for that pun)- I've definitely tried to use data in building a defense when my wife has called me out on something. Unfortunately for me, she knows how a cherry-picked data table can tell many different stories. Nevertheless, I persist!

In this post I discuss:
*DAX function CALENDARAUTO
*why I broke-up with function CALENDAR
*link to a demo I create

*how I attempt to use a Date Table to make myself look better to my wife 😁




I’ve really loved learning about DAX functions lately during my deep dive into the world of Power BI.  As you know I have a math teaching background so it is fascinating to see how I can manipulate simple calculations to use time intelligence, override specific filters, and cross reference other tables.  One of the things I came across though the other day while helping out a client is a simple DAX function that I hadn’t given much thought to at the time.  That function is CALENDARAUTO.

I had learned in the past that is was really simple to make a date table using DAX just by implementing the function CALENDAR.  With the CALENDAR function you simply put in your start date and end date and voila!,  a 1 column table of all the dates from the beginning to end are created for you.  It was a simple enough formula to implement and it was the one I used, until this past week.  Why did I move on from this formula you ask?  Well, it comes down to doing a data refresh.

I was working with a client and everything was going smooth until we refreshed her data and our table visual did not look quite right.  What happened?  Well, when she refreshed her data there were some new data associated with dates that were after our predefined ending date and before our predefined starting date.  It was a pretty easy fix though because we just went in and sorted her table to look for the earliest date and latest date and then updated our CALENDAR function with those dates.  

You can see the problem, however, if we are going to refresh the data in the future we will have to fix the problem each time.  Well, let me introduce you to our friend CALENDARAUTO to do the heavy lifting for us.

The DAX function CALENDARAUTO will scan through every single table we have loaded into our Power BI model and look for the oldest and most recent date.  When it finds the earliest date it will automatically make January 1st of that year as our starting point for our date table.  When it finds the most recent date it will automatically make the December 31st of that year our last date for our date table.  This means we no longer have to do anything manually and the date table will always updated when new data with dates is brought in.

I can’t share her data below so I thought I would put out a real basic video example to illustrate the differences between the two. 

Again, thanks for following the journey!

Comments

Popular posts from this blog

Best Practice To Trim Before Removing Duplicates or Merging In Power Query Editor

In last week’s blog, I wrote and did a video about how to remove duplicate records and keep the most recent entry as long as a date column was part of the data source.   I came across the scenario while giving training on Power BI with my company Pragmatic Works.   See the video below:     This week, while doing another two-day training I came across a different scenario from a follow-up conversation from day 1.   I had explained how to remove duplicate records and one of the students started working on a Power BI project she has for her company.   On day 2 the student informed me that her remove duplicates step was not working.   I said that is odd and I asked to see the data.   In one of her table visuals, I could see that it appeared that a few of the records had duplicates based on the name column.   After further investigation though, we figured out the culprit.     She had done all the steps correctly, but it was a data integrity issue.   In her data source, the perso

Relating "Related Tables" to Baseball because I Miss Sports

I miss sports. In particular, I miss baseball. Between learning more Power BI functions and the ins-and-outs of DAX, I've turned to Netflix to fill the deep caverns left in my soul since baseball season has been postponed. And as a result, I've thought more about tigers and big cats more than I ever have in my life. I know ALL about Carol Baskins and am fully on board for a spin-off centering on locating her lost husband. I've googled "is it really legal to own a tiger in a residential area?" Without baseball in April, I am barely hanging in there (kinda like Joe Exotic's eyebrow ring). So, I am filling the sports-sized hole by using baseball stats in Power BI to demonstrate pulling data from multiple tables and consolidating it into one table.  Some of the data we want to consolidate also has to have some aggregations (which is fancy for "calculations") performed on it.  In this demo I will attempt to break down what is really going on

Create A Record Without A Form In Power Apps Using PATCH

 In Power Apps, forms are great to use to submit data to be recorded in your data source.  They do not take long to set up and the functions used to submit the data are fairly simple.  This simplicity, however, can come at a cost.  The cost of using a form is you don’t have a lot of design control in terms of layout and design.  If you don’t like the rigid structure of forms and want more freedom, then I’ve got the fix for you.  You need to become acquainted with the Patch function.   The Patch function allows you to update or create a new record in your data source.   The Patch function requires you to identify your data source, decide if you want to update or create a record, and then point to your controls on the app that contains the data you are submitting.   The coding is a little more involved compared to SubmitForm(FormName) that you use on forms.   The payoff, though, for learning a little more advanced code is you get complete design freedom for your data input controls.