[download id=”1408″]

I’ve been wondering for a while how to go about running async tasks within Access.  The lack of multi-threading support has always been something I wished was available, but not until relatively recently when dealing with Azure backend databases has this lack of feature been quite so painful.  While there’s typically plenty of ways around it, it would certainly be helpful to have in many cases.

In any case, I recently came up with a way to implement some rudimentary async processing by using a separate utility Access application that is fully managed by the main front end.  Commands can be sent to the async processor from the main application, and when completed (or at other desired intervals/events) the async processor sends a notification back to the main application.

Naturally there’s restrictions – the two aren’t “tightly tied” to each other and the only interface is through these command/notification methods (and any shared linked tables), but it’s enough to empower some pretty good functionality overall.  The restrictions aren’t much different from multi-thread programming in other platforms, so it should be no biggie.

Overall, it’s a considerably more friendly setup than tapping into the .NET framework with COM interop and wired events.

Attached is a zip file with a demo.  Be sure both Main and Util applications are in trusted folders!  Otherwise you’ll get an error when trying to instantiate the util app that does the async processing.

Open the main app and open Form1 to see it in action.  This uses a 5 second interval timer for the async process and simulates a long running task with a 4 second Sleep command.

Here’s some basic (pertinent) code, but the demo has everything wired up nicely.

Main Application

(the callback for the notifications – make sure it’s in a standard module and public so the util/async app has visibility to it)

Util/Async Processing Application

(and the form with a timer to simplify the simulation of a long running task)

[download id=”1408″]

Share on:

Share on facebook
Share on twitter
Share on linkedin

Reader Interactions


    • Jack D. Leach says

      Thanks Brian. I’ll have to update this after I get the rest fully fleshed out, but what’s not included here so far as that in order for it to work, the “background” processes need to be fired from a timer. Thus, one should set up a queue (a VBA collection works well with IDs generated via static counter), and the timer should fire on a short interval and check the queue collection for new commands to process.

      Having done some extensive timer/queue work on other projects, the important thing there is to be sure and include DoEvents within the timer loop, before processing a task. This keeps the timer intervals backlogged correctly when the task in process takes longer than the timer interval is set for. I’ll update the post after I have this technique in production with the bugs smoothed over.

Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.

Recent articles