Hi all,

I have to syncrhonize two c/s databases. One is at the clients site, another
somewhere "in the internet". Only one of them does produce data. So, there
are two scenarios:

1) local server gets data, WAN server is just for backups

and if the local server fails, then the customer will switch to

2) WAN server gets data, local server is backup (or better: will read
changes when up again).

The synchronization must be as immediate as possible.

Right now, I plan to enhance the DBISAM server. A switch or a special
version will write every single change (INSERT, UPDATE, DELETE, I am not
sure about structure changes) in a text file or something similar. That
stuff will be transferred by a tool every 30 seconds or so to the central
backup site. Compressed, of course, only with the needed data, maybe sent
via FTP. There, another tool reads the file and writes all changes to that
db.

Every db will be served by 2 DBISAM servers: one for work, which will write
the changes tothe file, and one only to get the changed data from the other
site. So, changes from that other site will not trigger the file writing.
The tool that writes the changes could write directly to the db in local
mode, which would have the same effect.

With some fiddling with the IDs (all AutoIncs, unfortunately not GUIDs, it's
an old project), they could even work on both sites in parallel. Say, the
local db will start with IDs from 0, the central/WAN/backup db with IDs from
1.000.000.000. Could be done easily with a little tool. And every table that
must be synchronized has an ID field, providing an identifier for every
record.

In theory, that should work. It's the best solution I can imagine, but that
means not much Does anybody has a better approach, or maybe even a
running system?

Ralf

Almost forgot: if anybody thinks that (s)he can implement such a system,
then I would be happy to outsource it!

Ralf Mimoun wrote:

> Almost forgot: if anybody thinks that (s)he can implement such a
> system, then I would be happy to outsource it!

you have to have another tier that splits and verify's the in- Output...
MAC adresses and timestamps (like the GUID's) could do that...

You really should do this!!!!!
I'll take care of your other customers... )

Ralf

When you have written your all new all singing double server posting
application why not buy one of these new record breaking Panta servers
to run it on ?
http://www.theregister.co.uk/2006/11/07/panta_server/
So so fast .
Rita

"Ralf Mimoun" <nospam@rad-on.de> wrote in message
news:C420225C-3415-407C-A945-B9CB0C7ACFAE@news.elevatesoft.com...
> Almost forgot: if anybody thinks that (s)he can implement such a system,
> then I would be happy to outsource it!

Ralf Bertoldi wrote:
> Ralf Mimoun wrote:
>
>> Almost forgot: if anybody thinks that (s)he can implement such a
>> system, then I would be happy to outsource it!
>
> you have to have another tier that splits and verify's the in-
> Output... MAC adresses and timestamps (like the GUID's) could do
> that...

Not in my case. I don't need to know who did the changes. Using different ID
areas is ugly, but it should work. I also don't need full replication
because only one site (local) will change important data. The other site has
only a simple application to enter additional records.

> You really should do this!!!!!
> I'll take care of your other customers... )

I bet you would

Ralf

Ralf,

<< In theory, that should work. It's the best solution I can imagine, but
that means not much >>

The key is unique record IDs across the multiple sites.  Once that is
accomplished, then the rest is just a matter of comparing records and
inserting/updating/deleting them as necessary.  Your scheme with the autoinc
ranges should work just fine provided that the ranges hold up over time in
terms of the number of records.

--
Tim Young
Elevate Software
www.elevatesoft.com