The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

We have the following problem with SQL Anywhere 12.1 (latest EBF applied).

The client starts synchronization through a stored procedure that calls start synchronization. The stored procedure is called from the application about every 10 minutes.

Sometimes we have the following entry in the log but we're sure that nobody cancels the synchronization (there's nothing built in to cancel it).

1917,5,7/11/2012 6:36:27 AM,DBSC_EVENTTYPE_ERROR_MSG,0,Stopping synchronization at user's request.

I would have loved to attached the logs to the task but according to the system "Uploading Images is allowed to users with 100 point or more". So logs are below.

Any Ideas?

Arthur

Client Log

Server Log

asked 15 Jul '12, 04:42

Arthur%20Hefti's gravatar image

Arthur Hefti
1668816
accept rate: 0%

edited 15 Mar '13, 21:12

Mark%20Culp's gravatar image

Mark Culp
22.3k9129262


Check out this warning in the server log...

W. 2012-07-11 06:36:26. <64> (,74) [10012] The consolidated and remote databases disagree on when the last synchronization took place, the progress offsets are 4080110242 in the consolidated database and 4080024780 in the remote database. The remote is being asked to send a new upload that starts at the last known synchronization point

...did the next upload work? The two logs look like they were cut off.

permanent link

answered 15 Jul '12, 07:52

Breck%20Carter's gravatar image

Breck Carter
26.6k418576824
accept rate: 21%

Thanks for the hint. The next uploads didn't work as well, all contain the same message.

Two things that I find interesting: 1. I assume that I have to read the message "4080110242 in the consolidated database and 4080024780 in the remote database" as that the synchronization on the server is more advanced that the client thinks. Doesn't the client fix this automatically? When looking at the client log it starts sending from the offset requested from the server. 137,5,7/11/2012 6:36:26 AM,DBSC_EVENTTYPE_INFO_MSG,0,Subscription 'CATTORSync' - Synchronizing - Log offset 04080024780 - Last download time 2012-07-11 01:05:14.359. ... 140,5,7/11/2012 6:36:26 AM,DBSC_EVENTTYPE_INFO_MSG,0,Log scan starting at offset 04080110242 ... 147,5,7/11/2012 6:36:26 AM,DBSC_EVENTTYPE_INFO_MSG,0,Subscription 'CATTORSync' - Synchronizing - Log offset 04080110242 - Last download time 2012-07-11 01:05:14.359.

  1. From the server log. Each try from the remote database starts at a later offset. 4080113170 in the consolidated database and 4080024780 in the remote database 4080114552 in the consolidated database and 4080024780 in the remote database

As it looks from the logs that the user quit the application and started it a couple of hours later. The synchronisation went without errors. The problem is, that we still have some records that are not synchronized from the remote to the consolidated database.

Regards Arthur

(16 Jul '12, 00:38) Arthur Hefti
Replies hidden
1

Sync problems like this are notoriously hard to debug, and require a careful look at all the evidence... the entire logs, the schema, the exact parameters used to launch mlsrv12.exe and dbmlsync.exe, and so on... and it can be hard to find folks willing to spend the time on a volunteer (i.e., free) basis.

Sometimes, it isn't worth the effort... for example, it may take many hours of work and success is not guaranteed, and if it is an isolated incident (i.e., one remote out of many is having a problem) it may be easier and cheaper to reset synchronization for that remote; i.e., drop/delete all the synchronization definitions for that remote, from the consolidated and remote databases, then manually rescue the missing changes from the remote and apply them to the consolidated database, and finally redefine/restart the synch definitions.

On the other hand, there may be a flaw in the schema or synch setup that will cause this symptom to appear again and again, and in that case, even if you do "restart the synch", you still have to investigate. The fancier your synch setup, the more likely a subtle flaw exists... that's just experience talking :)

(16 Jul '12, 06:57) Breck Carter
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×404
×266
×66
×15
×3

question asked: 15 Jul '12, 04:42

question was seen: 1,261 times

last updated: 15 Mar '13, 21:12