Displaying Power Pivot Calculated Measures in Alphabetical Order

Sharing a quick tip I got the other day from Meagan Longoria...

See in this screen shot how the calculated measures are being displayed in random order in the PivotTable Field List? If you have a long list of measures, this can be a wee bit aggravating.


To fix it, click the gear symbol towards the top right of the PivotTable Field List. Change "Sort in Data Source Order" to "Sort A to Z."


And with that, we have a much more usable list to work with.


Parameterizing Connections and Values at Runtime Using SSIS Environment Variables

This post discusses how to parameterize connection strings and values at runtime using SSIS environment variables. Although it may seem like a lot of steps, it's a one-time setup per environment and makes your SSIS projects very portable and allows for easier manageability of dynamic values that change routinely.

Applicable to: SQL Server 2012 or 2014. Screen shots shown are from SQL Server 2014.

What are SSIS Environment Variables?

SSIS Environment Variables provide the mechanism to set values at the time a package is executed. This functionality is useful for any number of things, frequently for specifying different values between Dev, QA, and Prod environments.

Note that these SSIS environment variables are a different thing than Windows environment variables, although similarly named. They're also different from "regular" variables inside an SSIS package. 

This technique is applicable to SQL Server 2012 and up, and only to the project deployment mode (i.e., not package deployment mode). The concept of SSIS Configurations is no longer applicable with the project deployment mode as they've been replaced with SSIS Environment Variables. If you're just getting familiar with these concepts, please check out this overview: Getting Started with Parameters, Variables, and Configurations in SSIS 2012 (the overview blog entry has gotten to be one of my most visited pages so I figure that's a clue that I should write more on the subject, eh?).

Steps for Using SSIS Environment Variables to Parameterize Connection Strings and Values When the Package Executes

SQL Server Data Tools (SSDT) - Integration Services Project
Step 1:  Create Parameters (Project or Package level as appropriate) and associate expressions, source queries, etc to these Parameters as appropriate.
Step 2:  Parameterize connection strings.
Step 3:  Deploy Project to the SSIS Catalog once package executes as desired within SSDT.

SQL Server Management Studio (SSMS) - Integration Services Catalogs>SSISDB
Step 4:  Create Environment & set up Variables within the Environment. These should coincide with the Parameters from the SSIS project.
Step 5:  Configure each Project (and Packages individually, if needed).
Step 6:  Execute package in SSMS via the Catalog. Will need to manually specify which Environment to use at execution time when running in this on-demand manner.
Step 7:  Create Agent Job to execute on an ongoing basis. Associate the job to the appropriate Environment so it automatically detects values which have been set.

Details for each step are below.

Step 1: Create Parameters and Associate Expressions to the Parameters (SSDT)

First thing to do is determine what elements of the package you wish to be able to vary at runtime. Or, in other words, what may need to be changed by the DBA or system admin without the SSIS developer needing to make a change in SSDT and redeploy the package.

In the example below I have 2 project-level parameters that signify a date range. Since this date range would apply to multiple packages, I made these project-level parameters rather than at the package-level:

Sidenote: in the real world, this generic name of "data extract..." would be too vague. As you'll see below, the SSIS environment variables on the server are shared across all projects, so that may influence your naming conventions if you have numerous projects to manage.

And here's an example of how a source query in my data flow has been associated to the project parameters:

Usually an SSIS project of any size ends up with at least a few project/package parameters, but it is possible that you don't have any.

Step 2: Parameterize Connection Strings (SSDT)

Note that there's a couple of different ways to handle changes to connection strings as you migrate from Dev to QA to Production. This describes one way to handle connections by grouping them with parameters.

I ensure that all connections are project level (not package level) and then I like to parameterize each of my connection strings:

In this example I've parameterized the connecting string itself. You can parameterize individual properties like server name, user name, catalog, if you prefer. This connection string is using Windows authentization so it's not set to sensitive (if it were a password you'd want to set it to sensitive so that it's encrypted).

I do like to set it to be Required which ensures it will be set in the SSIS Catalog before the package can be executed on the server.

Once you have parameterized your connections, you'll see them in the parameters pane. 

Step 3:  Deploy Project to SSIS Catalog

For deploying to Dev, I usually just right-click the project in SSDT and deploy to the Catalog from there.


For deploying to other environments like Prod, where you may need to hand off the deployment to someone else, I typically make use of the ISDeploymentWizard tool instead. Details on this can be found here: http://msdn.microsoft.com/en-us/library/hh231102.aspx.

Step 4:  Create Environment & Set Up Each Variable (SSMS)

Once you've deployed your project to the SSIS Catalog, you'll be able to see it in SQL Server Management Studio.


Next we want to create a new SSIS Environment (assuming it doesn't already exist). Environments are usually called Dev, QA, Prod, that sort of thing, but they could of course be used differently in some situations.

For setting up new variables within the SSIS Environment, you want to have SSDT open as well as SSMS. Copy and paste the name & value for each parameter from the SSDT parameters window into the SSIS environment variable window (note: I tend to use an EV prefix but that's just a personal preference). Modify any of the values if different on the server than were used in SSDT.

Step 5:  Configure Each Project (SSMS)

At this point we have an SSIS environment available with variables specified that coincide with our parameters. Now we're ready to let the project know that the environment exists (and which one to use, if there are multiple environments on the same server).


On the parameters page, we can associate each parameter for the project to the environment variable that was set up. In this example I kept the scope at the project level, but you can set them at the individual package level when appropriate.

In the screen shot above, you'll see there's one package-level parameter that is just set to "Yes." When you see this, you might be tempted to just set the connection values here too and not bother with referencing them to the SSIS environment variables. If you only have one or two projects, that method would be ok. However, if you have a larger number of SSIS projects that all make use of shared parameters and/or database connections, you'll find great benefit in changing the values of an SSIS environment variable once and allowing it to affect all projects.

Step 6:  Execute in SSMS Via the Catalog (SSMS)

At this point, everything is set up. Let's run it in SSMS to see if it works. 


Initially, you see alerts because SSIS doesn't presume to know which environment to use (even if only one exists). So, you want to check the box and choose the correct environment - this will always be true when a package is run on-demand like this.

Step 7: Create Agent Job and Associate Job to the Environment (SSMS)

Our last step is to set up an Agent job to run the package on a schedule. 


I won't go into detail on settings for the Agent job, but the key to bringing it all together is on the Configuration page where you specify which Environment the job should use.

Note that you can also specify a parameter value directly within the Agent job. In most situations I wouldn't do this since it could be confusing if different than the environment variable or the project configuration, but it is nice flexibility to have if used with caution.  

You Might Also Like...

Getting Started With Parameters, Variables & Configurations in SSIS 2012

Big Changes - What You Need to Know About the Power BI Public Preview

Yesterday Microsoft released a Public Power BI Preview for customers to evaluate new features in Power BI. This newly redesigned platform offers many familiar components, as well as some new and unique features. Which means you may be asking yourself what this new preview means to your current or prospective Self-Service BI initiative now that there's an additional choice available.

Head on over to the BlueGranite blog to keep reading...

Power Pivot Update and Issue with Relationships Between Tables

Yesterday the Power BI team released a fantastic new update that improves the usability of Power Pivot inside of Excel. I'm thrilled with what I've seen so far as it removes a lot of the delays when making changes to the data model.

However...I have noticed one issue since the update. This morning I created a simplified data model in order to create a Power View demo for a customer who's not yet familiar with Power View's interactivity behavior. When putting together a sample Power View report I noticed the dreaded "Relationships between tables may be needed" message. 


There are times this message is accurate and expected (such as when you're purposely using disconnected tables). However, in this case, I knew something was wrong. Upon checking the Diagram View for the model, sure enough, the arrow was pointed in the wrong direction.

Prior to the update, I believe Power Pivot would reverse the arrow of the direction for you if it detected that you dragged it the "wrong" way -- i.e., it wants to point to the dimension table / lookup table / table with distinct set of values. So, I deleted the relationship and dragged it the correct direction and all was well.

So, keep an eye out for that behavior on the direction of the relationships.

You'll know you have the December update with the performance improvements if you are on 15.0.4675.1002 (File > Account).


Update 12/18/2014: It seems the "Relationships" message is also displaying sometimes when it's not truly applicable - ex: I'm seeing it when one explicit calculated measure from a single table is the only thing that has been added to a pivot table & I'm absolutely certain the relationships are defined accurately. 

You Might Also Like...

Getting New Power Pivot Features and Other Office 2013 Updates