Griff has a good point about needing an external source for the necessary version number. An exe checking its own version number it has encoded in its own verification code will always pass itself.
Introducing this is not really possible unless you do it from version 1. The only way I see is to let too old versions without such verification fail, for example by renaming an important table. A too old exe then will crash. I don't see a way to enforce this gracefully without an error popping up. And I won't take that lightly, if you talk about an application you ship to many customers, any hard system error message reduces the trust into an application.
But from then onwards, the mechanism as Griff describes it will be fine. I'd also take in the possibility for executables to only need to match in the major version. Obviously, if you make a db change that's mandatory for all users, that automatically makes this update a major update.
The only weak point then is faking exe version or changing the version in the DB, that should be cared for by permissions, of course. A dbf containing the db version made read only means the executable with a newer version than db version could upgrade the db but not the version of it, which is a problem. Well, you then would not do the DB update from within the exe but administratively within a company. For the scenario of a product shipped to end users, you can't administer the database that way, though.
Also, file permissions are not the strongest safeguard, as users could change them.
This means, in any serious scenario you get into the territory of cryptographic safety mechanisms. Signing the necessary version number with a private key, the signature can be checked by an executable knowing the public key of the private/public key pair. And it can know the public key without breaching the security of that, by definition of such asymmetric cryptographic mechanisms. That way you also won't need read-only protection, a user trying to manipulate something will be caught by a wrong signature and he'd be incapable of producing a new valid signature.
There's still a problem with this, as an older version together with an older valid signature still is valid. The problem scope is now smaller though, a user could only override both db version and exe to older versions. That'll only give him an advantage if an old version enables him to do something the new version doesn't allow. For example by a flaw of the old version. I had to struggle with exactly that scenario, once. An old version had a built-in adminstrative backdoor that I gave to thje admin of a company, and he didn't keep it secret. In the end, I could only finally make old versions unusable by introducing a new table-structure and -naming the versions with the backdoor would not be able to use.
Chriss
![[ponytails]](/data/assets/smilies/ponytails.gif "[ponytails] [ponytails]")