The Access Wizard Newsletter Tips, Tricks, and Traps for Access Users and Developers
July 2009

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.

In this Issue
  • Tip of the Month - Store Pieces of Information and Data in Tables, Not in Code
  • The Versioning Table
  • Putting the Table to Use
  • Philosophy and Next Steps

  • 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.

    Quick Links...

    Custom Software Home

    Access Wizard Archives

    Our Services

    Join our mailing list!

    Forward email

    Safe Unsubscribe
    This email was sent to jim@custom-software.biz by jim@custom-software.biz.

    Custom Software | Copyright Custom Software All Rights Reserved | Westford | MA | 01886