Mobilink (v9.0.2.3924) Synchronization Error -10023

[former_member1045597]

First, I hope this is the right place for posting this discussion, as I've searched and searched and couldn't find any specific 'Places' for Mobilink or Ultralite... The issue I'll be asking about involves a rather old version of Mobillink and Ultralite (v9.0.2.3924), so I really hope someone has some comments that might help.

This problem pertains to the following Mobilink error message when synchronizing mobile devices containing an Ultralite remote database which has been restored from a backup file (.bak copied to .udb): "Error [-10023] The remote database may have been restored from backup, or perhaps user name 'XYZ' is being used by different remote databases. Set ml_user.commit_state to zero to re-enable synchronizations for this user."

The remote database on the mobile device has indeed been "backed-up and restored" by the mobile application. It simply closes the database and copies the .udb file to another filename with a .bak extension, and then, if the user ever needs to, or the mobile application detects that the current database is corrupt, it can be restored from the backup file, which simply deletes the current database and copies the .bak file to the originally named .udb file. However, we always receive the error message (-10023 noted above) from the Mobilink Server whenever we perform a synchronization operation when using a restored database. I've seen some postings indicating that there's some kind of "internal sequence number or key" in the remote database which is applied during synchronization to determine if the database has been restored, but I've been unable to find answers to the following questions:

1. How does a mobile application "properly" backup and restore a remote database (.udb) file, in-case of corruption, to where Mobilink will not generate this error message?
2. Can we somehow, obtain the "internal sequence number or key" from the current database (even if it's by opening the file in binary-mode and seeking to a byte position) and then use that value to overwrite the one in the backup (.bak) file so when it's restored the Mobilink Server won't notice it during synchronization?
3. Are there any methods to trap and automatically handle this synchronization error [-10023] on the Mobilink Server? Like "somehow" trap this error and execute a stored procedure in the appropriate Consolidated database (Oracle) so that ml_user.commit_state gets set to zero for the user mentioned?

Just looking for ANY kind of solution, and unfortunately, at this time, we do not have the luxury of being able to upgrade to the latest-and-greatest version of Sybase/SQL Anywhere/Mobilink/Ultralite; so that won't be an option.

Any assistance would be greatly appreciated!

Thank you for your time.

[ddeconin · Accepted solution]

Hi,

Your current 'backup' scenario has the problem that, after you used the .bak file, your client database is now de-synchronised from the central DB, so you could have data inconsistencies.

The simplest 'solution' is to use the central database (CDB)  as the 'backup' instead.

If your client database becomes corrupted, simply replace it on the client with the initial empty database that is part of your application and start synchronising to download all data from the central database to the client. This way you'll get a client database that is consistent with the server again and no errors on the ML server.

Regards,

Diether

P.S. Since version 9 is unsupported for a while now, I strongly suggest you invest the time to upgrade to the latest version.

[former_member1045597 · Accepted solution]

Thanks for the reply Diether, but unfortunately that's not a valid solution as we would lose all of the data the user has gathered in the field. The purpose of the backup is to ensure that we don't lose all of the data, only a minimal few records, should the working database become corrupt. Our reference (remote) database schema does not change, so there would never really be any "data inconsistencies" between the Consolidated and Remote databases, so that's not an issue.

I'm actually looking for explicit answers to the three questions I posted, which again are:

1. How does a mobile application "properly" backup and restore a remote database (.udb) file to where Mobilink will not generate the -10023 error during synchronization?
2. Can we somehow, obtain the "internal sequence number or key" from the current database (even if it's by opening the file in binary-mode and reading it from a specific byte position) and then using that value to overwrite the one in the backup file so when it's restored the Mobilink Server won't notice that it's been restored?
3. Are there any methods to trap and automatically handle this synchronization error on the Mobillink Server to update the commit_state to zero?

Can anyone respond specifically to these questions?

Thank you.

[regdomaratzki · Accepted solution]

1) The -10023 error occurs because you have taken a copy of the UDB file, the original database synchronizes successfully, and then you later attempt to synchronize again with the older copy of the UDB file.  The only way to "properly" backup and restore a remote database without generating a -10023 error is to not synchronize.

2) No.  That would require internal knowledge of the format of the UDB file, which we do not publish.

3) I'm not sure you'd want to.  See my comments below.

I still believe that recovery from the consolidated database as Diether suggested is a viable option.  The fact that when you "recover" the older UDB file and get a -10023 error tells me that there has been a synchronization of the original UDB file since the backup was taken.  That means that the data in the consolidated database for this remote database is actually more recent than the data in the UDB file you backed up.  If your goal is to recover as many operations in the local UDB file as possible, recovering from the consolidated database is usually the best option.

Reg Domaratzki

SAP Canada – SAP Labs Waterloo – SQL Anywhere Sustaining Engineering

[former_member1045597 · Accepted solution]

Thank you Reg and Diether!

I did not realize that the error (-10023) indicated the current database was synchronized, but we failed to update the backup copy!! This tells me that our code is not always updating the backup copy after every synchronization; correct? If so,  then we'll need to ensure the backup is always updated on each sync.

Thank you both, very much!!

[former_member1045597 · Accepted solution]

Just an update, but now that our application is backing up the database after every type of synchronization operation, we no longer receive the error message from the Mobilink Server when using a restored copy of the remote database during synchronization!

Thanks again for pointing out the cause of the error.

P.S. The user-interface for this website is horrible! It locks-up if I try to paste text into it. It doesn't properly highlight text when holding-down the shift key and using the arrow keys. Terrible UI.

[jeff_albion · Accepted solution]

Hi Greg,

P.S. The user-interface for this website is horrible!

I'm not sure if this helps, but we do have an alternate "stackoverflow-like" forum for SQL Anywhere which you might find more familiar:

  http://sqlanywhere-forum.sap.com/

Also, the SCN team has plans to migrate to a new platform going forward - see: http://scn.sap.com/community/about/blog/2015/03/20/the-long-run

Regards,

Jeff Albion

SAP Active Global Support