Excel reports sql server

Introduction

A few weeks back I had been working on an interesting proof of concept for a client within the food / grocery industry. The objectives were to be able to provide the client with information on sales patterns, seasonal trends and location profitability. The client was an accountant and was therefore comfortable utilizing spreadsheets. This said, I felt that this was a super opportunity to build our proof of concept utilizing a SQL Server Tabular Solution and by exploiting the capabilities of Excel and Power Reporting for the front end.

In today’s “fire side chat” we shall be examining how this proof of concept was created and we shall get a flavour of the report types that may be generated, simply by utilizing Excel.

In the second and final part of this article, we shall be examining the power of utilizing SQL Server Reporting Services 2016 to generate user reports.

However, before getting carried away with Reporting Services, let us look at the task at hand, that being to work with the tabular model and Excel Power Reporting.

Thus, let’s get started.

Getting Started

Our journey begins with the raw data. Opening SQL Server Management Studio 2016, we locate a database which I have called SQLSaturday554. In the screenshot below, the reader will note that we have the beer sales from major South Africa cities for several years.

We also have customer data within our “Customer” table (see below).

Last but not least, we have a “year month calendar table” (to add a time dimension) to our exercise (see below).

For our exercise, we shall be working with these three tables.

Creating our tabular model

Should you not have a tabular instance installed upon your work server, you may want to install one from the media supplied from Microsoft. One merely adds another instance and select ONLY the Analysis Services option and then the “Tabular” option. The install is fairly quick.

Should you be unfamiliar with the Tabular Model itself, fear not as we shall be working our way through the whole process, step by step.

From this point on I shall assume that we all have a tabular instance installed upon our work servers.

Opening Visual Studio 2015 or SQL Server Data Tools (2010 and above) we create a new project by selecting “New Project” under the Start banner as shown below.

The “Project Type” menu is brought up (see below).

We select an “Analysis Services Tabular Project” project (as shown above) and give our project an appropriate name. We click “OK” to create our project.

The “Tabular Model Designer” now appears (see below).

What the project wishes to know is to which TABULAR server and workspace we wish to deploy our model. We must remember that whilst our source data originates from standard relational database tables (for our current exercise), the project itself and the reporting will be based off data within Analysis Services.

We set the “Workspace Server” and test the connection as shown above. We click OK to create the model and we are then brought to our design and work surface (see below).

We now double click on the “Model.bim” icon, shown in the screen shot below.

The model designer opens (see below).

Adding data to our model

Clicking upon the “Model” tab on the menu ribbon (see below) we select “Import from Data Source”.

The “Table Import Wizard” appears (see below).

We select “Microsoft SQL Server” as shown above because our source data is from the relational database tables that we saw above. We then click “Next”.

We now select our “source” database server, our database and test our connection (see above). Once again, we click “Next”.

We must now set out “Impersonation Information” (see the screenshot above). In our case I have chosen to utilize a specific Windows user name and password. Once set, we click “Next”.

The system now wants us to select the relational tables that we wish to import into our model. We select the “Select from a list of tables and views to choose the data to import” option (see above). We then click “Next”.

We select the “beersales554” (Our sales figures), “Customer” (our list of clients), and “datee” (our time dimension) tables (see above) and then click “Finish”. The project will then begin the import into our model (see below).

Should our load was successful, then we receive the message shown above. We now click “Close”.

Our data will now appear within our design window (see the screenshot above). WOW, it looks like a spreadsheet. Those finance folks are going to love this!

Let the fun begin!!

The astute reader will note that in addition to the “Province”, “City” and “CustomerNo”, we also have a “yearmth” field and a field containing the Rand value of beer sales.

This breakdown is on a monthly basis and oft times folks wish to see results by quarter. GOTCHA!!!!

The one thing that we must remember is that now that we are working with the tabular model, calculations or defined fields cannot be created utilizing standard T-SQL. We must utilize DAX (data analysis expressions).

We select “Add Columns” (as shown above) and add our DAX expression

to the “function box” below the menu ribbon (see above).

The “Quarter” has now been created (see below).

Once again, the eagle – eyed reader will question the financial year calendar. Fear not, the same DAX expression may be used for a fiscal year starting July 1 and ending June 30^th. Such is the beauty of the DAX language.

We now rename the column to “Quarter” (See below).

Aggregating our “Amounts”

As “champions of reporting”, we all know that the decision makers will want to view reports which have aggregated results, by region and by time. This said we now aggregate our “Amount” field so that when we report from our tabular “cube”, the results will be aggregated at the appropriate level.

We place our cursor in any cell below our data display (see the blue highlighted cell in screen shot below). It should be understood that “any cell below the data is adequate”.

We now create the DAX formula to aggregate the data.

The DAX formula is created in the same function box that we utilized for the “Quarter”, and a grand total will display in the blue cell (shown below).

It should be remembered that at this point in time that the result is meaningless as we have not linked “Amount” to our date and customer dimensions 🙂

We shall now create these linkages by clicking on the “Diagram” box located at the bottom right of the screen shot below (see the red circle).

Having clicked upon the “Diagram /Relationship” icon (discussed imediately above), we are brought to the “Relationship” work surface.

We note that our three tables /entities are displayed (see above). We now create the necessary relationship links by dragging the corresponding fields within the Customer entity to the customer number within the BeerSales entity. We do the same for the “Datee” entity (see below).

This completes the development portion of our exercise. The only thing remaining is to deploy our model.

Deploying our model

To begin the deployment process we must set a few properties.

We click on the “Project” tab on the menu ribbon and select “Properties” (see above).

The “Properties” dialog box is now displayed (see below).

We set the TABULAR Analysis Server name and set a name for the target database that will reside on the Tabular Analysis Services server. In our case the server is “STR-SIMONSTEVE2016TABULAR” and the database name will be “SQLShackTabularBeer” (see above). We then click “OK”.

Our next step is to “Build” our solution prior to deploying it. This step will help detect any errors or other issues. We simply right click the project name and select “Build” (see below).

We are notified our the status of our “build” as may be seen in the screen shot below:

Having “Built” the solution, we are now in a position to deploy our solution and create our Analysis Services tabular database.

Once again we “right click” on the project name and select “Deploy” (see below).

The “Impersonation” dialog box is displayed as may be seen below:

We pass the necessary credentials to the system (as we have done above) and deployment commences.

With deployment successful, we now closed Visual Studio or SQL Server Data Tools 2010 and we shall go back into SQL Server Management Studio, however this time into our Analysis Services tabular instance.

Verifying that our database has been created

Opening SQL Server Management Studio we select our Analysis Services tabular instance.

Expanding the database tab, we note that our database has been created (see below).

Expanding the SQLShackTabular database tab we find our three tables.

We can now run a few simple DAX queries to ascertain if our results look reasonable. DAX is an amazingly powerful “beast”. It is complex to learn and understand, and this is beyond the scope of this article. Enough said, let us get busy with those small test queries!

We simply open a new query by selecting the “New Query” button on the banner. The query editor now opens (see below).

Using a very elementary DAX statement, we shall calculate the total beer sales by our client base,

The DAX statement is

When we execute this query we obtain the following results (see below).

The eagle – eyed reader will have noted that the values for all customers appear the same and that is because we requested the “GrandTotal” be displayed with each customer (which is really not that informative, to say the least!).

Changing the query slightly by adding the Customer Name and utilizing the “Amount” field instead of the “GrandTotal”, we can now see the total sales for the whole period for all customers (customer by customer).

The code to achieve this is below as is the result set.

In short, working with DAX is similar to working with MDX. It has its rules and ways of traversing the data tree and is frankly not for the faint of heart.

This said, let us have a look at reporting based upon our tabular model.

Reporting

For today’s reporting exercise, we shall be utilizing Excel. In part two of this article, we shall be utilizing SQL Server Reporting Services.

Opening a new workbook, we click upon the “Data” tab and select “From Other Sources” (see below).

