Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 17 » MobiLink - Server Administration » MobiLink events » Synchronization events

upload_fetch table event

A data script that fetches rows from a synchronized table in the consolidated database for row-level conflict detection.


In SQL scripts, you can specify event parameters by name or with a question mark. Using question marks has been deprecated. Use named parameters instead. You cannot mix names and question marks within a script. If you use question marks, the parameters must be in the order shown below and are optional only if no subsequent parameters are specified (for example, you must use parameter 1 if you are going to use parameter 2). If you use named parameters, you can specify any subset of the parameters in any order.

Parameter name for SQL scripts Description Order (deprecated for SQL)

s. remote_id

VARCHAR(128). The MobiLink remote ID. You can only reference the remote ID if you are using named parameters.

Not applicable

s. username

VARCHAR(128). The MobiLink user name. This parameter is optional.

s. script_version VARCHAR(128). Optional IN parameter to specify that the MobiLink server passes the script version string used for the current synchronization to this parameter. Question marks cannot be used to specify this parameter.

Not applicable

r. primary-key-1

Required. The first primary key column value, referenced by column name or column number.

1 (2 if username is referenced)

r. primary-key-2

Required. The second primary key column value, referenced by column name or column number.





r. primary-key-N

Required. The last primary key column value, referenced by column name or column number.

N (N+1 if username is referenced)
Default action



The upload_fetch script is a companion to the upload_update event.

The columns of the result set must match the number and order of columns being uploaded from the remote database for this table. If the values returned do not match the pre-image in the uploaded row, a conflict is identified.

Do not use READPAST table hints in upload_fetch scripts. If the script skips a locked row using READPAST, the synchronization logic thinks that the row was deleted. Depending on what scripts you have defined, this either causes the uploaded update to be ignored or it triggers conflict resolution. Ignoring the update is likely to be unacceptable behavior, and may be harmful. Triggering conflict resolution may not be a problem, depending on the resolution logic you have implemented.

You can have only one upload_fetch or upload_fetch_column_conflict script for each table in the remote database.

This script must be implemented in SQL. For Java or .NET processing of rows, use direct row handling.

This script may be ignored if none of the following scripts are defined: upload_new_row_insert, upload_old_row_insert, and resolve_conflict.

SQL example

The following SQL script is taken from the Contact sample and can be found in %SQLANYSAMP17%\MobiLink\Contact\build_consol.sql. It is used to identify conflicts that occur when rows updated in the remote database Product table are uploaded. This script selects rows from a table also named Product, but depending on your consolidated and remote database schema, the two table names may not match.

CALL ml_add_table_script(
  'SELECT id, name, size, quantity, unit_price
   FROM Product 
   WHERE id={ml}' )