|
...the answer is out there, but hiding from Google :) In particular, how do I stop the synchronization process for a single remote, wipe out all traces of the synchronization setup for that remote database from both the consolidated and remote databases, and then redefine and restart synchronization? |
|
We don't have an API to kill an active sync on the server side, which I presume is the case you are interested in. At minimal verbosity level (-v) you'll see a message: "The current synchronization is using a connection with ...". This message identifies the RDBMS connection for any given sync. If your RDBMS supports it, you could use the information to kill the connection. For a more programmatic approach, you could use the -vR switch to add the remote ID to all log messages for a sync, and listen in Java or .NET on all log lines, looking for the message above. Then it would just be a matter of what trigger mechanism and/or business logic you would use to kill the RDBMS connection. As to wiping, we instead recommend using a different remote ID (eg. a new GUID), so you start clean. This approach has the advantage that it can be initiated client-side, in most deployment scenarios. Thanks! but... that's an answer to a whole different question... upvoted nonetheless :) In this case there's no sync running, it's a question about how to blow away all static traces of a MobiLink relationship between consolidated and one remote, and then re-establish that static MobiLink relationship (subscription, publication, ML user, whatever)... a step-by-step how-to that someone can follow when they want to "give up and start over" because synchronization is failing for some unfathomable reason.
(16 Jul '12, 12:54)
Breck Carter
2
The on-boarding process varies considerably between deployments, and the effort of resetting can vary accordingly. Most of the customers I've dealt with just regenerate everything from scratch. Nevertheless, for the simplest deployments using SQL Anywhere remotes you would do the following using version 12.0.1: 1) In the remote, drop the synchronization profile(s), drop the subscription(s), drop the synchronization user, and drop the publication(s). Or, just create a new remote database from scratch (usually simpler and less error-prone). Then re-create the publication(s), synchronization user, subscription(s), and synchronization profile(s). Set the remote ID either to NULL (so you'll get a new GUID on first sync) or to the previous remote ID (not recommended). 2) In the consolidated database, call ml_delete_sync_state( user, rid ) Is this closer to what you are looking for? If not, then more details as to the particular problems you are facing would help.
(16 Jul '12, 13:24)
RussC_FromSAP
Replies hidden
Yes, that's exactly what I'm looking for... my templates and samples on the subject are in an unstable not-for-publication state, and I'm feeling lazy on a Monday... :) ... a simple MobiLink setup where the user can't recreate the remote from scratch, BUT wants to kick-start synchronization. In some environments, the remotes were not created by Mobilink in the first place, but are full-tilt databases in their own right, and may have existed long before synchronization was added... and contain massive amounts of data that isn't synchronized at all. In other words, not SUP :)
(16 Jul '12, 15:40)
Breck Carter
|