Best practices for running multiple synchronization profiles (MobiLink) ?

[Former Member]

Our clients have different replication needs; some want this, some want that, some want both.

This leads to an unhappy replication maintainer (me) since changes to common logic often involves changing ( +testing, deployment) multiple customer-specific profiles.

To avoid this I have started to look into how I can split the synchronization profiles in smaller parts. Instead of having these large profiles I want to have a lot of smaller sync profiles common for all customers. Then they can choose what parts and profiles they want to set up.

ATTEMPT 1, Two synchronization profiles - Profile1 & Profile 2

After having deployed the profiles from the MobiLink project in Sybase Central this is the .cmd file that will perform synchronization for the client:

@ECHO OFF
SET DBMLSYNC=C:\\Program Files\\SQL Anywhere 12\\Bin64\\dbmlsync.exe
SET DBNAME=remotedb_1
SET DEFAULTS=uid=dba;pwd=***;commlinks=tcpip
SET LOGDIR=C:\\***
SET SASERVICE=***

SET SYNCPROFILE1=Profile1
SET SYNCPROFILE2=Profile2

"%DBMLSYNC%" -c "eng=%SASERVICE%;dbn=%DBNAME%;%DEFAULTS%" -v+ -sp "%SYNCPROFILE1%" -ot "%LOGDIR%\\mlclient_%DBNAME%(%SYNCPROFILE1%).log
"%DBMLSYNC%" -c "eng=%SASERVICE%;dbn=%DBNAME%;%DEFAULTS%" -v+ -sp "%SYNCPROFILE2%" -ot "%LOGDIR%\\mlclient_%DBNAME%(%SYNCPROFILE2%).log

It works, however some lines in the client log file caught my attention.

From Profile 1:

I. 2012-10-10 10:40:08. Subscription 'Profile2' - Not Synchronizing - Log offset 0001880549 - Last download time 2012-10-10 10:39:42.429.
I. 2012-10-10 10:40:08. Subscription 'Profile1' - Synchronizing - Log offset 0001880139 - Last download time 2012-10-10 10:39:22.282.

Profile 2:

I. 2012-10-10 10:39:41. Subscription 'Bedrift CorporateRemote' - Not Synchronizing - Log offset 0001880139 - Last download time 2012-10-10 10:39:22.282.
I. 2012-10-10 10:39:41. Subscription 'Klassifisering CorporateRemote' - Synchronizing - Log offset 0001879755 - Last download time 2012-10-10 10:15:24.217

ATTEMPT 2, multiple publications in the same profile

To me, it seems like I can perform synchronization for both subscriptions in one go.

First, I tried to create a new synchronization profile and let this profile include the Profile1 and Profile2 subscriptions generated by the deployment wizard and I tried this:

create or replace synchronization profile SyncAll's=Profile1,Profile2;mp="***"'

.. and updated the .cmd file to sync only this profile (-sp "SyncAll"). When synchronizing I get this:

E. 2012-10-10 11:00:49. Subscriptions Profile1 and Profile2 cannot be synchronized together because they have different script versions.

First thing I thought for myself was "Of course they have different script versions, why would I set up duplicate synchronization for the same script version?", but I'm pretty sure I've missed something.

They do have different script versions, "Profile1 ver 1" and "Profile 2 ver 1". I suspect I would create a lot of havoc in the consolidated database if I started to deply several models with the same script version (don't know if it's even allowed, I haven't dared to try).

Is another way to synchroniza multiple subscriptions in one go ? My first attemt does work, but it seems a bit cumbersome to call dbmlsync.exe once for each publication I want to synchronize.

• Both publications cover a separate subset of data
• One dataset/publication may depend on another, in that case I need to set the order of synchronization.
• Per remote database, all subscriptions are subscribed by the same remote user.
• All publications/subscriptions/sync profiles target the same consolidated database.

[VolkerBarth]

AFAIK, dbmlsync -s can be used multiple times, and it makes a difference whether you use "-s sync1,sync2" or -s sync1 -s sync2". What happens when you specify "s=Profile1;s=Profile2;..." in the sync profile?

[Former Member]

Yes, the subscriptions and sync profiles have the same name. That's why that works 😃

-sp Profile1 and -sp Profile2 does not work, dbmlsync runs the Profile1 sync profile and ignores Profile2, so I think I'll stick to -s Profile1 -s Profile2 for now.

[Former Member · Accepted solution]

Setting -s "Profile1, Profile2" as åarameters to dbmlsync.exe gives me E. 2012-10-10 13:00:48. Subscriptions Profile1 and Profile2 cannot be synchronized together because they have different script versions.

Same if I set both subscriptions in one sync profile and try to sync that one only.

-s Profile1 -s Profile 2 works. However, I encountered something strange there. I have to specify the password as a parameter to dbmlsync (-mp ***). Setting the same password as the MobiLinkPwd extended option for the Synchronization Subscription does not work. That just gives me E. 2012-10-10 13:09:26. Invalid MobiLink username, password or script version. and I have to specify the password in a dbmlsync popup window.

[VolkerBarth · Accepted solution]

When using "dbmlsync -s Profile1 -s Profile2" you are specifying two subscriptions but not two synchronization profiles. Therefore I'm surprised that this does work at all. Or are your subscriptions and sync profiles identically named?

As such I would (wildly!) guess that the rest of the command line parameters is then applied to both subscriptions (but may not fit to both).

What happens when you use "dbmlsync -sp Profile1 -sp Profile2" to specify both sync profiles? (I even don't know of this is allowed - but if so, it should allow to use different options like mp or u as these can be specified differently for both sync profiles.)

[Former Member]

Just to be clear, while deploying different sync models to the same script version likely won't work, you can have different subscriptions synchronizing to the same script version. This would mean leaving the comfort zone of the modeller and going a more manual route.

Also, you can specify script versions in many different places, including at the subscription level. One option is to remove the ScriptVersion (sv) option from the subscription level and always specify it on the command line. This would avoid the "cannot be synchronized error" above.