In this corner, coming in with all its Excel glory we have Power Query! And in this corner we have a new programming language, DAX! Have you ever felt like there is a tug of war going on between these two technologies? In this episode, the team discusses the two technologies, what they do, when — and perhaps more importantly, WHY might you use them.
“They have two very different purposes. They start out as two incompatible technologies and there’s no sane way to merge the two.”
“I liken Power Query/M to be able to use what we used to with SSIS to bring that data in and get it into almost the final state.”
“Power Query, you can get away with just, as my boss used to say, poke and hope. Just start clicking buttons and figure it out. With DAX, you’re just going to run into a wall if you try that.”
“’Would I want to do this using Integration Services? Okay, then I’m going to use Power Query.’ If I’m not going to want to do this and get it into the data warehouse and I want to build it into a semantic layer, then I’m going to be using DAX.”
“They do have a good complementary nature. It would be very hard to do the job of both with one or the other.”
Listen to Learn
00:38 Intro to the team & topic
01:25 Compañero Shout-Outs
02:39 What Have I Learned
04:47 SQL Server in the News
06:13 Power Query and how it fits into Power BI
09:08 Why does my Swiss Army knife have a scalpel and a cork screw?
10:40 The elevator pitch on the difference between these technologies
12:17 So…which one should I use?
13:15 You have to learn to think differently to use DAX
15:21 You might need to do some unlearning
18:15 Are both Power Query and DAX here to stay?
19:40 How M fits in…and the serious answer: functional vs imperative languages
24:43 Recommendations on learning these technologies
26:35 Closing Thoughts
“Happy Rock” for What Have I Learned by https://www.bensound.com
Music for SQL Server in the News by Mansardian
Carlos: Compañeros, welcome to another edition of the SQL Data Partners Podcast. I am Carlos L Chacon, your host, this is Episode 162 and I am joined by my fellow cohorts, Angela Henry.
Carlos: Eugene Meidinger.
Carlos: And all the way from the other side of the world, Kevin Feasel.
Carlos: So if he drops out–
Kevin: Hello, can you hear me?
Carlos: Yeah, if he–
Kevin: Am I there?
Carlos: He sounds a little bit like Max Headroom, then that’s why.
Kevin: Also because I am stuck in the 80’s.
Eugene: It’s a good time to be stuck in.
Carlos: Our topic today is Power Query versus DAX. We’re going to be talking about differences, and I guess why or how you’d want to be using one or the other. But first, we do have a couple of shout-outs we want to give. I have shout-outs Richard Nuffer, Naga Perni, Tahir Gul, Mary Case, Jennifer Halstead, Carlos Garcia from Tijuana, giving us a little bit of love on the podcast, so thanks for tuning in, Carlos. Gina Meronek, I’m sure I’m saying that wrong. I apologize. Ed Pearson, and then Mala, who I used to say was from Kentucky, but not from Kentucky anymore. Now she’s actually down in Raleigh, is going through the archives and gave us a little love about Episode 106 with Randolph West, talking about temporal tables. That was a long time ago, but thanks, Mala, for the shout-out. Angela has a shout-out.
Angela: I do. Jose Mueller reached out to me on LinkedIn and Carlos, he still wants an episode about BizTalk.
Carlos: Yes, and I have still been searching for somebody to talk about BizTalk. So compañeros, if you want to talk about BizTalk, reach out to us. We’d love to know. I need to see if I can get somebody down. I haven’t been able to get that person, just yet.
Angela: It’s kind of tough.
Carlos: Yeah. We are still thinking about you, Jose. So thanks for following back up with us. Okay, so in the What Have I Learned section, and or we will have a video in the show notes for today’s episode, but Bert Wagner. His videos are becoming pretty impressive. Now, his guests, not so much.
Eugene: Wow, ouch. That was a direct jab at me, everyone, just to be clear.
Carlos: Yeah, yeah, no, obviously.
Eugene: Jess Pomfret is fine, Erin Stellato is fine, Drew Furgiuele is fine. That was directly aimed at me.
Carlos: Yeah, yes, if you just put your hand up on the right hand of the screen, you know, you’ll be okay, watching the video. But Bert Wagner’s been doing some pretty cool stuff. We’re going to have his video on the show notes today, Power Query vs DAX, as well and that’ll be fun. We’ve been working on a couple of Power BI projects and Angela and Eugene have come up with something they’ve found.
Eugene: Well, yeah, this is quite a discovery.
Angela: Eugene more painfully than myself.
Eugene: Yeah, so we’re doing some work and one of our customers loves the aesthetic design of Stephen Few and Stephen Few, for those of you who don’t know, he’s very much a fan of detail-heavy dashboards with sparklines and he invented bullet charts, and just how much information, compared to the pixels on screen can you fit, which a lot of times makes a ton of sense. But it runs totally opposite to what Power BI is good at, because Power BI is not great at that detail-heavy kind of reporting. There’s a limited number of options for doing sparklines, limited number of options for doing bullet charts and that sort of thing, and it’s not really designed to slam a bunch of different contexts into the same row of a table or a matrix. I’m learning the hard way that Stephen Few and Power BI, the two don’t align as well as one might like.
Carlos: Yeah, it’s interesting, so when philosophies collide, there, when your philosophies and your tooling, not to say that some things can’t happen, but–
Eugene: It feels like swimming upstream a little bit.
Carlos: A little bit, right.
Angela: Yeah, they are definitely contraindicated.
Carlos: There you go. Okay, so for a little SQL Server in the News. I’m not sure how new this is, necessarily, but apparently, we’re being reminded, how about that? So, Azure SQL Managed Instance, a version came out in full support late last year, and I think they were rolling out the business one here, shortly, if they haven’t already done it. But Microsoft wants to remind us that we can recreate dropped databases in Azure Managed SQL Database via the automated backup process. And so, there are some tools and tips on how to do that, so we’ll put up the link on the show notes, today.
Angela: And then I have one more. It’s not necessarily SQL Server in the News, but it’s Power BI in the News. So they just did a new release of Power BI Desktop, was it Monday or Tuesday, I don’t know, the days have all run together, now, but in the last few days, and one of the things that has been released is word-wrap for titles on visuals. Oh my gosh, yay! The crowd goes wild! Wooo! It seems like such a small thing, but it makes such a huge impact. So there you have it, folks, they listened, they made it happen.
Carlos: Tada! And the people rejoiced.
Angela: Yes, yes.
Kevin: More importantly, what are the lines?
Angela: And they added rounded corners, so it’ll go faster, just like they did when they did that to SSIS, so, woohoo!
Carlos: There you go. Very nice. Okay, compañeros, for our conversation today, on the left-hand side of your audio device, we have Power Query, coming in from Excel land! Power Query enhances self-service business intelligence for Excel with intuitive and consistent experience!
Eugene: Oh, geez.
Carlos: And on the other side, coming in at, I don’t know, whatever the download speed for your internet, is DAX! DAX, a collection of functions, operators and constants that can be used for formula expression to calculate and return one or more values!
Eugene: Oh my goodness.
Carlos: That’s the extent of what I know about these two things, so that’s as good as it’s going to get from me, today, compañeros.
Eugene: Sure, it’s all downhill from here.
Angela: So who’s wearing the red trunks? That’s what I want to know. Who’s wearing the red trunks?
Carlos: Yes, there we go, so I’ll let you guys decide how all that needs to shape up, here. But ultimately, I think we’re talking about how to get functions or how to manipulate data, at least for this conversation, specifically to Power BI. Now, it’s curious, my brief investigation of this topic, when I look at Power Query, I start getting a lot of things for Excel. So maybe first, let’s talk about, maybe a little bit of history for Power Query, and then we can get into how it fits into Power BI.
Eugene: Yeah, so it’s funny, Power BI, I like to call the current iteration, the SSAS iteration, Power BI V2, because V1 was a bunch of unrelated Excel add-ins that just had the word Power in the name. So, you had Power Query, you had Power Pivot, which was the DAX piece. You had Power View, which was like the Silverlight-based visualization piece, and then you had Power Map, which was maps. And so that was Power BI V1 and part of the reason why Power Query comes up so much for Excel, not only were they both add-ins for Excel, but there’s a great TechEd talk from Matt Masson, who was the project manager for Power Query back in 2014, and he says that the litmus test, when they were designing this, for who would find it useful, was anyone who got regular use in the week out of the Excel formula bar. So those Excel users were kind of ground zero for the target audience when it was first created, and so that’s part of why you see that. But back in like 2015, Power BI became a cloud offering and these two languages kind of migrated away from Excel to Power BI, but they’re still both available in base Excel today.
Carlos: Okay, so then how are they different? Are we using the same thing? That idea is, if I’m an Excel user I’ll feel right at home. I’ve started using them in Excel, I’ll feel right at home in Power BI, right?
Eugene: Yeah, they transfer over pretty one-to-one. You’ll generally have some more features a lot of times in Power BI, but yeah, if you’ve learned Power Query and DAX in Excel, those technologies will just transfer straight over if you’re working with Power BI.
Carlos: Okay, so then why do we have two? What’s the whole Power BI or Power Query, rather, versus DAX?
Kevin: Wait until Carlos finds out about M.
Angela: Mmm, it’s good.
Carlos: The letter of the alphabet that proceeds N? Yes, I’m very familiar.
Eugene: So why do we have two? One of the ways that I think about it is that they’re both domain-specific languages, so I’m literally finishing up a course on Power Query and I have this one diagram that kind of shows general purpose languages like C# and Python and that sort of thing, and the way I describe those is, anything that you can make a normal video game in is a general-purpose language. It has support for graphics and user-input and all this kind of stuff. But stuff like DAX and M/Power Query, those have very, very narrowly defined purposes, and so that’s part of why we have two of them is they do very different things. You’re used to maybe having a Swiss Army knife, and you’re asking right now to me, “okay, why do we have a scalpel and a cork screw? Why can’t we just use one of them to do the job?” Cause you could open a bottle of wine with a scalpel.
Angela: You might lose a finger.
Eugene: You might lose a finger.
Angela: But you could do it.
Eugene: And you could make some incisions with a cork screw.
Kevin: It’s called trepanation.
Eugene: Yes! Look, once you relieve that pressure, all of your problems go away. I think they have two very different purposes, and probably two just historical reasons. They start out as two incompatible technologies and there’s no sane way to merge the two.
Carlos: Okay, so then why am I using Power Query?
Eugene: If I’m ever in an elevator and I have one minute to explain these technologies, the way that I like to think about it is M stands for menial labor and anything that you could pay an intern $8 an hour to do in Excel, you can automate with Power Query. That’s the level of complexity you want to be thinking about. Whereas DAX is the stuff that you’re paying someone $35 an hour because they understand how the business works, and they’re trying to model the KPIs and key metrics and stuff for the business, and so it’s two different use cases, there. Power Query is for that data cleanup, that data preparation. It’s for getting everything in place as one of our previous guests, Matthew Roche says, it’s for that mis en place, which I learned what that means, but it’s getting all of the stuff ready. Whereas, DAX is much more of, “okay, I have all the pieces, what do I want to represent or show? How do I add that meaning? How do I add ‘okay, this is what the data means?’” That semantic layer.
Carlos: Right, right, okay.
Angela: Yeah, so and I liken this to we’ve always had that traditional– I say traditional, you know, it’s been what, 15 years. The whole building your data warehouse, you do all that, you use Integration Services, so I kind of liken Power Query M to be able to use what we used to with SSIS to bring that data in and get it into almost the final state if that helps anybody out there, listening.
Eugene: Yeah, and they’re moving in that direction more. We had an episode on dataflows, right?
Eugene: And they definitely seem to be moving in that direction where they’re making it so it’s more of a reusable process to be able to do all of that data staging.
Carlos: Ultimately, from our podcast, we like to talk a lot about how to get started with some of this stuff, you’ve already quantified, if I’m an $8 an hour employee, I’m using Power Query, is that where I’m headed, or what’s the learning curve? How would I describe myself and which one should I go after?
Eugene: To be clear, I make more than $8 an hour and I use both. I do want to be clear on that. The learning curve for Power Query is immensely, immensely easier, because so much of it you can just do through the graphical user interface.
Carlos: I see, sure.
Eugene: They kind of follow the 80/20 rule of user interface design where 80% of what you ever want to do with Power Query is immensely simple. You want to convert the first row into headers? Click a button. You want to remove duplicate rows? Click a button. You want to rename a column? Click a button. That other 20%, like you want to talk to some web API, really, really, really difficult. So for Power Query, they’ve optimized for the business user. For DAX, if you want to learn DAX, either buy a book or watch my course on Pluralsight, because it’s a pain. Sincerely. I’d prefer the second, so you can help pay for my mortgage, but either way, because, sincerely, DAX looks easy. It looks like, “oh, it’s just Excel formulas”, but it requires a very different mental model to work with, because you have to start thinking in columns instead of rows, and you have to start thinking about what filters are applied at any one time and unapplying and manipulating those filters. So, DAX is a lot harder to understand. I want to say Marco Russo says, “it’s simple but not easy”, which I think is a good way of describing it. So, Power Query, you can get away with just, as my boss used to say, poke and hope. Just start clicking buttons and figure it out. With DAX, you’re just going to run into a wall if you try that.
Carlos: So Angela, I know this is something we’ve been talking about, as far as, you get getting more involved in this. What’s been your experience as you’ve tried to, either learn or go between these two?
Angela: I always have to stop and go back to my Integration Services days, and I have to stop and think, “would I want to do this using Integration Services? Okay, then I’m going to use Power Query.” And if I’m not going to want to do this and get it into the data warehouse and I want to build it into a semantic layer, then I’m going to be using DAX. Now, one of the really hard parts for me, that I’ve had, my background is a DBA and I’ve learned to think in set theory and that kind of goes all out the window when it comes to DAX.
Eugene: Yeah, 100%.
Angela: That makes me absolutely crazy. That is the thing that I struggle with the most, and your business users aren’t going to have that issue, but a lot of DBAs are going to have that problem if they’re going to try and start using Power BI to do some of this stuff. You really have to change your thinking. It’s very frustrating.
Eugene: Yeah, I think out of the two options of coming from the Excel world or the SQL world, coming from the SQL world is more painful, because you have more things you have to unlearn to be able to take advantage of DAX.
Carlos: Oh, interesting.
Angela: Yeah, very true, very true.
Kevin: So what’s an example of a case where you would have to do that unlearning?
Angela: One thing I ran into recently is I have a table and one of the columns, it’s essentially a list, a delimited list. Now, I would just normally parse that out, shove it into a separate table, call it a day. But trying to figure out, first of all, should I do that in Power Query, or should I do that in DAX? That was my first question. And then the second question was, “oh, well it’s super easy if I do it in Power Query, because I can just create a copy of the table, get rid of the stuff that I don’t want, add an index, tada! There it is.” But if I try to do that in DAX, it’s like, “oh, geez, my head hurts.” That’s my biggest one, because for me, coming from a DBA background, that’s a no-brainer. In a SSIS background, that’s a no-brainer. Very common pattern. But having to learn a new pattern to do that, that was painful.
Eugene: Yeah, something I see a lot of times is people want to be able to look at a row and say, “okay, I want to be able to reference the previous row.”
Angela: Oh, yeah.
Eugene: With SQL Server, ever since we had LEAD() and LAG() from 2012, that’s pretty simple to do, but in DAX, trying to do anything where you have this concept of previous or next row, you have to start using something called iterators, which are slower, and it’s just harder to work with and think of, where it’s so much easier for a lot of things, if you can think in terms of filters and unapplying them and reapplying them, and also the fact that it’s super easy to undo a filter. So, let’s say I want to do kind of like a slice of pie analysis. I want to be able to say, “okay, whatever product I’m looking at right now in my pivot table or whatnot, what percentage of total sales was that?” In DAX, it’s super easy to do that, because you can have one intermediary measure that’s just saying “all parentheses product” or whatever you want to undo for your filters, and you just divide the sum of your current sales by that amount, and so, unapplying filters is really, really easy to do. Whereas in SQL, the idea of doing an anti-WHERE clause just kind of blew my mind, because there’s no great way to do that. You’re probably looking at some sort of sub-query, or something along those lines. So I think those are some examples where it’s not easy to reference a previous row or think in terms of ordered rows at all, and the fact that so much of what you’re doing is dealing with filters, manipulating those, especially implicit filters. One of the things, too, is learning that when you have a pivot table, or you have a visual, there’s filters implicitly being applied, so if you do a bar chart by color, that bar is applying a filter on color and you can do stuff with DAX to manipulate that, to change that or what have you. It’s stuff that you may not normally think about at all when you’re dealing with SQL.
Carlos: Okay. So, technology’s always changing. Power BI is a great example of that, new feature every day, almost. And obviously, you’ve already emphasized, these are two different things. They may overlap slightly, but they have different purposes, so we’ll treat them individually, but from a future-state perspective, do you see both of these hanging around in Power BI? Are you already seeing something that, “well, we might not be doing this in December”?
Eugene: They’re definitely going to stay around for a couple of reasons. One is they do have a good complementary nature. It would be very hard to do the job of both with one or the other. Power Query, where it’s showing up is slowly expanding. A few months ago, they added support in Microsoft Flow for Power Query, so I feel like that’s expanding. I feel like tabular mode and DAX has become kind of dominant in the semantic space for Microsoft, because you look at Azure Analysis Services, they still haven’t added support for traditional multidimensional in MDX, so, I see the two staying around. With Power Query, what’s interesting is they’ve taken an extension approach, because right now, you can add in steps for R and Python instead of M to do some of that work. So, I could see that continuing to expand out in Power Query allowing you to pick more of the languages that you want to work with. But I see no reason for either to go away any time soon, at least in the Power BI space.
Carlos: So Kevin mentioned M, how does that fit into it? The landscape?
Kevin: Yeah, what is M and why is it a rip-off of F# that isn’t nearly as good as F#?
Eugene: Ooo, shots fired.
Kevin: Shots fired.
Eugene: Yeah. Well, because if you program in a functional programming language and you’re aware of it, then you have to have one of those thick-rimmed glasses with the bridge is broken in the middle and it’s taped together.
Kevin: Let me check my glasses.
Eugene: So M is like the cool, hip young brother of F#, because if you’re working with F#, you’re either in Quant and doing financial stuff, or you’re a giant nerd and so they had to appeal to all of the business users that didn’t want to be associated with that. So, that’s my immediate guess there.
Kevin: Says the guy right after talking about implementing another functional language within Power Query.
Eugene: Let’s see, do I have a serious answer to your question? So, M, you know, honestly, I don’t know 100% of why they designed it. I know why some of the benefits of the fact that it’s kind of this F#-like programming language, and that’s because it allows you to be more declarative and gain performance benefits that you wouldn’t be able to get from normally an imperative language. You think something like C# where you’re telling the engine, “do this, then this, then this, then this.” That’s an imperative kind of language. Whereas a functional language, a lot of that, you’re describing these functions and you’re just kind of chaining them together and some of the benefits of that is you can get these really cool optimizations. One of the things that’s common, and, correct me if I’m wrong on any of this, in functional languages, is lazy loading, or lazy evaluation, where the engine can look and say, “oh, well, we don’t actually need this information, so we’re not going to pull it.” Or, “we’re not going to process any of this until it’s actually called.” And so, for Power Query, that’s a big benefit, because if you do a bunch of work on a column and then later on, because you know, you’re not thinking things through, you remove that column, the engine’s not going to do all of that work. There’s lazy loading in M and actually one of the fun demos you can do is you can make a stored procedure that just calls like ‘wait for 5 seconds’ to simulate a slow-called procedure, and then at the last second, just get rid of any references to it and M’s smart enough that it won’t ever call that stored procedure anymore, even though it’s part of your workflow. It also supports something called query folding, where it can be really, really lazy in another way where let’s say you’re filtering on a column. It’s able to push that information down to the SQL Server and just write it into the SQL query, and so because it has a lot of these F#-like features, it can do a lot of optimizations under the hood that it wouldn’t be able to do if it had a lot of size effects or state or was touching the outside world a lot. Or if you were being very, very strict in telling it which way to do it, an imperative language is a lot like if you’re from the SQL Server world, working with cursors. You’re going through and iterating and that sort of thing, whereas it’s so much better if you can do it like SQL where you’re just saying, “get me this output and figure out the best way to get that to me.” But I don’t know why exactly they made all of the language decisions that they did.
Kevin: Yeah, as far as functional goes with M/Power Query, it’s a perfect space for it because, let me push up my tape-covered glasses.
Eugene: Yes, please.
Kevin: So, because functional programming languages, at their core, are basically about the data and the functions that transform the data, and not so much in the way of overhead. I contrast this, instead of imperative languages, to an object-oriented approach, where you’re thinking in terms of objects that you develop out and there tends to be a fair amount of boilerplate, even with POCOs or simple Java classes, where I’m still creating a lot of stuff around the data, just to do the thing I want to do with the data. And you can contrast that with a functional approach with, like you mentioned, “here’s a function or a couple of functions, and do some work with the functions, chain them together, build a pipeline,” which is more intuitively understandable than other approaches, “and give me out my results.” I don’t care so much about a coherent object model that I can reuse every place, because I’m not going to reuse the object model. I’m going to copy and paste a function that does what I want. But I’m not going to copy and paste an object model to another Power BI dashboard that’s 95% the same, but 5% different and now I’m maintaining a bunch of different object models. I had heard one time, I think, why they chose to go their own language route and I don’t remember understanding the answer, so I just keep bringing it up in a snide manner, because I figure someday someone’s going to lay it out straight for me and then I’ll get it and I’ll still keep bringing it up because F# is still better.
Carlos: There you go. I’m fairly certain that after they said, “well, we’re not using F#,” it was like, “ah, I don’t really care about the rest.”
Kevin: “Sorry, you guys made your first mistake.”
Carlos: Yeah, that’s right. Okay, well, good deal. So ultimately, this is the introduction-type conversation. What else do we need to be talking about, here?
Kevin: If I do want to learn about DAX, Eugene already mentioned that he’s got his Pluralsight course, and I think he secretly mentioned something about writing a book, and if he hasn’t yet, apparently, I’m going to force him into it.
Eugene: The book is not on DAX. I just got signed to do a book on Power BI for the SSRS developer, so I’m working on that, but yeah, if you want a book on DAX, get the purple bible by the Italians. I believe it’s called DAX Fundamentals or something along those lines. I’m sure we’ll be able to put it in the show notes.
Kevin: Yeah, so what about really getting into Power Query and M? any recommendations, there?
Eugene: Gil Raviv just released a book on that. It looked like it had a pretty good structure to it. I haven’t had a chance to read it. My criticism with the other two books that I’m familiar with, I think it’s M is for Data Monkey and geez, there’s one by Chris Webb on Power BI. My issue with those two is that they’re aimed squarely at that Excel audience that we talked about and so if you don’t live in Excel, a lot of that stuff isn’t necessarily relevant. Which is kind of true for Power Query in general, because one of the things I say to people a lot is, “if your data lives in SQL, half the stuff in Power Query is useless to you.” Like, let’s say OneDrive is your relational database and you’re stuck dealing with .csv files and that sort of thing, well, the problem is that let’s say you have a date and it’s 01/02/2019. Well, what date does that represent? Well, it depends where the .csv file came from. And so you have to figure out, “okay, did this come from Germany or Japan or America, and how do I need to format that?” Whereas, if it’s in SQL, you have a data type and you don’t have to do all of that legwork. The book that I recommend checking out is Collect, Combine and Transform Data Using Power Query in Excel and Power BI by Gil Raviv.
Angela: That’s a mouthful. But you know, if you put that on a visual in Power BI, it would word-wrap, now.
Eugene: That’s true.
Carlos: Okay, very good. I think that’s going to do it for today’s episode, compañeros. Ultimately, that idea of, we have two different technologies. Hopefully they’ve given you some guidance or some thoughts around why you’d want to use each one or what they can do for you. And if you have questions or comments, we’d obviously be very interested in hearing them from you. You can reach out to us on social media. But before we allow you to do that, I do need to say that our music for SQL Server in the News is by Mansardian used under Creative Commons. Again, our show notes page for today’s episode will be at sqldatapartners.com/powerbi. If folks want to reach out with you, Angela, how do they do it?
Angela: You can reach out on LinkedIn. I’m AngelaHenryDBA. And just mention that you heard us here, because I’m not on there very often and so I don’t want just some random person hitting me up on LinkedIn, because I’ll probably ignore you. Sorry, but that’s just the truth. Or you can get me on Twitter. I am sqlswimmer on Twitter.
Eugene: Yeah, so you can find me on Twitter at sqlgene and you can read my blog at sqlgene.com.
Carlos: Or wherever fine Pluralsight courses are found.
Eugene: Yes. Hopefully only one spot, occasionally on Udemy and other sites depending on piracy levels.
Carlos: And Mr. Kevin Feasel.
Kevin: You can find me on WeChat or whatever other Chinese social media platform is popular these days.
Carlos: Compañeros, I am at CarlosLChacon on LinkedIn or on Twitter and we’ll see you on the SQL Trail.