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
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
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
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
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
I'm creating a shareware program using Visual Basic and SQLite. I'm using
the SQLiteDB wrapper.
I want to plan how I am going to handle updates to my program that involve
modifing the database, and thus I'd like some advice as I'm sure others
have faced this problem before. I need to be
6 matches
Mail list logo
