cancel
Showing results for 
Search instead for 
Did you mean: 

Mobilink Error 10012

Former Member
0 Kudos

I get the following error when we have sporadic connection / sync issues.

I am able to fix this by resetting the value in the consolidated database to remote database value or below  (usually make it 0)  then it will finish syncing.

My problem is I may be missing some data at that point, but my only other fix is to reload the whole database

I have tried everything to trap for this event, I would like to be able to insert some logging so we can notify our support team when this happens.

It does not look like the handle_error event is even firing...

W. <18> [10012] The consolidated and remote databases disagree on when the last synchronization took place, the progress offsets are 99 in the consolidated database and 83 in the remote database.  The remote is being asked to send a new upload that starts at the last known synchronization point

E. <18> [-10035] Download failed with client error -794

I have tried  the following events

handle_error / handle_odbc_error events

{CALL ps_error_insert({ml s.action_code}, {ml s.error_code}, {ml s.error_message},  {ml s.username},    {ml s.table} )}

These events only seems to fire when I have an odbc / sql error .

I thought that this would fire for all errors...

end_synchronization event

Insert into SyncStatus(RemoteID,UserID,SyncStatus,ScriptVersion)

Values({ml s.remote_id},{ml s.username},{ml s.synchronization_ok},{ml s.script_version})

This event seems to only fire when i have a successful sync.

Where do i put this trap ?

Thanks

Jay

Accepted Solutions (0)

Answers (1)

Answers (1)

chris_keating
Advisor
Advisor
0 Kudos

The behavior you describe is a feature that is intended to deal with cases of lost connectivity at specific critical points in the synchronization process. You simply need to allow the next sync to clear this disagreement. 

There are some known cases where this state cannot be resolved.

  • If you are replacing a remote or consolidated from a backup, you need to ensure that the backup brings the remote and/or consolidated to a consistent point - for example, you cannot have a remote that has synchronized at a point in time after the consolidated backup restore point. 
  • You must ensure that no two remotes have the same remote id.

If you are seeing a persistent case of this warning which is not explained by the items above, you may be encountering a known issue in pre-v16 software that impacts UltraLite clients only. A workaround is to delay any new synchronization after encountering a connection error at the client by a timeframe at least as long as the timeout period for the MobiLink server.

We can determine if the problem you are encounter is potential related to that know issue with  -vpe logging level in MobiLink  that shows a working remote transitioning to a persistent [10012].

We have addressed this in v16 software. There were two recent changes which are also recommended so using 16.0.0.2178 or later would be recommended if moving to v16.

Former Member
0 Kudos

I believe that the client is erroneously calling a sync finished  when it hasn't, but cant prove this as of yet. Here is how it is fixed today...

Remote Client gets 10012 error.

Sales rep Calls Help desk.

Help desk resets progress for their rid to 0.

Sales rep sync's again, no further issues.

I am fully aware that they may  not have the latest sync but the other option is they download a new data set from scratch. The help desk does reset progress first then forces new download if that didn't work.

I would like to be able to trap for any sync error and run through a process to either fix or log the errors.

The ultralite db is 12.00 and the mobilink server is 16.00.1691

I will upgrade  the Dev environment next week sometime and test for issues as well..

These are the option that I start ML with.

-zp -zs -v -os 3M -ds 4g -x tcpip(port=2439) -zu+ -w 5 -wm 100 -cmax 12g -cinit 6g

We have 500 clients(ultralight) and a db size of around 500M each

Thanks

Jay

chris_keating
Advisor
Advisor
0 Kudos

The error handling scripts are only triggered if the errors occur while executing the scripts. This warning is not an error which is not resulting from a problem with a script.

I would strongly recommend that you update the clients to v16 or modify the application usage so that when a communication error is encountered, there is a delay equal to the MobiLink server timeout to avoid the circumstances in which current v12 software can encounter a persistent warning case.

The only other option is to monitor the MobiLink log for these warnings. However, you need to sure that no action is taken to reset the remotes until it is comfirmed that the warning is persistent otherwise you may reset a remote that is working OK.  For example, the MobiLink server API LogMessage class can be used to monitor the log.

Former Member
0 Kudos

I didn't think of that,  will try to write somthing that looks at that...

I cant upgrade the clients as of yet, It is an outside vendors application and they are working on going to v16+ but I  need something to handle the daily problems. We have over 400 production users so the MobiLink monitor is not really a good option as it gets too big. I would love it if the ML monitor was able to log to an external db so I could do purges etc... I am running v16x server but clients are 12.01.3311. I have updated the ultralite db to 12.01.4301 for the beta version I am working on and fixed all the erroneous warnings that mobilink throws... I will have them update the client (ipad) to 4301 as well to fix a few major bugs that where fixed by that version.

Thanks,

Jay