Testing a synchronization setup for a customer.
On the first synchronization I notice that everything, including old data, is downloaded to the remote database. It is as if the timestamp has been reset to the client thinks that everything on the consolidated database is updated :( As an example I now get a syncrhonization error from a row last updated 2010-09-30 11:27:49.476000.
When connecting to the Mobilink server I see that each remote database is registered with 15 subscriptions for the same publication and user. Probably there has been created a new one for each time the synchronization is redeployed (that has been done now and then). Is it possible to delete the unused subscriptions ? (The list in DBA.ml_subscription)
EDIT: Came across something in the documentation http://dcx.sybase.com/index.html#1201/en/mlserver/ml-synchtech-s-3939388.html:
This might be my problem. As I copied a setup from another server I might not have copied the client timestamp. Docs state that it is stored in the Sys.SYSSYNC view, but this view is empty on my remote database. That brings me to the question; Where does the Mobilink client store its timestamp and how can I add it to my test setup ?
Well, I must say that these internet forums are one of the things I praise Sybase for when discussing database engines with other people =)
So if I understood this correctly (I want to alter the timestamp only once and only for a given user), lets say I have a mobilink user names mluser and on 13 October 12:00 I knew that the databases were in sync;
Then I can make my ModifyDownloadTimestamp script to do something like this ?
CREATE PROCEDURE ModifyDownloadTimestamp( @download_timestamp DATETIME OUTPUT, @user_name VARCHAR( 128 )) AS BEGIN IF (@download_timestamp < '2012-10-03 12:00') AND (@user_name = 'mluser') THEN SELECT @download_timestamp = '2012-10-03 12:00'; RETURN; END IF; --Default handling goes here SELECT @download_timestamp = @download_timestamp; END
answered 05 Oct '12, 07:59
Another (though obviously undocumented) method might be to simply adjust the values in the ml_subscription ML system table in the consolidated database. From ML's point of view, that's a system table, but from a DBA' point of view it's just another user-defined table.
That's what stored procedures like ml_delete_sync_state_before do, as well, as Russ has pointed towards. However, whereas they generally drop/reset state information, you apparently would need to "correct" values here like the "progress" counter to make them fit those of the remote.
A BIG CAVEAT: Unless you are really aware of the meaning of those values, modifying them is expected to lead to problems.
Note: I've never done that with v12 but had to do so with older versions (v8 in particular).
answered 05 Oct '12, 09:03