MobiLink clients

New remote ID MobiLink now uses a new identifier called a remote ID to uniquely identify a remote database. Previous versions used the MobiLink user name. The remote ID is stored in the remote database. MobiLink generates a remote ID the first time a remote database synchronizes (or any time it encounters a NULL value for the remote ID). The remote ID is created automatically as a GUID, but you can set it to any string that has meaning to you. The remote ID lets the same MobiLink user synchronize multiple remote databases. In UltraLite remote databases, the remote ID is also useful for allowing multiple MobiLink users to synchronize the same remote database.
Every script that accepts the MobiLink user name as a parameter now also accepts a remote_id parameter. The remote_id parameter is only available if you use named parameters.

To help you change the remote ID, a new database option is added to both SQL Anywhere and UltraLite databases called ml_remote_id.

See:
- Remote IDs
- MobiLink user names and remote IDs
- SQL Anywhere clients: Setting remote IDs
- UltraLite clients: UltraLite ml_remote_id option
New file transfer functionality New functionality helps you transfer files to remote devices using the same network path you use to synchronize data. SQL Anywhere clients can use the new mlfiletransfer utility, and UltraLite clients can use the new MLFileTransfer method. This functionality is especially useful when populating new remote databases or upgrading software. A new MobiLink event has been added to authenticate the file transfer, if desired. See:
- SQL Anywhere clients: MobiLink File Transfer utility (mlfiletransfer)
- UltraLite clients: Using MobiLink file transfers
- MobiLink server: authenticate_file_transfer connection event
SendColumnNames has changed The SendColumnNames dbmlsync extended option and Send Column Names UltraLite synchronization parameter were previously used to upload information about remote database columns so that the MobiLink server could generate sample synchronization scripts. The creation of sample synchronization scripts has been removed (and replaced with the Create Synchronization Model wizard). SendColumnNames is now used only by direct row handling. See:
Simplified liveness timeout settings Liveness timeout is now controlled by the client. A new network protocol option called timeout is introduced that replaces liveness_timeout, contd_timeout, unknown_timeout, and network_connect_timeout.
See timeout.
Buffer_size enhancements Using the buffer_size network protocol option, you can now control write buffering for TCP/IP protocols as well as HTTP body size for the HTTP protocols. The default values have also changed.
See buffer_size.

UltraLite clients

Palm support for network_leave_open On Palm devices you can now choose whether network connectivity stays open after synchronization finishes. This functionality was available on other platforms in previous releases.
See network_leave_open.
UltraLite enhancements For information on other UltraLite enhancements, see Synchronization.

SQL Anywhere clients

Scripted upload In regular synchronization, dbmlsync uses the transaction log to create the upload, and so synchronizes all relevant data that has changed on the remote database since the last upload. You can now write stored procedures that define exactly what rows get uploaded, and so bypass the use of the transaction log. These stored procedures can perform DML and upload the result set, so the rows can be created dynamically, if required.
See Scripted upload.

Support for scripted uploads has required the following changes to SQL Anywhere system objects:
- New column (sync_type) in the ISYSPUBLICATION system table.
  
  See SYSPUBLICATION system view.
- New catalog objects in the ISYSSYNCSCRIPT system table for tracking synchronization scripts.
  
  See SYSSYNCSCRIPT system view.
- New system procedures convert progress values. See:
  - sa_convert_ml_progress_to_timestamp system procedure
  - sa_convert_timestamp_to_ml_progress system procedure
New scheduling options for dbmlsync When using the EVERY and INFINITE scheduling options, you can now specify that a synchronization does not occur when dbmlsync starts.
See NoSyncOnStartup (nss) extended option.
Download-only publications You can now create publications that only download data. Download-only publications do not use a log file.
See Download-only publications.
Error handling enhancements New event hooks have been added that allow you to process errors reported by dbmlsync on the client.
See:
Stop dbmlsync from enforcing table order By default, dbmlsync issues an error if a child table is uploaded before a parent table. A new extended option allows you to override this behavior.
See TableOrderChecking (toc) extended option.
Persistent connections You can now specify that dbmlsync should keep open the connection to the MobiLink server between synchronizations.
See -pc+ dbmlsync option.
New way to track synchronizations For SQL Anywhere remote databases only, you can now specify a subscription_id parameter in your begin_publication or end_publication script. This value is called sync_id in the SYSSYNC system table. This is an advanced feature that helps you track information about your synchronizations. See:
- begin_publication connection event
- end_publication connection event
dbmlsync now uses ISO 8601 datetime format for message timestamps Timestamps in informational, warning, and error messages now use the non-ambiguous ISO 8601 datetime format: {I|W|E}.yyyy-mm-dd hh:mm:ss message.
Expanded values in #hook_dict The dbmlsync utility exposes hooks and passes values as name/value pairs through a temporary table called #hook_dict. In the past, the values in the #hook_dict table were defined as VARCHAR(255). This has been increased to VARCHAR(10240).

Discuss this page in DocCommentXchange.