We select “From Analysis Services” (see below)

The “Data Connection Wizard” now appears. We configure this to point to our Tabular Analysis Database (see below).

We click “Next”.

The next screen shows our Model that we created in Visual Studio or SQL Server Data Tools (see below).

Having selected our database, we click “Next”.

We now save our data connection and click “Finish” to complete the connection process (see below).

Having achieved all of this, we are now at the stage where we can import all the data that we have assembled (see below). We shall accept to create a “PowerTable” report for this exercise and click “OK” (see below).

Having completed this we find our work area looks similar to my view shown below:

This is where we are going to work our magic!!

We shall drag the measure “GrandTotal” (see above) which now appears among the Pivot Table Fields and which originates from our Visual Studio / SQL Server Data Tools project; onto the Pivot Table (occupies cells A1 to C18) (see below).

To this we now add our “CustomerName” from the customer table. Our canvas appears as follows:

Now let us look at the financial year 2013 solely to see the results for those clients listed above. To achieve this, we add a filter to the “Filters” box seen above and enclosed within the circle.

The change in the values may be seen in the following two screen shots.

and

Now naturally we could have chosen any year, the point being do note that because the values are aggregated by a “date time”, changing the “what if” scenario is fairly easy and rapid.

We take our exercise one step further by inserting a Pivot Chart. This is achieved by selecting “Insert“ from the main menu ribbon. We select a “Pivot Chart” (see below).

The results may be seen in the following screen shot.

The screenshot above shows a bar chart and the following screenshot as simple line graph

Our final report appear below and is quite comprehensive.

It should be noted that once the filters are removed or altered (within the matrix), that both the chart and the line graphs will reflect the changes as may be seen below.

Demographic Consumption

Now what would be interesting is to view the sales relative to geography.

To do so we shall utilize “Power Map”. Before we can do this though we must add these tables to our data model within our Excel Workbook.

We click upon the PowerPivot tab and select “Manage Data Model” as may be seen below:

The blank “Manage Model” worksheet appears (see below).

We click the existing connection to create a “View” from the tables in the Tabular Model that we created (see below).

We click “Open” and note that Excel shows us the necessary connection string which will enable us to “communicate” with our Analysis Services database.

The next step in the process is a real GOTCHA and the author has been caught on this one numerous times. The following screen appears asking for a MDX expression with which to work. “What the heck!!!”

We simply click the design button and the contents of our cube automatically appear (see below).

Dragging our “Grand Total” field, the province, the city, the quarter onto our work surface we now have the following view.

We click OK to accept our data choices whose data originates from the BeerSales554 and customer tables. The wonderful thing is that the MDX expression from our field selection is now displayed in that blank MDX expression box, as may be seen below:

The MDX expression is also shown below.

We click “Finish” and the system imports the necessary raw data (see below).

We close the “Table Import Wizard” and ascertain that our data has been imported as may be seen below:

We “Save”, “Close” and “Exit” (see below).

We are now in a position to create our “Power Map”!

We select “Insert” from the main menu ribbon and click “Map” and “Launch Power Map”.

Opening Power Map we are greeted with our drawing surface (see below).

We now set the “Geography” by clicking on the City field within the “Choose Geography” box (see above).

We note that upon doing so that the map changes to show southern Africa.

We click the “Beersales554CityCity check box and the cities for which we have data are now visible on the map.

Our next task is to plot the amount of sales that were recorded. We click “Next”.

By checking the “MeasureGrandTotal” box we see the value of the total sales (see above) and by adding a time dimension, we can gage beer sales for the period of time under consideration (see below).

These types of charts are extremely useful to the decision maker who really wants to understand seasonal fluctuations and their effect on the bottom line.

Once again we have come to the end of our “get together” and I sincerely hope that this project has stimulated you, the reader, to try some topics that we have discussed. I honestly believe that you will be surprised.

Conclusions

Decision makers oft times are faced with difficult decisions with regards to corporate strategy and the direction and correction that must be made in order for the enterprise to achieve its mission and objectives. Many of today’s decision-makers have had extensive experience utilizing Microsoft Excel and it often gives them a “feeling of comfort”. The SQL Server Tabular project projects the “spreadsheet” image and often installs confidence in those that take advantage of its capabilities. While Excel is merely one manner in which data may be turned into information, SQL Reporting Services may achieve the same results, and in the second and last part of this series, we shall be utilizing this same project however our reporting will come from our Reporting Server.

In the interim, happy programming.

See more

For SQL Server and BI documentation, consider ApexSQL Doc, a tool that documents reports (*.rdl), shared datasets (*.rsd), shared data sources (*.rds) and projects (*.rptproj) from the file system and web services (native and SharePoint) in different output formats.

References:

• Microsoft Power BI Blog
• Automated administration across Multi-server environment
• Event forwarding between target and master servers

By Ryan Lambert — Published April 03, 2015

Let’s imagine that you have a database that contains some data in it that you want to share. Maybe you’ve inherited a SQL Server database and want to provide some basic reports to other users. Does that scenario sounds somewhat familiar?

Add Data to SQL

If you aren’t interested in creating the test database, feel free to skip this section by scrolling down until you see the chart. My feelings won’t be hurt, I promise!

To create a report in Excel using data in SQL, so we need some data to query against, and before we can have data, we need tables. Let’s create an employee and sales table.

CREATE TABLE dbo.employee
(
    employeeID INT IDENTITY NOT NULL PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    title VARCHAR(100) NOT NULL
);

CREATE TABLE dbo.sales
(
    salesID INT IDENTITY NOT NULL PRIMARY KEY,
    employeeID INT REFERENCES dbo.employee (employeeID),
    amount NUMERIC (6,2) NOT NULL,
    sale_date DATETIME NOT NULL DEFAULT GETDATE(),
);

Now insert some data. The first part is a straightforward INSERT statement to create the employees of this family ran sales business. The second part loops through and inserts 500 sales records to random employees. Change the @loop variable if you want to add more or fewer records, keep in mind more records will take more time.

INSERT INTO dbo.employee (name, title)
    VALUES
    ('Bob Smith','Sales Manger'),
    ('Jane Smith','Sales Associate'),
    ('Susan Doe','Sales Associate'),
    ('Suzy Salamander','Sales Associate'),
    ('Walker Texas-Ranger','Sales Cowboy'),
    ('John Doe','Sales Associate')
GO

DECLARE @i INT = 0;
DECLARE @loop INT = 500;
DECLARE @employeeID INT;
DECLARE @amount NUMERIC(6,2);

WHILE @i < @loop
BEGIN
    SELECT @employeeID = employeeID FROM dbo.employee ORDER BY NEWID();
    SELECT @amount = (RAND() * 10) + (RAND() * 100) + (RAND() * 150);
    INSERT INTO dbo.sales (employeeID, amount)
        VALUES (@employeeID, @amount);
    SET @i = @i + 1;
END
GO

Query Data

Now we have some data in our sales and employee tables so let’s run a query to get sales by employee.

SELECT e.name, e.title, SUM(s.amount) AS totalSales
    FROM dbo.sales s
    INNER JOIN dbo.employee e
        ON s.employeeID = e.employeeID
    GROUP BY e.name, e.title
    ORDER BY SUM(s.amount) DESC

You should see something like the following results, the totalSales will obviously vary.

Now you could copy and paste those results in Excel and make a chart off the data manually and you might end up with something that looks like this:

We could do that manually each day, week, or hour that they want the report updated, or we could automate away a lot of that headache.

Manual Processes Suck

I don’t like copying and pasting things. In my opinion, that’s low hanging fruit for automation! Below I include some VBA to help automate reports from SQL. You don’t have to “know” VBA to get this to work, the changes you have to make to the code should be minimal.

In Excel 2007 you now must save the file as a “Macro Enabled Workbook” that gets the file extensions “.xlsm”. You can find this option when you do “File > Save As”. In older versions of Excel they’re still stored in the same .xls files as regular files. To access the VBA editor in any version of Excel hit “Alt + F11″.

