Re: [sqlite] Handling database updates in my program updates

2005-02-02 Thread Jay
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

Re: [sqlite] Handling database updates in my program updates

2005-01-29 Thread Darren Duncan
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

Re: [sqlite] Handling database updates in my program updates

2005-01-29 Thread Mrs. Brisby
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

Re: [sqlite] Handling database updates in my program updates

2005-01-29 Thread Eric Scouten
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

Re: [sqlite] Handling database updates in my program updates

2005-01-29 Thread Darren Duncan
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