🚀 go-pugleaf

In our replication we always currently do 1 day for each table, eventhough
in some databases some tables are owned by one DB whilst others by another
DB.  So each is a source and a target.

We did look into how we could have row level ownership (not in the table
itself, but a generic ownership table (advantages and disadvantages to
this).  We could group pyramids of data e.g. a client has their notes, their
bank transactions etc and as such by a database owning the client, we could
avoid conflicts (I think it is unacceptable for a techie to have to resolve
business level conflicts and would avoid at all cost).

To this end, when you goto a client, then you could check / request that
your db owns it.  A server service would have to check to see if you did own
it and if not, organise with the other database migration of ownership.  In
the time of the user interaction, you would have the following happening:
1) Your local DB owns it - fine
2) You didn't own it, but you do now
3) You didn't own it, there are updates pending from a another DB, so you
can't update it until they have propagated - try later.

I worked out for the 100,000 clients on the DB, collision of ownership
requests / updates would be very low.  We could bias the ownership based on
business lifecycle (sales, account set up, general customer services, client
exit team) and as such have 4 databases serving 1000 users no problems in 2
or three different sites.

As it happened, business slumped and it was never required (we were seeing a
10% growth rate per month!).

Just ideas.

JAC


"Jonathan Neve" <jonathan@!nospam!microtec.fr> wrote in message
news:3f012904@newsgroups.borland.com...
> Craig Stuntz [TeamB] wrote:
> > With asynchronous replication your referential constraints can't stop a
> > user on DB 1 from deleting a record referenced by a newly inserted
> > record on DB 2.
> >
> > In the real world, the easiest way to use replication is to establish
> > rules for who can change what which prevent conflicts from happening in
> > the first place and stick to them.  This might mean that "average Joe"
> > users are allowed to insert lookup table entries but not delete them,
> > and that they are only allowed to edit records they create.  Things
> > they edit will be sent to the master DB, and the rest of the DB, which
> > they are not allowed to change, is sent back from the master.
>
> I see. I hadn't though very much about all that. Currently, in my
> application, I make an empty update of the record the user wants to
> delete or update before letting them do so, and if there's a lock
> conflict, I show an error message. This works very well. Do you think
> there would be any way of doing the same sort of thing on the replicated
> system (e.g. Holding the record locked as long as the change hasn't been
> sent to the server)?
>
> How are conflicts handled with IBReplicator?
>
> Thanks,
> Jonathan Neve.
>