Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 5 of 5 total |
Silly Replication Gotcha |
Tue, Aug 9 2011 1:34 AM | Permanent Link |
David Cornelius Cornelius Concepts | 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 |
Tue, Aug 9 2011 5:12 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, Aug 10 2011 12:20 AM | Permanent Link |
David Cornelius Cornelius Concepts | 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 |
Wed, Aug 10 2011 2:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Sat, Aug 13 2011 11:28 AM | Permanent Link |
Adam Brett Orixa Systems | 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. |
This web page was last updated on Wednesday, June 12, 2024 at 01:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |