MobiLink server changes

Changes to MobiLink scripts
  • 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 Writing 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:

  • 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 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 Creating models.

mlsrv10 changes
  • -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:

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

    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:

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

    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.

Statistical properties
  • Changes to statistical properties   There are two general changes:

    • The meaning of byte counts for upload and download have changed. The counts now reflect the amount of memory used within the MobiLink server to store the upload and download. Previously, they were the size in bytes of the upload and download as sent to or received from the MobiLink server. The new counts are more useful because they provide a good indication of a synchronization's impact on server memory. Also, the previous counts could be unreliable when HTTP, encryption, or compression were used.

    • In previous versions of the documentation, the property descriptions did not explain that the properties return different values based on whether you are using them in normal upload mode or in forced conflict mode. This has been corrected (see below).

    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.

    See MobiLink statistical properties.

Other MobiLink server changes
  • 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.

    See MobiLink server system procedures.