Cursor-based uploads removed   The following scripts were deprecated in version 9.0.0 and are now removed: upload_cursor, new_row_cursor, and old_row_cursor. You should instead use statement-based scripts.

See Scripts to upload rows.

Unrecognized scripts cause the synchronization to fail   If the MobiLink server encounters any unrecognized table-level or connection-level scripts, it will abort the synchronization. In previous versions, unrecognized scripts only resulted in a warning message. This means that the presence of cursor-based upload scripts cause the synchronization to abort.

Errors in upload or download scripts cause the synchronization to fail   The synchronization now always aborts if the MobiLink server encounters errors with upload or download scripts. Previously, the MobiLink server did not always abort the synchronization.

The handle_error and handle_odbc_error events work in a more restricted fashion   The handle_error and handle_odbc_error scripts are now only called when an ODBC error occurs while MobiLink is processing an insert, update, or delete script during the upload transaction, or is fetching download rows. If an ODBC error occurs at another time, the MobiLink server will call the report_error or report_odbc_error script and abort the synchronization.

Authentication scripts committed   If there is no error, the MobiLink server always commits the transaction after invoking an authenticate_user, authenticate_user_hashed, or authenticate_parameters script, even if the authentication fails. Previously, transactions involving failed authentication were rolled back, so there could be no record of failed attempts to authenticate. See:

• authenticate_user connection event
• authenticate_user_hashed connection event
• authenticate_parameters connection event

Changes to authenticate_user_hashed script   The authenticate_user_hashed script can now be called more than once during an authentication sequence for a user.

See authenticate_user_hashed connection event.

When a begin script is called, its end script is called regardless of the success of the synchronization   There are several MobiLink scripts that have a begin and end form, such as begin_connection and end_connection. In the past, the end script was often not executed if the synchronization failed. Now, if the begin script is called, the end script is always called (if it is defined), even if the synchronization has errors.

See Synchronization events.

Upload scripts are not called for a table when there is no data to upload   In previous versions, you could use the -us option to prevent the MobiLink server from calling upload scripts when there is no data to upload. The -us option is now removed and by default, the MobiLink server only invokes upload scripts when the upload stream contains data to upload. You can revert to the old behavior using the -zus option.

See -zus mlsrv12 option.

SQL Anywhere 10 and Microsoft SQL Server 2005 consolidated databases should not change the isolation level in the begin_connection script   For SQL Anywhere version 10 and Microsoft SQL Server 2005 and later, the default isolation level for downloads is now snapshot. This means that the isolation level may be changed at the beginning of the download transaction, in which case any setting from the begin_connection script is overridden. Therefore, you should change the isolation level for downloads in the begin_download script or use the new mlsrv10 -dsd option to disable snapshot isolation. Previous documentation recommended changing the isolation level in the begin_connection script, and this is still good practice for consolidated databases that do not use snapshot isolation.

See MobiLink isolation levels.

example_upload_cursor, example_upload_delete, example_upload_insert, and example_upload_update table events are removed   As a result of removing the -za and -ze MobiLink server options, the example_upload_cursor, example_upload_delete, example_upload_insert, and example_upload_update table events are no longer generated. You can now generate scripts using the Create Synchronization Model wizard.

See Setting up a MobiLink application with the Create Synchronization Model Wizard.

-w and -wu options have changed   The -w and -wu options set the number of database worker threads and maximum number of uploading database worker threads, respectively. In previous versions, these worker threads performed every aspect of synchronization, including reading and writing to the network, unpacking and packing protocol bytes and row data, running scripts, and updating and fetching rows in the consolidated database.

Now the worker threads affected by -w and -wu are database worker threads. These database worker threads are solely responsible for all database activity, and nothing more. Other threads are responsible for network activity, packing and unpacking, and all other MobiLink server activities.

The new behavior of the -w and -wu options is independent of network activity. In previous versions, networks with high latency could cause worker threads to block, requiring some deployments to specify a large number of worker threads. The new MobiLink architecture removes this requirement.

The -w and -wu options are still the simplest way to limit the load that the MobiLink server puts on the consolidated database. Testing -w and -wu values can help you find the best throughput for your synchronization system. See:

• -w mlsrv12 option
• -wu mlsrv12 option
• MobiLink performance

Options for setting cache size are removed   The following mlsrv10 options have been removed:

• -bc
• -d
• -dd
• -u

These options have been replaced with the mlsrv10 -cm option, which sets the cache for all synchronizations.

See -cm mlsrv12 option.

Options for setting timeout are removed   The following mlsrv10 options are no longer required and have been removed:

• contd_timeout
• unknown_timeout

Them mlsrv10 liveness_timeout option has also been removed. It is replaced by the timeout option for synchronization clients.

See timeout.

Backlog option no longer required   The mlsrv10 backlog option is no longer required and has been removed.

Changes to protocol names and options for network security   The following network protocol keywords have been removed: https_fips, rsa_tls, rsa_tls_fips, ecc_tls; as well as the network protocol option security. The protocols are not removed, but you specify them differently now. The mlsrv10 -x syntax has changed as follows:

See -x mlsrv12 option.

Change to -bn option   The mlsrv10 -bn option compares BLOB bytes during conflict detection. Previously, characters were compared for data of type LONGVARCHAR. Now the units that are compared are always bytes for both binary and LONGVARCHAR BLOBs.

See -bn mlsrv12 option.

Change to verbosity output   The mlsrv10 options -vr, -vt, and -vu all output slightly different information:

See -v mlsrv12 option.

MobiLink server options -za and -ze are removed   Automatic script generation provided by the MobiLink server -za option and -ze options has been removed. You can now generate scripts using the Create Synchronization Model wizard.

See Setting up a MobiLink application with the Create Synchronization Model Wizard.

-zac and -zec are removed   The MobiLink server options for generating cursor-based scripts, -zac and -zec, were deprecated and are now removed.

MobiLink server option -oy is removed   The mlsrv10 -oy option, which showed the year in timestamps, has been removed. The year is now always shown in timestamps in informational, warning, and error messages.

Changes to statistical properties   There are two general changes:

The following statistical properties have changed:

See MobiLink statistical properties.

Null characters can now be synchronized to and from columns with CHAR or NCHAR data types in the remote database   Previously in MobiLink, VARCHAR and CHAR column values containing null characters could cause a synchronization to fail. Now you can synchronize null characters in remote database columns of data type CHAR, VARCHAR, LONG VARCHAR, NCHAR, NVARCHAR, AND LONG NVARCHAR.

New format for logging information, warning, and error messages   Previously, the MobiLink server logged messages in the following format:

T.mm/dd hh:mm:ss. thread_id User_name: message

Now, the MobiLink server logs messages in the following format:

T. yyyy-mm-dd hh:mm:ss. synchronization_id: message

For each synchronization, the first message in the log shows the remote ID, user name, script version, and client name (UltraLite or SQL Anywhere).

The new format reduces the size of the output log without reducing the information that is provided.

New data type in system procedures for Oracle   In MobiLink system procedures that are used to register scripts, the script contents parameter now uses the CLOB data type for Oracle consolidated databases. In the ml_add_property system procedure, the prop_value parameter is now CLOB for Oracle. Previously, these parameters were type VARCHAR.