KK

> But many questions we get:
>
> A.)
> Low level problem:
>
> Two site - two server.
> If we uses timestamp to stamp the modified records, the servers'
> time must have been synchronized.
> If times are not have been synchronized, or the times are different,
> the replicators make incorrect record versions, or the last update
> is updated by prior record version.

Not a good idea, you need triggers to audit when a record is inserted /
updated / deleted. A replication process would then check the audit table
and do the appropriate action in the other database.

A row needs to be owned at one end or another, we developed a system for
changing ownership of a row when it was needed someone logged into another
database. Either in the client or in an additional marshal type application.

You may find that you can do selects from your local DB and updates, inserts
and deletes directly at the main database if the proportion is typically
read 90% mods 10%.

> B.)
> High level - logical - problems:
>
> B.1)
> Master/detail info - inconsistency.
> Some cases we must store redundant informations in the higher logical
> units (why : speed, or other problems).
> For example: billing.
> The bill must have header, and items.
> If the header storing TOTAL SUM, ITEMCOUNT, etc., then:
> In A server, we are modify the bill. We are update item 2, and 3.
> In B server, somebody modify this bill. He/she is update 3, delete 4,
> and insert item 7.
> When the replicators are has been done with this replication, the
> item 2 contain A, item 3,4,7 contain B server modifications.
> In the headers stored the B record state, but because the A update
> item record 2, the header containing wrong TOTAL SUM.

My second solution would do fine with this as long as the sums are done by
triggers. Alternatively you have to organise your tables in such a way as
the details are owned by the header row and ownership (i.e. which datbase
has write access) of header row is what counts. When you want to update the
detail, you check the header to see who owns it. This should be enforced by
triggers.

>
> B.2)
> Foreign Keys:
> M/D.
> Problem 1: how to keep foreign keys to not deleting by other server.
> The FK-s are localized - the FK checks are localized.
> When I deleting an Master, what not used in server A, but used in
> server B; in the replicator I get error, because B uses this Master.
> In this time we get conflict: Master A deleted, Master B not
> deletable.

I'm not sure I get this. The databases should be duplicates in terms of
data etc.

>
> Also problem: we know the order, how to be insert, and modify records.
> But the replicator don't know. If it not follow this order: the repli-
> cation is failed.

By using the audit log, you get the same order.

> What we can do for avoid these problems ?

We have always rolled our own replication as we have found that each
situation, with some careful planning can take huge advantages of business
requirements of the data. I have not looked at the replication SW supplied
by IBPhoenix, but I don't think it deals with multi-site updates to rows
with pre-emptive locking / ownership. Most replication engines I have seen
seem to use post action conflict management, which for me is a no no. I
never want a techy / program to have to decide what is important, when the
user thinks the changes have already been applied.

Just my 2c.

Jason Chapman
JAC2 Consultancy

Training - Development - Consultancy
Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
Troubleshooting projects, QA.....
www: www.jac2.co.uk
Mob: (+44) 07966 211 959 (preferred)
Tel: (+44) 01928 751088

- Come and see me at DCON2003 - 3 talks and a day of preconf training.
- Completed London Marathon 13/4/03 beating my PB by 30 seconds - only �500
short of sponsorship, so if you're feeling generous, throw money at me at
DCON (VICTA - For blind kids).