I've made one change to the "replication strategy that will work!" since I
posted that topic at the end of May.  It came about through testing and
trying to find a flaw in the logic before my customer did!

I found one and it surprised me.  I call this "silly" because it appears the
replication strategy is so efficient in EDB that I had to modify how I mark
a record locked.

In review, each user of my customer's application is a remote user and
desires both instantaneous updates from other users and the speed of a local
database.  My bi-directional replication strategy was to mark a boolean
"locked" field on the server as True, do the local editing, then let
replication take care of the rest, assuming the locked field would be
cleared when the locally edited record got sent to the server.

But I found that even if I set the local record's locked field to True, then
set it to False when I was done editing, it seemed to be stripped out of the
update that was sent because the value did not change on the server.  The
application has a separate thread for sending/receiving updates and if I
waited for a while, the locked value would go up and then when I finally
finished editing, the locked value, now set back to False, would go up after
that and effectively clear the lock.  But if I made a quick change (I've set
replication to happen every 30 seconds), then the locked value gets set to
True then back to False and is left out of the update (because it's the same
as the original value).  And since I remotely set the locked value on the
server, it doesn't get updated and my record continues to appear locked to
everyone else!

What I needed to do was change the locked value every time there was a
change and never have the new value match the original one, thus forcing the
field to be replicated in each and every case.  So I changed the locked
field from Boolean to integer and incremented it.  Now, ODD values mean
"locked" and EVEN values means "unlocked."  And it works!

The records are unlikely to be changed after a month or so of editing, and
even if they were, the locked value could be incremented every second for
over 63 years before getting close to an integer overflow!

David Cornelius
Cornelius Concepts

David,

If you've published the table containing the "lock" column, then EDB will
log an update any time the "lock" column changes.  However, if the column is
changed to one value, and then changed back, applying those changes in the
same update to another table would result in the *appearance* of nothing
being changed.

Am I understanding your situation at all ?

--
Tim Young
Elevate Software
www.elevatesoft.com

The table is definitely published.  Other fields get replicated to the
remote.  I tried at least a couple of different things.

1. REMOTE: Lock=True; LOCAL: edit fields, make sure Lock=False, post.  Lock
field on remote did NOT get set back to False, I guess because it hadn't
been modified on the local, which means it's an efficient "save updates"
mechanism.  I wouldn't want 53 unchanged fields of a record to get
replicated when only two were changed, for example.

2. REMOTE: Lock=True; LOCAL: set Lock=True (with quick post), edit other
fields, set Lock=False, post.  Sometimes Lock would get set to False,
sometimes not (if I recall correctly).  Here is where if I take a minute or
so to edit the record, the Lock=True value gets replicated, then when I set
it back to False and post the record, it gets switched back to False
correctly.  But if I make a quick change, it gets set to False before the
Save Updates happens and (evidentially) the Lock value is left out of the
updates--again, nice and efficient!

So the solution that works in either case is to simply increment an integer
Lock field every time I want to toggle its state.  That way Save Updates
always picks it up.  


David Cornelius
Cornelius Concepts

David,

<< 1. REMOTE: Lock=True; LOCAL: edit fields, make sure Lock=False, post.
Lock field on remote did NOT get set back to False, I guess because it
hadn't been modified on the local, which means it's an efficient "save
updates" mechanism.  I wouldn't want 53 unchanged fields of a record to get
replicated when only two were changed, for example. >>

Correct, it will only replicate columns that have changed, although I've got
a hidden option in there to always force full-row replication but haven't
surfaced it yet.

<< 2. REMOTE: Lock=True; LOCAL: set Lock=True (with quick post), edit other
fields, set Lock=False, post.  Sometimes Lock would get set to False,
sometimes not (if I recall correctly).  Here is where if I take a minute or
so to edit the record, the Lock=True value gets replicated, then when I set
it back to False and post the record, it gets switched back to False
correctly.  But if I make a quick change, it gets set to False before the
Save Updates happens and (evidentially) the Lock value is left out of the
updates--again, nice and efficient! >>

It won't get left out of the update file, rather the update file will
contain both updates, resulting in a NOP, or the update file will contain
the first update only and the second update file to come later will contain
the second update.

<< So the solution that works in either case is to simply increment an
integer Lock field every time I want to toggle its state >>

Yes, incrementing integer values are very useful for change detection and
versioning.  EDB uses them everywhere.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear David,

Thanks for this, it is really useful to hear how your replication system is progressing. The fact that if the value on the remote computer toggles False/True/False the update isn't captured is important & I will bear it in mind in my own strategy.