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.
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:
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.
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.
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 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.
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 Creating models.
-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:
Options for setting cache size are removed The following mlsrv10 options have been removed:
These options have been replaced with the mlsrv10 -cm option, which sets the cache for all synchronizations.
See -cm option.
Options for setting timeout are removed The following mlsrv10 options are no longer required and have been removed:
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:
Old syntax | New syntax in version 10.0.0 | Description |
---|---|---|
-x https_fips | -x https(fips=y;...) | HTTPS with FIPS |
-x rsa_tls | -x tls(tls_type=rsa;...) | TCP/IP with TLS using RSA encryption |
-x rsa_tls_fips | -x tls(tls_type=rsa;fips=y;...) | TCP/IP with TLS using RSA encryption and FIPS |
-x ecc_tls | -x tls(tls_type=ecc;...) | TCP/IP with TLS using ECC encryption |
-x tcpip(security=...) | -x tcpip | TCP/IP |
-x http(security=...) | -x http | HTTP |
See -x 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 option.
Change to verbosity output The mlsrv10 options -vr, -vt, and -vu all output slightly different information:
-vr Now, -vr returns only the upload and download row values. Previously, the upload and download script names and contents were also returned.
-vt Now, -vt returns only the contents of translated scripts. Previously, the original script contents were also returned.
-vu Now, -vu returns all undefined table scripts when the scripts need to be invoked. This includes statistical scripts.
See -v 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 Creating models.
-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:
Statistical property | Description |
---|---|
conflicted_deletes |
In normal upload mode, this is always zero. In forced conflict mode, it returns the total number of uploaded deletes that were successfully inserted into the consolidated database using the upload_old_row_insert script. Previously, this returned the number of uploaded deletes for which conflicts were detected. |
conflicted_inserts |
In normal upload mode, this is always zero. In forced conflict mode, it returns the total number of upload inserts that were successfully inserted into the consolidated database using the upload_new_row_insert script. Previously, this returned the number of uploaded inserts for which conflicts were detected. |
conflicted_updates |
In normal upload mode, this returns the total number of update rows that caused a conflict. In forced conflict mode, it returns the total number of upload update rows that were successfully applied using upload_new_row_insert or upload_old_row_insert scripts. Previously, this returned the number of uploaded updates for which conflicts were detected. |
download_bytes |
This returns the amount of memory used within the MobiLink server to store the download. Previously, this returned the number of downloaded bytes. |
ignored_deletes |
In normal upload mode, this returns the total number of upload delete rows that caused errors while the upload_delete script was invoked, when the handle_error or handle_odbc_error are defined and returned 1000, or when there is no upload_delete script defined for the given table. In forced conflict mode, this returns the total number of upload delete rows that caused errors while the upload_old_row_insert script was invoked, when the handle_error or handle_odbc_error are defined and returned 1000, or when there is no upload_old_row_insert script defined for the given table. Previously, this returned the number of uploaded deletes that were ignored. |
ignored_inserts |
In normal upload mode, this returns the total number of upload insert rows that caused errors while the upload_insert script was invoked, when the handle_error or handle_odbc_error are defined and returned 1000, or when there is no upload_insert script defined for the given table. In forced conflict mode, this returns the total number of upload insert rows that caused errors while the upload_new_row_insert script was invoked, when the handle_error or handle_odbc_error are defined and returned 1000, or when there is no upload_insert script defined for the given table. Previously, this returned the number of uploaded inserts that were ignored. |
ignored_updates |
In normal upload mode, this returns the total number of upload update rows that caused errors while the upload_update script was invoked, when the handle_error or handle_odbc_error are defined and returned 1000, or when there is no upload_update script defined for the given table. In forced conflict mode, this returns the total number of upload update rows that caused errors while the upload_new_row_insert or upload_old_row_insert scripts were invoked, or when the handle_error or handle_odbc_error are defined and returned 1000. Previously, this returned the number of uploaded updates that were ignored. |
upload_bytes |
This returns the amount of memory used within the MobiLink server to store the upload. Previously, this returned the number of uploaded bytes. |
upload_deleted_rows |
In normal upload mode, this returns the total number of rows that were successfully deleted from the consolidated database. In forced conflict mode, this is always zero. Previously, this returned the number of row deletions that were uploaded from the synchronization client. |
upload_inserted_rows |
In normal upload mode, this returns the total number of rows that were successfully inserted in the consolidated database. In forced conflict mode, this is always zero. Previously, this returned the number of row insertions that were uploaded from the synchronization client. |
upload_updated_rows |
In normal upload mode, this returns the total number of rows that were successfully updated in the consolidated database. In forced conflict mode, this is always zero. Previously, this returned the number of row updates that were uploaded from the synchronization client. |
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.
Send feedback about this page via email or DocCommentXchange | Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0 |