Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.

We have an app that synchronizes tables using Mobilink to mobile users (iPads specifically). Every so often we get a support call about some records that exist on the remote, but after a sync do not exist on the consolidated database. But additional records added and updates do sync. These records just sit on the device thinking they've been synchronized and the only way we can get them to sync is to write a script which effectively copy's the rows and inserts them again.

Specifically this seems to happen with highly mobile users who are moving even between timezones, and who synchronize infrequently.

I've given up troubleshooting. It's so infrequent (but does happen), and I haven't been able to reproduce in tests.

Thanks in advance!

asked 09 May '13, 22:30

Jason%20S's gravatar image

Jason S
66226
accept rate: 0%

Have you been able to determine if the "missing" row(s) were sent to the consolidated but not inserted or if the row never gets sent during the sync? What is the consolidated database? Can you provide some insight into the scripts that would be responsible for processing the "missing" row? How does the application manage the changes between timezones?

(10 May '13, 09:13) Chris Keating

What build number are you using?

Can you obtain a database which exhibits this problem?

(13 May '13, 11:48) Tim McClements

To help answer Chris' question, could you provide a verbose MobiLink console log (mlsrv12 -v+ -o mlsrv12.txt) from a time where a remote synchronizes this information, but this information is not seen at the consolidated? Can you confirm everything is committed successfully from a MobiLink perspective?

(13 May '13, 14:10) Jeff Albion
Replies hidden

Hi, Sorry for the late reply. Here's some more info:

Consolidated: MS Sql Server 2008 R2 Remote: Ultrilite iOS 12.0.1.3577 Mobilink: 12.0.1.3554

I can't confirm (or deny) if the missing rows were ever sent and failed, or just never sent. I do know that all of the rows added (even child rows with a foreign key) during that day (the data was sync'd at the end of day) were never applied to the consolidated. But any rows added after the sync at the end of the day were applied and no errors were thrown and synchronization resumed as if nothing happened. I don't believe the "Timezone" has anything to do with it as UTC is UTC, but just wanted to mention it as one of the users mentioned to me that he was in-between timezones throughout the day.

It would be hard to obtain a database which contains the "Zombie" rows as I call them. After I run a script to re-insert the zombie rows, I typically have the user sync, delete, and resync the DB to bring it back to a consistent state. But I can give it a shot.

I see in the lates EBF for Ultralite engine there are some issues addressed regarding circumstances where rows may not get uploaded. I was hoping to gain some insights in to wether it is believed the issues i'm seeing are related to these bug fixes? And if not any ideas as to what could possibly be the issue? Thanks!

(13 May '13, 14:12) Jason S

I think it would be good to update to the latest EBF. Indeed, build 3856+ fixes an obscure issue where concurrent database operations during a synchronization could in theory cause rows to be excluded from upload. To verify this is the issue we would need access to the database file. Failing that you could deploy an update and monitor for recurrences.

permanent link

answered 13 May '13, 14:31

Tim%20McClements's gravatar image

Tim McClements
2.0k1830
accept rate: 35%

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:

×371
×162
×20

question asked: 09 May '13, 22:30

question was seen: 2,978 times

last updated: 13 May '13, 14:31