Invalid sync sequence ID for remote ID [3]

[former_SQLA_member1694889]

Hello everybody,

I have the problem in a productive environment (MobiLink UL 17.0.1211, UltraLite client) that the sync sequence somehow got screwed up.

    I. 2019-08-13 16:38:37. <772053> (,XXX) Request from "UL 17.0.1211" for: remote ID: 80BEC4E6-3E48-4DDE-A2F9-30EA93F8F7B4, user name: XXX, version: XXX
I. 2019-08-13 16:38:37. <772053> (,XXX) Publication #1: XXX, subscription id: 2, last download time: 2019-08-05 18:30:06.140000
I. 2019-08-13 16:38:37. <772053> (,XXX) The sync sequence ID in the consolidated database: 090dbdbcce784081818e66e1783c6689; the remote previous sequence ID: 3095cd779772426d9980f8f5be914c95, and the current sequence ID: 7011acb6b19243e7904dd27b6bf02f02
E. 2019-08-13 16:38:37. <772053> (,XXX) [-10400] Invalid sync sequence ID for remote ID '80BEC4E6-3E48-4DDE-A2F9-30EA93F8F7B4'
I. 2019-08-13 16:38:37. <772053> (,XXX) Synchronization failed

Of course I would be interested to understand why this happened, but more important I need to get the data from the client UDB into my system (billing relevant data).

Is there anyway I can fix the sequece? I am aware of the risks with the transactional data, but in this case we only talk about data that was created on the remote udb and I need to get it into the consolidated somehow. Any suggestions?

Thanks, Alex

[VolkerBarth]

As you are using the old 17.0.0.1211 built, the following FAQs may be of help:

• Invalid sync sequence ID for remote ID 'X'
• Invalid sync sequence ID for remote ID 'X' [2]

[former_SQLA_member1694884 · Accepted solution]

This is hopefully fixed in 17.0.9.4840; you should consider upgrading. Do you have the logs for the last few times the remote 80BEC4E6-3E48-4DDE-A2F9-30EA93F8F7B4 synced? If you have more than one server the remote will likely have syncs on both. If you can get us that we can tell you if it's the same issue.

There isn't a good way to get the remote syncing again. You can call ml_delete_sync_state (http://dcx.sap.com/index.html#sqla170/en/html/81c642976ce21014b84a95a9a6227406.html) to make the server think the remote had never synced before. If you do that, then whatever state the remote is in will get applied, but that can cause problems like primary key errors or updates being applied twice. If there's only a few rows, a safer option is to manually apply the changes to the consolidated.