ooops, I meant to cc Alex on that last reply ... check it out Alex (sorry)

>PMFJI, Andrew and Alex ... BTW, nice to meet both of you at WhilFest!!
>
>I probably missed half of this discussion, but I just wanted to add to what Andrew said, about going from one known state to another ... I missed your session at WhilFest Andrew, so I don't know how you keep track of the known state, but I just wanted to throw in the way that we do it and that is to have a table in the database that keeps track of what version the database is at. Then, we keep track of updates we have to do by version number (we keep them in a VFP table, ordered by version number with the SQL script stored in a memo field) and update the backend starting at the next version number. The key, Alex, is to make sure that you never update the database except thru this method, and then you'll *have* to keep track of the updates. I'm sure you do something similar, Andrew, but not knowing I thought I'd just throw in my 2cents as well (and hope I'm not being redundant).
>
>~~Bonnie
>
>
>>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