Adam,

> The problem is rather that once I have forced 1 user to stop updating "i.e. "System change pending, please wait to use the system until update is complete" I then have to wait until the very last user has logged on and confirmed their update is loaded before I can restart.

Hmm... I don't think so.

Why do you have to wait for a user until he loggs in?
Any user can continue to work with the old local database-version as
long as he wants.
The point is just the moment when he wants to send or receive updates.

At that point he connects to his "Changes"-store *before* exchanging
update files. If the mentioned file is in this store, he downloads the
script, executes it and his local database is altered.

After that he can continue to send and receive updates with the new
database structure.

Should work.

Regards Uli

Uli I don't think you have looked at the script I posted.

>>Any user can continue to work with the old local database-version as
>>long as he wants.

No this will not work. The update file being created by this "old" user will not be able to be loaded into the "new" database, as their database structure differs from the "new" system, and update files cannot be applied across database versions.

As soon as you change the system from "old" to "new", all updates made by users to the "old" version cannot be applied to the "new" version.

For example a salesperson adding sales to the sales database would not be able to pass them up to the server, so these sales would be lost, or would have to be re-entered.

Adam,

> I don't think you have looked at the script I posted.

The question is not whether or not an outdated updatefile will work, the
question his how to prevent a user from creating such an update file.

> No this will not work. The update file being created by this "old" user will not be able to be loaded into the "new" database, as their database structure differs from the "new" system, and update files cannot be applied across database versions.

As I mentioned before: there will be no update file created by the "old"
user.

To make clear what I mean:

1. Normal business
2. User1 wants to send update
3. User1 connects to "ChangesStore"
4. No file in the store
5. User1 creates and sends update

1. Database has to be altered by main server
2. Main reads pending updates and puts "Stop"file into "ChangesStore" of
each user. After that Main restructures the database.
3. User1 wants to send update
4. User1 connects to "ChangesStore"
5. StopFile (maybe with restructure script in it) found in the store
6. User1 is not allowed to create and send further updates
7. User1 has to execute the restructure script, file is deleted from
remotestore.
8. User 1 can now create and send updates.

Agree?

Adam


What is the maximum time without updates being transfered around that is acceptable?

I'm thinking some sort of synchronisation object passing may work. The last time I was involved in synchronising databases at multiple sites ithe setup was via tape transfer and me exceeding the speed limit between Grimsby, Market Harborough and Bedford.

My idea is roughly along the lines of:

1. Ready to start the process - send out notification to remote sites
2. When they receive notification they acknowledge it, do their last publication of changes to their database and send it off
3. When all (apart from Fred who's on holiday) have acknowledged and their updates have been processed send out a get new structure notification
4. Users receive it, upgrade, and return acknowledgement
5. Having had the last upgrade acknowledgement you send out a business as usual notification
6. When users get that they can then go back to normal operation



Roy Lambert

Uli


Very similar to my suggestion. It will be nice to know how Adam finally copes.

Roy Lambert

Roy,

> Very similar to my suggestion. It will be nice to know how Adam finally copes.

I am just coding that and decided to put an xml-file in the user's
remote "changes" store.

Something like this:

<medicontrol>
  <action>
    <title>Neues Feld "Einheit" in Tabelle "Laborwerte"</title>
    <date>10.04.2012</date>
    <script>
   SCRIPT
   BEGIN
         Execute Immediate 'ALTER TABLE "Laborwerte"
           ADD COLUMN "Einheit" VARCHAR(10) COLLATE "UNI_CI"';
   END
    </script>
  </action>
  <messagetext>
     Some text here to notify the user what's going to happen...
  </messagetext>
  <appversion>
     1.0.0.1
  </appversion>
</<medicontrol>

The application reads this file before trying to send an update and can
execute the script in it.
As long as the xml-file is present, no furthere updates can be sent.

Uli

I'm probably being stupid here.

Can you run the updates from a client twice? I would have thought this would be possible because what if there was an error writing the updates, I presume that they could be re-run.

For instance, could the update be refused by the server if the version number of the software is different?

Then the user has to update the software, during the process the data layout is changed. Now when an update is run both the databases would be the new version and the update would work??????

Apologies if this is way off the mark, I have not had the time to look into this in depth yet.

I am still waiting for confirmation from the client of the contract for the job.  Had a text (a text - what the *&^%$*????) from the Managing Director this morning assuring me its definetely going ahead.....

Peter

For clarity.

What if the client cannot run the updates unless connected to the server.  In that way couldnt the client database structure be updated before any update is run.  Both the databases would then be the same. Similar suggestion toUli.

Peter

Peter,

> For clarity.
>
> What if the client cannot run the updates unless connected to the server.  In that way couldnt the client database structure be updated before any update is run.  Both the databases would then be the same. Similar suggestion toUli.

With the way to mange changes in the db-structure I described, it's
quite simple:

When the user is not able to connect, he is not allowed to write any
(local) update i.e. not to upload them.

When he is online again, he will receive the Restructure file and only
be able to create updates after having executed the restructure script.

Uli

Uli Becker wrote:

Peter,

> For clarity.
>
> What if the client cannot run the updates unless connected to the server.  In that way couldnt the client database structure be updated before any update is run.  Both the databases would then be the same. Similar suggestion toUli.

With the way to mange changes in the db-structure I described, it's
quite simple:

When the user is not able to connect, he is not allowed to write any
(local) update i.e. not to upload them.

When he is online again, he will receive the Restructure file and only
be able to create updates after having executed the restructure script.

Uli


I agree that would seem to be the way to go to me.

Regards

Peter