Hi Alex,

Firstly, on re-reading my message I realised that it could come across as glib and condescending. If it did, please accept my apologies -- it was certainly not intended in that way.

I think the thing that presents the most problems in your approach is that you don't know what the state of the database is before you create a new one and append from etc. It could (potentially) be almost anything. In the intervening period, changes to the database may have removed fields, added tables and so on. What if this particulkar client has missed an upgrade for example.

The approach I presented at WhilFest, OTOH, goes from one known state to the next, applying updates, moving and massaging data and all the ancillary stuff along the way. Mike Levy suggested that there might be a tool that generated the change script to go from one one database structure to another (but of course it wouldn't know about the data massaging), so you might be able to combine the approaches.

Another thought I just had is to keep a copy of each version of the database you ship and then test your change script on that copy so you can verify that you have been meticulous. Any missing meticulousness <g> could be replaced in the script by hand before you ship the update.

Once again, the approach you propose will work, I just feel that it would be more difficult to maintain than the incremental technique I presented.

Cheers,

Andrew

>>Sure, you could use that approach, but I would have thought that with "overriding all rules just for the import" and then "a procedure that ran only once and did more complicated changes such as filling a new field with a default, etc" plus "Things such as rights would not be moved over, but I can deal with those separately", it would be more "error prone" than keeping track of your changes as you make thme to the development box and having them applied automatically from any app instance that starts up.
>
>Because our database is at an early stage and changes continuously I want to automate as much of the maintenance as possible. I must confess, however, that the main reason we use this approach is that I don't trust myself to keep track of all changes properly. This way we make all changes on a single database and write programs to create an empty database and to propagate the changes fairly automatically.
>
>Thanks for your response and especially for bringing SQL-DMO to my attention.
>
>Alex