|
There doesn't seem to be something similar to mobilink server handle_error for the remote/client side of synchronization. There are hook procedures( <list> 1. sp_hook_dbmlsync_all_error 2. sp_hook_dbmlsync_misc_error 3. sp_hook_dbmlsync_sql_error </list>) that all seem to point towards a restart of a failed synchronization session. Has anyone put together a strategy using hook procedures to handle errors such as failed downloads, or unique index errors, or any other client errors? Possibly skipping errors that aren't causing problems with a particular synchronization strategy, etc? Appreciate the help. |
|
The strategy most often used is to design for correct operation on the remote side, and to treat exceptions as bugs in the code that must be removed rather than accommodated. The reason for this bias is that MobiLink itself is heavily biased toward centralized administration, and that if you expect bad things to happen as part of normal operations, you design the synchronization so the symptoms appear while mlsync.exe is running, not dbmlsync.exe. Sometimes, folks try to fight MobiLink's bias toward central administration, and generally their life is one of misery and heartbreak ("sp_hook" is French for "sorrow" :) If you can describe the errors you are expecting, one at a time, folks here may offer some ideas. "Failed download" - too vague to offer suggestions. "Unique index errors on the remote side" - Design these out of your synchronization setup. "Other client errors" - also vague. Note that referential integrity errors on the download are silently handled/bypassed/ignored by default... if you didn't know that, you may be (rightfully) horrified :)... it's another problem that should be designed out. Breck, thank you for the reply. I'll take a look at central administration.
(30 Jan '19, 19:25)
user2359
|
