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.

Hi All, I am developing an iPad application. My dev environment set up is like

  1. SQL Server 2008 as consolidated database.
  2. SQLAnywhere 12.0.1 EBF 3605 as Mobilink Server.
  3. Ultralite DB as client database on iPad. libulrt.a form 12.0.1 EBF 3577

I have implemented the synchronization model successfully. I have three different publications to synchronize. All are working fine. But if somehow any synchronization failed due to any issue either WIFI connectivity or if already have an open connection from Sybase Central tool. After this failure synchronization won't success for that particular ml-remote-id, no matter how many times i try. I am getting this errors:

Sync failed: -1305 (MOBILINK_COMMUNICATIONS_ERROR) %1:8 %2:7 %3:0

If i try again by changing ml-remote-id same publication will run successfully.
I am stuck with this issue. Please help.

asked 18 Apr '12, 01:38

Gandalf's gravatar image

accept rate: 50%

edited 18 Apr '12, 09:53

Reg%20Domaratzki's gravatar image

Reg Domaratzki

Can you please add "-v+" to the MobiLink start line, and then post the Mobilink Server log with this high verbosity that includes :

1) The last successfull synchornization

2) The failed synchronization that causes the problem

3) The next synchronization that also fails

4) A successfull synchronization after changing the remote-id

Thanks, Reg

