> I'm planning a project that would be well served by your type setup

(local

> dbs with a central master db).
> Might I be so bold as to inquire how you worked out the keys? A

straight

> generator won't work in this situation since
> each local db would have generators and would thus be generating

duplicate

> keys.

No problem at all. Only the master database is used for that
sort of problem. I don't actually use the information on the
local copies, as all of the inserts and updates are
broadcast from the main server, but I have a network request
to get the next number from the master copies generator if
an operator is trying to add a train from a remote location.

The problem here is quite simple - train timetables - so the
raw information does not change much, we just have to say
where a train is, and each local copy updates itself.
Station names and other details are transmitted as 7
character codes ( it's historic <g> ) and so the look-up
table is held in each local copy. Result, nothing much going
down the network - wodge of data each hour when we extend
the timetable, but it's then got an hour to go down the line!

I did away with 'events' and have my own messaging system
which checks the state of each site every minute, monitors
status, and allows for messages such as 'update to record
xx' in addition to 'train into aa', and each slave site then
reads a copy of the updated record from the main server into
the local one - IBPump is great - no need to 'refresh all',
just download the updated record. Each local machine builds
a list of the records it need to update, and downloads them
as it need to in a slow background 'scan'. Urgent updates
just get poped in at the top of the list and are done next.

(Try again on-line I'll be glad when my hosting come up on claranet!)