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:

• Direct row handling
• SendColumnNames (scn) extended option
• Send Column Names synchronization parameter

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.

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.

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 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:

• Handling errors and warnings in event hook procedures
• sp_hook_dbmlsync_all_error
• sp_hook_dbmlsync_communication_error
• sp_hook_dbmlsync_misc_error
• sp_hook_dbmlsync_sql_error

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 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).