🚀 go-pugleaf

In short there are a number of confict resolution things the replicator
does.
in short, if it has an update and the record is being used, it will report a
lock and then update it next time through.


"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.
>