Provides an event that the MobiLink server uses during processing of the upload to handle rows updated at the remote database.

Parameters

Default action

None.

Remarks

The statement-based upload_update script may perform direct updates of column values as specified in the UPLOAD statement.

The WHERE clause must include all of the primary key columns that are being synchronized. The SET clause must contain all of the non-primary key columns that are being synchronized.

You use as many non-primary key columns in your SET clause as exist in the table, and MobiLink sends the correct number of column values. Similarly, in the WHERE clause, you can have any number of primary keys, but all must be specified here, and MobiLink sends the correct values. MobiLink sends these column values and primary key values in the order the columns or primary keys appear in a MobiLink report of your schema. You can use the -vh option to determine the column ordering for this table schema.

For example, in the following upload_update script, the question marks are in good order:

UPDATE MyTable
  SET column_1 = ?, ..., column_M = ?
  WHERE pk_column_1 = ? AND ... AND pk_column_N = ?

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

For Java and .NET applications, this script must return valid SQL.

To use the upload_update script to detect conflicts, include all non-primary key columns in the WHERE clause:

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

In this statement, col1 and col2 are the non-primary key columns, while pk1 and pk2 are primary key columns. The values passed to the second set of non-primary key columns are the pre-image of the updated row. The WHERE clause compares old values uploaded from the remote to current values in the consolidated database. If the values do not match, the update is ignored, preserving the values already on the consolidated database.

See also

• Script parameters
• Adding and deleting scripts
• Detecting conflicts with upload_update scripts
• Resolving conflicts with upload_update scripts
• upload_delete table event
• upload_fetch table event
• upload_insert table event

SQL example

This example handles updates made to the Customer table in the remote database. The script updates the values in a table named Customer in the consolidated database.

CALL ml_add_table_script(
  'ver1',
  'table1',
  'upload_update',
'UPDATE Customer 
   SET name = {ml r.name}, rep_id = {ml r.rep_id} 
      WHERE cust_id = {ml o.cust_id}')

Java example

The following call to a MobiLink system procedure registers a Java method called uploadUpdateTable as the script for the upload_update table event when synchronizing the script version ver1.

CALL ml_add_java_table_script(
  'ver1',
  'table1',
  'upload_update',
  'ExamplePackage.ExampleClass.uploadUpdateTable' )

Following is the sample Java method uploadUpdateTable. It calls a method called genUU to dynamically generate an UPLOAD statement.

public String uploadUpdateTable() {
  return( genUU(_curTable) ); 
}

.NET example

The following call to a MobiLink system procedure registers a .NET method called UploadUpdate as the script for the upload_update table event when synchronizing the script version ver1 and the table table1.

CALL ml_add_dnet_table_script(
  'ver1',
  'table1',
  'upload_update',
  'TestScripts.Test.UploadUpdate'
)

Following is the sample .NET method UploadUpdate. It calls a method called GenUU to dynamically generate an UPLOAD statement.

public string UploadUpdate() {
  return ( genUU(_curTable) );
}