MobiLink Synchronization Reference
  Synchronization Events

resolve_conflict table event

Function 

Defines a process for resolving a conflict in a specific table.

Parameters 

In the following table, the description provides the SQL data type. If you are writing your script in Java or .NET, you should use the appropriate corresponding data type. See SQL-Java data types and SQL-.NET data types.

Event parameters are optional only if no subsequent parameters are specified. You must use parameter 1 if you want to use parameter 2.

Default action 

None.

Description 

When a row is updated on a remote database, the MobiLink client saves a copy of the original values. The client sends both old and new values to the MobiLink synchronization server.

When the MobiLink synchronization server receives an updated row, it compares the original values with the present values in the consolidated database. The comparison is carried out using the upload_fetch script or, if using cursor-based uploads, the upload_cursor script.

If the old uploaded values do not match the current values in the consolidated database, the row conflicts. Instead of updating the row, the MobiLink synchronization server inserts both old and new values into the consolidated database. The old and new rows are handled using the upload_old_row_insert and upload_new_row_insert scripts, respectively. If you are using cursor-based uploads the rows are handled using old_row_cursor and new_row_cursor, respectively.

Once the values have been inserted, the MobiLink synchronization server executes the resolve_conflict script. It provides the opportunity to resolve the conflict. You can implement any scheme of your choosing.

This script is executed once per conflict.

Alternatively, instead of defining the resolve_conflict script, you can resolve conflicts in a set-oriented fashion by putting conflict-resolution logic either in your end_upload_rows script or in your end_upload table script.

You can have one resolve_conflict script for each table in the remote database.

See also 

upload_old_row_insert table event

upload_new_row_insert table event

upload_update table event

old_row_cursor cursor event (deprecated)

new_row_cursor cursor event (deprecated)

end_upload_rows table event

SQL example 

The following statement defines a resolve_conflict script suited to the CustDB sample application for an Oracle installation. It calls a stored procedure ULResolveOrderConflict .

exec ml_add_table_script(
   'custdb', 'ULOrder', 'resolve_conflict',
   'begin ULResolveOrderConflict();
end; ')
CREATE OR REPLACE PROCEDURE ULResolveOrderConflict()
AS
  new_order_id integer;
  new_status   varchar(20);
  new_notes   varchar(50);

BEGIN
  -- approval overrides denial
  SELECT order_id, status, notes
    INTO new_order_id, new_status, new_notes
    FROM ULNewOrder
   WHERE syncuser_id = SyncUserID;
  IF new_status = 'Approved' THEN
    UPDATE ULOrder o
       SET o.status = new_status, o.notes =
 

new_notes
     WHERE o.order_id = new_order_id;
  END IF;
  DELETE FROM ULOldOrder;
  DELETE FROM ULNewOrder;
END;

Java example 

The following stored procedure call registers a Java method called resolveConflict as the script for the resolve_conflict table event when synchronizing the script version ver1. This syntax is for Adaptive Server Anywhere consolidated databases.

call ml_add_java_table_script(
   'ver1',
   'table1',
   'resolve_conflict',
   'ExamplePackage.ExampleClass.resolveConflict' )

Following is the sample Java method resolveConflict. It calls a Java method that will use the JDBC connection provided by MobiLink. It also sets the action code.

public String resolveConflict( String user,
 String table)
{  resolveRows(_syncConn, user ); }