diwic2 wrote:

> For me, I find it simplest to embed a metadata update within a new
> version of the program. So the first thing the program does when it
> starts, is to check whether the database needs to be updated - if it
> does, it executes some SQL stuff ("alter table add column" or
> whatever), then it continues as usual.

I have something like that too. I created a simple table with column
DATABASE_VERSION. In application I have metadata update scripts that
bring db to specific version. For example:

1. ALTER TABLE ABC DROP DEF;
2. DROP PROCEDURE DIDNTNEEDITANYWAY;
3. etc.

When the app. is run, it just reads the DATABASE_VERSION from the
database, and executes all available scripts that have a bigger number.
After each step it does update on DATABASE_VERSION. That way you can
have one customer who hasn't updated for a long time, and has for
example db version 3, and other customer that updated recently with
version 10. You can freely send them the same app with version 12, and
they'll both be updated properly.

HTH

--
Milan Babuskov
http://fbexport.sourceforge.net
http://www.flamerobin.org