SQL Anywhere database replication - Still struggling with Update Conflict issues

Author

Still struggling with Update Conflict issues - Bouncing updates

Brian Greiman

2005-04-07, 8:02 pm

ASA 9.01.1964

We are using a datetime_modified column in one of our tables and it is
causing me some grief. Here is my scenario (simplified):
1. Remote database updates key_id in table from 1to 2, then 2 to 3, then 3
to 4.
2. Remote database triggers dbremote to prepare updates to be sent to
consolidate.
3. Remote database updates key_id in table from 4 to 5.
4. Consolidate database applies updates from remote. datetime_modified does
not match for one of updates so original updates are bounced back to remote.
5. Remote database runs dbremote to apply new messages from consolidated.
Bounced updates are applied and remote now shows a key_id value of 4 instead
of the desired 5.

Eventually the system will catch up and be back in synch, but we are finding
duplicate key issues because of the bouncing updates.

Can anybody give me some tips of how to make this work better?

Thanks,
Brian

Rob Waywell

2005-04-11, 8:24 pm

How are you generating the Primary Key values? It sounds like that is a
separate problem that has been exposed now that you have the conflict
resolution issue addressed.

--
-----------------------------------------------
Robert Waywell
Sybase Adaptive Server Anywhere Developer - Version 8
Sybase Certified Professional

Sybase's iAnywhere Solutions

Please respond ONLY to newsgroup

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports:
http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer
"Brian Greiman" <bgreiman@bernicks.com> wrote in message
news:42555885$1@foru
ms-2-dub...
> ASA 9.01.1964
>
> We are using a datetime_modified column in one of our tables and it is
> causing me some grief. Here is my scenario (simplified):
> 1. Remote database updates key_id in table from 1to 2, then 2 to 3, then 3
> to 4.
> 2. Remote database triggers dbremote to prepare updates to be sent to
> consolidate.
> 3. Remote database updates key_id in table from 4 to 5.
> 4. Consolidate database applies updates from remote. datetime_modified
does
> not match for one of updates so original updates are bounced back to
remote.
> 5. Remote database runs dbremote to apply new messages from consolidated.
> Bounced updates are applied and remote now shows a key_id value of 4
instead
> of the desired 5.
>
> Eventually the system will catch up and be back in synch, but we are
finding
> duplicate key issues because of the bouncing updates.
>
> Can anybody give me some tips of how to make this work better?
>
> Thanks,
> Brian
>
>

Brian Greiman

2005-04-11, 8:24 pm

In this case, we are genereating them from our own table
(sy_next_record_key)
.

"Rob Waywell" <rwaywell@no_spam.ianywhere.com> wrote in message
news:425aac29$1@foru
ms-2-dub...
> How are you generating the Primary Key values? It sounds like that is a
> separate problem that has been exposed now that you have the conflict
> resolution issue addressed.
>
> --
> -----------------------------------------------
> Robert Waywell
> Sybase Adaptive Server Anywhere Developer - Version 8
> Sybase Certified Professional
>
> Sybase's iAnywhere Solutions
>
> Please respond ONLY to newsgroup
>
> EBF's and Patches: http://downloads.sybase.com
> choose SQL Anywhere Studio >> change 'time frame' to all
>
> To Submit Bug Reports:
>
http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug
>
> SQL Anywhere Studio Supported Platforms and Support Status
> http://my.sybase.com/detail?id=1002288
>
> Whitepapers, TechDocs, and bug fixes are all available through the
iAnywhere
> Developer Community at www.ianywhere.com/developer
> "Brian Greiman" <bgreiman@bernicks.com> wrote in message
> news:42555885$1@foru
ms-2-dub...
3[color=darkred]
> does
> remote.
consolidated.[color=darkred]
> instead
> finding
>
>

Rob Waywell

2005-04-14, 9:23 am

Are you replicating that table? If so, then the most likely change you need
to make is to not replicate it back up to the consolidated. If you are
replicating it back up to the consolidated, then you may be generating
conflicts on that key pool table which then result in the next value in the
table being set back to an outdated value. If that is the case, then change
it to be one-way replication down to the remote and have a trigger on the
consolidated that removes used values when a new record comes up from the
remote.

--
-----------------------------------------------
Robert Waywell
Sybase Adaptive Server Anywhere Developer - Version 8
Sybase Certified Professional

Sybase's iAnywhere Solutions

Please respond ONLY to newsgroup

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports:
http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer
"Brian Greiman" <bgreiman@bernicks.com> wrote in message
news:425ab894@forums
-1-dub...
> In this case, we are genereating them from our own table
> (sy_next_record_key)
.
>
>
> "Rob Waywell" <rwaywell@no_spam.ianywhere.com> wrote in message
> news:425aac29$1@foru
ms-2-dub...
>
http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug
> iAnywhere
then[color=darkred]
> 3
datetime_modified[co
lor=darkred]
> consolidated.
>
>

Sponsored Links