Don't forget to check the version numbers of the DLL's and
such that your program calls. I've had a LOT of grief in the past
because users installed a new program, after installing my program,
which placed newer (or older) incompatible DLL's on their system.
My program just started mysteriously cr
At 12:19 AM -0500 1/30/05, Mrs. Brisby wrote:
None of this is necessary if you select a durable schema.
Whenever you think you need to "add a field" - add a whole new table and
use joins anywhere you need access to the new field.
You can't "delete" a field, but deleting a field usually means losing
None of this is necessary if you select a durable schema.
Whenever you think you need to "add a field" - add a whole new table and
use joins anywhere you need access to the new field.
You can't "delete" a field, but deleting a field usually means losing
data anyway.
You can't change the nature o
There are two issues at play here:
(1) Schema updates driven by new versions of your application program.
The method you described is basically a sound method, though I might
suggest a couple of modifications. You raised the question of a user
skipping versions. This is easily addressed by havin
If you are looking for longetivity of your program, as I am doing
with mine, I would keep and continue to use a Control table such as
you speak of. However, this Control table should not contain the
database version number, but rather the version number of your own
application program. That w
5 matches
Mail list logo