|
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. |
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. |
2 |
|
... |
... |
... |
|
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) |
None.
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.
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(
'ver1',
'Product',
'upload_fetch',
'SELECT id, name, size, quantity, unit_price
FROM Product
WHERE id={ml r.id}' )