|
To Get To Where You're Going, It Helps To Know Where You Are -- Versioning 101
I've talked in the past about global positioning
systems (GPS). These nifty devices help pinpoint
your location anywhere on earth. Over the last
decade, these devices have grown from the preserve
of hobbyists to near ubiquity. They've become so
commonplace that they are found not only in cars and
on boats, but also in cell phones.
Like GPS units helping you find where you are, a
versioning table in Microsoft Access can help you
figure out which version a user has and determine
whether it's time to update. This month, we'll take a
look at a system for keeping track of versions.
| The Versioning Table |
 |
|
The easiest way to keep track of versions is just to
plop a version number on your opening menu or form,
and leave it at that. This has the beauty of simplicity.
However, if you release multiple versions over time, it
is helpful to maintain a history of versions and to know
which version a particular user has.
Last month, I showed the following opening menu
from the Flash Card program:
As you can see in the lower left hand corner, I have a
version number and a build date. This is controlled by
the following versioning table:
The fields for this table are as follows:
- Version key - This is the primary key on the
table and, as always, it is an auto number.
- Version ID - This is the top level version
number. It gets updated only when there is a very
significant change in features or structure of the
program.
- Major revision - This field tracks important
changes, but is less important than those associated
with versions.
- Minor revision - This is updated for every
single release; it is alphanumeric and a trailing letter
can be appended as needed.
- dtmBuild - This date stamp (default value
= current date) tracks a when the version is
released.
- Released - This field tracks whether a
version is actually released. There are occasions
when a version is not released; perhaps the
application is going through on site testing and fails
whatever tests have been set up. It's good to know
that a version has been installed and then
withdrawn.
- Build notes - This field is a place to make
any notes about the release. It is strictly for the
developer and is not exposed to the user.
|
| Putting the Table to Use |
|
|
Every time there is a release, I update the table. This
makes it easy for me to keep track of where I am in my
versions, versus those of my users. In some
applications, I have hundreds of users spread out
over a large geographic area. These users may well
have different versions of the applications.
Some sites have special requirements and get
updated versions that meet their particular needs,
changes that have limited or no value to other users.
In some cases, I'll add an additional required Yes/No
field. In certain circumstances, users are notified that
that particular version is a mandatory update on their
system, and it will be flagged as required in the table.
In other cases, the changes may be minor, in which
case users know that a new version has been
released but that the update on the local system is
optional.
For all releases of the software, I'll let users know
about the new features and whether or not the update
is optional, so the users can to decide for themselves
whether or not to install.
|
| Philosophy and Next Steps |
|
|
At this point in the process, we have the table that will
provide data for our versioning code to put the version
ID and build date onto the menu. The actual
transmission of the data from the table to our menu,
we'll tackle next month.
In theory, we could have skipped the table entirely and
put everything we need in code.
As a good programming practice, it's better to put
things into tables rather than embed them
into code. See this month's tip for more about this
approach of keeping track of data and bits of
information.
|
|
Tip of the Month - Store Pieces of Information and Data in Tables, Not in Code |
|
|
|
As you are developing an application, you will have
small bits and pieces of information that your code
needs to access periodically. This is not application
data, but data needed to drive your code. Unless the
piece of information or data is strictly for one-time use
and is never to be used again, it should live in a table
and not in your code.
The reasons for this are compelling. First, it is easier
to find a piece of information in a table than if it is
buried in code.
Second, if the data is stored in a table, it's not only is it
easier to find, but also easier to access. If you keep
all the discrete pieces of data that are used
occasionally and tend to be unique in a dedicated
table, you then have a centralized location for your bits
of data. Because they're centralized, you can also
build an engine to retrieve and manipulate that data.
When you think about this, keep the following rule in
mind: If it's data, it belongs in a table.
|
|
