Access JumpStart 2.0 | Blog

A Rapid Development Framework for Microsoft Access

Sounds intriguing, doesn’t it? So what do I mean by running Access headless? I am referring to the term headless as it refers to running a machine without user intervention as an automated process.

For example, I have some reports that get emailed out at certain time each week for a client. We have set up a Windows Scheduled Task to run on a computer at their location. This task does run as a particular user, but the user does not need to be logged in to the machine to run the task. The task launches the main Access database using command line switches to tell it what to do. It runs certain routines, then shuts itself down.

There are many caveats to using Access this way, and looking for alternatives as quick wins might be preferrable. Like writing a VBscript via an automated task is more suited to most requirements and works better out of the box.

In my case, I need to export a particular complex Access report to a PDF file and email it to a number of people. I already had everything set up to preview the report for users who were logged in, so I didn’t want to have to reinvent the wheel, plus it was an Access report. Not easy to recreate with other programs.

Here are some of the gotchas:

  1. I needed to set the login for the Scheduled Task (in Windows Task Scheduler) to run whether the user was logged in or not as shown in the selected option below:
  1. Furthermore this required me to have an Admin on the customer’s network give the user permission to be able to Log on as a batch job – Windows 10 | Microsoft Learn.
  2. Even though now my user had permission to run the job as a batch user, I still had to overcome a few more obstacles with my Access program.
  3. If Access tries to display any message boxes or throws an unhandled error, the task will freeze and tasks will start piling up at the scheduled intervals, at some point taking up all the computer’s resources and slowing it to a crawl. You will want to make sure you have a routine that works flawlessly and without any required user input to use this approach.
  4. Since my main database requires user input right away, I added usage of the “Command()” VBA function which will tell you what was passed to Access via the /cmd flag. So for instance, I started using: “msaccess.exe mydatabase.accdb /cmd ProcessEmail”, then make my first line in my autoexec macro call a function to detect if “ProcessEmail” was sent and run the special routines to process the email and then shut down Access.

This was just a basic high level look at what I needed to do to use this approach. If you would like me to do more articles delving into this further, let me know in the post comments on the web site or reply to this email!