As Access developers begin thinking in terms of "the Cloud", all
sorts of possibilities open up. Things that used to be hard, like managing
licenses for your home grown software apps, are simplified by employing online
I was recently asked to create an Access application for managing golf
tournaments. The objective was to create a shrink-wrapped product that, once
purchased, could not be illegally pirated. What follows is the solution I came
up with, which implements a centrally located cloud database for managing
Before I begin with the code, allow me to admit that my approach is not iron
clad. I have no doubt it can be defeated. Since the application targets a
small, non-technical audience, the idea was to create a system complex enough
to discourage illegal installation while providing useful feedback on where and
by whom the application was being used.
The code used for this article (download
here) was unit-tested but may present minor glitches and is no doubt
subject to improvement. It represents my first pass at the problem but it’s a
good starting point. However, setting up an environment for the demo to work is
not a trivial task. It requires the following:
- Download the zip file and extract to a folder
- Run the script, BuildLicenseDB.sql on a SQL Server
- Holding the SHIFT key, open the file License Demo.mdb
- If you are on a 32 Bit Machine, it should run correctly
If not, you’ll need to edit the basAPI declarations as shown below.
- Finally, open frmConnect to reset the object connect
(use your own server login credentials)
Comment out the appropriate API declarations
Run the connection-refresh form, frmConnect
The Process in Overview
The idea is simple but the process quickly became very involved. Below is a high-level
view of what the authentication procedure attempts to perform. When the
start-up form (frmSplash) is opened and its Timer() event is triggered, the
following steps are taken:
- Custom database file properties are read (Key, Machine,
- Properties are validated against the computer name and
- A test is made to see if a Trial period was started and/or
- Failure of either of these, or a missing key triggers the
- Supplying a valid key updates the file properties for
The idea is similar to the way Microsoft implements "Activation"
for Office. If you’re not connected to the Internet, you can use the product
without activation for some weeks. If you go online, you can activate the
product once and never need to be connected to the Internet again to use the
Additionally, the online license database allows for two valid
"uses" of the license key. A single table License contains typical
user info plus two sets of columns that describe the registrations: Login,
Machine and Date. The first time the registration key is used, the first set of
columns are populated. The next time the file is opened on an unfamiliar
machine or with the incorrect login, a second registration will be required.
This paradigm allows for only two logins but since the license database is
"in the cloud", the registrations may be manually reset, much like
what happens when you register too many devices with iTunes or Audible.com. If
you, as the developer, want to be more generous with activations, the paradigm
may be extended.
When the user opens a properly registered MDB file for the second time, the
authentication is made, not with the Internet database, but between the local
machine attributes (login and computer name) and the properties saved with the
The Access properties window, shown below, reveals the custom properties in
their initial state. As registrations are activated, these properties are
populated. Few developers know these properties exist and fewer yet actually
use them. While that’s not deterrent, their hidden nature makes them difficult
to hack and if the MDB is compiled into an MDE (as it should be), the code that
would reveal them becomes obfuscated as well.
At the risk of sounding stupid, I cannot find this property page when using
Access 2010. I had to open the mdb in Access 2003 to generate this screen shot.
So while not perfectly hidden, these attributes are well buried.
Run the Demo
What you see below in the screen shot is pretty much the entire user
interface. The connection form (shown above) is necessary to initialize the
license objects to your cloud database, but the end user should neither know of
nor have access to this function. Once set, that form and its methods are no
The easiest way to understand and debug the process is to set a breakpoint
in the Form_Timer() event of frmSplash and step through the
code. Roughly speaking, it follows these steps:
- If previous license registration matches Login and
Computer, open app
- If in TRIAL mode and not expired, open app, otherwise
- If not connected to the Internet, registration cannot
proceed … exit app
- If user-supplied KEY is supplied
- Check against cloud database to verify it’s valid
- Check to see if Licence 01 location is available
- Check to see if License 02 location is available
- If a registration is available, open app with SUCCESS.
Otherwise, exit app.
Implement in Your Application
To implement this paradigm you will need to import most all objects from the
demo database. If you already have a splash form, then simply copy the code in
the form’s module to your form. Same with the About form, which displays the
registration information as it appears in the database properties window.
The other concern would be duplication of API declarations and other
functions, should they already exist in your application but those are simple
enough to find by forcing a code compile. As I stated at the beginning, this
code was unit tested but it could be possible that some condition was missed in
the testing. Still, it’s a good start if you want to push registration key
maintenance to the cloud.