To handle direct uploads, complete the following steps:
Register a Java or .NET method for the handle_UploadData connection event.
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 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 an UpdateResultSet. For .NET, UploadedTableData methods return an instance of an UpdateDataReader interface. 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.
Handling conflicts for direct uploads
Discuss this page in DocCommentXchange. Send feedback about this page using email. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |