SQL Anywhere Bug Fix Readme for Version 12.0.1, build 3769



Choose a range of build numbers for which to display descriptions.
For example if you want to see what was fixed since the last EBF you applied then change 3152 to the build number of that last EBF.
Click Update Readme to make those changes take effect.
to Update Readme

Contents



Description of download types

Express Bug Fixes

A subset of the software with one or more bug fixes. The bug fixes are listed below. A Bug Fix update may only be applied to installed software with the same version number. While some testing has been performed on the software, you should not distribute these files with your application unless you have thoroughly tested your application with the software.

Maintenance Release

A complete set of software that upgrades installed software from an older version with the same major version number (version number format is major.minor.patch). Bug fixes and other changes are listed in the "readme" file for the upgrade. For answers to commonly asked questions please use the following URL: Frequently Asked Questions



12.0.1 Behavior Changes and Critical Bug Fixes

If any of these bug fixes apply to your installation, iAnywhere strongly recommends
that you install this fix.  Specific testing of behavior changes is recommended.


SQL Anywhere - Server

================(Build #3320 - Engineering Case #663991)================ Under some circumstances, queries with cached plans and queries containing complex correlated subqueries may have returned incomplete results if they were executed as parallel plans. This has been fixed. Note, a workaround is to disable intra-query parallelism (set MAX_QUERY_TASKS=1). ================(Build #3315 - Engineering Case #661791)================ A query containing a join between two or more tables could have returned an incorrect result if the executed query plan used an Index-Only Scan of some index T_idx over table T. For the problem to have occurred, a column T.col must have participated in a non-equality join predicate (e.g. "T.col < S.col", or "T.col BETWEEN S.col1 AND S.col2"), and there must have existed one or more columns in index T_idx preceeding T.col that did not participate in equality predicates. This has been fixed.

UltraLite - UltraLite Engine

================(Build #3549 - Engineering Case #687157)================ Upload rows sent by clients might not have been applied to the consolidated database on a SQL Anywhere or Sybase IQ database server if a redundant synchronization request was received by the MobiLink server, and the MobiLink server aborted the request with the following error: User 'a_ml_user_name' has the row in 'ml_database' locked (ODBC State = 40001, Native error code = -210) The new synchronization must also have contained an upload that included upload rows for multiple synchronization tables, and reused the database connection that was used for processing the redundant synchronization. This problem is fixed now. Note, all connections used by a MobiLink server are shown in the MobiLink server logging file with a prefix SPID when a minimal verbosity is specified in the MobiLink command line.



12.0.1 New Features

This section contains a description of new features added since the release
of version 12.0.1.


MobiLink - QAnywhere client

================(Build #3347 - Engineering Case #668833)================ The dbmlsyc command line option -qi prevents the tray icon or window from being displayed. This behaviour is identical to the -qi option of the database server. The option has existed since 11.0.1, but was not referenced in the usage text or the documentation. The usage text has been corrected

MobiLink - QAnywhere server

================(Build #3362 - Engineering Case #671955)================ The new property "ianywhere.qa.server.disableDeleteRules" has been added to the QAnywhere server properties that can be specified in the configuration file that can appear after the -m option of the MobiLink command. When set to True (default is False), this property disables the message delete rules and archiving processes that automatically run while the server is running. This property would normally not be used, but it is useful, along with the property "ianywhere.qa.server.disableNotifications", in the scenario where more than one MobiLink server is running on a given consolidated database, and the servers are not in a server farm configuration. In this case, the MobiLink servers must be configured such that only one of the servers is running message delete rules and the QAnywhere notifier.

MobiLink - Relay Server

================(Build #3726 - Engineering Case #706387)================ Three new flow control elements have been introduced, allowing the Relay Server to detect potential dangers proactively, and urgently signal the Outbound Enabler to throttle back on pushing data down to the Relay Server in an isolated per client manner. These new elements are: Per client shared memory consumption Per client virtual memory consumption Global shared memory level This change also introduces a new user control in the Relay Server configuration: [backend_farm] max_client_buffer = <memory size> When the Relay Server consumes more than the "max_client_buffer" amount of virtual memory to buffer server response for a slow reading client, an urgent flow control signal will be sent to the Outbound Enabler to pause reading further server responses for this client. The Relay Server will signal the Outbound Enabler to resume the reading responses for the client when the client has consumed enough of the responses until only half of "max_client_buffer" worth of server responses for the client is left in the Relay Server. The default value of "max_client_buffer" is 1M. The "max_client_buffer" property can be adjusted online and the change takes effect immediately without restarting the Relay Server. Similarly, per client shared memory is also being monitored, and isolated per client throttling was added. There is no user control for this element of the flow control system, as this element doesn't directly prevent shared memory exhaustion but it prevents deadlocking of the down-channel. Monitoring of the global shared memory level has also been added, so that flow control can be triggered on any client even if their personal quota has not yet been reached. No new user control has been introduced for this element of the flow control system, but the behavior of the existing "shared_mem" control in the Relay configuration has changed. Previously, this value was used only for specifying the extra amount of shared memory for buffering traffic and state tracking, in addition to the amount implied by the configuration. The property had an effect of an amount equal to its size on the startup allocation. Online adjustment to the value had no effect on the total allocation until the Relay Server is restarted. Now, this property has an effect of an amount three times its value on the startup allocation of shared memory, and is broken down as follows: - one third for buffering traffic and state tracking where user thought is enough at startup time. - one third for future online growth of the number of tenants, and backend farm size of the tenants. - one third as an extra blanket inside the auto calculated shared memory low water mark for triggering flow control. The sum of these values are pooled together for all functional needs without usage partitioning. The factoring is for calculating the gross startup amount and also users to understand the new implications of online adjustment of this value. Online adjustment to this value still has no effect on the total allocation, but it does change the global shared memory low water mark for triggering flow control. Because of one third factor as a blanket inside the low water mark, users can make adjustments to the flow control behavior without restarting the Relay Server. Here are some new usages of the shared_mem property in terms of online adjustments: The administrator doesn't foresee growth in number of tenants and/or their size and so wants to reduce the shared memory low watermark in order to reduce triggering of unnecessary flow control. The shared_mem property can be reduced online. The change doesn't decrease allocation until restart, but it does reduce the blanket amount immediately by an amount equal to the change. The administrator has seen some of the following after their Relay Server had been running for some time: Substantial growth in number of tenants Substantial growth in size of the backend farm Substantial growth in number of clients Growth in http response size Addition of slower clients or slower network to the clients Upgraded to faster network between RS and OE and wants to increase the global shared memory low water mark so that flow control kicks sooner to protect against global shared memory exhaustion. This can be done by increasing "shared_mem" online without restarting the Relay Server. The change doesn't increase allocation until restart but it increase the blanket amount immediately by an amount equal to the change. The "shared_mem" value to now allowed to be bigger than 4G. This change has extended the existing protocol between the Relay Server and the Outbound Enabler so that upgrading to a new Outbound Enabler is required for this feature. The new Relay Servers and Outbound Enablers are backward compatible with older versions, but flow control cannot take place and so the Relay Server is not protected against memory exhaustion. Before these changes, the Relay Server can run out of resource due to reaching the hard limit of shared memory or reaching the limit on virtual memory. This could have had different causes, including, but not limited to, an increase in the number of clients or backend farms/servers, http response size, and sustained slow reads from clients. Some exhaustion may have lead to deadlocks and the symptom may not have been fatal as current Relay Servers will resolve the deadlock, but the requests could still have been failed and shared resources were blacked-out during the deadlock period. sers might experience ================(Build #3724 - Engineering Case #694165)================ An interactive quick setup feature has been added to help users running on an Apache web server to configure the web server for Relay Server, create a demo application, and generate a Quick Reference guide. This quick setup is divided into two main steps: 1- Configure the Apache web server for Relay Server Run ap-setup.sh script, which consists of the following sections: 1. Introduction 2. Validation 3. Create Backup 4. Deploy the Relay Server 5. Deploy the SimpleTestApp page and Quick Reference 6. Introduction to test setup script (part two) 2- Create and start Relay Server test services Run rs-test-setup.sh script, which consists of the following sections: 1. Introduction 2. Create and deploy Relay Server and Outbound Enabler test services 3. Start the Apache web server and the test services 4. Launch the SimpleTestApp 5. Launch the Relay Server status page 6. Generate and launch the Quick Reference guide 7. Shut down ================(Build #3546 - Engineering Case #695497)================ Only the status page via the rs_admin.dll and rs_mionitor.dll provides full breakdown of status of all farms and servers and the amount of info can be overwhelming for large deployment like hosting environment. The status page via rs_client.dll or rs_server.dll only provides a single Relay Server wide status summary, and the user cannot pinpoint their query to a specific farm for backend server. This change introduces the following two new query parameters for all status pages. ias-rs-farm=<backend-farm-id> ias-rs-server=<backend-server-id> Use of ias-rs-server requires ias-rs-farm to be specified as well. The comparison of the value of these parameters are case sensitive but the name of these parameters are case insensitive. These new parameter can be applied to the status page url via all of the 4 existing extensions and they can co-exist with the ias-rs-refresh-sec parameter. Example status page url: http:\\my.com\rs\admin\rs_admin.dll?ias-rs-farm=myfarm&ias-rs-server=myserver http:\\my.com\rs\client\rs_client.dll?ias-rs-farm=myfarm&ias-rs-status-refresh-sec=20 When addressing rs_client.dll or rs_server.dll while IAS-RS-SERVER is not specified, individual server status will still be reported but the server name are hidden by label of this format: "_#<enumeration>_". In the cases of farm or server not found. The status page will still response with basic RS server information together with an error reporting what was not found. In those cases, no status information of any kind are reported but the viewer can still verify if they have a successful access to the extension of their choice. The pin-pointed status url shares the pre-existing refresh control and it can be used as a basic service monitor in a browser. ================(Build #3519 - Engineering Case #692340)================ Machine and OS information have now been added to the Relay Server Outbound Enabler log. As well, timezone offset information has been added to the Relay Server and the Outbound Enabler logs. ================(Build #3477 - Engineering Case #687786)================ An interactive quick setup feature has been added to help users with deploying Relay Server components to Microsoft IIS 6.0 on Windows Server 2003. This is being provided as an alternative to the manual procedure documented in the Relay Server Guide. Setup is automated but also interactive. It creates a demo application and a Quick Reference Guide to assist in subsequent Relay Server server maintenance. The Quick Reference is launched automatically as part of the setup. Setup is comprised of the following major steps: 1. Introduction 2. Customization 3. Create a Backup 4. Deploy and Start the Relay Service 5. Generate and Launch the Quick Reference 6. Launch the Relay Server Status Page 7. Launch the SimpleTestApp Client 8. Shut down To deploy the Relay Server components to Microsoft IIS 6.0 on Windows Server 2003, run rs-setup.bat from the SQLANY12%/RelayServer/IIS/quicksetup_iis6 directory ================(Build #3475 - Engineering Case #688116)================ Support has now been added to the Relay Server to allow it to extract identity information from client certificate and then forward them in HTTP headers that SAP Gateway or Web Dispatcher understands. To turn on the feature for a backend farm, set the following new backend farm property in the Relay Server configuration file: forward_x509_identity = yes In the case were there is a chain of SAP intermediaries, the client identity headers may already present in the request. However not all clients may be granted a permission to act as such forwarder. So the default behavior is to replace the existing headers with the identity of the forwarder. To grant permission for a forwarder to forward its client identity without being overwritten by its identity, the following new pair of backend farm properties may be in the Relay Server configuration file: forwarder_certificate_subject = <match-string> forwarder_certificate_issuer = <match-string> The <match-string> is used to check against a serialized form of the corresponding compound name field in the certificate. A '?' can be used to match any character and a '*' can be used to match any string. A '\' can be used as the leading escape character for '?', '*' or '\' of they need to be matched literally. For example: forwarder_certificate_subject = 'CN = mySapWD??.my.com, OU = Sybase, O = SAP, *' forwarder_certificate_issuer = 'CN = quicksigner, OU = security department, O = my coop, L = my city, S = my state, C = my country' To obtain the subject or issuer string of a forwarder, simply perform a forwarding without setting up the match requirement. The following error messages in the Relay Server log will reveal the full subject or issuer which fails the default empty match-string: Forwarder certificate subject '<full-subject-string>' does not match pattern '' required in farm '<farm>' Forwarder certificate issuer '<full-issuer-string>' does not match pattern '' required in farm '<farm>' ================(Build #3475 - Engineering Case #663987)================ The Relay Server Outbound Enabler is now able to initiate SSL connections to the backend server. In the -cs option, HTTPS=1 is used to enable an SSL connection to the backend server. When SSL is enabled, the -cs option can take the values 'trusted_certificates', 'identity' and 'identity_password' for server and/or client authentication. ================(Build #3467 - Engineering Case #686057)================ An optional ias-rs-status-refresh-sec query parameter has been added to the status url for controlling the auto refresh rate of the status page. A refresh interval of 0 means auto refresh is not wanted and users are expected to use the refresh button on the browser to refresh the status. The following information was also added to the status page: - Service start time in UTC. - Status capture time in UTC. - Status refresh interval, or indication that manual refresh is expected.

MobiLink - SA Client

================(Build #3588 - Engineering Case #687570)================ A .NET Policy DLL and the associated iAnywhere.MobiLink.Client.config file are now installed and configured. The .NET Policy DLL will allow .NET applications compiled against any build of v12.x of the iAnywhere.MobiLink.Client assembly to automatically re-direct to the most recent build of the assembly installed on the machine, if the desired build of the assembly could not be located on the machine. Before these files were installed and configured, an application.config file or machine.config file could have been used to get the same functionality. ================(Build #3537 - Engineering Case #693928)================ When the StartServer method in the dbmlsync API is used to start a dbmlsync server, the dbmlsync commandline is now obfuscated making it harder for someone with access to the machine to discover the dbmlsync commandline.

MobiLink - Streams

================(Build #3563 - Engineering Case #697061)================ The sample certificates in rsaroot.crt and rsaserver.id have been regenerated using SHA1 and 2048-bit RSA keys. The original certificates used MD5 and 1024-bit keys.

MobiLink - Synchronization Server

================(Build #3758 - Engineering Case #713455)================ Support has been added to the MobiLink Server for consolidated databases running on Microsoft SQL Server 2012 servers with the Microsoft native ODBC driver named SQL Server Native Client 11.0, version 2011.110.xxx.xx. This support is limited to Microsoft Windows only. ================(Build #3744 - Engineering Case #706828)================ The MobiLink server now supports bulk upload for sync tables that contain LOBs when the consolidated database is running on an Oracle server. The bulk upload feature would have previously been disabled when a sync table contained LOBs. The number of rows uploaded by each batch is controlled by -s command line option. Note, the iAS ODBC driver for Oracle must be upgraded to the same EBF level as the MobiLink server when the consolidated database is running on an Oracle server and the synchronization tables contain CLOBs or BLOBs. ================(Build #3590 - Engineering Case #700276)================ The MobiLink server now supports the Oracle XMLTYPE data type. This Oracle data type can be mapped to the SA/UL XML data type. However, the Oracle database server does actually validate the data before storing it into a XMLTYPE column and SA/UL does not. Therefore, users must make sure the upload XML data are valid XML documents. Small XML documents with a length less than or equal to 32 KB can be uploaded into and downloaded from an Oracle database with Oracle PL/SQL statements. However, when the length of XML documents is great than 32 KB, the upload XML documents may need to be uploaded into a (global) temporary table by the upload_insert and upload_update scripts and the upload data can then be converted and stored into the actual sync table in the end_upload_rows or end_upload script. The following section gives sample upload and download scripts to upload and download XMLTYPE objects between an Oracle consolidated and SQLAnywhere remote databases. Here we assume our upload table is defined as create table test (pk int not null primary key, c1 XMLTYPE) in the Oracle consolidated database and create table test (pk int not null primary key, c1 XML) in the SA remote database. Then the upload and download scripts for the test table could be defined below: 1) All XML documents are less than or equal to 32KB long: The upload and download scripts can be written as a) upload_insert: declare v_pk integer; v_c1 clob; x_c1 xmltype; begin v_pk := {ml r.pk}; v_c1 := {ml r.c1}; x_c1 := XMLTYPE.createXML( v_c1 ); insert into test values( v_pk, x_c1 ); end; b) download_cursor: select pk, XMLSERIALIZE( content c1 ) from test This upload_insert script works well, when the XML data length is less than or equal to 32 KB. However, if the XML data length is greater than 32 KB, the Oracle server could complain with the following error: ORA-01460: unimplemented or unreasonable conversion requested when the MobiLink server was trying to execute the upload_insert script with the upload data. 2) Some of the XML documents are greater than 32KB long: If there are any XML documents greater than 32 KB long, we are not able to use Oracle PL/SQL to upload data into the Oracle XMLTYPE columns. To work-around this problem, the upload XML data needs to be uploaded in a global temporary table: a) upload_insert: The upload_insert script will upload the XML documents into a global temporary table in the Oracle consolidated database and the global temporary table is defined as create global temporary table tmp_test (pk int, c1 CLOB) then the upload_insert script can written as insert into tmp_test values( {ml r.pk}, {ml r.c1} ) Please note, the c1 column in the temporary table must have the CLOB data type. b) end_uoload_rows: The end_upload_rows script first retrieves the XML documents from the global temporary table, converts it to XML documents, and then stores the XML data into the test table. Here is the end_upload_rows script: insert into test (pk, c1) (select pk, XMLTYPE.createXML(c1) from tmp_test ================(Build #3574 - Engineering Case #696647)================ A new NetworkData class has been added to the Java and .NET scripting APIs to give access to HTTP headers and client-side certificates used in a request. A NetworkData object can be obtained by calling the getNetworkData method, or getting the NetworkData property of the DBConnectionContex class in Java or .NET, respectively. Collection of the network data must be explicitly enabled by adding "collect_network_data=1" to your -x options. To collect client-side certificates, trusted_certificates=<certificate file> must be added to -x options. The client-side certificates are not yet available for MacOS, but that will be added in a future EBF. The class documentation for the Java class follows: /** * Contains information about the network streams for a synchronization. * This is useful if you wish to authenticate against some other server in * the enterprise using the client-side certificate and HTTP headers. * * To enable collection of network stream data, add collect_network_data=1 to * your -x switches. This adds additional per sync memory overhead to store * the data. If using TLS or HTTPS with client-side certificates, add * trusted_certificates=<certificate file> to have the server ask the client to send * a certificate during the TLS handshake, incurring a time and network cost. * * You can obtain a NetworkData object by invoking the getNetworkData method * of the DBConnectionContext class. When using HTTP or HTTPS, it will contain * the header data for the last HTTP request received by the server before the * authenticate scripts are invoked. * * @see DBConnectionContext * * @examples * The following example shows how to get a NetworkData object from the * DBConnectionContext, and prints the data it contains to the log. * * <pre> * public class OrderProcessor { * DBConnectionContext _cc; * * public OrderProcessor( DBConnectionContext cc ) { * _cc = cc; * } * * // The method used for the authenticate_user event. * public void AuthUser() { * NetworkData nd = _cc.getNetworkData(); * if( nd != null ) { * if( nd.isHTTP() ) { * System.out.println( "http" ); * String user_agent = nd.getHTTPHeaderValue( "user-agent" ); * System.out.println( " user-agent: " + user_agent.substring( 0, user_agent.indexOf( '/' ) ) ); * } else { * System.out.println( "no http" ); * } * if( nd.isTLS() ) { * System.out.println( "tls" ); * CertPath certs = nd.getCertificateChain(); * if( certs != null ) { * System.out.println( " client-side cert:" ); * int n = 1; * for( Certificate c : certs.getCertificates() ) { * System.out.println( " cert " + n++ ); * X509Certificate c509 = (X509Certificate) c; * System.out.println( " Subject: " + c509.getSubjectX500Principal().getName() ); * System.out.println( " Issuer: " + c509.getIssuerX500Principal().getName() ); * } * } else { * System.out.println( " no client cert" ); * } * } else { * System.out.println( "no tls" ); * } * if( nd.isEndToEndEncrypted() ) { * System.out.println( "e2ee" ); * } else { * System.out.println( "no e2ee" ); * } * } else { * System.out.println( "NULL networkdata" ); * } * } * } * * </pre> */ public interface NetworkData { /** * Returns true if this sync is using HTTP or HTTPS, and false otherwise. * * @return True if this sync is using HTTP or HTTPS, and false otherwise. */ public boolean isHTTP(); /** * Returns the value of the last header received by the server with the supplied * name. * * @param the header name to the return the value for * * @return the last header value associated with the supplied header-name * * @see NetworkData#getHTTPHeaderValues * @see NetworkData#getHTTPHeaders */ public String getHTTPHeaderValue( String name ); /** * Returns all the header values received by the server associated * with the supplied name. * * @param the header name to the return the values for * * @return the header values associated with the supplied header-name * * @see NetworkData#getHTTPHeaderValue * @see NetworkData#getHTTPHeaders */ public List<String> getHTTPHeaderValues( String name ); /** * Returns a Map that maps header names to a List of header-values. * * @return a Map containing all the headers received by the server. * * @see NetworkData#getHTTPHeaderValue * @see NetworkData#getHTTPHeaderValues */ public Map<String, List<String> > getHTTPHeaders(); /** * Returns true if this sync is using TLS, and false otherwise. * * @return True if this sync is using TLS, and false otherwise. */ public boolean isTLS(); /** * Returns a java.security.cert.CertPath containing any certificates * sent by the client. The certificates are all * java.security.cert.X509Certificate objects. * * This function will return a non-null value only if isTLS() is true, * the client supplies a certificate using the "identity" stream * parameter, and the trusted_certificates option is set on the server. * A non-null CertPath will contain the certificates in order, * from the self-signed certificate to the peer certificate. * * @return A CertPath containing the X509 certificates that identify the * client, or null if no such certificates were provided. */ public java.security.cert.CertPath getCertificateChain(); /** * Returns true if this sync is end-to-end encrypted, and false otherwise. * * @return True if this sync is end-to-end encrypted, and false otherwise. */ public boolean isEndToEndEncrypted(); } This method was added to the Java DBConnectionContext class: /** * Returns information about the network streams for a synchronization. * This is useful if you wish to authenticate against some other server in * the enterprise using the client-side certificate and HTTP headers. * * To enable collection of network stream data, add collect_network_data=1 to * your -x switches. This adds additional per sync memory overhead to store * the data. * * @return information about the network streams used for the request, or * null if collection has not been enabled. * @see NetworkData */ NetworkData getNetworkData(); The .NET class documentation follows: namespace iAnywhere.MobiLink.Script { /// <summary> /// Contains information about the network streams for a synchronization. /// </summary> /// <remarks> /// This is useful if you wish to authenticate against some other server in /// the enterprise using the client-side certificate and HTTP headers. /// /// To enable collection of network stream data, add collect_network_data=1 to /// your -x switches. This adds additional per sync memory overhead to store /// the data. If using TLS or HTTPS with client-side certificates, add /// trusted_certificates=<certificate file> to have the server ask the client to send /// a certificate during the TLS handshake, incurring a time and network cost. /// You can obtain a NetworkData object by invoking the getNetworkData method /// of the DBConnectionContext class. When using HTTP or HTTPS, it will contain /// the header data for the last HTTP request received by the server before the /// authenticate scripts are invoked. /// /// </remarks> /// <example> /// The following example shows how to get a NetworkData object from the /// DBConnectionContext, and prints the data it contains to the log. /// <code> /// using iAnywhere.MobiLink.Script; /// using System.Collections.Generic; /// using System.Security.Cryptography.X509Certificates; /// /// public class OrderProcessor { /// DBConnectionContext _cc; /// /// public OrderProcessor( DBConnectionContext cc ) { /// _cc = cc; /// } /// /// public void AuthUser() { /// NetworkData nd = _cc.NetworkData; /// if( nd != null ) { /// if( nd.IsHTTP ) { /// PrintLn( "http" ); /// string user_agent = nd.GetHTTPHeaderValue( "user-agent" ); /// PrintLn( " user-agent: " + user_agent.Substring( 0, user_agent.IndexOf( '/' ) ) ); /// } else { /// PrintLn( "no http" ); /// } /// if( nd.IsTLS ) { /// PrintLn( "tls" ); /// X509Certificate2Collection certs = nd.ClientCertificates; /// if( certs != null ) { /// PrintLn( " client-side cert:" ); /// int n = 1; /// foreach( X509Certificate2 x509 in certs ) { /// PrintLn( " cert " + n++ ); /// PrintLn( " Subject: " + x509.SubjectName.Name ); /// PrintLn( " Issuer: " + x509.IssuerName.Name ); /// } /// } else { /// PrintLn( " no client cert" ); /// } /// } else { /// PrintLn( "no tls" ); /// } /// if( nd.IsEndToEndEncrypted ) { /// PrintLn( "e2ee" ); /// } else { /// PrintLn( "no e2ee" ); /// } /// } else { /// PrintLn( "NULL networkdata" ); /// } /// } /// } /// </code> /// </example> public interface NetworkData { /// <summary> /// Returns true if this sync is using HTTP or HTTPS, and false otherwise. /// </summary> /// <returns> /// True if this sync is using HTTP or HTTPS, and false otherwise. /// </returns> bool IsHTTP { get; } /// <summary> /// Returns true if this sync is using TLS or HTTPS, and false otherwise. /// </summary> /// <returns> /// True if this sync is using TLS or HTTPS, and false otherwise. /// </returns> bool IsTLS { get; } /// <summary> /// Returns the existing connection to the MobiLink consolidated database. /// </summary> bool IsEndToEndEncrypted { get; } /// <summary> /// Returns the value of the last header received by the server with the supplied /// name. /// </summary> /// <param name="name"> the header name to the return the value for </param> /// <return> /// The last header value associated with the supplied header-name. /// </return> /// /// <seealso cref="GetHTTPHeaderValues"/> /// <seealso cref="HTTPHeaders"/> /// string GetHTTPHeaderValue( string name ); /// <summary> /// Returns all the header values received by the server associated with /// the supplied name. /// </summary> /// <param name="name"> the header name to the return the values for </param> /// <return> /// The header values associated with the supplied header-name. /// </return> /// /// <seealso cref="GetHTTPHeaderValue"/> /// <seealso cref="HTTPHeaders"/> /// IList<string> GetHTTPHeaderValues( string name ); /// <summary> /// Returns a dictionary that maps header names to a list of header-values. /// </summary> /// <return> /// A dictionary of header name-value pairs. /// </return> /// /// <seealso cref="GetHTTPHeaderValue"/> /// <seealso cref="GetHTTPHeaderValues"/> /// IDictionary<string, IList<string> > HTTPHeaders { get; } /// <summary> /// Returns an X509Certificate2Collection containing any certificates /// sent by the client. /// </summary> /// <remarks> /// This function will return a non-null value only if isTLS() is true, /// the client supplies a certificate using the "identity" stream /// parameter, and the trusted_certificates option is set on the server. /// A non-null CertPath will contain the certificates in order, /// from the self-signed certificate to the peer certificate. /// </remarks> /// <return> /// An X509Certificate2Collection containing the X509 certificates that identify /// the client, or null if no such certificates were provided. /// </return> X509Certificate2Collection ClientCertificates { get; } } } The following property was added to the .NET DBConnectionContext: /// <summary> /// Returns information about the network streams for a synchronization. /// </summary> /// <remarks> /// This is useful if you wish to authenticate against some other server in /// the enterprise using the client-side certificate and HTTP headers. /// /// To enable collection of network stream data, add collect_network_data=1 to /// your -x switches. This adds additional per sync memory overhead to store /// the data. /// </remarks> /// /// <returns> information about the network streams used for the request, or /// null if collection has not been enabled. /// </returns> /// /// <seealso cref="NetworkData"/> NetworkData NetworkData { get; } ================(Build #3557 - Engineering Case #698198)================ The -x option of the MobiLink Server now supports the trusted_certificates option when encryption is in effect. The option is comparable to and symmetric with the client-side option of the same name (see Engineering case 696697). The usage is: mlsrvXX ... -x tls(...;trusted_certificates=certificate_file) ... mlsrvXX ... -x https(...;trusted_certificates=certificate_file) ... Used in the simplest way, the trusted_certificates option provides validation of clients, but without other capabilities like certificate revocation lists. To implement a certificate revocation list and otherwise integrate with your enterprise certificate infrastructure, you'll need to make use of the NetworkData.ClientCertificates API, described in the email forwarded below. The simplest example to illustrate this is: client --> ML server --> Enterprise certificate infrastructure Use the trusted_certificates option to ensure the client certificate is valid, then use the NetworkData.ClientCertificates API to further authenticate the certificate in the authenticate_user script (written in Java or .NET). ================(Build #3540 - Engineering Case #693344)================ The MobiLink server and clients now support certificates signed using SHA-2. Previously, only MD5 and SHA-1 were supported. Also, the Certificate Viewer utility (viewcert) will now also correctly display the signature algorithm for certificates signed using SHA-2.

MobiLink - Utilities

================(Build #3727 - Engineering Case #706817)================ The Certificate Creation and Certificate Viewer utilities (createcert and viewcert) will now encode unencrypted RSA private keys using PKCS #1 instead of PKCS #8, if provided a new '-p1' option. This is useful when creating certificates for use with Apache since it expects unencrypted RSA private keys to be encoded using PKCS #1 (SQL Anywhere software always expects private keys to be encoded with PKCS #8). Encrypted keys and ECC keys will continue to be encoded using PKCS #8 regardless of whether the '-p1' option is specified. ================(Build #3490 - Engineering Case #688892)================ When running mlgenreplayapi with a non-existent recorded protocol file, and/or using the -d switch with a non-existent directory, no error messages was displayed at the console. However, if the -o or -ot switch was used, the errors were logged in the log file. Now, if no -o or -ot options are specified for mlreplay and mlgenreplayapi, all output goes to stdout. As well, mlgenreplayapi will now create the directory specified by the -d option (the directory in which to put the generated code) when it does not exist. ================(Build #3347 - Engineering Case #668832)================ The dblsn command line option -qi prevents the tray icon or window from being displayed. This behaviour is identical to the -qi option of the database server. The option has existed since 11.0.1, but was not referenced in the usage text or the documentation. The usage text has been corrected

SQL Anywhere - ADO.Net Managed Provider

================(Build #3758 - Engineering Case #713388)================ Support for the latest release of .NET Framework, .NET 4.5, has now been added. The following features are new in the .NET Framework 4.5 RC: 1. Asynchronous Programming The new asynchronous programming feature provides a simple technique to make code asynchronous. Asynchronous code can make the user interface of client applications more responsive, it can also make server applications more scalable. Writing asynchronous code has traditionally involved installing a callback (also called continuation) to express the logic that occurs after the asynchronous operation finishes. This complicates the structure of asynchronous code as compared with synchronous code. .NET 4.5 allows call into asynchronous methods without using callbacks, and without splitting code across multiple methods or lambda expressions. The 'async' modifier specifies that a method is asynchronous. When calling an async method, a task is returned. When calling an 'await' statement against the task, the current method exits immediately. When the task finishes, execution resumes in the same method. Calling an async method does not allocate any additional threads. It may use the existing I/O completion thread briefly at the end. The following methods were added in SQL Anywhere ADO.NET provider to support asynchronous programming: SAConnection.OpenAsync SACommand.ExecuteDbDataReaderAsync SACommand.ExecuteNonQueryAsync SACommand.ExecuteReaderAsync SACommand.ExecuteScalarAsync SADataReader.GetFieldValueAsync SADataReader.IsDBNullAsync SADataReader.NextResultAsync SADataReader.ReadAsync SABulkCopy.WriteToServerAsync Here are some examples: internal async Task Execute() { using (SAConnection conn = new SAConnection("DSN=SQL Anywhere 16 Demo")) { SACommand command = new SACommand("select 1", conn); int result = MethodAsync(conn, command).Result; command = new SACommand("select top 10 * from SalesOrders", conn); using (DbDataReader reader = await command.ExecuteReaderAsync()) { while (await reader.ReadAsync()) Console.WriteLine(String.Format("{0}", reader[0])); } } } private async Task<int> MethodAsync(SAConnection conn, SACommand cmd) { await conn.OpenAsync(); await cmd.ExecuteNonQueryAsync(); return 1; } private async Task ExecuteSqlTransaction() { using (SAConnection connection = new SAConnection("DSN=SQL Anywhere 16 Demo")) { await connection.OpenAsync(); SACommand command = connection.CreateCommand(); SATransaction transaction = await Task.Run<SATransaction>(() => connection.BeginTransaction()); command.Connection = connection; command.Transaction = transaction; command.CommandText = "Delete From Departments Where (DepartmentID = 777 OR DepartmentID = 888)"; await command.ExecuteNonQueryAsync(); command.CommandText = "Insert into Departments(DepartmentID, DepartmentName) VALUES (777, 'HR')"; await command.ExecuteNonQueryAsync(); command.CommandText = "Insert into Departments(DepartmentID, DepartmentName) VALUES (888, 'Supporting')"; await command.ExecuteNonQueryAsync(); await Task.Run(() => transaction.Commit()); Console.WriteLine("Both records are written to database."); } } private async Task AsyncSqlBulkCopy() { using (SAConnection conn = new SAConnection("DSN=SQL Anywhere 16 Demo")) { await conn.OpenAsync(); DataTable dt = new DataTable(); using (SACommand cmd = new SACommand(selStmt, conn)) { SADataAdapter adapter = new SADataAdapter(cmd); adapter.Fill(dt); using (SABulkCopy bcp = new SABulkCopy(conn)) { bcp.DestinationTableName = destTable; await bcp.WriteToServerAsync(dt); } } } } 2. SACredential class. A new class SACredential has been added for setting the credentials outside of the connection string via the new Credential property of SAConnection. Now the developer can create a SACredential object with a UserId and a SecureString Password to hold the credential values of a connection. This helps mitigate the memory dump vulnerability of keeping the User Name and Password in the connection string. Here's an example: private void OpenConnection() { SecureString password = new SecureString(); // txtPassword.SecurePassword; password.MakeReadOnly(); SACredential credential = new SACredential( "dba", password ); using ( SAConnection conn = new SAConnection( "DSN=SQL Anywhere 16 Demo", credential ) ) { conn.Open(); } } ================(Build #3714 - Engineering Case #703288)================ When using a "managed resource only" deployment (such as Microsoft's ClickOnce) for .NET applications, delivering SQL Anywhere native dlls through this mechanism may have been a problem. A demonstration project DeploymentUtility (with source code) has been added to help with this. It adds SQL Anywhere native dlls as embedded resources, and copies them to a local drive when a .NET application is deployed. ================(Build #3706 - Engineering Case #701776)================ Support has now been added for Visual Studio 2012. The utility SetupVSPackage will now create the proper registry keys for Visual Studio 2012. ================(Build #3594 - Engineering Case #700458)================ Support has now been added to the SQL Anywhere ADO.NET provider for latest release of Microsoft Entity Framework - EF 4.3. The major new feature of EF 4.3 is migration tools which enable the user to keep track of the data model changes. ================(Build #3495 - Engineering Case #689781)================ The ADO .Net provider now supports Microsoft Entity Framework 4.2. To use the new Entity Framework 4.2, it must be added to Visual Studio projects using the Visual Studio tool NuGet. ================(Build #3429 - Engineering Case #682773)================ EF 4.1 is the latest release of Microsoft Entity Framework. The major new feature of EF 4.1 is "Code First". Support has now been added for Code First. Code First enables a different development workflow: defining data model objects by simply writing C# or VB.NET classes mapping to database objects without ever having to open a designer or define an XML mapping file. Optionally, additional configuration can be performed by using data annotations or the Fluent API. Model can be used to generate a database schema or map to an existing database. Here's an example which creates new database objects using the model: using System; using System.Collections.Generic; using System.ComponentModel.DataAnnotations; using System.Data.Entity; using System.Data.Entity.Infrastructure; using System.Linq; using iAnywhere.Data.SQLAnywhere; namespace CodeFirstExample { [Table( "EdmCategories", Schema = "DBA" )] public class Category { public string CategoryId { get; set; } [MaxLength( 64 )] public string Name { get; set; } public virtual ICollection<Product> Products { get; set; } } [Table( "EdmProducts", Schema = "DBA" )] public class Product { public int ProductId { get; set; } [MaxLength( 64 )] public string Name { get; set; } public string CategoryId { get; set; } public virtual Category Category { get; set; } } [Table( "EdmSuppliers", Schema = "DBA" )] public class Supplier { [Key] public string SupplierCode { get; set; } [MaxLength( 64 )] public string Name { get; set; } } public class Context : DbContext { public Context() : base() { } public Context( string connStr ) : base( connStr ) { } public DbSet<Category> Categories { get; set; } public DbSet<Product> Products { get; set; } public DbSet<Supplier> Suppliers { get; set; } protected override void OnModelCreating( DbModelBuilder modelBuilder ) { modelBuilder.Entity<Supplier>().Property( s => s.Name ).IsRequired(); } } class Program { static void Main( string[] args ) { Database.DefaultConnectionFactory = new SAConnectionFactory(); Database.SetInitializer<Context>( new DropCreateDatabaseAlways<Context>() ); using ( var db = new Context( "DSN=SQL Anywhere 12 Demo" ) ) { var query = db.Products.ToList(); } } } } Here's another example which maps to an existing database: using System; using System.Collections.Generic; using System.ComponentModel.DataAnnotations; using System.Data.Entity; using System.Data.Entity.Infrastructure; using System.Linq; using iAnywhere.Data.SQLAnywhere; namespace CodeFirstExample { [Table( "Customers", Schema = "GROUPO" )] public class Customer { [Key()] public int ID { get; set; } public string SurName { get; set; } public string GivenName { get; set; } public string Street { get; set; } public string City { get; set; } public string State { get; set; } public string Country { get; set; } public string PostalCode { get; set; } public string Phone { get; set; } public string CompanyName { get; set; } public virtual ICollection<Contact> Contacts { get; set; } } [Table( "Contacts", Schema = "GROUPO" )] public class Contact { [Key()] public int ID { get; set; } public string SurName { get; set; } public string GivenName { get; set; } public string Title { get; set; } public string Street { get; set; } public string City { get; set; } public string State { get; set; } public string Country { get; set; } public string PostalCode { get; set; } public string Phone { get; set; } public string Fax { get; set; } [ForeignKey( "Customer" )] public int CustomerId { get; set; } public virtual Customer Customer { get; set; } } public class Context : DbContext { public Context() : base() { } public Context( string connStr ) : base( connStr ) { } public DbSet<Contact> Contacts { get; set; } public DbSet<Customer> Customers { get; set; } } class Program { static void Main( string[] args ) { Database.DefaultConnectionFactory = new SAConnectionFactory(); Database.SetInitializer<Context>( null ); using ( var db = new Context( "DSN=SQL Anywhere 12 Demo" ) ) { foreach ( var customer in db.Customers.ToList() ) { Console.WriteLine( "Customer - " + string.Format( "{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9}", customer.ID, customer.SurName, customer.GivenName, customer.Street, customer.City, customer.State, customer.Country, customer.PostalCode, customer.Phone, customer.CompanyName ) ); foreach ( var contact in customer.Contacts ) { Console.WriteLine( " Contact - " + string.Format( "{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9}, {10}", contact.ID, contact.SurName, contact.GivenName, contact.Title, contact.Street, contact.City, contact.State, contact.Country, contact.PostalCode, contact.Phone, contact.Fax ) ); } } } } } } Additional assembly references need to be add to run these examples: EntityFramework, iAnywhere.Data.SQLAnywhere.v4.0, System.ComponentModel.DataAnnotations, System.Data.Entity. ================(Build #3338 - Engineering Case #667520)================ A new command line option 'uninstallall' (or 'ua') has been added to SetupVSPackage.exe. When specified, the 'uninstallall' option will cause SetupVSPackage to remove all versions of SQL Anywhere assemblies from the Global Assembly Cache. For example: SetupVSPackage.exe /ua

SQL Anywhere - DBLIB Client Library

================(Build #3292 - Engineering Case #659363)================ The Timeout, SendBufferSize, and ReceiveBufferSize TCP options now have upper limits. Values specified above these limits will result in connection failure (-832). The limits are: Timeout: 3600 seconds SendBufferSize: 1048576 bytes (1 MB) ReceiveBufferSize: 1048576 bytes (1 MB)

SQL Anywhere - JDBC Client Library

================(Build #3515 - Engineering Case #691979)================ The SQL Anywhere JDBC 4 Driver (sajdbc4.jar) now contains the proper manifest information to allow it to be loaded as an OSGI bundle.

SQL Anywhere - ODBC Client Library

================(Build #3371 - Engineering Case #674389)================ On Windows desktop platforms, the Winsock version 1 library has been replaced by the Winsock version 2 library. As a result, Wsock32.lib has been replaced by Ws2_32.lib. A few applications (MobiLink, Relay Server) that need Microsoft additional functionality, such as TransferFile, also include Mswsock.lib. The result is the elimination of the Wsock32 DLL and a smaller execution time footprint (36K less). Note, this change also affects the ADO .NET provider, the OLE DB provider, MobiLink server, Relay Server Outbound Enabler, database server, all SA software requiring TCPIP running on Windows.

SQL Anywhere - OLEDB Client Library

================(Build #3373 - Engineering Case #674702)================ Assertion failure messages now include a database name where available.

SQL Anywhere - Other

================(Build #3466 - Engineering Case #685973)================ If a user's path contained a large number of directories and/or contained directories located on mapped network drives, the first connection attempt made by an application could have been slow. This has been fixed. A workaround is to create an empty file called saldap.ini (assuming the LDAP feature is not being used) in the installation bin32/bin64 directory. ================(Build #3284 - Engineering Case #657471)================ The PHP external environment and the PHP driver now support PHP versions 5.3.3, 5.3.4, and 5.3.5.

SQL Anywhere - Server

================(Build #3711 - Engineering Case #700997)================ On Windows systems, the error "R6025 - pure virtual function call" would have caused a dialog box to be opened, even if the executable should not interact with the desktop. This has been fixed so that no dialog box is now opened. ================(Build #3625 - Engineering Case #691732)================ The database server now accepts the -gta command line option to control which logical processors the database server is permitted to use. The argument to -gta is a comma-separated list of processor numbers and/or ranges. For example: -gta 3,5-7 allows the database server to run on processors 3, 5, 6 and 7. The lower endpoint of a range may be omitted in which case it is assumed to be zero. The upper endpoint of a range may be omitted in which case it is assumed to be the highest cpu known to the OS. The database server will only use logical processors specified by -gta but it may not use all of them if the license does not allow it, or if one or more of the specified logical processors does not exist or is offline. If the set of processors specified by -gta exceeds the license limits, the server will use the lowest-numbered logical processors specified by -gta up to but not exceeding the license limits. In particular, the server does not choose logical processors in the order listed by -gta and it does not attempt to maximize concurrency within the license limit and the specified -gta option. If the set of processors specified by -gta does not match any online processors, the server acts as if -gta was not specified and uses up to the licensed number of processors starting at processor 0. Note that -gta cannot be used at the same time as -gt or -gtc. A usage message will be displayed when -gta is used with either -gt or -gtc. ================(Build #3605 - Engineering Case #696064)================ A new collation '1252BIN' has been added that is based on the windows-1252 character set but has a binary sort ordering. As with the other binary collations, ordering isn't quite binary when it is used in a case-insensitive database. For case-insensitve 1252BIN collations, upper case letters A-Z sort as if they were lower case (ie, greater than the backquote '`' character). ================(Build #3579 - Engineering Case #695258)================ A new connection-level property 'NumLocalTempTables' has been added that returns the number of local temporary tables in use by the connection. Note that even when a local temporary table is dropped or falls out of scope, it is still considered to be "in use" until the next commit. ================(Build #3553 - Engineering Case #696323)================ Localized server resources for the French language have now been enabled on Linux systems. ================(Build #3518 - Engineering Case #692243)================ The [NOT|AUTO] COMPRESSED option is now supported in the OPTIONS list of the OPENSTRING clause. This is useful for reading in files created using UNLOAD with the COMPRESSED option. ================(Build #3517 - Engineering Case #692127)================ A new database server property, 'ProcessID', has been added. This proberty returns the PID of the server process. ================(Build #3508 - Engineering Case #691168)================ Load table operations were not permitted on temporary tables in a read-only database, even though other DML operations (INSERT/UPDATE/DELETE/TRUNCATE) were. This has been fixed. Note, as expected no data is logged to the transaction log in this case. ================(Build #3507 - Engineering Case #691167)================ The request timing counters record the number of times, and the duration, a connection blocks waiting for various resources (disk accesses, locks, etc.). These counters were normally only available when the server was run with the -zt option, or when enabled with sa_server_option('RequestTiming', 'on'). As of this change, the ReqTimeBlockIO and ReqCountBlockIO properties are always available, regardless of the -zt setting. These properties are cheap to maintain, relative to the others, because the time required to wait for a disk access is much larger than that required to update the property. ================(Build #3489 - Engineering Case #688888)================ The ENCRYPTED KEY option of the OPENSTRING clause can now specify a variable name rather than a string. For example: create variable mykey varchar(50); set mykey='TheActualEncryptionKey'; select * from openstring(...) with (...) option (encrypted key mykey); ================(Build #3418 - Engineering Case #678806)================ The ENCRYPTED KEY '<key>' clause is now supported in the openstring OPTIONS clause. This is useful for reading in files created using UNLOAD with the ENCRYPTED clause. ================(Build #3393 - Engineering Case #677104)================ Current login policy allowed putting a restriction over the number of failed login attempts a user can make before the user's account is locked. However, this restriction did not apply to users with DBA authority. Regardless of the number of failed login attempts, a DBA user was always allowed to login if correct credentials are provided. This made DBA accounts vulnerable to brute force attacks. This has been changed with the new option, max_failed_login_attempts. The value of this option is also applied to users with DBA authority. However, to prevent complete database lock down, an automatic unlock time of 1 minute is also applied. At the time of database restart, a DBA user will also be allowed to make one failed login attempt, regardless of the number of failed login attempts stored in the catalog. ================(Build #3370 - Engineering Case #673210)================ The NodeType connection parameter is used by read-only scale-out to possibly redirect a connection to a different server. Previously, NodeType supported the values DIRECT, PRIMARY and COPY. Support has now been added for MIRROR and READONLY values. MIRROR - When the NodeType connection parameter is set to MIRROR, and you have connected to a copy node or the primary server, the connection is redirected to the mirror server. READONLY - When the NodeType connection parameter is set to READONLY, and you have connected to a copy node or the primary server, the connection is redirected to the copy node in its branch with the lowest load. If there are no copy nodes, the connection is redirected to the mirror server. If you have connected to the mirror node the connection is accepted since the mirror server does not know the status of the copy nodes. READONLY is used to connect to any read-only server, either a copy node or the mirror. ================(Build #3338 - Engineering Case #667668)================ The following two extensions have been made to the -xa option: 1) The dbn= value can be "*", which means any database can use this server as an arbiter. 2) The auth= value can be: a) omitted, which means no validation of the authentication string provided by a mirror server is done. b) a single value, which means all databases must use the same authentication string. c) a list of values with the same number of entries as specified by dbn= (i.e. previous behavior) ================(Build #3287 - Engineering Case #657712)================ Additional information is now saved for graphical and long plans. This additional information includes: - Known values for expressions are now dumped in the plans. For example, a stored procedure parameter known at the optimization time is dumped as 'parm1[100]' if its name is 'parm1' and its known value is '100'. - For long plans generated by the application profiling, extra information related to the optimization process is now dumped. For example, 'Plan [ Total Cost Estimate: 3.5657, Costed Best Plans: 1, Costed Plans: 13, Optimization Time: 0.074541, Estimated Cache Pages: 590 ]' This type of information is already present for long plans generated by calling the explanation() function. - Information related to the cached plan of a statement is now dumped in its long plan. - Predicates used to generate fence posts for a partial index scan are now dumped in the long plans generated by the application profiling. This type of information is already present for long plans generated by calling the explanation() function. Also, graphical plans with statistics saved during tracing did not actually contain any statistics. This has been fixed.

SQL Anywhere - Sybase Central Plug-in

================(Build #3707 - Engineering Case #704191)================ Changes have been made to Sybase Central to allow it to run with the Java 1.7 runtime. Note, this change also relates to the Interactive SQL utility as well. Sybase Central and the Interactive SQL utility were not reviewed for compatibility. ================(Build #3589 - Engineering Case #699988)================ When Sybase Central attempted to execute SQL that used a secured feature, an error would have been reported immediately. Now, a prompt is displayed, allowing the server's secure feature key to be specified, after which the original SQL statement is re-executed. Note that the server must be started with a secure feature key (-sk) to make use of this feature.

SQL Anywhere - Utilities

================(Build #3596 - Engineering Case #701470)================ The Certificate Viewer utility (viewcert) now accepts the -q parameter, which will suppress all output from the command, including error messages. ================(Build #3561 - Engineering Case #697020)================ Parameters for the Certificate Viewer utility (viewcert) can now be put into a response data file and viewcert can be called as: viewcert @data. ================(Build #3363 - Engineering Case #672080)================ The following new entry point has been added to the dbtools library: DBLogFileInfo function Obtains the log file and mirror log file information of a non-running database. Prototype short DBLogFileInfo ( const a_log_file_info * ); Parameters A pointer to a structure. See a_log_file_info structure . Return value A return code, as listed in Software component exit codes . Remarks The DBLogFileInfo function returns the log file and mirror log file paths of a non-running database file. Note that this entry point will only work for databases that have been created with SQL Anywhere 10.0.0 and up. ----------------------------------------------- Here is the necessary information for the new a_log_file_info structure: typedef struct a_log_file_info { unsigned short version; // set this to DB_TOOLS_VERSION_NUMBER MSG_CALLBACK errorrtn; const char * dbname; // database file name spec const char * encryption_key; // database file encryption key char * logname; // buffer for returning log file name size_t logname_size; // size of the logname buffer char * mirrorname; // buffer for returning mirror log file name size_t mirrorname_size; // size of the mirrorname buffer void * reserved; // reserved for internal use, must set to NULL } a_log_file_info; ================(Build #3300 - Engineering Case #662054)================ When deploying, the directory used by the Interactive SQL utility, Sybase Central, the Console utility, and the MobiLink Monitor, can now be specified. To do this, an OEM.ini file must be deployed along with these utilities. The file must contain the following lines: [preferences] directory={preferences files directory| where "preferences_files_directory" is a fully-qualified directory name, e.g. "c:\work\prefs". The directory name should not end in a separator (backslash on Windows; forward slash on Unix and Mac OS X). Preferences files include: .isqlPreferences12_32 .isqlPreferences12_64 .isqlHistory12 .jlogon12 .textCompleter12 .SybaseCentralEditor610 .scUserPreferences610_32 .scUserPreferences610_64 among others. ================(Build #3299 - Engineering Case #661493)================ The certificate utilities, Certificate Viewer (viewcert), Certificate Creation (createcert), and Key Pair Generator (createkey), now run on 64-bit Windows.

SQL Remote for SQL Anywhere - Database Tools Interface

================(Build #3346 - Engineering Case #668757)================ SQL Remote for SQL Anywhere (dbremote) now supports HTTP and HTTPS as a message type for SQL Remote messages for remote databases. Users wishing to use the HTTP or HTTPS message type from a remote database will configure the remote database using the SET REMOTE OPTION command, in the same way that the FILE, FTP and SMTP message type is configured. The HTTP/HTTPS message type uses the following control parameters that are set by the SET REMOTE OPTION statement: • url : Specify the server name or IP address and optionally the port number of the HTTP server being used, separated by a semi-colon. If requests are being passed through the Relay Server, you can optionally add an URL suffix to indicate which server farm the request should be passed to. url=’server-name[:port-number][url_suffix]’ • https : Specify whether to use HTTPS (https=YES) or HTTP (https=NO). • certificate : To make a secure (HTTPS) request, a client must have access to the certificate used by the HTTPS server. The necessary information is specified in a string of semicolon-separated key/value pairs. You can use the file key to specify the file name of the certificate, or you can use the certificate key to specify the server certificate in a string. You cannot specify a file and certificate key together. The following keys are available: file : The file name of the certificate. certificate : The certificate itself. company : The company specified in the certificate. unit : The company unit specified in the certificate. name : The common name specified in the certificate. Certificates are required only for requests that are either directed to an HTTPS server, or can be redirected from a non-secure to a secure server. Only PEM formatted certificates are supported. certificate=’key=value[:key=value]' • user : The HTTP server user ID. Authenticates to third-party HTTP server and gateways using RFC 267 Basic Authentication. user=’userid’ • password : The HTTP server password. Authenticates to third-party HTTP server and gateways using RFC 267 Basic Authentication. password=’password’ • debug : When set to YES, all HTTP commands and response are displayed in the output log. This information can be used for troubleshooting HTTP support problems. The default is NO. • proxy : Specifies the URI of a proxy server. For use when SQL Remote must access the network through a proxy server. Indicates that SQL Remote is to connect to the proxy server and send the request to the message server through it. proxy=’http://proxy-server[:port-number]’ • client_port : Identifies the port number on which SQL Remote communicates using HTTP. It is provided for and recommended only for connections through firewalls that filter "outgoing" TCP/IP connections. You can specify a single port number, ranges of port numbers, or a combination of both. Specifying a low number of client ports could result in SQL Remote being unable to send and receive messages if the operating system has not released the ports in a timely manner after SQL Remote closes the port on a previous run. client_port=’nnnn[-mmmm]’ Unlike the FTP or SMTP message type, which relies on a third-party FTP or E-mail server, the HTTP message type makes use of the web services functionality that exists in the SQL Anywhere database engine to act as the HTTP server, which we refer to as a "message server". In order to setup the message server, you only need to run the sr_add_message_server on the consolidated database, and ensure that the database server has been started with the -xs http[s] switch. If starting the HTTP[S] listener on a database server hosting the consolidated database is a performance or security concern, then you can use a separate database server, as long as the database you run sr_add_message_server on has identical SQL Remote definitions to your consolidated database. For more information on how to setup a consolidated database to be a message server, how to setup a separate message server, or how to use the Relay Server to forward HTTP requests from remote database to the message server, please read the tutorials and full documentation. The SQL Remote documentation has been updated to include information about the new message type. In the SQL Anywhere installation directory, see: documentation/en/pdf/sqlremote1201.pdf

SQL Remote for SQL Anywhere - SQL Remote for Adaptive Server Anywhere

================(Build #3276 - Engineering Case #655157)================ If there were any missing messages, SQL Remote would have asked for a resend after it had reached its receive polls given by the -rp option. This resend logic could have caused the publisher to re-scan the transaction log(s) and slow down replicating new transactions, especially on heavy load databases. This has been changed so that when a message in a multi-part message series (SQL Remote will generate multiple messages for a single transaction to form a multi-part message when the transaction is too big to fit in a single message) is missing, SQL Remote will not immediately ask for a resend, if the received messages are not followed by any messages that contain a commit or any messages that belong to another multi-part message series. This new logic will help users who need to shut down or kill SQL Remote when it is sending multi-part messages to its subscribers.

UltraLite - Runtime Libraries

================(Build #3713 - Engineering Case #701779)================ For the UltraLite C++ API, methods using wide characters (UTF-16/UCS-2) are generally only supported for Win32. This change adds wide character support for the character data streaming methods, on iOS. The affected methods are: ULPreparedStatement::AppendParameterStringChunk ULResultSet::GetStringChunk ULResultSet::AppendStringChunk ================(Build #3480 - Engineering Case #687980)================ UltraLite is now supported on the Pocket PC 2003 platform. Support for TLS and HTTPS sync encryption, however, is not available for this platform. ================(Build #3339 - Engineering Case #667716)================ A new name type ul_name_type_qualified has been added to ul_column_name_type in tjhe header ulcpp.h. When this new name type is used in conjunction with the GetColumnName function in the ULResultSetSchema class, a qualified name for the associated column in the ResultSet can be obtained, if possible. If the column represents a correlated table, then that qualified name is used; if the column represents a table column, then that qualified name is used; if the column has an alias name, then that name is used. Otherwise, an empty string is returned. ================(Build #3308 - Engineering Case #663307)================ UltraLite now supports the 'armv7' architecture when targeting iOS. With the just-released Xcode and SDK versions, the default includes armv7. ================(Build #3292 - Engineering Case #659615)================ Some internal optimization algorithms have been generalized and improved. This may change plans for queries.

UltraLiteJ - Runtime

================(Build #3747 - Engineering Case #708638)================ UltraLitej for BlackBerry now supports end-to-end stream encryption. Some methods that were previously Android-only are now available for other platforms: /** Sets the name of the file containing the end-to-end public key. * <p> * By default, this value is null, indicating that end-to-end encryption is * not used. * <p> * Corresponds to MobiLink client network protocol option "e2ee_public_key". * * @param public_key The name of RSA public key file used in the encryption. */ public void setE2eePublicKey( String public_key ); /** Get the name of the file containing the end-to-end public key. * * @return the name of the file containing the end-to-end public key. */ public String getE2eePublicKey(); And there are also BlackBerry-specific methods to change the encryption type. ECC end-to-end encryption is available only for BlackBerry. /** * Pass this to setE2eeType to use RSA-based end-to-end encryption */ public final short E2EE_RSA = 0; /** * Pass this to setE2eeType to use ECC-based end-to-end encryption */ public final short E2EE_ECC = 1; /** * Set the type of end-to-end encryption to use. Pass one of StreamHTTPParms.E2EE_RSA or * StreamHTTPParms.E2EE_ECC. The default is StreamHTTPParms.E2EE_RSA. * <p> * Only available on BlackBerry. ECC encryption is not supported on other platforms. * * @see StreamHTTPParms.E2EE_RSA * @see StreamHTTPParms.E2EE_ECC * @param type One of E2EE_RSA or E2EE_ECC */ public void setE2eeType( short type ); /** * Returns the end-to-end encryption type being used. * <p> * Only available on BlackBerry. ECC encryption is not supported on other platforms. * @return the end-to-end encryption type being used */ public short getE2eeType(); The public key used must be DER encoded. The public key needed for end-to-end encryption can either be stored on an SD card or the device object store. When using an SD card, the parameter to setPublicKey should have the form "sdcard://<path>" where "<path>" is the absolute path to the file on the card. e.g. "file:///SDCard/ulj/public_key.der". When using the object store, use the file transfer utility built into ULj to download the file from the MobiLink server. To use file transfer to transfer a key it must have an extension of ".der". ================(Build #3747 - Engineering Case #708578)================ UltrLitej for BlackBerry and J2SE now support zlib stream compression. Some methods that were previously Android-only are now available for other platforms: /** Enables or disables ZLIB compression. * <p> * By default, ZLIB compression is disabled * <p> * Only available for Android and BlackBerry * <p> * Corresponds to MobiLink client network protocol option "compression=zlib". * * @param enable Set to true to enable ZLIB compression, or false to disable * ZLIB compression. */ public void setZlibCompression( boolean enable ); /** Sets the download window size for ZLIB compression. * <p> * Only available for Android and BlackBerry * <p> * Corresponds to MobiLink client network protocol option "zlib_download_window_size". * * @param size The compression window size specification, inclusively * ranging from 9 to 15. This parameter is the base two * logarithm of the window size. (the size of the history * buffer) */ public void setZlibDownloadWindowSize( int size ); /** Sets the upload window size for ZLIB compression. * <p> * Only available for Android and BlackBerry * <p> * Corresponds to MobiLink client network protocol option "zlib_upload_window_size". * * @param size The compression window size specification, inclusively * ranging from 9 to 15 for Android and 10 to 15 for BlackBerry. * This parameter is the base two * logarithm of the window size. (the size of the history * buffer) */ public void setZlibUploadWindowSize( int size ); ================(Build #3747 - Engineering Case #708576)================ UltraLitej for BlackBerry and J2SE now support basic HTTP authentication. New methods have been added to StreamHTTPParms: /** * Sets the userid and password used for Basic HTTP authentication as * described in RFC 2617. * <p> * With Basic authentication, passwords are included in HTTP headers in * clear text; however, you can use HTTPS to encrypt the headers and * protect this password. * * @param userid The userid to use * @param password The password to use */ public void setHTTPUserIDAndPassword( String userid, String password ); /** * Returns the userid previously set by setHTTPUserIDAndPassword. * * @returns The userid previously set by setHTTPUserIDAndPassword */ public String getHTTPUserID(); /** * Returns the password previously set by setHTTPUserIDAndPassword. * * @returns The password previously set by setHTTPUserIDAndPassword */ public String getHTTPPassword(); ================(Build #3747 - Engineering Case #708575)================ UltraLitej for BlackBerry and J2SE now support custom HTTP headers. New methods have been added to StreamHTTPParms: /** Adds a message header to each HTTP request. If addCustomHTTPHeader is called * more than once with the same name parameter, the values are concatenated together * into a comma-seperated list. * <p> * The following standard headers are set by ULj and cannot be changed using * addCustomHTTPHeader: Connection, Content-Length, User-Agent, Content-Type, and * Content-Length. Other headers may also be modified by the Java VM. * <p> * Not available on Android. On Android, specify a custom_header parameter using * setExtraParameters * * @param name The name of the header * @param value The value of the header */ public void addCustomHTTPHeader( String name, String value ); /** Returns a Hashtable containing the HTTP headers specified using addCustomHTTPHeader * * @return Returns a Hashtable containing the HTTP * headers specified using addCustomHTTPHeader */ public java.util.Hashtable getCustomHTTPHeaders(); Custom cookies can be specified by calling addCustomHTTPHeader with "Cookie" as the header name. ================(Build #3741 - Engineering Case #709898)================ UltraLiteJ for Android now supports changing the database encryption key as documented for UltraLite. The following API was added: Connection.changeEncryptionKey( String newKey ) For consistency the following APIs were added, which are equivalent to setDatabaseKey and getDatabaseKey respectively: ConfigPersistent.setEncryptionKey( String key ) String ConfigPersistent.getEncryptionKey() ================(Build #3723 - Engineering Case #705847)================ UltraLiteJ for Android now supports restartable downloads as documented for C UltraLite. The following APIs have been added: Connection.rollbackPartialDownload() SyncParms.setAdditionalParms( String v ) SyncParms.getAdditionalParms() SyncParms.setKeepPartialDownload( boolean c ) SyncParms.getKeepPartialDownload() SyncParms.setResumePartialDownload( boolean c ) SyncParms.getResumePartialDownload() SyncResult.getPartialDownloadRetained() ================(Build #3712 - Engineering Case #703229)================ Performance improvements have been made when adding rows sequentially into an index. For example, a table whose primary key consists of an autoincrement column, or an initial download with a download cursor that sorts the download by primary key. When doing single inserts, UltraLiteJ now does less page reads and writes. When doing a block of inserts, the page read and writes may remain the same but CPU work has been greatly reduced. ================(Build #3605 - Engineering Case #702006)================ Indexes in UltraLiteJ now support index hashing using the "WITH MAX HASH SIZE x " SQL clause. Index hashing improves inserts, updates, deletes and searches when the columns being indexed have a good distribution of values (for example strings that do not have a common prefix) at the cost of bigger index structures. Hashed indexes locate rows first using the hash, then direct row comparison to differentiate rows with the same hash value. If the hash size is sufficiently big, the hash will uniquely identify a row without needing to read and compare the row. However, if the hash size is too big and the page size small, the index may need too many database pages whose maintenance costs offset the benefits of hashing. Columns of type REAL, DOUBLE, GEOMETRY, LONG BINARY and LONG VARCHAR are not hashed (LONG columns cannot be indexed in UltraLiteJ). If the SQL statement creating an index does not specify a hash size, the value of the Connection.OPTION_MAX_HASH_SIZE option is used as the default. In addition to hashing support, performance improvements were made to indexing to reduce the number of pages written when committing inserts, updates and deletes. ================(Build #3605 - Engineering Case #701654)================ With UltraLiteJ for Android, the validateDatabase method has been added to the Connection class: public void validateDatabase( int flags, ValidateDatabaseProgressListener listener, String tableName ) The interfaces ValidateDatabaseProgressData, and ValidateDatabaseProgressListener have also been added. ================(Build #3550 - Engineering Case #696240)================ With UltraLiteJ for Android, the MobiLink file transfer APIs, similar to those for UltraLiteJ for J2SE and BlackBerry, are now supported. Specifically, the method DatabaseManager.createFileTransfer( String fileName, int streamType, String userName, String version ) is supported, as are the interfaces FileTransfer, FileTransferProgressData, and FileTransferProgressListener. ================(Build #3533 - Engineering Case #694022)================ In UltraLiteJ for Android, the API StreamHTTPParms.setExtraParameters( String ) has now been added. The classes StreamHTTPParms/StreamHTTPSParms contain a number of methods to set MobiLink client network protocol options as properties, eg. setHost( String ). However, there were no methods to cover all possible MobiLink client network protocol options. This API can now be used to specify a semi-colon-delimted list of options that are appended to the options that are generated by the property settings for the class. The meaning of the option list for this API is as specified in the documentation of MobiLink client network protocol options. ================(Build #3517 - Engineering Case #690250)================ The UltraLiteJ runtime now supports restartable HTTP synchronizations. With restartable HTTP enabled, UltraLiteJ applications can tolerate network interruptions, so synchronizations will fail less often on unreliable networks. Restartable HTTP is disabled by default. To enable, use the following new methods on the StreamHTTPParms class: /** * Enables or disables restartable HTTP. With restartable HTTP enabled, * UltraLiteJ can tolerate network interruptions, so synchronizations will fail * less often on unreliable networks. * <p> * To use restartable HTTP, both UltraLiteJ and the MobiLink server must have * applied CR#690250. * * @param isRestartable Pass true to enable restartable HTTP, and false to * disable. The default is false. * @see #isRestartable() */ public void setRestartable( boolean isRestartable ); /** * Returns true if restartable HTTP will be used, and false otherwise. * * @return Whether restartable HTTP will be used. * @see #setRestartable(boolean) */ public boolean isRestartable(); To use this change, both remotes and servers must be upgraded. It is safe to upgrade only one of the remote or the server, as long as setRestartable is not called on the remote. ================(Build #3478 - Engineering Case #680231)================ Databases which are accessed with row limiting enabled (see ConfigPersistent.setRowMinimumThreshold and setRowMaximumThreshold) will now always lazy load indexes. ================(Build #3335 - Engineering Case #667152)================ Some internal optimization algorithms have been generalized and improved. This may change plans for queries. ================(Build #3324 - Engineering Case #665538)================ ZLIB compression has been added to UltraLiteJ for the Android. This is accomplished with the following addition methods: setZlibCompression( boolean ) setZlibDownloadWindowSize( int ) setZlibUploadWindowSize( int ) zlibCompressionEnabled() ================(Build #3315 - Engineering Case #664390)================ End-to-end encryption (e2ee) has been added to UltraLiteJ for the Android platform. This was accomplished by using the new methods in the StreamHTTPSParms interface: void setE2eePublicKey( String file_name ) String getE2eePublicKey() The file_name is the name of an RSA public key file used in the encryption.

UltraLiteJ - Utilities

================(Build #3309 - Engineering Case #663502)================ A new UltraLiteJ utility, ULjExportBuilder, has be added. This utility takes an existing J2SE UltraLiteJ database and produces a more compact file that can be deployed to J2SE or RIM clients. An equivalent database can then be created from the exported file. usage: ULjExportBuilder database-file exported-file The required two arguments are file names. The database must not be encrypted and must be a shadow-page database (the default). To invoke the export functionality from a Java program, create an object com.ianywhere.ultralitej.pgmsutility.ULjExportBuilder (there are no arguments passed to the constructor) and then invoke the export method with one argument which is a two-element String array containing the names of the database and export files respectively. The exported file can placed on a client device using, for example, a MobiLink file transfer. The database may be imported using an import method which has three arguments: java.io.InputStream which is used to read the exported file String to specify the name of the database null (no encryption) or an EncryptionControlObject which will be used to encrypt pages within the database. (1) On Rim devices the methods are: DatabaseManager.importDatabaseFileME (import to a RIM file in flash or on an SD-card) DatabaseManager.importDatabaseObjectStore (import to the Rim Object store) (2) On J2SE: DatabaseManager.importDatabaseFile (import to a file )



12.0.1 Bug Fixes

(see also Critical Bug Fixes) (see also New Features)
This section contains a description of bug fixes made since the release
of version 12.0.1.

MobiLink - Java Plugin for Sybase Central

================(Build #3740 - Engineering Case #709761)================ When attempting to open a log file using the MobiLink Server Log File Viewer, if the file could not be opened for any reason, an error message saying that the file cannot be opened was displayed and then Sybase Central would have reported an internal error. The problem which caused the internal error has been fixed. ================(Build #3514 - Engineering Case #691891)================ If all the consolidated tables were already mapped in a synchronization, and the New Table Mappings menu or toolbar button was used, the user would have been incorrectly prompted to update the remote schema instead of the consolidated schema. Also, unchecking the option to add a table to the remote schema when adding a table mapping, would have resulted in the new table mapping having no remote table. These problems have now been fixed. ================(Build #3483 - Engineering Case #685982)================ Updating the remote schema in a synchronization model from an UltraLite database may have subsequently caused errors, including NullPointerException, if a user was not specified when connecting to the UltraLite database. This would have changed the remote tables to have no owner, but the table mappings may still have referred to remote tables using owners. Such invalid mappings were not detected by the program when opening a synchronization model. This has been fixed. Owner mismatches for table mappings are now detected when the remote table in either the remote schema or the table mapping has no owner .A workaround is to specify a user when connecting to the UltraLite database to update the remote schema. The error message displayed when a table in a table mapping can't be found in the corresponding schema has also been fixed. The message now correctly includes the table name that could not be found, instead of displaying '{0}' for the table name. Another problem is also addressed with this change. Previously if you changed the remote table for a table mapping, some options could change to their defaults, such as the direction changing to bidirectional. Now the synchronization direction and other synchronization options are maintained. ================(Build #3429 - Engineering Case #682889)================ Changes made using the Interactive SQL utility might not have been automatically committed when it was closed, if it was opened from a new MobiLink project. This problem only affected newly created MobiLink projects. If Sybase Central was restarted after creating the project, the problem did not happen. It also only occurred when connect to the consolidated database using only an ODBC data source. If explicit connection parameters were provided, the problem did not happen. This has been fixed. ================(Build #3426 - Engineering Case #682532)================ In version 12 of the Table Mappings editor for synchronization models, if the mapping to direction was changed to "Not synchronized" it was not possible to use the same menu to change it back. As a work around, either use Edit > Undo, or save the model and re-add the table mapping. This has been fixed. Now the table mapping direction menus remain enabled after changing the mapping direction to "Not synchronized". ================(Build #3423 - Engineering Case #681081)================ The connection string an agent uses to connect to a given remote database can be changed by selecting the agent, then selecting a database on the "Managed Remote Databases" panel and clicking the "Set Connection String" menu. If the "Cancel" button was clicked on the resulting window, the changes were made permanent, as if "OK" had been clicked instead. This has been corrected so that the changes in the dialog are discarded when "Cancel" is clicked. ================(Build #3423 - Engineering Case #681055)================ When setting the MobiLink client network protocol options for an Agent, it was not possible to specificy a certificate file name if that name contained any of the following characters: "!@#%^&()+-_". Attempting to do so would have resulted in an error message saying there was a syntax error in the protocol options. This message was incorrectly being display, and is now not shown. ================(Build #3373 - Engineering Case #673646)================ It was possible to check both the "Task runs on a schedule" and "High priority" boxes in the Remote Task Properties window. These options are mutually exclusive, so this should have been disallowed. This has been fixed. ================(Build #3373 - Engineering Case #673641)================ Renaming of a member of a destination alias would have caused an error message saying that there was a problem saving the "deletion rule". Destination alias members can now be successfully renamed without getting an error message. When deleting the members of a destination alias, the exception generated is now explicitly ignored if the client being deleted doesn't actually exist. ================(Build #3338 - Engineering Case #655987)================ The "Apply" button on the property sheet for a Remote Task was not enabled when various changes were made. Now, the button is enabled correctly. ================(Build #3291 - Engineering Case #658860)================ Sybase Central would have crashed when using the QAnywhere plugin to define a property for a connector and the property was given both a blank name and value. Now, the creation of properties with blank names is prevented, as these are meaningless in any case. A message box indicating that the property name must not be empty is displayed. ================(Build #3284 - Engineering Case #657284)================ The MobiLink Server log file viewer in Sybase Central might not have listed all synchronizations in a given log file separately if the log file contained messages from more than one run of the MobiLink Server. This has been fixed. ================(Build #3284 - Engineering Case #657068)================ In the MobiLink Server Log File Viewer, selecting a synchronization could have resulted in the window becoming unresponsive if the synchronization contained hundreds of thousands of messages. This has been fixed. Also, it was noticed that synchronizations were not initially listed in chronological order if the log file contained output for more than one run of the MobiLink Server. This has also been fixed. ================(Build #3281 - Engineering Case #656863)================ If a synchronization model had script errors that were fixed without opening the Events editor or saving the model, attempting to deploy the model would have erroneously failed because of a script error. This has been fixed. ================(Build #3280 - Engineering Case #656291)================ If a Destination Alias defined in a Server Store was deleted, the alias was still shown in Sybase Central until the QAnywhere server completed the deletion. That could have taken up to a minute, or could never have happened if the QAnywhere server was not running. If deleting the alias was tried a second time, an obscure error message would have been displayed saying that the alias could not be deleted. Now, the Destination Alias is removed from Sybase Central as soon as the user deletes it, the same as in earlier versions of Sybase Central. ================(Build #3275 - Engineering Case #654759)================ Changes to the members list were not saved when the OK button in the property sheet for a destination alias. Also, the Apply button was not enabled after a member was added, removed, or edited. Both of these problems have now been fixed. ================(Build #3268 - Engineering Case #653058)================ When creating a rule with a "Custom" schedule type, the schedule that was saved could have been incorrect if "Run rule every" was turned off in the "Schedule Editor" window. The rule was saved such that it was run every 10 minutes. This has been fixed. ================(Build #3266 - Engineering Case #652577)================ Sybase Central could have crashed while the property sheet for a client message store was open, if adding a new property was started, but then the action was cancelled. This has been fixed.

MobiLink - Monitor

================(Build #3520 - Engineering Case #693579)================ When using the "Export to Database" functionality of the MobiLink Monitor on a 64-bit Linux systems, a dialog with an exception like the following would have been displayed: Error! The DBLIB library could not be loaded. This can happen if your SQL Anywhere installation has been corrupted. You will not be able to search for database servers. /opt/sqlanywhere12/lib32/libdblib12_r.so.1: /opt/sqlanywhere12/lib32/libdblib12_r.so.1: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) Dismissing the dialog would allow the Monitor to continue, but the "Find" button would not have been available to search for SQL Anywhere database servers. Workaround: . /opt/sqlanywhere12/bin64/sa_config.sh export LD_LIBRARY_PATH=/opt/sqlanywhere12/lib64:$LD_LIBRARY_PATH /opt/sqlanywhere12/bin64/mlmon ================(Build #3480 - Engineering Case #687837)================ If an Overview color in the Options dialog was changed, the Overview display would have been erased. This has been corrected. A workaround is to disable, then re-enable, the Overview or change, then change back, the option to keep the Overview window attached to the main window. ================(Build #3325 - Engineering Case #665535)================ When exporting to a database in the MobiLink Monitor, the values exported to the per-table details table (called mlm_by_table by default) were the per-sync values instead of the per-table values. This has been fixed. ================(Build #3299 - Engineering Case #661035)================ When deploying a Synchronization Model for an existing remote database and only deploying to file, the generated Windows batch file would have failed when execute. For example, a "You are not connected to a database" error could have occurred when the batch file tried to apply the generated SQL file to the remote database. This has been fixed. To workaround the problem, change this line in the generated batch file: set CONNECTION=%1 to this: set CONNECTION=%~1 ================(Build #3289 - Engineering Case #658482)================ When a MobiLink Monitor instance that already had a horizontal scroll bar, was connected to a MobiLink server, the Utilization Graph time scale (if Utilization Graph was enabled) would have been different than the Chart time scale. After being connected long enough for the horizontal scroll bar to be redisplayed, the scroll bar position would have been incorrect and the Overview Marquee Tool would have fluctuated between the inconsistent time scales. This has been fixed. A workaround is to use the Marquee Tool, or change the zoom to fix the display, or disable the Utilization Graph to prevent the problem. ================(Build #3286 - Engineering Case #657979)================ The MobiLink Monitor's Zoom To Selection menu or toolbar button might not have panned to the selected synchronization until it was used a second time. This has been fixed. ================(Build #3268 - Engineering Case #653055)================ Any parameters entered on the MobiLink Monitor's command line with a Multibyte Character Set would have been mangled. This has been fixed.

MobiLink - QAnywhere client

================(Build #3759 - Engineering Case #713390)================ In some circumstances, such as a transient connection error to the database server, the MobiLink Client process (dbmlsync) that was launched by the QAnywhere agent could have terminated prematurely. When this occurred, the QAnywhere agent could not perform any message transmission, and the only remedy was to restart the QAnywhere agent. This has been fixed by adding the capability to the QAnywhere agent to restart dbmlsync if it detects that the dbmlsync process has terminated. ================(Build #3726 - Engineering Case #706554)================ The QAnywhere Agent could have failed to start if it could not automatically upgrade the message store in some cases. This problem was introduced by the changes for Engineering case 696917. For 11.0.1.2781 until 2804, the qaagent would have failed to start with message stores created with a qaagent from 11.0.1.2780 and before. For 12.0.1.3711 until 3725, the qaagent would have failed to start with message stores created with a qaagent from 11.0.1.2781 until 2804, or with a qaagent from 12.0.1.3711 and before, or with a qaagent from 12.0.0. This has been fixed. A workaround for this problem is to recreate the message store using qaagent -si, if that is possible. ================(Build #3349 - Engineering Case #669235)================ When starting the QAnywhere Agent (qaagent) with the command line option "-qi", the MobiLink Listener and the MobiLink Client processes were not also launched with "-qi" options, resulting in system tray icons on Windows Mobile devices. This has been corrected. ================(Build #3303 - Engineering Case #662456)================ On a Windows Mobile device, the QAnywhere Agent (qaagent) would have sometimes given the following error messages at start up: E. 2011-03-14 08:33:50. Error registering with DBLSN code: -1 The error message was displayed in a message box, even when qaagent was executed in quiet mode. This has been fixed. Now, qaagent is more tolerant to dblsn slowness at startup. Also, a message box is not displayed when qaagent is executed in quiet mode (-q or -qi), and the message is logged in the qaagent console and log file.

MobiLink - Relay Server

================(Build #3769 - Engineering Case #715167)================ The Relay Server affinity cookies were sometime not used properly by third party client software in cases where the same cookie was used concurrently on different HTTP requests. In such situation, the Relay Server behaviour was to let the latest request to take over the connection associated with the affinity cookie. An optional backend farm property called renew_overlapped_cookie has now been introduced. It has a default value of 'No', which maps to the existing behavior. When renew_overlapped_cookie is set to 'Yes', the Relay Server will detect overlap for the farm that has this property explicitly turned on and renew the overlapping cookie by creating a brand new affinity binding. The request with the renewal will still be routed to the same backend server but not the same backend connection as the on going request that it overlapped with. A new backend connection will be created instead. Relay Server configuration example: [backend_farm] description = a backend server farm id = RSTEST02.F0 renew_overlapped_cookie= yes Online update of the of the renew_overlapped_cookie property is supported. ================(Build #3766 - Engineering Case #715033)================ The following changes have been made to the Relay Server level 4 debug log: - The "Replaying 0 bytes ..." message was confusing and has been suppressed. - Added "Response headers submitted for sending" message. - Logging Content-length expectation up front. - Enhance Content-length replay status with remaining length. - Added user friendly response status and header logging so that users don't need to suffer level 5 payload logging which is heavier and less readable. - Moved user friendly request header logging from log level 5 to log level 4 so that user don't need to suffer level 5 payload logging which is heavier an less readable. ================(Build #3766 - Engineering Case #715025)================ A Relay Server, which doesn't produce urgent flow control packets according to protocol, could have crashed the Outbound Enabler. No Relay Server has been released with this problem, but a fix has been made so that the Outbound Enabler will give an error and not crash in such situations. ================(Build #3765 - Engineering Case #714896)================ Issues with the IIS 6 and IIS& QuickSetup scripts have been corrected: - the IIS7 auto install could not be invoked if the appcmd.exe utility was missing. This issue has been fixed so that appcmd.exe utility is not needed before triggering IIS7 [re]installation. - the IIS7 Relay Server setup script could not handle a machine not having a domain suffix. - the IIS6 & IIS7 Relay Server setup scripts were referencing sleep.exe which is not a standard utility on Windows. The reference has been removed. ================(Build #3758 - Engineering Case #713458)================ The Outbound Enabler was not logging requests at verbosity 1, but the Relay Server does. This has been corrected by lowering the minimum log verbosity level of RS_CLI_SESSION_BEGIN and RS_CLI_REQUEST_BEGIN packets in order to have them logged at verbosity level 1 instead of 3 in the Outbound Enabler. There will now be one log event per HTTP request at log level 1 like the Relay Server does. ================(Build #3755 - Engineering Case #713098)================ When the Relay Server was restarted, new persistent HTTP requests from persisting client cookies from a previous instance of the Relay Server could have caused truncated responses on new requests from new sessions by the time the backend server could have timed out the persistent connection of the old session. This has been fixed. A workaround is to have clients clear their cookie cache. The Relay Server affinity cookie is implemented as a non-persistent cookie, standard http client implementation shouldn't persist the RS affinity cookie across restart of the http client agent. ================(Build #3755 - Engineering Case #713024)================ The Apache setup script now generates <LocationMatch> tags instead of <Location> tags when setting up Apache for RelayServer use. The use of <LocationMatch> allows for a wider range of regular expressions for URL matching, hence, reducing errors resulting from URL-mismatching. This fix also includes changes to the location of generated rs.config and oe.config files (used by the simple test app). The rs.config file is now generated in the RelayServer binaries directory (containing Apache modules and rshost), and the oe.config file is now generated in the same setup scripts directory. ================(Build #3748 - Engineering Case #711685)================ The Relay Server was buffering the entire HTTP chunk in server response for validation before relaying to the client at once. Some backend servers produce large chunks, as big as many megabytes. The buffering was consuming memory, and so reducing scalability. The large write also affected timeliness of the flow control evaluation done interleaving on the same line of execution. This has now been fixed by replacing the handling with streaming packets of size no bigger than 64k regardless of chunk boundary. The validation is still performed but now done with state tracking on the go. ================(Build #3747 - Engineering Case #711393)================ When a non-sticky load balancer was used in front of a Relay Server farm, concurrently requesting larger responses could have resulted in an RSE4003 error. This has been fixed. The workaround is to turn HTTP stickiness on for the load balancer, or to disable Relay Servers until only one remains enabled. ================(Build #3746 - Engineering Case #711258)================ Some shared memory sizes and other memory usage were logged using a format that cannot display value greater than 4 Gbytes. This has been corrected. ================(Build #3746 - Engineering Case #711219)================ Some occurances of Relay Server error messages had the backend farm and server names in the wrong order. Errors affected were: RSF13000, RSF13001, RSF13007, RSF14000, RSF14001, RSF14002, RSF14003. This has now been corrected. ================(Build #3741 - Engineering Case #710111)================ The Relay Server Outbound Enabler report would have reported session errors without parameters to Relay Server, but subsequent errors may have caused a crash. This has been fixed. ================(Build #3741 - Engineering Case #710078)================ When a cookie used by the Relay Server is not encoded properly, it should result in a RSE1003 error, but sometime the error RSE2003 was raised instead. This has been fixed. ================(Build #3741 - Engineering Case #709219)================ When starting the Outbound Enabler, if the machine where the Relay Server was installed was running, but the Relay Server was not available, the Outbound Enabler would have started, failed to gather a Relay Server peer list, and then done nothing until it was manually shut down. This has been corrected so that the Outbound Enabler will now loop and continue to try and gather the Relay Server peer list until it is successful, or it is told to shut down. ================(Build #3739 - Engineering Case #709640)================ The Relay Server Outbound Enabler uses GET requests to monitor backend server status when the -cs command line option is used. The GET request was using an incorrect host header that always pointed to localhost:80. This has been fixed to respect the host and port implied by the -cs option. ================(Build #3738 - Engineering Case #709506)================ The IIS Quick Setup script has had the following enhancements: 1) When the Relay Server is loaded with a high volume of requests and payload, transfer rate per client may thin out to a point that it cannot satisfy a preset requirement of IIS. The result is a dropping of connections and a Timer_MinBytesPerSecond event in the HTTPERR log. A change has been made in section 5b of the setup script to disable this minimum transfer rate requirement. 2) The Relay Server uses a default application timeout of 8 minutes. A change has been made in section 5b of the setup script to configure the connection timeout value of the web server to be 1 minute higher than the default application timeout. The client application can lower the timeout on a per request basis. The purpose of this change is to remove timeout issue due to mismatch timeout settings along the chain. ================(Build #3730 - Engineering Case #707729)================ The Relay Server may have exhibited undefined response behavior in some error cases. This has been corrected. ================(Build #3729 - Engineering Case #707554)================ The following improvements have been made to the interactive quick setup feature for the Relay Server running on an Apache web server: - Improved script interaction, especially questions with (Y/n) choices. Defaults have been added to speed up progress. - Output log is now flushed timely to give complete log if script is stopped at any time. - Removed the option of keeping test services running to overcome a hanging problem. - Wording has been improved in several places. ================(Build #3729 - Engineering Case #707534)================ The Relay Server is designed to overload the up-channel liveness for notifing the Outbound Enabler in the case the down-channel is not connected. This gives the Outbound Enabler a chance to increase down-channel puncture data, as the web server can be be set up to buffer the request to a certain amount before passing to the extension for handling and takeover the rest of the reading of the request. This issue was introduced in 12.0.1 when HTTP authentication support was added to the Outbound Enabler, where the test request will fool the Relay Server into thinking the down-channel connection was successful. This fix is to change the Relay Server to deal with the Outbound Enabler behavior change. ================(Build #3729 - Engineering Case #707124)================ Mixing different versions of Relay Server components together on a single server is not supported and may have lead to crashes in some combinations. Now, the SQL Anywhere version and build number are used to detect conflicts. Any conflicts are reported via the following HTTP response status: 500 Abort due to version of this Relay Server extension conflicts with the version of the running rshost Note, this change also fixes some error responses that didn't terminate the header list with \r\n. ================(Build #3728 - Engineering Case #707078)================ When a Relay Server received a request with cookie pointing to a backend that was no longer connected, the Relay Server would have done unnecessary processing and reported twice the request to be aborted with verbosity level 2 or higher. This extra processing has now been removed. ================(Build #3728 - Engineering Case #707033)================ When a property was repeated in a section of the Relay Server configuration file, or when a section header separating two sections of the same type of object was missing, the Relay Server would have started without complaints, silently overriding repeated properties. This behaviour has now been corrected to abort the startup with an error. ================(Build #3728 - Engineering Case #706846)================ The Relay Server would have had the client expire the affinity cookie for the case where the Outbound Enabler detected a request specific error and reported the error back to the Relay Server. This didn't cover other error cases where the Relay Server had enough information to also have the client to give up the Relay Server affinity cookie. This fix is to add cookie expiry for those uncovered cases as well. The Relay Server will also response to the client with cookie expiry if the backend server responds to the client with HTTP 400 or higher. This fix also strengthens validation of the cookie format, improves HTTP status codes, and provides finer HTTP status messages for easier diagnosis. The responses being changed are summarized in the following table: New response New response expires cookie? Old response as a record of behavior change 500 Relay server failed creating client traffic record n 500 Relay server error 500 Relay server failed initializing server access n 500 Relay server error 500 Relay server failed writing locking request list n 500 Relay server error 500 Relay server failed creating request n 500 Relay server error 500 Relay server failed initializing request n 500 Relay server error 500 Relay server failed adding initialized request n 500 Relay server error 401 The backend farm client_security property in the Relay Server configuration disallow this type of client transport y 401 The backend farm rejected this client security 500 Relay server failed initializing backend farm access n 500 Relay server error 400 Bad affinity query y 401 Bad affinity query 400 Bad session id y 401 Bad session id 404 Backend farm is missing from URL y 404 Not found 404 Backend farm not found y 404 Not found 503 The backend farm is currently disabled n 404 The backend farm is currently disabled 400 Backend server encoded in cookie not found y --No change -- 400 Bad request with no response from backend server y --No change-- Note, the HTTP status messages will remain generic for the Relay Server for Apache, which may not follow the new status codes. This Relay Server for Apache issue will be addressed as a separate platform dependent issue which is independent to this one. ================(Build #3726 - Engineering Case #706812)================ The Relay Server Outbound Enabler may have crashed when it was running with a Relay Server farm, and the backend server was under heavy load or busy, then went down or became unresponsive. This problem has been corrected. ================(Build #3725 - Engineering Case #705997)================ The Relay Server could have deadlocked after an I/O error with a client while receiving a large http response. The Outbound Enabler would have tried to recover, but would have failed with an RSE3003 error (displayed in the Relay Server log) until the original up-channel failed with error RSE3009. After that, the Outbound Enabler up-channel retry would have resulted in the error RSF13002 being displayed in the Relay Server log over and over until the Relay Server was restarted. New sessions accessing the same backend farm would have resulted in the error RSF14001. This has been fixed by allowing the Relay Server to recover from this deadlock state without causing any Relay Server fatal errors, and the backend service should recover successfully. ================(Build #3718 - Engineering Case #695549)================ When the ias-rs-status-refresh-sec url query parameter was specified on a status page url, the Relay Server would have returned the error: HTTP 404 "Not Found". This has been fixed. ================(Build #3710 - Engineering Case #702818)================ If a client with an old cookie accessed a blacked out backend service, the subsequent requests when the backend server comes back up will suffer load latency under low load situations. This has been fixed. ================(Build #3709 - Engineering Case #702528)================ The SQL Anywhere Monitor for Relay Server was the only means to observe the breakdown of time costs in different phases of a request, response processing. There were two issues with this: 1. The numbers rendered through the browser were aggregated and averaged across all requests going to the same backend server. So individual request tracing was not viewable. 2. The Monitor was not included in any rebundling of the Relay Server. The verbose logging (-v 4) of the Relay Server Outbound Enabler (RSOE) of the DoneReceive event has now been enhanced to include a Since Last Sent (sls) number. The sls measures number of millisecond elapsed since the completion time of the last send that occurred on the same socket that had just completed a receive operation. This can be used as a measure of the backend server processing time, which includes the communication cost of sending the last packet (as the OS can declare completion before the packet is actually flushed) between the RSOE and the backend server (which normally should be minimal when they are local to each other). Here is a sample log line: <Backend-0000> DoneReceive: sidx=0 ridx=0 socket=01227b58 sfp=f6c1ee75 len=65514 usage=8192 (12%) sls=0 If the backend server also reports a value for the overall request-response processing time, the associated sls value can be used to verify the qualify of the measurement without need to insert third party sniffing tools, which may, in some cases, change the network topology and invalidate the study. ================(Build #3639 - Engineering Case #704622)================ The opcode parameter in the Relay Server error RSE4007 was not logged properly. This has been fixed. Note: this change is fixed the English resource only. ================(Build #3605 - Engineering Case #701651)================ Relay Server Outbound Enabler up channel packet header logging is enabled by setting the verbosity level (-v) to 3 or higher. The logs are useful for the analysis of certain issues. Two of the packet headers were carrying incomplete information: <UpChannel-0000> 499 RS_CLI_SESSION_BEGIN(snum=0000 sfp=995770b6 ridx=0) <UpChannel-0000> 557 RS_CLI_REQUEST_BEGIN(oidx=0 snum=0000 sfp=995770b6 ridx=0 sidx=0) This has been fixed to complete the logging like the following: <UpChannel-0000> 499 RS_CLI_SESSION_BEGIN(snum=0000 sfp=7329322a ridx=0 appt=2 per=1) <UpChannel-0000> 557 RS_CLI_REQUEST_BEGIN(oidx=0 snum=0000 sfp=7329322a ridx=0 sidx=0 appt=2 per=0) ================(Build #3604 - Engineering Case #701382)================ The Relay Server and the Outbound Enabled log files contained an error in the UTC time zone offset log line. This has been fixed. The correct log line now reads: "Time zone offset from UTC in minutes:" ================(Build #3599 - Engineering Case #701212)================ The Relay Server responded with an HTTP 401 status code when the client accessing the backend farm didn't fulfill the client security requirement specified by the client_security property in the backend_farm section in the Relay Server configuration. The message had a typo that has now been corrected to: "The backend farm rejected this client security" ================(Build #3596 - Engineering Case #700803)================ Client software is expected to have full control of Relay Server affinity using standard HTTP cookie reflection, or proprietary Relay Server affinity header reflection. However, as the Relay Serve usage evolved to cover many kinds of clients, some client software behaves unreasonable in the sense that it was stubbornly reusing the same invalid cookie repeatedly after an error. The expected behavior was either the client software would have discarded the cookie after error, or add an IAS-RS-AF=new URL query parameter to restart a new application session with a new cookie. The Relay Server cookie can become invalid for various reasons including application timeout, Relay Server farm member removal, communication error between OE and the backend server, and others. If the client software doesn't conform to the expectation, the application could have been stuck with an invalid cookie until it was deleted manually. This fix is to have the Relay Server explicitly instruct the client software to expire the cookie immediately when the Relay Server knows the affinity has became invalid. Again, not all stubborn client software can benefit from this, but those that support expires cookie attribute (pre-RFC Netscape draft spec for cookies) should. ================(Build #3596 - Engineering Case #700788)================ Affinity cookies assigned by the Relay Server could have become invalid to the Outbound Enabler over time when the Relay Server was being removed from a Relay Server farm. An Outbound Enabler receiving such a request will trigger an unnecessary internal restart that drops other innocent requests. This has been fixed so that the Outbound Enabler will report an OE_SESSION_ERROR to the Relay Server without affecting other ongoing requests. ================(Build #3596 - Engineering Case #700759)================ Some wording in the Relay Server quick setup script has been corrected. The software is not affected by this change. ================(Build #3595 - Engineering Case #700715)================ Downloads of small requests while the Relay Server Outbound Enabler down channel was under low load situation, may have suffered 200ms TCP Nagling latency. This has been fixed by inserting a pad of Ethernet MTU size in order to defeat the Nagling latency at the end of foreseeable download data. ================(Build #3574 - Engineering Case #698218)================ An attempt by the Relay Server to notify the Outbound Enabler to disconnect the associated backend connection may have been mis-routed and discarded. This would have caused a delay in closing the backend connection, together with a SYS64 error, when the backend server eventually timed out the connection. The conditions for this problem were: - TCP load balancer without stickiness was used in front of a Relay Server farm of size greater than 1; and - an application session had more than one HTTP request; and - the session had crossed over to a Relay Sever different from the one where the session started and an I/O error or timeout occurred with the client connection. The problem was that the Outbound Enabler was misinforming the Relay Server for a change in upward packet destination, when a session was migrated from one Relay Server to another, on a clear request-response boundary. This has now been fixed so that the Relay Server is protected from being misinformed by Outbound Enablers older than 12.0.1.3574. ================(Build #3574 - Engineering Case #698082)================ An attempt by the Relay Server to notify the Outbound Enabler to disconnect the associated backend connection may have been mis-routed and discarded. This would have caused a delay in closing the backend connection, together with a SYS64 error, when the backend server eventually timed out the connection. The conditions for this problem were: - TCP load balancer without stickiness was used in front of a Relay Server farm of size greater than 1; and - an application session had more than one HTTP request; and - the session had crossed over to a Relay Sever different from the one where the session started and an I/O error or timeout occurred with the client connection. The problem was that the Outbound Enabler was misinforming the Relay Server for a change in upward packet destination, when a session was migrated from one Relay Server to another, on a clear request-response boundary. This has now been fixed so that the Outbound Enable is stopped from misinforming the Relay Server. ================(Build #3573 - Engineering Case #698076)================ The Relay Server Outbound Enabler could have reported a SYS64 error ("SYS64: The specified network name is no longer available...") with no ill effect to the client. This would have happened when a backend server timed out the connection, and would often have happened when the HTTP response had been completely received by the Outbound Enabler and the connection remained idle for an extended period of time. Receiving a SYS64 error in that case was false alarm. This has been fixed so that this error is now suppressed and verbosity 4 debug logging will now log this situation as "DoneReceive EOF SYS64..." instead of "DoneReceive EOF", which is for the normal disconnect situation. For the cases where the SYS64 happen prematurely before the entire HTTP response has been received by the Outbound Enabler, the Relay Server will detect the problem and report and error. ================(Build #3570 - Engineering Case #697611)================ The Relay Server Outbound Enabler (RSOE) did not log command line arguments on startup and before detecting the availability of a backend server. The command line arguments were only printed after detecting that a backend server was up and while connecting to the Relay Server. This has now been fixed so that command line arguments are printed immediately on startup so that RSOE configurations are visible as early as possible. ================(Build #3568 - Engineering Case #697450)================ The Relay Server Outbound Enabler may have crashed in a Relay Server farm environment. This has been fixed. ================(Build #3566 - Engineering Case #697289)================ When the Relay Server extension name in the URL was specified with some uppercase characters, the Relay Server extension may have crashed. The Relay Server would have recovered, but active requests involved in the crashing process would have failed. This has been fixed so that uppercase character are now acceptable. Note: The farm name and server id in the URL remain case sensitive. ================(Build #3536 - Engineering Case #694605)================ SUP's Sybase Control Center (SCC) may have reported a false positive Relay Server Outbound Enabler (RSOE) status when the up channel or down channel failed to make direct connection to individual Relay Servers in the farm for a sustained period of time when RSOE debug logging is turned on. This was due to RSOE suppressing reporting repeated errors while SCC was scanning only the tail of the RSOE log to determine status. The RSOE has now been changed to not suppress repeated errors for this issue. ================(Build #3520 - Engineering Case #692342)================ Attempting to start the Relay Server Outbound Enabler with the command line option "-cs status_url" would have failed. This has been fixed and a usage text for -cs status_url, which was missing, has been added." ================(Build #3519 - Engineering Case #692346)================ The Relay Server Outbound Enabler would have crashed after showing the usage text due to an invalid parameter. This has been fixed. ================(Build #3517 - Engineering Case #691976)================ Aggregated download throughput, using one or more Outbound Enablers, has been improved significantly across all kinds of loads when there is bandwidth left in the link to the Relay Server. Running multiple OEs still remains an option to further improve throughput over a single OE. In our test environment, it now takes about 12 OEs in order to become network bound. Previously, even with 64 OEs with network bounding client load (i.e. RS/OE slows down the traffic to the point that it is no longer network bound) it was not possible to max-out the link. When the load is not sufficient to cause a network bounding situation, the Relay Server can now achieve close to 90% of the direct throughput where the clients are directly accessing the backend server. ================(Build #3513 - Engineering Case #691739)================ The detailed Relay Server status page, via the rs_admin.dll and rs_monitor.dll, were showing a heading and an empty list of fully available farms when there were no fully available farms. This has now been changed to not show the heading when the list is empty. The issue with partially available farms and unavailable farms has also been fixed. ================(Build #3508 - Engineering Case #691106)================ The Relay Server Outbound Enabler's down channel would have responded slowly to new requests when there were on-going heavy downloads. This has been fixed by internal tuning of the Outbound Enabler's down channel. In testing, two concurrent 1G reponses were making the Outbound Enabler take 18 sec to satisfy another pair of clients waiting for 10x10k responses. After tuning, it took only 0.5 sec to satisfy the lighter responses without jeopardizing the aggregated download throughput. ================(Build #3491 - Engineering Case #689174)================ The Relay Server was sensitive to the networking environment and how quickly the web server detected read errors (RSE3004) caused by network problems on the down channel between the Outbound Enabler and the Relay Server. If there was enough delay so that the Outbound Enabler had already recovered the channels before the detection occur, the Relay Server would have failed subsequent client requests targeting this back-end server and reported the following warning: W. 2011-10-28 21:23:36. <5608.2420.F5fcB0S456bR0> Server response NOT completed. Remaining 0 of 0 bytes. Restarting the Outbound Enabler would have resolved the issue. This has now been fixed so that client requests will not be affected by the delay and restarting Outbound Enabler is no longer required. ================(Build #3487 - Engineering Case #688573)================ An interactive quick setup feature has been added to help users with deploying Relay Server components to Microsoft IIS 7.0 or 7.5 on Windows Server 2008/Windows Server 2008 R2. This is being provided as an alternative to the manual procedure documented in the Relay Server Guide. Setup is automated but also interactive. It installs IIS7, turns on required IIS7 features, configures IIS7 for Relay Server, creates a demo application and a Quick Reference Guide to assist in subsequent Relay Server server maintenance. The Quick Reference is launched automatically as part of the setup. Setup is comprised of the following major steps: 1. Introduction 2. Customization 3. Install IIS7 and Required Features 4. Create a Backup 5. Deploy and Start the Relay Service 6. Generate and Launch the Quick Reference 7. Launch the Relay Server Status Page 8. Launch the SimpleTestApp Client 9. Shut down To deploy the Relay Server components to Microsoft IIS 7.0 or 7.5 on Windows Server 2008/Windows Server 2008 R2, run rs-setup.bat from the SQLANY12%/RelayServer/IIS/quicksetup_iis7 directory. ================(Build #3479 - Engineering Case #687776)================ The changes for Engineering case 686057 made have caused the server to crash when using URL query parameters. This has been fixed. ================(Build #3479 - Engineering Case #687571)================ If Relay Server State Manager failed to initialize on startup during creating the shared memory step, it did not output a detailed message with the system error code and message. This has been corrected. ================(Build #3476 - Engineering Case #687277)================ The Relay Server Outbound Enabler (RSOE) didn't complain about typos in the -cs and -cr command line options. For example, if trusted_certificates was entered as trusted_certificate, RSOE would not stopped with an error right at start-up. Also, when HTTPS related parameters were specified and HTTPS=1 was not set, RSOE would also silently attempt to make an HTTP connection. These problem have been fixed so that RSOE will detect these problem, report an error, and abort. ================(Build #3476 - Engineering Case #687273)================ The HTTPS parameter was not mentioned in the usage text description of the Relay Server Outbound Enabler's -cs option, nor do any cert parameters mention that it is required. This is also the case for the usage for the -cr option, where HTTPS was not mentioned anywhere. Descriptions have now been added to the usage text for these options, as well as a mention that HTTPS=1 is required for any of the cert parameters. Also the -cs https=1 default port was set to 80, this has now been changed to 443 instead. ================(Build #3474 - Engineering Case #679356)================ When the Relay Server state manager was started with the -os command line option, and the Relay Server extension was published using a user account without write permission of the folder that contained the log file, then auto truncation of the log when the size limit was reached may have failed on IIS7.x with a RSF11013 error where the underlying reason was system error 5 (Access is denied). This issue has been fixed. ================(Build #3471 - Engineering Case #686524)================ The SQL Anywhere Monitor was incorrectly reporting the total disk space as the current Relay Server log's file size. This has been fixed. ================(Build #3471 - Engineering Case #686501)================ Debug logging level 3 or higher would have produced logging of OE_UPCHANNEL_CONNECT packets with the oei field equal to "older than 12.0". This is misleading and the packet doesn't contain such a field. The misleading information has been removed. ================(Build #3470 - Engineering Case #686415)================ Relay Server shutdown may have taken unnecessarily long, or even crashed. This would have occurred if the shutdown was requested when a new client session was waiting for backend server assignment while all Outbound Enablers of the backend farm had been disconnected. This has been fixed. ================(Build #3468 - Engineering Case #686237)================ Relay Server web server extensions may have crashed if the URL contained redundant leading forward slashes. This has been fixed. ================(Build #3456 - Engineering Case #684808)================ When a back-end server aborted reading a request, for example due to some early detectable protocol error, the Outbound Enabler may have caused further protocol errors later on for other requests. This has been fixed. ================(Build #3456 - Engineering Case #684721)================ The rs_client.dll may have crashed when parsing a malformed response header. This has been fixed so that the Relay Server will response with an http 400 instead of crashing. ================(Build #3436 - Engineering Case #683240)================ A forced termination of the web server worker process, may have caused the Relay Server Outbound Enabler (RSOE)connection to become unrecoverable until the rshost process was restarted. The RSOE will receive authentication error continuously upon every recovery attempt, and the Relay Server log will continuously report RSE3003 accordingly. The forced termination could have been caused by killing the w3wp processes, crashes, worker process recycling or IIS configuration update timeout waiting for outstanding requests to complete. This problem has now been corrected so that the recovery should succeed two minutes after the forced termination, without requiring the rshost process to be restarted. The workaround is to restart the rshost process. This has been fixed ================(Build #3427 - Engineering Case #682648)================ When using the local Relay Server reconfiguration utility on Linux Apache to change the Relay Server configuration, or to archive the Relay Server log, the utility would not exit once complete. This has been fixed. ================(Build #3427 - Engineering Case #682621)================ Remote Relay Server administration operations can be initiated from Sybase Central's Relay Server plugin, or via the Relay Server administration API. Remote administration operations, such as Relay Server reconfiguration or log archiving, could have caused the Linux Apache Relay Server to crash. This has been fixed. ================(Build #3427 - Engineering Case #682561)================ The fix for Engineering case 660995 had caused an issue where client requests that were not assigned to a backend server may have caused the IIS worker to crash in rs_client.dll. The client request may not have been assigned for various reasons. For example, when the Relay Server Outbound Enabler of the backend server was not connected, or the farm was disabled. If that happened and there were also I/O error while reading the request for discarding, a crash could have occurred when the Relay Server tried to report the I/O error. The crash has been fixed. ================(Build #3421 - Engineering Case #681791)================ On Windows systems, a standalone Relay Server Outbound Enabler (RSOE) may have mistakenly identified a backend server as down or not accepting requests during the backend ping cycle on startup. This error could have happened if the Winsock DLL startup failed. This has now been fixed. Instead, the RSOE will print the error message "Backend ping socket startup failed", and backend ping attempts will stop. ================(Build #3421 - Engineering Case #681789)================ Version information was missing from rstool.jar, so an ianywhere.ml.rs.BuildNum class with a static main method that prints the version with build number to System.out, has been added. ================(Build #3420 - Engineering Case #681621)================ In a Relay Server farm environment, likely with non-sticky loadbalancer, it was possible for the Outbound Enabler to leak memory in the rare case of failing to locate the proper channel where the client request originally came from. This has now been fixed. ================(Build #3417 - Engineering Case #681059)================ The usage text for the Relay Server Outbound Enabler was incorrectly listing 'identity_name' as a value for the -cr option. The value 'identity_name' has now been removed . ================(Build #3416 - Engineering Case #680920)================ The ISS Application Pool Process (w3wp.exe) may have crashed some time later after handling a request with a URL ending with the Relay Server extension. ================(Build #3391 - Engineering Case #676505)================ Under rare, timing dependent conditions, the Relay Server may have reported a fatal error "RSF11016: Freeing already freed memory block in shared memory". The Relay Server's shared memory manager would have protected itself from this illegal operation and continued to operate normally. This error may have occurred right after RSE2000, RSE3008 or Relay Server shutdown. This has been fixed by eliminating the redundant freeing. ================(Build #3384 - Engineering Case #675317)================ Under extreme load conditions, the Relay Server may log errors on shared memory operations. This logging operation may have crashed the web server worker process. Also, for 12.x Relay Servers, the line label for such logging has the format of <pricessId.threadId.ShmDebug>. The threadId could have been wrong. Both of these problem have now been fixed. ================(Build #3376 - Engineering Case #674187)================ A web server worker thread may have crashed when it failed to load the localized language resource (e.g dblge12.dll). The reasons for the failure may have included the file not being found due to path and registry info, or the account associated with the worker did not have permission to read the resource. The symptom was a truncated log line with a missing end-of-line. This has been fixed so that the crash will no longer occur and an unlocalized error message is displayed regarding the loading error. ================(Build #3376 - Engineering Case #674120)================ A web server worker may have crashed when logging lengthy debug messages that had not been localized. This has been fixed. ================(Build #3364 - Engineering Case #672213)================ The Relay Server may have become unrecoverable due to continuous errors from the shared memory manager when one of the backend servers had been serving more that four types of clients. This has been fixed so that a hard limit of 1600 client types is in effect. When the new limit is reached, a graceful error will be reported without affecting the rest of the requests. ================(Build #3345 - Engineering Case #668791)================ When the Relay Server Outbound Enabler failed a backend connection test, it may have crashed, or have been unable to recover even after the backend became available again. This has been fixed. ================(Build #3332 - Engineering Case #666845)================ The Relay Server admin and monitor extensions may have slowly leaked memory. Eventually, admin or monitoring requests would have failed without any trace in the HTTP error log, IIS access log, or in the Relay Server log. This problem has been fixed so that recycling is no longer necessary. To workaround this problem, users may setup application pool recycling for the admin and monitoring extension. ================(Build #3327 - Engineering Case #664284)================ The Relay Server Outbound Enabler would have stopped discovering Relay Servers after the last Relay Server was disabled from a server farm. The Outbound Enabler would have become unusable until restarted. This is fixed so that the Outbound Enabler will now attempt to discover new Relay Servers at the rate specified by the existing Outbound Enabler -d switch. ================(Build #3323 - Engineering Case #663171)================ The Relay Server may not have responded to HTTP GET requests for non-relay purposes. For example, using a browser to visit the rs_admin extension would have resulted in a connection drop without a response. A load-balancer trying to test the Relay Server service via the rs_server extension, would also have resulted in a connection drop without a response regardless of the status of the relay service. This has been fixed so that a useful response is now provided when HTTP GET requests are issued against various Relay Server extensions. ================(Build #3315 - Engineering Case #661112)================ It was possible for synchronizations to fail if any of the 'certificate_name', 'certificate_company', or 'certificate_unit' parameters were supplied, even though the value of these parameters matched the corresponding field values in the server's certificate, if they were encoded as Unicode in the server's certificate. This has been corrected. ================(Build #3314 - Engineering Case #664283)================ Relay Server enable/disable events were not broadcast to connected Outbound Enablers. For example, disabling the last Relay Server from a Relay Server farm was not going to suffer the issue described in Engineering case 664284, but when adding a Relay Server to the Relay Server farm, it would also not have woken up the Outbound Enablers to start utilizing the new Relay Server. The user workaround is to restart the Outbound Enabler. This problem has been fixed. ================(Build #3314 - Engineering Case #664139)================ When a Relay Server starts up, its description was logged and the startup verbosity was applied properly, but those values were not stored correctly for later consumption. Such as for the admin tool to export the configuration or for the next configuration update to properly determine if an updated was required. This problem has been fixed. ================(Build #3311 - Engineering Case #663936)================ On Unix systems, the second field in the Relay Server's log, which is the thread ID, may shown a negative number. The type used to store the thread ID value was not big enough on Unix systems, as thread IDs tend to be large, and could have overflowed. This has now been fixed. ================(Build #3308 - Engineering Case #663261)================ The Relay Server Outbound Enabler on MacOS may have failed to receive all download data from the backend server. If Relay Server for Apache was used, then it would have appended a 500 HTTP error page to the data, which most likely would have caused client failure. This has now been fixed. ================(Build #3306 - Engineering Case #663061)================ Proxy support for the Relay Server Outbound Enabler may only have worked with HTTPS against some HTTP 1.1 proxy servers. The down channel using HTTP instead of HTTPS would have connected successfully at first but then would have been dropped by the proxy after a period of being idle. This problem is proxy specific and it does not affect all HTTP proxy environments. This problem has been fixed in the Relay Server so that an update to the Outbound Enabler is not required (see Engineering case 662749). The workaround is to use HTTPS, or apply the Outbound Enabler fix from case 662749. ================(Build #3305 - Engineering Case #662749)================ Proxy support for the Relay Server Outbound Enabler may only have worked with HTTPS against some HTTP 1.1 proxy servers. The down channel using HTTP instead of HTTPS would have connected successfully at first but then would have been dropped by the proxy after a period of being idle. This problem is proxy specific and is does not affect all HTTP proxy environments. This problem has been fixed in the Outbound Enabler so that HTTP will now also work. The workaround is to use HTTPS. ================(Build #3300 - Engineering Case #661849)================ When using the Service utility (dbsvc) to start a Relay Server service with a large configuration on a slow machine, it may have reported startup errors while the service was still in the pending start state. A fix was made to the Relay Server to correct this problem. ================(Build #3298 - Engineering Case #660995)================ When connected to a Relay Server, and no Outbound Enabler providing the backend service had connected yet, the connection was expected to timeout within the application timeout time specified by the client. However on IIS7, some J2SE http clients may have become stuck writing to a server that was no longer reading and eventually failed the write and then perform a delayed internal retry without processing the response sent by the web server. This change modifies the Relay Server to provide the expected fail fast experience according to the timeout against such J2SE clients. ================(Build #3291 - Engineering Case #658710)================ When the Relay Server was being reconfigured, a crash may have occurred in the rs_client.dll, and all http requests served by the same worker process would have failed. The web server would then have replenished the worker pool and the Relay Server would have continued to operate with the new configuration. The issue is highly timing sensitive and is very difficult to reproduce. This crash has now been fixed. ================(Build #3284 - Engineering Case #655574)================ The integrated Outbound Enabler library was not being unloaded correctly when the Mobilink server shutdown. The library eventually unloaded when the MobiLink server executable exited and no bad side effects where observed as a result, but this condition is now fixed. ================(Build #3283 - Engineering Case #656716)================ The Relay Server could have leaked heap memory under the following conditions: - On the response to the first HTTP request in the session, or specifically, anytime a cookie was set, if the response was long and came in small packets. - A small number of bytes were leaked on Upchannel and Dnchannel creation. This has been fixed. ================(Build #3282 - Engineering Case #657026)================ The MobiLInk server would immediately refuse to startup, if it could not make any connections to the consolidated database, even when it was running as a Windows service. This behaviour has changed so that the MobiLink server will retry to make connections, when it is running as a Windows services. The retries are once a minutes for ten minutes. If it still cannot make a connection after that, it will refuse to startup. ================(Build #3267 - Engineering Case #652382)================ The Relay Server did not work with a Relay Server Outbound Enabler (RSOE) that was behind an HTTP 1.0 proxy. The Relay Server has now been fixed to adapt to HTTP version downgrades done by an HTTP 1.0 proxy, and is needed when working with a 12.0.1 RSOE in conjunction with a HTTP 1.0 proxy.

MobiLink - RelayServer plug-in for Sybase Central

================(Build #3278 - Engineering Case #655989)================ Sybase Central would have crashed whenu attempting to open a Relay Server configuration file which was zero-length, or that contained only whitespace. This has been fixed. ================(Build #3273 - Engineering Case #654244)================ On some Chinese Windows systems, the fields for entering the MAC address for back end servers was too narrow to see both digits of each byte of the address. This has been fixed.

MobiLink - SA Client

================(Build #3664 - Engineering Case #706541)================ In a mirroring system, if the mirror or a copy node was stopped around the time the primary performed a transaction log operation that required more than one page, the next time the mirror or copy node was started it could have asserted or crashed. The most likely assertion failure error numbers were 100902, 100903 or 100904. This has been fixed. ================(Build #3353 - Engineering Case #670360)================ The SQL Anywhere synchronization/replication components, including the MobiLink client (dbmlsync) and SQL Remote (dbremote), could have given the error 'No off-line transaction log file found and on-line transaction log starts at offset XXXXX'. This would have occurred: 1) if no transaction-logs-directory was given on its command line; and 2) if the length of the transaction log name including its absolute path was greater than 128 bytes. This problem is now fixed and the length of the transaction log name plus its absolute path has been extended to 1024 bytes. ================(Build #3341 - Engineering Case #668425)================ The MobiLink client now prints information about the operating system and machine architecture on which it is running to the log. It also prints the platform for which the executable was compiled. This is similar to what the MobiLink server and the database server already do. ================(Build #3303 - Engineering Case #662639)================ When a SQL Anywhere database is used as a remote database, the MobiLink client (dbmlsync) generates a remote ID which is a GUID for the database during the first synchronization. This remote ID is used by the Mobilink server to identify the remote. MobiLink keeps a list of synchronizing remotes in the ml_database table. When a blank padded SA database was used as a remote, a remote ID would have been generated during the first synchronization, sent to the MobiLink server and stored in the ml_database table. On all subsequent synchronizations, a blank padded version of the remote id would then have been sent. The results of this were: 1) The server would not have been recognized on the second sync that the same remote was synchronizing and would treat the second sync as a first sync. That is to say the server would not have used state information it had from the first sync when processing the second. Third and subsequent sync's were not affected. This would have had no impact unless the first synchronization had failed. 2) Two entries would have been made in the ml_database table for each remote. One would contain the blank padded remote id and the other would contain the unpadded id. This behaviour has now been fixed. Now, on first synchronization the remote_id assigned to the remote database will be blank padded. ================(Build #3298 - Engineering Case #650856)================ Synchronizations using HTTP-based communication protocols (including HTTP, HTTPS and other encrypted HTTP protocols) could have failed intermittently. When synchronizations failed, they would do so after the download had been applied and committed, and would have reported an error message like: "Data read failed. Requested 2 bytes but got 0 bytes." When this occurred the MobiLink server would have reported the error: "Connection was dropped due to lack of network activity". These failures were only likely to occur when applying the download to the remote database took longer than the stream timeout interval, which is 4 minutes by default. This problem has now been resolved ================(Build #3278 - Engineering Case #655955)================ Several memory leaks have been fixed in the MobiLink Client. ================(Build #3278 - Engineering Case #655953)================ Several memory leaks have been fixed in the MobiLink client. These leaks would primarily affect applications using the dbmlsync API. ================(Build #3272 - Engineering Case #653930)================ The Console utility could have stopped refreshing database and/or server properties after changing the set of properties which were displayed, even after it was restarted. The problem was sensitive to the speed with which properties were selected or unselected. This has been fixed. ================(Build #3263 - Engineering Case #651692)================ When a plug-in failed to load on startup, other plug-ins may then not work correctly. This has been fixed.

MobiLink - Streams

================(Build #3729 - Engineering Case #707541)================ Unnecessary HTTP headers were being sent in HTTP CONNECT requests. This has been fixed. ================(Build #3522 - Engineering Case #692598)================ An HTTPS synchronization could have failed on 64-bit Windows with STREAM_ERROR_SECURE_HANDSHAKE, depending on what trusted certificates were provided. This failure would have been more likely to occur when using the OS's CA certificate store. Certicom has provided updated libraries which correct this problem. ================(Build #3512 - Engineering Case #691654)================ MobiLink clients that output localized error messages, now output a more detailed error message for connection failures on Windows desktop and devices, in addition to doing so for network read and write errors as they did before. ================(Build #3444 - Engineering Case #683721)================ When the password provided by the identity_password option for an encrypted private key for a client side certificate was incorrect, the error STREAM_ERROR_INTERNAL was reported. Now the correct error STREAM_ERROR_BAD_PRIVATE_KEY_PASSWORD is reported. ================(Build #3419 - Engineering Case #681404)================ A MobiLink client doing an HTTPS synchronization could have crashed if the connection was lost. This has been fixed. ================(Build #3417 - Engineering Case #681078)================ TLS and HTTPS synchronization would have failed when the client attempted to use a client-side identity with an unencrypted private key. The error reported would have been: "Unable to read the private key". This has now been fixed. ================(Build #3326 - Engineering Case #665837)================ The changes for Engineering case 661112 introduced a bug where the MobiLink client could have crashed, or the check of the certificate_name, certificate_company, or certificate_unit could have failed, if any of the certificate fields were encoded as Unicode in the server's certificate. This has been fixed. ================(Build #3275 - Engineering Case #650719)================ After a failed download, an attempt to restart the download may have failed and reported a "Protocol Error" or a read failure. This has been fixed.

MobiLink - Synchronization Server

================(Build #3757 - Engineering Case #706878)================ The MobiLink server could have crashed when a TIMESTAMP column was fetched from Oracle using the .NET-ODBC bridge. This has been fixed. ================(Build #3752 - Engineering Case #706183)================ If a DBRowReader from the MobiLink Server .NET API was used to gather binary data from a fixed length binary column in the consolidated database, then the binary data that was fetched would have had zeroes appended to the result up to the maximum size of the fixed length column. This has been corrected so that zeroes are no longer added to the result. ================(Build #3742 - Engineering Case #710432)================ The MobiLink server could have crashed if a failed download using HTTP was restarted. This has been fixed. ================(Build #3728 - Engineering Case #707061)================ The MobiLink server could have crashed if it had an HTTPS listening port. This has been fixed. ================(Build #3728 - Engineering Case #707039)================ Synchronizations could have hung when using HTTP if an error occurred on the server side. This has been fixed. ================(Build #3725 - Engineering Case #705697)================ Set-Cookie HTTP headers, and sync parameters that set a cookie value to the empty string, will now cause the cookie to be removed, preventing it from being sent to the server in subsequent HTTP requests. Previously, the client would report an error in this case. ================(Build #3718 - Engineering Case #704464)================ HTTP headers returned by the NetworkData Java and .NET classes were silently truncated. This has been fixed. Also, a bound has been placed on the total amount of header data that can be sent in an HTTP request. If a request exceeds the bound, the server will return an HTTP error code and abort the request. This bound is controllable with the header_limit HTTP option. For example, "-x http(header_limit=200000)" will raise the limit to 200000 bytes. The default value is 64000 bytes. ================(Build #3673 - Engineering Case #698075)================ The MobiLink server could have crashed while shutting down when it was using an integrated Outbound Enabler. This has been fixed. ================(Build #3602 - Engineering Case #701348)================ Exceptions were not thrown when strings containing invalid timestamps were assigned to TIMESTAMP WITH TIME ZONE columns in the MobiLink Java and .NET direct row APIs. This has been fixed. ================(Build #3602 - Engineering Case #701343)================ Unnecessary cast exceptions could have occurred when using the MobiLink .NET direct row API with SMALLINT and TINYINT columns. This has been fixed. ================(Build #3602 - Engineering Case #701342)================ The following remote types were not supported by the MobiLink Java and .NET direct row APIs: NCHAR NVARCHAR LONG NVARCHAR VARBIT LONG VARBIT XML This has been fixed. ================(Build #3599 - Engineering Case #701349)================ It was possible to call PreparedStatement.setTime for columns that were not times or dates in the MobiLink direct row API. This has been corrected. ================(Build #3599 - Engineering Case #701347)================ The varchar(max) and varbinary(max) types in Microsoft SQL Server did not work when using the MobiLink .NET-ODBC bridge. This has been fixed. ================(Build #3599 - Engineering Case #701344)================ A security issue with the MobiLink direct row API has been corrected. ================(Build #3553 - Engineering Case #695119)================ The MobiLink server would not have accepted any status-check requests sent by clients who had lost the last synchronization status. When a status-check request was received, the MobiLink server would have repoprted the error: [Sybase][ODBC Driver][SQL Anywhere]Authentication violation (ODBC State = 08001, Native error code = -98) and then failed the request when all the following conditions were met: 1) The consolidated database was running on an OEM version of a SQL Anywhere server; 2) The consolidated database had been restarted since the MobiLink server was started; and 3) A client required a status-check because it did not get a full response in the last sync request that contained an upload. These problem is fixed now. The immediate work around for this problem is to restart the MobiLink server. ================(Build #3543 - Engineering Case #695370)================ The MobiLink server could have crashed when using the DBRowReader or DBCommand interfaces in the MobiLink .NET-ODBC bridge, if varchar or binary columns longer than a few KB were used. This has been fixed. ================(Build #3513 - Engineering Case #691327)================ If the Notifier had encountered an unexpected error (such as a deadlock) when executing one of the Notifier events, subsequent attempts to execute the same Notifier Event would have resulted in an "Invalid Cursor State" error. This has been corrected so that the Notifier no longer reports the "Invalid Cursor State" error on subsequent attempts. Stopping and starting the MobiLink Server would also have resolved the issue. ================(Build #3500 - Engineering Case #689194)================ When synchronizing with a SQL Anywhere remote using the MobiLink client running on a non-English operating system, it was possible for the following message to be generated by the MobiLink server: Gtk-CRITICAL **:gtk_text_buffer_emit_insert:assertion 'g_utf8_validate (text, len, NULL)' faild This problem has been fixed. As a consequence, the message output in the MobiLink server log when a synchronization request is received from a SA remote will change from: Request from "Dbmlsync Version 16.0.0.3940" for: remote ID: ... to: Request from "Dbmlsync 16.0.0.3940" for: remote ID: ... ================(Build #3496 - Engineering Case #689792)================ Requests to 12.0 MobiLink servers from MobiLink clients without the changes made for Engineering case 471582, where the MobiLink client included version and build number in each synchronization, could have ended with an "Unknown request completed" in the MobiLink server log. Also, error "[-10344] The remote database identified by remote ID '89d85096-0006-11e1-8000-8a42a227c45d' is already synchronizing: orphaned UltraLite synchronization" could have been reported for requests from MobiLink clients without this change as well. These issues have been fixed. ================(Build #3450 - Engineering Case #547730)================ If a corrupted UltraLite or SQL Anywhere remote client synchronized with a MobiLink server, it was possible for protocol errors to be generated. When this occurred, the MobiLink server console log would have shown the text: I. <1> failed reading command with id:%d and handle:%d I. <1> Synchronization complete This has been fixed. Now, the error message "[-10001] Protocol Error: 400" will be displayed and a synchronization error will be reported. ================(Build #3448 - Engineering Case #683720)================ If a schema change was done using the START/STOP SYNCHRONIZATION SCHEMA CHANGE functionality, and authentication parameters were passed during synchronization, it was possible that the authentication parameters would not have been sent for the first synchronization after the schema change commands had been processed. This would likely have resulted in a failed synchronization. The next synchronization though would have been successful, and no data loss would have occurred. This problem has now been fixed, and authentication parameters are no longer missed. ================(Build #3446 - Engineering Case #683830)================ There were two problems in the MobiLink server remote ID locking logic that have now been corrected: 1) When the consolidated database was running on a MySQL server, the MobiLink server could have immediately failed a status-check request when the server was not able to lock the remote ID; 2) When the consolidated database was running on a SQL Anywhere server, if the remote ID could not be locked in the upload transaction, the server would have shown the following warning message: "Retrying the upload after deadlock in the consolidated database" and then retried the upload transaction one more time. ================(Build #3423 - Engineering Case #678983)================ The MobiLink server could have crashed when synchronizing using HTTP. This has been fixed. ================(Build #3420 - Engineering Case #681620)================ If the MobiLink server was started with an identity file containing an unencrypted private key, it would have fail to start with error "Unable to read the private key.". This has been corrected. ================(Build #3376 - Engineering Case #674250)================ When the MobiLink Server ran against a consolidated database running on Microsoft SQL Server, the MobiLink server could have reported the following error message: [-10002] Consolidated database server or ODBC error: ODBC: [Microsoft][SQL Server Native Client 10.0][SQL Server] Cannot drop the table '#elbat_yraropmet_ymmud_a_si_siht', because it does not exist or you do not have permission. (ODBC State = 42S02, Native error code = 3701) This error would have occurred in one of the following situations: 1) a deadlock was detected during upload; 2) an error occurred in a trigger that was defined on an upload table; or 3) the 'XAXT_ABORT' option was set to 'ON' in one of the user-defined scripts. This problem is fixed now. ================(Build #3354 - Engineering Case #669465)================ The MobiLink server could have crashed when handling restartable downloads and the restartable download cache was too small to hold all possible restartable downloads at one time. This has been fixed. ================(Build #3301 - Engineering Case #662072)================ When deploying a Synchronization Model with conflict resolution to a SQL Anywhere or Sybase IQ database, the SQL generated to create a global temporary table checked twice for an existing table. Although this did not cause any errors, the generated SQL has been fixed so that it now only checks once for an existing table before creating a global temporary table. ================(Build #3289 - Engineering Case #658453)================ When using MobiLink synchronization and timestamp-based downloads with an Oracle Real Application Cluster (RAC) system, there is a chance of missing rows to be downloaded if the clocks of the Oracle cluster nodes differ by more than the time elapsed between the MobiLink server fetching the next last download timestamp and fetching the rows to be downloaded. This problem is unlikely on a RAC system with synchronized node clocks, but the likelihood increases with larger node clock differences. A workaround is to create either a modify_next_last_download_timestamp or modify_last_download_timestamp script to subtract the maximum node clock difference. Note that at least since version 10i, Oracle has recommended using Network Time Protocol (NTP) to synchronize the clocks on all nodes in a cluster, and NTP typically runs by default on Unix and Linux. With cluster nodes properly configured to use NTP, their clocks should all be within 200 microseconds to 10 milliseconds (depending on the proximity of the NTP server). Since Windows Server 2003, the Windows Time Service implements the NTP version 3 protocol and it runs by default. Also, as of version 11gR2, Oracle Clusterware includes the Oracle Cluster Time Synchronization Service (CTSS) to either monitor clock synchronization or, if neither NTP or Windows Time Service is running, it will actively maintain clock synchronization. However CTSS and Windows Time Service are less accurate than NTP, To avoid missing rows when Oracle RAC node clocks differ by up to one second more than the time between fetching the next_last_download_timestamp and the rows to be downloaded, now the MobiLink server will subtract one second from the next_last_download_timestamp fetched from the consolidated database, if 1) the Oracle account used by the MobiLink server has execute permission for SYS.DBMS_UTILITY, 2) the consolidated database is an Oracle RAC system, and (only for MobiLink version 12.0.0 and up) 3) there is no generate_next_last_download_timestamp script. For Oracle RAC node clocks that may differ by greater amounts, you can avoid the problem by defining a generate_next_last_download_timestamp, modify_next_last_download_timestamp or modify_last_download_timestamp script to compensate for the maximum node clock difference. ================(Build #3286 - Engineering Case #657869)================ If the MobiLink Server's memory use grew more than 4GB in less than 5 minutes, the TRACKED_MEMORY ppv value would have been incorrect. As a consequence, for all 12.0.1 platforms and non-Windows 12.0.0 platforms, the MobiLink server cache could have erroneously shrunk and not recovered. This has been fixed. A work around is to use a larger -cinit option value, and if the problem persists to disable dynamic cache resizing by specifying the same value for -cmax and -cmin. Also, on 12.0.0 for Windows, the cache could have failed to stabilise. This has also been fixed. ================(Build #3277 - Engineering Case #655780)================ The method MLResultSet.getBigDecimal(L/java/lang/String;) unnecessarily threw a 'method not supported' exception. This has been fixed. ================(Build #3273 - Engineering Case #653183)================ The NUM_CONNECTED_SYNCS ppv metric and the "Synchronizations", "Started Synchronization Rate", "Synchronizations Started", and "Unknown Connected Clients" metrics incorrectly considered syncs that had failed during the download and were waiting to be restarted as being connected and so would show an incorrect value in the log or in the SA Monitor. Also, as a consequence, the server would prompt for confirmation to kill active syncs during hard shutdown even if all the syncs in the system are waiting to be restarted. This has been fixed. ================(Build #3265 - Engineering Case #652263)================ The usage text for the Relay Server Outbound Enabler didn't describe what were the valid options for the -cr option. This has been corrected so that the values are now listed for the tcp options, server certificate options, and client certificate options. In addition, http authentication options, proxy options, and proxy authentication options, have been added in version 12.0.1. ================(Build #3153 - Engineering Case #660428)================ The MobiLink server could have crashed during shutdown if user spawned Java threads printed to System.out or System.err after the ShutdownListeners were notified of shutdown. This has been made much less likely to happen. A work around is to ensure all user threads are stopped before the ShutdownListeners return.

MobiLink - Utilities

================(Build #3605 - Engineering Case #701661)================ Using the Certificate Creation utility with the -c option ("Read the signer's certificate from the specified file") could have caused it to crash. This has been fixed. A workaround is to use the interactive prompt instead. ================(Build #3593 - Engineering Case #700315)================ The MobiLink Replay utility could have crashed if the GetNumRecordedInserts, GetNumRecordedUpdates, or GetNumRecordedDeletes callbacks were called from the replay DLL with values not explicitly given by MLReplay when calling the GetUploadTransaction callback. This has been fixed. ================(Build #3590 - Engineering Case #700132)================ The Certificate Creation utility (createcert) would have fail to create a certificate with the error "Error occurred encoding object" when run on a leap day, and the expiry for the certificate was not a leap year. This has corrected. ================(Build #3571 - Engineering Case #697637)================ The MobiLink Replay utility (mlreplay) could have crashed when using the replay API to customize uploads of tables that had no nullable, signed number, or bit columns. This has been fixed. ================(Build #3566 - Engineering Case #697189)================ The MobiLink replay utility (mlreplay) can unpack blobs incorrectly (i.e. using the wrong type) when determining the number of inserts, updates, and deletes in the recorded protocol file. This has been fixed. ================(Build #3528 - Engineering Case #693325)================ The MobiLink replay utility (mlreplay) could have crashed when the version of the recorded protocol was incompatible with the version of the replay utility replaying it. This has now been fixed. ================(Build #3451 - Engineering Case #684361)================ The MobiLink Replay utility (mlreplay) could have read and sent row data in the wrong order. This could have caused a crash in mlreplay, and caused the MobiLink server to read incorrect/invalid row data resulting in a -10308 error. This has been fixed. ================(Build #3421 - Engineering Case #681788)================ Version information was missing from mlnotif.jar, so an ianywhere.ml.notifier.BuildNum class with a static main method that prints the version with build number to System.out, has been added. ================(Build #3344 - Engineering Case #668612)================ The MobiLink Replay utility (mlreplay) could have crashed when synchronizing unsigned big integers using the Replay API. This has been fixed. ================(Build #3315 - Engineering Case #664140)================ Sometime the MobiLink Listener (dblsn) could have taken a few minutes to shutdown if the shutdown was initiated by the QAnywhere Agent (qaagent). This problem has been fixed. ================(Build #3311 - Engineering Case #663629)================ When replaying a recorded protocol file more than once with the same client without using the –ap option, all replay sessions after the first would have failed due to a progress mismatch warning received from the MobiLink server (this is expected). However, the error message that appears in the MLReplay log in this situation does not make it clear that the problem will disappear if the –ap option is used. So, the MobiLink Replay utility has been changed so that when it receives an unexpected progress mismatch from the MobiLink server, an error message saying so is logged, which points the user to use the –ap option.

MobiLink - iAS Branded ODBC Drivers

================(Build #3764 - Engineering Case #707781)================ The iAS ODBC driver for Oracle could have crashed in the OCI library when a query contained results from a proxy server if the size of the result set was greater than the "Array size" given by the DSN. This problem has now been fixed. ================(Build #3292 - Engineering Case #657721)================ There was a memory leak in the iAS ODBC driver for Oracle. The memory leak would have occurred when an application tried to make a connection but the ODBC driver was not able to obtain a valid database connection. This problem has now been fixed.

MobiLink - scripts

================(Build #3759 - Engineering Case #712456)================ When using the DBRowReader class, it was possible for all the values in a long column to be erroneously returned as NULL. This has been fixed. ================(Build #3284 - Engineering Case #657397)================ When the consolidated database was running on an Oracle server, the MobiLink server could have displayed the error: 'ORA-00001: unique constraint ... violated' and then refused further synchronization requests. This would have occurred when the MobiLink server schema in the consolidated database was upgraded from a version earlier than 11.0.0, and the synchronization request was for a new MobiLink user and/or MobiLink remote database. This problem has been fixed in the upgrade scripts for Oracle. The following steps can be used to correct the problem if the Oracle consolidated database had already been upgraded with the old upgrade scripts: 1) Shut down all MobiLink servers; 2) Execute the SQL file against the Oracle consolidated database with the following command line: sqlplus LoginID/Password@TNSServerName @%SQLANY12%\MobiLink\Upgrade\fix_ora.sql Replace the LoginID, Password, and TNSServerName in the above command line with your own login information.

SQL Anywhere - ADO.Net Managed Provider

================(Build #3746 - Engineering Case #711375)================ If the Remote Server name was longer than 64 characters, the system procedure sp_servercaps() would have returned a "right truncation of string data" error. Example: CREATE SERVER ABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJ CLASS 'SAODBC' USING 'SQL Anywhere 12 CustDB'; CALL sp_remote_tables('ABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJ'); CALL sp_remote_columns ('ABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJ', 'ULCustomer'); CALL sp_servercaps ('ABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJ'); The first two calls succeed. The sp_servercaps() call would have failed as the argument was limited to 64 characters, which is too short. This problem has been fixed. The sp_servercaps() now accepts up to 128 characters. ================(Build #3732 - Engineering Case #707922)================ UPDATE statements generated by the Entity Framework could have failed with a syntax error if the table being updated had a uniqueidentifier key column. This problem has been fixed. ================(Build #3731 - Engineering Case #707952)================ When using a version 10.0, 11.0 or 12.0 of ADO.NET provider with a version 9.0 server, the .NET string parameters are incorrect mapped to nvarchar. This problem has been fixed. ================(Build #3599 - Engineering Case #699241)================ Using the SQL Anywhere ADO .NET Data Provider, the continuous closing and reopening of a pooled connection was slower than it was under version 9.0.2. This problem has been corrected. SAConnection conn = new SAConnection( connectString ); conn.Open(); . . . conn.Close(); ================(Build #3597 - Engineering Case #700928)================ The Entity Framework migration tools could have thrown an exception if the schema name of an entity set was not specified. For example: public class BlogContext : DbContext { public DbSet<Blog> Blogs { get; set; } } [Table( "Blogs" )] // [Table( "Blogs", Schema = "GROUPO" )] public class Blog { public int BlogId { get; set; } public string Name { get; set; } public string Url { get; set; } public int Rating { get; set; } } This has now been fixed. ================(Build #3520 - Engineering Case #692504)================ Entity Famework queries could have returned incorrect result when using parameters. This has been fixed. ================(Build #3499 - Engineering Case #690295)================ An IIS web server application could have crashed after running for a few days. This has now been fixed. ================(Build #3495 - Engineering Case #689764)================ The assembly names of version 3.5 and 4.0 providers in the policy config file were not correct. This meant that version 3.5 and 4.0 policy files did not redirect old versions to a newer version. This has been corrected ================(Build #3466 - Engineering Case #687578)================ Applications using the .Net provider could have crashed after running for some time. In rare occasions, the provider could have attempted to drop a prepared statement twice. This has now been fixed. ================(Build #3447 - Engineering Case #683999)================ When calling the method SADataReader.GetSchemaTable, the SQL Anywhere provider creates two prepared statements which were not dropped immediately in some situations. Actually, the statements are dropped either when the SACommand objects (created in SADataReader.GetSchema Method as local variables) are garbage collected, or when creating a new command and the number of prepared statements has exceeded the 'max_statement_count' option. Still, the SADataReader.GetSchema method has now been modified to dispose of the commands within the SADataReader.GetSchema method. This will drop the prepared statements immediately. ================(Build #3427 - Engineering Case #682662)================ A small amount of memory was leaked when an application using the ADO.NET interface executed a distributed transaction. This has now been fixed. ================(Build #3424 - Engineering Case #681915)================ A client application could have failed with an AccessViolationException, instead of a normal communication error, when a connection was dropped. This problem has been fixed. ================(Build #3387 - Engineering Case #675805)================ It is possible, although rare, for the machine.config file to contain multiple registered SQL Anywhere ADO.NET providers. When unregistering, the SetupVSPackage.exe utility only removed one SQL Anywhere ADO.NET provider from the machine.config file. This problem has been fixed so that SetupVSPackage.exe now looks for all registered SQL Anywhere ADO.NET providers. ================(Build #3359 - Engineering Case #671397)================ The following Entity Framework datetime functions were not mapped to SQL Anywhere functions: AddDays, AddHours, AddMicroseconds, AddMilliseconds, AddMinutes, AddMonths, AddSeconds, AddYears, DiffHours, DiffMicroseconds, DiffMilliseconds, DiffMinutes, DiffMonths, DiffSeconds, DiffYears. For example: Entities db = new Entities(); var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays( x.OrderDate, DateTime.Now ) > 100 ); string trace = ( ( ObjectQuery ) query ).ToTraceString(); This problem has been corrected by adding new function handlers for mapping Entity Framework datetime functions to the SQL Anywhere functions 'DATEADD' and 'DATEDIFF'. ================(Build #3347 - Engineering Case #669227)================ On systems running Windows Vista or later, when using the Visual Studio Add Connection wizard the SQL Anywhere .NET provider listed USER DSNs only in the ODBC Data Sources drop-down list. The SYSTEM DSNs are omitted. This problem has been corrected. The SetupVSPackage tool must be run to install this fix. It should be noted that on 64-bit Windows, only the 64-bit SYSTEM DSNs are listed (after this correction). Any 32-bit SYSTEM DSNs are not displayed. In Visual Studio 2008's design environment (which is 32-bit on 64-bit platforms), the Test Connection button will attempt to establish a connection using the 32-bit equivalent of the 64-bit DSN. If the 32-bit DSN does not exist, the test will fail. ================(Build #3342 - Engineering Case #667672)================ The Entity Framework function 'DiffDays' was not mapped to the SQL Anywhere function 'Days'. For example: Entities db = new Entities(); var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays( x.OrderDate, DateTime.Now ) > 100 ); string trace = ( ( ObjectQuery ) query ).ToTraceString(); This problem has been fixed. ================(Build #3341 - Engineering Case #668141)================ Calling the method SATcpOptionsBuilder.ClientPort could have caused the exception InvalidCastException to have been thrown. For example: SATcpOptionsBuilder options = new SATcpOptionsBuilder( "localonly=yes;port=6873" ); string cport = options.ClientPort; This problem has been fixed. ================(Build #3340 - Engineering Case #667762)================ SetupVSPackage.exe would have failed to add some dlls to the Global Assembly Cache on 64 bit Windows systems. This problem has been fixed. Also, a new command line option 'salocation' (or 'sal') has been added to SetupVSPackage to allow specifying the SQL Anywhere install location. If 'salocation' is specified, SetupVSPackage will use it to locate the necessary dlls. If 'salocation' is not specified, SetupVSPackage will use SQL Anywhere registry keys to locate the dlls. ================(Build #3337 - Engineering Case #667441)================ Misleading error messages would have been returned to the client when opening a connection using an invalid DSN. This problem has been fixed. ================(Build #3328 - Engineering Case #667927)================ The SQL Anywhere .NET Provider, running in 64-bit mode, might have inadvertently attempted to load a 32-bit language resource DLL (e.g., dblgen12.dll) and failed with an error. This problem has been corrected. ================(Build #3310 - Engineering Case #663470)================ On CE devices, if multiple applications were running simultaneously, the library dbdata.dll could have been deployed multiple times to the temp directory. This problem has been fixed. Additionally, the version number has been added to the native dll name (i.e. dbdata12.dll). This will allow running multiple versions of the provider simultaneously on Windows CE. ================(Build #3299 - Engineering Case #661459)================ The .NET provider was incorrectly assuming that a Sybase IQ 12.7 server supported the NCHAR datatype. This resulted in a failure to establish a connection to a Sybase IQ 12.7 server. This problem has been fixed. ================(Build #3286 - Engineering Case #657542)================ The results of an Entity DAta Model query could have been non-deterministic. For example, having a GridView with the properties "AllowPaging" and "AllowSorting" set to "True", would have returned a "Result is non-deterministic" warning (SQLCODE 122). This has been fixed by adding an ORDER BY clause to the generated SQL. ================(Build #3280 - Engineering Case #656481)================ An application using the ADO .Net provider, and calling the method SAConnection(), could not have successfully connected to an IQ 12.7 server. A run-time error (iAnywhere.Data.SQLAnywhere.SAException) would have occurred when the provider tried to parse the server version string. This problem has been resolved. ================(Build #3276 - Engineering Case #654446)================ If there were multiple applications running simultaneously, the ADO.NET provider could have failed to load dbdata.dll. This has now been fixed.

SQL Anywhere - DBLIB Client Library

================(Build #3718 - Engineering Case #704775)================ When multiple TLS connections were made from a single client application, a small amount of memory would have been leaked for each connection beyond the first. This could also have occurred in the database server, but only when the server made outgoing TLS connections (i.e. for mirroring or to remote servers). This has been fixed. ================(Build #3718 - Engineering Case #704775)================ When multiple TLS connections were made from a single client application, a small amount of memory would have been leaked for each connection beyond the first. This could also have occurred in the database server, but only when the server made outgoing TLS connections (i.e. for mirroring or to remote servers). This has been fixed. ================(Build #3718 - Engineering Case #704609)================ If a TLS library could not be found, or an error occurred when loading it, the resulting error message would have contained the system charset name rather than the name of the library. This has been fixed. ================(Build #3660 - Engineering Case #703452)================ If a SQL Anywhere client application exited abnormally, System V semaphores that were allocated by the SA libraries were not cleaned up. This problem affected all Unix platforms except Solaris, and has now been fixed. ================(Build #3651 - Engineering Case #705863)================ Connections from Linux clients may not have included the EXE value in connection_property( 'AppInfo' ). In particular, this affected applications where the effective user for the application was changed. This has been fixed so that the EXE value is now included in connection_property( 'AppInfo' ) on Linux, even if the effective user is changed. ================(Build #3529 - Engineering Case #693539)================ The changes for Engineering case 635466 introduced a problem where, on machines under heavy load, TCP connection attempts could have failed with an incorrect error code. On certain operating systems, the connection attempt could have hung. This has been fixed. ================(Build #3412 - Engineering Case #680183)================ In rare timing-dependent cases, a multi-threaded client application that made simultaneous connection attempts from different threads may have crashed. This has been fixed. ================(Build #3384 - Engineering Case #675293)================ If an initial connection was made to a blank-padded database, and the connection was redirected because of the NodeType connection parameter, the connection would have incorrectly failed with the error "Database cannot be started -- ???". If the LogFile connection parameter was used to get more information, the generated file would have contained the line "Communication function i_cs_ProtocolErrorP code 0". This has been fixed. ================(Build #3352 - Engineering Case #670185)================ If a client was attempting to connect over TCP/IP to a server that had just shut down, it is possible that the connection would have returned a SQLE_CONNECTION_ERROR error rather than a SQLE_SERVER_NOT_FOUND. This has been fixed. ================(Build #3344 - Engineering Case #668603)================ In rare cases, an application could have failed to connect because of a TCP/IP communication link failure. No specific reason for the failure would have been logged to the file specified by the LOGFILE connection parameter. This has been fixed. Note, this problem affected the .Net provider, the ODBC, JDBC and OLEDB drivers as well. ================(Build #3297 - Engineering Case #660204)================ Specifying a TCP timeout value of more than 2147 seconds could have caused connection failures. This has been fixed. ================(Build #3294 - Engineering Case #659643)================ An application could have crashed if it was attempting an Integrated Login or Kerberos connection and the connection to the server was lost. This could have occurred if the server was stopped or terminated during the connection. This has been fixed.

SQL Anywhere - JDBC Client Library

================(Build #3757 - Engineering Case #712102)================ If an application called CallableStatement/PreparedStatement/Statement.executeQuery() and then subsequently called CallableStatement/PreparedStatement/Statement.getResultSet() to retrieve the same result set that was generated by calling executeQuery(), then the JDBC driver would have leaked the memory. This problem has now been fixed. Note, there are two workarounds for this problem, both of which are considered better JDBC programming practices. The first is to use the ResultSet returned by calling executeQuery() directly and thereby avoid the second unnecessary call to getResultSet(). The other approach is to call execute() instead of executeQuery(), followed by a call to getResultSet(). ================(Build #3723 - Engineering Case #705368)================ If a JDBC application using the SQL Anywhere JDBC Driver called the "autoGeneratedKeys" overload of Connection.prepareStatement(), Statement.execute() or Statement.executeUpdate() with Statement.NO_GENERATED_KEYS, then the JDBC driver would incorrectly throw a "generated keys not supported" exception. This problem has now been fixed and calling these overloads with Statement.NO_GENERATED_KEYS now simply calls the "non-autoGeneatedKeys" overload. ================(Build #3525 - Engineering Case #693005)================ If a JDBC application was launched, and no language resource DLL or shared object was located, the application would have gone into a loop consuming virtual memory until an "out-of-memory" error occurred. This problem has been fixed. ================(Build #3480 - Engineering Case #687796)================ If an application using the SQL Anywhere JDBC driver attempted to exit, then there was a very small chance the client would crash on non-MacOS systems; however, on MacOS systems, the crash would have occurred every time. This problem has now been fixed. Note that the original problem was introduced with the fix for Engineering case 680183.

SQL Anywhere - ODBC Client Library

================(Build #3747 - Engineering Case #710978)================ If there were fewer SQLFreeHandle( SQL_HANDLE_ENV,... ) than SQLAllocHandle( SQL_HANDLE_ENV,... ) calls, and at least one TCP/IP connection had been made, unloading the ODBC driver dll, usually when the application exits, could have taken much longer than it should have. This could also have occurred if there were fewer SQLDisconnect calls than successful SQLConnect calls. This has now been fixed. ================(Build #3745 - Engineering Case #711141)================ The ODBC driver could have crashed when executing a block insert statement using data-at-execution time parameters. The problem would only have occurred when mixing data-at-execution time parameters with regular parameters. This has been fixed. ================(Build #3729 - Engineering Case #707201)================ In rare low-memory situations, a client application could have crashed on startup if TCP/IP was being used. This has now been fixed. ================(Build #3726 - Engineering Case #706558)================ When executing a bulk update with SQLExecute, there was a chance that not all rows would have been updated. If the UPDATE statement contained a WHERE clause that did not match any rows, any subsequent rows in the batch would have been ignored. This has been fixed. ================(Build #3579 - Engineering Case #699007)================ Calls to ODBC functions SQLGetDiagRec(with HandleType == SQL_HANDLE_ENV) or SQLGetDiagField(with HandleType == SQL_HANDLE_ENV and DiagIdentifier==SQL_DIAG_MESSAGE_TEXT) in the SQL Anywhere ODBC driver may caused a crash under certain circumstances. This problem has been fixed. ================(Build #3540 - Engineering Case #694658)================ If a double-precision floating-point object (SQLDOUBLE) was not aligned on an 8-byte boundary on a Windows Mobile ARM-based device, the SQL Anywhere ODBC driver would have incorrectly issued the following error message when an attempt was made to reference the object (for example, using SQLGetData()): [Sybase][ODBC Driver]Invalid string or buffer length On the ARM hardware platform, a double-precision value consists of two 32-bit words and, when held in memory, the two words must appear consecutively and must both be word-aligned (i.e., a multiple of 4). The ODBC driver has now been corrected to check for an alignment that is a multiple of 4, not 8. ================(Build #3452 - Engineering Case #684608)================ ODBC/JDBC escape syntax incorrectly required uppercase keywords like IN or FROM in scalar functions like POSITION and EXTRACT. For example: select {fn extract(month from '2011-05-07')}, {fn position('b' in 'abc')} would have failed with syntax errors. If an uppercase keyword was used, the query would have succeeded: select {fn extract(month FROM '2011-05-07')}, {fn position('b' IN 'abc')} This problem has been fixed. Note: In Interactive SQL, the braces { and } must be doubled-up (i.e. {{ and }} ). ================(Build #3432 - Engineering Case #675119)================ If the Microsoft Firewall Client (FwcWsp.dll) was installed on a Windows systems, applications would see a 20-second delay when the SQL Anywhere ODBC driver was unloaded. For example, if "Test Connection" was used when configuring a Datasource Name (DSN), using the ODBC Datasource Administrator on a system with Microsoft Firewall Client installed then a 20-second delay occurs after the OK button is clicked. A work-around has been developed for this problem. If the Firewall Client DLL is present when the SQL Anywhere ODBC driver is unloaded, the Windows Socket libraries are not unloaded by the driver. This avoids the 20-second delay. In this case, the Windows Socket libraries are unloaded when the client application terminates. ================(Build #3428 - Engineering Case #682755)================ Multithreaded client applications (e,g., ODBC, OLEDB, ADO.NET applications) could have crashed with a memory access violation, or leaked memory, when attempting simultaneous connections to a server. This problem has been fixed. ================(Build #3411 - Engineering Case #680039)================ A memory leak could have occurred when using the SQL Anywhere ODBC driver in such a way that the driver was repeatedly loaded and unloaded by the Microsoft ODBC Driver Manager on Windows Vista and Windows 7. This could have occurred when repeatedly creating and subsequently freeing the ODBC Environment as part of calling the SQL Anywhere ODBC driver. This problem occurs under Windows Vista and Windows 7 only as a result of a bug in Microsoft's SHELL32.DLL for these two operating systems. An Activation Context object is leaked on each load of the DLL. A workaround has been developed to avoid the problem. Another way to avoid the problem is to create and destroy the ODBC Environment only once in an application and connect/disconnect as often as desired. SQLAllocHandle( SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv ); SQLSetEnvAttr( henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0 ); loop connect/disconnect many times endloop SQLFreeHandle( SQL_HANDLE_ENV, henv ); Note, Microsoft has published http://support.microsoft.com/kb/2624911, which describes the problem with Windows Vista and Windows 7. ================(Build #3376 - Engineering Case #671099)================ When the ODBC driver ware loaded, part of its initialization involved loading and initializing the system TCP/IP libraries, even in cases where TCP/IP would not be used (eg. creating or viewing a DSN through the Data Source utility). This could have caused delays or problems with some firewall software. This has been fixed so that the TCP/IP libraries are now only loaded and initialized when they will be used. Note, this change also affect the other SQL Anywhere client libraries as well, i.e. DBLib, OLEDB, ADO.NET, etc. ================(Build #3372 - Engineering Case #669581)================ If an application attempted to perform a wide or batched insert, and the application did not bind or set enough parameters to match the number of parameters within the prepared INSERT statement, and the wide insert or batch insert size was greater than 1, then the application would have crashed. This problem has now been fixed. ================(Build #3364 - Engineering Case #672184)================ If an application attempted to perform a wide insert using the SQL Anywhere ODBC driver, or a batched insert using the SQL Anywhere JDBC driver, then there was a very small chance the application would crash if the system was low on memory or under stress. This problem has now been fixed. ================(Build #3286 - Engineering Case #657826)================ When using the Microsoft ODBC Data Source Administrator, a crash may have resulted if an encrypted password had been specified and the "Test Connection" button was used. This has been fixed. ================(Build #3267 - Engineering Case #652752)================ When starting dbisqlc, or an ODBC application with a connection string containing LINKS=TCPIP, if there is an error connecting the connection dialog is displayed. It was incorrectly defaulting to "connect to a running database on another computer", losing the LINKS=TCPIP setting. If TCP parameters were specified, such as LINKS=TCPIP(PORT=2638), then it worked correctly. This has now been fixed.

SQL Anywhere - OLEDB Client Library

================(Build #3727 - Engineering Case #706876)================ A Microsoft Data Link Error could have occurred with newer versions of Microsoft software when using the SQL Anywhere OLE DB provider. When the Test Connection button was clicked, the following message would have been displayed when the error occurred: Test connection failed because not all properties can be set. Window Handle (BAD VALUE) Continue with test connection? [Yes] [No] The message was informational only and Yes can be clicked. If the credentials and other connection information were correct, the connection succeeded. This problem has been fixed. Instead of returning a NULL window handle to the Microsoft software, the OLE DB Window Handle property is now marked as unsupported, which removes the warning message. ================(Build #3425 - Engineering Case #683425)================ Additional changes were required for Engineering case 681396, where the server may not start on HP-UX machines if there were many network interfaces. The description for case 681396 mentioned Unix systems, but this problem was actually limited to HP-UX only. A border case, as well as IPv6, were corrected as well. ================(Build #3422 - Engineering Case #683161)================ A multithreaded application using the SQL Anywhere oledb driver could have crashed with an access violation when a rowset was released. This problem was introduced by the changes for Engineering case 662986, and has now been fixed. ================(Build #3422 - Engineering Case #681419)================ Multi-threaded OLEDB applications could have experienced an access violation when a rowset was released. This problem was introduced by the changes made for Engineering case 662896 and has now been fixed. ================(Build #3309 - Engineering Case #662896)================ When using the OLEDB provider, if a statement was prepared, executed, and then the ADO MoveFirst() (OLE DB RestartPosition() ) method was called when the cursor type was forward-only, the statement would have become unprepared. Subsequent attempts to execute the prepared statement would then have failed. This problem has been corrected. ================(Build #3291 - Engineering Case #658887)================ The OLE DB DBSCHEMA_FOREIGN_KEYS rowset returned the following indicated integer values for the UPDATE_RULE or DELETE_RULE referential actions. CASCADE 0 if referential action is NULL 1 SET NULL 2 SET DEFAULT and RESTRICT 3 These values, derived from the ODBC SQLForeignKeys result set, did not match the following OLEDB constants defined for these referential actions. DBUPDELRULE_NOACTION = 0x0 DBUPDELRULE_CASCADE = 0x1 DBUPDELRULE_SETNULL = 0x2 DBUPDELRULE_SETDEFAULT = 0x3 Furthermore, the DBSCHEMA_FOREIGN_KEYS rowset should have returned strings rather than integers for the UPDATE_RULE or DELETE_RULE referential actions. The OLE DB specification states: If a rule was specified, the UPDATE_RULE or DELETE_RULE value is one of the following: "CASCADE" — A <referential action> of CASCADE was specified. "SET NULL" — A <referential action> of SET NULL was specified. "SET DEFAULT" — A <referential action> of SET DEFAULT was specified. "NO ACTION" — A <referential action> of NO ACTION was specified. Providers should return NULL only if they cannot determine the UPDATE_RULE or DELETE_RULE. In most cases, this implies a default of NO ACTION. Also, the fix for Engineering case 620136 did not handle the situation when there was no declared Primary Key in the primary table but there were table or column (not nullable) Unique Constraints that permitted the addition of foreign keys. These problems have been fixed. The Upgrade utility should be used to update the OLE DB schema rowset support in any database used with ADO, ADOX or OLE DB. ================(Build #3266 - Engineering Case #651383)================ As of the changes for Engineering case 633120, a SQL query producing multiple result sets was not handled correctly by the SQL Anywhere OLE DB provider. This problem has now been corrected. The cursor is no longer closed after the first result set is processed.

SQL Anywhere - Other

================(Build #3759 - Engineering Case #713568)================ Mini-dump files generated by SQL Anywhere software on Linux system could have been unusable. This problem was most likely to occur if the process being dumped was using a large number of threads (> 480). This has now been fixed. ================(Build #3605 - Engineering Case #701922)================ Use of some of the HTTP samples verbatim in a production system could have caused exposure to Cross Site Scripting (XSS) issues. This has been fixed. Note that it is highly recommended that application developers and DBAs always review their web application code for possible security vulnerabilities before they are put into production. The Open Web Application Security Project (https://www.owasp.org) contains more information on how to secure your web application. ================(Build #3565 - Engineering Case #715904)================ Installing SQL Anywhere in silent mode on Solaris systems may have resulted in an error like: "The following option names are invalid or are not exposed by the registration key provided". This has been fixed. ================(Build #3540 - Engineering Case #695079)================ When connected via jConnect, the procedure used to query the primary key metadata of a table would have returned too many rows if the table had a primary key column that was also a foreign key reference to another table. This problem has now been fixed. Note, an ALTER DATABASE UPGRADE will need to be performed on existing databases in order to get the new jConnect metadata procedures. ================(Build #3539 - Engineering Case #695772)================ When creating a custom MSI install using the deployment wizard, two properties were not being set correctly: UpgradeCode and ProductVersion. This has been fixed so that they are now set correctly. ================(Build #3518 - Engineering Case #689954)================ An ODBC application could have crashed when attempting to connect if a thread was unable to be started. This has been fixed. ================(Build #3513 - Engineering Case #691893)================ When installing an MSI file created by the Deployment wizard, the install would have partially completed and then failed, rolling back the install. This has been fixed. ================(Build #3485 - Engineering Case #687835)================ If an MSI install was built using the Deployment wizard, and Sybase Central was selected but Interactive SQL was deselected, the subsequent install of Sybase Central would have failed on exit. The error: Interactive SQL could not be launched. Please change the plug-in properties and add the isql.jar file to its path. was due to Sybase Central expecting ISQL.jar to be installed. This has been corrected by adding a dependency on ISQL.jar when an install of Sybace Central is created. ================(Build #3478 - Engineering Case #686304)================ When SQL Anywhere components were running in the isolated session 0 (ie, the services session) of Vista and later Windows operating systems, but were not actually running as services, the components could have attempted to display GUI elements. Due to session 0 isolation, these GUI elements were not accessible to users. To execute as a non-service within session 0, the program was likely to have been launched as a child of a service. On Vista and later versions of Windows, SQL Anywhere components now suppress GUI components when running in session 0 rather than just when running as a service. ================(Build #3476 - Engineering Case #685894)================ When running at a verbosity higher than 0, the Relay Server Outbound Enabler was not obscuring the security token and passwords in the log file. This has been fixed so that their values are now hidden by ******, regardless of verbosity level. ================(Build #3467 - Engineering Case #685289)================ When performing an archive backup via an external backup provider, the database server provided incorrect min_iosize & max_iosize parameters to the provider when calling the syb_defineapi() function. Generally, the min_iosize was set to what is actually the server's maximum IO size and max_iosize was set to 512K. Usually, the min_iosize was larger than the max_iosize. This problem has been fixed by setting the min_iosize to 2K and the max_iosize to the server's actual max buffer size. ================(Build #3390 - Engineering Case #676364)================ The version of zlib used by the SQL Anywhere and MobiLink clients and servers contained security vulnerabilities documented under US CERT Vulnerability notes VU#680620 and VU#238678. These are fixed in zlib version 1.2.3. SQL Anywhere and MobiLink clients and servers now use zlib version 1.2.5. Links: http://www.kb.cert.org/vuls/id/680620 http://www.kb.cert.org/vuls/id/238678 ================(Build #3376 - Engineering Case #674262)================ When 64 bit versions of SQL Anywhere, MobiLink or the Relay Server were installed, and none of the corresponding 32-bit features were installed (which is the default feature selection), the Start menu shortcuts to dblang.exe ("Change language to <language>") would not have worked. This has been fixed. ================(Build #3367 - Engineering Case #672577)================ If the PATH environment variable placed earlier versions of SQL Anywhere before version 12.0 in the path, then newdemo.bat would have launched earlier versions of SQL Anywhere utilityes, but used the version 12 Scripts folder. This may have resulted errors if the earlier version did not support the same SQL language that was used by the scripts in the Scripts folder. This problem has been fixed. The newdemo.bat file will now reference the tools explicitly by their path. Note, the newdemo.bat file is referenced by the SQL Anywhere documentation whenever it is desirable to start with a newly initialised version of the demonstration database. ================(Build #3365 - Engineering Case #672739)================ A number of edits have been made to the SQL Anywhere server, the MobiLink server and UltraLite error messages to improve readability and to make the wording more consistent with the SQL Anywhere documentation. These changes include minor grammatical corrections, and changes to enforce consistency with hyphens and capitalization. No changes were made to SQLCODE, SQLSTATE, or ODBC error states for any of these messages. ================(Build #3364 - Engineering Case #669747)================ On Linux systems, when installing the SQL Anywhere Monitor EBF, the installer would have removed the old copy from the samonitor_oldXX directory after migrating samonitor.db. This behavior was different from 12.0.0 EBFs which would always have left the old copy in the samonitor_oldXX directory. This has been fixed. ================(Build #3364 - Engineering Case #661180)================ On Linux systems, if the SQL Anywhere Monitor EBF was installed as a non-root user, and the SQL Anywhere Monitor service had been started by the root user, the following error messages would have been displayed: Migrating SQL Anywhere Monitor database Connecting... Can't connect to source database. [Sybase][JDBC Driver][SQL Anywhere]Specified database not found Rolling back files in /opt/samonitor12 ... wc: ./.ebf_20110601-1149/samonitor.db: Permission denied Cleaning up ... This has been fixed so that the following error message is now displayed: The setup program was unable to stop a running instance of SQL Anywhere Monitor. Please stop it manually and run the setup program again. A workaround is to stop the SQL Anywhere Monitor service manually, then re-run the EBF installer. ================(Build #3359 - Engineering Case #668771)================ When building a Deployment wizard install MSI, and select Chinese (ZH) as the deployment language. progress messages would have been displayed in English. This has been corrected so that they are now displayed in Chinese. ================(Build #3355 - Engineering Case #669408)================ On Unix, if SQL Anywhere was installed into the default location as user A, logging in as user B and checking for updates would have failed with an error like, "Could not check for updates." The installed.ini file only had read and write permissions for the current user and group. This has been fixed by giving broader permissions on the file so it could be used by "other" users. ================(Build #3354 - Engineering Case #668766)================ When creating a 64-bit Deployment wizard MSI install, containing both 64-bit and 32-bit software, only one set of Sybase Central plugins would have been registered when installing on a 64-bit system. This has been corrected so that both 32-bit and 64-bit plugins are now registered. ================(Build #3353 - Engineering Case #668768)================ After uninstalling a Deployment wizard .MSI install made with default contents, several .JPR files would have been left behind in the SQL Anywhere 12\java directory. This has been fixed so that these files are now correctly uninstalled. ================(Build #3348 - Engineering Case #669407)================ When uninstalling on Solaris, it was possible to see an error like: find: stat() error /opt/sybase/sqlanywhere12/sun/jre160/lib: no such file or directory This has been fixed. It should be noted that despite the error, the uninstaller would have completed successfully. ================(Build #3345 - Engineering Case #668765)================ When running the Deployment Wizard, clearing the default MSI name in the Destination Path page of the wizard and clicking the Next button would have caused an unhandled exception. This occurred due to the fact that the filename was not valid. This has been corrected by graying out the Next button if the filename is left blank. ================(Build #3321 - Engineering Case #665004)================ When trying to connect using the Ruby DBI interface, the driver did not raise an error if the username/password was invalid. Instead it silently failed. This has been fixed. ================(Build #3301 - Engineering Case #669009)================ When upgrading from 12.0.0 to 12.0.1, if the 12.0.0 samples had been installed to a non-default location, the upgrade to 12.0.1 installed any new or reorganized samples to the default sample location. This has now been fixed. Note that 12.0.1 EBFs can be now applied directly to 12.0.0 installations - effectively performing an upgrade. Therefore if a 12.0.0 installation has not yet been upgraded to 12.0.1, use of a 12.0.1 EBF with this fix will avoid this problem. If a 12.0.0 installation had been upgraded with a build without this fix, uninstalling the product will not remove all the sample files. Those files will need to be removed manually. ================(Build #3298 - Engineering Case #661242)================ A silent install of SQL Anywhere Monitor in which the location of the database (DIR_SQLANY_MONITOR) was not specified, would have caused the database to be installed to %SystemDrive%\CommonDocFolder. This has been fixed so that the correct default location is now used (%ALLUSERSPROFILE%\Documents\SQL Anywhere Monitor 12). ================(Build #3298 - Engineering Case #661188)================ The 64-bit UltraLite ODBC driver (Bin64\ulodbc12.dll) was not being correctly registered. This would have resulted in the failure of Interactive SQL and/or Sybase Central to load an UltraLite database. The has been fixed. Alternatively, the driver can be registered manually using the following command: regsvr32.exe %SQLANY12%\Bin64\ulodbc12.dll ================(Build #3295 - Engineering Case #660190)================ The folder names under %SQLANYSAMP12%\UltraLiteJ\Android\CustDB used mixed case and in some cases were incorrect in the GA release of 12.0.1. This caused Eclipse to fail when building the sample. This has been fixed such that future remastered releases will use the correct case. However, EBF installs will not fix these incorrect folder names. A workaround is as follows: Before attempting to build the sample in Eclipse, ensure that the sub-directory names are as show below. Note that all names are lower case and that hyphens (-) should be used, not underscores (_), where applicable. libs res src libs\armeabi res\drawable-hdpi res\drawable-ldpi res\drawable-mdpi res\layout res\menu res\values src\com src\com\sybase src\com\sybase\custdb ================(Build #3281 - Engineering Case #659357)================ Running the Deployment wizard when SQL Anywhere had been installed to directory with a path containing multi-byte characters would have caused the generation of the MSI to fail with an error like: "C:\Sy签署\SQL Anywhere 12\bin32\dblib12.dll (Not Found)". This has been fixed.

SQL Anywhere - Server

================(Build #3769 - Engineering Case #715597)================ Performance of statements that select from a stored procedure call is slightly improved when the call results in a SQLError. ================(Build #3769 - Engineering Case #715309)================ The server was incorrectly accepting the special values NaN, INF, and INFINITY for double and float data types when receiving host variable values. This has been fixed. Now the server will set the SQL error "Value NaN/INF out of range for destination". ================(Build #3768 - Engineering Case #715473)================ In extremely rare cases, the server may have crashed on shutdown on multi-CPU machines. This has been fixed. ================(Build #3768 - Engineering Case #715310)================ If a mirror or copy node was shutdown, and it was actively applying log operations from the primary or its parent, the server could have failed assertion 100904 - "Statement interrupted by user". This has been fixed by not failing this assertion when the server is in the process of shutting down. ================(Build #3768 - Engineering Case #713922)================ If a query contained two predicates on the same column T.A, of the form 'T.A > constant' and 'T.A = R.A' , and an index on the column T.A exists, the cardinality of the index scan with the predicate 'T.A = R.A' was incorrectly computed always using the predicate 'T.A > constant'. This may have affected the quality of the best plans for such queries. This has been fixed. ================(Build #3766 - Engineering Case #714752)================ Queries using text indexes with constructs of the form CONTAINS( ... 'xxx*' ... ) may have had poor performance. This has been fixed. ================(Build #3766 - Engineering Case #707918)================ In rare cases, a query using a parallel NestedLloopsJoin could have caused the server to crash. This has been fixed. A workaround is to disable intra-query parallelism for the affected query. ================(Build #3765 - Engineering Case #714777)================ In rare cases, a mirroring server could have crashed if it received an invalid request from another mirror server. This has been fixed to no longer crash. ================(Build #3765 - Engineering Case #714776)================ In rare timing dependent cases, a high availability mirror or copy node could have incorrectly failed with the assertion 100927. The assertion could have occurred just after the mirror or copy node had connected to its partner or parent and had just started synchronizing. This has been fixed. ================(Build #3765 - Engineering Case #714656)================ The server could have crashed when starting a database. If the server was in the process of shrinking the cache, references to memory that were no longer available were possible. This has now been fixed. ================(Build #3763 - Engineering Case #714440)================ In a high availability system, a forced or preferred server fail-over could have failed to restart the database on the primary server if all of the following conditions held: - the database character set was different from the operating system character set - the database name (or alias) contained characters other than 7-bit ASCII characters - an "ALTER DATABASE SET PARTNER FAILOVER" statement was executed, or a preferred partner was defined and the current primary was the non-preferred partner. This has been fixed. ================(Build #3761 - Engineering Case #713914)================ For a pooled CmdSeq connection or HTTP connection, connection_property( 'ApproximateCPUTime' ) incorrectly included CPU time from before the connection was reused, and connection_property( 'LoginTime' ) was not reset when a pooled connection was reused. This has been fixed, so that 'ApproximateCPUTime' now only includes time from when the application connected, and 'LoginTime' is set to the time when the application connected. ================(Build #3759 - Engineering Case #713681)================ If the server was displaying the usage window, or was very early in the start-up process, and the Windows machine the server was running on was suspended, the server could have crashed when the machine was restarted. This has been fixed. ================(Build #3758 - Engineering Case #711791)================ Recursive queries can not contain aggregate functions. When written using a window (OVER clause), aggregates were improperly allowed. In some cases this could have lead to the server crashing under certain system conditions. This has been fixed, queries with windowed aggregate functions now correctly give an error. ================(Build #3757 - Engineering Case #424085)================ When a computed column is added to a table, the expression used to generate the column values may give an error, the actual error will depend on current option settings and the current connected user. The following examples show ways that a computed column may give an error in some circumstances only: - Use an unqualified user-defined function (UDF). If the current user does not include the UDF in the lookup path, an error is returned. - Miss-spell a UDF name. There is no checking done when the column is added. Any use of the table fails. - Create the column referencing a UDF then drop it. Even if 2. is fixed, there is no dependency tracking to prevent 3. - Use a cast that gives an error at build time (e.g, TIME -> INT). The table causes an error unless the Conversion_error option is Off. - As with 1. 2. or 3. , use a sub-select referencing a table, view or procedure that is unqualified or non-existent. - Use features in the compute expression that cause SQL flagger errors to be returned. If the connection options give a flagger error, the table can not be used. http://dcx.sybase.com/index.html#1201/en/dbusage/defining-computed-javause.html*d5e620 When the expression for a computed column gives an error, it does so for any query that references the table (even if the table is not modified by the statement. As a best practice, computed columns should be defined with an expression that is computed in the same way for all connections and all users that have permission to read from the table. ================(Build #3755 - Engineering Case #713113)================ In rare timing dependent cases, a mirror or copy node could have crashed or failed assertions (the most likely assertion was 100927). This could have occurred when very frequent transactions were committed on the primary and the mirror or copy node was not applying the operations as fast as it was writing them (i.e. db_property( 'LastWrittenRedoPos' ) is significantly more than db_property( 'CurrentRedoPos' )). This has been fixed. ================(Build #3755 - Engineering Case #712964)================ The server could have crashed in very rare cases while attempting to close a connection that had previously made an external environment call if the external environment call subsequently made a server side request that obtained table locks which were still being held when the connection was closed. This problem has now been fixed. ================(Build #3755 - Engineering Case #712128)================ In rare cases, the server could have hung while trying to shut down a database if there were open connections that subsequently had open Remote Data Access connections. This problem has now been fixed. ================(Build #3754 - Engineering Case #712884)================ In very rare timing dependent cases, if a mirroring primary failed over and then failed back, one partner could have received a log mismatch error and shutdown, and transactions that had been submitted could have been lost. Specifically, in order for this to have occurred with partners S1 and S2: - S1 must initially have been the primary, failed or otherwise have shutdown, causing a failover to S2 - S2 took over as primary - while S1 was restarting, S2 must have lost quorum and have been shutting down In which case it was possible for S1 to have become primary again, even though it was missing the transactions from when S2 was primary. This has been fixed to ensure that S1 will not be primary in this case, and S2 will continue to be primary once it restarts. ================(Build #3754 - Engineering Case #712851)================ A cloud partner could have hung upon losing quorum. This problem has now been fixed. ================(Build #3754 - Engineering Case #712722)================ Under rare circumstances, rollback of a DML statement that affected a table with at least one immediate text index defined could have caused production assertion failure 200112. This has been fixed. ================(Build #3754 - Engineering Case #712087)================ While using blocking timeout options in the presence of other connections accessing referenced tables, ALTER TABLE ... DROP FOREIGN KEY statements could have caused the server to fail assertion 102813. This has been fixed. Now the alter table statement fails, properly displaying a locking error. ================(Build #3754 - Engineering Case #706150)================ In rare cases, a server may have received an odd ClassNotFoundException when making a Java external environment call, even though the class had previously been successfully loaded. This problem has now been fixed. Note that this change also greatly improves the performance of loading classes from the database. ================(Build #3753 - Engineering Case #711139)================ Under exceptionally rare conditions, the server may have crashed while accepting a new shared memory connection, if the client application exited during connect request processing. This has been fixed. ================(Build #3750 - Engineering Case #702214)================ If an application called an external environment procedure that was defined with SQL SECURITY INVOKER and then subsequently made a stored procedure call using the server side connection, then there was a chance the call would have incorrectly fail with a permission denied error. This problem has now been fixed. ================(Build #3749 - Engineering Case #711803)================ If the encrypt() or decrypt() functions were called with a non-null string but a null encryption key, the functions returned null. This has been fixed. An encryption key is required, so these functions will now raise an error if the encryption key is null. ================(Build #3749 - Engineering Case #700123)================ If two connections made external calls that in turn attempted to access rows that the other connection already had a lock on, then the server would incorrectly hang the two connections rather than returning a deadlock error to one of the connections involved. This problem has now been fixed. ================(Build #3748 - Engineering Case #711656)================ When fetching an unsigned int value from an sajdbc, iqjdbc or asejdbc remote server, the returned value would always have been NULL. This problem has now been fixed. Note that this problem does not affect ODBC based remote servers. ================(Build #3748 - Engineering Case #708057)================ When fetching from a directory access table with a query of the form: select ... from directory_access_table where ... file_name like 'abc%' ... the server would have returned a syntax error. This problem only existed if the comparison value (i.e. 'abc%') had no directory separators. For example, a query of the form: select ... from directory_access_table where ... file_name like 'abc\def%' ... would have worked just fine. This problem has now been fixed. ================(Build #3748 - Engineering Case #691040)================ When fetchingd a string value containing trailing blanks from a proxy table, the trailing blanks would have been stripped. This problem has now been fixed and the string value will be exactly as returned by the underlying driver. ================(Build #3745 - Engineering Case #711129)================ In rare timing dependent cases, the server could have crashed if one or more connections were using the blocking_others_timeout temporary option. This has been fixed. ================(Build #3743 - Engineering Case #710285)================ Under rare circumstances, a server may have crashed while opening the result set cursor of a batch or stored procedure when the cursor's query was a cached simple SELECT. This has been fixed. A workaround is to turn plan caching off (option Max_plans_cached = 0). ================(Build #3742 - Engineering Case #710072)================ Under certain rare circumstances, calling the system procedure sa_locks() could have caused the server to fail a fatal assertion. This has now been fixed. ================(Build #3740 - Engineering Case #668716)================ In rare circumstances, a database with snapshot isolation enabled could have triggered an assertion while updating values indexed by an immediate text index. This problem required high contention on the base table. This has been fixed. ================(Build #3736 - Engineering Case #709203)================ If a jConnect or Open Client connection prepared a statement and called a stored procedure with a set of host variables, then the server could have crashed, or returned an odd "variable already exists" error, if the stored procedure had a parameter or variable named @p0. This problem has now been fixed. ================(Build #3736 - Engineering Case #708087)================ When using the VALIDATE TABLE or VALIDATE INDEX statements, the server could have reported that there was an 'orphaned blob' (ie. a blob that is in the database but not referenced by any row) when there were, in fact, no orphaned blobs. To encounter this problem, there must have been deleted rows in the database that contained unique blobs (not shared by any other row) and either the deletes were uncommitted, or they had been left for the database cleaner to remove at a later time. Rows not cleaned by the cleaner were more likely to be seen on a read-only database, as the database cleaner is disabled for read-only databases. This problem has been fixed. Also when using the VALIDATE TABLE or VALIDATE INDEX statements, the server could fail to report orphaned blobs when they did, in fact, exist. Whether or not this problem occurred depended on random contents of memory as well as the number of DML operations applied to the table prior to validation. This problem has been fixed. When reporting a validation problem, the server returns an error to the client but also displays additional information in the server console. For orphaned blobs, a blank message was erroneously displayed in the console. This problem has been fixed. ================(Build #3736 - Engineering Case #707910)================ A query with many nested UNION query blocks may have taken a very long time before query execution began. This has been fixed. ================(Build #3732 - Engineering Case #708199)================ The server would have returned a syntax error when trying to specify "client" as a secure feature to be enabled or disabled (-sf command line option). This has been fixed. ================(Build #3729 - Engineering Case #707553)================ In rare cases, the first time a mirror server or copy node connected to a high availability primary or a read-only scale-out parent, the primary or parent could have crashed. This has been fixed. ================(Build #3729 - Engineering Case #707064)================ When starting the Network Server on Windows, or calculating the 'IsPortableDevice' server property, the server may have taken longer than necessary to obtain information about the computer. This has been fixed, althought the difference in the delay is not likely to be noticeable. ================(Build #3729 - Engineering Case #707002)================ The request for the graphical plan of a statement would have caused the server to crash if the statement contained an IN predicate and the list consisted of only host variables and an In List algorithm was chosen for it. This has been fixed. ================(Build #3726 - Engineering Case #704963)================ If a predicate selectivity estimate was computed using a column histogram and the lookup value was out of bound in the histogram, an index probe was not then used for selectivity estimate. This has been fixed. This also improves the selectivity estimates for a column for which the histogram is out of date or contains incomplete data if an index on that column exists. ================(Build #3725 - Engineering Case #706371)================ The SQL Anywhere HTTP server may have crashed if a request was timed-out. The crash would have occurred when a request had timed-out on a host under very high CPU load (the server itself need not have been especially busy). This has been fixed. ================(Build #3723 - Engineering Case #705529)================ In some cases, 64-bit servers could have crashes when executing queries using TIMESTAMP WITH TIME ZONE values. The 32-bit server was not affected. This has been fixed. A workaround is either to use regular TIMESTAMP types, or use a 32-bit server. ================(Build #3723 - Engineering Case #703642)================ If a database had a user defined type based on nchar, nvarchar or long nvarchar, then attempting to fetch a value defined with that user defined type would have incorrectly returned a binary value when the connection was via jConnect or Open Client. This problem has now been fixed. Note that fetching nchar values defined with the nchar, nvarchar or long nvarchar base datatypes is not affected by this problem. ================(Build #3723 - Engineering Case #702184)================ If an application had a Java stored procedure defined with SQL SECURITY INVOKER, and the application subsequently called the stored procedure with two different effective userids from the same database connection, then the server would have incorrectly given a "table ExtEnvMethodArgs not found" error. This problem has now been fixed. ================(Build #3723 - Engineering Case #696617)================ If the database option PUBLIC.Java_vm_options was set to contain only spaces, then the server would have crashed when the JAVA external environment was started. This problem has now been fixed. ================(Build #3722 - Engineering Case #704801)================ Cursors over SELECT statements referencing proxy tables could have returned errors in the presence of publications for some of the tables. The error depends of how complex the publications are. A typical error would be "assertion failed: 102604 - Error building sub-select". This has been fixed. ================(Build #3721 - Engineering Case #704468)================ If deadlocks arose between connections using parallel execution plans, the deadlock may not have been detected. Additionally, another connection later contending for the same locks could have caused the server to crash. This has been fixed. A workaround is to set the option MAX_QUERY_TASKS to 1 for transactions that are known to participate in deadlocks. ================(Build #3721 - Engineering Case #703234)================ If a parallel backup with backup option WITH CHECKPOINT LOG RECOVER had finished its write pass but had disk I/O errors during its completion pass, then, in exceptionally rare circumstances, the backup may have incorrectly been marked as valid and no SQL error was returned. Also, if a parallel backup of the database file was cancelled after its read pass then the server may have crashed. Both problems have now been fixed. ================(Build #3720 - Engineering Case #640952)================ On Solaris systems, the server would have failed to start if the filesystem for the temporary file ($SATMP) was of a size greater than 4TB. This problem has now been fixed. ================(Build #3719 - Engineering Case #704057)================ If a database was created with 9.0.2.4029 or earlier, with any version of 10.0.0, or with 10.0.1.4072 or earlier, then upgraded (using the Upgrade utility or ALTER DATABASE UPGRADE) to a newer build of SQL Anywhere, the Unload utility could have erroneously generate SQL to re-create the jConnect-related objects "jdbc_functioncolumns" and "sp_jdbc_getfunctioncolumns" which are, after the builds indicated, included automatically in newly created databases. Similarly, if a database was created with any version of 10.0.0, and then upgraded to any version of 10.0.1 or later, the Unload utility could erroneously have generate SQL to re-create the SQL Anywhere internal function "sa_ansi_standard_packages". During a reload, these problems would have generated a message such as the following: ***** SQL error: Item 'jdbc_functioncolumns' already exists These problems have been fixed. ================(Build #3719 - Engineering Case #701364)================ Queries with derived tables or views using UNION, EXCEPT, INTERSECT orRECURSIVE constructs may have returned incorrect results. For this problem to have occurred at least one child of the derived table or view would have had a LIMIT, window function, or DISTINCT clause, and there was a predicate referring only to the columns of the derived table or the view in the main query block. This has been fixed. ================(Build #3719 - Engineering Case #697900)================ Attempting to execute a long SQL statement to create a stored procedure could have failed with a "parse stack overflow" error (SQLCODE -131). This problem may also have occurred when parsing a long and nested SQL statement. This has been fixed. ================(Build #3713 - Engineering Case #702733)================ This change extends the fix for Engineering case 693560. In this case, the parallel hash filter could deadlock if a runtime error occurred while it was fetching. This has now been fixed. ================(Build #3713 - Engineering Case #693560)================ Under very rare circumstances, a server could hang if it had a large number of processors and was executing a query with a parallel hash join. This was more likely on systems with large numbers of cores (more than 8). This has been fixed. A workaround is to disable intra-query parallelism by setting option MAX_QUERY_TASKS=1. (This only needs to be done for the statement or connection experiencing the problem, if it can be isolated.) ================(Build #3712 - Engineering Case #703225)================ If a database had been created with a server from a version prior to 11.0.0, and it contained a proxy table with an index, then unloads of this database using a server from version 11.0.0 or later' would have generated an incorrect CREATE INDEX statement containing the IN "SYSTEM" clause. This has been fixed. ================(Build #3712 - Engineering Case #703104)================ When translating a transaction log with certain types of corruption, the Log Translation utility could have terminated silently, without reporting a problem. To the user, it would have appeared as if the translation completed successfully. This problem has been fixed. ================(Build #3712 - Engineering Case #703100)================ When querying the TcpipAddresses, HttpAddresses, or HttpsAddresses properties from a server running on a Unix platform, any IPv6 addresses may have included a zone indicator (eg. the "%2" in "(fd77:55d:...:6a1f%2):2638". This was not useful outside the server's machine and should not have been included in the value of this property. This has been fixed. ================(Build #3712 - Engineering Case #703083)================ If the number of databases on the command line was near to or greater than the server concurrency setting (-gn), then the server could have crashed, or reported any of various assertion failures, during startup. The Personal Server was particularly susceptible since its default concurrency is only 20. This problem has been fixed. ================(Build #3712 - Engineering Case #702738)================ The server could have become deadlocked when updating blobs in a table with articles or triggers. This has now been corrected. ================(Build #3712 - Engineering Case #701652)================ When shutting down a database server on a Windows machine with a SQL Anywhere Volume Shadow Service (VSS) writer service active, the database server could have logged the message "Registered with the SQL Anywhere Volume Shadow Copy Service writer." many times to the console log. This problem has been fixed. ================(Build #3712 - Engineering Case #696917)================ With the QAnywhere .NET client, the elapsed time to queue messages was substantially slower than that of version 9.0.2. Several performance optimizations have been made, bringing the timings closer to those for version 9.0.2. Note that the SQL client API is no longer supported by default. If the SQL client API is needed, the QAnywhere message store must be initialized using qaagent -si with the new option -sqlapi. ================(Build #3711 - Engineering Case #702296)================ When generating a reload.sql script, the server did not double-up single quotes and backslash characters in constant strings for dbspace file names in the CREATE DBSPACE statement, directory server paths in the CREATE SERVER statement, or AT location clauses of the CREATE EXISTING TABLE statement. As a result running the reload script would have failed and the generated objects would not have worked. This has been fixed. ================(Build #3709 - Engineering Case #702274)================ A potential security problem with the server has been corrected. ================(Build #3709 - Engineering Case #701339)================ The server may have crashed when using a cached query plan if the plan useed a row column variable in a Distinct Hash strategy and the row column variable was of type string or numeric. Row column variables are column names that are used with a REFERENCING table alias name from the CREATE TRIGGER. This has been fixed. ================(Build #3707 - Engineering Case #702086)================ If a new IP address was added to a machine running a SQL Anywhere server, the server may have failed to recognize the new IP address. This would only have occurred when the server was running on a portable device (eg. laptop), or if the -xm switch was specified. This has been fixed. ================(Build #3707 - Engineering Case #701151)================ Read-only connections on an OEM server were not able to drop local temporary database objects. This has been fixed. ================(Build #3706 - Engineering Case #701327)================ If an application attempted to fetch data from an ADS proxy table using a 64-bit server, then there was a very good chance the server would have crashed. This problem has now been fixed. ================(Build #3683 - Engineering Case #708826)================ In rare, timing dependant cases a copy node in a mirroring read-only-scale-out setup may have crashed. This has been fixed. ================(Build #3683 - Engineering Case #708518)================ Mirroring copy nodes could have hung on shutdown with one core at 100% utilization. ================(Build #3683 - Engineering Case #708426)================ In rare timing dependent cases, a mirror server or copy node could have crashed while it, or the mirrored database, was shutting down. In order for the crash to have occurred, a copy node child must have begun to request log pages from the stopping server. This has now been fixed. ================(Build #3680 - Engineering Case #709909)================ In rare, timing depending cases, the server could have crashed. This was more likely to have occurred when multiple database events could start and stop concurrently on multi-core computers. This has been fixed. ================(Build #3679 - Engineering Case #707904)================ If the root database restarted soon after a copy node connected to it, the copy node could have, in rare timing dependent cases, crashed or failed assertions. This has been fixed. ================(Build #3672 - Engineering Case #707037)================ In rare timing dependent cases, a high availability partner or copy node server could have crashed. Additionally, in rare cases, the arbiter could have reported the following message to the console: "arbiter already has two connections". These problems could have occurred when a partner detected loss of quorum, when a copy node was attempting to connect back to its original parent after being connection to an alternate parent or the root server, or if a connection between mirror servers failed. This has been fixed. ================(Build #3670 - Engineering Case #707529)================ If the primary server failed in some timing dependent cases, the mirror server could have failed to take over as primary. When this problem occurred, the mirror database would have restarted and be attempting to determine its role until the primary was restarted, or the ALTER DATABASE ... FORCE START statement was executed on the mirror server. This has been fixed. ================(Build #3664 - Engineering Case #707019)================ When the database server was running a database whose page size was smaller than the cache's page size, dynamic cache sizing could have chosen a cache size that was too small, which could have resulted in a performance penalty. This problem has been fixed. ================(Build #3661 - Engineering Case #706892)================ There are many reasons for a database, that is a partner in a High Availability system or a copy node, to be restarted. In several cases, no reason for a restart was logged to the console. This has been fixed so that a message indicating the reason for a restart is now logged to the console. ================(Build #3658 - Engineering Case #706724)================ The server was failing to redirect an HTTP request made to a secure web-service (requiring HTTPS protocol) when the request specified an ipv6 address. This has been fixed. ================(Build #3656 - Engineering Case #706510)================ A server would have leaked memory, and may eventually have run out of memory, if a very large number of Open Client or jConnect secure password connection requests were made. This problem has now been fixed. ================(Build #3653 - Engineering Case #706179)================ When a server in a mirroring system tried to start up a database as a mirror or copy node, it was possible for the server to receive a transaction log mismatch if there was a problem connecting to the primary or the copy node's parent server. This would have caused the database to shut down, and subsequently the server, if no other databases were running on the server. In this particular case, there was not actually a log mismatch, and so the database would have restarted successfully without replacing database files. The error message printed in the console was: "Transaction log does not match log on mirror partner". This has been fixed. ================(Build #3653 - Engineering Case #706174)================ If a High Availability partner server encountered a disk full condition, is was possible for both partners to hang. This has been fixed so that the partner that encounters the disk full condition stops immediately. The other server should be able to continue as the primary or take over as the primary. Taking over requires that the primary and mirror were synchronized. ================(Build #3653 - Engineering Case #706158)================ A High Availability mirror server could have crashed when starting up or restarting when it was in the "determining mirror role" phase. The primary server must also have had a read-only scale-out copy node connected to it, and a transaction log rename was being performed on the primary server. This has been fixed. ================(Build #3650 - Engineering Case #704453)================ Execution of the system function USER_NAME() in a login check stored procedure (which is set through the login_procedure database option) could have caused a server crash. This would have occurred when using server-side connection pooling, and has now been fixed. ================(Build #3647 - Engineering Case #705557)================ In rare timing dependent cases, it was possible for a server that was the parent of a scale out copy node, or the primary in a scale out system, to incorrectly fail requests with a thread deadlock error. It was also possible (but less likely) for the parent or primary to hang. The thread deadlock and hang were more likely when the scale out copy node could connect to the parent or primary, but the parent or primary could not connect back, perhaps due to an incorrect connection string for the copy node server mirror, or due to a firewall issue. This has been fixed so that the server no longer hangs and thread deadlock is much less likely. ================(Build #3647 - Engineering Case #705543)================ In a mirroring system, it may have been possible for a copy node to connect to its parent and report that it was connected, but not receive log pages. This has been fixed. If a copy node lost its host name because of a network problem at any point, the copy node's parent would have been unable to connect to the copy node. This would have appeared in the logs like the copy node connected to the parent without any problems, but the parent would have been unable to connect back. The parent would then drop the connections and the copy node would have made the connection again, causing an infinite cycle that caused the copy node to be unable to stay connected or receive log pages. This has been fixed. If a copy node tried to connect to its parent, but was unable to resolve the parent's host name during connection due to network problems, the copy node would have connected to the primary and never tried to connect to its parent again. This has been fixed. ================(Build #3647 - Engineering Case #702423)================ While a copy node server was shutting down or restarting a mirrored database, the database may have made connections to the copy node's parent. This has been fixed. The copy node will no longer make connections to its parent while the database is shutting down or restarting. ================(Build #3639 - Engineering Case #704649)================ In a mirroring system, it is possible for a server to be unable to start mirroring because its log does not match the one on its parent. Previously, a message would have been printeded to the console indicating that a log mismatch had occurred, with no further information. This has been corrected so that now there is more information printed to the console of its parent that gives further details. ================(Build #3638 - Engineering Case #704654)================ Creation of SQL Anywhere web services is not permitted on the utility_db. An HTTP request attempting to access the utility_db may have caused the server to crash, rather than being rejected with a "404 'Not Found'" status. This has been fixed. ================(Build #3632 - Engineering Case #704016)================ The server could have crashed if it was serving as a mirror server and became the primary, and a stored procedure referencing a catalog table was executed both before and after the transition. There is no known workaround. This has been fixed. ================(Build #3623 - Engineering Case #703079)================ If there were connections on the mirror database, or a copy node for a mirror database, that were modifying a temporary table at the same time as the transaction log was renamed, then the copy node or mirror could have failed in timing depending cases. In particular, the mirror server or copy node could have crashed or the transaction log on the mirror server or copy node could have been corrupted. This has been fixed. ================(Build #3623 - Engineering Case #696467)================ In very rare circumstances, the database server could have consumed 100% of 1 CPU when shutting down, or when stopping a database. This problem has now been fixed. ================(Build #3620 - Engineering Case #702931)================ In very race cases, the server would have consumed 100% CPU usage while attempting to stop a database. For this to have occurred, the database being stopped needed to make heavy use of scheduled events. This has been fixed. ================(Build #3617 - Engineering Case #672447)================ Under very rare circumstances, frequent transaction log renames may have left small portions of logs that overlapped. This has been fixed. ================(Build #3616 - Engineering Case #702731)================ In rare, timing dependent cases when using High Availability or Read-Only Scale Out, it may have been possible for the server to crash, hang, behave in unexpected ways, or have an incorrect state. This has been fixed. ================(Build #3613 - Engineering Case #698526)================ Windows 7 and Windows 2008R2 support systems with more than 64 logical processors; however, it does so by partitioning them into "groups" with no more than 64 processors in each group. Unless an application takes additional measures to take advantage of multiple processor groups, the application will execute only within one processor group and be unaware that other processors are available. Previously, SQL Anywhere would only recognize and utilize the processors in the group to which it was assigned by the OS at startup, but now SQL Anywhere recognizes and supports all processors on Windows 7, Windows 2008R2. For more information on Windows processor groups, see the following: http://blogs.msdn.com/b/saponsqlserver/archive/2010/09/28/windows-2008-r2-groups-processors-sockets-cores-threads-numa-nodes-what-is-all-this.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dd405503 In addition to supporting more than 64 processors on Windows, SQL Anywhere now uses the hardware topology as reported by Windows for license enforcement on all supported versions of Windows except Windows 2003 and Windows XP 64-bit edition where the operating system is known to misrepresent the actual topology. Previously, SQL Anywhere relied solely on its own hardware detection on x86 and x64 Windows platforms. By relying on the topology reported by Windows, SQL Anywhere will have a more consistent view of the topology when running in a VM. These processor topology changes include fixes on other platforms too. On Solaris prior to this change, if the standalone engine was run within a processor set it would bind itself to a single random processor in the set. Now if the standalone engine is run within a processor set, it binds to the lowest numbered processor in the set. Outside of a processor set, the behaviour has not changed: we bind to the lowest processor that is not bound to any set. Also on Solaris, the database server considered processors that were online but non-interruptible as offline. SQL Anywhere would not bind to such a processor. This problem has also been fixed. SQL Anywhere now properly avoids processors that are offline when the server starts; however, no attempt is made to adapt to processors that are taken offline or brought online during runtime. ================(Build #3606 - Engineering Case #701170)================ In rare timing dependant cases, dropping the mirror server definition for an arbiter in a mirroring configuration could have caused the primary server to hang. This has been fixed. ================(Build #3605 - Engineering Case #687840)================ The initial primary mirror server could have crashed or not correctly processed requests in rare timing dependent cases after executing the "ALTER DATABASE SET PARTNER FAILOVER" statement. This problem could have also occurred when a preferred partner server became available after being disconnected. This has been fixed. ================(Build #3604 - Engineering Case #701477)================ A SQL Anywhere server may have hang on shutdown with 100 percent CPU usage if HTTP requests were concurrently in process. This has been fixed. ================(Build #3597 - Engineering Case #700903)================ In a read-only scale-out setup, it was possible for adding a copy node using "CREATE/ALTER MIRROR SERVER ... USING AUTO PARENT" to fail with the error "Cannot assign automatic mirror server parent", if there were no connected servers that had available spaces in its fan-out. For example, if the root server had ten children and had a fan out of ten, all of which were disconnected, adding another server would fail. This has been fixed. Under these circumstances, the new server will be added as a child of the auto add server. Auto-parenting uses sa_mirror_server_status() to determine what servers are connected. In a read-only scale-out setup, it was possible for sa_mirror_server_status() to report a copy node as connected when it was actually shut down. This would have happened when the copy node and its parent were shut down in quick succession. This has been fixed. Now, the copy node will appear as connected for up to two minutes, at which point the server will be marked as disconnected. ================(Build #3597 - Engineering Case #700882)================ If a high availability mirror, or read-only scale-out copy node, needed to restart its database, it could in rare timing dependent cases caused the server to crash. This has been fixed. ================(Build #3596 - Engineering Case #700309)================ If there was an apostrophe in a user name or table name, a verbose unload (dbunload -v or an unload in Sybase Central) would have failed, and would have reported a syntax error similar to the following: ***** SQL error: Syntax error near 'xxx' on line 1 Also, during reload, extra apostrophes would be displayed in progress messages containing table, index, view, procedure or trigger names. This problem has been fixed. ================(Build #3595 - Engineering Case #700426)================ If files were opened concurrently by two threads of the same process on Windows Mobile / Windows CE devices, the two threads could have been assigned the same POSIX file handle number and IO could then have been directed to the wrong file. This problem, given the nature of Windows Mobile devices, was very unlikely to occur and has been fixed. Also, a structure used to query the OS version on Windows Mobile / Windows CE devices was not initialized correctly; however, it is not believed ever to have caused a problem. This problem has also been fixed. ================(Build #3592 - Engineering Case #700287)================ A security issue with Remote Data Access has been fixed. ================(Build #3592 - Engineering Case #695788)================ In rare, timing dependent cases, the server may have failed fatal assertion 101412 - "Page number on page does not match page requested". This has now been fixed. ================(Build #3591 - Engineering Case #699667)================ If an application made a Java external environment call that returned a SQLException on a JDBC statement, then the next call to the Java external environment would have returned with a NullPointerException if there are no other Java calls in between. This has been fixed. ================(Build #3591 - Engineering Case #693917)================ If a copy node in a mirroring setup became unresponsive, it was possible for its parent to hang. This has been fixed. ================(Build #3589 - Engineering Case #700008)================ Under rare circumstances, the server may have failed assertion 101413 - "Unable to allocate a multi-page block of memory". This was more likely when many (~5 or more) databases were running within a server, and when the server was running with a small cache (less than 100M per database); and was more likely to be seen when starting a new database after the server has been running for some time. This has been fixed. A workaround is to start the server with several extra databases, and then stop them as soon as the server is started. ================(Build #3589 - Engineering Case #689696)================ In exceptionally rare circumstances, the server may have failed with assertion errors 200130, 200131, 200106, 108701, or others, on index pages. The problem was seen on multi-core machines under very high index contention, that included index updates and deletes. This has been fixed. ================(Build #3584 - Engineering Case #699703)================ In a mirroring setup, it may have been possible for the sa_mirror_server_status() system procedure to report that the primary server had a higher log offset than the mirror or copy nodes, and it could have remained this way until the server received further transactions. This has been fixed. The log offset reported for the primary server will now report the offset that has been pushed to any mirrored servers. Note that this was not a problem with the mechanism that pushes log pages to copy nodes and mirror, but with the way the offset was reported. ================(Build #3584 - Engineering Case #697188)================ When starting the database server, an error is reported (by displaying the usage text) if a non-numeric parameter is passed where a numeric parameter is expected. For example: dbeng12 -n jcs -c nonsense However, if the argument to -c started with the a character associated with memory units (k, m, g), no usage text was displayed. For example: dbeng12 -n jcs -c garbage dbeng12 -n jcs -c magic dbeng12 -n jcs -c k This has been corrected so that the usage text is now displayed. ================(Build #3583 - Engineering Case #699537)================ If several Open Client or jConnect applications attempted to connect to a server using the extended encrypted password protocol, then there was a very small chance the server would crash if all of the extended encrypted password connection requests were made at the same time. This problem has now been fixed. ================(Build #3582 - Engineering Case #699387)================ If a server, or one of the SA client utilities, attempted to launch a secondary application (like an external environment), then the secondary application may have failed to start properly when the command line for the secondary application contained characters that were not 7-bit ASCII. This problem has now been fixed. ================(Build #3582 - Engineering Case #699214)================ In a mirroring setup of servers running on multiple host machines, it was possible for the system procdure sa_mirror_server_status() to return incorrect information if the hosts did not have the exact same time. In particular, it was possible for it to appear that some servers were not receiving log pages, even if they were up to date. This has been fixed. The "last_updated" column in the table will always report the time relative to the server named in the "server_name" column. ================(Build #3579 - Engineering Case #699022)================ If a server was started with the "remote_data_access" secure feature turned on (see -sf command line option), and an application attempted to use the secure feature and subsequently received an error indicating that Remote Data Access was disabled, then any subsequent remote calls would incorrectly have returned a 'cursor already open' error. This problem has now been fixed. ================(Build #3578 - Engineering Case #693111)================ On Windows Mobile / CE, database files were not always properly flushed when necessary. The file metadata was the most likely data not to have been flushed, and assertion failure 201129 (File shorter than expected) was the most likely corruption to be seen in the event of a full power outage (eg if the CE device battery runs out). This problem has been fixed. Also, the server's '-u' (use buffered IO) command line switch was ignored on Unix platforms that supported direct IO. This problem has also been fixed. ================(Build #3577 - Engineering Case #697936)================ A statement could have failed with an error (Assertion 106104 failed) if the statement contained an aggregate function AGG( agg_arg ) where: - agg_arg was a complex expression - a complex sub-expression of the agg_arg was used in the WHERE (or in an ON condition) - the optimizer selected an execution strategy involving "distinct-by-rowids" (for example, there was an EXISTS subquery) This problem has been fixed. For example, the following query could have caused the SELECT statement to fail with the assertion failure error: create table T_DBR_1( x int ); create table T_DBR_2( x int ); insert into T_DBR_1 select row_num from sa_rowgenerator(1,10); insert into T_DBR_2 select row_num from sa_rowgenerator(1,100); commit; select count(*), sum( complex_expr1+2 ) from ( select case R1.x*10 when 11 then R1.x end case complex_expr1 , 99+R2.x as complex_expr2 from T_DBR_1 R1 left join T_DBR_2 R2 on R1.x = R2.x where exists ( select * from dbo.rowgenerator R3 where R3.row_num+1 = R1.x ) ) D where complex_expr1 <> 12 or complex_expr2+2 <> 11 ================(Build #3575 - Engineering Case #698386)================ The Server could have hung in very rare cases if a connection made a Remote Data Access request that required a remote connection to be established. This problem has now been fixed. ================(Build #3575 - Engineering Case #696638)================ Using an ALTER TABLE statement to change the length of a string column (char, [long] varchar, [long] binary) that used default INLINE/PREFIX values, would also have explicitly set the INLINE/PREFIX values for that column if there was data in the table. This has been fixed. ================(Build #3574 - Engineering Case #698236)================ The drive_model property could have returned a random string of characters if the OS did not make the corresponding property available. This has now been corrected. ================(Build #3574 - Engineering Case #698219)================ In very rare timing dependent cases, a copy node could have failed to connect to its alternate parent or the root if its parent was unavailable. Additionally, in order for this to have occurred, the copy node's connection to its parent would have had to disconnect for some reason shortly after it connected. This has been fixed. ================(Build #3574 - Engineering Case #698201)================ The Server could have been unresponsive for a long period of time when a backup was starting. This has now been corrected. ================(Build #3568 - Engineering Case #697593)================ If a row was inserted while a REORGANIZE TABLE process was running, and the inserted row's primary key was greater than the highest primary key at the time the REORGANIZE started, the server could have possibly entered into an infinite loop and consumed 100% of 1 CPU without terminating. The operation could, however, be cancelled. This problem has been fixed. ================(Build #3567 - Engineering Case #697440)================ The server may have hung on shutdown if an HTTP client procedure was still active. This has been fixed. ================(Build #3567 - Engineering Case #697439)================ On rare occasions a time-out of a SQL Anywhere web client procedure may have caused the server to crash. This has been fixed. ================(Build #3566 - Engineering Case #697349)================ The SQL Anywhere HTTP server may have crashed due to rare error condition. This has been fixed. ================(Build #3566 - Engineering Case #697235)================ The changes for Engineering case 695216 introduced problems with certificate files (for example, supplying an ECC certificate when an RSA certificate was expected) which would have yielded the error message "An identity password must be specified", even if a password was specified. This has been fixed. In this example, the correct error message is now "An ECC certificate was supplied where an RSA certificate was expected.". ================(Build #3564 - Engineering Case #685156)================ The server may have crashed if a procedure debugger connection disconnected before a debuggee connection was able to get attached to the debugger. This has been fixed. ================(Build #3559 - Engineering Case #696816)================ Transaction log corruption could have occurred at the mirror or copy nodes of a high availability or read-only scale-out system if the following sequence of events took place: 1) The transaction log was renamed (and a new one started) at the end of a backup of the primary 2) The mirror or copy node caught up and applies some operations from new transaction log 3) The mirror or copy node lost connection with its partner or parent 4) The mirror or copy node reestablished connection with its partner or parent Note that if the mirror or copy node restarted prior to reconnecting, corruption would not have occurred. If corruption did occur, an 'invalid transaction log' assertion failure on the mirror or copy node was the most likely outcome. This problem has been fixed. Also, if a copy node (call it CN) has a parent that was not the primary (call it NP), it was possible for CN to stop applying transactions altogether. CN would have remained running as a read-only node but it would not have applied transactions until the database was manually restarted. For CN to enter this state, the following sequence of events must have occurred: 1) CN and NP become disconnected or CN just wasn't running yet 2) NP renamed the transaction log and started a new one (which happens as a result of copying actions performed at the primary) 3) CN and NP reconnect (or CN was started) In this case, CN will now display a "Recovery complete" message in the console log. ================(Build #3556 - Engineering Case #696394)================ Execution of a procedure with a very large argument list may have crashed the server. The crash would have occurred if statement needed to be copied (e.g. a remote server statement or a SELECT INTO statement), and a server worker thread ran out of stack. This has been fixed. ================(Build #3551 - Engineering Case #695095)================ When executing a REORGANIZE TABLE statement, the server could have unnecessarily allocated an amount of memory that was proportional to the number of rows in the table. These allocations could have affect performance, and could have caused the cache to grow or, if the cache grew to its limit, could have caused a 'dynamic memory exhausted' failure. This problem has been fixed. ================(Build #3549 - Engineering Case #695774)================ Attempting to execute a grouped query with a complex ORDER BY expression could have failed with the error: "Assertion failed: 106105 Unexpected expression type ..". This would have occurred if the complex ORDER BY expression referenced a base table column from the GROUP BY clause - such as "T.X +1", where T.X is a base table column in the GROUP BY clause; and the base table column T.X was eliminated from the GROUP BY clause based on functional dependencies. This has now been corrected. ================(Build #3549 - Engineering Case #695242)================ On some systems with multiple physical processor packages (ie multiple sockets) using certain Intel x86/x64 processors, including Intel Xeon E5630, the detection of processor geometry could have been incorrect. Too few packages would have been detected but the correct number of logical processors would still have been detected (with some assigned to the incorrect package). This problem was similar to, but different from, Engineer case 666639, and has now been fixed. ================(Build #3549 - Engineering Case #695082)================ Execution of a query with a query block with a FROM clause that was empty, or contained only the DUMMY table, could have crashed the server if the WHERE clause of this query block contained an EXISTS() predicate which could have been flattened. This has been fixed. ================(Build #3548 - Engineering Case #695909)================ Attempting to upgrade a version 10.x database using a version 11.0.0 or later server would likely have failed with the error: "Item 'SYSCAPABILITYNAME' already exists" error. This problem has now been fixed. ================(Build #3547 - Engineering Case #695762)================ The ALTER SERVER server CONNECTION CLOSE statement was a DDL statement that could not be executed in a read-only database. This has been fixed so that the statement is now executable in a read-only database, and no longer does an automatic commit. ================(Build #3547 - Engineering Case #695495)================ When connected to an older 10.x database, creating a remote server and then attempting to utilize the remote server would likely have caused an incorrectly foreign key violation error. This problem has now been fixed. ================(Build #3547 - Engineering Case #694933)================ Execution of a statement could have crashed the server, or returned incorrect results, if the statement contained derived tables with INSERT, DELETE, UPDATE, MERGE query blocks, and either the updated object was a simple updatable view, or the statement was used inside stored procedures, function, triggers, views, or batch statement. This has been fixed. ================(Build #3546 - Engineering Case #695633)================ Physical plan operators, such as base table sequential scans and joins, could not have be parallelized if an IN filter predicate belonged to that operator. This potentially could have caused performance degradation from earlier version where such operators could have been parallelized. This problem did not prevent the rest of the plan from being parallelized. For example, for a query with four tables and an IN predicate referencing only one of the tables, only the table referenced in the IN predicate could not have been parallelized, while the two joins joining the rest of the three tables could have been parallel joins. This has been fixed. ================(Build #3541 - Engineering Case #695216)================ If the server was started with a TLS/HTTPS identity file that required a password, but none was supplied, an unhelpful error message was given ("Error parsing certificate file, error code 20763"). This has been fixed; the error message is now "An identity password must be specified". ================(Build #3541 - Engineering Case #695213)================ When running on Windows systems, the server would have returned the value of property('MachineName') truncated to 15 characters. This has been fixed so it will now return the full name. ================(Build #3540 - Engineering Case #695084)================ Execution of a CREATE PROCEDURE statement with a number a parameters that exceeded the limit would not have failed. Now, execution of such a statement will fail with the error: SYNTACTIC_LIMIT 54W01 -890. Note, the maximum number of parameters allowed is a function of the database page size. For example, for a page size of 4k, the limit is ~3620096 parameters. ================(Build #3539 - Engineering Case #694479)================ Attempting to use a server or the Java-based administration tools with large amounts of memory on a Linux system with kernel versions between 3.0 and 3.3 may have resulted in improper system memory calculation. This problem could have manifest itself in many ways. The server may have reported insufficient memory, or may have reported a very low value for its cache size, even when a large amount of system memory is available, e.g.: 8192K of memory used for caching Minimum cache size: 8192K, maximum cache size: 8192K The Java-based administration tools may also report the following error: Invalid maximum heap size: -Xmx0m This has been fixed. ================(Build #3537 - Engineering Case #694594)================ In some cases, statements that included a DML statement in the FROM clause could have missed some checking that is normally done on statements. This has been fixed. ================(Build #3537 - Engineering Case #694593)================ When evaluating the DATENAME() builtin function, it was possible that the server could have crashed. This potential problem has not been observed, and it is now fixed. ================(Build #3537 - Engineering Case #694592)================ Evaluating particular forms of expressions in procedural code could have caused a server crash. This has been fixed. ================(Build #3537 - Engineering Case #694591)================ When the search condition in an IF expression evaluates to UNKNOWN, the IF expression should return NULL (not the "else" branch). For example, the following statement returns (NULL,NULL) select a , if a=1 then 1 else 0 end if as b from openstring(value ',') with( a int ) D If an IF expression was used as an argument to a CASE expression where the predicate is known at open time, then the IF expression was incorrectly evaluated so that UNKNOWN was treated as FALSE, leading to the ELSE branch being returned instead of NULL. For example, the following statement incorrectly returned (NULL,0,0) instead of (NULL,NULL,NULL) select a , if a=1 then 1 else 0 end if as b , case when 1=1 then b end case c from openstring(value ',') with( a int ) D A similar problem could occur with an IF expression used as an argument to NULLIF. This problem has been corrected. ================(Build #3537 - Engineering Case #666132)================ In some cases, expressions could have been evaluated with incorrect domain information. The affected information included: - precision and scale for NUMERIC values - length for string values - differences between string types (e.g., char/varchar/long varchar or binary/varbinary/long binary) For example, the following statement would have incorrectly returned: a a_string 1.0000 "1.0000" select case when dummy_col=0 then 1 else cast(2 as numeric(10,4) ) end case a , cast( a as varchar ) a_string from sys.dummy However, the following statement would have incorrectly returned: a a_string 1 "1" select case when 0=0 then 1 else cast(2 as numeric(10,4) ) end case a , cast( a as varchar ) a_string from sys.dummy The incorrect behaviour affected expressions that were partly or fully evaluated at query open time or in procedural code, and affected IF, CASE, NULLIF, ARGN, COALESCE and some other related expression types. This problem has now been fixed. ================(Build #3536 - Engineering Case #694143)================ When using the CREATE ENCRYPTED TABLE DATABASE statement on a fully encrypted database, the resulting database had all table and index pages encrypted, rather than only the pages for encrypted system tables. This has been fixed. ================(Build #3535 - Engineering Case #694491)================ If the server's main heap was extremely large and fragmented, and/or an extremely large number of SQL objects had been referenced (ie a large number of table names, column names, etc), checkpoints could have been slower than necessary by using more CPU than necessary. Even in extreme cases, the delay might have been only a few seconds and might generally go unnoticed for normal checkpoints; however, execution of a long sequence of DDL statements that performed implicit checkpoints would have been observed as extremely slow. The problem was caused by some in-memory cleanup that must be performed by the server periodically and was performed on every checkpoint; however, this cleanup doesn't need to be performed when checkpoints are executed in quick succession. Now, SQL Anywhere will perform the cleanup during checkpoint at most once every twenty minutes. ================(Build #3534 - Engineering Case #694137)================ There were two problems with attempting to encrypt a table using the ALTER TABLE <table_name> ENCRYPTED statement: 1. Executing the ALTER TABLE statement incorrectly succeeded on a database that did not support encrypted tables (i.e. one that is not encrypted or fully encrypted). 2. If a database was created with version 10 to support encrypted databases, but was being executed on a version 11 or later server, the same ALTER TABLE statement would have fail with error -1047 "This database does not support encrypted tables". These problems have now been fixed. In the first case, the ALTER statement will now return error -1047, and in the second case, the ALTER statement will succeed. ================(Build #3534 - Engineering Case #692307)================ In blank padded and case insensitive databases using INSERT ON EXISTING UPDATE when updating a value which was logically equivalent but physically different could have failed due to constrain violations. This has been fixed. The server now does constraint checking using logical representations. ================(Build #3533 - Engineering Case #694002)================ In extremely rare timing dependent cases, the server could have hung when the db_property function was called. The only known case of this occurring involved mirror servers, but this problem may have affected servers not involved in mirroring. This has now been fixed. ================(Build #3533 - Engineering Case #693938)================ In very rare circumstances, the server could have become deadlocked or hung. In some cases , database mirroring would have been involved and very specific timing was required; however, the problem could have occurred in other situations and would also have required very specific timing. This problem has now been fixed. ================(Build #3532 - Engineering Case #693819)================ When the server was running with the -fips command line option (Requires that only FIPS-approved algorithms should be used for strong database and communication encryption), it was still able to start simple-encrypted databases. This has been fixed, such databases will now fail to start. ================(Build #3531 - Engineering Case #693670)================ When a copy node server in a mirroring setup was not running an arbiter or partner server for another database, any connections from a server running mirroring to the copy node would have consistently dropped and reconnected for no apparent reason. This has been fixed. ================(Build #3530 - Engineering Case #691879)================ If an IPv6 address was used in the HOST or LINKS parameters of a connection string, on a machine that did not support IPv6, the client would have displayed the message "No IP address found for <IPv6 address>". This has been fixed. The error message will now read "No valid host names or addresses given". If the LOG= parameter is also used, the message "Ignoring IPv6 address <IPv6 address>" is written to the log for each IPv6 address found. ================(Build #3528 - Engineering Case #693418)================ A partner mirror server could have hung when stopping the mirrored database in rare timing dependent cases after executing an ALTER MIRROR SERVER for the arbiter server. This problem was introduced by the changes made for Engineering case 688291 and has now been fixed. ================(Build #3528 - Engineering Case #687999)================ In rare timing dependent cases, a transaction which was successfully committed on a primary server could have been lost. In order for there to have been a chance of this occurring, all of the following needed to be true: - the application was connected to a primary server that lost quorum (the server lost the connection to both the mirror and arbiter servers) - the application stayed connected to this server (the old primary server) even though the network connection to other servers dropped - the application was in the middle of committing a transaction between the time that the old primary server lost its connection to the mirror and arbiter server, and when the old primary server restarted as the new mirror server because it lost quorum - the old mirror server took over as the new primary (the mirror server must have been able to connect to the arbiter server for this to occur) This problem has now been fixed. ================(Build #3527 - Engineering Case #690768)================ In order to prevent the possibility of having two primary servers running at the same time when there was no connection between the two partners, the arbiter would have refused a role switch from "mirror" to "primary" if it had a connection to the current primary. If a mirroring partner server was unable to connect to its partner server after the connection dropped, it was possible for the server to be unable to decide whether to take the role of primary or mirror server. A work around for this problem was to use the syntax "ALTER DATABASE <mymirroreddb> FORCE START" to force the database to start up as primary, and should only have been used if there was no other primary server running. This problem has been fixed, and the server should now be able to decide to take a role of either "primary" or "mirror" server. ================(Build #3526 - Engineering Case #693135)================ On Mac OS X, servers or client applications that made many TCP/IP connections requiring broadcasts to other servers could have sent many more UDP broadcast packets than required. In extreme cases, this could have flooded the network with UDP packets, affected an entire subnet's performance. Connection strings such as links=tcpip (with no broadcast=) or host=hostname (with no port) use broadcasting to other servers and could have had this problem. This has been fixed. ================(Build #3524 - Engineering Case #692899)================ The changes for Engineering case 691204 introduced a problem where, in rare timing dependent cases, a high availability server or a copy node server could have crashed when shutting down, or when a DROP MIRROR SERVER statement was executed for a connected copy node. ================(Build #3524 - Engineering Case #692867)================ The changes for Engineering case 677962 introduced a situation where, in rare timing dependent cases, a server could have hung when it was shutting down a database which was a high availability mirror or a copy node. This has been fixed. ================(Build #3524 - Engineering Case #692583)================ In some rare cases, the server would have hung when a connection queried another connection's LastStatement property. This has been fixed. The work-around is to not use the -zl command line option, or to turn off the RememberLastStatement server option. ================(Build #3522 - Engineering Case #692617)================ When the dbisqlc OUTPUT_FORMAT option 'ASCII' was renamed to 'TEXT' in version 11.0.0, the ability to generate the old format that dbisqlc called 'TEXT', which was fixed-width with column headers, was lost. Now, setting the OUTPUT_FORMAT to 'COLUMNS' will generate the old TEXT format. ================(Build #3519 - Engineering Case #692216)================ A problem with TDS secure logins has been corrected. ================(Build #3518 - Engineering Case #690075)================ Events run on temporary connections, but those connections did not always have the correct locale information. In particular, functions such as errormsg() would have returned strings encoded in the OS character set rather than in the database character set. This problem has been fixed. ================(Build #3517 - Engineering Case #692013)================ If a copy node in a read-only scale out setup was converted to be a partner mirror server, the primary mirror server could not have been restarted. This has been fixed. ================(Build #3516 - Engineering Case #691662)================ DELETE query blocks (e.g. a main query block in a DELETE statement or a query block of a DML DELETE derived table) were restricted from flattening subqueries defined in the WHERE clause. An exception was that subquery flattening was done if and only if the cardinality of the DELETE query block was not affected. The restriction has now been removed, which may significantly improve the performance of some DELETE statments. With this change, any subquery which qualifies for flattening is flattened similar with SELECT/UPDATE query blocks. ================(Build #3515 - Engineering Case #690133)================ When connected via jConnect or Open Client, retrieving the metadata of a long nvarchar or ntext column may have incorrectly indicated that the column was a long binary value. This problem has now been fixed. ================(Build #3513 - Engineering Case #665176)================ The NEXTVAL operation on sequences did not return an error when executed in a read-only database. This has been corrected. The operation should return an error because the sequence value cannot be updated in the catalog table. ================(Build #3512 - Engineering Case #691322)================ The ENCRYPTED KEY option of the OPENSTRING statement was recently extended to permit the encryption key to be specified as a variable (see Engineering case 688888). In certain scenarios this feature could have caused either a crash, or an inappropriate error - SQLCODE -851 "Decryption error: Missing encryption key". This has been fixed. ================(Build #3512 - Engineering Case #691204)================ In a high availability mirroring configuration, it is possible to drop the mirror server definition for a partner server currently acting as a mirror. If the dropped server later tried to connect to the primary server as a copy node, the primary server would still have thought the server was its partner, rather than a copy node. This has been fixed. Also, in a read-only scale out mirroring configuration, it is possible to drop the mirror server definition for a copy node. If that copy node was connected to the primary server at the time of the drop, the mirror server definition would not have been removed from the system tables. This to has been fixed. ================(Build #3509 - Engineering Case #691304)================ The changes for Engineering case 686407 introduced a problem for shared memory connections where calling connection_property( 'LastReqTime' ) could have reported an inaccurate value. This has been fixed. ================(Build #3508 - Engineering Case #691178)================ Attempting to make a Kerberos connection with a large Kerberos ticket could have failed with the error "Kerberos login failed". This would have occurred with a Kerberos ticket size approaching 8K, which was possible if the ticket was part of a large number of Active Directory groups. This has been fixed. ================(Build #3507 - Engineering Case #686428)================ In a mirroring system, it was possible for multiple servers to deadlock, waiting for responses from each other. This has been fixed. ================(Build #3507 - Engineering Case #681739)================ In extremely rare situations, the primary server in a mirroring system could have become deadlocked while attempting to send log pages to the mirror partner. For the problem to have occurred, all request tasks on the primary server must have been blocked and the connection from the primary to the mirror must have been severed while the log pages were being sent to the mirror. This problem has been fixed. ================(Build #3506 - Engineering Case #691036)================ When using the -sf server option to disable certain features other than "database", the CREATE DATABASE statement could have failed. This has been fixed. ================(Build #3504 - Engineering Case #690734)================ The MIN and MAX aggregate functions would have returned an error when using an argument of type "timestamp with time zone" or "xml": Cannot convert timestamp with time zone to a numeric or Cannot convert xml to a numeric Further, using an "numeric" before computing the aggregate. This has been fixed. The MIN and MAX aggregates no longer attempt to cast these types to "numeric". ================(Build #3500 - Engineering Case #690373)================ Statements with virtual tables referencing user-defined functions, and stored procedures which qualify for in-lining, may crashed the server or returned incorrect results. This has been fixed. ================(Build #3500 - Engineering Case #690254)================ When request logging is enabled with ALL or PLAN, the server may have crashed if the following sequence occurred: - Connection A opened a cursor that included fetching rows from a procedure - Connection B dropped the procedure used by connection A - Connection A then closed its cursor This problem has been fixed. ================(Build #3497 - Engineering Case #690114)================ Recovery could have failed if an operation in the transaction log required access to a feature that was secured on the command line via the -sf option. The operation could have entered the log, either by having the operation performed on a server where the feature was not secured, or if security was permitted, on the given connection via the -sk server option and setting the secure_feature_key option to match. The failure would have been displayed as assertion number 100904 "Failed to redo a database operation". This has now been fixed. Note, not all secured features add entries to the transaction log. For example, the READ_FILE secured feature blocks access to xp_read_file which would not get logged; however, the REMOTE_DATA_ACCESS secured feature blocks access to statements such as CREATE SERVER does get logged. ================(Build #3496 - Engineering Case #689614)================ In rare cases in a mirroring system, where a mirror server lagged far behind the primary in applying changes, it was possible for the primary and mirror server to hang. This has been fixed. ================(Build #3494 - Engineering Case #689464)================ The Property() function would have displayed negative values for the server properties 'HttpPorts' and 'HttpsPorts' when the port numbers were above 32768. This has been fixed. ================(Build #3494 - Engineering Case #689193)================ The changes for Engineering case 682512 introduced a problem where stopping a high availability primary server while it was connected to its partner (mirror) server could have resulted in the database not being able to start. Specifically, in timing dependent cases, attempting to restart the primary mirror server could fail with the "Database cannot be started -- <database name> not expecting any operations in transaction log". This has been fixed. ================(Build #3493 - Engineering Case #689657)================ Three new properties have been added: LastCommitRedoPos: This property is available at both the connection-level and the database-level. The value returned is the redo log position after the last COMMIT operation was written to the transaction log by the connection or database. LastWrittenRedoPos: This is a database-level property only. The value returned is the last redo position for which a write was issued to disk. The write is not necessarily synced to the physical medium as it may still be cached by the OS, disk controller or disk drive. LastSyncedRedoPos: This is a database-level property only. The value returned is the last redo position for which a write was issued to disk and the data was synched to the physical medium. Data prior to this position is expected to be present on disk even in the event of a power failure. ================(Build #3493 - Engineering Case #689511)================ In some extremely rare cases, the transaction log may not have been committed to disk when a COMMIT operation was performed. Also, if a transaction only modified temporary tables, it was possible that the transaction log would have been committed to disk although it didn't need to be. These problems have been fixed. ================(Build #3492 - Engineering Case #689315)================ When connected via jConnect or Open Client to a blank padded UTF8 database and a non-nullable char(n) value was fetchesd, the client may have experienced protocol errors if n was less than 3. This problem was introduced by the fix for Engineering case 686183 and has now been fixed. ================(Build #3489 - Engineering Case #687749)================ A query using aggregate functions may have caused a server crash if its select list contained a derived table with an outer reference to the query, and the outer reference did not appear in the queries group by list. At least one of the following conditions must also have been trun: 1) The derived table contained a procedure call in its FROM clause and the procedure argument expression contained the outer reference. 2) The derived table contained a OPENSTRING clause in its FROM clause and its value expression contained the outer reference. 3) The derived table contained another derived table and the outer reference was inside this other derived table. The below query shows an example of condition 3). select ( select V0.e from ( select T3.e from T3 where T3.e = T2.c ) V0 ) c1, max(T1.b) as c2 from T1 join T2 on T1.a = T2.c This problem has been fixed. The engine will now correctly return the error SQLE_INVALID_GROUP_SELECT, since the outer reference column has to be specified in the GROUP BY clause. Specifying the outer reference column in the GROUP BY clause (in the above example: group by T2.c) is also the work around to this problem. ================(Build #3488 - Engineering Case #688788)================ In rare timing dependent cases, if a mirror server was using all available workers, it was possible for the server to hang, or for a mirror database to not restart after loss of quorum. The maximum number of workers is defined by -gnh (in version 12) or by -gn (in version 11). This has been fixed. ================(Build #3488 - Engineering Case #688581)================ In a read-only scale-out system, if the non-primary server (say S) in the read-only scale-out tree had more than ten direct or indirect children, then S's parent could have hung, in rare timing dependent cases. This problem was introduced by changes made for Engineering case 681813, and has now been fixed. ================(Build #3488 - Engineering Case #686791)================ In a mirroring system, if the primary server made changes faster than the mirror server could apply them, and if the connection between the two servers was dropped, in rare timing dependent cases, the mirror server could have hung with 1 CPU at 100%. Stopping the server or the database during the 100% CPU hang would have succeeded. This has now been fixed. ================(Build #3487 - Engineering Case #686407)================ In rare cases where a primary server lost its connections to both the mirror and the arbiter servers as a checkpoint was performed, the next time the primary and mirror servers were connected and attempted to synchronize, the mirror server may have reported the error: 'Database "<name>" mirroring: database is not compatible with primary; files must be replaced' and then stop with the message: 'Database server shutdown due to incompatible files for database mirroring'. This has been fixed so as to reduce the possibility of this occurring. In rare cases this could still occur and the database running on the current primary must be manually copied or backed up to the mirror server so that the server can successfully synchronize again. Note, this extends the changes made by Engineering case 660851. ================(Build #3484 - Engineering Case #688435)================ An IS [NOT] DISTINCT FROM predicate may have been incorrectly evaluated for some data types, such as string datatypes. The incorrect evaluation would have been observed if the predicate was not used in a Hash Join, Merge Join, or as a sargable predicate for a partial index scan. This has been fixed. ================(Build #3483 - Engineering Case #687393)================ Under very rare circumstances, a server could have crashed during backup if many connections are committing transactions at the same time. Live backups were the most likely to suffer from this problem. This has been fixed. No workaround is known. ================(Build #3483 - Engineering Case #685566)================ When a mirror or diagnostics connection to another server was attempted the "Using broadcast address of: ..." message was logged to the console when it should not have been. This has been fixed so that this message is only logged if the -z server option is used. ================(Build #3482 - Engineering Case #688019)================ When connected to the utility database (utility_db), if a statement that was not supported was prepared, the PREPARE may not have generated an error when it should have. This has been fixed so that the unsupported prepare now returns the error "Permission denied: you do not have permission to execute a statement of this type." ================(Build #3482 - Engineering Case #687998)================ While extremely rare, the server may have crashed while executing a query that referenced proxy tables. The problem has now been fixed. ================(Build #3481 - Engineering Case #687973)================ Calling the system procedures sp_remote_tables or sp_remote_columns for an ASE or MS SQL Server remote server would have failed if the catalog argument was specified as NULL. This problem was introduced in 12.0.1 GA and has now been fixed. ================(Build #3480 - Engineering Case #686575)================ Very complex disjuncts in the WHERE clause were not able to be used for index scans. Now, IN predicates are generated if at all possible. These new IN predicates can then be used to drive an index scan improving the execution times for this type of query. ================(Build #3479 - Engineering Case #687773)================ In extremely rare cases, the server could have crashed when request level logging was enabled. The problem has now been corrected. ================(Build #3479 - Engineering Case #687747)================ If the server was shutdown while a mirrored database was in the process of starting on the server, the server could have crashed. This has been fixed. ================(Build #3479 - Engineering Case #686822)================ If an ALTER PUBLICATION or a DROP PUBLICATION command was executed by the MobiLink client inside the sp_hook_dbmlsync_schema_upgrade hook, it was possible for the command to have thrown an 100904 assertion ("Failed to redo a database operation ...") if the database server had to replay the operation during recovery. This has now been fixed. ================(Build #3479 - Engineering Case #665966)================ A query whose execution used a parallel HashGroupBy operator, may have returned an incorrect result if the MIN or MAX aggregate function was used, or may have caused the server to crash if an aggregate function was used on a numeric or string expression. This has been fixed. A workaround for the problem is to set the database option max_query_tasks to 1. ================(Build #3478 - Engineering Case #687761)================ The dbisqlc utility would have reported a syntax error whenever it tried to execute a 'STOP SERVER' statement. This problem has been fixed. The statement used to be 'STOP ENGINE ...' and dbisqlc did support (and continues to support) that variant; however, it was never updated when the statement was changed to 'STOP SERVER'. ================(Build #3478 - Engineering Case #687596)================ When shutting down a server that was running as a Windows service, the server could have crashed. Although the problem was only seen when shutting down an interactive service on Windows XP by using the 'Shutdown' button on the server window, the problem was a timing issue and could have occurred when the server was shut down in other ways. The problem has been corrected. ================(Build #3477 - Engineering Case #687447)================ In rare, timing dependent cases the server could have had incorrect behaviour when a connection had at least 20 prepared statements with cached prepared statements, or at least 20 cursors open. The incorrect behaviour could have varied, and the only known symptom was incorrectly returning the error "Resource governor for 'prepared statements' exceeded", but it may also have been possible for server crashes or assertions to have occurred. This has now been fixed. ================(Build #3477 - Engineering Case #687411)================ When an ALTER DATABASE UPGRADE statement is executed, events are suspended in order to avoid having active connections while upgrading. Once upgrading is done, events are re-enabled. Running simultaneous ALTER DATABASE UPGRADE statements could have left events permanently suspended on the server. No events on any database would have been executed. This problem has been fixed. Also, when upgrading a single database, the server suspended events for all databases that were running. This was unnecessary and the server now only suspend events in the database that is being upgraded. ================(Build #3476 - Engineering Case #687264)================ The server's http log did not display the query component of the request URI. This has been fixed. ================(Build #3476 - Engineering Case #686202)================ For recurring scheduled events, there were several errors in how end times were computed: 1. If an end-time was specified (i.e., "BETWEEN start-time AND end-time"), then: a. Seconds were being ignored. For example, an end-time of '23:59:59' was being interpreted as '23:59:00'. b. The end-time was tested as an exclusive endpoint rather than an inclusive endpoint, contrary to the documentation of the BETWEEN ... AND clause. For example, the schedule "BETWEEN '9:00' AND '17:00' EVERY 60 MINUTES" would cause the event to fire last at 16:00, rather than 17:00. 2. If an end-time was not specified (i.e., "START TIME start-time"), the end-time for each day was implicitly being treated as '23:59:00' exclusive, instead of '23:59:59' inclusive. The combined effect of these error were that no scheduled events would fire in the minute from 23:59:00 until midnight. This has been fixed. ================(Build #3476 - Engineering Case #685149)================ When execution of a stored procedure or user defined function was cancelled by the user and an error handler within the stored procedure was invoked, an incorrect SQLCODE (0 or the error code of a different error that occurred prior to the cancel) could have been reported. An incorrect error message could also have been reported by the ERRORMSG() function. This has been fixed. ================(Build #3475 - Engineering Case #681759)================ The database property 'PartnerState', as returned by db_property, would have returned inaccurate results for databases that had no mirroring definitions, but were running with mirroring enabled. This has been fixed. Now, db_property('PartnerState') will return "null" if no partner has been defined. ================(Build #3472 - Engineering Case #686790)================ When the server was starting a database, statistics collection may be performed on the database tables even though the statistics are not updated. This has been corrected so that statistics collection is now disabled on a database that is being started. ================(Build #3471 - Engineering Case #686561)================ If any of the following occurred while starting a database, the server could have crashed, although it would only occur in very rare situations: 1. An error was encountered while starting the database 2. Logs were being applied to a database at startup with -a, -ad or -ar but the -as switch was not used 3. The engine was requested to stop while the database was starting. This has now been fixed. ================(Build #3471 - Engineering Case #686183)================ If an application using the UTF8 character set connected via jConnect or Open Client to a blank padded non-UTF8 database and fetched a non-nullable char(n) value, then the returned value would have been blank padded to n*3 bytes. This problem has now been fixed. ================(Build #3471 - Engineering Case #681921)================ If an application had an insert trigger on a local table that referenced a proxy table, then the trigger could have failed if the remote query involved the new row values for the trigger. This problem has now been fixed. ================(Build #3471 - Engineering Case #670470)================ If the server received an OS error for a disk write to the database file, transaction log file or temporary file, and the written size was zero, then it may have incorrectly reported a disk full error. This has been fixed. As well, disk write error messages will now print the file name and the OS error code. ================(Build #3470 - Engineering Case #686409)================ If an IPv6 address that included a port number was specified in square brackets, rather than parenthesis, the server or client libraries would not have parsed it correctly. For example, if a connection string included ";HOST=[<ipv6_addr>]:<port>", the error "No IP address found for [<ipv6_addr>]:port." This has been fixed. Note, this applies to addresses in connection strings (using the LINKS or HOST parameters), the -x and -xs switches on the server, and URLs in web service procedures. ================(Build #3469 - Engineering Case #686204)================ Cancelling an external environment call that was in the process of returning a large result set, could in very rare cases have caused the server to crash. This problem has now been fixed. ================(Build #3469 - Engineering Case #685574)================ When unloading a database, ALTER INDEX ... RENAME statements were not being added to the reload.sql file when an index or unique constraint had been renamed. This has been fixed. ================(Build #3469 - Engineering Case #684769)================ In very rare cases the server may have crashed when upgrading a pre-version 12 database to version 12, if the database did not use a transaction log file. This has been fixed. ================(Build #3468 - Engineering Case #686203)================ Cancelling an external environment call call immediately after making the external call, could in very rare cases have caused the server to crash. This problem has now been fixed. ================(Build #3468 - Engineering Case #686036)================ Attempting to make a Remote Data Access connection to an Oracle database, using an ODBC driver other than the iAnywhere Oracle ODBC driver, could have caused the server to crash when running on a Unix system. This problem has now been fixed. ================(Build #3467 - Engineering Case #686009)================ Under some circumstances SQL Anywhere HTTP logs would have contained an empty URI for the @U log-format place holder. This may have occurred for the following reasons: - HTTP METHOD was not supported, - request URL was malformed, - the HTTP listener specifies that the DBN was required but the database name was not within the URL path. This has been corrected. Now if a request has faulted due to any of the above reasons, the HTTP method (@M) and version (@V) will emit the string "???". The given request line is pre-pended with a ">>>" and emitted for the (@U) format place holder. For example: A request of the form: BLAH /sample/test HTTP/1.0 will emit the following for LogFormat="@M @U @V" "??? >>> BLAH /sample/test HTTP/1.0 ???" ================(Build #3465 - Engineering Case #685733)================ The server could have unnecessarily consumed 100% of one CPU in certain circumstances as described below. These problems have been fixed. - In certain cases when a copy node lost its connection to its parent and then encountered a log mismatch with the parent after it reconnected, a single CPU would remain at 100% utilization indefinitely. - When cancelling a CREATE EVENT statement while processing a procedure profile (sa_procedure_profile, sa_procedure_profile_summary), a single CPU would have remained at 100% utilization until no connections were processing profile information - While waiting for connections to drop when yielding to a mirroring partner, a CPU would have remained at 100% utilization until all connections were dropped. ================(Build #3465 - Engineering Case #684891)================ If a query plan used multiple nested-loops outer joins then a cursor positioning using FETCH RELATIVE 0 may have returned the next row in the forward direction, instead of refetching the current row. This has been fixed. A possible work-around for the problem is to use an insensitive or keyset-driven cursor type. ================(Build #3463 - Engineering Case #685559)================ If a non-recurring event was run on a read-only database, or had the "FOR ALL" clause, indicating it could run on a mirror or copy node, the server could have hung with 1 CPU at 100% after the event ran. Non-recurring events are events with a SCHEDULE clause that does not specify EVERY or ON. This has been fixed. ================(Build #3461 - Engineering Case #685318)================ The values returned in the table_page_cached and ext_page_cached columns of the result set returned by the system procedure sa_table_stats() could have been smaller than the number of pages that were actually cached by the server. This problem has been corrected. ================(Build #3461 - Engineering Case #683525)================ If a partner in a mirroring environment setup that is mirroring more than one database, it is possible to specify more than one mirror state file. If multiple databases were started and configured on the same server without restarting the server after configuration, this could have resulted in the server not being able to get quorum when its partner shut down. This has been fixed. ================(Build #3460 - Engineering Case #685323)================ If the server's ports (-x) or web protocols command line option (-xs) contained certain multibyte characters, the server could have failed to start up and would have displayed the server's usage message or window. This problem has been fixed. ================(Build #3456 - Engineering Case #683717)================ When performing a database upgrade (either via the Upgrade utility (dbupgrad) or via the ALTER DATABASE UPGRADE statement) on a database containing spatial data, the server would have terminated with a the following error: SQL error (-1474) -- SRID 0 is referenced by column ... of table ... This has been fixed. ================(Build #3456 - Engineering Case #680766)================ Execution of a CREATE OR REPLACE SEQUENCE statement would have failed with the error "Sequence <sequence name> already exists" if the sequence already existed. This has been fixed. The workaround is to manually drop the sequence before issuing the CREATE statement. ================(Build #3451 - Engineering Case #682530)================ When unloading a database, the DESC clause was not being added to statements in the reload.sql file when creating Primary and Foreign Keys with a descending sequence. This has been fixed. ================(Build #3450 - Engineering Case #684335)================ An explicit or implicit cursor describe that should have failed could have caused the server to crash. An example of a describe cursor that is expected to fail is if the describe is cancelled. This has been fixed so that server no longer crashes. ================(Build #3450 - Engineering Case #681963)================ If a statement similar to the statement below was used in a stored procedure, function, or trigger, a syntax error may have been incorrectly returned. The statement must have containeds both MATCH and DELETE or INSERT clauses. This has been fixed. For example: create or replace PROCEDURE test1( ) BEGIN ALTER TABLE ixddl6 ADD CONSTRAINT FK_primary FOREIGN KEY (x) REFERENCES ixddl5(pk) match unique simple on delete set null END ================(Build #3450 - Engineering Case #680769)================ When unloading a database, SEQUENCE generator comments were not included in the reload.sql file. This has been fixed. ================(Build #3448 - Engineering Case #684096)================ In timing dependent cases, a read-only scale-out copy node could have crashed or hung. This was more likely if the server was loaded and requests needed to be queued because there were no idle workers (more concurrent tasks than the current multiprogramming level). This has been fixed. ================(Build #3447 - Engineering Case #683947)================ In very rare cases, when a server shutdown was requested via the server console, the server would have shutdown successfully, but the server console would have stayed up. This would only have occurred on Windows machines with multiple processors. This has been fixed. ================(Build #3447 - Engineering Case #683728)================ In some situations, the server may have crashed while executing an ALTER SYNCHRONIZATION PROFILE statement with the MERGE clause. The maximum size of the new profile string was being calculated incorrectly. This has been fixed. ================(Build #3447 - Engineering Case #680767)================ When unloading a database, incorrect CREATE TEXT CONFIGURATION of external term breakers and prefilters were being generated in the reload,sql file. This has been fixed. ================(Build #3446 - Engineering Case #683410)================ A server in a mirroring system could have crashed when another server with many IP addresses was connected. This has been fixed. Note, if a server that does not have this fix, and has many IP addresses, connects to a server with this fix, the fixed server will give a protocol error. ================(Build #3446 - Engineering Case #680779)================ When unloading a database, the ALTER TABLE statement to generate unique constraints in the reload.sql file did not include the CLUSTERED keyword for clustered unique constraints. This has now been corrected. ================(Build #3446 - Engineering Case #680242)================ Procedures with a SELECT statement that called another procedure may have become slower over time. This happened when the SELECT statement generating the result of the inner procedure qualified for a certain type of caching. This has now been fixed. A workaround is to ensure that the SELECT statement inside the inner procedure is not subject to simple query caching. If this slowdown is observed, the workaround can be implemented by adding a predicate that is not a tautology, but which is always known to be true for the data, to the inner select. For example, if a certain column is always greater than zero, adding the predicate col >= 0 is sufficient to avoid the problem. Note that simple predicates such as 1=1 will be detected as data-independent tautologies and removed. ================(Build #3444 - Engineering Case #683707)================ When a copy node was promoted to replace its parent via "ALTER MIRROR SERVER ... ALTER PARENT FROM ...", or internally because a copy node was not responding, siblings of the promoted node did not notice that their parent had changed and would continue trying to reach their original parent. This has been fixed. ================(Build #3436 - Engineering Case #682250)================ In a database mirroring setup using asynchronous mode, the mirror was not responding to pages sent by the primary as quickly as it should, affecting performance. This has been fixed and performance should be improved. ================(Build #3436 - Engineering Case #681813)================ The system procedure sa_mirror_server_status() would have returned incorrect results when run on a copy node server, or a mirror server in a mirroring setup. The procedure was returning results for the server's parent or partner, and could have returned an incorrect status for a server that had been involved in a failover. This has been fixed. The procedure will now return the correct status for the queried server and its children. ================(Build #3435 - Engineering Case #683385)================ If an application that was connected using Open Client or jConnect executed a Transact SQL batch that contained an undefined host variable, then there was a chance the server would have crashed. This has now been fixed so that batch will fail with a "not enough values for host variables" error. ================(Build #3433 - Engineering Case #683170)================ When using a CREATE OR REPLACE MIRROR SERVER server_name AS COPY USING AUTO PARENT statement to convert a mirror server from a partner to a copy node, server_name would have been given an invalid parent and the alternate parent would be lost. This problem has been fixed. ================(Build #3432 - Engineering Case #683025)================ If the connection making an http or https request was closed while the request was still executing, and that request was in turn making a request to a mirror server (for high availability or read-only scale-out), or making a request to a diagnostic server, the server could have hung or fail in some other way. This has been fixed. In high availability or read-only scale-out, if the connection to the primary or parent server was dropped just after the mirror or copy node had determined its role, the mirror or copy node could have failed to start with the errors: "database is not compatible with primary; files must be replaced" and "Database server shutdown due to incompatible files for database mirroring." This has been fixed. Note that attempting to restart the mirror or copy node after receiving this error should succeed in this case. ================(Build #3431 - Engineering Case #681758)================ In a mirroring setup, copy node server console messages often said "mirror" or "partner", causing confusion about the actual role of the server and which server was its parent server. This has ben corrected so that the server console messages for a copy node will now refer to the copy node itself as "copy node", and its parent as "parent". ================(Build #3428 - Engineering Case #682762)================ Changes forn Engineering case 674559 introduced a bug which could have caused a crash on the primary server of a mirroring system when auto-adding a copy node. This problem has been fixed. ================(Build #3428 - Engineering Case #682756)================ If operations on a mirror server created a cycle by committing operations on the primary server (via, for example, an OMNI connection), the primary and mirror servers could have deadlocked on each other and appear to hang. The problem was most likely to have been seen when the mirror server was also attempting to shut down. This problem has been fixed. ================(Build #3427 - Engineering Case #682512)================ If a high availability partner was shutdown while it was the primary, its partner took over as primary, and then the partner that was shutdown was restarted, it could have failed to start with the errors: "database is not compatible with primary; files must be replaced" and "Database server shutdown due to incompatible files for database mirroring." This has been fixed. ================(Build #3425 - Engineering Case #681396)================ If an Unix machine had many network interfaces (hard to say how many), starting the server may have failed. The only error message displayed was "TCPIP communication link not started". This has been fixed. ================(Build #3424 - Engineering Case #682246)================ If an application attempted to cancel a query that involved one or more proxy tables, then the cancel request would have, in some rare cases, been ignored. This problem has now been fixed. ================(Build #3424 - Engineering Case #681765)================ One or more high availability or read-only scale-out servers could have hung in rare timing dependent cases. This has been fixed. ================(Build #3424 - Engineering Case #681755)================ In a high availability setup, if both partners accessed the arbiter at the same time, the arbiter could have crashed or behaved incorrectly. This has been fixed. ================(Build #3423 - Engineering Case #681796)================ In a High Availability system, if the primary was processing changes faster than the mirror could apply them, it was possible that the primary could have hung. This has been fixed. ================(Build #3422 - Engineering Case #681398)================ The server could have crashed while using the UNLOAD statement to unload data with 'APPEND ON' to a file if that file was also being deleted by some other process. This has been fixed ================(Build #3421 - Engineering Case #681612)================ In a read-only scale-out configuration, the use of CREATE OR REPLACE MIRROR SERVER parent-server (where parent-server is the parent to any copy node) could have resulted in incorrect behaviour. The incorrect behaviour included servers and/or databases stopping, or the copy node not being able to connect. This has been fixed. ================(Build #3420 - Engineering Case #681571)================ If an application attempted to drop a connection that had a cursor on a proxy table open, then there was a chance the server would have crashed. This problem has now been fixed. ================(Build #3420 - Engineering Case #681545)================ If a client's character set was a multi-byte character set, the following operations could have resulted in CHAR or NCHAR sizes larger than they should have been: - the columns in a table created by the SELECT ... INTO [ LOCAL TEMPORARY TABLE ] table-name - the columns in a view - sa_describe_query and sa_describe_cursor domain_name_with_size and widths - the EXPRTYPE returned data type length These operations have been fixed to return the correct lengths. ================(Build #3419 - Engineering Case #681551)================ In rare cases, the server may have hang while trying to flush histogram statistics. This has been fixed. ================(Build #3419 - Engineering Case #676340)================ The database server could have taken longer than expected to perform a backup. During such a backup other database requests may have appeared to stall, and connections to the server may also have been impacted. This should only have occurred if the total size of database files was larger than 5 GB. This has been fixed. ================(Build #3418 - Engineering Case #680180)================ Conversions between Date and Time datatypes during direct computation would fail in versions 11.0 and earlier, but in version 12.0, this conversion did not fail. This has been fixed so conversions between dates and times in version 12.0 will now also fail, as these conversions are invalid. ================(Build #3417 - Engineering Case #680726)================ If a server identity file with an unencrypted private key was provided to the server, the server would have refused to use it, reporting "Error parsing certificate file, error code 4113". This has been fixed. Note that this problem would not be seen on Mac OS X systems. ================(Build #3417 - Engineering Case #680569)================ When run on Unix systems, the system procedure xp_startsmtp(), which Starts an email session under SMTP, would have hung when called with a non-null "trusted_certificates" argument. This has been fixed. ================(Build #3415 - Engineering Case #675738)================ Some statements, like CREATE TEXT INDEX and CREATE MATERIALIZED VIEW, record the current database option values that exist at the time the statement was executed in the transaction log. The server would have returned the assertion failure error 100904 - "Invalid option '<option-name>' -- no PUBLIC setting exists", if there was not public setting for one of these options during startup recovery, or when applying changes on a mirror server. This has been fixed. ================(Build #3413 - Engineering Case #679370)================ If an application had a proxy procedure defined with an INOUT or OUT parameter of type [n][var]char(m), then calling that proxy procedure would have caused a server crash if the remote returned a value for that parameter that was the full m characters long. This problem has now been fixed. ================(Build #3412 - Engineering Case #680196)================ An application that connected using jConnect version 7 would have found that certain DatabaseMetaData calls returned incorrect results or unexpected errors. These metadata problems have now been corrected. Note that a database upgrade is needed in order to get this fix. ================(Build #3412 - Engineering Case #678117)================ Under rare circumstances, the database server could have crashed or failed an assertion while running diagnostic tracing on a database where a large number of procedures, user-defined functions, triggers or events are being invoked. This has been fixed. ================(Build #3412 - Engineering Case #677165)================ In specific circumstances, it was possible for the server to fail assertion 101519. This has been fixed. ================(Build #3411 - Engineering Case #680025)================ If a database had one or more ODBC based remote servers that used the new "driver=SQL Anywhere Native" feature, and if more than one connection attempted to establish a remote connection using these remote server definitions, and if no other connection had previously established a remote server definition using one of these remote server definitions, then there was a very small chance that the server would have crashed on exit. This problem has now been fixed. ================(Build #3410 - Engineering Case #679605)================ When a geometry had multiple polygons configured in a particular way, the Union of that geometry with another polygon, which was also configured in a particular way, would have caused a 'ring not closed' error. A simple example of a query that demonstrates this error is: select ST_Geometry::ST_GeomFromText( 'MultiPolygon( ( ( -10 -10, -11 -10, -11 -11, -10 -11, -10 -10 ) ), ( ( 2 2, 2.5 1, 1 1, 1 2, 0 2, 0 0, 3 0, 3 2, 2 2 ) ) )' ).ST_Union( ST_Geometry::ST_GeomFromText( 'Polygon( ( 1 1, 2.5 1, 2 2, 1 2, 1 1 ) )' ) ) The only work around is to break up the MultiPolygon and perform the unions in a different order. This has been fixed. ================(Build #3410 - Engineering Case #679580)================ The server could have crashed if a table was being dropped at the same time as a virtual table was being created. This has been fixed. ================(Build #3410 - Engineering Case #678942)================ There was a small chance that some statistics could have been reported incorrectly if parallel plans were used. Statistics affected include lock count, and the various io counts. This has been fixed. ================(Build #3409 - Engineering Case #679408)================ If a connection exists on the mirror server (ie, not the primary) when a failover occurs, that connection will persist while that partner becomes the primary. Database operations then performed by that connection (including certain temp-table operations which are valid from read-only connections) could have caused errors or crashes on other servers in the mirroring / HA system. This problem has been fixed. ================(Build #3408 - Engineering Case #677430)================ In extremely rare cases, inserting data into a compressed column that had a blob index may have resulted in the blob index becoming corrupt. This could have resulted in assertion failures if the data was accessed randomly (i.e. using substr(), right(), or similar), and would also have resulted in validation failures. This has been fixed. Note: existing corrupted blob indexes must be dropped and recreated after the fix is applied. This can be done using: alter table <table> alter <column> no index alter table <table> alter <column> index ================(Build #3407 - Engineering Case #678817)================ A canceled SQL Anywhere HTTP client procedure may, on rare occasions, hang the server. This has been fixed. ================(Build #3403 - Engineering Case #678259)================ A SQL Anywhere http procedure call may, on rare occasions, have caused the server to crash. This has been fixed. ================(Build #3402 - Engineering Case #677515)================ Running REORGANIZE TABLE on a table with foreign key indexes when the database was under heavy update/delete load, had a chance of corrupting the table. Specifically, the indexes on the table would have contained more values then the table itself. This has been fixed. ================(Build #3402 - Engineering Case #677251)================ If an embedded SQL application or a stored procedure first opened a READ ONLY cursor on a simple SELECT query qualifying for optimizer bypass, and later opened an UPDATE cursor for the same query, a positioned update to the second cursor could have failed with SQLCODE -192 ("Update operation attempted on non-updatable query"). This has been fixed. For the error to occur in version 11, the first cursor would need to be explicitly declared FOR READ ONLY, because FOR UPDATE is the default (c.f. documentation for DECLARE CURSOR statement). In version 12.0.0 and later, cursor updatability depends upon cursor type (c.f. documentation for SELECT and PREPARE statements) but defaults to FOR READ ONLY for ESQL. ================(Build #3402 - Engineering Case #671017)================ In a certain virtual machine implementation, CPU topology detection (which is performed at server startup) could spin consuming 100% of a single logical CPU. The VM software had bugs which reported CPU information to the guest operating system in a manner that does not meet Intel's specifications. Changes have now been made so that SQL Anywhere can tolerate the bugs in the VM software without affecting correct CPU detection in other nvironments. ================(Build #3401 - Engineering Case #677962)================ When a database was shut down (for example, as part of server shutdown) and the database was a high availability mirror or a read-only scale-out copy node, the server could have hung in rare timing dependent cases. If the server was hung due to this problem, there would have been messages like the following in the server console: A write failed with error code: (6), The handle is invalid. Fatal error: disk full when writing to "???" This has been fixed. ================(Build #3401 - Engineering Case #665212)================ Statements using user-defined functions eligible for inlining could have failed unexpectedly. This problem could have affected databases created with earlier versions and reloaded to a version 12 database if such databases contained views referencing inlinable user-defined functions. Such databases could have failed to be reloaded. This has now been fixed. ================(Build #3400 - Engineering Case #677803)================ If an invalid certificate was encountered by the server running on the Mac, the error reported may have been "Error parsing certificate file, error code 0". This has been fixed, the error code should have been non-zero if an error occurred. Note, this problem also affected SQL Anywhere clients running on the Mac. ================(Build #3399 - Engineering Case #677327)================ In some cases, SQL Anywhere HTTP procedures and the HTTP server would have failed to process received chunked mode transfer encoded data when the chunk length meta-data contained leading zeros. This has been fixed. ================(Build #3396 - Engineering Case #676210)================ Execution of a SET REMOTE OPTION would have failed if the value of the setting was larger then 256 bytes. This was due to the schema of the ISYSREMOTEOPTION table which has a 255 byte limit on the length of the settings column. The server has been changed to provide a more appropriate error message. ================(Build #3395 - Engineering Case #672573)================ Using either mixed case or upper case when specifying the ".dll" portion of the assembly name in a CLR external environment procedure, could have caused the external environment to fail to run the specified method within the assembly. For example, an external name clause like: external name 'MyTest.DLL::MyNameSpace.MyTestClass.MyMethod() int' would have failed to execute MyNameSpace.MyTestClass.MyMethod, but an external name clause like: external name 'MyTest.dll::MyNameSpace.MyTestClass.MyMethod() int' would successfully find and execute MyMethod. This problem has been fixed. Note that a workaround is to simply lower case the ".dll" portion of the assembly name. ================(Build #3394 - Engineering Case #675326)================ When run on a Windows Mobile device, the server could have crashed if the "Authentication parameters" field in an existing "SYNCHRONIZATION PROFILE" was modified. This has now been fixed. ================(Build #3393 - Engineering Case #674559)================ 1) In a read-only scale out environment, if a copy node was automatically added (no CREATE MIRROR SERVER statement was executed), but the database server was restarted and used a different TCP/IP address or port, it would have failed to connect properly to other mirror servers. This has been fixed so that copy node servers and primary servers that have this fix will automatically continue to be able to connect if the copy node's TCP/IP address or port changes the first time the copy node connects. 2) If an ALTER MIRROR SERVER statement was executed to adjust a copy node's connection string, that copy node may have temporarily failed to connect properly to other servers. This has also been fixed. ================(Build #3392 - Engineering Case #676664)================ After the changes for Engineering case 661663, passing an invalid certificate to a web procedure (i.e. CREATE FUNCTION ... URL '...' CERTIFICATE '...') may have caused the server to crash when the procedure was executed. This has been fixed. ================(Build #3392 - Engineering Case #676015)================ Queries involving spatial predicates over an indexed geometry column may have failed to select a plan that used the spatial index if the table was very large (several gigabytes at least). This has been fixed. ================(Build #3391 - Engineering Case #676495)================ 1. A copy node can now act as an arbiter for the database it is copying in a high-availability system with mirroring. The arbiter and both partners must be running the updated software to take advantage of this change. As before, a partner cannot act as arbiter for its own database. When defining the arbiter to refer to a copy node, use an arbitrary mirror server name for the arbiter that does not match the server name of any of the database servers in the HA system. The name of the arbiter mirror server isn't actually used for connecting. For example: CREATE MIRROR SERVER "scaleout_child" AS COPY connection_string = 'server=scaleout_child;host=winxp-2:6878'; CREATE MIRROR SERVER "TheArbiter" AS ARBITER connection_string = 'server=scaleout_child;host=winxp-2:6878'; Note that there is no database server in the HA system that is running with the server name "TheArbiter": it is just being used as a placeholder in the mirror server definitions to hold the connection string for the arbiter. 2. Copy nodes could have reported a log mismatch error in certain cases involving a failure of both the primary server and the arbiter. This problem has been fixed. 3. There was a race condition that could have allowed an arbiter server to create two separate internal states for the same mirroring system. This problem has been fixed. ================(Build #3388 - Engineering Case #676007)================ The server would have failed to rename the request log correctly if the option RequestLogNumFiles was set to 1. This has been fixed. ================(Build #3388 - Engineering Case #674917)================ Under rare conditions, the server could have crashed when processing queries with intra-query parallelism. This has been fixed. The crash can be worked around by disabling intra-query parallelism by setting the database option MAX_QUERY_TASKS=1. ================(Build #3385 - Engineering Case #644908)================ After an ALTER TABLE statement, some views may have been incorrectly marked as INVALID. The problem only occurred for views in which the altered table occurs multiple times in the logical expansion of the view definition. This has been fixed. ================(Build #3384 - Engineering Case #671906)================ When processing an UPDATE statement, the server could have constructed erroneous values for the OLD table that would have been created for AFTER ROW or AFTER STATEMENT triggers. This could have lead to incorrect results if the AFTER trigger referenced these values, or could have resulted in the statement failing with an SQL error. The problem would have occurred if and only if the following conditions hold: 1) The UPDATE statement modifies a table that had a primary key, UNIQUE constraint, or unique index. 2) The UPDATE statement modified a column included in the primary key, UNIQUE constraint, or unique index, such that the new value matched a value already existing in the index. 3) The modified table had an AFTER ROW or AFTER STATEMENT trigger This problem has been corrected. ================(Build #3382 - Engineering Case #674782)================ If a server involved in a high availability mirroring system had active TLS connections, the server may have hung indefinitely due to a thread deadlock. This has been fixed. ================(Build #3382 - Engineering Case #674753)================ In rare, timing depending cases, a primary, mirror or copy node server could have hung while shutting down. This has been fixed. ================(Build #3381 - Engineering Case #674704)================ If a directory access server was queried, and one of the files was owned by a user that did not exist on the system where the server was running, then the server would have crashed. This problem has now been fixed. ================(Build #3381 - Engineering Case #674537)================ Simple INSERT statements referencing a table with an article defined with a non-empty WHERE and/or SUBSCRIBE BY clause could have occasionally failed with a "Column not found" error for the column referenced in either WHERE or SUBSCRIBE BY clause. Re-execution of the same INSERT would, in most cases, have succeeded with no error. This has been fixed. ================(Build #3380 - Engineering Case #674550)================ Calling the system function WRITE_CLIENT_FILE could have incorrectly resulted in the error "Client library reported a permissions error accessing object ('<FILENAME>') during transfer" if there were multiple READ_CLIENT_FILE or WRITE_CLIENT_FILE calls in a batch, procedure, or function referring to the same client file name. This could have happened if the client executed a batch or procedure, which in turn called other functions or procedures which ended up doing multiple READ_CLIENT_FILE or WRITE_CLIENT_FILE calls during the execution of the batch or procedure that was executed by the client. This has been fixed by explicitly closing the file at the end of the function call. The file was previously closed at the end of the request. ================(Build #3379 - Engineering Case #673173)================ The fix for Engineering case 661622 missed the situation where a subselect that referenced two tables from the main query block, and was equated to a constant, could also have caused the server to fail an assertion or crash . For example: Select * from T1, T2 where 10 = (select e1 from R where p(R,T1, T2) ) and .. This has now been fixed. ================(Build #3377 - Engineering Case #674582)================ The server would have crashed when inserting several values lower then MIN_DBL (about 1e-306, which is the smallest double which can be stored in normalised format) which still can be stored using denormalized double values. This was fixes by forcing all of the denormal double values to be rounded down to zero. ================(Build #3377 - Engineering Case #674320)================ After a MANUAL or AUTO REFRESH text index was renamed, it may not have been found by subsequent statements. This has been fixed. Note that restarting the database server eliminates the problem ================(Build #3375 - Engineering Case #674027)================ When using read-only scale-out and the NodeType=COPY parameter, the connection may have been incorrectly redirected to a parent node or a node which had a higher load than the current node. Also, in very rare timing depending cases with concurrent clients connecting with NodeType=COPY, the server could have crashed. These problems have now been fixed. ================(Build #3375 - Engineering Case #673704)================ In very rare circumstances, the histogram cleaner could have caused the server to crash. This has now been fixed. ================(Build #3371 - Engineering Case #673844)================ The server may have crashed while attempting to log a deadlock error between connections. For this to have happened, the Log_deadlocks option needed to have been set to 'on', and at least one of the connections that was participating in the deadlock needed to be executing a query that had a parallel plan. There are two possible workarounds: 1) Turn off intra-query parallelism by setting the Max_query_tasks option to 1, or 2) Set the Log_deadlocks option to 'off' This problem has been fixed. ================(Build #3371 - Engineering Case #673212)================ 1) If one TCP/IP address for one partner server in the partner/mirror/primary server connection string in the MIRROR SERVER or -xp configuration was correct, but the TCP/IP address for the other mirror partner server was incorrect, it was possible for the primary server to have skipped performing checkpoints indefinitely. This could only occur with the incorrect TCP/IP address configuration and if the mirror servers contained the fix for Engineering issue 660851. This has been fixed so that the primary server checkpoints normally. 2) If a High Availability or read-only scale-out server failed to connect to another server, there may not have been any indication of the failed connect. This has been fixed by logging a message to the console for each failed connection. 3) A High Availability or read-only scale-out server may have displayed the message "... recovery n% complete" where n was a number less than zero or much greater than 100. This has been fixed. ================(Build #3369 - Engineering Case #675686)================ The server may have failed assertion 101412 - "Page number on pages does not match page requested", if the database/connection option 'chained' was set to 'off'. This has been fixed. ================(Build #3369 - Engineering Case #673014)================ When a SQL Anywhere ROOT service processes a request and queries its HTTPServiceName connection property, its name "root" is appended to the first path element (if one is present). This has been fixed. The HTTPServiceName for a ROOT service is always "root". ================(Build #3369 - Engineering Case #672879)================ If a High Availability partner or copy node encountered a problem (such as the log file being inconsistent compared to the partner or parent), it would have shutdown the problem database. If the same server was also running one other database (other than the database that was mirrored or a participating in read-only scale-out) the server may have also incorrectly shutdown. This has been fixed so that the mirror server or copy node server will only shutdown the server if the only database running is the problem database. ================(Build #3369 - Engineering Case #672858)================ The server could have crashed if a table was being dropped at the same time as a proxy table was being created. This has been fixed. ================(Build #3367 - Engineering Case #672749)================ If the two partner databases in a mirroring configuration were both starting up at the same time, while the servers that were hosting them were attempting to shut down, both servers could have hung. This problem has been fixed. ================(Build #3365 - Engineering Case #672430)================ In very rare situations, the server may have hang on shutdown, if while in the process of shutting down the option MaxMultiProgrammingLevel was increased. This has been fixed. ================(Build #3365 - Engineering Case #665184)================ The server would have incorrectly returned the error "XPath parser error: syntax error at or before character 0 <--" if a stored procedure contained a SELECT statement with an openxml clause that used a variable for the xpath string. This has been fixed. ================(Build #3364 - Engineering Case #672207)================ When attempting to use the IS [NOT] DISTINCT FROM predicate in a query that involved proxy tables the server would have failed the query with a strange "unknown node type" error. This problem has now been fixed and the IS [NOT] DISTINCT FROM predicate can now be used with proxy tables. ================(Build #3363 - Engineering Case #672077)================ Executing a query that joined two or more External Environment result sets could have caused the server to crash if the join resulted in a very large result set. This problem has now been fixed. ================(Build #3363 - Engineering Case #672076)================ When inserting a string literal value into a time or timestamp column of a proxy table, if the string literal contained more than 3 digits of precision within the fractional seconds portion of the time/timestamp value, then the fractional seconds would have been truncated to 3 digits of precision. This problem has now been fixed. Note that this fix only applies to ODBC based Remote Data Access servers. The fractional seconds precision will still be truncated to 3 digits of precision for JDBC based Remote Data Access servers. ================(Build #3363 - Engineering Case #671911)================ The system function OPENSTRING allows a text file to be parsed and interpreted as a relational table. The schema for OPENSTRING can be explicitly specified or can be provided by means of an existing database table. If a remote (IQ or other proxy) table was used to specify the OPENSTRING schema then the server can behave erratically, including crashing. This problem has now been resolved. ================(Build #3361 - Engineering Case #671711)================ The changes for Engineering case 624047 could have caused a server running high availability mirroring, or a read-only scale-out copy node, to fail assertion 200131. The failure was timing dependent, and required accessing an empty table with an index from a read-only connection. This has been fixed. ================(Build #3360 - Engineering Case #659138)================ In exceptionally rare cases, the server may have crashed if two procedure debuggers had been attached to a database and one of them disconnected while a new connect request for a user to debug was being executed. This has been fixed. ================(Build #3360 - Engineering Case #655524)================ A MERGE statement on a table that had a column with DEFAULT AUTOINCREMENT would have increased the autoincrement value for every matching row independently of whether the value had already been used for an INSERT or not. This behaviour has been improved so that the server only generates a new autoincrement value if the matching branch is an INSERT and the value will be used. ================(Build #3357 - Engineering Case #670990)================ If the number(*) function was used in the VALUES clause of an INSERT statement, then the server would have returned a non-fatal assertion error 106103. This has been fixed so that the correct error is now returned. ================(Build #3356 - Engineering Case #670896)================ An "HTTP 404 Not Found" error could have occurred from a web service, if the database that contained that web service was not started at the same time the server was started. This could have happened if the database was started via an ODBC DSN, or with the "START DATABASE" statement. The problem did not occur when the name of the database file was specified on the command line when starting the server. It also would not occur if the database name was specified when calling the web service. This has been fixed. ================(Build #3356 - Engineering Case #670866)================ The following query would have incorrectly returned a 1 indicating the date string was acceptable: select isdate('1234+') While the following query failed with a runtime error indicating the date string was not acceptable: select date('1234+') This problem has been fixed. The "isdate" query now returns 0. At a minimum, the timezone indicator (+) must be followed by hours. For example, '2011+5' is acceptable. Also, if a date string contained a timezone offset of "+" or "-" and was followed by the Z (Zulu) timezone indicator (e.g., '1234-12-31+Z'), no error was diagnosed. This has been corrected. ================(Build #3356 - Engineering Case #670838)================ In rare timing dependent cases, if a High Availability mirror server was in the process of taking over as the primary, it could have failed. The 201120 assertion failure could have been logged to the console log. This problem could only have affected servers containing the fix for Engineering issue 663964. This has been fixed. ================(Build #3355 - Engineering Case #669965)================ A database server using web services could have crashed in very rare situations when an HTTP connection was shutdown. This has been fixed. ================(Build #3354 - Engineering Case #670486)================ In exceptionally rare cases, the server could have crashed when executing a non-parallel query that contains a hash join. The crash would only have occurred if all of the following conditions were true: - the probe input of the hash join had already consumed a lot of memory for hash tables - a child of the hash join returned an error - a hash based parent query node of the hash join needed to allocate memory for the hash table and is restricted by the memory governor, so that it had to acquire memory from other hash based query nodes. This problem has been fixed. ================(Build #3354 - Engineering Case #670403)================ When a database was shut down (for example, as part of server shutdown) and the database was a high availability mirror or a read-only scale-out copy node, the server could have hung in rare timing dependent cases. If the server was hung due to this problem, there would have been messages like the following in the server console: A write failed with error code: (6), The handle is invalid. Fatal error: disk full when writing to "???" This has been fixed. ================(Build #3353 - Engineering Case #669448)================ When performing a backward index scan (a rare occurrence) while there were heavy concurrent updates to the index, there was a small chance that the server could have made a comparison to a random value with unpredictable results. This has been fixed. ================(Build #3352 - Engineering Case #670202)================ In rare timing dependent cases, a primary, mirror or copy node server could have crashed or hung. Also in rare timing dependent cases, partner servers starting for the first time could have fail to have chosen a primary after the changes for Engineering case 663964. These problems have been fixed. ================(Build #3352 - Engineering Case #669633)================ The SQL Anywhere Server provides a system procedure sa_refresh_materialized_views() that can be used to refresh all currently stale materialized views. Invoking the procedure with an argument value of 0 would have caused an error to be reported if at least one of the materialized views failed to be refreshed. This procedure is invoked by the reload script generated by the Unload utility when executed with the "-g" command line switch. This problem has now been resolved. ================(Build #3351 - Engineering Case #647802)================ The server may have failed assertion 106104 "field unexpected during compilation" for queries containing correlated subselects in the WHERE clause. The WHERE subselect predicate must have been of the form "T.X = (subselect referencing R.Y)" where R.Y was an outer reference. This has now been fixed. ================(Build #3349 - Engineering Case #669431)================ When attempting to cancel a Remote Data Access request to an ODBC based remote server, there was a very small chance that the server would have become unresponsive if all three of the following was true: - the local server was running on a Windows based system - the local server had a restricted (or small) number of CPUs or cores (either due to the limitations of the server machine or VM, or as a result of using the -gt or -gtc command line option) - the remote server was not defined to utilize the new "driver=SQL Anywhere Native" feature This problem has now been fixed. ================(Build #3347 - Engineering Case #668989)================ In rare timing dependent cases, a transaction which was successfully committed on a primary server could have been lost. In order for there to have been a chance of this occurring, all of the following needed to be true: - the application was connected to a primary server that lost quorum (the server lost the connection to both the mirror and arbiter servers) - the application stayed connected to this server (the old primary server) even though the network connection to other servers dropped - the application was in the middle of committing a transaction between the time that the old primary server lost its connection to the mirror and arbiter server, and when the old primary server restarted as the new mirror server because it lost quorum - the old mirror server took over as the new primary (the mirror server must have been able to connect to the arbiter server for this to occur) This has been fixed so that the application may now receive the new error for this situation, "The transaction may not be committed because the primary server lost quorum." ================(Build #3346 - Engineering Case #663056)================ In exceptional rare situations the server could have crashed or failed assertions 106808, 100913, or 111706 if very long property values are queried. This has been fixed by truncating property values to the max varchar length of 32000 bytes. ================(Build #3343 - Engineering Case #664702)================ Queries using the spatial cast function TREAT( type1 AS type2 ) could have failed to return a syntax error when it was used incorrectly, and instead could have returned meaningless result sets. This has been fixed. ================(Build #3342 - Engineering Case #659608)================ When making an external environment call, if the external environment procedure made a server side request that ended up leaving a cursor on a temporary table open, then the server could have crashed when the connection was closed. This problem has now been fixed. ================(Build #3341 - Engineering Case #668109)================ Attempting to start two High Availability partner servers without state files (for example, starting them for the first time) could have, in rare timing dependent cases, failed to have one server start as the primary. If this occurred, one partner started as the mirror, and the other partner server looped indefinitely attempting to determine which role it should take. This has been fixed. Also, if a mirror server was in the middle of taking over as the primary when it was shutdown, the database shutdown could have hung until any remaining connections were disconnected. This has been fixed. ================(Build #3340 - Engineering Case #667930)================ In rare situations, the server could have crashed when generating or updating a histogram for a string column. This problem has been corrected. ================(Build #3340 - Engineering Case #667901)================ If an application connected via jConnect and then subsequently attempted to use the {} JDBC escape sequence when making a stored procedure call, then there was a chance the server would have returned an incorrect "variable @p0 not found" error at the time the stored procedure statement or result set was closed. This problem has now been fixed. ================(Build #3340 - Engineering Case #667900)================ If the Transact-SQL ROWCOUNT option was used to limit the number of rows returned by a cursor, the cursor may have skipped the first row in the result set in some cases. This incorrect behaviour only occurred for queries in which optimization was bypassed, and the plan contained a SortTopN operator, rather than a RowLimit operator. This incorrect behaviour was introduced as part of the fix for Engineer case 653706, and has now been fixed. ================(Build #3339 - Engineering Case #667686)================ If an application attempted to cancel or drop a connection that was in the process of making a connection-scoped external environment call, then there was a very small chance the server would have crashed. This problem has now been fixed. ================(Build #3339 - Engineering Case #660691)================ When accessing a directory or file using a Directory Access Server, if the name of the directory or file contained a multi-byte character where one of the bytes in the character was 0x5C, then the Directory Access Server would have failed to find the directory or file. This problem has now been fixed. ================(Build #3338 - Engineering Case #667518)================ When merging recent data distribution information into a table's histogram, the server could have allocated up to one database page worth of data outside of the database cache and then failed to free the memory. The leak could eventually have caused the server to fail due to a lack of memory on 32-bit platforms, or due to lack of swap space on 32-bit or 64-bit platforms. This has now been corrected. ================(Build #3338 - Engineering Case #667001)================ If a stored procedure or a user defined function with the hidden definition appeared on the stack when an error occurred, subsequent call to the TRACEBACK function could have returned the statements from the hidden definition. This has been fixed so that the output of the TRACEBACK function now contains the string '<hidden>' instead of the statements from the hidden procedures or user defined functions. ================(Build #3336 - Engineering Case #667316)================ When unloading a database, the server would have incorrectly output a "dynamic result sets" clause for non-external environment procedures in the reload.sql file. This problem has now been fixed and the "dynamic result sets" clause is now only output for external environment procedures. There are a few points of note: 1) this problem would only have occurred with stored procedures that were created using an older SA 12.0.1 server 2) this fix will only affect new procedures that are created 3) the existence of the "dynamic result sets" clause for non-external environment procedures is in fact a no-op and does not affect performance or behaviour of the non-external environment procedure. ================(Build #3336 - Engineering Case #667314)================ If more than one connection attempted to install or remove Java external environment objects at the same time, then there was a chance the server would have crashed or failed assertions. This problem has now been fixed. ================(Build #3335 - Engineering Case #667142)================ In very rare timing dependent cases, the server could have crashed when a database was stopping. Also in rare cases, it was possible for an automatically started database to not automatically stop when there where no longer any connections to it. Both of these problems have now been fixed. ================(Build #3332 - Engineering Case #661440)================ In rare cases, the server may have crashed while performing DDL and DML operations concurrently. This has been fixed. ================(Build #3331 - Engineering Case #666639)================ The detection of processor geometry (number of physical processors, cores and threads) was incorrect for certain Intel x86/x64 processors, including the Intel Xeon E5405. The server would have detected all cores and threads as belonging to a single physical processor. This problem has been corrected. ================(Build #3328 - Engineering Case #666182)================ An HTTP request over a persistent keep-alive connection to a SQL Anywhere HTTP server may have failed if a previous request on that connection had sent an unexpected body. This has been fixed. For HTTP methods other than POST, the body may be retrieved using HTTP_VARIABLE('TEXT') or HTTP_VARIABLE('BODY') as dictated by the Content-Type. An HTTP POST method is assumed to have a Content-Type of application/x-www-form-urlencoded unless otherwise specified (as with any other HTTP method, alternate Content-Types may be accessed using HTTP_VARIABLE('TEXT') or HTTP_VARIABLE('BODY')). ================(Build #3328 - Engineering Case #665657)================ The problems described here affect Windows CE 5.x kernels only. Note that Windows Mobile 6 platforms use the Windows CE 5.x kernel. With version 11.x, the server was not able to create a cache larger than 32MB. Attempting to do so would have caused the error "Not enough memory". With version 12.x, the server would have automatically and erroneously restricted the cache size to a size smaller than 32MB. The default maximum cache size was erroneously restricted to a value less than 32MB. The "percentage" notation for cache sizes (eg, "-c 50p") erroneously based the percentage on a value that was less than 32MB, rather than the total system memory as documented. These problems have been corrected. ================(Build #3328 - Engineering Case #665630)================ Upgrading a database that had been created with the -dba switch (to set the DBA username and password) could have failed. This has been fixed. ================(Build #3328 - Engineering Case #662419)================ A mirror node in a mirroring system could have failed to recover its database if the database used sequence generators, and the primary and mirror roles switched between the servers. This has been fixed so that servers can now recover logs that exhibit this problem. ================(Build #3327 - Engineering Case #666011)================ When a root server was committing and sending log pages to a copy node, the root server could have experienced poor performance. Root servers which had frequent commits, and copy nodes running on slow computers or connected through high latency connections, would have shown the most noticeable poor performance. This has been fixed so that the performance of the copy node latency will have a smaller affect on the root node by using the equivalent of asynchronous log page synchronization. When using the "SET MIRROR OPTION synchronization_mode = '<value>'" statement, where <value> was asynchronous or asyncfullpage, the server was incorrectly treating this as a synchronous synchronization. This has been fixed as well. ================(Build #3326 - Engineering Case #665799)================ On Windows systems, a minidump might not have been generated under certain circumstances. This has been fixed. ================(Build #3326 - Engineering Case #665665)================ The server could have crashed when increasing the CurrentMultiProgrammingLevel using the system procedure sa_server_option() if there wasn't enough memory available. This has been fixed. ================(Build #3326 - Engineering Case #661622)================ Execution of a query with a subselect predicate correlated on two different tables from the main query block may have caused an assertion failure in the server. This has now been fixed For example: Select * from T1, T2 where T1.X = (select e1 from R where p(R,T1, T2) ) and .. The predicate "T1.X = (select e1 from R where p(R,T1, T2) )" has a subselect and references both tables T1 and T2 from the main query block. ================(Build #3326 - Engineering Case #635353)================ The server could have hung when a connection disconnected, or was dropped. This was more likely to have occurred if the server was under heavy load. This has been fixed. ================(Build #3325 - Engineering Case #665684)================ If an application attempted to establish a Remote Data Access connection to an ASE server, and that connection request failed over to a different ASE server, then the Remote Data Access connection request would have failed. This problem has now been fixed. ================(Build #3324 - Engineering Case #665524)================ An exclusive table lock on a non-transactional global shared temporary table could have caused the server to crash on subsequent INSERT, UPDATE or DELETE statements. This has been fixed. All conditions must have been met (non-transactional, shared global temp table, and LOCK TABLE WITH EXCLUSIVE) for the crash to have occurred. If any of these three can be relaxed, the crash will be avoided. ================(Build #3324 - Engineering Case #665522)================ The attachment specified by the attachname parameter of the system procedure xp_sendmail() may not have been received properly by the recipient's mail client. This has been fixed. ================(Build #3324 - Engineering Case #661066)================ If a range of values was supplied for the TCP/IP option ClientPort, connection attempts may have been slow if the server was not found, or if multiple hosts were supplied for the Host option. This has been fixed. ================(Build #3323 - Engineering Case #665325)================ When validating a database using the VALIDATE statement or the Validation utility (dbvalid), the operation could not have been cancelled. This has been fixed. ================(Build #3319 - Engineering Case #661036)================ Activity executing on the utility_db could have caused a crash, memory corruption, or other unpredictable behaviour, if the cache were to shrink at the same time. This problem has been fixed. ================(Build #3317 - Engineering Case #664695)================ In rare situations, the server could have erroneously reported the error "Not enough memory" at startup. This problem has been corrected. ================(Build #3317 - Engineering Case #664490)================ Cancelling a query that referenced spatial functions could have caused the server to crash, although the probability was exceedingly small. This has been fixed. ================(Build #3315 - Engineering Case #664348)================ In very rare timing dependent cases, the server could have crashed or hung on shutdown if there were active client requests during shutdown. The databases would have already been stopped before the failure, so there was no chance of data loss. This has been fixed. ================(Build #3315 - Engineering Case #664292)================ In rare situations, the server could have crashed if a log truncation or rename (dbbackup -x or -xo or -r) took place while the server was processing a large number of transactions, especially long-running transactions. This has been fixed. No workaround for this problem is known, except to avoid performing log truncation or renaming when the server is handling large numbers of inserts, updates or deletes. ================(Build #3314 - Engineering Case #664247)================ If the system procedure sa_get_user_status() was run on a database with an extremely high number of user definitions, the procedure would have blocked DDL statements and could not have been cancelled until its result had been materialized. This has been fixed. ================(Build #3314 - Engineering Case #663940)================ In very rare cases, a spatial query that applied one of the following methods to a complex geometry value may have returned an incorrect result, or an error: 1. all set operations: ST_Union, ST_Intersection, ST_Difference, ST_SymDifference 2. certain aggregation functions: ST_UnionAggr, ST_IntersectionAggr 3. certain spatial predicates: ST_Intersects, ST_Overlaps, ST_Within, ST_Disjoint, ST_Touches, ST_Crosses, ST_Contains, ST_Relate This has been fixed. ================(Build #3311 - Engineering Case #663596)================ Attempting to insert a variable of type long binary, varchar or nvarchr into a proxy or IQ table that had been generated using the REPEAT() function could have caused an incorrect value to be inserted. It should be noted that this problem would only have occurred if the fix for Engineering case 662000 had already been applied. This problem has now been fixed. ================(Build #3309 - Engineering Case #663459)================ Attempting to autostart a database server on Windows CE when one was already running was incorrectly giving the error: "Unable to start specified database: server exit code -11728" (where the number could vary). This has been fixed to return the correct error: "Database server already running" Note that on Windows CE only one database server can be running at a time, even if when attempting to start a second server with a different name. ================(Build #3309 - Engineering Case #659115)================ The server may have crashed if a query block contained an alias definition and the expression of the alias used columns that could be folded as a constant, (in the example below, alias v011 can be folded as a constant if column T2.a2 was created as NOT NULL), and the alias name was used in a subselect of the query block and in the GROUP BY clause of the query block. For example: select if T2.a2 is null then 99999 else 11111 endif as v011, (select count(*) from T1 where T1.a1 = v011) as c from T2,T3 where T2.a2 = T3.a3 group by v011 This has been fixed. ================(Build #3306 - Engineering Case #663259)================ The Remote Data Access feature is now capable of loading the SQL Anywhere ODBC driver directly. If a remote server is defined similar to the following: CREATE SERVER remote-server CLASS 'saodbc' USING 'driver=SQL Anywhere Native;...' where the the USING clause contains the key pair "driver=SQL Anywhere Native", and the remainder of the USING clause provides all the connection parameters necessary to successfully connect to the remote SQL Anywhere server, then the remote data access layer will load the SQL Anywhere ODBC driver directly and bypass the Windows ODBC Driver Manager on Windows based platforms and the SQL Anywhere ODBC Driver Manager on UNIX platforms. The benefit to loading the SQL Anywhere ODBC driver directly is that, although the ODBC driver still needs to be installed, it no longer needs to be registered if it is only being used for the remote data access support. What's more, if there are multiple copies of the ODBC driver installed, then loading the ODBC driver directly will guarantee that the ODBC driver for the current server version gets used rather than one that was registered with a previous version of SQL Anywhere. It should be noted that if the application also makes use of non-SQL Anywhere remote servers or if there are SQL Anywhere remote servers defined without the "driver=SQL Anywhere Native" key pair, then the remote data access layer will still use a Driver Manager for those other remote servers. ================(Build #3305 - Engineering Case #663283)================ The server may have chosen less that optimal plans for queries with predicates of the form 'T.X=(unknown expression)' if an index on T(X) existed. The '(unknown expression)' could have been, for example, a variable whose value was not used for queries inside the procedures, or could have been a complex expression (i.e. "R.Y+1"). This has now been fixed. ================(Build #3305 - Engineering Case #661663)================ For each outgoing HTTPS web procedure connection, a small amount of memory was leaked which could eventually have lead to memory exhaustion. This has been fixed. ================(Build #3303 - Engineering Case #662025)================ In some cases, the server would have displayed recovery progress messages incorrectly when recovering a large transaction log. In this situation, either no messages would have been displayed or an incorrect percentage would have been displayed. This has been fixed. ================(Build #3303 - Engineering Case #661633)================ Execution of an "UPDATE ... PUBLICATION ... WHERE .." statement with a complex WHERE clause may have caused the server to crash. This has been fixed. ================(Build #3302 - Engineering Case #662452)================ Attempting to start a connection-scoped external environment, and then canceling the start request before the external environment completed the startup process, could have caused the server to crash. This problem has now been fixed. ================(Build #3302 - Engineering Case #661193)================ Atempting to call a Java external environment stored procedure or function with a very long binary or string input argument, could have taken a very long time to execute. This problem has now been fixed. ================(Build #3301 - Engineering Case #662000)================ Attempting to insert a variable of type LONG BINARY into a proxy could have taken a very long time, even though the variable was only a few megabytes in length. This problem has been resolved and the performance of inserting LONG BINARY variables into proxy tables has been greatly improved. Note that this fix also improves the performance of inserting LONG VARCHAR and LONG NVARCHAR variables into proxy as well. ================(Build #3300 - Engineering Case #660851)================ When a primary server lost its connections to both the mirror and arbiter servers as a checkpoint was performed, the database on the primary may not have been recoverable. Typically, it would fail assertion 100904. This has been fixed. Similarly, in cases where a primary server lost its connections to both the mirror and arbiter servers as a checkpoint was performed, the next time the primary and mirror servers were connected and attempt to synchronize, the mirror server may have in rare situations reported "Database "<name>" mirroring: database is not compatible with primary; files must be replaced" and then stop with the message "Database server shutdown due to incompatible files for database mirroring". This has been fixed to reduce the possibility of this occurring. It is possible for this to still occur, so then the database running on the current primary must be manually copied or backed up to the mirror server so that the server can successfully synchronize again. The primary server could have hung, again in rare situations, if only one of the two connections between it and the mirror server was dropped, for example due to a liveness timeout. This has been fixed. When the mirror server was becoming the primary server there was a small possibility it could have hung after reporting it was starting a checkpoint and then reporting it was recovering. This has been fixed. ================(Build #3299 - Engineering Case #661453)================ If the distance parameter of the proximity search condition contained letters, the server could have silently failed, and returned some result, instead of reporting an error. This has been fixed. For example, the following query would not report an error and would behave as if the full text query was 'apple NEAR[2] oranges': SELECT * FROM t CONTAINS( 'apple NEAR[ 2b ] oranges' ) Note that the following query was correctly reporting an error: SELECT * FROM t CONTAINS( 'apple NEAR[ b ] oranges' ) ================(Build #3298 - Engineering Case #661034)================ Under rare conditions, the server could have hung while executing a query with multiple GROUP BY clauses. This may have occurred when the workload executing on the server suddenly changed (i.e. if many requests arrived almost simultaneously). This has been fixed. A workaround is to disable intra-query parallelism for the affected query (SET TEMPORARY OPTION MAX_QUERY_TASKS=1). ================(Build #3297 - Engineering Case #660629)================ When connected to an ASE 15.5 server and attempting to make a remote request to SQL Anywhere, there was a chance the request would have failed with an "unkown token 35" error. This problem has now been fixed. Note that this problem only affected remote requests from ASE to SQL Anywhere. The problem did not affect making remote requests from SQL Anywhere to ASE via Remote Data Access. ================(Build #3297 - Engineering Case #660446)================ Performing a backup with a TRANSACTION LOG RENAME would have caused read-only connections to the database on the mirror server to be dropped. This has been fixed. ================(Build #3297 - Engineering Case #658330)================ Execution of an INSERT ON EXISTING UPDATE statement, with CASCADE as the foreign key update option, would have resulted in a foreign key constraint violation error when updating values which were logically the same, but had different physical representation. For example, in case insensitive database changing 'EMPLOYEE' to 'employee'. This has been fixed. ================(Build #3296 - Engineering Case #660432)================ Creating a variable with an initial value specified as a host variable did not give a syntax error in some cases. This has been fixed. ================(Build #3296 - Engineering Case #660248)================ If an application connected via jConnect or Open Client and made an external environment call that returned a result set, then the server may have crashed. This problem has now been fixed. ================(Build #3296 - Engineering Case #659870)================ Empty string values indexed by an IMMEDIATE text index were not counted towards the total number of documents indexed, unless more than one column was indexed and the value in at least one of the columns was neither an empty string nor NULL. This problem caused scores for full text queries to be lower then they should have been if all the documents were correctly counted. Additionally, a memory leak could have occurred in this situation. This has been fixed. Note, if a text index was created or updated using a server with this problem, it may be necessary to rebuild the index with an updated server if problems are encountered with the index. ================(Build #3295 - Engineering Case #660235)================ On Windows Vista and later operating systems, whenever a new server executable had to be launched in order to autostart a database, launching the executable may have failed when a relative path to the server executable was specified. For example, dbspawn mybin\dbsrv12.exe -n myserver my.db, or using "...;start=mybin\dbsrv12.exe..." in a connection string, could have fail to launch the server executable. This problem has been fixed. ================(Build #3295 - Engineering Case #660211)================ In rare circumstances, calling the system procedures sa_locks, sa_describe_shapefile, st_geometry_dump, sa_list_cursors, or sa_mirror_server_status, could have caused the server to crash, or could have caused unpredictable behaviour. The problem was more likely to have occurred when small cache sizes were used. This problem has been fixed. ================(Build #3295 - Engineering Case #660194)================ Execution of a query on a Directory Access proxy table with a WHERE clause that contained a predicate of the form "file_name = variable", may have sometimes run very slowly while running very quickly most other times. This problem has now been fixed such that the query performance is now consistently fast from one run to the next. ================(Build #3295 - Engineering Case #660057)================ If a foreign key was created with both MATCH and CHECK ON COMMIT clauses, and the database subsequently required recovery, recovery would have failed when replaying the statement from the transaction log. This has been fixed. ================(Build #3295 - Engineering Case #652949)================ The trigger operation condition 'UPDATE( {column-name} )' did not return TRUE if the column value had been changed by a previously running BEFORE UPDATE row-level trigger only. This has been fixed. ================(Build #3295 - Engineering Case #652244)================ An internal unload/reload (i.e. dbunload -ii) that encountered a SQL error could have hung or caused a subsequent unload/reload on the same server to hang. This problem has been fixed. ================(Build #3294 - Engineering Case #659804)================ If a proxy table or proxy procedure was defined with variables in the AT clause, then the AT clause would have been incorrectly truncated if the length of the AT clause after variable expansion was greater than the length of the original AT clause. This problem has now been fixed. ================(Build #3294 - Engineering Case #659639)================ When making a Java external environment call, if the stored procedure had an argument of type char (note that this is a single char value rather than a java.lang.String), and a NULL value was passed in for the char argument, then the server would have failed the request with a Java NullPointerException. It should be noted that the Java VM would have continued to run in this situation and the connection was still able to make subsequent Java external environment calls. This problem has now been fixed such that passing a NULL char value to a Java external environment call will result in a char with zero value being passed down to the Java method. Again, it should be noted that this problem does not affect passing NULL string values to java stored procedures. ================(Build #3294 - Engineering Case #659631)================ If an application enlisted a connection within a DTC transaction and then subsequently attempted to perform a DTC commit on the transaction after explicitly unenlisting it first, then the application would have hung until the server was shut down. This problem has now been fixed and the commit request will now immediately fail as expected. ================(Build #3294 - Engineering Case #659370)================ Inlining of simple functions could have generated unexpected errors or incorrect results. For incorrect results to have occurred, the caller of the function had to have variables defined with the same names as the inlined function. This has been fixed. ================(Build #3294 - Engineering Case #613299)================ Queries involving indexes could return incorrect results, and using tools such as the Validate Database Wizard in Sybase Central, or the Validation utility, could have reported index corruption when there was in fact none. For this to have occurred, the index must not have been unique and there must be many consecutive rows with the same indexed value. This has been fixed. ================(Build #3292 - Engineering Case #658985)================ Unexpected deadlocks could have occurred when using the UPDLOCK hint at isolation level 3. For example, if two transactions issued the statements SELECT t.c FROM t WITH (UPDLOCK) WHERE t.pk = 1 UPDATE t SET c = 2 WHERE t.pk = 1 concurrently at isolation level 3, a deadlock would have occurred if both connections managed to issue the SELECT before either issued the UPDATE. This has been fixed. ================(Build #3292 - Engineering Case #658849)================ If an application on a Unix system attempted to make a TCP/IP connection to a server that was not running, the connection attempt may have failed with error code -832 "Found server but communication error occurred". This has been fixed, the correct error code should be -100 "Database server not found". ================(Build #3291 - Engineering Case #657823)================ The fix for Engineering case 620136 did not handle the situation where there was no declared Primary Key in the primary table but there were table, or column, (not nullable) Unique Constraints that permit the addition of foreign keys. This problem has been corrected. ================(Build #3290 - Engineering Case #658114)================ The server would have crashed if a SELECT statement useed the FOR XML EXPLICIT clause, and a null value was used for the CDATA directive. This has been fixed ================(Build #3290 - Engineering Case #656998)================ Remote queries with many aliases in grouped derived tables may have taken a long time to execute. This has been fixed. ================(Build #3289 - Engineering Case #657621)================ If a server (S2) acting as mirror saw a dropped connection to the primary server (S1) after a temporary network outage, it could have attempted to become primary while S1 was still running. S2 would then have failed during startup because S1 still owned the alternate server name for the database. This error would also have caused S2 to shut down. If S1 needed to restart, it would have been unable to take ownership of the database because S2 was unavailable and the arbiter's state had been updated to indicate that S2 was the owner. Also, when a server acting as primary (S1) accepted an inbound connection from the mirror (S2), S1 attempted to make an asynchronous outbound connection to S2 if one did not already exist. If this connection attempt failed, S2 would have failed to receive updates from S1. These problems have now been fixed. ================(Build #3288 - Engineering Case #658302)================ If many contiguous index entries were removed from an index with no intervening inserts, concurrent snapshot transactions could have seen incorrect results, and in rare circumstances, foreign rows could have been added without matching primary rows. This has been fixed. ================(Build #3287 - Engineering Case #658189)================ If a copy node (S3) was starting just as its intermediate node parent (S2) was receiving pages from the root (S1), S3 could have failed to receive some of the pages and would have reported a corrupt transaction log file. This has been fixed. ================(Build #3287 - Engineering Case #658130)================ SQL Anywhere web client procedures were not able to proxy https requests. This has been fixed. The following example routes an https request destined for 'securehost' (default port 443) through a proxy host named 'squid' listening on port 8080: create or replace procedure test() URL 'https://securehost/service' TYPE 'HTTP:GET' PROXY 'http://squid:8080'; ================(Build #3287 - Engineering Case #658121)================ On some Windows machines, attempting to make a TCP connection to a Personal Server on the same machine may have failed. This has been fixed. ================(Build #3287 - Engineering Case #657987)================ The server could have crashed, or failed assertion 200114, when processing a LIKE predicate. This has been fixed. ================(Build #3287 - Engineering Case #657812)================ A number of read-only scale-out issues have been fixed. 1) The server could have crashed or otherwise failed in rare cases when one or more read-only scale-out children were added to a node. This could have occurred if one node was stopped or restarted. 2) If a parent node was restarted and had a lower log offset than it's child, the child could have shutdown with the message "Database server shutdown due to incompatible files for database mirroring." Restarting the child node after the parent caught up to primary would succeed. Now the child node no longer stops and the child node will start applying log changes once its parent gets to a higher log offset. 3) If a parent copy node was started with child nodes already running, a child node and possibly other nodes could have hung. 4) If a copy node was connected to it's alternate parent, and then it's alternate parent stopped, the copy node may have stopped applying updates. The copy should have connected to the primary server to receive updates but was actually not receiving updates. Note that sa_mirror_server_status may show that the node which is not receiving updates is connected, when in fact it was not. Now the copy node will connect to the primary server if neither the parent nor alternate parent servers are available. 5) An ALTER MIRROR SERVER statement that only changed the alternate parent was ignored until the server being altered was restarted. For example, if ServerC had parent ServerB: ALTER MIRROR SERVER 'ServerC' AS COPY FROM SERVER 'ServerB' OR SERVER 'ServerA' was ignored by ServerC until it was restarted. Now the alternate parent is effective on the server being altered once it has applied the log offset with the ALTER MIRROR SERVER statement. 6) Attempting to SET MIRROR OPTION auto_add_server to the alternate server name for the primary server incorrectly resulted in an error. 7) If read-only scale-out copy nodes had a primary server as their root node, and the primary server failed over to the mirror server, then all client connections to all copy nodes were incorrectly dropped. ================(Build #3285 - Engineering Case #657520)================ In very rare cases, the server asserts with assertion error 102300 "File associated with given page id is invalid or not open" if request level debugging is turned on and includes plan logging and there are schema changes around. This has been fixed. To work around the problem plan caching can be turned off (option Max_plans_cached = 0) or plan logging can be turned off (switch -zr without "plan" and "all"). ================(Build #3285 - Engineering Case #654801)================ The SQL Anywhere Optimizer may have incorrectly pruned, without costing, optimal plans during query optimization. This has been fixed. This incorrect pruning would most probably have affected the final execution plans for complex, but inexpensive (i.e., the optimal plan has a small runtime) queries. ================(Build #3284 - Engineering Case #657586)================ If a call was made to the Java external environment, and the stored procedure had an argument of type tinyint and a NULL value was passed in for the tinyint argument, then the server would have failed the request with a NullPointerException. It should be noted that the Java VM would continue to run in this situation and the connection was still able to make subsequent Java external environment calls. This problem has now been fixed such that passing a NULL tinyint value to a Java external environment call will result in a byte with zero value being passed down to the Java method. ================(Build #3284 - Engineering Case #656691)================ If a query was rewritten by the optimizer to use a materialized view, the query would incorrectly have returned zero rows if a spatial predicate was applied to the rows originating from the view. This has been fixed. ================(Build #3283 - Engineering Case #656828)================ Adding the CHECK IMMEDIATE REFRESH clause to a CREATE MATERIALIZE VIEW statement would have caused the server to crash. This has been fixed. ================(Build #3283 - Engineering Case #656264)================ When connected to a database that had the same character set as the OS, and a query like the following was executed: SELECT ... FROM dirtab WHERE file_name = '...' where dirtab was a directory access table and the file_name string literal contained non-ASCII characters, there was a chance the server would have crashed. This problem has now been fixed. ================(Build #3282 - Engineering Case #656847)================ If a derived table was joined with the rest of the query using a Join Nested Loops operator, the performance of the query may have suffered when the derived table had to be computed many times due to many rows generated by the left hand side of the Join Nested Loops. The optimizer was choosing such a plan if the estimated number of rows of the left hand side was very small. If this estimation was wrong (e.g., the optimizer estimates one row for the left hand side but in reality the left hand side produces 1,000 rows), the derived table was computed many, many times during execution. This has been fixed so that the optimizer considers only Join Hash or Join Sort Merge operators for the derived tables if it is correct to do so. ================(Build #3282 - Engineering Case #656839)================ If an INSERT or UPDATE statement affecting the value of a spatial column was canceled, or a run-time error was encountered during execution, there was a possibility that the server would have failed assertion 112701: "Failed to convert geometry to EWKB for the redo log -- transaction rolled back [-301] ['40W01']". This has been fixed. ================(Build #3281 - Engineering Case #656650)================ The system procedure sa_db_list() did not validate its database id parameter if the value was a positive integer. This would have resulted in a single row result set containing the value provided. Now, if the value is not a valid database id, the procedure will return an empty result set. ================(Build #3281 - Engineering Case #655981)================ Values for the ApproximateCPUTime property is never expected to decrease between calls, as it represents an estimate of accumulated CPU time for a connection. However, for connections that had accumulated approximately 1000 seconds of CPU time, the counter could have periodically receded by approximately 400 seconds. ================(Build #3279 - Engineering Case #656272)================ The INSERT ON EXISTING SKIP statement did not report the correct number of inserted and updated rows using @@rowcount and sqlcount. This has now been corrected. ================(Build #3279 - Engineering Case #655749)================ Execution of an INSERT ... ON EXISTING SKIP statement did not report the correct number of inserted and updated rows using @@rowcount and sqlcount. This has been fixed ================(Build #3279 - Engineering Case #654294)================ When canceling a query involving spatial operations, there was a small probability the server could have crashed, or failed to release resources. This has been fixed. ================(Build #3278 - Engineering Case #655972)================ The fix for Engineering case 636018 missed a case, which has now been corrected. Description of case 636018: Queries involving indexes containing long values could have returned incorrect results. Index corruption was possible, but not likely.. ================(Build #3278 - Engineering Case #654938)================ In rare cases, a corrupt TCP packet could have caused the server to crash. The server now validates the packet header before do anything with the packet. If it is corrupt, the packet is dropped. ================(Build #3277 - Engineering Case #655533)================ Under rare circumstances, inserting the result from the Round Earth linestring() function, or using the linestring() function in a query, could have crashed the server, if the line string crossed the equator. This has been fixed. ================(Build #3275 - Engineering Case #654790)================ In very rare cases, the server may have crashed with a floating point exception when slightly loaded. This has been fixed. ================(Build #3273 - Engineering Case #654284)================ The server could have crashed if the STOP SERVER or STOP ENGINE statement was called from an event or HTTP connection. This has been fixed. Note that the 'STOP SERVER' syntax is new to version 12 (older servers support 'STOP ENGINE'). ================(Build #3273 - Engineering Case #654259)================ The changes for Engineering case 650489 may have caused execution remote procedure calls to an ASE remote server to fail with a strange "unchained transaction mode" error. This problem has now been fixed. ================(Build #3272 - Engineering Case #653591)================ Attempting to attach tracing to an older version database file could have caused the server to crash. This has been fixed so that attempting to attach tracing to an older version file now returns the error "ATTACH TRACING could not connect to the tracing database" (-1097). ================(Build #3272 - Engineering Case #556778)================ The return values of the built-in functions user_id() and suser_id() may have incorrectly been described as not nullable even if the function argument was not nullable. This may have lead to the assertion error 106901 "Expression value unexpectedly NULL in write". This has been fixed so that the functions' results are always described as nullable. ================(Build #3270 - Engineering Case #653245)================ The value for the column "columns" for the system view SYS.SYSFOREIGNKEYS is generated using a LIST() function, but the function did not include an ORDER BY and so the result returned could have varied. This has been fixed by adding an ORDER BY clause. Note, the system view must be recreated by upgrading or rebuilding the database for the new view definition to be used. ================(Build #3270 - Engineering Case #652911)================ If an INSTALL JAVA UPDATE statement was executed to update an existing java class, the server would have incorrectly added a new system object id rather than reuse the already assigned object id. This problem has now been fixed. ================(Build #3269 - Engineering Case #653590)================ Diagnostic tracing, or application profiling to LOCAL DATABASE could not be used when the server was started with the command line option -sb 0 (disable broadcast listener). This has been corrected. A workaround is to manually supply a connection string (ATTACH TRACING TO <connstr>) with the DoBroadcast=NO option, rather than using the LOCAL DATABASE clause. ================(Build #3269 - Engineering Case #653588)================ If tracing was suddenly detached (because, for example, the server receiving the tracing data was shut down) at the same time as a deadlock occurred, a deadlock victim may have failed to write a ROLLBACK to the transaction log. This may have lead to an incorrect partial commit of a deadlocked transaction. This has been fixed. This problem is expected to be very rare. ================(Build #3269 - Engineering Case #635956)================ A query with a CUBE, ROLLUP, or GROUPING SETS clause and HAVING predicates may have returned an incorrect result set. The query must not have had any aggregate functions, and the grouping sets must have contained the grand total which should have been filtered by the HAVING predicates, but instead it was returned as a valid row. For example: select n_comment from nation group by cube (n_comment) HAVING n_comment like 'alw%'; The result set would have contained all the rows with n_comment for which the predicate "n_comment LIKE 'alw%' is TRUE, but also the row "(NULL)". This has now been fixed. ================(Build #3268 - Engineering Case #652592)================ Attempting to connect to a read-only scale-out database with a non-ASCII database name using the NODETYPE connection parameter could have incorrectly failed with a "Specified database not found" error. The database name was being sent back in either OS-charset or DB-charset, but the client needed it to be in client-charset. This has now been fixed. ================(Build #3267 - Engineering Case #652791)================ If a statement for a directory access table failed with the error SQLSTATE_OMNI_REMOTE_ERROR, and this statement was the last statement of the transaction then all subsequent remote server statements of this connection would have failed with the same error. This has been fixed. ================(Build #3267 - Engineering Case #652759)================ If a table was included in a MobiLink publication and one or more options were defined for that publication, but there were no synchronization subscriptions defined, the table could not be ALTERed to, for example, add a new column. This has been fixed. ================(Build #3267 - Engineering Case #652756)================ When validating a table that contained spatial data on 32-bit x86 systems where the processor did not support the SSE2 instruction set (the minimum required for SA spatial features), the database server would have reported a non-fatal assertion error 113300 or 113302 "failed to build cursor to validate". This problem has been fixed and the underlying error is now reported: SQL error (-1515) -- Support for spatial is not available for this CPU. ================(Build #3267 - Engineering Case #651294)================ When starting a 32-bit server with a large initial number of request tasks (-gn option), the server could have failed to start by reporting an error, crashing or quietly exiting. This problem has been fixed by reducing the maximum cache size to accommodate the address space needed for the stacks of the request tasks. ================(Build #3266 - Engineering Case #652587)================ When running a database without a transaction log, performance could have been significantly slower than in previous versions. This problem has been corrected. See Engineering case 608904 for a similar issue.. ================(Build #3266 - Engineering Case #652543)================ The server may have crashed during inserts into a view, if the view column was not a base table column. This has been fixed. Now the correct error SQLSTATE_NON_UPDATEABLE_VIEW is returned. ================(Build #3265 - Engineering Case #651694)================ If the connections between servers in a mirroring system used encryption, the primary server could have hung when performing an operation which required exclusive access to the database (e.g. a checkpoint) if other update activity was also occurring. This has been fixed. ================(Build #3264 - Engineering Case #652107)================ If a foreign key had both ON UPDATE and ON DELETE actions, renaming a column referenced by the foreign key could have caused one of the system triggers to be deleted and the other to be left unchanged. A trigger for an ON UPDATE action could have been converted to an ON DELETE action. This has been fixed. ================(Build #3264 - Engineering Case #651846)================ On Windows systems, the performance monitor might not have displayed counter values provided by the server. Typically this would have happened when a shared memory client that was attached to the server terminated abnormally. Counter values should not display for subsequent servers until all processes holding handles to the dead server (e.g. shared memory clients) are terminated. This has been fixed. ================(Build #3263 - Engineering Case #651658)================ On Windows systems, SQL Anywhere provides a version 1 (registry) performance provider. Windows should generate WMI classes automatically after the counter dll is registered, but these classes were generated only after instances of these objects (i.e. server, database and connection) existed in a process running in session 0 (i.e. as a service in Vista and up). This has been fixed. ================(Build #3262 - Engineering Case #651323)================ When the distance between two ST_Points exceeded the spatial reference system's tolerance by at least a factor of 1, but less than a factor of sqrt(2), the spatial relations ST_Equals and ST_Intersects could have incorrectly returned TRUE. This has been fixed. ================(Build #3262 - Engineering Case #651169)================ If a database containing a table with a uniqueidentifier column was unloaded using the Unload utility (dbunload) with one of the external unload options (-xi or -xx), and the resulting reload.sql script was executed using the Interactive SQL utility, a conversion error would have been reported. This has been fixed. A workaround is to avoid using -xx or -xi when rebuilding the database. ================(Build #3262 - Engineering Case #650337)================ Queries with an outer join having the same base table as the preserved and null-supplying sides could have returned incorrect result sets. Conditions where this could happen: 1. the outer join is of the form : T as T1 LEFT OUTER JOIN T as T2 ON(p) 2. the ON predicate p has only equijoins, and at least two equijoins 3. p is of the form : T1.c1 = T2.c1 and T1.c3 = T2.c2 4. there exists an unique index on T < c1,c2> This has been fixed. ================(Build #3261 - Engineering Case #650740)================ Execution of a DROP DATABASE statement would have failed if the automatically generated database alias name was an invalid identifier. This has been fixed. ================(Build #3261 - Engineering Case #650690)================ The server would have returned assertion failed 100905 "Articles on the table use do not match those on the table definition", if a table had publications and a simple INSERT with multiple row value constructors was executed. For example: insert into tab1 values (1,'a'),(2,'b'). This has been fixed. ================(Build #3153 - Engineering Case #647077)================ When run on Mac OS X systems, the server would have exited with the error "Failed to become daemon" if both the -um and -ud command line options were specified. This was due to a limitation in the OS X GUI infrastructure. This has been fixed. The -um flag is now ignored if -ud is specified. A workaround is to use dbspawn instead of -ud.

SQL Anywhere - Sybase Central Plug-in

================(Build #3750 - Engineering Case #711705)================ After creating a directory access server that used the new for 12.0.1 "{varname}" syntax in the USING clause, Sybase Central could have crashed when attempting to open the Directory Access Servers folder. This has been fixed. ================(Build #3747 - Engineering Case #711499)================ If Sybase Central encountered an internal error, and the user elected to send a report to Sybase, they would get a message saying that the report could not be sent, even if it was. This problem also occurred with the Interactive SQL utility, the Console utility, or the MobiLink Monitor, and has been fixed. ================(Build #3739 - Engineering Case #709633)================ W@hen clicking the column heading of the Current, Average or Maximum columns on the Performance Monitor tab, the corresponding values would have been sorted as strings, not as numeric values. Now the values are sorted numerically. In addition, the values are now right-aligned. ================(Build #3733 - Engineering Case #708422)================ If a user owned one or more tables, views, procedures or sequence generators, and permissions on these objects were assigned to another user, then deleting the first user could have caused Sybase Central to crash. This has been fixed. ================(Build #3731 - Engineering Case #707971)================ The Compare Databases window would have reported ALTER LOGIN POLICY as an unrecognized statement. This has been corrected. ================(Build #3718 - Engineering Case #699351)================ When connecting to an SQL Anywhere database from Sybase Central or the Interactive SQL utility, a standard connection dialog is displayed to gather connection options. On the Identification page of that dialog there is a drop-down named "Authentication". When "Windows Integrated Login" was chosen in the drop-down the choice was ignored and the value "Database" was used instead. This has been fixed. ================(Build #3712 - Engineering Case #703102)================ When comparing two databases, running the generated script in Interactive SQL would have caused syntax errors to be reported if the script contained Transact-SQL statements. This has been fixed. ================(Build #3557 - Engineering Case #696640)================ Attempting to create a maintenance plan with a single quote in its name would have failed. The plan's name is used in a generated SQL statement. If the name contained a single quote, then the generated statement would not have executed. Any single quotes in the name are now doubled-up before including it in the generated statement. ================(Build #3557 - Engineering Case #696631)================ Attempting to create a maintenance plan, or test the email settings for a maintenance plan, would have failed when running on a French machine. This has been fixed. ================(Build #3533 - Engineering Case #694466)================ The Compare Databases window could have reported syntactically-distinct, yet semantically-equivalent, differences between the two databases. The differences were limited to the ordering of the following: 1. Authorities for a user or group 2. Option name-value pairs for a login policy 3. Tables for a publication 4. Columns for an article 5. Option name-value pairs for a mirror server In all of the above cases, the ordering was irrelevant; however, the tool could have reported differences because the comparison could have generated random orderings. For example: GRANT CONNECT,DBA,RESOURCE TO "DBA" IDENTIFIED BY ... vs: GRANT CONNECT,RESOURCE,DBA TO "DBA" IDENTIFIED BY ... These have been fixed. The comparison now provides a consistent ordering as follows: 1. User and group authorities are ordered by authority name. 2. Login policy options are ordered by option name. 3. Publication tables are ordered first by user name, then by table name. 4. Article columns are ordered by column id. 5. Mirror server options are ordered by option name. ================(Build #3527 - Engineering Case #694480)================ Selecting a tenant database's Login Mappings folder in the tree would have caused an error. This has been fixed. ================(Build #3527 - Engineering Case #694468)================ Attempting to compare a tenant database with another database would have caused Sybase Central to crash. This has been fixed. ================(Build #3514 - Engineering Case #691736)================ When connected to a version 11 or earlier database, clicking the database's Overview panel would have displayed a "Table 'sysmirrorserver' not found" error. This has been fixed. A check of database version has now been added before querying the SYS.SYSMIRRORSERVER table. ================(Build #3507 - Engineering Case #681082)================ If deployment of a synchronization model to a consolidated database stopped progressing because another database connection was blocking it, clicking Cancel would have caused Sybase Central to become unresponsive, even after the blocking from the other connection ended. This has been fixed. ================(Build #3492 - Engineering Case #689233)================ Opening a procedure in a new window, deleting the procedure from the main Sybase Central window, and then attempting to save the procedure from the new window, would have caused Sybase Central to crash. The same problem occurred for views, functions, triggers and events. These issues have been fixed. ================(Build #3461 - Engineering Case #685299)================ The "Overview" panel for a database shows the HTTP and HTTPS ports which its server is using. If both HTTP and HTTPS were used, and the server's -xs command line option was sufficiently complex, the reported port numbers would have been incorrect. Typically, they were more than 6 digits long. Now, the correct port numbers are displayed. ================(Build #3423 - Engineering Case #681931)================ When looking at the commands in a deployed task, the "On failure" setting for each command was displayed as "Abort task", even for those commands with different "On failure" settings. This has been fixed. The correct "On failure" setting is now shown for each command. ================(Build #3423 - Engineering Case #681928)================ A command can be added to a remote task by selecting the task, then clicking the "Add Command" toolbar button or menu item. If a command is then selected in the "Commands" tab, the new command appears on the row following the selected row. This command was not actually added to the task at that position, instead, it was always added to the end of the command list. This has been fixed so that the new command actually follows the selected command. This problem could have made it appear as if the order of commands changed when a remote task was deployed, if the remote task was deployed shortly after adding a command. In fact, the ordering of the commands was incorrect immediately after the command was added. If Sybase Central was started and the task was viewed without deploying it, the added command would have been at the end of the command list. ================(Build #3415 - Engineering Case #680760)================ When viewing extended options for a synchronization profile, publication, MobiLink user, or synchronization subscription, the values for the MobiLinkPwd and NewMobiLinkPwd extended options could have been seen in plain text from their tooltips. Now, no tooltips are shown for these values. ================(Build #3415 - Engineering Case #680755)================ Sybase Central could have crashed when selecting a global temporary table in the tree, then selecting the Data tab in the right-pane and attempting to insert a row into the table. The crash would only have occurred if the table's commit action was DELETE ROWS. This has been fixed so that the Data tab is no longer shown for a GLOBAL TEMPORARY table unless its data is SHARE BY ALL. ================(Build #3415 - Engineering Case #676363)================ When attempting to use Sybase Central to create a proxy table for an Access database, and the remote server used the 'MSACCESSODBC' server class, the following error would have been displayed: [Sybase][ODBC Driver][Adaptive Server Anywhere]Server '<server-name>': [Microsoft][ODBC Driver Manager] Driver does not support this function (-660) A call was being made to SQLPrimaryKeys() to determine which columns in the table belong to the primary key. Access does not support this function, so this error is now ignored for the 'MSACCESSODBC' server class. ================(Build #3387 - Engineering Case #675894)================ In Sybase Central, you can generate HTML documentation for a database to which you are connected. That documentation includes cross-reference information for stored procedures -- a list of procedures a given procedure calls, and a list of the procedures which call the given procedure. This cross-reference information was not being generated for those stored procedures which used the Transact SQL dialect. Cross-reference information for procedures which used the SQL Anywhere dialect were generated fine. This has been fixed so that cross-reference information is generated for stored procedures that are written using either dialect. ================(Build #3376 - Engineering Case #674243)================ The text completer in the Interactive SQL utility and Sybase Central usually suggests SQL statements (e.g. DELETE,INSERT,SELECT) when starting to typing a statement. There was a problem that prevented statements from being suggested when typing a new statement if there was already a statement on a later line, and there was no command delimiter (i.e. a semicolon) between the new statement and the existing one. In this case, only matching SQL keywords and database object names would be suggested. This has been fixed. ================(Build #3339 - Engineering Case #667675)================ After the Database Documentation Wizard completed, a prompt asked whether to view the generated documentation. If "Yes" was clicked, a browser window was supposed to open to show the documentation, but the browser failed to open if the path to the generated files contained a space. This has now been fixed. ================(Build #3327 - Engineering Case #666024)================ Using Sybase Central's searching capabilities to search in a Version 11.0 or earlier database would have caused Sybase Central to crash. This has been fixed. ================(Build #3327 - Engineering Case #666013)================ Using Sybase Central's searching capabilities to search for a single backslash would have caused Sybase Central to crash. This has been fixed. ================(Build #3297 - Engineering Case #660656)================ After updating an external environment object via File->Update..., the object's Contents tab would not always have reflected the changes made to the object. This has been fixed. ================(Build #3292 - Engineering Case #659177)================ If a non-initialized materialized view or text index was selected in the tree and the Data tab was selected in the right-pane, then attempting to switch from one mode (Design, Debug or Application Profiling) to another would have caused a refresh of the materialized view or text index to be prompted for twice. This has been corrected so that there is now only one prompt. ================(Build #3279 - Engineering Case #656454)================ When connected to a database that contained one or more publications, and the property sheet for a Publication was opened and an Article was selected in the "Subscribe by restriction" tab, the Editor pane at the bottom of the tab would have been disabled except when the 'expression' radio button was checked. When the Editor pane was disabled it was still possible to right click on it to reveal a pop-up menu that allowed for search and replace in the box. The menu is now disabled when the Edit pane is disabled. ================(Build #3278 - Engineering Case #655945)================ On the database Fragmentation tab, the shortcuts for Zoom In (Ctrl++) and Zoom Out (Ctrl+-) did not work with the numeric keypad. This has been fixed. ================(Build #3278 - Engineering Case #644464)================ If a database had two or more 'post_login_procedure' option settings, then attempting to connect to the database would have failed with a "Subquery cannot return more than one row" error. This has been fixed. ================(Build #3273 - Engineering Case #654249)================ The External Environments folder was erroneously including an entry for dbmlsync. This has been fixed. ================(Build #3266 - Engineering Case #652547)================ Altering the schedule for an event to remove a days-of-month specification did not set SYSSCHEDULE.days_of_month to null. This has been fixed. ================(Build #3264 - Engineering Case #651520)================ Displaying the results of an Index Consultant run of a large workload could have required an excessive amount of memory, causing Sybase Central to crash if there was not enough physical memory available. This has been fixed. ================(Build #3262 - Engineering Case #651723)================ Opening a column's Property sheet would have caused the error: "Support for spatial is not available for this CPU", when the server was run on a system with on a Pentium III processor. The same error would also have occurred in the Function and Domain wizards, and the Spatial Reference Systems folder if it was selected in the tree. These issues have been fixed.

SQL Anywhere - Utilities

================(Build #3769 - Engineering Case #715480)================ When using the Unload utility to rebuild a pre-version 10 database, if the connection string contained the server name or the source database name, then the warning 'Rebuild of database with older file format ignoring connection parameter "???"' was printed with question marks for the parameter. This has been fixed so that the parameter name is now displayed in the message. ================(Build #3753 - Engineering Case #712618)================ Setting the isql_allow_read_client_file or isql_allow_write_client_file options in the Interactive SQL utility to 'on' or 'off' had no effect. Interactive SQL would always behave as if the option was 'prompt'. This has been fixed. ================(Build #3751 - Engineering Case #711977)================ The help screen for several SQL Anywhere utilities (viewcert, createcert, dbcloudadd, dbcloudextract, and dbcloudcmd) tried to format the output for terminal display by splitting at 80 characters. When multi-byte characters were used, the splitting could have happened in the middle of a character, causing that character to display incorrectly. This also affected general output from the dbcloudcmd. This has now been corrected. ================(Build #3748 - Engineering Case #711146)================ The Interactive SQL utility has an option to control which result sets from a query to display; just the first one, or all of them. If "Show all result sets" was selected, the widths of columns in the table on the "Results" panels were not automatically sized to show the data. If "Show only the first result set" was selected (which is the default), the columns were automatically sized correctly. This has been corrected. ================(Build #3746 - Engineering Case #711377)================ The text completer for the UltraLite function ML_GET_SERVER_NOTIFICATION would have completed the text as ML_GET_SERVIER_NOTIFICATION (note the extra "I" in "SERVER"). This has been fixed. ================(Build #3744 - Engineering Case #711034)================ The START DATABASE statement includes the following optional clause: CHECKSUM { ON | OFF } Attempting to execute a START DATABASE statement in the Interactive SQL utility with this clause would have resulted in an inappropriate error message which complained of an unexpected keyword. This has been fixed. Engineering Description: The CHECKSUM clause was added in 12.0.0. I'm not sure how this got missed. I noticed the omission when I started to look at adding support for the new MIRROR ON clause of START DATABASE. Behaviour Changes: n/a Admin Tools, Installers and Other Affected Software: n/a Documentation Changes: n/a Testing Requirements: A test was added to the ISQL grammar test suite. ================(Build #3744 - Engineering Case #711000)================ If an invalid value was given for a network protocol option on the Interactive SQL command line, the program could have reported an internal error. This would have happened only for those options which take a set of specific values. For example, running the following command would have crashed as "bogus" is not an allowable value for the "DoBroadcast" option. dbisql -c "links=tcpip(DoBroadcast=bogus)" This problem has been fixed. ================(Build #3744 - Engineering Case #707010)================ In the table of query results, cell values, entire rows, and entire columns, can be copied to the clipboard. When copying a column or multiple cells, the values were always separated by a comma rather than the ISQL field separator string. This has been corrected so that the field separator is now used. Note that the field separator was already being used when copying entire rows of values. ================(Build #3744 - Engineering Case #689907)================ The Interactive SQL utility would not have reported an error if an unknown encoding name was used in the READ statement's ENCODING clause. This has been corrected so that now it does. ================(Build #3738 - Engineering Case #709639)================ On Solaris 11 systems, the default quitting time suggested by the Console utility is one hour later than the current time if daylight savings time is in effect. The solution to this problem is to update the Java Runtime Environment to version 1.6.0_31 or later. Instructions for doing this are contained in a white paper called "Updating the SQL Anywhere Java Runtime Environment", available from the Sybase web site: http://www.sybase.com/detail?id=1058536 There are no code changes for this issue. Note, that this problem does not occur with Solaris 10. ================(Build #3736 - Engineering Case #709208)================ If an INI file was used with the Windows launchers for the Interactive SQL utility, Sybase Central, MobiLink Monitor, the Console utility, or SQL Anywhere Monitor, and the VM arguments exceeded 260 chars, the launcher would have fail. This has been fixed. ================(Build #3709 - Engineering Case #702774)================ When connected to a database which was mirrored, the server name displayed in the Interactive SQL title bar and the server name printed by the DESCRIBE CONNECTION statement, was inadvertently the alternate server name, rather than the main server name. The alternate server names tend to be long and end in a long sequence of letters and numbers. This has been corrected so that the main server name is now always used. ================(Build #3548 - Engineering Case #667179)================ The Start Server in Background utility (dbspawn), when used with -p option to specify the OS process id, was reporting a process id for the started server of 0 on Windows Vista, Windows 7 and Windows 2008. Windows XP, Windows 2003 and Unix were not affected. This has been fixed so that the process id of the started server is reported correctly. ================(Build #3535 - Engineering Case #694489)================ If a connect to a cloud tenant database was made in the Interactive SQL utility, or Sybase Central, by selecting an action of "Connect to a running database in a cloud" in the "Connect" dialog, and then the connection was disconnected, opening the "Connect" dialog again would not have had the "Action" box initially set to "Connect to a running database in a cloud". This has been corrected so that now it is. ================(Build #3533 - Engineering Case #693999)================ When using the Unload utility (dbunload), if an APPINFO connection parameter was specified for the source database (-c option), the APPINFO value was ignored and a warning message printed stating such. This bahaviour has now been changed, the APPINFO value is now passed to the source database and a warning message is printed stating that the rebuild may fail if the source database has an older file format (version 9.0 or older). Connections to the target database (-ac option) are unaffected by this change. Both the previous and new behaviour is to pass the APPINFO value to the target database. ================(Build #3525 - Engineering Case #692376)================ After the changes for Engineering case 666434 ("dbisqlc could report errors when using output redirection for nested READ statements"), dbisqlc did not always correctly close all files opened for READ statements. If enough files were opened for READ statements during a session, dbisqlc could have reported "too many open files". This problem has been fixed. ================(Build #3513 - Engineering Case #691215)================ Different system catalog views, DESCRIBE, and the dbunload schema information, showed different base type names for the domain Signed Integer. The base type names shown were "int" or "integer". This has been fixed. Now the base type name "integer" is consistently returned. ================(Build #3512 - Engineering Case #692249)================ On Mac OS X 10.7 Lion, the Java administration tools (Sybase Central, Interactive SQL, etc) would have silently failed if Java was not installed. Previous versions of Mac OS X included a Java runtime, but on Lion it is a separately installed component. Use the following method to initiate the Java runtime installation or confirm it is currently installed: 1.Go to Applications > Utilities > Java Preferences. 2.Open the Java Preferences. 3.If Java is not installed, you receive the following message: “To open “Java Preferences," you need a Java runtime. Would you like to install one now?” 4.Click Install and follow the prompts. The Java runtime is downloaded and installed. ================(Build #3512 - Engineering Case #691657)================ When using the Deployment Wizard, a temporary list of files is generated to pass over to makecab.exe based on the temporary directory path (%TMP%); e.g. makecab.exe /F C:\DOCUME~1\user\Local Settings\Temp\1\sql6.tmp. If the %TMP% variable contained a space, this would not work correctly, although the MSI file would still have been generated, but it would not have contained the necessary files. This has been fixed. ================(Build #3491 - Engineering Case #689167)================ After using the "Find" button to find a network server, the message "You cannot use the Host connection parameter and advanced network parameters at the same time." could have been returned, even though nothing was specified on the "Network" tab. For this problem to have occurred, the "Action" field had to have been set initially to "Connect to a running database on nother computer". The problem would not have occurred if the "Action" value had been changed prior to clicking the "Connect" button. This has been fixed. In a related issue, the above error message should have been displayed, but was not, in a number of other cases. This has also been fixed. ================(Build #3477 - Engineering Case #685205)================ When unloading a database, comments for unique constraints were not included in the reload.sql file. This has been fixed. ================(Build #3466 - Engineering Case #685857)================ When inserting a value into a FLOAT column, an error would have been given if the absolute value of the number was too big, or too close to zero. This has been fixed. Now, an error will only be given if the absolute value of the number is too big. If the number is too close to zero, it will be set to zero and inserted without an error. ================(Build #3465 - Engineering Case #685873)================ When using the Service utility (dbsvc) for Windows to delete a service that was currently running, the following messages were displayed: The specified service is running. The service will be deleted when it is stopped. Service "<svc name>" was deleted successfully. This has been fixed. If the service is running, only the first message is displayed, otherwise only the second is displayed. ================(Build #3449 - Engineering Case #680770)================ When unloading a database, GRANT INTEGRATED/KERBEROS statements containing square brackets were written in the reload.sql file. These statements would have would have generated an 'unexpected statement' error when executed. This has been fixed by always putting double quotes rather than square brackets around the user identifier. ================(Build #3448 - Engineering Case #683704)================ Whenever the Server Licensing utility (dblic) was used with the -k option (to specify a new registration key), the registration key was being written to the license file. This should not have been done for add-on keys such as the High Availability option, and has now been corrected. ================(Build #3433 - Engineering Case #683177)================ The Interactive SQL utility would have crashed if the "Show progress messages" option was modified in the "Options" window while not connected to a database. This has been fixed. ================(Build #3418 - Engineering Case #680917)================ Interactive SQL contains a number of menu items for selecting the current, previous, and next statements. These menu items could hale selected more than just the statement text, or could have selected nothing at all if the statement being selected included the text "IF NOT EXISTS". For example: CREATE TABLE IF NOT EXISTS t ( c INT PRIMARY KEY ) This has been fixed. Now, statements are selected properly. This same problem also affected the behavior of the "Single Step" menu item which also relies on being able to select the next statement. ================(Build #3413 - Engineering Case #680348)================ When the Text Completer completes a table, view, or procedure name, the owner name is now added if the name would be ambiguous without it. Previously, the owner name could have been added when it wasn't necessary. This has been fixed. ================(Build #3409 - Engineering Case #679415)================ Reloading a database that contained a table that referenced a sequence could have failed. This has been fixed. As a work around, the "Create sequences" section could be manually moved to before the "Create tables" section in the reload.sql file. ================(Build #3409 - Engineering Case #676224)================ If a database had a publication defined using the "download only" or "scripted upload" clauses, but had not defined any synchronization users or synchronization subscriptions, then when a dbunload was run on the database, the "download only" or "scripted upload" clauses of the publication would not have been maintained. This problem has been fixed. A workaround to this issue would be to add any synchronization user or synchronization subscriptions to the database. For example, if a publication "p1" was defined for download only, execute "CREATE SYNCHRONIZATION SUBSCRIPTION TO p1 TYPE 'tcpip'". This would define TCP/IP as the default communication type when synchronizing the publication, which is the default that would be chosen anyway. ================(Build #3405 - Engineering Case #676727)================ When editing a TIMESTAMP column value in the "Results" panel, the editor did not distinguish between AM and PM, always assuming AM. This has been corrected so that the editor now distinguishes between the two. ================(Build #3400 - Engineering Case #676844)================ Attempting to perform an unload with reload of a database, using the Unload utility or the dbtools DBUnload function, may have failed with a "Cannot find index named ...' error if the index had a comment. This problem has now been fixed. ================(Build #3391 - Engineering Case #674748)================ Attempting to unload and reload a SQL Anywhere database from version 10.0.0 and later could have failed if the database contained a large number of integrated logins, and several of the integrated logins had comments associated with them. This problem has now been fixed. ================(Build #3388 - Engineering Case #676033)================ When a statement cannot be executed by the Interactive SQL utility, the error is displayed in an error window. That window contains a "Help" button which, which clicked, can display a menu of relevant help topics (for the error message and for the type of statement being executed). Opening this error window could have taken a non-trivial amount of time if the online documentation for SQL Anywhere was not installed. In those cases, the software had to check with the DocComment Exchange (DCX) server to see if help was available for the statement in question. While the Interactive SQL utility is doing this check, it could be unresponsive. The problem was most acute on machines that were not connected to the internet at all. This has been fixed so that the error dialog opens without delay, and Interactive SQL remains responsive at all times. ================(Build #3385 - Engineering Case #675496)================ Explicitly opening the Text Completer when the "SQL Statements" field contained only matching parentheses would have caused the Interactive SQL utility to crash. This has been fixed. ================(Build #3383 - Engineering Case #675147)================ The Interactive SQl utility's Import wizard usually remembers the names of recently-imported files and presents them in the combo-boxes where a file can be selected to import. A bug was preventing the list of file names from being remembered. This has been fixed. ================(Build #3382 - Engineering Case #674931)================ The 32-bit versions of Sybase Central, the Interactive SQL utility, the Console utility, and the MobiLink Monitor, could have failed to start on 32-bit Windows systems under "low" memory conditions. The point at which memory becomes low is difficult to quantify, and depends heavily on the number of other programs running on the machine, and their locations in memory. This has been fixed. As part of this change, the message that is displayed when the Java Virtual Machine can't start has been improved to include the actual JVM error. ================(Build #3375 - Engineering Case #674024)================ The toolbar buttons in the Interactive SQL utility were not enabled if a stored procedure was executed from Sybase Central and the procedure completed with errors. This has been corrected so that the toolbar buttons are now enabled correctly. ================(Build #3374 - Engineering Case #674063)================ When typing a single-line SQL comment, the Text Completer could have opened while typing. This has been corrected so that the Text Completer remains hidden unless it is explicitly opened. ================(Build #3374 - Engineering Case #673852)================ With both 32 bit and 64 bit versions of SQL Anywhere installed on a 64 bit Windows system, using the Deployment wizard to create a 32 bit install would have displayed the 64-bit UltraLite feature. Attempting to install the MSI that was created in this way on a 32-bit Windows system would have caused the following error: Module C:\Program Files\SQL Anywhere 12\BIN64\ulodbc12.dll failed to register. HRESULT -2147024703. Contact your support personnel. This has been fixed. ================(Build #3368 - Engineering Case #669572)================ If the Service utility (dbsvc) was used to shut down a service, and the service took a long time to shut down, dbsvc may have reported that an error occurred. For example, if checkpointing one of the databases took longer than 3 seconds. The server would still have shut down eventually. This has been fixed. ================(Build #3364 - Engineering Case #669412)================ When run on Linux systems, the Service utility (dbsvc) requires the LSB init-functions. Some Linux distributions do not installed by default so the must be installed manually in order to use dbsvc For example, on Fedora, run the following command: yum install redhat-lsb redhat-lsb.i686 ================(Build #3363 - Engineering Case #672088)================ The Extraction utility could have incorrectly extracted an event from a consolidated database for a user that would be not be created in the remote database. This has now been corrected. ================(Build #3354 - Engineering Case #670521)================ Attempting to modify NCHAR, NVARCHAR or LONG NVARCHAR values, using the scrolling table in the "Results" panel, would have silently failed if the value was loaded from a file. This has been fixed. ================(Build #3353 - Engineering Case #669783)================ The Update Checker could have informed that there were updates, even when it had been asked not to. Specifically, if there had been a new documentation release (in a new language, say), and the Uupdate Checker had been configured to not show informational messages, you would still have been notified. This has been fixed. ================(Build #3351 - Engineering Case #670020)================ The Support utility (dbsupport) may have silently failed to submit diagnostic information if it was a first-time submission. This has been fixed. ================(Build #3350 - Engineering Case #669411)================ When run on some Linux distributions, the Interactive SQL utility (or any of the graphical administration tools) may not have displayed Chinese characters correctly. This has been fixed. Workaround: 1. Shut down any graphical administration tools (Sybase Central, Interactive SQL (dbisql), the MobiLink Monitor, SQL Anywhere Monitor, or SQL Anywhere Console utility (dbconsole) that are running. 2. Run the following commands: mkdir $SQLANY12/sun/jre160_x86/lib/fonts/fallback ln -s /usr/share/fonts/truetype/arphic/*.ttc $SQLANY12/sun/jre160_x86/lib/fonts/fallback ln -s /usr/share/fonts/truetype/wqy/*.ttc $SQLANY12/sun/jre160_x86/lib/fonts/fallback ================(Build #3347 - Engineering Case #669218)================ Using an encrypted command file did not work on big endian computers (typically running Solaris or AIX). The symptom was an error message "Could not decrypt command file." This has been fixed. ================(Build #3344 - Engineering Case #666960)================ When connected to an ASE database, the "Help" menu could have contained redundant separators. This has been fixed. ================(Build #3343 - Engineering Case #668397)================ The SQL Passthrough feature was removed in version 12 and three associated tables (sync_passthrough_progress, sync_passthrough_script, and sync_passthrough_status) were dropped. The Unload utility did not properly handle the case where a pre-version 12 database contained these tables and they were not empty. This has been fixed. ================(Build #3340 - Engineering Case #667932)================ For a table with no foreign keys, SQLForeignKeys would have returned a single row with NULLs in most columns. This problem could have resulted in a java.lang.NullPointerException in the Interactive SQL utility's Query Editor. This has been fixed so that when the table has no foreign keys, no rows will be returned. ================(Build #3329 - Engineering Case #666434)================ When using output redirection for a READ statement that referenced a file containing another READ statement, the dbisqlc utility would have reported an error such as "invalid file number". This problem has been corrected. Example: "READ file1.sql >& output.txt" file1.sql: read file2.sql go SELECT ... file2.sql: SELECT ... ================(Build #3329 - Engineering Case #665710)================ When executing a SELECT statement such as "(select 1)" that begins with open parenthesis, the dbisqlc utility would have reported a syntax error. This problem has been fixed. ================(Build #3327 - Engineering Case #665673)================ If the Interactive SQL utility was launched from a program using the Apache Portable Runtime, and standard output and/or standard error file handles were redirected, an internal error could have been reported. This has been fixed. ================(Build #3326 - Engineering Case #663937)================ In the Interactive SQL utility, setting the "on_error" option to "continue" was not preventing warnings from being displayed in a popup window. This has been corrected so that when the option is set to "continue", warnings are now displayed in the "Messages" pane. ================(Build #3325 - Engineering Case #665670)================ The execution tree in the Plan Viewer window could have partially obscured the bottom part of the tree drawing if a display option for the plan was changed to make it larger (by turning on "Show percent cost", for example). This has been fixed. ================(Build #3324 - Engineering Case #637476)================ Importing data from a database that was not a SQL Anywhere or UltraLite database into an UltraLite database, using the Interactive SQL INPUT statement or the Import Wizard, could have failed. This would have occurred if a new table was to be created for the imported data and the data contained one or more INTEGER columns. This has been fixed. ================(Build #3321 - Engineering Case #662766)================ When using the Deployment wizard to build an MSI install containing both 64-bit and 32-bit software, the jvm.dll in the sun\jre160_x64\bin\server directory was being replaced by the 32-bit version. This could have occurred whenever two different files were included with the same name, in a directory with the same name, and with the same parent directory. This has been corrected. ================(Build #3314 - Engineering Case #637446)================ Exporting TIME values to a DB2 database with an OUTPUT USING statement in the Interactive SQL utility would have failed. This has been fixed. ================(Build #3311 - Engineering Case #663786)================ The Server Enumeration utility (dblocate) may have failed to list some running database servers if many (over around 50) servers were running in the TCP/IP subnet. This problem was more likely if the -d option ("brief list of databases running on each server"). This has been fixed by increasing the UDP receive buffer size used by dblocate. For some Unix/Linux operating systems, in order for this change to take effect, the system maximum UDP receive buffer size may need to be increased. On Linux, this can be done by increasing the sysctl net.core.rmem_max setting. ================(Build #3308 - Engineering Case #663279)================ Clicking the "Stop" toolbar button in the Interactive SQL utility often did not stop execution if many short-running statements were being executed. It did work correctly if executing a single long-running statement. This has been fixed. The workaround for this problem is to use the SQL->Stop menu item, which always works. ================(Build #3305 - Engineering Case #663123)================ Creating an ODBC data source for IQ from the Connect dialog did create a DSN, but it was not created correctly. The following issues have been fixed: 1. The driver name for the data source was always "SQL Anywhere 12" rather than "Sybase IQ". This prevented the data source from being listed in the "Data Source Names" window unless you checked "Show all data sources". Also, to connect using the data source, the SQL Anywhere ODBC driver had to be installed. 2. Creating a system data source would fail on machines that did not have "dbdsn" installed. This would be a problem on computers running Vista or Windows 7 which have IQ installed, but not SQL Anywhere. ================(Build #3304 - Engineering Case #662944)================ On Mac OS X, the tool tips for the "zoom in", "zoom out", "reset view", and "save image" buttons in the "Value of Column" dialog indicated that the Control key should be held down to activate the button. This was incorrect, it should have shown the Command key. This has now been fixed. ================(Build #3303 - Engineering Case #656680)================ The Interactive SQL utility could have become unresponsive when executing a statement which returned a result set if the entire result set cannot be returned due to a row lock. This has been fixed. ================(Build #3301 - Engineering Case #662233)================ The connection properties on the Advanced page of the Connect dialog were not filled when attempting to reconnect following a disconnect. For this problem to have occurred, the IQ plug-in for the Interactive SQL utility would needed to have been loaded. That plug-in is loaded by default starting in version 12.0.1. A similar problem affected the TLS packet encryption parameters on the Network page. Both of these problems have now been fixed. ================(Build #3295 - Engineering Case #660005)================ If a file was opened in the Interactive SQL utility and then the window was closed, the file would still have been locked by the dbisql process if the "Enable fast launcher" option was on. This has been fixed. ================(Build #3292 - Engineering Case #659337)================ SQL changes in the Plan Viewer and Spatial Viewer windows were ignored if the Editor component had been selected, "Options" was clicked and then dismissed by clicking "OK". This has been fixed. This issue had at least one other symptom: If a file was opened, "Options" for the editor was selected, either by right-clicking as described above or by opening the Options window, then clicked "OK", subsequent changes in the Editor would not have caused the Interactive SQL utility's window title text to include an asterisk. The asterisk indicates that there are unsaved changes in the editor. ================(Build #3292 - Engineering Case #659140)================ The text completer may not have suggested any matches if there was an empty single quoted string earlier in the statement, or in a previous statement. This has been fixed. ================(Build #3289 - Engineering Case #658334)================ If a database option value contained a single quote, the reload script generated by the Unload utility would have resulted in a syntax error when the database was reloaded. This has been fixed. ================(Build #3286 - Engineering Case #653316)================ When deleting rows from an UltraLite database, the Interactive SQL utility would have incorrectly reported the number of rows affected by a DELETE. The message "1 row(s) deleted" would have been shown in the Message pane, regardless of how many rows were deleted. This has been fixed. ================(Build #3285 - Engineering Case #657324)================ Installations created by the Deployment wizard were to be missing the following files from the assembly\v2\ directory: iAnywhere.Mobilink.Client.dll iAnywhere.QAnywhere.Client.dll iAnywhere.QAnywhere.Resources.dll iAnywhere.QAnywhere.ws.dll These files were being installed in the Global Assembly Cache (GAC), but an additional copy was not also put in the assembly\v2 directory. This has been corrected so that these files are now installed in both locations. ================(Build #3281 - Engineering Case #658169)================ When using the Service utility (dbsvc) for Linux to create an automatic service (when the machine boots) on Linux SUSE 11 for the SQL Anywhere server, the server may have started before the network service had been started. As a result, some applications running inside the SQL Anywhere server may have failed to work properly. This issue would have affected SQL Anywhere Server Monitor deployments. This has been fixed. ================(Build #3281 - Engineering Case #656897)================ Attempting to execute a SQL statement that was made up only of full-width space characters (U+3000, the "Ideographic Space") would have caused the Interactive SQL utility to crash. This has been fixed. ================(Build #3278 - Engineering Case #637456)================ Attempting to import NCHAR types from ASE using the INPUT statement or the Import Wizard, would have failed with the message "Cannot convert '' to a varbit". This has been fixed. ================(Build #3278 - Engineering Case #631019)================ Two issues relating to using the INPUT and OUTPUT statements (and their corresponding wizards) to move data between SQL Anywhere and ASE have been fixed. Importing a table from ASE which had TIMESTAMP columns into a new table would have failed. The ASE TIMESTAMP type was being misinterpreted as being equivalent to the SQL Anywhere TIMESTAMP type, which is false. Exporting data from SQL Anywhere into ASE would have reported various conversion issues for SQL Anywhere DECIMAL values. ================(Build #3277 - Engineering Case #655607)================ The text in the Favorites sidebar could have disappeared if the mouse was moved over it. This has been fixed. ================(Build #3275 - Engineering Case #654981)================ The Console utility could have stopped refreshing connection properties after changing the set of properties which were displayed, even after restarting DBConsole. This has been fixed. ================(Build #3274 - Engineering Case #654636)================ Opening a .saplan file in the "Plan Viewer" window and clicking the "Print" button did not do anything. This has been corrected so that it prints the plan. There was no problem printing plans which were generated by clicking the "Get Plan" button. ================(Build #3274 - Engineering Case #654635)================ If HTMLHelp documentation for SQL Anywhere was installed, it was possible for the Index Consultant to open DCX help under some circumstances. This has been fixed. ================(Build #3274 - Engineering Case #654425)================ In the Options window, the components for editing the quitting time were enabled even if the "Quitting time" checkbox was not checked. Now, the components are disabled when the checkbox is not checked. ================(Build #3274 - Engineering Case #654253)================ In versions of the Interactive SQL utility 10.0.0 and later, using an ISQL parameter for the value of an option in a SET OPTION statement did not work because the parameter was not substituted correctly. This has been fixed. ================(Build #3270 - Engineering Case #653743)================ The Import wizard would have reported an internal error when importing a shapefile if no spatial reference system was selected. This has been fixed.

SQL Anywhere Monitor - SQL Anywhere Monitor

================(Build #3762 - Engineering Case #714654)================ If a cloud database became unavailable, and it was being monitored by the SQL Anywhere Monitor, the alert details would have claimed the server name to be 'null'. This has been fixed. ================(Build #3746 - Engineering Case #711380)================ In the SQL Anywhere Monitor, the sparkline for a metric was usually drawn empty. This has now been fixed. ================(Build #3605 - Engineering Case #701635)================ Creation of a SAMonitor resource to monitor Relay Server farms via HTTPS may have failed, while HTTP worked. This would have happened when the Relay Server address specified in the Relay Server configuration file was missing the domain suffix. Even when the load balancer address given to the SAMonitor was a FQDN, the resource creation may have failed. This has now been fixed by making the monitor attempt its best effort to apply the domain suffix of the load balancer to the Relay Server address when it is missing while HTTPS is in use. If any of the Relay Server addresses, or the load balancer address, are specified in IPv6 or IPv4 numeric notation, then this fix will not kicks in and authentication will continue to fail. Use of FQDNs is required by the SAMonitor when HTTPS is used. ================(Build #3531 - Engineering Case #693900)================ The SQL Anywhere Monitor database gathers monitoring data over time, and this data is reduced according to the maintenance settings. If data reduction settings allowed more data to be gathered than the default settings, when the maintenance plan did run it may not have been able to successfully prune the gathered data. This has been fixed. ================(Build #3478 - Engineering Case #687567)================ The SQL Anywhere Monitor may have missed counting some uncommon Relay Server errors. These errors were: FARM_CHANNEL_CONNECT_WITH_INVALID_SERVER_IDX 2006 SERVER_DISCONNECT_EARLY 3014 FARM_FAIL_ACCESS 12000 SERVER_FAIL_NEWING_CLIENT_STATISTIC 13011 This has been fixed. ================(Build #3472 - Engineering Case #686586)================ A lengthy Relay Server alert may have been corrupted by having extra non-break space tokens (&nbsp;) broken up by exclamation marks. This has been fixed. ================(Build #3353 - Engineering Case #669738)================ The memory used by the Java process spawned by the SQL Anywhere Monitor could have grown without bound if there were MobiLink collectors. It would have grown faster when the MobiLink servers were consistently unreachable. This has been fixed. ================(Build #3342 - Engineering Case #668136)================ An SQL Anywhere resource may have generated an alert for "No Recent Backup Recorded", even though a client-side backup had recently been done. This has been corrected so that the alert now clearly indicates that it pertains to server-side backups only. ================(Build #3328 - Engineering Case #666566)================ After performing an unload of a resource database, the SQL Anywhere Monitor server console would have shown 'Permission denied' errors for serveral system procedures. Graphing the metrics for "free disk space" would have displayed incorrect values (a horizontal line as if nothing changed). This is caused by the server policy to preserve permissions granted or revoked on objects owned by dbo user that are created in a newly initialized database. The following describe the steps required to correct this whenever an unload of a database is performed: 1. log in to SQL Anywhere Monitor Web UI as the user 'administrator'. 2. click Administrator on the left pane to open an Administrator dialog 3. under Resource tab, select the resource that had been dbunloaded 4. click Stop button to stop monitoring the resource 5. click Repair... and enter DBA uid/pwd to repair the resource database 6. after done, click Start to start monitoring the DB After the above steps, the resource should function correctly. ================(Build #3315 - Engineering Case #664506)================ Steady Relay Server metrics, like peak values, values associated with idle farms, and idle error counts, may not have shown correctly in graphs inside the SQL Anywhere Monitor. The work around is to view them as current values instead of graphing. This issue has been fixed. ================(Build #3310 - Engineering Case #663573)================ The SQL Anywhere Monitor's server console, would have shown the following incorrect error message: [Sybase][JDBC Driver][SQL Anywhere]Could not load dynamic library 'dbsrvmon11' (SQLCODE: -620, SQLSTATE: HY000) An incorrect version number being assigned when a monitor object was removed. This has been fixed. ================(Build #3304 - Engineering Case #662942)================ Charting metric data may have omitted some ending data points. This has been fixed. ================(Build #3288 - Engineering Case #658458)================ When editing options for configuration, but not editing Data Reduction, a warning message for Data Reduction was displayed. This has been fixed. ================(Build #3284 - Engineering Case #657448)================ The aggregated time increment used to calculate the following metrics were not divided by the request count increment before plotting to the graphs: "Average Request time" "Average Backend server processing time" "Average Response time" "Average Request Completion time" The problem has been fixed. ================(Build #3281 - Engineering Case #656660)================ During a Relay Server outage, the SQL Anywhere Monitor did not display the the "Unavailable since" time, but cleared the "Up since" time only. A farm outage alert was also not raised. Only a sustained outage alert was raised after the threshold time elapsed. When the Relay Server came back up again, data collection did not resume and the "Up since" time was not updated. These problems have now been fixed. ================(Build #3281 - Engineering Case #656645)================ Dates shown in the Graph widget were localized but not in the correct order (they showed "MM DD" instead of "DD MM"). This has been fixed. ================(Build #3277 - Engineering Case #655599)================ It was not possible to drag and drop the second operators in the Add Resource page. This has been fixed. ================(Build #3277 - Engineering Case #655570)================ The tab order on the Edit Configuration:Maintenance tab was not correct.. This has been fixed. ================(Build #3277 - Engineering Case #655544)================ The 'Next' button and the 'Create' button were disabled in the Add Resource page when an invalid time was entered. This has been fixed.

SQL Remote for SQL Anywhere - Database Tools Interface

================(Build #3764 - Engineering Case #714642)================ If SQL Remote had failed to find a publisher for the database it was connected to, it would have continued to run and could have generated a large number of duplicate messages for a single remote user. This has been corrected so that SQL Remote will now shut down when it determines there is no publisher. ================(Build #3433 - Engineering Case #683159)================ When SQL Remote was running in continuous mode, if the max_retries message system parameter had been set, and a message was generated because the maximum size of the message had been reached before the next send phase, then SQL Remote would have incorrectly believed that an error had occurred when sending the message. SQL Remote would then have paused for the number of seconds specified by the pause_after_failure message system parameter. This problem has now been fixed. ================(Build #3365 - Engineering Case #672208)================ The changes for Engineering case 655157 introduced a problem such that when multiple consecutive pinging messages appeared in the incoming message box, SQL Remote would have generated the warning message: Deleting duplicate message from ... and then deleted the duplicate pinging messages. This problem is fixed so that all the duplicate pinging messages are now processed without complaint.

SQL Remote for SQL Anywhere - Extraction Utility for Adaptive Server Anywhere

================(Build #3527 - Engineering Case #693255)================ If the publisher's address for a database contained a UNC path, or if the address for a remote user contained a UNC path, the Unload and Extraction utilities would have failed to escape the string properly, resulting in an address in the new database with missing backslash characters. This has now been fixed.

SQL Remote for SQL Anywhere - Ftp Messaging for Adaptive Server Anywhere

================(Build #3411 - Engineering Case #679803)================ SQL Remote would have generated the following error message: "The address given is invalid. The address must be a directory name with no path separators." and then aborted the message receiving thread when it was able to retrieve all the names of the message files in the given directory from a FTP server, but for some reasons (such as network problems) was not able to retrieve the contents of a file from the server. This problem is fixed so that the error message is now: "Unable to retrieve message file 'xxxx' from the FTP server."

SQL Remote for SQL Anywhere - SQL Remote for Adaptive Server Anywhere

================(Build #3405 - Engineering Case #678597)================ When running in a continuous mode, SQL Remote would have leaked about 10 kilobytes of memory in every attempt of sending messages to its subscribers. This problem has now been fixed. ================(Build #3367 - Engineering Case #667109)================ If SQL remote (dbremote) was running in continuous mode, it was possible for it to have have reported "Execution Complete", but no errors or warnings would have been printed to the dbremote log indicating why the process had stopped. This has been fixed. ================(Build #3297 - Engineering Case #660813)================ If the database was blank padded and the database option Compression was set to be -1, .SQL Remote would have logged the following warning message in its output file: Option DBA.Compression contains invalid value -1 The value -1 is a valid value, it was the blank padding that was causing the option to be treated as invalid. This problem has been fixed. ================(Build #3278 - Engineering Case #656093)================ The Log Translation utility (dbtran) and SQL Remote could left temporary files undeleted after execution. This has been fixed. ================(Build #3277 - Engineering Case #655351)================ Temporary files created by SQL Remote and Log Translation utility may not have been deleted. This problem has been fixed.

Sybase Central Java Viewer - Java Viewer

================(Build #3407 - Engineering Case #677800)================ When editing the SQL for a web service in the service's Property sheet, if the Text Completer was open when the Property sheet was closed, Sybase Central would have reported an internal error. This has been fixed. ================(Build #3404 - Engineering Case #678229)================ If the remote database schema in a synchronization was updated from an existing remote database that had the same schema, except for the case of identifiers (such as table names or owner names), errors could have resulted. The table mappings would have become invalid, clicking on such a table mapping would have caused an unexpected error dialog, and script generation errors could have occurred. This has been corrected.

UltraLite - Analyser Java Classes

================(Build #3340 - Engineering Case #667934)================ The attempt to add a second primary key was not diagnosed in an ALTER TABLE statement. This has been corrected.

UltraLite - Runtime Libraries

================(Build #3718 - Engineering Case #704611)================ An index on a binary column could have become corrupt if it contained binary values shorter than the hash size for the table. This has been fixed. ================(Build #3715 - Engineering Case #703801)================ HTTPS synchronizations using iOS 5 to a Windows (or Linux) Mobilink server, could have failed with secure handshake errors. The synchronization would have worked to a Mac OS X Mobilink server. This is now fixed. ================(Build #3709 - Engineering Case #702761)================ Synchronizations would have failed if the length of the parameter string for a sync profile was larger than 64K. The error reported could have varied, but SQLE_SYNC_INFO_INVALID would have been most likely. This error could have occurred with the .NET API if the application set sync authentication parameters whose total length approached or exceeded 64K. This problem has now been corrected. ================(Build #3589 - Engineering Case #699971)================ The index hash for Timestamp with Time Zone columns was not properly incorporating the offset component. This could have lead to an incorrect ordering of timestamp values that had varying timezone offsets. This has been fixed. ================(Build #3588 - Engineering Case #699839)================ A hashing algorithm used to speed the access to rows with indexes involving timestamp with time zone columns, in rare conditions, could have performed slightly worse than optimal. This has been fixed. ================(Build #3584 - Engineering Case #699687)================ The UltraLite runtime now supports RSA TLS and HTTPS on Pocket PC 2003 devices. There is no support for ECC or FIPS. ================(Build #3572 - Engineering Case #698048)================ When using Xcode 4.2 and running armv6 code (i.e., after enabling armv6 and running on 'iPhone 3G' or earlier), UltraLite may have corrupted double (floating point) values stored in the database. This has been fixed. As this seemed to be a compiler issue, it may be better to use an older version of Xcode when targeting these older armv6 devices. Note that switching between Clang and LLVM-GCC will not resolve this issue. A workaround has been implemented to avoid the problem with double values, but the above note still applies. ================(Build #3567 - Engineering Case #697464)================ A synchronization using end-to-end encryption could have crashed on the iPhone. This has been fixed. ================(Build #3558 - Engineering Case #696667)================ Upgrading an UltraLite database schema by executing "ALTER DATABASE SCHEMA FROM FILE", could have resulted in corrupt indexes. This has been fixed. ================(Build #3493 - Engineering Case #688896)================ If an application crashed during synchronization it was possible that subsequent sync attempts would have failed with server errors. The MobiLink server would have reported a progress mismatch and the log could have shown multiple instances of the same publications. This has been fixed. ================(Build #3490 - Engineering Case #689047)================ An HTTP or HTTPS synchronization through the Relay Server could have failed with stream error STREAM_ERROR_HTTP_HEADER_PARSE_ERROR. This has been fixed. ================(Build #3488 - Engineering Case #676102)================ Inserting Unicode strings into a database using an MBCS/ANSI encoding (that is, not UTF-8) could have resulted in corruption of the strings and possibly unbounded store growth. Unicode strings are inserted using the wchar methods in the C++ API, or using .NET. The Unicode conversion routines to and from wchar were not correct and have been fixed. ================(Build #3486 - Engineering Case #688468)================ The UltraLite runtime library for iPhone would have failed to build with recent Xcode/SDKs (Xcode 4.2 with iOS 5.0 SDK, for example), as gcc-4.2 was no longer being shipped (the command wais not found while trying to run build.sh). This has been fixed by having the UltraLite runtime makefile now simply use 'gcc'. This problem can be worked-around by creating a symlink for gcc-4.2 -> gcc in the /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin and similar Simulator directories, or by modifying the makefile or build.sh used by UltraLite. ================(Build #3461 - Engineering Case #685284)================ If a synchronization failed during the upload, subsequent changes to the database would not have been uploaded in the next synchronization, but in the synchronization after that. This has been fixed. ================(Build #3437 - Engineering Case #683555)================ The UltraLite Database Unload utility (ulunload) would not have preserved the download-only table attribute when unloading a database. This has been corrected. ================(Build #3437 - Engineering Case #683552)================ If an UltraLite application was suddenly terminated (application crash, device reset, etc.) while a transaction was in progress, and the partial transaction was flushed to the database file by another commit or checkpoint, rows were not properly rolled back on subsequent restart. This has now been corrected. ================(Build #3422 - Engineering Case #681956)================ Calling the ULConnection methods SetSyncInfo() or ULSetSynchInfo() with a ul_sync_info, where both the auth_parms and additional_parms were non-null, would have created a sync profile where one of the additional_parms had been made into an auth_parm. This has been fixed. ================(Build #3419 - Engineering Case #681424)================ On Windows Mobile devices, calling GetStringLength(), on a ULValue returned from any of the schema methods in ulcpp11.cpp, could have returned 0 even if it was a valid non-zero length string. This has been fixed. ================(Build #3374 - Engineering Case #673856)================ Sometimes the TLS internal communication error (220) was reported without a useful system error code (e.g. Certicom error code) for further analysis. This has been corrected. ================(Build #3363 - Engineering Case #672094)================ Renaming a table that was marked as no-sync or all-sync would have changed it to a normal synchronizing table if the new name didn't have the "_nosync" or "_allsync" suffix. This has been fixed. The table will now retain its old sync type unless the previous name did have one of the special suffixes ("_nosync", "_allsync", and "_download_only") and the new name does not since a change to the sync type is implied by the removal of the special suffix. ================(Build #3348 - Engineering Case #668396)================ Join queries with predicates in the WHERE or ON clauses that involved columns not in indexes have now been improved. ================(Build #3315 - Engineering Case #664633)================ A synchronization using FIPS end-to-end-encryption could have corrupted a FIPS encrypted UltraLite database. This has been corrected. ================(Build #3302 - Engineering Case #662477)================ When resuming a download, the sent and received statistics are restored from the previous sync and continue as expected from that point, except the byte counts, which were reset to zero. This has now been fixed. The byte counts (like the row statistics) are cumulative for resumed downloads. These statistics are available to the synchronization observer callback and are contained in the sync-results object. ================(Build #3300 - Engineering Case #662074)================ The following UltraLite resumable-download problems are now fixed: In rare cases, UltraLite incorrectly computed where to resume the download. When this occurred, the subsequently resumed download was effectively corrupted, likely causing a synchronization error. (To recover, the download must have been rolled back.) When resuming a download, the server continued to use the original 'timeout' specification, but UltraLite used the default. If a non-default timeout value was specified, the resumed download may have timed out even though the network connection was fine (though it still maked progress). Sometimes the sync-info (or sync-result) 'partial_download_retained' flag was false after trying to resume a download when there was still a partial download present. (Workaround is to only make use of this flag when first set - attempting to subsequently resume when there is no partial download is safe and returns an error.) As well, the following problem is fixed: The COMMITTING_DOWNLOAD sync observer state was signaled later than it should have been. The observer saw UltraLite was still receiving the download, when in fact it had begun committing the download. ================(Build #3295 - Engineering Case #660263)================ Incorrect results were possible for a deeply nested (at least a depth of three) aggregate subquery. This has been corrected. ================(Build #3295 - Engineering Case #659922)================ A syntax error could have been incorrectly generated for an outer reference occurring in a subquery containing another nested subquery, where the outer reference was to the right of the nested subquery. This has been corrected. ================(Build #3290 - Engineering Case #658549)================ Result set rows could have been presented in an incorrect order when all of the following conditions were present for a SQL query: - An index existed in which the first column (say col1) was specified to be in descending order - The query contained a search condition of the form "col1 LIKE expression" where the expression started with non-wildcard characters. - The query contained an ORDER BY starting with col1 This has been corrected. ================(Build #3275 - Engineering Case #654684)================ References to derived table columns may have been incorrect when temporary tables were present and the derived table was used to load the temporary table. This has been corrected. ================(Build #3275 - Engineering Case #654648)================ The substr() function was permitting LONG VARCHAR values to be used as the first argument to the function. This has been corrected ================(Build #3272 - Engineering Case #653884)================ The Mobilink Server would have logged the error "Light weight poll request failed" after every poll attempt from an Ultralite client (through the use of the ML_GET_SERVER_NOTIFICATION function), even if the polls were actually successful. This has been fixed

UltraLite - Sample Application

================(Build #3530 - Engineering Case #693690)================ When the 'CustDB' sample was loaded into Xcode 4.2, several warnings would have been reported. Even after this change, there will still be a prompt to remove the obsolete 'PREBINDING' build setting. It is recommended that this build setting be removed. The other warnings have been addressed. The most significant change is that the project format has been upgraded to Xcode 3.2-compatible format. Some other minor enhancements have also been made to the sample, such as specifying the UltraLite temp_dir. See the DataAccess class' openConnection method for more details. ================(Build #3529 - Engineering Case #693569)================ When the 'Names' sample was loaded into Xcode 4.2, several warnings would have been reported. Even after this change, there will still be a prompt to remove the obsolete 'PREBINDING' build setting. It is recommended that this build setting be removed. The other warnings have been addressed. The most significant change is that the project format has been upgraded to Xcode 3.2-compatible format. Some other minor enhancements have also been made to the sample, such as specifying the UltraLite temp_dir. See the DataAccess class' openConnection method for more details.

UltraLite - UL Java Provider for Sybase Central

================(Build #3328 - Engineering Case #666232)================ The "Go To Table" and "Go To Foreign Key" menu items for the ER Diagram tab did not always work. The "Go To Table" menu item did nothing if the database tree node was collapsed. The "Go To Foreign Key" menu item did not work at all. These have now been fixed. ================(Build #3298 - Engineering Case #661008)================ Right-clicking on an UltraLite database in the UltraLite Sybase Central plug-in, will show a list of database properties, one of which is the database file name. If the file name contained multi-byte characters, they could have been displayed as mangled characters. This has now been fixed. ================(Build #3294 - Engineering Case #659866)================ If an invalid value was specified for the "(other)" parameter on the Synchronization Profile property sheet, then it was not possible to clear this invalid value unless the property sheet was closed and F5 was pressed. This has now been fixed. ================(Build #3279 - Engineering Case #656087)================ When connecting from Sybase Central to an UltraLite database with multi-byte characters in its file name, the database name would have appeared with mangled characters. This has been fixed. ================(Build #3265 - Engineering Case #652188)================ When a table was selected in the tree and the Indexes tab was shown in the right pane, there was no File -> New -> Index... menu item. As such, it was only possible to start the Index wizard from the toolbar button. This has been fixed.

UltraLite - UltraLite Engine

================(Build #3518 - Engineering Case #689910)================ Extra rows were returned when executing a query using UNION where the subqueries contained joins with ON conditions. This has now been fixed. ================(Build #3492 - Engineering Case #688720)================ UltraLite could have returned fewer rows than expected for queries utilizing an index scan with conditions on multiple columns in the index. This has now been fixed.

UltraLite - UltraLite for M-Business Anywhere

================(Build #3496 - Engineering Case #685163)================ For version 12.0, the methods ResultSet.getString() and ULTable.getString() would have returned an empty string for columns that were null. Earlier versions would have correctly returned a 'null'. These methods have been corrected so that they now return results consistent with the prior versions. ================(Build #3491 - Engineering Case #686519)================ Calling PreparedStatement.setBytesParameter would have truncated a byte array with more than 32k elements. This has been fixed. Note, it is recommended that large binary parameters be set using PreparedStatement.appendBytesParameter(). ================(Build #3453 - Engineering Case #683813)================ The methods Connection.getNewUUID() and ULPodUUID.toString() were removed in version 12.0 as a result of the introduction of equivalent SQL functions. These methods have been reintroduced. As a workaround the system functions newid() and uuidtostr() can be used. Documentation: Connection::getNewUUID method Returns a new UUID value. Syntax UUID getNewUUID() example: uuid = conn.getNewUUID(); SQLType.toString method Returns the string name of the specified SQL column type constant or BAD_SQL_TYPE if not a recognized type. Syntax String toString(UInt16 code) Parameters code The SQL column type constant. example: uuid_str = conn.getNewUUID().toString(); ================(Build #3370 - Engineering Case #672372)================ Execution of an ALTER DATABASE SCHEMA FROM FILE statement may have failed with a SQLE_SCRIPT_MISSING_DELIMITER error when using a SQL file generated from ulunload or ulinit. This has been fixed. ================(Build #3281 - Engineering Case #656844)================ ULPod may have caused AvantGo clients to crash when calling the method TableAGDBSet getTableAGDBSet. This has been fixed.

UltraLite - UltraLite.NET

================(Build #3484 - Engineering Case #684277)================ Accessing result set or table columns, via streaming methods like ULResultSet::GetStringChunk in C++, could have returned unexpected values when the actual value was null, so checking explicitly to see if the value is null (ULResultSet::IsNull) was essential. This issue has been addressed by ensuring empty strings are now returned in this case. Proper handling of null values still requires an explicit check to differentiate between null and empty strings though. ================(Build #3447 - Engineering Case #675048)================ An application attempting to update a blob column on a result set by calling ULResultSet::AppendByteChunk (ULResultSet.AppendBytes in .NET) would have crashed. The crash wouldn't have occurred when updating a blob column using an UPDATE statement or a ULTable object. In .NET, this problem would have appearred as a System.AccessViolationException. This has been fixed. Also, when attempting to update a blob column that was NULL using a ULTable object, the column value would have remained NULL. This has also been fixed. ================(Build #3412 - Engineering Case #680218)================ Calling ULConnection.SetSyncListener would have internally launched a thread that would never terminate. This could have prevented Windows Mobile applications from completely shutting down. This has been fixed. ================(Build #3409 - Engineering Case #679436)================ After returning false from the SyncProgressed method, or calling CancelSynchronize to cancel a synchronization, it was possible that the Synchronize or EndSynchronize call would have hung. This has been fixed. Also, the ULSyncProgressData.FLAG_IS_BLOCKING flag could have been set erroneously when the state was ULSyncProgressData.STATE_CANCELLED. This too has been fixed. ================(Build #3326 - Engineering Case #664507)================ ULDataAdapter class may have reported the error SQLE_TOO_MANY_TEMP_TABLES even if the Dispose() method was invoked. This has been fixed. ================(Build #3275 - Engineering Case #653158)================ The methods ULConnection.CountUploadRows, ULConnection.GetLastDownloadTime, and ULConnection.ResetLastDownloadTime would have failed on Windows desktop when provided named publications instead of ULConnection.SYNC_ALL_DB. This has been fixed.

UltraLite - Utilities

================(Build #3301 - Engineering Case #661930)================ In some cases, the UltraLite Database Unload utility (ulunload) would have generated foreign keys in its XML output file that were not really in the database being unloaded. This has been fixed. ================(Build #3274 - Engineering Case #653467)================ If an UltraLite database had a table with a LONG VARCHAR column, and that column contained XML data, attempting to view that data in the Interactive SQL utility's cell editor (in the XML Outline tab) could have failed with the error: "An invalid XML character (Unicode: 0x0) was found in the element content of the document". This is now fixed.

UltraLiteJ - Runtime

================(Build #3764 - Engineering Case #713899)================ A query with a reverse index scan on the left hand side of a join may have resulted in a null pointer exception. For example: CREATE TABLE t1( a1 INT PRIMARY KEY ) CREATE TABLE t2( a2 INT PRIMARY KEY ) SELECT t1.a1, t2.a2 FROM t1, t2 ORDER BY t1.a1 DESC Also, a query with a reverse index scan on the right hand side of a cross join may not have returned any rows. For example: SELECT t1.a1, dt.a FROM t1, (SELECT a2 FROM t2 ORDER BY a2 DESC) AS dt( a ) ORDER BY t1.a1 ASC Both these issues have now been fixed. ================(Build #3759 - Engineering Case #713695)================ The fault tolerant HTTP processing in UltraLiteJ for Java 2 Platform Standard Edition (J2SE) did not work correctly. This has been fixed. ================(Build #3741 - Engineering Case #708660)================ If a URL suffix had a leading '/', the URL formed would have been [http|https]://host-name:port-number//url-suffix. This could result in an synchronization error. This differs from UltraLite which ensures that the '/' is not added when there is an leading '.' in the URL suffix. This has been fixed, the leading character of the url_suffix is checked and a '/' is appended only if needed ================(Build #3729 - Engineering Case #707362)================ On BlackBerry devices, and the simulator, when using HTTPS UltraLiteJ would have done an extra HTTPS POST request at the beginning of a synchronization to verify the contents of a certificate. This extra POST was not needed when the StreamHTTPSParms used in the synchronization had null CertificateCompany, CertificateName and CertificateUnit (all three null). This has been fixed. UltraLiteJ now will only do the extra POST if one or more of CertificateCompany, CertificateName and/or CertificateUnit are not null. ================(Build #3723 - Engineering Case #705854)================ With UltraLiteJ for Android, calling the PreparedStatement.set() method when the PreparedStatement had already been closed would have crashed the application. This has been fixed. Now, a ULjException with code SQLE_ULTRALITE_OBJ_CLOSED is thrown. ================(Build #3721 - Engineering Case #705696)================ With UltraLiteJ for Android, a binary column value with a length greater than or equal to 64 KB would have been truncated when using PreparedStatement.set(int, byte[]) to set the value for an INSERT or UPDATE statement. This has been fixed. A workaround is to use PreparedStatement.getBlobOutputStream(int) to get an OutputStream object, and use that to write the parameter value. ================(Build #3719 - Engineering Case #704967)================ With UltraLiteJ for Android, calling Connection.prepareStatement with a null statement parameter would have crashed the application. This has been fixed so that a ULjException with code SQLE_INVALID_PARAMETER is now thrown. ================(Build #3718 - Engineering Case #704600)================ In some circumstances, an index may have become corrupted after a DELETE. An index must have had Index Hashing turned on to be affected. This has been fixed. ================(Build #3714 - Engineering Case #703819)================ Rows with null values in BINARY(x) or UNIQUEIDENTIFIER columns, or small binary values in BINARY(x) columns (for example a 2 byte binary value stored in a column declared BINARY(512)), would have used more memory than necessary. This has been fixed. ================(Build #3714 - Engineering Case #703780)================ If a download for a particular table contained two rows with the same primary key value, UltraLiteJ would have thrown an exception with the warning SQLE_DUPLICATE_ROW_FOUND_IN_DOWNLOAD. This may have confused users into believing the download continued, when in fact the download had been rolled back. This has been fixed. UltraLiteJ now throws SQLE_PRIMARY_KEY_NOT_UNIQUE. ================(Build #3713 - Engineering Case #703785)================ With UltraLiteJ for Android, DatabaseManager.release() had undesirable effects - it may have caused erratic behaviour when the application was relaunched after it was used when the application closes after initial launch. This has been fixed. ================(Build #3713 - Engineering Case #703450)================ Columns containing TIME values were not properly hashed in indexes. Although values were correctly ordered, they were not as efficient. This has been fixed. ================(Build #3582 - Engineering Case #699393)================ With UltraLiteJ for Android, closing a PreparedStatement after its Connection object had been released caused the application to crash. The same was true for a ResultSet object. This has been fixed so that a ULjException with error code -908 "Invalid operation on a closed object" is now thrown. ================(Build #3569 - Engineering Case #697638)================ With UltraLiteJ for Android, it was not possible to retrieve the SQLCODE of the last executed SQL statement if it was a warning (ie. SQLCODE was greater than 0). This has been fixed. The method Connection.getLastWarning() has been added for Android only. This method returns a SQLInfo object, from which can be obtained the SQL code and a localized message. If the last SQL statement resulted in a SQL error code, a ULjException is thrown, as before. ================(Build #3553 - Engineering Case #696272)================ With UltraLiteJ for Android, calling SyncParms.setLivenessTimeout(n) had no effect. This has been fixed. Now the liveness timeout value for the synchronization connection is set to n seconds. Note, the default liveness timeout for synchronization and file transfer connections is 100 seconds for BlackBerry, J2SE and J2ME platforms, and 240 seconds (the default for UltraLite/MobiLink) for Android platforms. ================(Build #3540 - Engineering Case #695214)================ With UltraLiteJ for Android, a ULjException with code -735 (Invalid parameter) was thrown when using PreparedStatement.set() to set a String parameter with UTF-8 encoded length greater than or equal to 32 KB. This has been fixed. A workaround is to use PreparedStatement.getClobWriter() to get a Writer object, and use that to write the parameter value. ================(Build #3512 - Engineering Case #691589)================ 1. ALTER TABLE would have allowed the addition of a UNIQUE constraint with nullable columns. This would have resulted in corruption of row store for the table, and would have lead to ArrayIndexOutOfBounds exceptions or corrupt data being read. 2. ALTER TABLE ADD constraint would not have added existing table rows to the new index. SELECT with ORDER BY using the new constraint would have returned less rows, and it was possible to INSERT rows that violated the constraint. 3. ALTER TABLE ALTER column would not have properly modified the column definition. 4. ALTER TABLE ADD column, DROP column or ALTER column, would have corrupted the in-memory state when lazy loading, resulting in SQLE_ERROR in subsequent operations on a given table. All the above issues have been corrected. ================(Build #3508 - Engineering Case #691207)================ An ArrayIndexOutOfBoundsException could have occurred when reconnecting to an UltraLiteJ database if a previous connection had used a large amount of storage for temporary tables. This has been fixed. ================(Build #3505 - Engineering Case #690291)================ An UltraLiteJ database that was created from a file using the method DatabaseManager.importDatabaseFile() could have been invalid in rare circumstances. The circumstances in which this was more likely were when the page size of the database was small (1 KB or less). This has been fixed. ================(Build #3505 - Engineering Case #676668)================ Values in long binary and long varchar columns may have become corrupted when used in temporary tables. This may have manifested itself as incorrect values read, or ArrayIndexOutOfBounds exceptions, when values were read or when rows containing these values are deleted or updated. This has been fixed. ================(Build #3501 - Engineering Case #690393)================ The changes for Engineering cases 673184 and 673184 may have caused non-lazy loading databases to encounter SQLE_ERROR and ArrayIndexOutOfBounds. This has been fixed. ================(Build #3496 - Engineering Case #689943)================ With UltraLiteJ, committing a SQL statement that updated a table containing a large BLOB or CLOB could have caused an ArrayIndexOutOfBoundsException. This has been fixed. ================(Build #3487 - Engineering Case #674467)================ Queries that contained a predicate where an expression was 'greater than or equal to' or less than or equal to' the minimum value for a column, would have returned a result set that included rows where that column was null (if rows with null exist in the table). Moreover, the HASH SIZE for the indexed column must have been large enough to fully hash the indexed value. For example, if x is of type signed integer and there are rows in T where x is NULL, and there is an index on x with max hash size 4, then the following statement would have returned a result set that included rows where X is NULL: SELECT * FROM T WHERE x >= -2147483648 This has now been fixed. ================(Build #3486 - Engineering Case #688459)================ Queries that use temporary tables could have produced incorrect results when UltraLiteJ was configured with row limitations (i.e. using ConfigPersistent.setRowScoreMaximum or ConfigPersistent.setRowScoreFlushSize). This has been fixed. ================(Build #3484 - Engineering Case #688272)================ If an INSERT or an UPDATE failed, due to a unique constraint violation for example, a row may have been left behind in the store. This would have resulted it unrecoverable database growth. This has been fixed. ================(Build #3484 - Engineering Case #686869)================ When a database page was reused, the unused portion of the page was not always set to zeros, possibly resulting in exposure of decrypted data when that page was written out. This has now been corrected. ================(Build #3484 - Engineering Case #681837)================ Doing a large number of download deletes when under extreme row limiting conditions may have resulted in an ArrayIndexOutOfBounds exception. This has been fixed. ================(Build #3484 - Engineering Case #680036)================ In a heavy indexing environment (many rows * many cursors with small row limiting values and small cache size relative to number of index pages in the database), a synchronization of many download deletes may have become stuck while committing the download. Sometimes, on the BlackBerry OS it would have caused a system wide ForcedStackTrace exception. These have been fixed. ================(Build #3484 - Engineering Case #678600)================ When downloading rows with multiple LONG BINARY or LONG VARCHAR columns, they may have been corrupted when earlier clob/blob columns were null. This could have then resulted in a variety of errors including reading random values. For example, if a table was defined as: CREATE TABLE t( c1 INT PRIMARY KEY, c2 LONG VARCHAR, c3 LONG VARCHAR ) and the row[ 1, null, 'b' ] was downloaded, reading c3 would have failed. Rows [2, 'a', 'b'], [3, 'a', null ] and [4, null, null ] would have been okay. This has been fixed. ================(Build #3483 - Engineering Case #676092)================ During download deletes, index pages were not being flushed. This has been fixed. Other changes have been made as well to reuse Java objects and reduce the creation of temporary objects during the download. These changes were made to improve memory useage during synchronization. ================(Build #3483 - Engineering Case #674032)================ A database's in-memory state may have become corrupt if it had many indexes on large tables and small row limits. This would have resulted in an ArrayIndexOutOfBounds exception. The database itself was not actually corrupted and could have been used after disconnecting and reconnecting. This has been fixed. ================(Build #3479 - Engineering Case #687769)================ In some circumstances, the Long.MIN_VALUE (-2^63) was incorrectly stored internally as a NUMERIC value. This resulted in incorrect values during expession evaluation. This has been fixed. ================(Build #3466 - Engineering Case #686039)================ After sending the upload and applying the download, UltraLiteJ sends a message to the server telling it the synch is complete. If there was a network error while sending this message, it would have been reported to the application, implying the sync had failed even though the download was applied correctly. This has been fixed and now the application no longer gets an error if the sync otherwise succeeded. ================(Build #3465 - Engineering Case #686040)================ UltraLiteJ could have caused the MobiLink server to report spurious protocol errors in the MobiLink server log. This has been fixed. ================(Build #3464 - Engineering Case #685746)================ With UltraLiteJ for Android, the method DatabaseInfo.getNumberRowsToUpload() always returned 0. This has been fixed so that it now works as documented. ================(Build #3464 - Engineering Case #679296)================ With UltraLiteJ for Android, synchronization with HTTP and E2EE was not possible because the methods setE2eePublicKey() and getE2eePublicKey() were members of the class StreamHTTPSParms. This has been fixed by moving the methods to the base class, StreamHTTPParms. ================(Build #3459 - Engineering Case #683700)================ With UltraLiteJ, committing a SQL statement that had updated a table containing a large BLOB or CLOB could have caused a StackOverflowError exception. This has been fixed. ================(Build #3449 - Engineering Case #683774)================ With UltraLiteJ, an UPDATE statement for table T with a subquery in the WHERE clause that referenced T, could have failed with a -144 error ("Column ... found in more than one table or it is used more than once in the SELECT list -- it needs a correlation name") at statement preparation time. This has been fixed. ================(Build #3435 - Engineering Case #683394)================ When UltraLIteJ was run on Android devices, the method DatabaseInfo.getPageSize() could have returned an incorrect value. This has been fixed. Also, the method Connection.getDatabaseProperty() was exposed for UltraLiteJ Android; and the method DatabaseInfo.getRelease() was modified to return the full software release, including the build number. ================(Build #3415 - Engineering Case #680578)================ If a table had many rows with the same index value (all columns for a given index were the same), updates and deletes could have been slow. The performance decreased as the number of non-unique indexes with poor value distribution on a given table increased. This has been fixed. ================(Build #3409 - Engineering Case #679403)================ Calling ResultSet.getString(i) when column i was of type INT, SMALLINT, UNSIGNED SMALLINT, BIGINT, NUMERIC, REAL or DOUBLE, would have thrown a ULjException with code SQLE_VALUE_IS_NULL when the column value was NULL. This has been fixed so that ResultSet.getString() now returns null in this case. ================(Build #3406 - Engineering Case #671994)================ Doing an FETCH ABSOLUTE instead of a FETCH RELATIVE could have caused the cursor to move to an incorrect row if the query contained a subquery. This could have resulted in a -197 error code when trying to get column values. The GetRowCount() method does an absolute fetch internally, so the problem could have occurred when invoking this method. This has now been fixed. ================(Build #3403 - Engineering Case #672633)================ When the MobiLink server was running on an OS with a multi-byte character set, and a synchronization request from an Android UltraLiteJ application caused a synchronization error at the server, the UltraLiteJ runtime could have caused an application crash. This has been fixed. ================(Build #3401 - Engineering Case #677867)================ Null values retrieved with ResultSet.getString( col_no ) were returned as an empty string. This has been fixed. Now, null values are retrieved as null with this method. ================(Build #3395 - Engineering Case #675363)================ A null pointer exception was possible when a host variable occurred in the HAVING clause This was corrected. ================(Build #3387 - Engineering Case #675642)================ Database corruption was possible when the UltraLiteJ Runtime was under row limitation stress (when the maximum and minimum row limitation values are close together). This has now been corrected. ================(Build #3387 - Engineering Case #674898)================ Multi-threading access to an UltraLiteJ database may have resulted in a null pointer or other exception. This problem would have occured if another thread was accessing many rows in a single operation (i.e. updating a table with a large number of rows and indexes with small row limiting values). This has been fixed. ================(Build #3376 - Engineering Case #674206)================ The DatabaseManager.release() method is designed to be used only once to release all resources associated with the UltraLiteJ runtime. However, some DatabaseManager methods (eg. connect) did not return an error, but silently failed when called after the call to release(). This has been fixed. Now, a ULjException is thrown with the error code SQLE_NOT_CONNECTED if a connect() or createDatabase() is called after the call to release(). ================(Build #3372 - Engineering Case #673483)================ When the method Connection.emergencyShutdown() was called, existing connections on the database did not have their states changed to NOT_CONNECTED. This has been fixed. Also, the method DatabaseManager.connect() now returns SQLE_INVALID_PARAMETER if passed a NULL configuration. ================(Build #3369 - Engineering Case #673051)================ It was not possible to use ZLib data compression with HTTP synchronization as the methods to enable compression appeared in StreamHTTPSParms, rather than StreamHTTPParms. This has been fixed by moving the methods from StreamHTTPSParms to StreamHTTPParms. Existing applications will continue to run because StreamHTTPSParms is a subclass of StreamHTTPParms. ================(Build #3354 - Engineering Case #669242)================ An ArrayIndexOutOfBoundsException could have been thrown during a COMMIT. This has been fixed. ================(Build #3345 - Engineering Case #668820)================ Calling the method DatabaseManager.release() would have caused the error: "No implementation found for native Lcom/ianywhere/ultralitejni12/implementation/JniDbMgr;.release ()V". This has been corrected by implementing the method DatabaseManager.release(). Note that prior to this fix, UltraLiteJ for Android would have done the equivalent of DatabaseManager.release() when the UltraLiteJ application terminated. Now it is possible for the application to execute DatabaseManager.release() at a specific point in time. ================(Build #3339 - Engineering Case #667720)================ The following methods have been implemented in ResultSetMetadata for UltraLiteJ for Android: String getAliasName( int column_no ) String getDomainName( int column_no ) String getCorrelationName( int column_no ) String getQualifiedName( int column_no ) String getTableColumnName( int column_no ) String getTableName( int column_no ) String getWrittenName( int column_no ) Previously, they returned the value "N.Y.I.". They now return values that closely approximate those returned by the UltraLiteJ runtime for Blackberry. ================(Build #3336 - Engineering Case #667519)================ The following get-by-name APIs were missing from ResultSet for UltraLiteJ for Android and have now been added: java.io.InputStream getBlobInputStream( String name ) boolean getBoolean( String name ) byte[] getBytes( String name ) java.io.Reader getClobReader( String name ) java.util.Date getDate( String name ) DecimalNumber getDecimalNumber( String name ) double getDouble( String name ) float getFloat( String name ) long getLong( String name ) int getSize( String name ) String getString( String name ) UUIDValue getUUIDValue( String name ) boolean isNull( String name ) ================(Build #3301 - Engineering Case #662232)================ The performance of database changes on first update (commit) after starting up has been improved. ================(Build #3297 - Engineering Case #660797)================ During a large (at least 15 MB) data synchronization, the UltraLiteJ native library for Android could have caused a Dalvik VM memory overflow condition similar to the following: WARN/dalvikvm(641): ReferenceTable overflow (max=512) ... ERROR/dalvikvm(641): Failed adding to JNI local ref table (has 512 entries) ... ERROR/dalvikvm(641): VM aborting The memory overflow condition would have occurred during a Connection.synchronize( SyncParms parms ) call, where a SyncObserver was defined in the SyncParms. This has been fixed. ================(Build #3297 - Engineering Case #660501)================ Incorrect results were possible when executing a query with an IN list consisting of a single host variable. This has been corrected. The work-around is to rewrite expression in ( ? ) as expression = ?. ================(Build #3295 - Engineering Case #660387)================ Incorrect results were possible for a deeply nested (at least a depth of three) aggregate subquery. This has been corrected. ================(Build #3290 - Engineering Case #658845)================ Result set rows could have been presented in an incorrect order when all of the following conditions were present for a SQL query: - An index existed in which the first column (say col1) was specified to be in descending order - The query contained a search condition of the form "col1 LIKE expression" where the expression started with non-wildcard characters. - The query contained an ORDER BY starting with col1 This has been corrected. ================(Build #3278 - Engineering Case #655880)================ Second and subsequent '%' characters were not being handled properly in LIKE clauses. This was corrected.

UltraLiteJ - Utilities

================(Build #3388 - Engineering Case #676069)================ The UltraLiteJ Database Unload utility (uljunload) did not allow specifying the page size on a new databases. A new flag -z has been added to uljunload to specify the page size in bytes. ================(Build #3369 - Engineering Case #673024)================ The message "Number of tables that are never synchronized:" would have returned the number of tables that were synchronized instead of the number that were never synchronized. This has been fixed. Also, the message "Number of tables that will always be uploaded:" was incorrect and misleading and the number displayed was invalid. This message has been changed to "Number of tables that are in publications:" and the output has been corrected.