> On 02-Aug-2004 07:09:05, Lester Caine wrote:
> If a structural change is made, the a new blank database is supplied,
> along with scripts to copy from the old database to the new. If any
> copies fail, then the problem is noted, and sorted before trying again.
> We usually get a few niggles relating to mistakes in the old copy, so
> they get picked up. Once happy with the new database THEN you switch
> over. Often they run a few days of tests with the new setup, then do a
> clean switch the following weekend - with a clean upload.

OK, but if you have hundreds of customers often running different versions
of the software (not all elect to upgrade at the same time), then how can
you handle the deltas between the current version and the old version?
Often the old version isn't known at the time of the upgrade.

For example, let's say that I have 20 customers running the following:

10 run v1.0
5 run v1.1
5 run v1.2

I want to release v2.0 of the 'system' (database and application). The
installer or utility for v2.0 will not be guaranteed what version the client
was using and what to upgrade from. How is this typically handled?

Regards,
Myles

===============================
Myles Wakeham
Director of Engineering
Tech Solutions US, Inc.
(480) 451-7440
www.techsol.org