The C.R.U.D. of Excel

Phil and I have teamed up on this workbench, which demonstrates how to create, read, update and delete information in Excel using T-SQL, from SQL Server. As always, the workbench is structured so that it can be pasted into Query Analyser and SSMS, and the individual examples executed – you can download the .sql from the “Code Download” link at the bottom of the article, load it up and start experimenting!

Contents

• Creating Excel spreadsheets via ADODB
• Manipulating Excel data via a linked server
• Synchronising the Spreadsheet with SQL Server Tables
• Manipulating Excel data using OPENDATASOURCE and OPENROWSET functions
• Creating Excel spreadsheets using sp_MakeWebTask
• OLE Automation

We start by showing you how to create an Excel Spreadsheet from SQL Server in TSQL(Transact SQL), create a worksheet, attach to it as a linked server, write to it, read from it, update it as if it was an ordinary SQL Server Database table, and then synchronise the data in the worksheet with SQL Server. We also illustrate the use of OPENQUERY, OPENDATASOURCE and OPENROWSET.

To create the Excel spreadsheet, we show how to attach to an ADODB source from SQL Server and execute SQL against that source. We then show you an alternative ‘quick cheat’ way (using sp_makewebtask) to create and populate an Excel spreadsheet from Transact SQL.

If you need more control over the Excel Spreadsheet that you are creating, we then show you how to do it via OLE automation. This will enable you to do anything you can do via keystrokes, and allow you to generate full Excel reports with pivot tables and Graphs.

Using this technique, you should be able to populate the data, or place data in particular calls or ranges. You can even do ‘macro substitutions’.

A word of caution before you start. If you have your security wide open, it is not just you who would be able to write out data as a spreadsheet. An intruder would be able to do it with that list of passwords or credit-card numbers. In a production system, this sort of operation needs to be properly ring-fenced. We tend to create a job queue and have a special user, with the appropriate permissions, on the Task Scheduler, to do anything that involves OLE automation or xp_CMDShell. Security precautions can get quite complex, but they are outside the scope of the article.

Some of what we illustrate can be done using DTS or SSIS. Unfortunately, these are outside the scope of this article. In fact, transferring data between Excel and SQL Server can be done in a surprising variety of ways and it would be fun one day to try to list them all.

First we need some simple test data:

And so on. (The full import file is in the ZIP, as is the Excel file!).

Create the table and then execute the contents of CambridgePubs.SQL.

Creating Excel spreadsheets via ADODB

First, we need to create the spreadsheet with the correct headings (PubName, Address, PostCode).

There are two possible ways one might do this. The most obvious way is using the CREATE statement to create the worksheet and define the columns, but there seems to be no way of doing this by linking the Excel file, unless the Excel file already exists. We need a utility stored procedure to get at ADODB in order to create databases and execute DDL and SQL against it.

Now we have it, it is easy.

The Excel file will have been created on the Database server of the database you currently have a connection to.

We could now insert data into the spreadsheet, if we wanted:

Manipulating Excel data via a linked server

We can now link to the created Excel file as follows.

To drop the link, we do this!

So now we can insert our data into the Excel spreadsheet:

INSERT INTO CambridgePubDatabase…CambridgePubs

(Pubname, Address, postcode)

SELECT Pubname, Address, postcode FROM ##CambridgePubs

Synchronizing the Spreadsheet with SQL Server tables

As we are directly manipulating the Excel data in the worksheet as if it was a table we can do JOINs.

What about synchronising the table after editing the Excel spreadsheet?

To try this out, you’ll need to DELETE, ALTER and INSERT a few rows from the Excel spreadsheet, remembering to close it after you’ve done it.

Firstly, we’ll delete any rows from ##CambridgePubs that do not exist in the Excel spreadsheet.

Then we insert into ##CambridgePubs any rows in the spreadsheet that don’t exist in ##CambridgePubs.

All done (reverse syncronisation would be similar).

Manipulating Excel data using OPENDATASOURCE and OPENROWSET

If you don’t want to do the linking, you can also read the data like this:

You can read and write to the Excel sheet using OpenRowSet, if the mood takes you.

Creating Excel Spreadsheets using sp_makewebtask

Instead of creating the Excel spreadsheet with OLEDB One can use the sp_makewebtask.

Users must have SELECT permissions to run a specified query and CREATE PROCEDURE permissions in the database in which the query will run. The SQL Server account must have permissions to write the generated HTML document to the specified location. Only members of the sysadmin server role can impersonate other users.

This is fine for distributing information from databases but no good if you subsequently want to open it via ODBC.

OLE Automation

So far, so good. However, we really want rather more than this. When we create an Excel file for a business report, we want the data and we also want nice formatting, defined ranges, sums, calculated fields and pretty graphs. If we do financial reporting, we want a pivot table and so on in order to allow a degree of data mining by the recipient. A different approach is required.

We can, of course, use Excel to extract the data from the database. However, in this example, we’ll create a spreadsheet, write the data into it, fit the columns nicely and define a range around the data.

GO

Now we can create our pubs spreadsheet, and can do it from any of our servers.

Or if you are using integrated security!

Although this is a very handy stored procedure, you’ll probably need to modify and add to it for particular purposes.

We use the DMO method because we like to dump build data into Excel spreadsheets e.g. users, logins, Job Histories. However, an ADODB version is very simple to do and can be made much faster for reads and writes.

We have just inserted values, but you can insert formulae and formatting numberformat) and create or change borders. You can, in fact, manipulate the spreadsheet in any way you like. When we do this, we record macros in Excel and then convert these macros to TSQL! Using the above example, it should be simple.