Skip to Content
0

change in synchronized tables with mobilink Remote / Consolidated

Feb 24, 2017 at 07:56 PM

134

avatar image
Former Member

Hi all,

I am using the version 10 of Sql Anywhere, where the mobilink is applied and the syncrhonization is running since long time.

Now I want to do some changes on one of the synchronized tables T1 (i.e. I want to add a new column in T1 which was already synchronizing correctly before) and have the following questions:

1- On the consolidated side, I need to amend the event scripts, so that I need to call the procedure "ml_add_lang_table_script_chk", for the download_event_cursor, and for T1....

The question is: Which parameter should I pass to this procedure as the last parameter (it looks something like checksum value).

What will be the result if I passed a wrong checksum value?

Actually the script will be updated correctly in the mobilink tables.

2- On the remote side, I will remove the table from the publication P1, alter the table T1 and then bring the table T1 again in the publication P1.

A. Alter publication P1 delete table T1.

B. Alter table T1 add column.....

C. Alter publication P1 add table T1.

The question is here, what is the risk in this approach? Why sometimes I have the table no more participating in the syncrhonization? Despite the table is still existed in the SYSARTICLES, but actually the table is no more syncrhonizing!!

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Best Answer
Chris Keating
Feb 27, 2017 at 04:31 PM
1

There are a number of procedures that are for internal use only. The ml_add_lang_table_script_chk is an internal procedure and should not be used. The documentation outlines the purpose of each "public" system procedure and identifies those that are internal.

If you want to update a script, you simply call ml_add_table_script() and MobiLink will do the work to modify the script in the system tables. That said, updating the schema of a table would benefit from creating a new script version and scripts unless you are able to ensure that the remote schemas are updated to reflect the new consolidated schema before synchronzition.

For performance reasons, scripts are cached once unless MobiLink. MobiLink can be configured to look for such changes but that is generally only recommended for development. As a result, you will generally need to restart MobiLink to pick up the changes.

If you sync environment is not working after the approach above, it may be that the MobiLink server was not restarted or the remotes.

Show 4 Share
10 |10000 characters needed characters left characters exceeded
Former Member

Hi, thanks for the reply.

Could you then assure that as long as:

1- The amended table is existed in SYSARTICLES (on remote side).

2- The table-level scripts corresponding to the amended table are existed in ML_SCRIPT (on consolidated side).

Then the synchronization should run correctly for this amended table? Having that the other tables included in the same publication are being synchronizing correctly.

Thanks again

0

Have you followed the "official" steps listed here(for v10.0.1)?

Schema upgrades for SQL Anywhere remote databases

Particularly, have you ensured that no other connection is using the table to be changed while it is dropped from the publication? Or have you used the "sp_hook_dbmlsync_schema_upgrade" hook?

1
Former Member
Volker Barth

Dear Volker,

thanks for the reply,

Actually I have never used "sp_hook_dbmlsync_schema_upgrade", but I used the traditional way on the remote using the following commands:

1- Alter publication P1 delete table T1

2- Alter table T1 add Column1

3- Alter publication P1 add table T1

I can confirm that during the execution of each of above commands no connection with the consolidated was existed, but do you think that it could cause a problem if the synchronization is started between 1 & 2 (after finishing the command 1 and before issuing the command 2)?

My problem is that SOMETIMES the whole table T1 comes out of synchronization (problem arising from remote side), although the table is existed in SYSARTICLES on remote.

Thanks in advance

0

> do you think that it could cause a problem if the synchronization is started between 1 & 2...

I would think it is expected that there is no synchronization at all of the remote database between dropping the table from the publication, altering it and adding it back to the publication, i.e. between your steps 1 and 3.

In the cited official steps, note that there is no synchronization between steps 3 and 7, and the last sync before the schema change (there the sync from step 3) must have been successful.

When you use the "sp_hook_dbmlsync_schema_upgrade" hook, IMHO you do not need to drop and re-add the table from/to the publication, as the hook is called in the sync process itself, and is therefore handled by the ML client "just in the right order". (That's true for v10 and v11, newer versions should use the START/STOP SYNCHRONIZATION SCHEMA CHANGE statements. Note, even v12.0.1 is now EOL'ed.)

1
avatar image
Former Member Feb 27, 2017 at 08:21 AM
0

BTW, what is the difference between "ml_add_lang_table_script_chk" and "ml_add_table_script"?

Don't the both procedures add table scripts on consolidated?

Thanks in advance

Sarkis

Share
10 |10000 characters needed characters left characters exceeded