Don’t forget References

Because I know we’re going to be using the ADODB library, we need to add that to VBA’s references. This is done in the VBA editor under “Tools > References”. In the dialog that comes up, find and check the “Microsoft ActiveX Data Objects 2.8 Library” then click “Ok”. Without this, VBA will throw an error on the first line that references ADODB.

On the left hand side of the VBA editor, Right click on the VBA Project that contains your file’s name in it then select “Insert > Module”. Your “project” now has a module named “Module1″. Rename the module to “SQL” in the name field of the properties pane shown at the bottom of the screenshot.

Now copy and paste the VBA code below into the code editor of your SQL module. Update the values for “db” and “srv” to match your environment. If you don’t know what values to put there, ask your database administrator. This assumes you’re using Windows Authentication to control access to MS SQL Server. Check out the code, I’ll explain after.

Option Explicit

Sub RunQry(dest As Range, SQL As String)

    Dim conn As New ADODB.Connection
    Dim cmd As New ADODB.Command
    Dim rs As ADODB.Recordset
    Dim connString  As String
    Dim db As String
    Dim srv As String

    ' Update the values between the double quotes (" ") to match your database server and name.
    db = "YourDatabaseName"
    srv = "YOURSQLSERVER"

    connString = "Provider=SQLOLEDB;Initial Catalog=" & db & ";Data Source =" & srv & ";Integrated Security=SSPI"
    conn.Open connString
    Set cmd.ActiveConnection = conn

    cmd.CommandText = SQL
    cmd.CommandType = adCmdText
    Set rs = cmd.Execute
    dest.CopyFromRecordset rs

    rs.Close
    conn.Close
    Set rs = Nothing
    Set conn = Nothing

End Sub

The RunQry module accepts two parameters, a Range for the returned data to be stored at and arbitrary SQL code to be executed. It creates an ADODB connection and executes the SQL query passed to the method against the server and database defined. The results from the executed SQL are then pasted at the range defined as a starting point.

Warning: This has potential security implications. Queries must be designed
with SQL Injection in mind!
Don’t ever pass raw text from the user in as query
parameters without sanitizing them first! Ideally users have very limited
permissions, and are limited to only executing stored procedures!

Execute our Query from Excel

Now that we have the SQL module with a RunQry, we can call it from other code and simply tell it what query to run, and where to put the data. Create a new module by right clicking on the Modules folder icon and again “Insert > Module” and name this one “main”.

Paste the following VBA code into the main module. Notice that I created a stored procedure in SQL Server to execute the sales by employee query because I hate having multi-line SQL escaped in VBA. This provides a cleaner and more secure approach.

Option Explicit

Sub run_sales_query()
    Dim data_start As Range
    Dim sql_qry As String

    ' Change to clear out the number of rows/columns your data will fill
    Sheet1.Range("A6:C20").Clear

    ' Change to move where data is placed
    Set data_start = Sheet1.Range("A6")

    ' Perfect example of why stored procedures are better for this!
    sql_qry = "EXEC dbo.getSalesByPerson"

    Call SQL.RunQry(data_start, sql_qry)
End Sub

The code pastes the results from our query (without headers) to cell A6 on Sheet1. This will leave room for the Refresh button above the data. I also manually add the headers above the data (row 5) since they don’t come in with the results from SQL.

To test run the report hit “Alt + F8″ and run the run_sales_query macro.

An error that highlights an ADODB line is probably a missing reference!
The sql_qry variable can be set to any regular SELECT or EXEC statement that returns data. I recommend always retrieving data from stored procedures, but hey, that’s just me!

SQL Enabled Report

I added a simple button that triggers the run_sales_query module to refresh the data. I can now add to the sales data by running a couple thousand more sales transactions (see the Loop code above) and see the updated report by simply clicking the “Refresh Data” button. Pretty slick!

Final Thoughts

