To handle direct uploads, you write a method for the handle_UploadData synchronization event. This event accepts one UploadData parameter. See:
The handle_UploadData event is usually called once per synchronization. However, for SQL Anywhere clients that use transaction-level uploads, there can be more than one upload per synchronization, in which case handle_UploadData is called once per transaction.
For more information about dbmlsync transaction-level uploads, see -tu option.
For more information about using the handle_UploadData event to process the upload, including a detailed example, see handle_UploadData connection event.
For general information about writing Java or .NET synchronization scripts, see:
For information about registering connection-level events, see:
The MobiLink server APIs for Java and .NET provide the following interfaces for handling direct uploads:
UploadData Encapsulates a single upload transaction. An upload transaction contains a set of tables containing row operations. See:
UploadedTableData Encapsulates a table's insert, update, and delete operations uploaded by a MobiLink client. For Java, UploadedTableData methods return an instance of a JDBC ResultSet. For .NET, UploadedTableData methods return an instance of a standard IDataReader. You traverse the result set IDataReaders to process the uploaded row operations. See:
UpdateResultSet For Java, this class represents an update result set returned by the UploadedTableData getUpdates method. It extends java.sql.ResultSet to include special methods for retrieving the new and old versions of an updated row.See UpdateResultSet. For .NET, the UpdateDataReader interface represents a set of rows returned by the UploadedTableData GetUpdates method. It extends IDataReader to include special methods for retrieving the new and old versions of an updated row. See UpdateDataReader interface.
See handle_UploadData connection event.
Handling conflicts for direct uploads