upload_fetch_column_conflict table event

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

Parameters

In SQL scripts, you can specify event parameters by name or with a question mark. Using question marks has been deprecated and it is recommended that you use named parameters. 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 want 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.	N/A
s.username	VARCHAR(128). The MobiLink user name. This parameter is optional.	Optional
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)
r. column-1	Required. The first non-primary key column value, referenced by column name or column number.	N + 1 (N+2 if username is referenced)
...	...	...
r. column-M	Required. The last non-primary key column value, referenced by column name or column number.	N + M (N+M+1 if username is referenced)

Default action

Remarks

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.

Note

Conflict detection is usually performed much faster when done all at once in the upload_update script. See upload_update table event.

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, see Direct row handling.