Hello P3 World! My name is Krissy Dyess and I…
**Use the discount code “3ORMORE” when signing up 3 or more people.
Hello P3 World! My name is Krissy Dyess and I…
I answered some forum questions recently that were similar in…
by Matt Allington In my last blog on PowerPivotPro.com I…
by Matt Allington In this post, I am going to…
Guest post by Thomas Allan
Intro by Avi: As in Excel, in Power Pivot there are often many ways to accomplish the same thing. For example you can source a Date/Calendar table from Excel, Azure (here and here), Power Query, and SQL (this post). That is usually a sign of strength of the tool. Although it also makes it more challenging/fun to be able to weigh the options and decide which one works best for you given your situation. Thomas, shows us a cool way to pull Date table from SQL.
Stepping back a bit, there is some good interplay between Power Pivot and SQL. In terms of feeding Power Pivot using SQL – see Why PowerPivot is Better Fed From a Database Part 1 and Part 2. And also Power Pivot being a great addition for SQL savvy folks – see I Know SQL Queries, So Why Do I Need Power Pivot?. Goodness all around, I say 🙂
Take it away Thomas…
In addition to often mentioned benefits of using SQL servers as data stores (flexibility, reliability, scalability and security), the benefit of linking to a centralized source that delivers results quickly, consistently to practically any client, anywhere, adds a powerful dimension of “portability“ from the outside of the Excel workbook as Power Pivot and DAX formulas offer on the inside.
Four types of resources are often used to create date tables within Power Pivot: 1) Excel itself, using formulas or VBA, 2) data feeds, which you can find an example of following this hyperlink, 3) Power Query, which you can find an example of following this hyperlink, and 4) relational databases.
The example that follows was developed using the relational database SQL Server 2012 and uses only table-valued functions. Although the code was developed on SQL Server 2012, it was also tested on a 2008 release of Microsoft’s flagship database product.
For demonstration purposes, the solution offered here is based on a calendar fiscal year (quarters start January 1, April 1, July 1 and October 1). For other types of calendars, such as 4-4-5 or school semesters, the code can modified by a SQL developer (also, for other types of calendars, some architectural issues may also apply inside Power Pivot, which are fully explained in Rob Collie’s comprehensive Power Pivot course).
This post assumes that the reader has basic familiarity with SQL Server Management Studio, sufficient to install table-valued functions, or has access to someone who knows how to install table-valued functions. This post also assumes familiarity with connecting to a SQL Server database from within Power Pivot (similar to connecting to an Access database).
Download SQL code below.
We have a really typical looking Date table. However, we are going to be drawing some pretty charts summarized by weeks, and our business defines “end of week” at Saturday. So, we need a new column in our Date table that stores this “Week Ending” date for each row.
The first thought to occur to me was “well, for each Year&WeekOfYear, I just want to grab the max date”. That sounded easy enough… EARLIER() no longer scares me…
Yes, We’ve Seen This Image Before and I Am Sure We Will See it Again
In the Spring of 2011, I dove into a Power Pivot project that I thought was going to be simple, but even today remains the most complex thing I’ve ever done in DAX. I think it’s fair to say that the experience, at the time, was traumatizing. (The client’s business logic itself was/is incredibly complicated. It’s 100% legitimate, but I think barometric pressure might be factored into their budget/actuals ratios. Kidding.)
But like many difficult experiences, a lot of good came of it as well:
Ah yes, the Greatest Formula in the World. The solution to all our custom calendar needs, and a pattern I’ve repeated hundreds of times since. On the blog, in the book, in client workbooks, everywhere.
Well it turns out, the GFITW could afford to go on a diet.
Here’s the “classic” GFITW pattern:
The Red Bars Are Accurately “Tied” to the Months in Which Those Sales Happened,
but the Blue Bars are Four Months “Late.”
So you know, I wrote a book last year. Being the author, I get reports on how well it’s selling.
What follows is strictly inevitable, considering the people involved and their addictive relationships with data.
Guest Post by Jeff Lingen [LinkedIn]
We don’t even know what it is yet. We don’t know what it is. We don’t know what it can be, we don’t know what it will be, we know that it is cool.
Zuckerberg’s early assessment of Facebook was a lot like how I felt after first discovering PowerPivot 3+ years ago. I knew it was cool but had no idea how it would fit into an enterprise business intelligence environment. For a long time PowerPivot for me was just a cool thing that I used for my own data analysis or for proto-typing tools that I would eventually turn into “enterprise-level” solutions. Today I need a pretty compelling reason not to use PowerPivot for almost all of my organization’s analytic requirements. So where does PowerPivot fit into the enterprise BI environment and how do you get associates engaged and use it to provide value?
“There’s a Fight Club up in Delaware City.”
“Yeah, I heard.”
“There’s one in Penns Grove too.”
“Bob even found one up in New Castle.”
“Did you start that one?”
“No, I thought you did.”
About a week ago I was talking to Chris Campbell and some of the other folks at Blue Granite. Chris mentioned that he has been teaching some PowerPivot classes at the Microsoft Technology Centers, sometimes even in my neck of the woods, but I didn’t know until he told me.
Which, of course, instantly reminded me of the scene above in Fight Club. I’m sure everyone else makes the same connection right?
Anyway, Chris asked if I would be interested in him writing a guest post and I said heck yeah! So, without further delay, I give you the PowerPivotPro.com debut of Chris Campbell.
Recently, a customer sent me a question regarding a DAX problem they were working on. They have a Members table in their model that includes attributes of “Start Date” and “End Date” for each member. The question they needed to answer was “How many active members did we have in [fill in the blank]?” I thought this was a pretty interesting question and it seemed like it ought to be pretty easy to do in DAX.