Sorry to be a bore on replication ...

How would EDB cope with the following scenerio:

I have 1 central database and many local "laptop" users. These users connect from time to time to load & save updates. This is all done with Unique keys & works.

The central server might SAVE UPDATES hourly.

A new user arrives. This user needs a "starting copy" of the database.

I call "BACKUP DATABASE .... INCLUDE CATALOG"

Install this backup on the new users computer. At the same time I create an "IN" and "OUT" store for this user to  use for the "load" and "save" processes.

--

Do I need to call "BACKUP DATABASE" hourly at the exact same time as the SAVE UPDATES in order to ensure I have a version of the DB which exactly matches?

If I only call BACKUP DATABASE when the new user arrives, some update files might include updates which are already present. Could this cause a conflict?

The new user should only get updates created after the database was backed
up.

In my case, I had a unique store for each customer that connected to the
server.  That store was created when the user was created and the first
thing that happened was the database was backed up and put in that store.
All such stores had a unique name and the hourly script looked through all
store names with that unique pattern to copy the updates.  So a user never
got any updates created before their database was created.

You could also check the date-stamp of the "updates" files.

David Cornelius
Cornelius Concepts

Adam,

<< Sorry to be a bore on replication ... >>

Not at all - sorry I'm only popping in here occasionally.  Hopefully this
situation won't be much longer.

<< How would EDB cope with the following scenerio:

I have 1 central database and many local "laptop" users. These users connect
from time to time to load & save updates. This is all done with Unique keys
& works.

The central server might SAVE UPDATES hourly.

A new user arrives. This user needs a "starting copy" of the database.

I call "BACKUP DATABASE .... INCLUDE CATALOG"

Install this backup on the new users computer. At the same time I create an
"IN" and "OUT" store for this user to  use for the "load" and "save"
processes.

Do I need to call "BACKUP DATABASE" hourly at the exact same time as the
SAVE UPDATES in order to ensure I have a version of the DB which exactly
matches? >>

Yes, since you're mixing a complete backup with what amounts to incremental
backups, you'll need to ensure that the timing of the two operations is done
in a time-consistent way.  The key here is to make sure that you do the SAVE
UPDATES, then the BACKUP DATABASE.  This will ensure that you've got a clean
cut-off point that is consistent between the update files and the backup
files.  Please note that there's still the possibility, albeit remote, that
an insert, update, or delete sneaks in to the database in-between the SAVE
UPDATES and the BACKUP DATABASE execution.  It really depends upon whether
the database is actively being used at the time.  This is why it's usually
best to do the BACKUP DATABASE in off-hours, and then just keep all update
files created since that point in the same store where the backup file is
created.  Then, any time a new user comes on board, just copy over the
backup file and all of the subsequent update files to get the user started.
After that, they can simply be included in the normal stream of update
files.

--
Tim Young
Elevate Software
www.elevatesoft.com

OK: Simple schema for creating new remote users in a "cloud-style" DB:

1. Backup Database, periodically (say daily in off hours)

2. <<General work of the database continues, with uploading and downloading of updates between server and all users>>

3. Save updates regularly the Backup Database store with the periodic backup file from step 1.

Files from the Backup Database store should enable the creation of a new remote user, who can then join in the process going on in step 2.

Each time we do step 1. we should delete all the files from step 3. and start again.

--

I only have a dozen or so users at this stage, but I do need to be able to add new ones periodically without too much difficulty. If the schema works I will definitely be rolling it out to all my users, as it is faster, more responsive and doesn't require continuous connection to the db.

... does the above look OK?

Adam,

<< .. does the above look OK? >>

Almost.  The only catch is that while the sequence works fine for new users,
you'll still need a way to keep existing users from trying to download the
same update files over and over again if you intend to keep all of the
updates files in the same store as the snapshot backup file.  There are a
couple of ways of doing this, but the easiest way is to simply keep track of
the timestamp (in a system table, etc.) from the last update file loaded at
each remote location, and then simply have the remote location only
copy/load the update files whose timestamp is greater than that timestamp.
The other way is to use a "distribution" mechanism whereby each remote
location has its own store on the main EDB Server for downloading updates,
and each update file saved in the same store as the snapshot backup file is
then also copied to each of the remote location stores.  This second method
is what is used in the sales quotation example of the replication technical
article.

--
Tim Young
Elevate Software
www.elevatesoft.com