Export Access Data to Excel
How to use VBA to export to Excel workbooks data from Access query datasheets and to format the worksheets once the data have arrived.
Last updated on 2018-04-13 by David Wallis
For many of the databases I develop I include an export-to-Excel capability. This is for clients who want the means of dumping data so that they can do their own thing without needing me to make changes to the database and without risk to the data it contains.
Quite often an export in itself is acceptable as a full report, thus avoiding time devoted to the creation of a carefully formatted Access report. Also, on occasions, the export serves as a useful check that the assembled records contain exactly what the client needs, prior to creation of a full-blown Access report.
This article describes a VBA procedure for dumping data from Access into Excel. It goes beyond a simple account of the DoCmd.TransferSpreadsheet method that you see in many websites covering this topic.
Compounded from client requirements over the years, I've identified these are the main features of an export-to-Excel capability:
- Automated export of data sets from queries
- Export directed to workbooks in folders of the client's choice
- Automated formatting of worksheets on completion of an export
- The possibility of users creating their own queries.
All DMW databases supplied to clients are split — FE (Front End) and BE (Back End). FEs contain queries, forms, reports, macros and modules, and, as appropriate, a table or two, as I'll explain below. BEs contain tables only.
From the viewpoint of a developer, these are my considerations:
- Users not to be allowed to modify the structure of the BE
- Users not to be allowed to alter the FE
- Provision for users to create their own queries
- Provision for incorporation of users' own queries into FE
- Give suitable control of the process to the client's IT.
Were users to be allowed to tinker, it would be an impractical and time-consuming task for me providing upgrades and on-gong support to the client. The client would not be happy with the bill.
VBA TransferSpreadsheet Method
The procedure dmwExport uses the bare bones of the TransferSpreadsheet method to export the contents of a table, or of a query datasheet, as a named Excel file to a named folder:
dmwExport("qsResults", "S:\Reports\Results.XLSX"), for example, exports the contents of the query qsResults to the folder S:\Reports\ as an Excel file named Results.XLSX.
Opening the Exported Workbook
dmwExport creates the workbook and saves it, but it doesn't display the completed workbook. Experience suggests that most users want to see the results of the export as soon as it's complete.
At this point we will include error handling and make sure that the procedure releases any connection with Excel once it has presented the workbook:
Path and Workbook Naming
You need to take care when supplying values to the path$ argument of dmwExport(query$, path$). Consider these values:
"S:\Reports\Results.XLSX" This works satisfactorily — the Workbook named Results.XLSX is directed to the S:\Reports\ folder.
"S:\Reports\Results" This works satisfactorily too — the procedure attaches the .XLSX extension to the workbook's name so that Results.XLSX is directed to the S:\Reports\ folder.
"S:\Reports\Results\" Here the problem arises that the final \ causes the procedure to treat S:\Reports\Results\ as a folder, without specifying any workbook at all, with resulting error conditions, eg —
If there's call for it (let me know), I shall add some code to contend with the issue. The full-blown export program described below incudes such code.
Providing for Folder Changes
In my experience, clients like to be able to determine for themselves to which folder the export process directs the workbooks it creates. Also, they want to be able to change that folder without needing to get me to tweak any code. This is a particular requirement when a client's IT want the freedom to change locations for files on a network and re-map drives.
Over the years, I've tried a number of ways of providing for this, currently settling with a method that uses an addition to the two main FE and BE files. This third file I name KEY.ini, which is a simple text file, the content of which is this:
Now we need to accommodate KEY.ini into the export process. The process must pick out the export path from KEY.ini.
In tune with good practice we are going to structure our programming by separating our code into a number of sub-routines. Each of these will perform a distinct operation, one of which will be the picking from KEY.ini.
From here on in dmwExport will become one of the sub-routines the running sequences of which will be determined by an overall controlling procedure.
The Controlling Procedure
This is the sequence of sub-routines that the controlling procedure, or program, named dmwExportToXL, will call:
dmwGetPath This VBA-function sub-routine will look for KEY.ini and get the export path from it. If dmwGetPath cannot locate KEY.ini, or is unable the find the information about the export path, then it will return an error message to dmwExportToXL.
dmwCheckPath This VBA-function sub-routine will seek to confirm the existence of the folder to which dumps are to be directed. If dmwCheckPath cannot locate that folder it will it report is as missing to dmwExportToXL.
dmwExport This will complete the export program passing data from Access and into Excel, the opening Excel to display the data, and the formatting of the worksheet.
This is the skeleton of the dmwExportToXL program:
Get Path Sub-Routine
The job of the sub-routine dmwGetPathFromKEY is to retrieve the path of the back-end DATA file from KEY.ini:
If it's unable to return the whereabouts of DATA, then dmwGetPathFromKEY warnings from which dmwStartUp composes messages to the user.
Check Path Sub-Routine
The job of the second sub-routine, dmwCheckPath, in the export program is to confirm that the folder specified in KEY.ini actually exists:
dmwCheckPath returns a null string if the folder is in place, or a message if that folder is missing or that the program cannot find it at the anticipated location.
Export to Excel Sub-Routine
The third and final subroutine in the program is dmwExport. But unlike the version at the top of this page, this version of dmwExport contains lines of code aimed at smartening up the contents of the worksheet created by the export.
The smartening up that my clients most like to see are these:
- Formatting of column headings
- Application of a currency format to columns, where appropriate
- Application of a date format to columns, where appropriate
- Adjustment of columns widths to suit content
- Appropriate naming of the worksheet's tab.
Hence a revised dmwExport, now fashioned as a function procedure:
Export to Excel Program Procedure
This is the controlling procedure that pulls together the sub-procedures to perform the export to Excel:
This is how you might provide values for the arguments of dmwExportToXL:
query$ as "qsExportSales" — your database query
fileName$ as "Hello" — the workbook file's name.
wksName$ as "World" — the worksheet's name
colsCurrency$ as "F:F" — Column F currency format
colsDate$ as "C:C,D:D" — Columns C and D date format.
Each argument value must be enclosed in the quotation marks as shown above.