(18 Apr '12, 09:55) Reg Domaratzki

Hi Reg Domaratzki,
Thanks for your valuable support and time. I have pasted the Server log after enabling -v+ option in mobilink start up script. You can find the log file Here.

(19 Apr '12, 09:31) Gandalf
Replies hidden

You can only have one sync running at a time for each remote. MobiLink will detect multiple concurrent syncs and will display the following error as seen in the log you posted,

E. 2012-04-19 16:24:17. <7> [-10344] The remote database identified by remote ID '893' is already synchronizing: orphaned UltraLite synchronization detected

MobiLink will try to clean up the scenario and return errors for the syncs it cancels. Concurrent syncs can be caused by the network connectivity disruption that you describe.

Would you be initiating multiple concurrent syncs from your application?

If you wait for more than 240 seconds (default client timeout) before you retry your sync, does it still fail?

The Sybase Central connection to which you refer, is that to your consolidated database?

Could you also post the command line you use to start MobiLink?

(19 Apr '12, 16:53) Bill Frier

Hi Bill,
I am not initiating concurrent sync.
I have tried syncing it after 4 min also that is also resulting to failure.
Yes the Sybase Central is my consolidated database.
My mobilink service initialization command is: -c "dsn=IRISIPAD;uid=IPADSYNC;pwd=tcs#1234" -vcns -o "C:IRISIPADlog.txt" -zu+ -cm 512m I was using this command. I replaced the -vcns option with -v+ as asked by Reg to generate the Log file.

(20 Apr '12, 06:30) Gandalf

It looks like the log file has been truncated. Please post the full MobiLink server log file or the part that contains the previous syncs for remote ID 893 prior to sync <7>. Thanks.

(22 Apr '12, 15:38) Yufei Guo

Hi Gandalf,

Have you resolved this issue? It looks like we are waiting for a more complete log from you in order to proceed.

(02 May '12, 14:19) Tim McClements

Sorry Guys, i was on leave for few days.
No this problem is still there. I am uploading the complete Log file this time. From here you can get the information starting from the successful sync for a remote id and then failure and again subsequent failures for that id. Log file is Here
You can have this info for ml_remote_id = 705 & 707
Thanks in advance for all your support.

(04 May '12, 01:32) Gandalf
Replies hidden

Thanks you for posting the MobiLink server logging file. We have taken a look at the logging file and found you have had completed the first four successful syncs for remote ID 705 and then on the fifth one, the MobiLink server found a mismatch offset and abort the sync. The problem is why there is a mismatch offset for ID 705.

Unfortunately, we still cannot find the source for this problem, because the logging file does not contain any progress offset. Adding MobiLink server logging verbosity, -vep would be helpful. Could you please regenerate a MobiLink server logging file with the MobiLink server command line options, -vep?

It looks like remote ID 705 contains multiple publications. Could you please tell us how many publications remote ID 705 has and what publications you have used for each of the first five syncs (the first four successful syncs plus the fifth unsuccessful sync)?


(04 May '12, 13:51) Yufei Guo

Hopefully, you did not run the fifth sync for remote ID 705 with a backup database. If you backed up the remote database after the third sync and then run the sync with backup database on the fifth sync, this problem can happen. If this is what you wanted and if you are sure it won't lose data, you can reset the sync state for the remote ID in the consolidated database before the fifth sync, then you should not have this problem. To reset the sync state for a given remote ID, you can run the stored procedure named ml_reset_sync_state.

(04 May '12, 14:53) Yufei Guo

Thanks for the support.
My sync model is having 3 publications. 1) Pub1 2) Pub2 3) Pub3.
The very first Sync attempt run all 3 publications sequentially. The next 3 syncs are using Pub1 & Pub3.

The fifth Sync which you saw failing is trying to run all publications as i deleted the project folder from IPAD simulator,as it is a requirement to run all pub if running for first time. but this is just an incident as i have tested this delete project kind of thing many times and this doesn't result to sync failure.

(08 May '12, 06:23) Gandalf

No i am not taking backup of remote DB. The worst thing i am doing is Deleting the App sandbox so that there is no DB file present already, and i can start the Sync sequence again for same ml_remote_id.

(08 May '12, 06:45) Gandalf

The ML server keeps a progress marker (or offset) for each remote ID and publication (in the ML system tables). So when you wipe the remote database and use the same remote ID, you get an error. You should either clear the remote ID (so a new one is generated) or use the ml_reset_sync_state stored procedure in the consolidated.

It's best to reset the remote ID when when you reset the remote database, which is why we now recommend using the ML user or an authentication parameter for data partitioning instead of using the remote ID.

(08 May '12, 11:48) Graham Hurst

Should have said "when you wipe the remote database and use the same remote ID, you might get an error." See comments to answers.

(09 May '12, 11:21) Graham Hurst
More comments hidden
showing 5 of 13 show all flat view

Hi Guys, Thanks a lot to all, especially to Yufei. This got solved too.
I just ran the ml_reset_sync_state SP on server for remote id = 705 and it worked. But here is an observation i would like to share: 1. As Graham mentioned that after wiping the DB file you need to reset the remote id otherwise it will lead to Sync failure, but i have tested this many times and sync will run successfully with same remote id even if i am deleting it from the App Sandbox.

permanent link

answered 09 May '12, 07:47

Gandalf's gravatar image

accept rate: 50%


Thanks. Your observation is right, because the MobiLink server will always accept the initial sync after the remote database is rebuilt.

(09 May '12, 09:11) Yufei Guo
Replies hidden

@Yufei: Thanks for reminding me that special handling of initial syncs had been added in an earlier version (I think it was version 10)!

@Gandalf: You probably saw the problem only after an initial sync failed after sending its upload, eg. because of a network error. In that case, the next sync could check the progress, so my advice still holds unless you can be certain that the first sync after remote reset won't fail.

(09 May '12, 10:54) Graham Hurst

I'm not sure this totally fits, but I'll offer it anyway. When you first synchronize an UltraLite database it automatically takes on a unique remote-id (it generates a UUID to do this, and stores it in the database). The server relies on each remote database having a unique remote-id. If you copy a synchronized database, and subsequently continue synchronizing both copies, the uniqueness requirement will not be met and you will likely encounter errors. (The server log should clearly diagnose this issue.) So, the rule is if you copy a database you must clear the copy's remote-id before synchronizing it. This is done by executing 'SET OPTION ml_remote_id='.

permanent link

answered 18 Apr '12, 13:40

Tim%20McClements's gravatar image

Tim McClements
accept rate: 34%

I am setting the ml_remote_id before synchronizing first time. I am not trying to sync this database copy from any other system. So ml_remote_id uniqueness is preserved. Problem starts after first sync failures.

(19 Apr '12, 01:23) Gandalf
Replies hidden

The uniqueness requirement is not just for a given point in time; there should only be one "sync progress" (or offset) for a remote ID. If you are wiping the remote DB file, and want to re-use a previously used remote ID, you have run the ml_reset_sync_state stored procedure in the consolidated database. Instead, you should not re-use a remote ID when a remote database is recreated - it's a different database after all.

(08 May '12, 15:18) Graham Hurst

As Yufei has clarified, the MobiLink server automatically resets the progress for a previously-used remote ID if it's the first sync since the remote database was created. However if that first sync fails after sending its upload and before the MobiLink server commits its automatic progress reset, the next sync from that remote will fail.

(09 May '12, 11:00) Graham Hurst

Update: In looking back, many holes in the progress checking logic have been filled over the years, so your problem should not be common. I suspect that it may be a case that only happens when using UltraLite remotes with multiple publications that have differing offsets, and following a failed initial sync with a re-used remote ID.

It's best to leave the remote ID alone. If you have been using it for data partitioning or business logic, instead use either the MobiLink user or an authentication parameter.

(09 May '12, 12:03) Graham Hurst

Here's another point which may not apply but is still important :)

As of iOS 5.0.1, you should set the "do not backup" attribute on the database file (see Technical Q&A QA1719).

You should also specify the temp_dir connection parameter with the path to the app's tmp directory (use NSTemporaryDirectory()), so UltraLite's temporary file is not placed in the Documents directory. (By default, the temp file goes beside the database file.)

permanent link

answered 07 May '12, 11:49

Tim%20McClements's gravatar image

Tim McClements
accept rate: 34%

edited 07 May '12, 11:51

Your answer
toggle preview

Follow this question

By Email:

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



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "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:


question asked: 18 Apr '12, 01:38

question was seen: 3,746 times

last updated: 09 May '12, 12:08