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