If you define an upload_fetch or upload_fetch_column_conflict script for a table, the MobiLink server compares the pre-image of an uploaded update to the values of the row returned by the script with the same primary key values. The MobiLink server detects a conflict if values in the pre-image do not match the current consolidated values. The server calls the upload_old_row_insert and upload_new_row_insert scripts followed by the resolve_conflict script when a conflict is detected.

The difference between upload_fetch and upload_fetch_column_conflict scripts is in the criterion the MobiLink server uses to detect a conflict. With an upload_fetch script any difference between the fetched row and pre-image row is treated as a conflict. With an upload_fetch_column_conflict script, only the columns updated by the remote database are compared between the fetched row and the pre-image row. In other words, upload_fetch provides row-based conflict detection, and upload_fetch_column_conflict provides column-based conflict detection.

The upload_fetch script selects a single row of data from a consolidated database table corresponding to the row being updated. There are two ways to use this script. The first way is to select the row with the same primary key(s) and same column values as the uploaded pre-image. If no row is returned, MobiLink server detects a conflict. This method of using the script has the following syntax:

SELECT pk1, pk2, ...col1, col2, ...
FROM table-name
WHERE pk1 = {ml r.pk1} AND pk2 = {ml r.pk2} ...
   AND col1 = {ml o.col1} AND col2 = {ml o.col2} ...

The second way is to select the row with the same primary key, letting MobiLink server compare the fetched row against the uploaded pre-image. If any columns differ, the MobiLink server detects a conflict. This approach works with all synchronizable column types:

SELECT pk1, pk2, ...col1, col2, ...
FROM table-name
WHERE pk1 = {ml r.pk1} AND pk2 = {ml r.pk2} ...

See upload_fetch table event.

The upload_fetch_column_conflict event is the same as upload_fetch, except that with it 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. The upload_fetch_column_conflict event can only be applied to synchronization tables that have no BLOBs.

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.

See upload_fetch_column_conflict table event.

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

 Locking the row on the consolidated database

SELECT column-names from table-name WITH (UPDLOCK) 
  WHERE where-clause

SELECT column-names FROM table-name WITH (HOLDLOCK)
  WHERE where-clause

SELECT column-names FROM table-name
  HOLDLOCK 
  WHERE where-clause

 Example