|
A data script that fetches rows from a synchronized table in the consolidated database for column-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. pk-column-1 |
Required. The first primary key column value, referenced by column name or column number. |
1 (2 if username is referenced) |
| ... | ... | ... |
|
r. pk-column-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_column_conflict script is a companion to the upload_update event.
This script can only be defined for remote tables that have no BLOBs.
With this script, the MobiLink server only detects a conflict for a row when the same column was updated on the remote database and the consolidated database since the last synchronization. Different users can update the same row without generating a conflict, as long as they don't update the same column.
For example, using the upload_fetch_column_conflict script, you could avoid detecting a conflict when one of your remote users updated the quant column of the ULOrder table, and another remote user updated the notes column for the same row. You would only detect a conflict if they both updated the quant column.
When using an upload_fetch_column_conflict script and no conflict is detected, the row values passed to your upload_update script come from either the remote database's upload or the current consolidated values from your upload_fetch_column_conflict script. The remote database's value is used for columns that were updated on the remote database, otherwise the current consolidated value is used. In other words, only the columns that were updated on the remote database are updated in the consolidated database.
You can have only one upload_fetch or upload_fetch_column_conflict script for each table in the remote database.
This script may be ignored if none of the following scripts are defined: upload_new_row_insert, upload_old_row_insert, and resolve_conflict.
This script must be implemented in SQL. For Java or .NET processing of rows, use direct row handling.