As your reports grow beyond more than one simple query, I find it’s best to have each distinct query going to its own dedicated worksheet to avoid potential overlap of data. Create your various polished reports for display that have links to the raw data worksheets. When the polished reports are ready, the raw data worksheets can be hidden to clean up the file. You can get fancier by providing drop down menus, but that’s beyond the scope of this post.

By Ryan Lambert
Published April 03, 2015
Last Updated April 17, 2015

Export SQL Data to Excel from Microsoft SQL Server

Let’s go over three ways to export an SQL Query to an Excel File Using MSSQL 

Despite the pushback from Database aficionados, sometimes it makes sense to export data from SQL to an Excel file. It really depends on who is the audience of the information. Not everyone is great with SQL Analysis. Few people require access to the database.

And lots of times the boss just needs to see the information in Excel.

So, if Excel is the Output required this article is here to help you Export SQL Queries to Excel. 

Here are three ways to Export a SQL query to Excel format. The last one can be kind of tricky. I’ll provide a condensed version followed by a detailed version with screenshots.

Three quick ways to Export SQL Data to Excel:

Choose the Summarized Version and then scroll to further down to use the SQL Export Version to Excel that works best for you. 

Method Number 1 – Copy Grid results and Paste into Excel

Under Query, Make sure results to Grid are selected.
After Running your query, right-click the top right corner of the grid.
Copy With Headers.
Paste into an Excel File

Possible Issues:
I’ve seen formatting issues with this strategy. For Example, there are situations where the spreadsheet drops preceding zeroes after the copy-paste.

I’ve also noticed lengthy fields, (think of a really long free text field) end up running into the next line.

For the reasons above, I prefer this next method for a clean Excel file.

Method Number 2: Export the Query Results as a Task

In the object explorer window, find the database you want to export from.
Right Click the Database, Click Tasks, and Export Data
The Wizard walks you through the rest of the steps but I have included screenshots below.

Method Number 3 – Use Good Old fashioned TSQL to send the data to an excel file

For those who value speed above all use the following script format.

Possible Issues – Configuring this might not be your type of fun and getting this straight deserves its own article.

Step by Step instructions with screenshots

Method Number 1 – Copy Grid results and paste into Excel

After ensuring results to grid turned on, Execute your query, right-click the top left-hand corner of the results grid.

Choose Copy with Headers and then you are ready to paste in Excel with Ctrl + C

Method 2 – Export Via the Export Wizard

Right-click on the database you want to export from. Then Select tasks and “Export Data”.

The SQL Server Wizard will startup. Click Next through the prompts.

Select the appropriate Native client, your server name, and database and choose “Next”.

Next, Select Microsoft Excel and the file path where you want to import the data. The .xls file that you name will be created by this process.

Now you can choose to export a whole table or a query. For the purpose of this exercise, we are creating a query.

Paste the query into the SQL Statement field. Make sure every output field has a unique name.

Click Next on the “Select Source Tables and Views” screen.

I use the default settings on the “conversion issues and data type mapping screen”

Now you can choose to Run immediately or Save an SSIS Package for later reuse.

Double Check your settings and click finish.

Make sure there were no errors in the Export.

Now Go to the directory you choose earlier and make sure you have a sweet-looking Excel File at that location!

Method Number 3 – Use TSQL to send the data to an excel file

This method is the quickest once you get it set up but the configuration is the tricky part. Permissions can be a limiting factor.

Also with the script below, you have to make sure the file exists before you run the query for it to import properly.

First, create a blank excel file at the directory of your choosing.

C:SQL2019ReportsUsernames.xlsx

Then run this script below.

INSERT INTO OPENROWSET(‘Microsoft.ACE.OLEDB.12.0’,’Excel 12.0;
Database=C:SQL2019ReportsUsernames.xlsx;’,’SELECT * FROM [Sheet1$]’)
SELECT DisplayName FROM dbo.Users Where Reputation > 2000

Configuring this can be tricky and dependent on your level of permissions. Make sure you have the correct Linked Server/Provider installed (‘Microsoft.ACE.OLEDB.12.0’) And check your Database user settings to this server .