I am creating a stand alone application that accesses a typical database on the server. It will likely be utilized by a couple of dozen folks my organization.

I understand which i will have to update the program and the style of the database. This produces the chance that someone will work a question around the database using old software.

I curently have a method in position which will catch when the user attempts to launch an out-of-date version from the application. However, this doesn't guard against somebody that keeps the applying up more often than not.

My idea ended up being to put a version entry within the database (in tblVersion or something like that like this) and appearance it every time any record in almost any table within the DB (except tblVersion) is added, up-to-date, or erased, although not basically read.

By doing this I possibly could catch stuff that (I believe) could corrupt the DB even when the consumer comes with an out-of-date version from the SW: look into the version within the DB against what's within the code, and disallow the add, update, or remove operation if there is a mismatch. Simultaneously, I would not be adding the overhead of lots of inspections to tblVersion for DB reads.

My questions: Is seem? It is possible to better approach to take about this? If that's the case, what?


I believe the tblVersion idea is most likely fairly seem, but I'd consider checking it at start-up rather and immediately failing, instead of awaiting the consumer to try a write around the database.

There is a couple reasons this really is advantageous:

  1. You avoid the necessity to frequently look into the version. This can be done once at startup and save a number of queries, particularly if plenty of customers are utilizing this technique.
  2. It's not necessary to litter your computer data access layer with one of these inspections.
  3. Looking into write most likely is not the very best consumer experience anyways. Customers would have the ability to load an archive, spend a couple of minutes carrying out some edits, after which need to abandon all individuals since the database has gone out-of-date. When they aren't likely to have the ability to do anything whatsoever helpful using the database, inform them in advance instead of once they finish their edits.

At least, you can examine at application start-up and warn the consumer they will not have the ability to save anything the moment they load the applying.

The utilization situation of the person getting the application open for such a long time that the new, incompatible rollout from the application happens and also the database schema (or interpretation) is modified inside a structurally compatible, but semantically incompatible way appears pretty narrow.

Getting a schemaInfo table with and getting two tuples, one using the current schema version and the other using the last compatible version will catch the huge most of cases whilst not excessively further complicating the application.

Looking into every write will be a horrible mess, if you are really worried about the scenario, possess a timer set off every hour or so that inspections the table version and appears a dialog warning the consumer to obtain a latest version.

Better still you can simply bounce the DB forcing all existing periods to disconnect once you have finished a schema change.

I believe that may work.

However, I'd suggest something slightly different.

You will find two parts into it:

  1. Consider two kinds of updates -- needed and optional. The concept is the software would more vigorously update itself once the update is needed. And also you because the developer would only flag an update as needed if you feel it must be. Sometimes on the similar kind of application and several updates which i see don't really have anything related to the database whatsoever... and individuals are the types of updates that needs to be optional.
  2. Add code for your application that queries your database every minute for that current version number. Once the current running version has gone out-of-date and also the latest update is needed, then appear a dialog box that needs the consumer to obtain the update. Based on the application, you may even have to add code that enables the consumer in order to save their work.

I believe should you adopted this method then you may update the applying instantly throughout start-up whether the update is needed or optional. However as the user is really while using application, I'd only pester the consumer concerning the needed updates.