MobiLink Synchronization Reference
Synchronization Events
Defines the insert cursor that the MobiLink synchronization server uses to insert the new values of rows that were updated in the remote database, but conflict with values presently in the consolidated database.
Use statement-based events for uploadsThis script has been deprecated. Use the statement-based event upload_new_row_insert instead. Support for the new_row_cursor event is likely to be removed from future releases. |
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.
| Item | Parameter | Description |
|---|---|---|
| 1 | ml_username | VARCHAR(128) |
None.
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. Also used to input an INSERT operation in forced conflict mode.
When the MobiLink synchronization server receives an updated row, it compares the original values with the present values in the consolidated database, using the upload_cursor. If the old uploaded values do not match the current value 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 using the old_row_cursor and the new_row_cursor, respectively.
The MobiLink synchronization server uses a cursor to insert the new uploaded values from conflicting rows into the consolidated database. This script contains the SELECT statement used to define this cursor.
It is common practice to use temporary tables to store the old and new versions of conflicting rows. You can create these temporary tables in an earlier script.
You can have one new_row_cursor script for each table in the remote database.
Normally, the columns in the select list must match those in the client table in both order and type. However, the MobiLink synchronization server permits you to add one extra column. If you do so, the MobiLink synchronization server automatically inserts the user name into the first column, then proceeds to insert the new row values using the remaining columns, as usual.
NoteThe script is ignored if any of the following scripts are defined for the same table: upload_insert, upload_update, upload_delete, upload_fetch, upload_new_row_insert, upload_old_row_insert. |
upload_new_row_insert table event
The following SELECT statement defines a new_row_cursor script suited to the CustDB sample application.
SELECT order_id, cust_id, prod_id, emp_id,
disc, quant, notes, status
FROM ULNewOrder FOR updateThe primary key of the ULOrder table is order_id.
The following SELECT statement could instead be used for the same client table. This variation includes the permitted one extra row. The MobiLink synchronization server automatically stores the user name in the first column.
SELECT user_name, order_id, cust_id, prod_id,
emp_id, disc, quant, notes, status
FROM ULNewOrder FOR updateThis script must return valid SQL.
The following stored procedure call registers a Java method called newRowCursor as the script for the new_row_cursor event when synchronizing the script version ver1. This syntax is for Adaptive Server Anywhere consolidated databases.
call ml_add_java_table_script( 'ver1', 'table1', 'new_row_cursor', 'ExamplePackage.ExampleClass.newRowCursor' )
Following is the sample Java method newRowCursor. It dynamically generates a new row cursor statement by calling a Java method.
public String newRowCursor()
{ return( getRowCursor ( _curTable ) ); }