SQL Anywhere 11.0.1 Release Notes for Windows Copyright © 2009, iAnywhere Solutions, Inc. All rights reserved. All unpublished rights reserved. SQL Anywhere 11.0.1 marks the introduction of various new editions that may include certain components that were separately licensed in previous versions. Further details can be found at: http://www.sybase.com/products/databasemanagement/sqlanywhere/editions If you are upgrading a non-Developer or non-OEM edition of SQL Anywhere from 11.0.0 to 11.0.1, the default upgrade will be to the SQL Anywhere Workgroup Edition. If your SQL Anywhere server currently uses more than 2 CPUs, or you use an add-on option not available in the Workgroup Edition, please contact your local Sybase office for assistance. With the introduction of new editions in SQL Anywhere 11.0.1, some registration keys have changed between the 11.0.0 and 11.0.1 releases. Do not use 11.0.0 registration keys to install 11.0.1 software. For example, this may lead to a scenario where the Administration Tools and samples are not installed properly. SQL Anywhere Server ------------------- o Databases from SQL Anywhere 9 and earlier must be rebuilt before they can be used with SQL Anywhere 11. After installing SQL Anywhere 11, consult the documentation for information about rebuilding databases. o The [NOT] DETERMINISTIC clause is not supported in the CREATE PROCEDURE and ALTER PROCEDURE statements. Previously, the clause was ignored. Now, the statement fails and a syntax error is returned. If you are upgrading a database that contains user-defined procedures that include the [NOT] DETERMINISTIC clause, you must remove it. o When using the 11.0.1 software to restore a tape archive backup made with an earlier version, the tape will be ejected once during the restore. Reinserting the tape will allow the restore to continue. MobiLink -------- o It should be noted that MobiLink, by default, loads version 1.2.8 of log4j.jar. The loading of this JAR precedes the loading of any classes specified in the "-sl java(-cp...)" command line option. If any classes loaded on the MobiLink command line require a newer version of log4j, MobiLink may generate unpredictable errors. (Currently, we are aware of problems loading the JBoss 4.2 JMS client.) You should be aware of what version of log4j you require. You can force MobiLink to load the appropriate log4j JAR file by using "-sl java(-Xbootclasspath/p:log4j.jar)" on the MobiLink command line. QAnywhere --------- o The Java environment on Windows Mobile that QAnywhere supports is the WebSphere Everyplace Micro Environment, Personal Profile 1.1. To use the Java QAnywhere client, qaclient.jar, with a SQL Anywhere message store on Windows Mobile, the following JDBC 3.0 interface classes must be in the boot classpath of the Java VM: java/sql/Array.class java/sql/BatchUpdateException.class java/sql/Blob.class java/sql/CallableStatement.class java/sql/Clob.class java/sql/Connection.class java/sql/DatabaseMetaData.class java/sql/DataTruncation.class java/sql/Date.class java/sql/Driver.class java/sql/DriverManager.class java/sql/DriverPropertyInfo.class java/sql/ParameterMetaData.class java/sql/PreparedStatement.class java/sql/Ref.class java/sql/ResultSet.class java/sql/ResultSetMetaData.class java/sql/Savepoint.class java/sql/SQLData.class java/sql/SQLException.class java/sql/SQLInput.class java/sql/SQLOutput.class java/sql/SQLWarning.class java/sql/Statement.class java/sql/Struct.class java/sql/Time.class java/sql/Timestamp.class java/sql/Types.class If these classes are not available in a JAR file on the Windows Mobile device in a particular WEME deployment, then they may extracted from a Sun 1.4.x JDK, packaged in a JAR file and deployed to the device. Relay Server ------------ o The minimum web server liveness timeout is 60 seconds. UltraLite --------- o UltraLiteJ Database Transfer Utility - When attempting to connect to a database that was created with the default password "dba", that password must be specified on the "Database Connection" screen. Leaving the "Database Password:" field empty will not use the default value. Documentation ------------- SQL Anywhere includes extensive documentation. The documentation is installed separately from the software. If you are installing SQL Anywhere from a CD, the documentation install is included and can be run from the main install. If you downloaded SQL Anywhere, the software and documentation are contained in separate downloads. The documentation should be installed in the same directory as the software. The default installation locations for the software and documentation installs are the same. If you choose to install the documentation in a different location, the context-sensitive help (help in Administration Tools) will not function properly. DocCommentXchange ----------------- DocCommentXchange (http://dcx.sybase.com) is a new web site for viewing and commenting on SQL Anywhere documentation and for viewing comments made by others. You can use DocCommentXchange directly, or you can view your installed documentation and click the DocCommentXchange link to see if there are any comments on a particular page or to make a comment. Bugs fixed in this maintenance release -------------------------------------- This section lists bugs that were fixed in this release. It does not list bugs that were fixed in earlier releases. For bug fix lists from earlier releases, go to MySybase, at http://www.mysybase.com. Note that this maintenance release may not contain all of the bug fixes from recent EBFs (Express Bug Fixes) made available from MySybase, since EBFs for earlier releases can occur after this maintenance release. If you are changing from an EBF of an earlier maintenance release and you require a recent bug fix, you may require a recent EBF for this maintenance release. The bug fix descriptions are in English because the list is generated from engineering tools used to track changes to the software. A translated version of the bug list may be available from a local Sybase web site. SQL Anywhere Maintenance Release Notes for Version 11.0.1 ========================================================= Contents ======== * Description of download types o Express Bug Fixes o Maintenance Release * Introduction * 11.0.1 Behavior Changes and Critical Bug fixes o MobiLink - Synchronization Server (1) o SQL Anywhere Server - Server (1) * 11.0.1 New Features o MobiLink - Relay Server (1) o MobiLink - Synchronization Server (4) o MobiLink - Utilities (1) o SQL Anywhere Server - JDBC Client Library (2) o SQL Anywhere Server - OLEDB Client Library (1) o SQL Anywhere Server - Server (5) o SQL Anywhere Server - Sybase Central Plug-in (1) o SQL Anywhere Server - Utilities (2) o SQL Remote for Adaptive Server Anywhere - SQL Remote Message Agent (1) o UltraLiteJ - Runtime (1) * 11.0.1 Bug fixes o MobiLink - Java Plugin for Sybase Central (14) o MobiLink - Monitor (5) o MobiLink - QAnywhere client (7) o MobiLink - QAnywhere server (10) o MobiLink - Relay Server (18) o MobiLink - SA Client (9) o MobiLink - Streams (4) o MobiLink - Synchronization Server (36) o MobiLink - Utilities (7) o MobiLink - iAS Branded ODBC Drivers (3) o MobiLink - scripts (1) o SQL Anywhere Server - ADO.Net Managed Provider (10) o SQL Anywhere Server - DBLIB Client Library (6) o SQL Anywhere Server - JDBC Client Library (28) o SQL Anywhere Server - ODBC Client Library (5) o SQL Anywhere Server - OLEDB Client Library (10) o SQL Anywhere Server - Other (21) o SQL Anywhere Server - Server (304) o SQL Anywhere Server - Sybase Central Plug-in (47) o SQL Anywhere Server - Utilities (61) o SQL Remote for Adaptive Server Anywhere - SQL Remote Message Agent (1) o Sybase Central Java Viewer - Java Viewer (1) o UltraLite - HotSync Conduit (1) o UltraLite - Runtime Libraries (5) o UltraLite - UL Java Provider for Sybase Central (4) o UltraLite - UltraLite Engine (4) o UltraLite - UltraLite.NET (1) o UltraLite - Utilities (3) o UltraLiteJ - Runtime (33) o UltraLiteJ - Utilities (1) * Some useful links o iAnywhere.com Support Page - http://www.ianywhere.com/support/support.html o EBF downloads page - http://downloads.sybase.com o SQL Anywhere newsgroups - http://www.ianywhere.com/support/newsgroups.html o SQL Anywhere Main Page (links to evaluation software, tech support, whitepapers, etc) - http://www.ianywhere.com/products/sql_anywhere.html o SQL Anywhere supported platform matrix - http://www.ianywhere.com/products/supported_platforms.html ================================================================================ 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. Moderate testing has been performed on the software, but full testing has not been performed. Customers are encouraged to verify the suitability of the software before releasing it into a production environment. 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 ================================================================================ Introduction ============ Release 11.0.1 is a regularly-scheduled maintenance release, containing fixes to reported problems with the software as well as some new features. ================================================================================ 11.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. MobiLink - Synchronization Server ===============(Release Build - Engineering Case #537962)=============== If an error occurred when executing a Java or .NET synchronization script, and operations had been performed on the connection returned from the DBConnectionContext.getConnection method, it was possible for those operations to have been committed to the consolidated database. In order for this to have occurred, the Java or .NET synchronization script would have to have been executed before any SQL scripts were executed in the transaction by the MobiLink Server. As a workaround, a SQL synchronization script that does nothing could be defined that executes at the start of the transaction. For example, define a begin_upload connection event that calls a stored procedure, that does nothing, to prevent a problem in the handle_uploadData event resulting in operations performed in the handle_uploadData event from being accidentally committed. This problem has now been fixed. SQL Anywhere Server - Server ===============(Release Build - Engineering Case #537171)=============== The search condition REGEXP and system function REGEXP_SUBSTR() were using the database's collation to determine if a literal, or character class range, in the pattern matched the string. For example, if the database was case insensitive and accent insensitive, matches were case insensitive and accent insensitive as well. Ranges were evaluated using the collation sort order. This resulted in different behavior than other tools such as Perl, Java, .NET, etc. This has been fixed so that REGEXP and REGEXP_SUBSTR() only match a literal in a pattern if it is the exact same character. Ranges in character classes (for example '[A-F]') only match characters which have character set encoding greater than or equal to the encoding of the first character in the range (A in '[A-F]') and less than or equal to the encoding of the second character in the range (F in '[A-F]'). Note, this change does not affect the SIMILAR TO search expression, which continues to use the collation to determine character equivalence and evaluate character class ranges. ================================================================================ 11.0.1 New Features =================== This section contains a description of new features added since the release of version 11.0.0. MobiLink - Relay Server ===============(Release Build - Engineering Case #537333)=============== HTTP clients going through the Relay Server may now optionally include the IAS-RS-Cookie header with the value set to 'reset' in the first request within the session. This was added in order to defeat the old standard cookie memorized by HTTP proxies, like the Blackberry MDS. If the client has full control of cookie caching, and a new http session will not reuse an old cookie, then implementation of this option is not needed in the client. This feature is suitable for Blackberry devices behind MDS, where the client application does not have real control on when to end the underlying HTTP session. MobiLink - Synchronization Server ===============(Release Build - Engineering Case #536143)=============== A new MobiLink server command line option, -ppv <period>, has been added which will cause the server to print new, periodic monitoring values every <period> seconds. The suggested period is 60s. If the period is set too small, the log will grow very quickly. These values provide insight into the state of the server, and are useful for determining the health and performance of the MobiLink server. For example, one could look at the DB_CONNECTIONS and LONGEST_DB_WAIT values to look for potential problems with the -w option or in the synchronization scripts. They also provide an easy way to track system wide throughput measures such as the number of rows uploaded or downloaded per second and the number of successful syncs per second. Each row of output is prefixed with "PERIODIC:" to aid searching for and filtering out the values. The following table contains a description of the printed values: Value Description TCP_CONNECTIONS Number of TCP connections currently opened PAGES_USED Number of cache pages used PAGES_LOCKED Number of cache pages loaded into memory TCP_CONNECTIONS_OPENED Total number of connections ever opened TCP_CONNECTIONS_CLOSED Total number of connection ever closed TCP_CONNECTIONS_REJECTED Total number of connection ever rejected TCP_BYTES_READ Total number of bytes ever read TCP_BYTES_WRITTEN Total number of bytes ever written ML_NUM_CONNECTED_CLIENTS Number of connected sync client PAGES_SWAPPED_OUT Total number of pages ever swapped to disk PAGES_SWAPPED_IN Total number of pages ever read from disk PAGES_IN_STREAMSTACK Number of pages held by the network streams CPU_USAGE Amount of CPU time used by MobiLink server in microseconds NUM_COMMITS Total number of commits NUM_ROLLBACKS Total number of rollbacks NUM_SUCCESS_SYNCS Total number of successful syncs NUM_FAILED_SYNCS Total number of failed syncs NUM_ERRORS Total number of errors NUM_WARNINGS Total number of warnings DB_CONNECTIONS Number of database connections in use RAW_TCP_STAGE_LEN Length of the network work queue STREAM_STAGE_LEN Length of the high level network processing queue HEARTBEAT_STAGE_LEN Length of the queue for periodic, non-sync work CMD_PROCESSOR_STAGE_LEN Length of the queue for sync work NUM_ROWS_DOWNLOADED Total number of rows sent to remotes NUM_ROWS_UPLOADED Total number of rows received from remotes FREE_DISK_SPACE Disk space available on the temp disk in bytes LONGEST_DB_WAIT Longest length of time an active sync has been waiting for the database LONGEST_SYNC Age of the oldest sync in ms NUM_UNSUBMITTED_ERROR_RPTS Number of unsubmitted error reports MEMORY_USED Bytes of RAM in use. Windows only. SERVER_IS_PRIMARY 1 if the server is primary; 0 otherwise ===============(Release Build - Engineering Case #532825)=============== A new logging option has been added to the MobiLink server. The -vm command line option will cause the server to print to the log the duration of each sync and the duration of each sync phase whenever a sync completes. The sync phases are the same as those displayed in the MobiLink monitor. Each value is prefixed with "PHASE: " to aid searching for and printing the values. Sample output follows: I. 2008-06-05 14:48:36. <1> PHASE: start_time: 2008-06-05 14:48:36.048 I. 2008-06-05 14:48:36. <1> PHASE: duration: 175 I. 2008-06-05 14:48:36. <1> PHASE: sync_request: 0 I. 2008-06-05 14:48:36. <1> PHASE: receive_upload: 19 I. 2008-06-05 14:48:36. <1> PHASE: get_db_worker: 0 I. 2008-06-05 14:48:36. <1> PHASE: connect: 18 I. 2008-06-05 14:48:36. <1> PHASE: authenticate_user: 51 I. 2008-06-05 14:48:36. <1> PHASE: begin_sync: 69 I. 2008-06-05 14:48:36. <1> PHASE: apply_upload: 0 I. 2008-06-05 14:48:36. <1> PHASE: prepare_for_download: 1 I. 2008-06-05 14:48:36. <1> PHASE: fetch_download: 4 I. 2008-06-05 14:48:36. <1> PHASE: wait_for_download_ack: 0 I. 2008-06-05 14:48:36. <1> PHASE: end_sync: 0 I. 2008-06-05 14:48:36. <1> PHASE: send_download: 10 I. 2008-06-05 14:48:36. <1> PHASE: get_db_worker_for_download_ack: 0 I. 2008-06-05 14:48:36. <1> PHASE: connect_for_download_ack: 0 I. 2008-06-05 14:48:36. <1> PHASE: nonblocking_download_ack: 0 ===============(Release Build - Engineering Case #534742)=============== The MobiLink server, and Java and .NET APIs, have been modified to allow users to register to receive notfications whenever an info line is printed to the log (i.e. lines prefixed with "I."). Java: The following methods, added to interface ianywhere.ml.script.ServerContext are used to register or unregister listeners: /** * Adds the specified LogListener to receive a notification * when info is printed. * method {@link LogListener#messageLogged} will be called. * * @param ll the LogListener to be notified on warning */ public void addInfoListener( LogListener ll ); /** * Remove the specified LogListener from the list of * listeners to receive a notification * when info is printed. * * @param sl the listener which will no longer be notified */ public void removeInfoListener( LogListener ll ); The following constant, added to class ianywhere.ml.script.LogListener, is returned by LogMessage.getType() for info messages: public static final int INFO = 2; Example: The following code registers a listener of type MyLogListener to receive notifications of info messages. // ServerContext serv_context; serv_context.addInfoListener( new MyLogListener( ll_out_file )); The following code shows an example of processing those messages: class MyLogListener implements LogListener { FileOutputStream _out_file; public TestLogListener( FileOutputStream out_file ) { _out_file = out_file; } public void messageLogged( ServerContext sc, LogMessage msg ) { String type; String user; try { if(msg.getType() == LogMessage.ERROR) { type = "ERROR"; } else if(msg.getType() == LogMessage.WARNING) { type = "WARNING"; } else if(msg.getType() == LogMessage.INFO) { type = "INFO"; } else { type = "UNKNOWN!!!"; } user = msg.getUser(); if( user == null ) { user = "NULL"; } _out_file.write( ("Caught msg type=" + type + " user=" + user + " text=" +msg.getText() + "\n").getBytes() ); _out_file.flush(); } catch( Exception e ) { // if we print the exception from processing an info message, // we may recurse indefinately if( msg.getType() != LogMessage.INFO ) { // Print some error output to the MobiLink log. e.printStackTrace(); } } } } .NET: Callback functions can be registered to the following event, added to interface iAnywhere.MobiLink.Script.ServerContext, to receive notifications about info messages: /// <summary> /// Triggered when the MobiLink server prints info /// </summary> event LogCallback InfoListener; The following, added to enum iAnywhere.MobiLink.Script.LogMessage.MessageType, can be returned by the Type property of the LogMessage class /// <summary> /// A log info message.</summary> INFO Example: The following code defines a callback that will process an info message. internal class TestLogListener { public TestLogListener( StreamWriter output_file, LogMessage.MessageType expected_type ) { _output_file = output_file; _expected_type = expected_type; } public void errCallback( ServerContext sc, LogMessage lm ) { string type; string user; if( lm.Type != _expected_type ) { _output_file.WriteLine( "Message type not expected!!" ); return; } if( lm.Type==LogMessage.MessageType.ERROR ) { type = "ERROR"; } else if( lm.Type==LogMessage.MessageType.WARNING ) { type = "WARNING"; } else if( lm.Type==LogMessage.MessageType.INFO ) { type = "INFO"; } else { type = "INVALID TYPE!!"; } if( lm.User == null ) { user = "null"; } else { user = lm.User; } if( (lm.Text.IndexOf( "10017" ) > 0) || (lm.Text.IndexOf( "10018" ) > 0) || (lm.Text.IndexOf( "10020" ) > 0) || (lm.Type == LogMessage.MessageType.INFO && lm.Text.IndexOf( "MobiLink server started" ) < 0 ) ) { return; } _output_file.WriteLine( "Caught msg type=" + type + " user=" + user + " text=" + lm.Text ); _output_file.Flush(); } StreamWriter _output_file; private LogMessage.MessageType _expected_type; } The following code adds the callback to the InfoListener event. // ServerContext _sc; TestLogListener itll = new TestLogListener( log_listener_file, LogMessage.MessageType.INFO ); sc.InfoListener += new LogCallback(itll.errCallback); ===============(Release Build - Engineering Case #530579)=============== A new MobiLink server option, -vo, now shows SQL passthrough activity in the MobiLink server. Prior to this option it was impossible to know what was happening on the server when debugging SQL Passthrough. MobiLink - Utilities ===============(Release Build - Engineering Case #539813)=============== A new command line option (-sv) has been added to the MobiLink Listener to allow for specifying the script version used for authentication. The default value is ml_global. SQL Anywhere Server - JDBC Client Library ===============(Release Build - Engineering Case #536335)=============== If an application generated a result set via one DatabaseMetaData call, and then generated a second result set via another DatabaseMetaData call, then the first result set would have been automatically closed. This behaviour is not incorrect, and is consistent with many other JDBC drivers. However, some applications have had the need to keep two separate DatabaseMetaData result sets open at the same time. The iAnywhere JDBC driver has now been enhanced to allow up to three separate DatabaseMetaData result sets to remain open at the same time. ===============(Release Build - Engineering Case #534307)=============== If an application using the iAnywhere JDBC driver attempted to use the optional DatabaseMetaData.getUDTs() method, the driver would have throw a "not yet implemented" exception. The iAnywhere JDBC driver has now been enhanced to return a proper result set for the getUDTs() method if the driver is connected to an SA database. For all non-SA servers, the iAnywhere JDBC driver will continue to throw the "not yet implemented" exception. SQL Anywhere Server - OLEDB Client Library ===============(Release Build - Engineering Case #543888)=============== The SQL Anywhere OLE DB provider did not support multiple parameter sets in the ICommand::Execute method. The number of parameter sets is specified in the cParamSets field of the DBPARAMS structure, for example: HRESULT Execute ( IUnknown     *pUnkOuter, REFIID        riid, DBPARAMS     *pParams, DBROWCOUNT   *pcRowsAffected, IUnknown    **ppRowset); struct DBPARAMS { void *pData; DB_UPARAMS cParamSets; HACCESSOR hAccessor; }; This is now supported, so it is now possible to execute one INSERT statement and specify several sets of parameters in order to insert several rows into a table. Note the following OLE DB specification restriction: Sets of multiple parameters (cParamSets is greater than one) can be specified only if DBPROP_MULTIPLEPARAMSETS is VARIANT_TRUE and the command does not return any rowsets. This means that multiple parameterized SELECT statements can not be executed that would each return a result set. For the SQL Anywhere provider, DBPROP_MULTIPLEPARAMSETS is VARIANT_TRUE (and always has been). SQL Anywhere Server - Server ===============(Release Build - Engineering Case #540195)=============== When a connection attempted to autostart a server, but then failed to connect, the client incorrectly attempted to autostart the server three times in some cases. This has been fixed so that the client will now only attempt to autostart the server once. ===============(Release Build - Engineering Case #394857)=============== Not all OLE DB schema rowsets are supported, however the most common and useful rowsets are supported.  Two OLE DB schema rowsets that were not supported have now been implemented. CATALOGS: The CATALOGS rowset identifies the physical attributes associated with catalogs accessible from the DBMS. SQL Anywhere does not support the notion of catalogs as some other database systems do. With that in mind, the SQL Anywhere OLE DB provider will return a result set for CATALOGS containing all currently started databases. The following is an example. CATALOG_NAME DESCRIPTION AnotherSample c:\SQLAnywhere10\Samples\sample.db demo c:\SQLAnywhere10\Samples\demo.db The CATALOG_NAME column contains the database name.  The DESCRIPTION column contains the physical location of the database on the database server computer. SCHEMATA: The SCHEMATA rowset identifies the schemas that are owned by a given user.  The following is an example of a SCHEMATA rowset  returned by the SQL Anywhere OLE DB provider. CATALOG_NAME SCHEMA_NAME SCHEMA_OWNER DEFAULT_CHARACTER_SET_CATALOG DEFAULT_CHARACTER_SET_SCHEMA DEFAULT_CHARACTER_SET_NAME demo dbo dbo demo SYS windows-1252 demo GROUPO GROUPO demo SYS windows-1252 demo ml_server ml_server demo SYS windows-1252 demo rs_systabgroup rs_systabgroup demo SYS windows-1252 demo SYS SYS demo SYS windows-1252 The CATALOG_NAME column contains the name of the database to which you are currently connected. The SCHEMA_NAME and SCHEMA_OWNER columns contain identical values  for SQL Anywhere databases. The DEFAULT_CHARACTER_SET_CATALOG column always contains the name of the database to which you are currently connected since character sets are associated with databases. The DEFAULT_CHARACTER_SET_SCHEMA column is arbitrarily set to SYS since the character set in use for the database is not owned by anyone. The DEFAULT_CHARACTER_SET_NAME column contains the value of the "CharSet" database property Note, to get this new functionality in existing databases, do the following: 9.0.2 - upgrade the databases by loading and running Scripts\oleschem.sql using Interactive SQL. 10.0.1 - run dbupgrad on each database, or connect to each database and run ALTER DATABASE UPGRADE. As an alternative, the databases can be upgraded by running Scripts\oleschem.sql using Interactive SQL. 11.0.0 - run dbupgrad on each database, or connect to each database and run ALTER DATABASE UPGRADE. ===============(Release Build - Engineering Case #533950)=============== The sa_locks() system procedure can be used to get a report on server locks currently held by various connections. Since both base tables and materialized views hold data, locks can be held on objects of either type. The server will now report the type of "MVIEW" for locks held on materialized view instead of the type of "BASE", which will continue to be reported for locks on base tables. ===============(Release Build - Engineering Case #533012)=============== The connection property 'IsDebugger' has been added to allow connections which are currently being used to run the procedure debugger to be distinguished from normal connections. The value of connection_property('IsDebugger',number) will be 'Yes' if "number" corresponds to the connection number of a debugger connection, and 'No' otherwise. ===============(Release Build - Engineering Case #528793)=============== A new connection and database property called "Authenticated" has now been added. The use of these two new properties is as follows: For OEM servers, once an application has executed the "SET TEMPORARY OPTION CONNECTION_AUTHENTICATION=" statement, the application can then turn around and execute a "SELECT connection_property( 'Authenticated' )" statement. If the result is "YES", then the connection was properly authenticated and all is well. If, however, the result is "NO", then the application can execute a "SELECT db_property( 'Authenticated' )" statement. If the result of this statement is "YES", then the database has been properly authenticated and the connection authentication failed because the CONNECTION_AUTHENTICATION string is incorrect. If, on the other hand, the result of querying the Authenticated database property is "NO", then the connection authentication failed because the database has not been properly authenticated. In this case, the customer should examine the DATABASE_AUTHENTICATION string to determine what is wrong. For non-OEM servers, the result of querying these new properties will always be "YES". SQL Anywhere Server - Sybase Central Plug-in ===============(Release Build - Engineering Case #547713)=============== Sybase Central would have failed to delete a remote server or a directory access server if it had one or more proxy tables. Now, the proxy tables are automatically deleted before the remote server or directory access server is deleted. This fix restores the behaviour to what it was in versions 10 and earlier. SQL Anywhere Server - Utilities ===============(Release Build - Engineering Case #555056)=============== A new feature was added to the Interactive SQL utility (dbisql) in version 11.0.0, which automatically released database locks after executing queries when it was run as a windowed application. This feature was on by default, and was undocumented. It unfortunately also broke the locking tutorial, and introduced an unexpected behavioral change. The behavioral change has now been rectified. Automatic lock releasing is now OFF by default. This is a behavioral change from 11.0.0, but it makes dbisql consistent with older versions. Also, users can now control the automatic lock releasing feature explicitly. The "Result Set" tab in the "Options" window contains a new checkbox called "Automatically release locks". Check this if dbisql is to release locks after executing a statement. ===============(Release Build - Engineering Case #541734)=============== The Service utility (dbsvc) now supports creating services for the Relay Server (rshost) and the Outbound Enabler (rsoe) using "-t rshost" and "-t rsoe" respectively. SQL Remote for Adaptive Server Anywhere - SQL Remote Message Agent ===============(Release Build - Engineering Case #539681)=============== If a connection string included the LINKS parameter, but included an unrecognized protocol type (eg. due to a typo), the error message would have been: "Trying to add unknown port", which was not indicitive of the problem. This has been corrected so that the message is now: "Trying to add unknown port '<port>'" where <port> is the invalid port type. UltraLiteJ - Runtime ===============(Release Build - Engineering Case #547073)=============== Performance of database operations when there was a large transaction log (many transactions awaiting synchronization and/or checkpointing) has been improved. Note, GA versions of the software will not be able to read a database that has been used by UltraLiteJ as of this change. Earlier databases will automatically be upgraded. ================================================================================ 11.0.1 Bug fixes ================ The following is a list of bugs fixed in this version of the software, as compared to the 11.0.0 release. MobiLink - Java Plugin for Sybase Central ===============(Release Build - Engineering Case #550247)=============== The MobiLink Deployment wizard could have crashed with a missing resource exception. This has been fixed. ===============(Release Build - Engineering Case #549636)=============== When connected to a SQL Anywhere database in Admin mode of the MobiLink plug-in for Sybase Central, any internal tables used for maintaining text indexes would have been displayed under the Tables folder. This has been corrected so that these tables are now excluded, since they are of no use to users when creating table scripts. ===============(Release Build - Engineering Case #548890)=============== The delivery condition for a destination alias may not have been fully visible on the "Members" tab of the alias' property sheet. The cells in the table have their height and width set explicitly . The code which calculated a row's height looked only at data in the second column, rather than using the data in all three columns. This has been fixed. ===============(Release Build - Engineering Case #547522)=============== If the MobiLink system setup in the consolidated database was corrupt, then using the Check MobiLink System Setup command in the MobiLink plug-in could have caused a Java null pointer exception. This would only have happened if a MobiLink system setup stored procedure incorrectly had no parameters. This bug has been fixed. A workaround is to manually remove the MobiLink system setup and then re-run the command. ===============(Release Build - Engineering Case #547037)=============== When using the QAnywhere plugin, it was not possible to create an empty destination alias. This has been fixed so that creating an empty alias is now possible. ===============(Release Build - Engineering Case #546912)=============== The wrong item could have been edited or deleted if the list that contained the item was sorted. This would have occurred in the following places: 1. List of members for a given destination alias 2. "Properties" tab of client store property sheets 3. The "Client Properties" tab of the property sheet for a server message store 4. The "Members" tab in the property sheet for a destination alias 5. The property sheet for a client in a server message store 6. The "Transmission Rules" or "Deletion Rules" tabs in any property sheet. 7. The "Properties" tab of a connector's property sheet. This has now been fixed. ===============(Release Build - Engineering Case #546869)=============== The property sheet for connectors contained a "Transmission Rules" page. This was incorrect because connectors do not have transmission rules; they have delivery conditions. As a result, that page has been replaced with a new "Delivery Conditions" page in which the single delivery condition for the connector can be typed. ===============(Release Build - Engineering Case #546046)=============== The QAnywhere plugin could have reported an internal error (NoClassDefFoundError) when connecting to a server message store if the plugin was registered with Sybase Central directly (i.e. using the QAPLUGIN.JAR file) rather rather than by using an installer-created .JPR file. This has been fixed. The workaround is to add "mldesign.jar" to the list on the "Advanced" page of the QAnywhere 11 plugin properties window. ===============(Release Build - Engineering Case #542239)=============== If the Admin Mode Connection Script wizard was used to create event scripts for handle_UploadData and handle_DownloadData events, they would get an "unknown event" error when syncing. The problem was that the event scripts were created with the names "handle_uploaddata" and "handle_downloaddata" (note the differences in case). This has been fixed. ===============(Release Build - Engineering Case #535973)=============== Changes made to property values on the "Client Properties" page, in a server message store's property window, would not have been saved if the client was "(Default)". This has been corrected so that they are now saved correctly. Also, if connecting using a QAnywhere connection profile was not possible, Sybase Central would have crashed rather than reporting the error. This has been corrected as well. ===============(Release Build - Engineering Case #534995)=============== When deploying a synchronization model to an UltraLite remote database, the generated <model>_ulsync.bat and dblsn.txt files incorrectly used the version 10 syntax for ulsync. This has now been corrected. ===============(Release Build - Engineering Case #534320)=============== Sybase Central could have crashed while using the QAnywhere plugin, if the connection to a server message store was unexpectedly lost. This has been fixed. ===============(Release Build - Engineering Case #481976)=============== When creating a new synchronization model for an existing remote database, the column order may not have been correct for upload_fetch or upload_fetch_column_conflict events. This has now been fixed. To fix existing synchronization models (after installing this fix), each synchronizing table must be set to 'Not Synchronized', the model saved, and then set back to their previous synchronization settings. ===============(Release Build - Engineering Case #532452)=============== The changes for Engineering case 530534 (which was a followup fix to Engineering case 491400) were incomplete, resulting in the Overview marquee not updating when zoomed out with the marquee at the leftmost position. This has been fixed. MobiLink - Monitor ===============(Release Build - Engineering Case #556925)=============== The fix for Engineering case 553312, may have prevented restarting the MobiLink Monitor after disabling the Details Table, Utilization Graph, or Overview panes. This has been fixed. Pane sizes are now also properly restored when re-enabling after restarting. ===============(Release Build - Engineering Case #553312)=============== If the MobiLink Monitor's Details Table, Utilization Graph, or Overview panes were disabled, when reenabled they might not be visible, under some circumstances, or a program error may have occurred. Also, resizing a pane or the application, could have produced unexpected results. These problems have been fixed. Now when resizing the application, only the Chart pane size is changed; and when resizing a pane, only the panes on either side of the splitter bar are affected. ===============(Release Build - Engineering Case #548455)=============== When attempting to export synchronized data to an Oracle database, the application could have given a false positive for a table's existence, which would have resulted in an export failure since it would not have tried to create the table for the current user. This has been fixed. Also, exports to Oracle previously used the Date data type. Now, for Oracle 9 or later Timestamp is used instead of Date. ===============(Release Build - Engineering Case #539499)=============== If the Overview, Details Table or Graph were disabled in the MobiLink Monitor, closing the Monitor and restarting it would have resulted in a Java null pointer exception. This has been fixed. A workaround is to edit the settings file (.mlmMonitorSettings in version 10 and earlier, .mlMonitorSettings11 in version 11) to restore display of the disabled feature. For the Overview, change ShowOverview=false to ShowOverview=true. For the Table, change ShowTable. For the Graph, change ShowGraph. ===============(Release Build - Engineering Case #537620)=============== The sync_request phase time was incorrect in the MobiLink monitor. It was usually 0, but could be negative. This has been fixed. MobiLink - QAnywhere client ===============(Release Build - Engineering Case #552767)=============== A QAnywhere application could have reported a deadlock error from the SQL Anywhere server, if the application was attempting to retrieve a message from the message store while the QAnywhere agent was synchronizing. This has now been fixed. ===============(Release Build - Engineering Case #537579)=============== The QAnywhere client (qaagent) would have silently initialized a new database the first time it was run. This has been fixed so that it now is mandatory to initialize a new database as a QAnywhere message store by running qaagent with -si, as a separate step. ===============(Release Build - Engineering Case #535983)=============== The usage messages for the QAnywhere Stop utility (qastop) did not display correctly on some non-english systems. This has been fixed. ===============(Release Build - Engineering Case #533612)=============== On a slow devices, the QAnywhere client (qaagent) would sometimes have given the following error messages at start up: "Error registering with DBLSN code: -1" and "Failed to start QAnywhere Agent (register with DBLsn)". This has been fixed so that the QAnywhere client is now much more tolerant to lengthy dblsn startup times. ===============(Release Build - Engineering Case #533249)=============== The download phase of a synchronization could have failed with a -194 error ("No primary key value for foreign key"). This was most likely to have occurred during large synchronzations or when the database engine is under considerable stress. This has now been fixed. ===============(Release Build - Engineering Case #531730)=============== After modifying the incremental download size of the QAnywhere Agent using the -idl option, it would not have been possible to reset the size to the default value of -1. Attempting to set the size to -1 would have left the incremental download size unchanged. This has been fixed. Now, specifying any non-positive number for the -idl option will reset the incremental download size to -1. ===============(Release Build - Engineering Case #531323)=============== If the QAnywhere Agent for Ultralite experienced a failed synchronization then there was a chance that subsequent synchronizations would then have failed with a -193 primary key not unique error. This has been fixed MobiLink - QAnywhere server ===============(Release Build - Engineering Case #546176)=============== When running a farm of MobiLink servers with QAnywhere messaging enabled, the delete rules and archiving process could have logged "deadlock detected" errors in the MobiLink server log. The rules were functioning correctly, but unnecessary database contention was occurring. This has been fixed by having the delete rules and archiving process run only in the primary server. ===============(Release Build - Engineering Case #546171)=============== When a delivery condition that referenced message properties was specified for a QAnywhere connector, message transmission to the connecting messaging system would have been disabled. This has been fixed. ===============(Release Build - Engineering Case #546164)=============== During the execution of server transmission rules, it was possible for the QAnywhere server to repeatedly report a java.util.NoSuchElement exception, and abort the rule execution. This has been fixed. ===============(Release Build - Engineering Case #545690)=============== When a message was sent to a destination alias, the QAnywhere Server may not have immediately generated push notifications for some members of the alias. This could have resulted in the server taking as long as a minute to push notifications to clients. This has been fixed. ===============(Release Build - Engineering Case #467274)=============== When a QAnywhere application (using SQL Anywhere as the message store) queued messages in time zone A, and then the time zone of the device was changed to time zone B with time earlier than time zone A, the queued messages would not have been transmitted until the time in time zone B reached the time that the messages were queued in time zone A. This has been fixed so that the messages queued in time zone A are now sent immediately when the device is online in time zone B. Note that the issue of time zone independence with QAnywhere has not been completely addressed. All time values used in transmission rules refer to local time. Also, the special variable ias_StatusTime, used in transmission rules, refers to local time. ===============(Release Build - Engineering Case #537595)=============== The changes for Engineering case 534179 introduced a problem where the QAnywhere Server's logging messages could have been output as garbled text. This has now been corrected. ===============(Release Build - Engineering Case #533728)=============== A small window of opportunity existed in the QAnywhere server where a statement could be closed and removed from the statement cache, just as another thread was preparing the statement to be closed. This resulted in some operations being performed on a closed statement, resulting in a JDBC error. This has been fixed ===============(Release Build - Engineering Case #531967)=============== The QAnywhere Server would have throw an ObjectRepositoryException if it was configured to use a delete rule with an empty condition clause. That is, if a rule was given that had nothing written to the right of the equals sign. One such rule might look like: "AUTO=" This has been fixed. Specifying an empty condition clause now specifies that all available messages should be deleted. ===============(Release Build - Engineering Case #531766)=============== If a JMS message bound for a QAnywhere client was missing its native address, and no default address was specified for the JMS connector, the QAnywhere Server would have reported a NullPointerException. This has been fixed. The server now reports the proper error message ===============(Release Build - Engineering Case #549052)=============== Scheduled transmission rules defined in the MobiLink server for QAnywhere message transmission, could have behaved unexpectedly in some circumstances. The server would have sent push notifications to clients with waiting messages satisfying the condition of a scheduled rule according to the schedule. However, if a client synchronized with the server for any reason, whether or not as a result of a push notification from a scheduled rule, messages satisfying the condition of a scheduled rule would have been transmitted to the client. Thus, the unexpected behaviour was that messages that satisfied the condition of a scheduled rule in the server could have been transmitted from the server to clients at times differing from the times specified in the schedule. This has been fixed so that the transmission of messages that satisfy the conditions of the scheduled rules from the server to clients is now governed more closely by the schedule specified in those rules. MobiLink - Relay Server ===============(Release Build - Engineering Case #552720)=============== When the Relay Server was under heavy load, with verbosity set to 4 or higher, it may have occassionally reported an OE_BACKEND_DISCONNECTED error. This was due to another session having taken over the request id. This was not harmful to known client types, as all known clients initiates their own disconnect. However, this may have caused the Relay Server to hold onto resource for the worker waiting for that packet. This would have timeout in 100 sec, and was transparent to the client. This has been fixed, the client worker is no longer held up until it ties out, as the faulty discarding has being removed. ===============(Release Build - Engineering Case #552716)=============== The Relay Server's throughput may have been reduced significantly when under load with Afaria traffic. This was caused by Afaria traffic not terminating persistent http sessions properly, when using Connection: close header. IIS did not release its resources until the connection's Keep-Alive timeout. Per-process resource limits cap the throughput when enough sessions are waiting to be timed out by IIS. This has been fixed bay having the Relay Server terminate Keep-Alive connections regardless of the presence of the Connection: close header, in the case where content-length is violated. Since Afaria traffic always violates content-length on the last request, in both of their POST and GET sessions, IIS will no longer hold on to keep-alive resources when the last request of their session exit the web server extension. This change also stops the Relay Server from complaining about content-length violations, if the client identifies itself as an Afaria client. The I/O error only is being suppressed. A user workaround is to increase web garden size (i.e. adding more worker processes) of the application pool associated with the rs_client.dll web server extension. This user workaround is inefficient though, letting limited resources to be held idle for unnecessary amount of time. With this fix, per process resource caps are no longer a reason for increasing the web garden size. ===============(Release Build - Engineering Case #552658)=============== The Relay Server may have crashed under stress and the Outbound Enabler may not have been able to recover connections to it, even when IIS replenished the service with a new worker. These potential crashes have been fixed. ===============(Release Build - Engineering Case #552649)=============== The Relay Server Outbound Enabler would have held on to a backend connections until the application timed out, when the request/response processing of the associated session had failed. Tnis has been fixed so that the Relay Server will now forward a command to the Outbound Enabler to explicitly disconnect the faulty session. ===============(Release Build - Engineering Case #552644)=============== Up channel recovery upon the Relay Server Outbound Enabler detecting a communication error may have sometimes failed on some active sessions. This has been corrected. Note, normal up channel renewal was not affected by this fix. ===============(Release Build - Engineering Case #551003)=============== When a backend server entry was removed from the Relay Server configuration file, and the rshost -u command was applied, the removed backend server should have been disabled, but it was not. This is now fixed. ===============(Release Build - Engineering Case #551002)=============== When a backend farm or backend server was disabled, the associated Relay Sserver Outbound Enabler could still have connected to a Relay Server even though further new relay service to that farm or server was blocked. This problem has been fixed. ===============(Release Build - Engineering Case #550999)=============== If an error occurred while the Relay Server Outbound Enabler was attempting to renew the up channel, it did not try again. Current client sessions going through the Outbound Enabler would not have survived. This has been fixed so that the Outbound Enabler now attempts again to renew the up channel, in order to preserve active client sessions. ===============(Release Build - Engineering Case #550991)=============== Client type information was not available in Relay Server log. Alternatively, users may have been able to derive the client type by looking at the optional user-agent header logging in the Web server's access log. However user-agent headers can be uncontrollable on certain mobile application platforms. Changes have been made which now allows the Relay Server to identify the following 11 types of known clients using a combination of user-agent header and proprietary header: Afaria dblsn DBMLSync MLClient // All pre-11.0.1 ml clients MLFileTransfer MLLightPoll MLMonitor UltraLite UltraLiteJ QAnywhere QAnywhereUL These client types, and the full client information (usually including build and version), will be logged by the Relay Server under verbosity level 1 or higher. ===============(Release Build - Engineering Case #550989)=============== When the Relay Server was relaying normal Afaria traffic, it would have reported the following error and warning: ... <F0B1S0R0> IIS ReadClient error(10054): Connection was forcibly closed by the remote host. ... <F0B1S0R0> Failed reading from client. Aborting this request. ... <F0B1S1R1> Communication warning! Backend server disconnected before finishing response. These are expected, as Afaria traffic uses false http content-length. The Relay Server will now suppress these messages for Afaria traffic. ===============(Release Build - Engineering Case #550985)=============== There are documented rules for making Relay Server configuration changes in a Relay Server farm environment. When those rules were violated, a farm of Relay Servers may have resulted in heterogeneous backend farm and server indices on different Relay Servers. When a tcp load-balancer, instead of a http load-balancer, was used to maintain client-RS affinity, client sessions could not survive moving across Relay Servers in such Relay Server farms. This has been fixed by remoings the need to keep the indices in sync across all Relay Servers. ===============(Release Build - Engineering Case #550957)=============== The Relay Server cannot grow the pre-allocated shared memory dynamically and it is essential that users start up the server with sufficient memory to handle foreseeable peak traffic. As well. there has been no tool for users to determine the amoumt of shared memory Relay Server was using. Now, a snap shot of shared memory usage is reported in the log file whenever the log is archived. That is when rshost.exe -ua is executed, the running Relay Server will log the current shared memory usage, archive and then truncate the log file. ===============(Release Build - Engineering Case #550956)=============== The Relay Server may have reported the error "Internal error! Session number out of sync." when handling a server response. When this error occurred, further traffic going through the same Relay Server to this particular responding backend server, had an increased chance of failure. This would have reduced the quality of service to the affected Relay ServerS serving the backend server where the problem first arose. The problem also would not have cleared itself until the affected Relay Server was restarted. Traffic going through other Relay Servers in the Relay Server farm, traffic going through the same Relay Server to other backend farms, or traffic going through the same Relay Server to other servers within the same backend farm would not have been affected. This problem has now been fixed. ===============(Release Build - Engineering Case #545917)=============== When the Relay Server (rshost) or the Relay Server Outbound Enabler (rsoe) RSHOST executables printed the usage message, empty lines and/or garbage characters could have been displayed after the usage message. This has now been fixed. ===============(Release Build - Engineering Case #542516)=============== Shutting down the Relay Server Outbound Enabler could have caused the communication error message: "Communication error! Failed reading." to be logged in the Relay Server log file. This has been fixed. ===============(Release Build - Engineering Case #539496)=============== At verbosity level 3 or above the Relay Server was logging a faulty protocol version of the connecting Outbound Enabler. The Relay Server also did not completely log the OE_REQUEST_RS_PEER_LIST packet. Although these problems were not affecting the Relay Server's functionality, they have been fixed. ===============(Release Build - Engineering Case #538963)=============== The Relay server was holding on to workers when finished serving Afaria traffic. A new command line option "-af" has been added to the Relay Server Outbound Enabler (rsoe) so that the Relay Server will be notified when the backend server disconnects. The relay server will then abort waiting for the entire content length to be satisfied. Without this option, rsoe will not notifiy the Relay Server when the backend disconnects and a worker in the Relay Server has finished relaying responses from an Afaria server, but will wait for more data until a timeout (default 8 minutes) before exiting. Older Relay Servers are not compatible with this newer rsoe. Newer Relay Server remains backward compatible with an older rsoe though. ===============(Release Build - Engineering Case #538953)=============== The Relay server may have failed to relay http responses for a several minutes after seeing an rsoe uuid mismatch on down channel connect. This would have been rare, as it required the down channel to be renewed right before an up channel renewal, plus the up channel renewal must have renewed the uuid before the down channel was authenticated. The Relay Server would have eventually detected an error on writing over the failed down channel and would have been able to recover, however http responses or portions of it relayed within that period were lost. This problem has been fixed and a rsoe uuid mismatch should not occur on a down channel unless this is caused by invalid running duplicated instances of the Relay Server with the same backend server identity. MobiLink - SA Client ===============(Release Build - Engineering Case #554271)=============== If the MobiLink client (dbmlsync) was run against a database with a character set that was different from the operating system's character set, then errors generated by the database would have been garbled when displayed in the dbmlsync log. This has been corrected so that these messages will now be displayed correctly. ===============(Release Build - Engineering Case #544956)=============== If MobiLink Client was performing a synchronization, and the status of the last synchronization was unknown, it was possible for the MobiLink Server to have reported that the synchronization had started twice. The MobiLink Log with no extra verbosity might contain the following messages: Request from "Dbmlsync Version 10.0.1.3750" for: remote ID: rem1, user name: rem1, version: v1 Request from "Dbmlsync Version 10.0.1.3750" for: remote ID: rem1, user name: rem1, version: v1 Synchronization complete This problem has been fixed. ===============(Release Build - Engineering Case #540407)=============== In the dbmlsync log file it was possible for a message to occasionally be omitted, or for two messages to be mixed together. For example, a line like the following might occur in the log: E. 2008-08-06 16:24:34. Timed out trying to readTimed out trying to read 7 bytes. This has been fixed. ===============(Release Build - Engineering Case #538936)=============== The Dbmlsync Integration Component could have crashed during a call to the Run method. As well, the OS would sometimes have detected a heap error. This has been fixed. ===============(Release Build - Engineering Case #537787)=============== If a C++ application had been created using the DBSync API, it was possible that this application would not have been able to connect to the a MobiLink client started in server mode, if the machine supported IPv6. This has now been fixed. ===============(Release Build - Engineering Case #533746)=============== If a download was interrupted by a network failure, it was possible for the MobiLink client (dbmlsync) to fail to create a restartable download file. Furthermore, dbmlsync would have displayed a network error to the dbmlsync log, but then attempted to apply the partial download, which would almost certainly have failed. This has been fixed so that dbmlsync now creates a restartable download file and does not attempt to apply the partial download. ===============(Release Build - Engineering Case #546742)=============== The MobiLink client (dbmlsync) could have crashed when reporting certain TLS or HTTPS errors. Certain TLS errors could have caused a null pointer dereference during creation of the error message string. This has now been corrected. ===============(Release Build - Engineering Case #531993)=============== On the MobiLink client's setup dialog, clicking either the "cmdline help" or "extended option help" buttons would have caused dbmlsync to shutdown without displaying the help dialog. This has now been fixed. ===============(Release Build - Engineering Case #531128)=============== On Unix systems, when starting the MobiLink client (dbmlsync) in server mode after having recently shutdown an instance of dbmlsync in server mode, if the same port number was reused on the -sp option it was possible for dbmlsync to have failed to start and report an error similar to "unable to bind to port ...". This problem has now been fixed. MobiLink - Streams ===============(Release Build - Engineering Case #553300)=============== Network error messages in the MobiLink monitor, the SA Monitor, the Notifier or the QAnywhere server could have been garbled on non-English machines. This has been fixed. ===============(Release Build - Engineering Case #548144)=============== If a network error occurred during a read from the stream, some MobiLink Java clients could have hung with 100% CPU utilization. This has been fixed. The MobiLink Monitor, the SQL Anywhere Monitor, the Notifier and QAnywhere are all affected by this. ===============(Release Build - Engineering Case #536173)=============== If the file containing the trusted certificates specified by the "trusted_certificates" option was not found, the error STREAM_ERROR_SECURE_ADD_TRUSTED_CERTIFICATE was reported, which was not very specific. Now STREAM_ERROR_SECURE_TRUSTED_CERTIFICATE_FILE_NOT_FOUND is reported, as was done in 10.0 and previous versions. ===============(Release Build - Engineering Case #532116)=============== Synchronizations through a server that required Digest HTTP authentication would have failed if the server required a reauthentication in the middle of the synchronization. This has been fixed so that the client will now successfully reauthenticate and continue the synchronization. MobiLink - Synchronization Server ===============(Release Build - Engineering Case #555985)=============== The MobiLink server would given an error message that the classpath was too long if the Java classpath given in the -sl java option was longer than about 3000 characters. This restriction has been removed. ===============(Release Build - Engineering Case #553387)=============== The following fixes have been made to support MobiLink in DB2 Mainframe Compatibility Mode - The ml_pt_script table did not have an explicit ROWID column. This was required for the CLOB column. Some D2M deployments support an implicit ROWID, and some do not, inluding compatibility mode. Fixed by adding an explicit ROWID column. - The SQL used for JCL-based CREATE PROCEDURE statements included the SQL body of the stored procedure. This worked most of the time, but not under compatibility mode. Now, the external-procedure form of CREATE PROCEDURE is used, which doesn't include the body (which of course isn't necessary because it is in the *.xmit files). - The SQL used to create the SQL-based D2M stored procedures didn't escape single quotes. This wasn't noticed because D2M treats most unquoted text between single quotes as a string, so it just worked. Single quotes are now escaped in the procedure body, inside the call to DSNTPSMP. - The D2M ml_add_pt_script stored procedure didn't work under compatibility mode, for several reasons: 1) it had a VARCHAR( 256 ) parameter (the flags for the SQL Passthrough script) that caused conversion problems inside the procedure when run under compatibility mode. This parameter has been changed to VARCHAR( 255 ). 2) it referenced a Unicode string, which isn't supported under compatibility mode. This has been fixed by replacing it with a non-Unicode string. 3) it used a form of the SIGNAL statement that isn't supported under compatibility mode. This has been corrected. ===============(Release Build - Engineering Case #553482)=============== Prior to executing the "begin_connection_autocommit" script, the MobiLink server will temporarily turn on auto-commit on the ODBC connection, due to restrictions with some consolidated databases. On ASE consolidated databases, this will generate a warning (SQL_SUCCESS_WITH_INFO) in the ODBC driver: "AutoCommit option has changed to true. All pending statements on this transaction (if any) are committed." This warning was being generated whether the begin_connection_autocommit script was defined or was absent. This has been fixed. The server will now only turn on auto-commit when the script is defined and will only execute the script if it is defined. If the script is defined, it is still possible to see this warning logged in the MobiLink server console log. This is expected behaviour. ===============(Release Build - Engineering Case #539627)=============== Some lines printed to the MobiLink server log would not have caused LogListeners to fire. In particular, warning 10082, "MobiLink server has swapped data pages to disk out:<...> concurrently used pages:<...>", never triggered LogListeners. This has been fixed. ===============(Release Build - Engineering Case #551858)=============== If a remote server used character length semantics for a string column (e.g. a SQLAnywhere remote with an nchar column, or an UltraLiteJ remote with a char column), and the column on the remote database was smaller than the column in the consolidated database, then the MobiLink server could have failed to report the truncation. The server was already counting the number of characters in the the column coming out the consolidated, but it wasn't checking the length against the domain info given by the remote. This has now been fixed ===============(Release Build - Engineering Case #551813)=============== Messages printed to the MobiLink server log could have been mangled on systems with non-English character sets. This would have happened most often on errors from QAnywhere or the Notifier. This has now been fixed. ===============(Release Build - Engineering Case #547906)=============== If a column in the consolidated database was larger than the corresponding column in the remote database, then the MobiLink server may have crashed when synchronizing. This has been fixed so that the sync will now abort with the error -10038. ===============(Release Build - Engineering Case #551264)=============== On Windows systems, if msvcr71.dll is not on the path and Java, the Notifier, QAnywhere or SQLPassthrough were being used, then the MobiLink server would have failed to start with an error stating that MSVCR71.DLL could not be loaded. This has been fixed. A work around is to put msvcr71.dll on the path. It is installed with the JRE. ===============(Release Build - Engineering Case #549235)=============== The external names for the D2 Mainframe stored procedures were supposed to be xxxa for version 10, xxxxb for version 11, and xxxxc for version 12. The changes for Engineering case 545762 incorrectly caused the names to be xxxxW. The scripts sent out as xxxxW will still be okay, as the important thing is that major versions differ in the external names by at least one character, so customers can use multiple versions of MobiLink in the same consolidated. This has now been corrected. ===============(Release Build - Engineering Case #548519)=============== The process for creating the MobiLink stored procedures for DB2 mainframe (D2M) via syncd2m_jcl.sql was not complete. This has been fixed. With the addition of d2mrelod.jcl, the steps are now: 1) Copy syncd2m_jcl.sql and edit it. Change {MLTABLESPACE} to your qualified tablespace, eg. MYDB.MYTS Change {WLMENV} to the name of a WLM associated with your DB2 instance 2) Start DBISQL and connect to DB2 mainframe. File->Run your copy of syncd2m_jcl.sql. 3) From the %SQLANY%\MobiLink\setup directory, FTP to your mainframe, running the following commands after you connect: bin hash cd xmit quote site recfm=fb lrecl=80 quote site cyl put d2mload.xmit put d2mdbrm.xmit quit The two XMIT files on the mainframe are now: USERID.XMIT.D2MLOAD.XMIT USERID.XMIT.D2MDBRM.XMIT where 'USERID' is the username you gave when connecting via FTP. 4) Open a terminal session and run the following commands from the ISPF Command Shell: RECEIVE INDATASET('USERID.XMIT.D2MLOAD.XMIT') RECEIVE INDATASET('USERID.XMIT.D2MDBRM.XMIT') The output is: USERID.ML.LOADLIB USERID.ML.DBRMLIB 5) Copy d2mrelod.jcl and edit it. Change USERID to your mainframe userid. Change DSNDB0T to your DB2 DSN. 6) Run your copy of d2mrelod.jcl 7) Copy d2mbdpk.jcl and edit it. Change USERID to your mainframe userid. Change DB0T to your DB2 SSID. 8) Run your copy of d2mbdpk.jcl The MobiLink schema should now be ready to use. ===============(Release Build - Engineering Case #548032)=============== The MobiLink server would have printed the warning, "[10082] MobiLink server has swapped data pages to disk", after it had swapped 5000 pages to disk, or about 20MB of row data. This has been changes so that it now prints this message after the first time the server must swap to disk. This should make it easier to diagnose performance problems when -cm is set slightly too small. ===============(Release Build - 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. ===============(Release Build - Engineering Case #547716)=============== Attempting to add a blob to the download stream when using the MobiLink Direct Row API and the MLPreparedStatement.setBytes() method, would have failed. The method would have returned the error "Value is out of range for conversion" if the length of the byte array was larger than 65536 bytes. This problem has now been fixed. ===============(Release Build - Engineering Case #547041)=============== Some remotes could have synchronized with servers that were not licensed to synchronize with those remotes. This has been corrected. ===============(Release Build - Engineering Case #546256)=============== When connected to a DB2 Mainframe (D2M) consolidated database, the MobiLink server could have held locks across COMMITs, causing increased contention and sometimes resulting in deadlock or timeout errors. This has been fixed. ===============(Release Build - Engineering Case #545762)=============== The MobiLink system stored procedures for DB2 Mainframe were created with a default isolation level of RR (Repeatable Read = Serializable) instead of CS (Cursor Stability = Read Committed). This has been fixed. ===============(Release Build - Engineering Case #546173)=============== When uploading timestamp data with the .NET Direct Row API, an exception could have been thrown. Even if an exception wasn't thrown, the fractional part of the timestamp would have been incorrect. When downloading timestamps with the .NET Direct Row api, values would have been incorrect by a few seconds. Both of these problems have now been fixed. ===============(Release Build - Engineering Case #544763)=============== The -nc option, which limits the number of concurrent sockets opened by MobiLink server, wasn't feasible to use with non-persistent HTTP/HTTPS, because sockets that could have been continuations of valid synchronizations might have been rejected. The -sm option has been improved to provide similar functionality to -nc when used with non-persistent HTTP/HTTPS. Furthermore, the MobiLink server should usually have provided HTTP error 503 (Service Unavailable) to the remote when the -sm limit was reached and sessions were kicked out. If the -nc limit was reached, however, the error would instead have been a socket error -- usually with a system code about being unable to connect, but experience has shown the system code can vary. Note, to limit the number of concurrent synchronizations for non-persistent HTTP/HTTPS, the -nc option should be set significantly higher than -sm. The greater the difference between -sm and -nc, the more likely (but never guaranteed) the 503 error will be sent to the remote instead of a socket error. ===============(Release Build - Engineering Case #544943)=============== The MobiLink server could have hung, or crashed, when using encrypted streams. The behaviour was highly dependent on both timing and data size. This has now been fixed. ===============(Release Build - Engineering Case #544321)=============== An HTTPS synchronization through a proxy server that required authentication would have failed. When using HTTPS through a proxy server, the client first sends a CONNECT HTTP request to establish a channel through the proxy. Unfortunately, authentication challenges was only active for GET and POST requests. This has been corrected so that CONNECT requests are now active as well. ===============(Release Build - Engineering Case #543391)=============== A security flaw in the MobiLink server was fixed. ===============(Release Build - Engineering Case #542634)=============== In a MobiLink farm environment with Server-Initiated Sychronization, when the secondary notifier was under stress, it may have failed to have been promoted to the primary. This would have resulted in an I/O exception being thrown whenever a push or pollnow request arose. This problem has been fixed. ===============(Release Build - Engineering Case #540200)=============== When running the MobiLink server with minimal verbosity, and using the MobiLink Listener (dblsn), the message "Disconnected from consolidated database" would have appeared in the server log. This has been corrected. The connection used by dblsn will now be reused by the next dblsn client. ===============(Release Build - Engineering Case #541075)=============== If the MobiLink Server was processing an invalid upload stream, it was possible for the MobiLink Server to have crashed. The MobiLink Server will now fail the synchronization. ===============(Release Build - Engineering Case #539812)=============== The MobiLink server name given by the -zs command line option was not shown in the title bar of the MobiLink server window. This problem is corrected. ===============(Release Build - Engineering Case #539309)=============== If the MobiLink Server had been started with the -nba+ switch, it was possible for the MobiLink Server to have crashed if a non-blocking download acknowledgment was received from a remote database, and the MobiLink Server had lost all its connections with the consolidated database. The MobiLink server will now properly report that all connections to the consolidated database have been lost. ===============(Release Build - Engineering Case #538347)=============== If the MobiLink server was started unsuccessfully (i.e invalid parameter, unable to connect to database, invalid stream specified), and no logging option was specified (-o or -ot), then the server would have displayed an error dialog and waited for the shutdown button to be pressed. After waiting about a minute for the manual shutdown, the server could then have crashed. This has been fixed. Note, this problem should only have occurred on systems where a GUI was used. ===============(Release Build - Engineering Case #538145)=============== MobiLink servers with web edition licenses had an incorrect feature set. This has now been corrected. ===============(Release Build - Engineering Case #537917)=============== A download_delete_cursor script that returned NULL and non-NULL values for the primary key columns of a synchronized table would have made the MobiLink client behave erratically: the client could have deleted rows that should not have been deleted, or could have displayed the following error message: SQL statement failed: (100) Row not found This problem has been fixed. The MobiLink server will now complain if a download_delete_cursor returns NULL as well as non-NULL values for the primary key columns of a synchronized table, and will then abort the synchronization. The download_delete_cursor script must return NULL values for all the primary key columns (the MobiLink client will delete all the rows from the corresponding sync table) or non-NULL values (the client will delete specific rows specified by the primary key values). ===============(Release Build - Engineering Case #534179)=============== Java messages could have been corrupted on operating systems with non-English character sets. Character set conversion was not being done correctly. This has been fixed ===============(Release Build - Engineering Case #536746)=============== When an encryption library could not found, the MobiLink server would have issued a misleading message indicating corruption: Invalid or corrupt network interface library: xxxxx This has been corrected so that now the MobiLink server issues the message: Failed to load library xxxxx he documentation for the load library message indicates that a license may be required, which is appropriate in this case. ===============(Release Build - Engineering Case #537609)=============== If a synchronization contained tables for which no rows were uploaded or downloaded, the MobiLink server would have allocated more memory than was neccessary. This has been fixed so that the memory usage will be proportional to the number of columns in empty tables multiplied by the number of upload transactions. In tests with 50 concurrent syncs of 200 empty tables with 6 columns per table, the peak memory used by MobiLink server dropped by 178MB, or about 3kB per column. Systems that synchronize many empty tables, or use transactional uploads (i.e. the -tu option on dbmlsync), will see improved performance with this fix. ===============(Release Build - Engineering Case #533805)=============== If a consolidated database was running on an Oracle 9i or later server, the MobiLink server could have sent clients a next_last_download_time (a timestamp value used to generate a download in the next synchronization) that was earlier than the last_download_time (a timestamp value used to generate the download in the current synchronization). This problem could have caused a MobiLink client to complain when it was trying to apply the downloaded file. This problem has now been fixed. ===============(Release Build - Engineering Case #533804)=============== When the MobiLink server was under heavy load, the Mobilink monitor may have crashed, hung or disconnect from the Mobilink server. This has now been fixed. ===============(Release Build - Engineering Case #551593)=============== When the MobiLink system tables were not present on the consolidated database, the MobiLink server would have displayed the following error on start-up: [-10076] The MobiLink server was unable to calculate the timestamp precision on the consolidated database using the ml_scripts_modified table. Timestamp precision related warnings will not be generated. This has been fixed. The following error will now be displayed: [-10100] The MobiLink system table 'ml_user' is missing or a table column is missing ===============(Release Build - Engineering Case #548580)=============== Synchronizing a UNIQUEIDENTIFIER field in a remote database to Oracle via MobiLink would have resulted in a 32 character UUID, followed by a NULL character and three other characters (typically also NULL). When sending GUIDs to Oracle, MobiLink was removing the hyphens to match the GUIDs generated by the SYS_GUID() function in Oracle, but was not trimming the ODBC bind length to account for the hyphen removal, thus resulting in 4 extra bytes in the string representation of the UUID in Oracle. These four extra characters have now been removed. MobiLink - Utilities ===============(Release Build - Engineering Case #548463)=============== Using the Certificate creation utility (createcert) to create certificates or certificates requests would have failed with the error "Error occurred encoding object", when provided non-ASCII input. This has been fixed. ===============(Release Build - Engineering Case #544613)=============== In an SIS environment, if a MobiLink client device went offline (device a), and then another client device (device B) came online with the same device address (ie. IP address/port) as A, and an SIS UDP notification for client A was sent by the notifier, then client B would have received and rejected the notification with an error similar to the following: Error: <Notifier(QAnyNotifier_client)>: Request 1604437321 is accepted by invalid respondent 'ias_receiver_lsn'. Please check the message filters on the listener This error would have happened whenever a UDP notification for client A was sent, resulting in wasteful SIS notifications. This has now been fixed. For 9.0.2, the fix was made only for MobiLink with messaging (QAnywhere) for ASA consolidated databases. In later versions, the fix applies to all MobiLink Notifiers in all supported consolidated databases. ===============(Release Build - Engineering Case #539799)=============== Notifier errors were cataglorized as MobiLink server errors. Errors such as failing to resolved a delivery path to a remote device, and/or failing a push attempt, was resulting in an error line in the MobiLink server log that began with an "E.". This also caused an new entry in the system event log. Notifier errors can be highly repeatative, if the business logic was not implemented in a way that minimized failing attempts. Since these failures are not affecting syncs, they have been recataglorized as informational messages that begin with "I." instead. Two sub labels, "<SISI>" and "<SISE>" have also been added to differentiate notifier informational message and notifier error message. Notifier informational message will now take on the following format: I. YYYY-MM-DD HH:MM:SS. <Main> <SISI> ... Notifier error message will now take on the following format: I. YYYY-MM-DD HH:MM:SS <Main> <SISE> ... ===============(Release Build - Engineering Case #535990)=============== The banner for the certificate utilities createcert, viewcert, and createkey could have been mangled on non-English systems. This has been fixed. ===============(Release Build - Engineering Case #535235)=============== The Listener utility (dblsn) with persistent connection turned off, may have failed to confirm message delivery or action execution. This may also have caused the MobiLink server to report protocol errors. This has been fixed. ===============(Release Build - Engineering Case #535244)=============== The IIS relay server would have leaked one mutex handle per http request. This has now been fixed. A workaround is to set the worker recycling option for IIS to ON, in order to keep the leak under control. ===============(Release Build - Engineering Case #498343)=============== When the visual version of the Dbmlsync Integration Component activex was used on Japanese Windows XP, the font selected for the log window did not support Japanese characters. As a result any Japanese text printed to the log window was garbled. An appropriate font is now used. MobiLink - iAS Branded ODBC Drivers ===============(Release Build - Engineering Case #547049)=============== After calling SQLGetTypeInfo, the application would not have been able to get the column names through problem could have prvented exporting MobiLink Monitor data to an Oracle database. This has now been fixed. ===============(Release Build - Engineering Case #546072)=============== The iAS ODBC driver for Oracle could have crashed when the application tried to create multiple connections concurrently. This problem was more likely to have occurred on Unix systems. This problem has now been fixed. ===============(Release Build - Engineering Case #533749)=============== The iAS ODBC driver for Oracle could have given mangled error and warning messages to the application when it was running on a operating system that used a multi-byte character set, such as a Japanese or Chinese. This problem is now fixed. MobiLink - scripts ===============(Release Build - Engineering Case #551615)=============== With Microsoft SQL Server 2005 and higher, the check for the existance of an index on given table did not work with tables under schemas that did not have a corresponding user. This has been fixed. A workaround is to deploy to file and then modify the SQL file to use the sys.schemas table wherever the sysusers table is currently used, and change the id, uid column references to object_id and schema_id for that table. SQL Anywhere Server - ADO.Net Managed Provider ===============(Release Build - Engineering Case #555185)=============== It was not possible to retrieve the columns for a primary key index using the method SAConnection.GetSchema. The SAConnection.GetSchema method was using a view which did not include the columns for primary keys. This problem has been fixed. ===============(Release Build - Engineering Case #554779)=============== It was not possible to retrieve index or key information through calls to the SAConnection.GetSchem method. The SAConnection.GetSchema method was using a view which did not include the primary keys. This problem has been fixed. ===============(Release Build - Engineering Case #552931)=============== When executing a batch command which returned multiple resultsets, if fetching the second or subsequent resultset caused an error, no exception was not returned to the application. This problem has now been fixed. ===============(Release Build - Engineering Case #486086)=============== Long exception message generated by the provider could have been truncated. This problem has been fixed. ===============(Release Build - Engineering Case #536608)=============== Calling sa_set_option('AcceptCharset', '+'); from within a stored procedure that is called via an HTTP request should set the response to the database charset whenever possible, but when a client specified the database charset it was only selected when its q-value was among the highest. This has been fixed so that the response uses database charset if specified by the client, regardless of q-value preference. Example: SA server uses ISO-8859-1 charset, client specifies Accept-Charset:UTF-8,IBM850;q=0.8,ISO-8859-1;q=0.5 Although least preferred by the client, SA will respond with ISO-8859-1 if SA_SET_HTTP_OPTION('AcceptCharset', '+'); has been called (from within a procedure servicing the HTTP request). ===============(Release Build - Engineering Case #536563)=============== The insert performance sample (instest) shipped with SQL Anywhere did not correctly assign values to integer columns on 64-bit big-endian platforms. Depending on the definition of the table being used, may have caused instest to terminate prematurely. The instest sample has now been corrected. This problem can be worked around by modifying the FillItem() function in instest.sqc to use an "int", instead of a "long", in the cast performed for the DT_INT/DT_UNSINT case. ===============(Release Build - Engineering Case #533979)=============== The columns from stored procedure result sets were not being excluded when Visual Studio enumerated stored procedure parameters. This has now been corrected. ===============(Release Build - Engineering Case #533570)=============== If a row was deleted, the delete rolled back, and then the row was updated, a snapshot scan may have seen the updated value before the update was committed. This has now been fixed. ===============(Release Build - Engineering Case #533478)=============== A multi-threaded client application, using the ADO .Net provider, could have crashed, hung or leaked memory if it did not handle thread synchronization properly. This problem has now been fixed. ===============(Release Build - Engineering Case #532999)=============== The database property 'VersionStorePages' was reporting the total number of pages in the temporary file rather than the number of pages in the version store. This has now been fixed. SQL Anywhere Server - DBLIB Client Library ===============(Release Build - Engineering Case #549682)=============== In rare, timing-dependent circumstances, multi-threaded client applications with multiple simultaneous TLS connections could have crashed. This has been fixed. ===============(Release Build - Engineering Case #546070)=============== The operation executed after an embedded SQL application executed a FETCH, could have caused a crash if the cursor was opened without WITH HOLD and a COMMIT or ROLLBACK was done by a procedure or function called by the FETCH. This has been fixed. ===============(Release Build - Engineering Case #538865)=============== Applications using TLS on Mac OS X systems, may have experienced crashes. This has been fixed. ===============(Release Build - Engineering Case #537774)=============== Under rare circumstances, clients running on Unix systems, could have crashed on disconnect. This has now been fixed. ===============(Release Build - Engineering Case #534482)=============== If a connection string contained an invalid encryption parameter, or was missing the mandatory trusted_certificates parameter, the error returned would have been: "Could not initialize the encryption DLL: '???'" This has been corrected so that a TLS handshake error will now be returned, as in previous releases. ===============(Release Build - Engineering Case #498395)=============== In vary rare circumstances, a Solaris client application may have crashed when attempting to connect to a server. This would have occurred if the communications initialization code failed to allocate some memory. This has been fixed. The client connect request will now receive a -86 "Client out of memory" error in these instances. SQL Anywhere Server - JDBC Client Library ===============(Release Build - Engineering Case #549431)=============== If a Windows based machine had both 32 and 64 bit client software installed, and an application subsequently attempted to use the iAnwhere JDBC driver, the driver may have thrown the exception UnsatisfiedLinkError indicating that it had attempted to load a dbjodbc11.dll of the wrong bitness. This problem has now been fixed. Note that switching the order in which the Bin32 and Bin64 directories appear in the path will work around this problem. ===============(Release Build - Engineering Case #549218)=============== If an application creates a scrollable statement and then scrolls through the result set, calling ResultSet.getRow() will return the correct row number for all rows. Calling ResultSet.getRow() will also return the correct row number when the end of the result set is reached. However, if the application called ResultSet.isLast() while positioned on the last row of the result set and then called ResultSet.getRow(), the row number returned would have been "invalid" or "unknown". This problem has now been fixed. Note that calling ResultSet.getRow() after calling ResultSet.isLast() while positioned on any row other than the last row would have returned the correct row number. ===============(Release Build - Engineering Case #548322)=============== If an application calls PreparedStatement.executeBatch(), the iAnywhere JDBC driver is supposed to return an integer array that contains a status for each row in the batch. The iAnywhere JDBC driver was instead returning an integer array containing only two elements. This problem has now been fixed. ===============(Release Build - Engineering Case #544626)=============== The iAnywhere JDBC driver may have crashed when allocating a new statement, and the Java VM was out of memory. This has been fixed. The driver will now either fail gracefully, or assert, depending on the circumstances. ===============(Release Build - Engineering Case #546290)=============== When connected to a DB2 Mainframe (D2M) database, the iAnywhere JDBC driver could have eld locks across COMMITs, causing increased contention and sometimes resulting in deadlock or timeout errors. This has been fixed. ===============(Release Build - Engineering Case #545772)=============== If an application was connected using the iAnywhere JDBC driver, and the application subsequently executed a statement that returned more than one result set, then attempting to fetch any result set after the first would have failed with a function sequence error. This problem would only have appeared once the fix for Egineering case 533936 was applied. This has now been fixed. ===============(Release Build - Engineering Case #533974)=============== When calling a Java stored procedure from the Interactive SQL utility with a SQL argument of type DATE, TIME or TIMESTAMP and a Java argument of type java.sql.Date or java.sql.Time, the server would have returned a parse exception from the JVM. Using dbisqlc to make the same Java stored procedure call would have worked fine. This problem has now been fixed. ===============(Release Build - Engineering Case #543541)=============== If an application was connected via the iAnywhere JDBC driver, and the application had made DatabaseMetaData calls, then calling Connection.close() would have given a NullPointerException if the server has already closed the connection. This problem has now been fixed. ===============(Release Build - Engineering Case #543397)=============== If an application was connected via jConnect and attempted to query the column metadata of a table containing a DATE or TIME column, then the server would have incorrectly returned the error -186 'Subquery cannot return more than one row'. When support for the TDS DATE and TIME datatypes was added, the metadata information in spt_jdatatype_info was not properly updated. This has now been fixed. ===============(Release Build - Engineering Case #542528)=============== An application using the iAnywhere JDBC driver may have in rare cases received a Null Pointer Exception when calling Connection.close(). This problem has now been fixed. ===============(Release Build - Engineering Case #541420)=============== In very rare circumstances, likely under heavy concurrency, the iAnywhere JDBC driver could have crashed. This has been fixed. ===============(Release Build - Engineering Case #536921)=============== Applications using the iAnywhere JDBC driver, could have crashed or hung if a process ran out of memory. This has been fixed so that it will now either fail gracefully, or cause an assertion with an appropriate error message, depending on the circumstances. ===============(Release Build - Engineering Case #538904)=============== If an application using the iAnywhere JDBC driver called the method ResultSet.isLast() when the result set was positioned on the last row, the call would have correctly returned a value of 'True', but the result set position would have been move to be after the last row. The problem has now been fixed. Note, this problem does not occur if the result set is not positioned on the last row. ===============(Release Build - Engineering Case #539289)=============== Applications using iAnywhere JDBC driver may have hung when calling the method ResultSet.get*(). This has been fixed. Note, this problem was introduced with the changes for Engineering case 533936. ===============(Release Build - Engineering Case #539094)=============== If an application was using the iAnywhere JDBC driver to generate one or more result sets by making DatabaseMetaData calls, then there was a chance the DatabaseMetaData result sets would not have been garbage collected until connection close time. Note that at most 3 of these result sets would have remained open until connection close. This problem has now been fixed. ===============(Release Build - Engineering Case #539077)=============== The changes for Engineering case 533936 introduced a problem where calling the JDBC method Statement.cancel() did not work for queries that did not return a result set. This has been fixed. ===============(Release Build - Engineering Case #537147)=============== If an application prepared a non-INSERT statement (i.e. a DELETE or an UPDATE statement) and used PreparedStatement.addBatch() followed by PreparedStatement.executeBatch() to execute a wide DELETE or wide UPDATE, then the results of executing the batch were unpredictable. Prepared batches were intended to be used for wide inserts only, but the iAnywhere JDBC driver did not restrict the usage to wide inserts. The driver now imposes this restriction and will throw an exception if an application attempts to use addBatch()/executeBatch() on a non-INSERT statement. ===============(Release Build - Engineering Case #538694)=============== An application that did not explicitly close Statement, PreparedStatement or CallableStatement objects may, in rare cases, have crashed when closing a Connection object. This problem has now been fixed. ===============(Release Build - Engineering Case #533936)=============== In rare situations, Java applications using the iAnywhere JDBC driver with concurrent connections may have hung, or even crashed. Several fixes have been made to correct race conditions between concurrent connections. ===============(Release Build - Engineering Case #537747)=============== If an application used the iAnywhere JDBC driver with either a Microsoft SQL Server, or DB2, ODBC driver, and the application did not explicitly close Statement or PreparedStatement objects, then it was possilbe that the application would have hung at garbage collection time. This problem has now been fixed. ===============(Release Build - Engineering Case #535849)=============== An application using the iAnywhere JDBC driver was not able to change the connection isolation level to one of the SA Snapshot Isolation levels. This problem has now been resolved. To use one of the SA Snapshot Isolation levels, the application can now call the Connection.setTransactionIsolation method with one of the following values: for applications using ianywhere.ml.jdbcodbc.IDriver, use: ianywhere.ml.jdbcodbc.IConnection.SA_TRANSACTION_SNAPSHOT ianywhere.ml.jdbcodbc.IConnection.SA_TRANSACTION_STATEMENT_SNAPSHOT ianywhere.ml.jdbcodbc.IConnection.SA_TRANSACTION_STATEMENT_READONLY_SNAPSHOT for applications using ianywhere.ml.jdbcodbc.jdbc3.IDriver, use: ianywhere.ml.jdbcodbc.jdbc3.IConnection.SA_TRANSACTION_SNAPSHOT ianywhere.ml.jdbcodbc.jdbc3.IConnection.SA_TRANSACTION_STATEMENT_SNAPSHOT ianywhere.ml.jdbcodbc.jdbc3.IConnection.SA_TRANSACTION_STATEMENT_READONLY_SNAPSHOT ===============(Release Build - Engineering Case #533604)=============== If a multi-threaded JDBC application generated a ResultSet object on one thread, at about the same time that the underlying Statement object was closed on another thread, then the application may in very rare cases have crashed, if that ResultSet object was subsequently closed. The same problem could have occurred if the ResultSet object was generated at about the same time that the underlying Connection object was closed. This problem has now been fixed. ===============(Release Build - Engineering Case #532802)=============== Closing a ResultSet object may have, in very rare cases, crashed the iAnywhere JDBC driver. This problem has now been fixed. ===============(Release Build - Engineering Case #531962)=============== If an application attempted to use a Statement, PreparedStatement or ResultSet object at the same time that the underlying Connection object was closed on a different thread, then there was a chance the application would have crashed.The problem has now been fixed. Note that finalizing Connection objects can cause the same crash. ===============(Release Build - Engineering Case #531718)=============== If an application using the iAnywhere JDBC driver attempted to perform a batched insert (using addBatch()/executeBatch()) and the batch size was large (greater than 500), then performance of the batch insert would have degraded significantly when long string columns were involved in the batch. The driver was allocating more memory than necessary, and making several small allocations instead of a few large ones. This problem has now been corrected. ===============(Release Build - Engineering Case #530596)=============== If a multi-threaded JDBC application attempted to make a connection on one thread while the Java VM was shutting down, there was a chance that the application would have crashed. Note that this problem was specific to Unix platforms only. The problem has now been fixed. ===============(Release Build - Engineering Case #500125)=============== When using the JDBC 3.0 version of the iAnywhere JDBC Driver and calling the method DatabaseMetaData.getColumns(), a result set with only 18 columns would have been returned, instead of 22 columns. Note that the extra 4 columns are in effect meaningless since they provide metadata for Ref types which are not supported in the iAnywhere JDBC driver. Nevertheless, the problem has now been fixed and the method now returns a result set with 22 columns. Using the JDBC 2.0 version of the iAnywhere JDBC Driver will continue to return a result set with 18 columns as expected. ===============(Release Build - Engineering Case #530594)=============== Closing a ResultSet object may, in very rare cases, crash the iAnywhere JDBC driver. This problem has now been fixed. SQL Anywhere Server - ODBC Client Library ===============(Release Build - Engineering Case #554106)=============== The ODBC driver would have issued an HY090 error if any of the connection string parameter to SQLConnect were specified as a combination of a NULL pointer and SQL_NTS. This situation is permitted by the ODBC specification. As a result, this restriction has now been removed. ===============(Release Build - Engineering Case #545565)=============== When an application called the ODBC fuction SQLTables() to get a list of supported table types, the TEXT table type would not have been listed. In addition, calling SQLTables() to list tables would have incorrectly listed tables of type TEXT as LOCAL TEMPORARY. Similarly, when an application using the iAnywhere JDBC driver called DatabaseMetaData.getTableTypes() to get a list of supported table types, the TEXT table type would not have been listed; and calling DatabaseMetaData.getTables() would have incorrectly identified TEXT tables as LOCAL TEMPORARY. Both the ODBC driver and JDBC driver have now been updated to properly list the TEXT table type and identify tables of type TEXT correctly. ===============(Release Build - Engineering Case #540927)=============== Attempting to execute a query that referenced a proxy table mapped to a table in an ADS database with a WHERE clause that contained a timestamp column, could have failed with a conversion error. When generating the remote query, the server was using the wrong format specification for converting the timestamp value to a string value. This problem has now been fixed. ===============(Release Build - Engineering Case #538292)=============== When Sybase Central was used to create a proxy table to a remote table in an ADS database, accessing the proxy table to perform queries or updates would have failed. This problem has now been fixed. It should be noted that in order to use proxy tables to an ADS table, the ADSODBC class must be used. Using the generic ODBC class will continue to cause access problems for ADS proxy tables. ===============(Release Build - Engineering Case #531532)=============== If a connection was dropped, or the server went down with a fatal error while connecting with ODBC, OLE DB or ADO.NET, or while calling the DBLib functions db_change_char_charset or db_change_nchar_charset, the client application could have crashed. This has been now been fixed. SQL Anywhere Server - OLEDB Client Library ===============(Release Build - Engineering Case #552739)=============== For an ADO/OLE DB application, if the CursorLocation was adUseClient and the size of the query was larger than 4K characters, then the SQL Anywhere OLE DB provider would have crashed. Also, if the client query contained single quotes (apostrophes), then the query metadata would not have been obtained. Both of these problems have now been fixed. ===============(Release Build - Engineering Case #543695)=============== Output parameters for stored procedure calls that were marked as indirect (DBTYPE_BYREF) were not handled properly by the SQL Anywhere OLE DB provider. This problem has been corrected. ===============(Release Build - Engineering Case #544214)=============== The changes for Engineering case 535861 caused the OLE DB schema support stored procedures to not be installed in newly created databases. This problem has now been corrected. As a work-around, databases can be upgraded using dbupgrad.exe or by executing an ALTER DATABASE UPGRADE PROCEDURE ON statement. ===============(Release Build - Engineering Case #540698)=============== Calling the OleDbDataReader GetString() method may have failed if the source string had a length of 0, or it may have returned a string that was missing the trailing null termination character when the source string length was greater than or equal to 1 (i.e., "abcde" comes back as "abcd"). This problem has been fixed. ===============(Release Build - Engineering Case #534792)=============== The OLE DB provider did not correctly support the DBCOLUMN_BASECOLUMNNAME rowset column of the IColumnsRowset::GetColumnsRowset method. This column should contain the name of the column in the data store, which might be different than the column name returned in the DBCOLUMN_NAME column if an alias or a view was used. Here is an example. CREATE TABLE GROUPO.MyTable( DATA2 varchar(16), DATA1 varchar(16), PKEY int NOT NULL default autoincrement, CONSTRAINT PKeyConstraint PRIMARY KEY (PKEY) ) ; CREATE VIEW DBA.MyView( PKEY, DATA_1, DATA2) AS SELECT PKEY, DATA1, DATA2 FROM MyTable; Consider the following queries. SELECT PKEY, DATA_1, DATA2 as D2 FROM MyView SELECT PKEY, DATA1 as DATA_1, DATA2 as D2 FROM MyTable In both cases, the OLE BD provider would return the following for DBCOLUMN_BASECOLUMNNAME and DBCOLUMN_BASETABLENAME for these queries. PKEY MyTable DATA_1 MyTable D2 MyTable Of course, the DATA_1 and D2 columns are not found in MyTable. With this fix, the provider now returns the correct column names. PKEY MyTable DATA1 MyTable DATA2 MyTable ===============(Release Build - Engineering Case #539056)=============== For a statement of the form "EXEC <linked_server_name>..dba.myproc", Microsoft SQL Server 2005 passes a statement of the form {?=call "dba"."myproc" } to the SQL Anywhere OLE DB provider. It passes in a single integer parameter for binding with a status of DB_E_UNAVAILABLE. The SQL Anywhere OLE DB provider had always checked the status of parameters and accepted one of DBSTATUS_S_DEFAULT, DBSTATUS_S_ISNULL, or DBSTATUS_S_OK. Any other status was flagged with an error. As such, the above example would have failed with an error. Since the parameter is OUTPUT-only, the status of the parameter can be ignored, as the status for any OUTPUT parameters will be set after the statement has been executed and any OUTPUT parameters will be filled in. The OLE DB provider behaviour has been changed to ignore the incoming status of OUTPUT-only parameters. This allows the EXEC statement to execute successfully. ===============(Release Build - Engineering Case #537804)=============== When the size of a long varchar or long binary column exceeded 32 KB on Windows, or 1 KB on Windows Mobile, the column may not have been read correctly by the OLE DB provider. This problem has been fixed. ===============(Release Build - Engineering Case #536620)=============== The OLE DB provider's ICommandWithParameters::SetParameterInfo() method may have caused an access violation, depending on the order of parameter indexes in rgParamOrdinals, which is one of the input parameters to the method. The problem may have also occurred if SetParameterInfo() was called after ICommandPrepare::Prepare(). This problem has now been fixed. ===============(Release Build - Engineering Case #530923)=============== Occasionaly, a DB_E_BADACCESSORHANDLE error would have been returned by the OLE DB IMultipleResults::GetResult method. This error could have occurred if the DBPARAMS structure that was passed to the ICommand::Execute method was disposed by the client before all the result rowsets from a stored procedure call were returned by calls to the GetResult method. On the final call to GetResult, output parameters may have become available. As a result, the DBPARAMS structure was required to be intact for each call to GetResult. This problem has been fixed. When Execute is called, if it is determined that there are no output parameters, then the DBPARAMS structure will be ignored on subsequent calls to GetResult. ===============(Release Build - Engineering Case #535861)=============== Updates to the OLE DB schema support procedures were not installed into the database using the Upgrade utility (dbupgrad) or when executing an ALTER DATABASE UPGRADE statement. They were installed though when the PROCEDURE ON clause was used with ALTER DATABASE UPGRADE. To ensure that dbupgrad will perform the OLE DB update, the ALTER DATABASE UPGRADE support procedures will now update and/or install the latest OLE DB schema support procedures. Since PROCEDURE ON is no longer required for the OLE DB update, you are no longer forced to update other system procedures. SQL Anywhere Server - Other ===============(Release Build - Engineering Case #547496)=============== A long-running HTTP connection to an OEM server would have resulted in an authentication violation. This was corrected by making all HTTP connections authenticated by default. ===============(Release Build - Engineering Case #549829)=============== When using the SQL Anywhere PHP driver, calling the sasql_num_rows() function always returned zero if the function sasql_query() was used with the SASQL_USE_RESULT option, or the function sasql_use_result() was called. According to the documentation, the function sasql_num_rows() is supposed to return an estimate with SASQL_USE_RESULT, and an exact value with SASQL_STORE_RESULT. This has now been fixed. The workaround is to use the SASQL_STORE_RESULT option or call the function sasql_store_result(). ===============(Release Build - Engineering Case #545912)=============== The original release of the Express Bug Fix for 11.0.0 1490 would have failed to install on non-English Windows systems. This has been fixed. ===============(Release Build - Engineering Case #547084)=============== A connection attempt that resulted in a warning was treated as an error and no connection was created. This was affecting the PHP, Python, and Ruby drivers. This has been fixed. Warnings no longer prevent a successful connection. The actual warning message can still be retrieved as usual. ===============(Release Build - Engineering Case #542482)=============== On Mac OS X systems, if the path specified in the "Database" field of the "New Server" dialog in DBLauncher contained spaces, the server would have failed to start the database. This has been fixed. ===============(Release Build - Engineering Case #542521)=============== On Unix systems, when an application crashed, rather that aborting or exiting, it may have gone intio a state of 100% CPU utilization. This would have occurred when the following conditions occurred in order: 1. The application loaded one of SQL Anywhere's client libraries (JDBC driver, ODBC driver, DBLIB), which automatically install a signal handler. 2. The application installs its own signal handler function 3. An application fault happens which causes the application's signal handler to call the SA signal handler. The SA signal handler will return without causingan abort and the application fault would have been re-triggered. The re-trigger of the signal and the return without handling the signal generated 100% CPU utilization. This has been fixed. ===============(Release Build - Engineering Case #542349)=============== Executing an SQL query batch using the Perl, PHP or Python drivers, that contained a SELECT statement in addition to other SQL queries that did not return a result set, could have returned the error: -180 'Cursor not open' error. This has now been fixed. For example: IF EXISTS( ... ) then DROP ... ENDIF; CREATE PROCEDURE ( ... ) BEGIN SELECT ... END; ===============(Release Build - Engineering Case #541591)=============== After installing the SQL Anywhere software on a non-1252 code page Windows operating system (such as Chinese, Japanese or Korean), the demonstration database (demo.db) has a 2K page size. On 1252 code page systems, the demonstration database has a 4K page size which is expected. Some examples in the documentation may not work on non-1252 systems as a result. In particular, if a database is started on a server that has a 2K page size, databases that have larger page sizes can not be started on the same server. To work around this issue, the demo.db database can be recreated using the dbinit, dbisql and the Scripts\mkdemo.sql script. Alternatively, the dbunload tool with the -ap option can be used to rebuild the database. ===============(Release Build - Engineering Case #541747)=============== The sample stoplists, the list of terms to ignore when building a text index, were corrupted for some languages. This has been fixed. ===============(Release Build - Engineering Case #541575)=============== When RSA encryption was in use by the server or client on Mac OS X systems, a crash was likely under very low memory conditions. This has been fixed. ===============(Release Build - Engineering Case #541576)=============== When RSA encryption was in use by the server or client on Mac OS X systems, memory could have been leaked. This has been corrected. ===============(Release Build - Engineering Case #541059)=============== The php driver source code was missing php_sqlany_ver.h on Unix platforms. This has been corrected. ===============(Release Build - Engineering Case #540690)=============== The "Check for Updates" entry on the Windows Start menu was missing. This has been fixed. ===============(Release Build - Engineering Case #540201)=============== On Mac OS X systems, an application may have taken a very long time to connect to a server if the server was found through an LDAP server and both the client and the server are IPv6-enabled. On Mac OS X, in order to establish a connection to a link-local IPv6 address, the scope (interface) ID must be specified. If a scope ID is not specified, it defaults to 0. A connection attempt where the scope ID is incorrect may take a long time to time out and fail. When a link-local IPv6 address was registered with LDAP, the scope ID was not included in the IP address that was registered. Doing so would not be useful, since scope IDs for the same link can vary from machine to machine. If an application obtained such a link-local address from LDAP and attempts to connect to it, in effect it will attempt a connection with a scope ID of 0. This has been fixed so that now an attempt to if the scope ID is 0 is refused on Mac OS X systems, including when the HOST connection parameter is used in the connection string with a link-local IPv6 address with no interface ID specified. Note that if the wrong non-zero interface ID is specified, a connection will still be attempted. ===============(Release Build - Engineering Case #540090)=============== After installing SQL Anywhere version 11.0.0 on a non-1252 code page system (such as Chinese, Japanese or Korean), the demonstration database (demo.db) does not contain image data in the Photo column of the Products table. The column values are NULL. This problem has been resolved. The mkdemo.sql script has been revised to use client-side reads (READ_CLIENT_FILE function) to populate the Photo column of the Products table. To correct existing demo.db databases: 1 start demo.db using dbeng11 or dbsrv11 2 change to the scripts directory of the install 3 run the following script: SET TEMPORARY OPTION allow_read_client_file = 'on'; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\TankTop.jpg' ) WHERE Products.ID=300; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\V-Neck.jpg' ) WHERE Products.ID=301; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\CrewNeck.jpg' ) WHERE Products.ID=302; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\CottonCap.jpg' ) WHERE Products.ID=400; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\WoolCap.jpg' ) WHERE Products.ID=401; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\ClothVisor.jpg' ) WHERE Products.ID=500; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\PlasticVisor.jpg' ) WHERE Products.ID=501; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\HoodedSweatshirt.jpg' ) WHERE Products.ID=600; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\ZippedSweatshirt.jpg' ) WHERE Products.ID=601; UPDATE Products SET Photo=READ_CLIENT_FILE( 'adata\CottonShorts.jpg' ) WHERE Products.ID=700; ===============(Release Build - Engineering Case #538317)=============== The Windows Mobile Deployment wizard was always writing to sqlany11.cab, rather than the filename specified by the user. This has been fixed. ===============(Release Build - Engineering Case #543955)=============== Some files for subfeatures would still have be included in the install created by the Deployment Wizard, even if their parent feature was unselected. This has been fixed. ===============(Release Build - Engineering Case #536568)=============== Using the SQL Anywhere Support utility (dbsupport) to check for updates on HP-UX and AIX would have failed to check for 32-bit client updates. This has been fixed. ===============(Release Build - Engineering Case #541783)=============== Calls to the sqlany_get_column() function in the C API library used by the data access modues for the various scripting languages (for example, PHP, PERL, Python, etc.) would have returned an incorrect value for the length field when fetching A_BINARY or A_STRING column information. This problem only affected 64-bit platforms. The length field is a size_t pointer and was being set to a 32-bit value, but on 64-bit platforms, size_t is a 64-bit value. This was fixed so that the length field points to the correct 64-bit or 32-bit value. ===============(Release Build - Engineering Case #531154)=============== The "Browse" button on the "DBConsole" pane of the "Options" window could have been enabled inappropriately , even when message logging was not turned on. This has been fixed. ===============(Release Build - Engineering Case #531126)=============== The "Connect" window was displayed on startup even if the "-c" command line option was given and the connection parameters were sufficient to connect. This has been corrected so that the "Connect" window is no longer displayed in this case. SQL Anywhere Server - Server ===============(Release Build - Engineering Case #559446)=============== If a server running on Linux systems with GTK libraries installed was auto-started, or started by the Start Server utility (dbspawn), in an X Window environment, an empty window titled "SQL Anywhere Developer Edition" would have remained visible until the server was shut down. This has been fixed. ===============(Release Build - Engineering Case #557808)=============== The changes for Engineering case 552171 introduced a problem where occasionally the use of the db_backup() function on a running database server could have returned a corrupt transaction log page. This would have caused the MobiLink client (dbmlsync) to fail the synchronization, or the Backup utility (dbbackup) to fail to recover the newly backed-up file. In both cases, this was a transient failure, and the sync/backup could simply have been restarted when the error was detected. This has now been fixed. ===============(Release Build - Engineering Case #557107)=============== When locking a table in exclusive mode (i.e. LOCK TABLE {tablename} IN EXCLUSIVE MODE), the server would first obtain a read lock on the table, increasing the likelihood of deadlocks occurring. This has now been fixed. ===============(Release Build - Engineering Case #557518)=============== An extremely busy server with multiple CPUs, maxed on processing queries, could have crashed in rare conditions. This has been fixed. ===============(Release Build - Engineering Case #548043)=============== Under heavy load, the server could have, in rare situations, generated a log that had an operation that would have been unreadable by the MobiLink client dbmlsync. Dbmlsync would have reported: "Log operation at <location> has bad data at offset <location>". This was likely only possible on multiprocessor systems, and has now been fixed. ===============(Release Build - Engineering Case #553901)=============== On rare occasions, a mirror server could have crashed, or failed an assertion on shutdown, particularly if the arbiter and primary were being shut down at the same time. On Linux, the problem could have also manifest itself as a hang in libc's __lll_mutex_lock_wait. This has been fixed. ===============(Release Build - Engineering Case #553693)=============== If a server had many external environment requests active, and several of these external environment requests were subsequently cancelled at the same time, there was a chance the server would have crashed. There was a very small window where a cancel request could have been ignored by the external connection. This has now been fixed. ===============(Release Build - Engineering Case #553520)=============== If a database server acting as mirror lost its connections to the arbiter and primary server, the database being mirrored did not restart and wait for the connections to be re-established. This has been fixed. ===============(Release Build - Engineering Case #552653)=============== Some situations, similar to those fixed for Engineering case 545904, allowed the server to hang while concurrently updating rows containing blobs. This has been fixed. ===============(Release Build - Engineering Case #552729)=============== Under rare circumstances, the server could have crashed, or failed an assertion, if it needed to grow a database file quickly by a large amount (e.g., as a result of inserting a very large blob). Furthermore, there was a possibility for corruption affecting the data that triggered the file growth. This has now been fixed. ===============(Release Build - Engineering Case #552620)=============== After the server had started a database that required recovery, it could have crashed when running a cleaner. This has now been fixed. ===============(Release Build - Engineering Case #552312)=============== The changes made for Engineering case 541615 introduced a problem where attempting to create a proxy table to a DB2 or Microsoft SQL Server table using Sybase Central could have failed with a strange conversion error, instead of creating the proxy table. This problem has now been corrected. ===============(Release Build - Engineering Case #552171)=============== When applying a series of renamed transaction logs to the server, or when the MobiLink client (dbmlsync) reads a series of renamed transaction logs, the error "Missing transaction log(s) after file ..." cound have been reported. The offsets reported in the error message (between the end of one log and the start of the next) can be subtracted to determine the size of gap; this apparent gap would have been exactly 24 bytes. With a 4K pagesize, this would have happened to roughly 1 out of every 4000 renamed logs; it is less likely with a larger pagesize. It was only a problem when the affected log was the last one before the online (currently active) log. This has been fixed. Note, despite the reported gap, no data was actually lost from the logs. The data can be recovered by using dbtran to generate a .SQL script and then applying this to the database. ===============(Release Build - Engineering Case #552304)=============== If the OS and database character sets were not the same, localized server window messages pertaining to checkpoints and events could have been mangled. This has been fixed. ===============(Release Build - Engineering Case #552189)=============== The changes for Engineering case 545904 introduced a problem where the server could have issued a variety of assertions, including "200610: Attempting to normalize a non-continued row" while concurrently updating rows containing blobs. For this to have occurred, the string values must have been less than a page size, but larger than the column's inline amount. This has been fixed. ===============(Release Build - Engineering Case #552077)=============== The server could have become deadlocked when frequently executing UPDATE ststements on the same set of rows. This would only have occurred if the table being updated had a non-unique index defined. This has now been fixed. ===============(Release Build - Engineering Case #551747)=============== Deadlocks could have occurred more often than expected at isolation level 3, if more than one transaction attempted to update the same row concurrently. This has been corrected. ===============(Release Build - Engineering Case #551259)=============== If a mirror server encountered a failed assertion, the primary server could have hung when the mirror server was stopped. This has been fixed. ===============(Release Build - Engineering Case #547738)=============== Starting with version 10.0.0, the server now uses a new mechanism to evaluate LIKE predicates that start with a prefix of non-wildcard characters. This mechanism is needed to provide correct results with the NCHAR collation. This new algorithm operates by computing sortkey hashes that specify a range of column values that could possibly match the LIKE predicate; the LIKE predicate is retained in some cases where it may further filter these returned rows. These sortkey hashes can be used as index range bounds to quickly filter the set of rows processed by the query. In the case that an index was not selected to process the LIKE predicate, the new implementation could have been more expensive, as it had the additional cost of computing the sortkey hash. The optimization has now been adjusted so that the sortkey hash bounds are used only if the LIKE predicate is used in an index scan. Otherwise, the like_prefix predicate is evaluated by comparing the column string to the pattern prefix character by character. This should give performance that meets or exceeds previous versions. ===============(Release Build - Engineering Case #552302)=============== If the HTTP listener was enabled, the server may have crashed on shutdown. There is no risk of data corruption. This has been fixed. ===============(Release Build - Engineering Case #551752)=============== Calling the system procedure sa_server_messages() could have resulted in the server crashing. This problem would have been rare, requiring a busy server to reproduce. This has been fixed. ===============(Release Build - Engineering Case #551749)=============== Connections that had executed a Java stored procedure would have taken three seconds longer than necessary when attempting to disconnect. Connections that were not used to make Java stored procedure calls are unaffected by this problem. The problem has now been fixed. Note that this problem was introduced in the changes made for Engineering case 548322. ===============(Release Build - Engineering Case #548941)=============== Statements with a CONTAINS clause, and statements over text index stored procedures (for example, sa_text_index_vocab), could have incorrectly returned no results. This problem affected only MANUAL and AUTO REFRESH text indexes, and only occurred when statements that useed a MANUAL or AUTO REFRESH text index had to be executed simultaneously with a REFRESH statement on the same text index. Alternatively, if the statement was prepared or cached by the server before a REFRESH on the text index occurred, an empty result set could also be returned when the prepared statement or cached plan was used after the REFRESH has completed. This has now been fixed. ===============(Release Build - Engineering Case #551690)=============== If a request was made that was larger than the packet size, then, in rare timing dependent cases, the connection could have hung until it was cancelled or dropped. Examples of requests larger than the packet size include executing a statement with long SQL text, or executing a statement with large host parameters. This has now been fixed. ===============(Release Build - Engineering Case #551686)=============== If a statement contained a work table, and evaluation of the expressions for the work table generated an error (for example, string trunctation or data overflow), then the server could have incorrectly returned an assertion failure error message (assertion 106502) instead of returning the appropriate error code. This assertion failure would have occurred only if expressions in the work table were not nullable. This problem has been fixed. ===============(Release Build - Engineering Case #551611)=============== If an application had uncommitted data in a local temporary table, and then called a Java, or any other, external environment procedure, there was a chance the server would have crashed if the application subsequently performed a rollback later on after the Java or external environment procedure had completed. This problem has now been fixed. Note that this problem will not show up if the local temporary table is declared with "on commit preserve rows" or "not transactional". ===============(Release Build - Engineering Case #551562)=============== If an execution plan contained an index-only retrieval scan and the scan had a predicate on a NUMERIC/DECIMAL or short string column, then it was possible for the scan to return the wrong result, omitting rows from the scan that should have been returned. This has been fixed. ===============(Release Build - Engineering Case #550236)=============== If a query execution plan included parallelism and specific expression types were used, it was possible for memory corruption or assertion failures to occur when the query was executed. The following expression types could have caused the problem: SORTKEY() COMPARE() CONVERT( <date, time, or timestamp>, <string expression> ) In order for the failure to occur, further specific characteristics needed to be present in the string parameters to the above functions. This problem has been fixed. ===============(Release Build - Engineering Case #547506)=============== The server could have become unresponsive when executing a query, if during an index scan very few rows satisfied the WHERE conditions. This has been fixed. ===============(Release Build - Engineering Case #551442)=============== The changes for Engineering case 547228 did not fully eliminate the assertions and other failures that could have occurred when committing deleted rows containing short strings. This has been corrected. ===============(Release Build - Engineering Case #551262)=============== If a cached plan for a MERGE statement was reused, the MERGE statement could have failed to perform the required updates. In particular, this problem could have affected immediate materialized view maintenance, if the view was updated multiple times by the same connection. This has been fixed. ===============(Release Build - Engineering Case #551261)=============== Index scans done with a snapshot isolation level could have returned incorrect results if there were concurrent UPDATE and DELETE statements to the underlying table. This has been fixed. ===============(Release Build - Engineering Case #550838)=============== The server was not utilizing 100% of all CPUs with a workload that should have been mostly CPU bound with interleaving I/O. This would likely have occurred on lightly loaded servers. This has been fixed. ===============(Release Build - Engineering Case #550839)=============== Dynamic cache size tuning was not enabled while databases were recovering at server startup. Prior to 9.0.0, dynamic cache size tuning was enabled during recovery. This has now been fixed. ===============(Release Build - Engineering Case #550669)=============== If a query plan contained a hash-based operator (group-by, distinct, or join) and the plan allowed at least one other operator to consume memory at the same time as the hash-based operator, then the execution plan could have been slower than it should have been. This slowness would also have resulted from high CPU usage. The slow behaviour did not occur if the hash-based operator appeared in a parallel execution plan, but only occurred in specific memory configurations. This slowdown has been fixed. ===============(Release Build - Engineering Case #550362)=============== In a database mirroring system, if the transaction log on the primary server was renamed via a backup, the mirror server could have reported various failed assertions, for example: 100902, 100903: Unable to find table definition for table referenced in transaction log 100904: Failed to redo a database operation For this problem to have occurred, other connections must have been making changes to the database at the time the log is renamed. The problem seemed to occur more frequently if many old log files were present on the primary server. The copy of the transaction log on the mirror server would have been corrupted as a result of this problem. When the log was renamed, there was a small window during which another connection could force a log page to be sent to the mirror before the mirror was notified that the log was renamed. The transaction log lock is now held across this window. ===============(Release Build - Engineering Case #550694)=============== A string ending with an incomplete multi-byte character may have had extra characters appended to its escaped representation as generated by an UNLOAD TABLE statement. This has been fixed. ===============(Release Build - Engineering Case #550693)=============== The server could have generated bad query execution plans due to incorrect index statistics. This has now ben corrected. ===============(Release Build - Engineering Case #550687)=============== In very rare circumstances, a server acting as a mirror in a High Availability setup may have spuriously hit assertion 100917 - "Unable to re-read a transaction log page" while shutting down. This has been fixed. ===============(Release Build - Engineering Case #550536)=============== If an application was using Java in the database and the Java VM run out of memory, then the Java VM would have remained alive even though Java in the database requests could no longer be made. The Java VM will now exit in this situation, and new Java in the database requests will now automatically restart a new Java VM. ===============(Release Build - Engineering Case #549847)=============== In rare cases, an execution plan using parallelism, and index-only retrieval with a string or numeric column, could have caused a crash or possibly returned a wrong answer. This has been fixed. ===============(Release Build - Engineering Case #550502)=============== There was a small possibility that canceling an HTTP request to a SQLAnywhere service, as the server was shutting down, may have caused the server to crash. This has been fixed. ===============(Release Build - Engineering Case #550416)=============== If an application executed a Java in the database stored procedure, and then subsequently canceled the request, in very rare cases the server may have crashed if the cancel request coincided with the Java request actually finishing. This problem has now been fixed. ===============(Release Build - Engineering Case #549999)=============== If an Open Client application supports retrieving result sets with a large number of columns, then attempting to perform a Kerberos login using such an application would have failed with a protocol error. This problem has now been fixed. ===============(Release Build - Engineering Case #549967)=============== A SELECT ... FOR XML ... over an NCHAR value could have caused a string right truncation error to be generated. For example: SELECT * from table FOR XML AUTO where table is defined with an NCHAR column, e.g.: create table (col1 LONG NVARCHAR); For the error to have occurred, the byte length of the NCHAR value must have been greater than 32767, and the "string_rtruncation" database option must have been set to "on" (which is the default). This has been fixed. ===============(Release Build - Engineering Case #549866)=============== The server could have crashed, or failed assertions, when under heavy load if pages were freed. The assertions were most likely to be about unexpected page types or contents. This has now been fixed. ===============(Release Build - Engineering Case #549606)=============== If an ALTER TABLE statement added a column with a user-defined type having a default value, subsequent ALTER's affecting the table could have caused a server crash. This has been fixed. ===============(Release Build - Engineering Case #549846)=============== In rare cases, monitoring of a heavily loaded server using the system procedure sa_performance_diagnostics, could have caused a server crash. This has been fixed. ===============(Release Build - Engineering Case #549644)=============== When running on Linux systems, a mini core could have been improperly generated under rare circumstances.This has been fixed. ===============(Release Build - Engineering Case #549628)=============== When starting a backup, if any dbspace files had not already been opened by the server (for example, the file was moved), the server could crash. This has been fixed. ===============(Release Build - Engineering Case #549622)=============== A server running on a Linux system, may have hung when under heavy I/O load, and a large number of concurrent request tasks (i.e. large -gn value). Specifically, if -gn was larger than 250, then there was a chance a hang may have occurred. This has been fixed. The workaround is reduce the -gn value. ===============(Release Build - Engineering Case #549453)=============== When manually unregistering the SQL Anywhere ODBC driver from the command line using "regsvr32 -u dbodbcXX.dll", the unregistration process may have failed and reported error code 0x8000ffff. Note that the failure occurred after the user successfully acknowledged the prompt to allow dbelevate (the "SQL Anywhere elevated operations agent") to run as an administrator. This problem has been fixed. As a work-around, run "regsvr32 -u dbodbcXX.dll" from a command shell which is already elevated. ===============(Release Build - Engineering Case #549424)=============== A server running a tracing database could have crashed. This has been fixed. ===============(Release Build - Engineering Case #549419)=============== If an Open Client application that supports retrieving result sets with a large number of columns attempts to perform an encrypted login, the login would have failed with a protocol error. This problem has now been fixed. ===============(Release Build - Engineering Case #549088)=============== Under rare circumstances, the server could have failed to report the warning "Row has been updated since last time read" (SQLCODE 104), when using a value-sensitive cursor and fetching a row that had been modified since it was last fetched. This has been fixed. ===============(Release Build - Engineering Case #548059)=============== A server started with a 32K page size, and a large cache size (or a very high -gn value), could have failed an assertion during or immediately following server startup. This has been fixed. ===============(Release Build - Engineering Case #549098)=============== If an application issued an external environment request, and the external environment process crashed for whatever reason at the same time, then there was a chance, although likely rare, that the server would have crashed as well. This problem has now been fixed. ===============(Release Build - Engineering Case #554782)=============== For particular forms of statements, it was possible for the server to incorrectly return the following error when trying to open a cursor: The optimizer was unable to construct a valid access plan [-727] ['WI010'] In order for the problem to have occurred, the statement must have referred to only a single table and used only columns satisfied by an index. Further, snapshot isolation must have been enabled. This has now been fixed. As a workaround, the statement hint "options(force optimization)" can be included to avoid the error. ===============(Release Build - Engineering Case #548833)=============== If a server was very busy, and several connections attempted to start external environments at the same time, and if several of the start external environment requests timed out, then, in very rare cases, the server could eventually have become unresponsive. This problem has now been fixed. ===============(Release Build - Engineering Case #547392)=============== Database corruption was possible if a database crashed while a lazy checkpoint was in progress. For corruption to occur, pages must have been allocated during the lazy checkpoint and one of the following must have occurred prior to the checkpoint: - dropping a table or index - truncating a table (that could have been truncated quickly, eg. no triggers) - deleting or replacing long blobs (greater than roughly page size) - [in general] an operation that resulted in pages being freed without the contents being modified This was more likely to have been an issue on heavily loaded servers. This problem has been fixed by temporarily allocating the pages at the start of the lazy checkpoint and then re-freeing them at the end. ===============(Release Build - Engineering Case #548710)=============== If recovery was attempted on a database that had grown since the last successful checkpoint had been executed, some pages may have become unavailable for reuse. This has now been fixed. ===============(Release Build - Engineering Case #548627)=============== Remote TCP connection attempts to servers running on Unix systems with IPv6 enabled, may have failed with the error "Connection error: An error occurred during the TCPIP connection attempt." This was only likely to happen on machines that were ONLY using IPv6. This has been fixed. As a workaround, the IPv6 address of the server machine can be specified using the HOST parameter. ===============(Release Build - Engineering Case #548626)=============== If a table had a trigger defined that made an external environment call and many connections attempted to access the table at the same time, forcing table locks and simultaneous external environment calls, then there was a chance the server would have hung. This problem has now been fixed. ===============(Release Build - Engineering Case #548470)=============== If a mirror server had shut down and then very quickly restarted as a preferred server, synchronization may have been delayed by thirty seconds. This has been fixed. ===============(Release Build - Engineering Case #548437)=============== Under rare circumstances, a loss of quorum could have resulted in the database file and the transaction log on the primary becoming out of sync. Subsequent attempts to start the database would have failed with the error "Unable to start specified database: Cannot use log file '<name>' since it is shorter than expected". This has been fixed. Note, the likelihood of this problem appearing with 11.0.0 servers was even smaller than with 10.0.1 servers. ===============(Release Build - Engineering Case #548323)=============== If many connections were making external environment (or Java) calls at the same time, and the number of worker threads had not been increased by an appropriate amount, then there was a possibility that the server would either have hung or crashed. A thread deadlock error will now be returned instead. ===============(Release Build - Engineering Case #548160)=============== In certain specific circumstances, some expressions in triggers could have caused the server to crash when executing the trigger. This has been fixed. ===============(Release Build - Engineering Case #547541)=============== Using a server that is in In-memory mode to start a database requiring recovery would have caused the server to fail assertion 201842, "Checkpoint log: failed to write info page". The server running in In-memory mode was unable to use the transaction and/or checkpoint logs for recovery. This has been changed so that the server running in In-memory Never-write mode (-im nw) will now read both logs during recovery only. When in In-memory Checkpoint-only mode (-im c), the server will read the transaction log during recovery only. This is useful for example, to validate a backup copy of a database that requires recovery, without making changes to the backed up copy. ===============(Release Build - Engineering Case #546882)=============== The GrowLog system event that fires when the database transaction log grows can be setup to truncate the transaction log upon its exceeding a certain size. In cases where the database server was very busy, the transaction log would not have been truncated often enough. This may have lead to the transaction log getting significantly larger than the threshold set in the event. This has been fixed, although in a very busy server it is still possible for the log to grow larger than the threshold for short periods of time. ===============(Release Build - Engineering Case #545570)=============== The server could have crashed while inserting rows to a table when also creating statistics on the table. This has been fixed. ===============(Release Build - Engineering Case #548007)=============== A query that executed using intra-query parallelism did not respect the Priority connection option and would have executed at the 'normal' priority level. This has been fixed. ===============(Release Build - Engineering Case #532314)=============== If creating a tracing database resulted in an error, the real cause of the error would have been missing from the error dialog details. This has been fixed. ===============(Release Build - Engineering Case #547708)=============== Attempting to create a database with an apostrophe in a filename or the dba user's password, could have failed with a syntax error. Also, attempting to create a database with a dbkey containing a backslash may have resulted in a database which could not be connected to. These problems have now been fixed. ===============(Release Build - Engineering Case #547513)=============== When running the server on Unix systems and using the -m command line option ("truncate transaction log after checkpoint"), the transaction log was not being truncated on checkpoints. This has been fixed. ===============(Release Build - Engineering Case #547415)=============== If all terms in a CONTAINS query were dropped, due to STOPLIST, MINIMUM and MAXIMUM TERM LENGTH settings of the text index, unnecessary searches in the text index could still have been performed. This has been fixed. ===============(Release Build - Engineering Case #547205)=============== Renaming a column in a table having referential action triggers, could have resulted in a server crash. This has been fixed. ===============(Release Build - Engineering Case #546587)=============== If the option Chained was set to off (i.e. auto-commit enabled), executing an INSERT, UPDATE or DELETE statement inside a BEGIN ATOMIC block would have resulted in error -267 "COMMIT/ROLLBACK not allowed within atomic operation". This has been fixed. The DML statement will now be allowed to execute and a commit (or rollback if an error occurs)will be performed automatically at the end of the atomic block. ===============(Release Build - Engineering Case #547228)=============== n very rare circumstances, the server could have failed a fatal assertion when commiting deleted rows containing short strings (less than a database page in length). The typical assertion seen in this instance was assertion 201501 - "Page for requested record not a table page or record not present on page". This has been fixed. ===============(Release Build - Engineering Case #546478)=============== Referential integrity constraint checking could have failed, allowing a primary key to be removed when it still had referencing foreign keys, or preventing the removal of a primary key with no referencing foreign keys. The likelihood of this happening decreased as the number of foreign tables increased. This has now been fixed. ===============(Release Build - Engineering Case #547248)=============== If the server had shut down due to a start-up error involving a database that participated in mirroring, the shutdown reason would not have been recorded correctly. On Unix systems, it would have been recorded as being a result of a SIGHUP signal. On Windows systems, it would have been recorded as being a result of a request from the console. This has been fixed so that it is now correctly recorded as being a result of a start-up error. ===============(Release Build - Engineering Case #547078)=============== An ODBC or OLEDB application may have been positioned to an incorrect row when fetching by bookmark value. This would only have happened if the last column of the result set was not bound (for example with SQLBindCol). This has now been fixed. ===============(Release Build - Engineering Case #542016)=============== When rebuilding a pre-10.0 database using the Unload utility (dbunload) with the -an or -ar command line options, dbunload could have hung under very rare conditions on certain Windows systems. This problem has only ever been observed on a few machines configured as Domain Name Servers (DNS), but the hang could have occurred under other conditions as well. This has been fixed. ===============(Release Build - Engineering Case #547076)=============== Executing a "MESSAGE ... TO CLIENT FOR CONNECTION n" statement could have resulted in a message with mangled characters in the message text. For this to have occurred, the source connection and destination connection must have been connected to databases with different collation sequences. This has been fixed. ===============(Release Build - Engineering Case #547036)=============== The PacketsSent and PacketsReceived properties were being updated by HTTP and HTTPS connections, even though the HTTP protocol has no real concept of packets. This has been fixed by no longer updating these properties for HTTP and HTTPS connections. The BytesSent and BytesReceived properties will continue to be updated for HTTP and HTTPS connections. ===============(Release Build - Engineering Case #546432)=============== The server may have hung while performing updates to rows containing blobs. This has been fixed. ===============(Release Build - Engineering Case #545901)=============== If an application called an external environment procedure immediately after issuing a commit, and the external environment procedure performed server side calls and issues its own commit, then there was a chance the server will have failed assertion 201501 "Page for requested record not a table page or record not present on page". This problem has now been fixed. ===============(Release Build - Engineering Case #542356)=============== A query with a GROUP BY clause that referenced the same alias at least twice, would have incorrectly returned a syntax error. For example: SELECT item = 'abc' FROM product p LEFT OUTER JOIN sales_order_items GROUP BY item, item This has been now been corrected. ===============(Release Build - Engineering Case #546854)=============== If a query contained DISTINCT, ORDER BY and GROUP BY clauses and an expression in the ORDER BY clause appeared in the the GROUP BY clause, but not in the SELECT list, then the wrong error was returned, namely "Function or column reference to ... must also appear in a GROUP BY." This has been fixed so that the correct error message: "Function or column reference to .. in the ORDER BY clause is invalid." For example, the query: SELECT DISTINCT X FROM T GROUP BY E ORDER BY E Would have returned the error: "Could not execute statement. Function or column reference to 'E' must also appear in a GROUP BY." SQLCODE=-149, ODBC 3 State="42000" ===============(Release Build - Engineering Case #545933)=============== Attempting to backup a database of size 5GB or larger with the clause "WAIT BEFORE START" could have caused the server to hang. Backups of databases this size and larger cause the server to calibrate the dbspaces, which is done to improve the parallel performance of the backup. However, if the calibration updated the catalog, then the WAIT BEFORE START clause would have caused the backup to wait on itself. This has been fixed by turning off calibration for large databases when the WAIT BEFORE START clause is specified. If desired, the CALIBRATE DATABASE statement can be issued before the backup begins. A workaround is to run the backup without the WAIT BEFORE START clause. ===============(Release Build - Engineering Case #544948)=============== The system function xp_sendmail() would have always encoded the subject line of an email being sent. While this is properly decoded when the email is delivered to an email client, it was not decoded in many instances when sent via SMS. A change has been made to not encode the subject line when the subject contains only 7-bit ascii characters. Attempting to send a message containing non 7-bit ascii characters to a SMS client will still result in the subject line being encoded. It will be up the carrier to properly convert from SMTP to SMS. ===============(Release Build - Engineering Case #546294)=============== The server could have failed assertion 104301 - "Attempt to free a user descriptor with non-zero reference count", while trying to drop a user. This assertion was likely to occur when an attempt was made to ALTER the same user in the same server session, and the ALTER had failed due to an error. This has been corrected. ===============(Release Build - Engineering Case #546074)=============== A database that was initialized with a version 10 server could have become corrupted when run with a version 11 server. The problem could have resulted in the database not starting, failing assertions, or other errors. This has now been fixed. Note that rebuilding a database to a version 11 format will provide performance improvements, while also preventing this problem. ===============(Release Build - Engineering Case #545899)=============== For particular structures of tables and indexes, it was possible for an ALTER TABLE statement to fail with an assertion failure such as the following: Assertion failed: 201501 - Page for requested record not a table page or record not present on page This has been fixed. ===============(Release Build - Engineering Case #545950)=============== The STOPLIST setting specifies the terms to ignore when building a text index. The sample stoplists for English contained words with apostrophes as well as words. An apostrophe is treated as a whitespace for the purposes of stoplist construction, causing such words to be treated as phrases (e.g. you'll is treated as "you ll"). Such words have now been removed from the sample. ===============(Release Build - Engineering Case #545934)=============== A database could have failed validation before a checkpoint, and then passed validation after a checkpoint. A possible message that may have been generated in this case was "Database validation failed for page nnnnnn of database file '<file.db>'". In cases such as this, the database was in fact valid, but the validation step was falsely reporting failure. This has been fixed, although there is still a small possibility that when run on an active database, the validation step could still report errors. It is recommended that, where possible, validation occur when there is little or no database activity. A workaround is to issue a checkpoint before running validation. ===============(Release Build - Engineering Case #545824)=============== When doing dynamic cache size tuning, the server could have choosen a cache size which was larger than appropriate. This could have caused performance degradation if other system components were competing for memory. The server was erroneously basing target cache size computations on the server's "peak" working set size, rather than its "current" working set size. This has been corrected. ===============(Release Build - Engineering Case #545815)=============== The database server could have leaked memory, and eventually failed with an 'Out of Memory' error, when using TDS connections (eg. jConnect) that fetched string data. This has now been fixed. This fix is in addition to the memory leak that was fixed for Engineering case 543069. ===============(Release Build - Engineering Case #544047)=============== Validation of a database may have reported that some tables contained orphaned blobs. This was only true for tables that were stored in a dbspace other than the SYSTEM dbspace. This should also have only occurred on databases using snapshot isolation. Databases containing these orphaned blobs have pages which are being wasted. The only way to free these pages for reuse is to rebuild the database file. This problem has been fix so that generating orphaned blobs should no longer be possible. ===============(Release Build - Engineering Case #545744)=============== The server may found, and used, the wrong license file when starting up. This has been corrected. Note: if the server now reports a "License file not found" error after applying this fix, when it started prior to the fix, then the license file was not correctly installed. To correct this, the license file should be moved so that it is in the same directory as the server executable. ===============(Release Build - Engineering Case #545713)=============== On Mac OS X systems, the function sqlany_initialize_interface() in sqlanydll.c would have failed if it attempted to use the default library name (that is, if the second argument to the function was NULL and the environment variable SQLANY_API_DLL was not set). This was due to the default library name having the wrong extension ('so' as opposed to 'dylib'). This has been fixed. As a workaround, the correct library name can be specified in the second argument to sqlany_initialize_interface, the environment variable SQLANY_API_DLL can be set to the correct library name, or the extension can be manually changed in the DEFAULT_LIBRARY_NAME macro in sacapidll.c. ===============(Release Build - Engineering Case #545707)=============== When running on Unix systems, the server could have hung and not proceeded any further while generating a mini-core. This has been fixed. ===============(Release Build - Engineering Case #545704)=============== When trying to create a Transact-SQL function or procedure, use of the "expr AS name" syntax in the arguments to a function call would have given an error. This has been fixed. A workaround is to write the function or procedure using the Watcom-SQL dialect. ===============(Release Build - Engineering Case #545574)=============== In certain circumstances, TLS connections that should have failed, would have actually succeed. This has been fixed. Note that this problem does not occur on Mac OS X systems. ===============(Release Build - Engineering Case #545383)=============== Queries accessing a table via an index could have performed poorly after performing many update and delete operations on the indexed table. If two leaf pages that required cleaning were merged, the second of the two would not have been cleaned, which could have resulted in many almost empty leaf pages. This has been fixed. ===============(Release Build - Engineering Case #545611)=============== In some rare cases, errors during execution of a DROP TABLE or DROP MATERIALIZED VIEW statement, could have resulted in locks being held for too long. This has been fixed. ===============(Release Build - Engineering Case #543069)=============== The server could have leaked memory, possibly leading to an 'Out of Memory' error, when using TDS connections (eg. jConnect) that fetched string data. This has now been corrected. ===============(Release Build - Engineering Case #545468)=============== Calling either of the system procedures sa_http_php_page() or sa_http_php_page_interpreted() would have resulted in a leading and a trailing space in the output. This has been corrected. ===============(Release Build - Engineering Case #545455)=============== A server started with the -zl or -zp command line options (or by calling the system procedure sa_server_option() with RememberLastStatement or RememberLastPlan), that services large numbers of HTTP connections could have crashed. This issue would have been rare and highly timing dependent. This has now been fixed. ===============(Release Build - Engineering Case #544972)=============== The server could have crashed while optimizing a text query containing a phrase. This has been fixed. ===============(Release Build - Engineering Case #544187)=============== A server could have failed to start if another server was starting at the same time. The server that failed to start would have displayed the error "Database cannot be started -- No such file or directory". The error message was also misleading since the database file did exist; the server actually had a problem opening the database's temporary file. This has been fixed. ===============(Release Build - Engineering Case #545374)=============== When using the SQL Anywhere ODBC driver, if SQLBindCol was called immediately after a SQLFetch and before calling SQLBulkOperations( SQL_UPDATE_BY_BOOKMARK ), then the SQLBulkOperations update would have failed. This problem has been fixed. ===============(Release Build - Engineering Case #545519)=============== The changes for Engineering case 541942 could have cause GLOBAL TEMPORARY tables to be created in the SYSTEM dbspace during database creation. Only databases created by a server with this problem are affected, and can be corrected by rebuilding with a fixed server. This problem has two visible results: Firstly, diagnostic tracing into a local database will cause the database to grow twice as large as expected due to diagnostic data. It will be necessary to rebuild a database this problem in order to prevent this growth from happening with subsequent builds. Secondly, JDBC metadata that is supposed to be unique to each connection will end up being visible to all connections. This can cause a variety of problems for applications that depend on querying this metadata. This manifestation of the problem can be avoided by running dbupgrad with a fixed server against a database with this problem. The presence of this problem in a database can be verified by querying SYSTABLE and noting that all jdbc_* tables have type of BASE. ===============(Release Build - Engineering Case #544669)=============== If a column histogram incorrectly contained a selectivity estimate of 100% for the NULL values, the best plan found by the optimizer could have been very inefficient. This problem affected the computation of the selectivity estimation of predicates of the form "T.X theta expression" (theta can be =, <>, >, >=, < or <=) which would have incorrectly been computed as 0%. A change has been made to the optimizer so that it no longer trusts a NULL selectivity estimation of 100%, instead it uses the computed selectivity estimation of (100% - epsilon). To test the estimated selectivity of the NULL values for a column T.X use: "select first estimate(X, null) from T". A workaround is to recreate statistics on the column T.X by using: "create statistics T (X)". However, if the column T.X has often only NULL values, and then it is updated to some non-null values, it is recommended to upgrade to a server containing this fix. ===============(Release Build - Engineering Case #544787)=============== If a statement required rows to be sorted and at least two rows had long ORDER BY key values that were equal in the first 256 bytes and the statement was executed with a parallel access plan, it was possible for the two rows to be returned in an order that did not match the ORDER BY clause. This problem has been fixed. Note, it was possible for text indexes that contain long search terms to be affected by this problem when the text index was built or updated. If this occured, the index should be rebuilt with a server containing this fix. ===============(Release Build - Engineering Case #539106)=============== In some cases where expressions were evaluated in stored procedures or batches outside of SELECT, INSERT, UPDATE or DELETE statements, it was possible for the expressions to be evaluated incorrectly. The incorrect behaviour would have appeared if arithmetic expressions were used with one argument a DATE, TIME, or TIMESTAMP, or both arguments were strings. In these cases, the incorrect domain could have been used for the arithmetic expression if it were used in an IF, CASE, IN, or concatenation operation. For example, the following select improperly returned '0002', the correct answer should be a numeric with value 2. create variable @v_res long varchar; set @v_res = if 1=1 then '0002' else '1' - '2' endif; select @v_res This problem could have also resulted in conversion errors being returned in cases where they should not, or missed in cases where they should have been generated. This problem has now been fixed. ===============(Release Build - Engineering Case #544961)=============== The Stored Procedure Debugger was not able to set breakpoints on statements within exception handlers. This has been fixed. ===============(Release Build - Engineering Case #544944)=============== When calling sp_remote_tables() to get the column information for an UltraLite table, any unsigned columns would have been described as signed columns. This problem has been fixed. ===============(Release Build - Engineering Case #544925)=============== A connection may have continued to hold table or row locks even when a DDL statement failed. This has been fixed. ===============(Release Build - Engineering Case #544199)=============== In rare situations, the server could have crashed during graphical plan construction. For the problem to occur, one of the tables used in the query had to have a unique index and a foreign key index sharing the same columns and settings, and the index had to be considered or used for the query. This has been fixed. ===============(Release Build - Engineering Case #544791)=============== In rare timing dependent cases, the server could have hung on shutdown, or possibly failed in other ways, after executing a DROP CONNECTION statement. This has now been fixed. ===============(Release Build - Engineering Case #544779)=============== Any web service in the SYSWEBSERVICE table with data in the PARAMETER column would have been disabled when the database was unloaded into a new database. This has been fixed. Note, any SOAP services that defined a DATATYPE, GROUP or FORMAT clause, or any web service that defined a METHODS clause, were affected. ===============(Release Build - Engineering Case #544672)=============== Some fulltext queries took inordinate amounts of memory when opening the statement. These queries typically also took too long to open. These problems predominantly affected queries with long phrases or queries over NGRAM indexes with long search terms. The memory usage and open times have been improved. ===============(Release Build - Engineering Case #543694)=============== When using Snapshot isolation, WITH HOLD cursors would have failed to see rows modified by their own connection after the connection executed a COMMIT. This has been fixed so that when using Snapshot, Statement-Snapshot or Readonly-Statement-Snapshot isolation, WITH HOLD cursors will see a snapshot of all rows committed at the snapshot start time, as well as all modifications done by the current connection since the start of the transaction within which the cursor was open. Note that the contents of the cursors are unaffected by the current transaction committing. ===============(Release Build - Engineering Case #543656)=============== A database that had gone through recovery after an abnormal shutdown could have been unreadable by the MobiLink Client dbmlsync. Dbmlsync would have reported that the transaction log was corrupt, even though the server successfully recovered. At the end of recovery, the server performs a checkpoint. This checkpoint was correctly updated in the database and written to the transaction log, but was not being flushed to the log properly. This has now been fixed. The original crashed database will need to be recovered with the fixed server. ===============(Release Build - Engineering Case #544670)=============== In some cases, statements containing complex expressions could have used an excessive amount of memory that could affect other connections in the server. This has been fixed so that attempts to execute large expressions that can not be handled will now generate the error: -890 "Statement size or complexity exceeds server limits" ===============(Release Build - Engineering Case #544651)=============== Under rare circumstances, a full text search could have returned incorrect results. For this problem to occur, the database with the text index had to have been refreshed at least once and then moved between platforms with different byte orderings. This has now been fixed. No action needs to be taken for databases with text indexes that were created on little-endian machines and were never refreshed or updated on big-endian machines. Text indexes will need to be truncated and refreshed (for MANUAL and AUTO text indexes), or recreated (for IMMEDIATE indexes), after applying this fix if they were created or refreshed on a big-endian machine. ===============(Release Build - Engineering Case #543940)=============== The server could have stop responding and continue to consume CPU when processing the SUBSTR() function. For this to have occurred, the SUBSTR() must appear on the right hand side of a string concatenation operation and must also be over a string that comes from a row in a table. Additionally, the string data must be greater than one database page in length. Even if all these conditions are met, it is very unlikely that this bug will be hit, as it depends on other internal server conditions as well. This has now been fixed. ===============(Release Build - Engineering Case #544486)=============== If an application connected using Open Client attempted to fetch a result set containing a large number of columns (more than 3000), then the application would have failed with a TDS protocol error. This problem has now been fixed. Note, that in order to fetch such a result set, the application must be using Open Client 15. ===============(Release Build - Engineering Case #543910)=============== The version 10 and 11 servers were truncating 32-byte names to 31 bytes. So when a version 10 or 11 client attempted a shared memory connection specifying a 32-byte server name that had a common prefix of exactly 31 bytes with a running version 10 or 11 server that also has a 31-byte name, the connection attempt would have failed. As well, if a version 10 or 11 client attempted a shared memory connection specifying a server name that had a common prefix of exactly 31 bytes with a running version 9 or prior server that had a name longer than 31 bytes, the connection attempt would have failed. This problem has been fixed. Note that for version 10 and 11, the fix affects both client and server. For version 9, the fix is just to the server. However, an unmodified version 10 or 11 client will be able to establish such a connection against an unmodified version 9 server. ===============(Release Build - Engineering Case #543812)=============== If a user caused an event to fire, e.g. by disconnecting to fire a Disconnect event, and another user immediately caused that user to be dropped, the server would have crashed. This has been fixed. ===============(Release Build - Engineering Case #542186)=============== Under rare circumstances, diagnostic tracing could have failed to record some cursor information for statements within procedures, for example, information about cursor close time and the graphical plan. This has been fixed. ===============(Release Build - Engineering Case #544213)=============== Comments on the following object types were not preserved by dbunload: dbspaces Java classes Java jars external environments external environment objects login policies This has been fixed. ===============(Release Build - Engineering Case #544181)=============== Calling the system function traced_plan() for a query containing captured host variables could have failed and return a conversion error. When using Profiling Mode in the Sybase Central plugin, this caused the profiling browser to fail to display a "Best Guessed Plan" for a query whose original graphical plan was not captured. This has been fixed. ===============(Release Build - Engineering Case #544030)=============== Triggers defined on global temporary tables were not fired. This has been fixed. ===============(Release Build - Engineering Case #543210)=============== Queries with a large number of aggregate expressions in the select list, but without a GROUP BY clause, could have crashed the server. This has been fixed. A workaround for this problem is to add a GROUP BY clause. ===============(Release Build - Engineering Case #544094)=============== When creating a procedure or function, if an existing procedure or function was altered and a language clause was specified with an undefined language, then the server would have failed to return an error. This problem has now been fixed and the server now correctly returns an error. ===============(Release Build - Engineering Case #537172)=============== In some cases, an execution plan using a parallel execution strategy could have used a low-memory fallback strategy, even though there was sufficient memory for it to complete. The QueryLowMemoryStrategy property would have increased if the low memory strategy for the operator was used. This problem has been fixed. ===============(Release Build - Engineering Case #543835)=============== The functions YEARS(), MONTHS(), WEEKS(), DAYS(), HOURS(), MINUTES(), and SECONDS() could have been described with the incorrect data type. If these functions were used with two parameters with the second parameter an untyped expression, then the expression was assigned the incorrect data type. Untyped expressions include NULL constant literals and host variable that are not yet bound to a type, for example during DESCRIBE. For example, the following expression was incorrectly described as TIMESTAMP (it should be INT): select months( current timestamp, NULL ) This incorrect type could have affected more complex expressions composed with one of the affected functions as an argument. This problem has been fixed. Note, this change could alter the definition of materialized views; views containing the affected constructs should be refreshed. ===============(Release Build - Engineering Case #543261)=============== The server could have hang while concurrently updating blob columns. This has been fixed. ===============(Release Build - Engineering Case #543826)=============== If an application called sp_remote_columns to determine the domain ids of an UltraLite table, and the UltraLite table contained a UniqueIdentifier column, then the domain id of the uniqueidentifer column would have been incorrectly returned as Char. This problem has now been fixed. ===============(Release Build - Engineering Case #543562)=============== If an application was connected using jConnect and attempted to fetch a result set containing a large number of columns (more than 3000), then the application would have failed with a TDS protocol error. This problem has now been fixed. Note, that in order to fetch such a result set, the application must be using jConnect 6.x. ===============(Release Build - Engineering Case #544496)=============== If the server was started with the "-x none" command line option, and without the -xs option, then calling an external web procedure would have caused the server to crash. This has been fixed. ===============(Release Build - Engineering Case #543652)=============== The stored procedure debugger would not allow breakpoints to be set within triggers. This has been fixed. ===============(Release Build - Engineering Case #543518)=============== The SQL Anywhere http option "AcceptCharset" generated a SQL error with "SQLCODE -939 Invalid setting for HTTP option" when a match was not found within the union of the client's Accept-Charset list and the server's AcceptCharset http option charset list. This has been fixed. With this change a SQL error is now generated only if the http option value is malformed or none of the charsets within the value are supported by SQL Anywhere. In addition, the run-time selection of a suitable response charset has changed to provide more control over the charset selection. Primarily, given that the union of server and client charset lists are empty, a charset is now selected based on the server's AcceptCharset http option value not from the client's Accept-Charset request header. The old behaviour is supported by allowing an asterisk (*) to be specified within the AcceptCharset http option list. An asterisk has the meaning that, should the client/server charset union be empty, try to use the preferred charset specified by the client. If none are found, then select from the server's AcceptCharset http option list. A summary of the processing priority of the various cases follow: Processing Priority cases: 1 - If a charset can be selected from the union of charsets from the AcceptCharset http option and the Accept-Charset HTTP request header, then it will be used (no change in behaviour). 2 - If the client sends an Accept-Charset HTTP request header, but none of the charsets match the AcceptCharset http option, then use the first and/or highest q-value charset specified within the AcceptCharset http option. (This is a behaviour change). 3 - If the client does not send an Accept-Charset HTTP request header, select the first and/or highest q-value charset specified within the AcceptCharset http option (no change in behaviour). Caveats: a. Within the AcceptCharset http option value, the placement of the '+' token (which specifies the use of database charset whenever possible regardless of the q-value assigned to it by the client) is now significant. If '+' is specified anywhere within the http option value then case 1) will be true if the client happens to specify the database charset. If '+' is specified first and/or it has the highest q-value, then cases 2) and 3) above would resolve to using the database charset. b. Within the AcceptCharset http option value, an asterisk (*) signifies that any client charset (as specified by its Accept-Charset HTTP header) should be considered prior to defaulting to the http option charset list. The best match within the union of client/server charsets ( case 1) ) has priority. In the processing priority cases above, having failed case 1) the client's Accept-Charset is scanned for a suitable charset. If a suitable charset is not found, then a charset is selected according to case 3). c. SQLCODE -939 error is only generated if the http option value is malformed or none of the specified charsets within its value is supported by SQL Anywhere. The database charset is selected whenever a SQLCODE -939 error is generated. ===============(Release Build - Engineering Case #543394)=============== An INSERT, UPDATE or DELETE statement executed on a table with an IMMEDIATE text index could have caused correctness issues for subsequent CONTAINS queries that used the text index. For the problem to have occurred, very long string values (over 32K characters) had to have been indexed by the text index and modified by the INSERT, UPDATE or DELETE statement. This has been fixed. For existing databases with IMMEDIATE text indexes that could be affected by this issue, dropping and recreating the text index is recommended. ===============(Release Build - Engineering Case #542962)=============== On a busy server, if an application made an external environment or Java call which could have resulted in a thread deadlock error, there was a small possibility that the server would have hung. This problem has now been fixed. ===============(Release Build - Engineering Case #543245)=============== In certain configurations, executing the REMOTE RESET statement can cause the server to crash. This has been fixed. ===============(Release Build - Engineering Case #530736)=============== The changes for Engineering case 491180 (enable write through on CE) introduced a dependency on the file note_prj.dll, which may not have been included on non-standard Windows CE devices. On these devices, the server may have failed to start with an error that it could not find the server or one of its components. The Standard Windows Mobile devices were not affected. This has been corrected and note_prj.dll is now loaded dynamically, and if it is not found, the server will not enable write through on pre CE 5 devices. ===============(Release Build - Engineering Case #543127)=============== After executing the Unload utility (dbunload) with the -d option (data only), the resulting reload.sql file would have contained calls to the non-existent function sa_unload_display_table_status(). The same problem would have occurred when using the Sybase Central Unload wizard and chosing "Unload data only". This has been fixed. ===============(Release Build - Engineering Case #542868)=============== In rare circumstances the server could have hung updating a blob column. This has been fixed. ===============(Release Build - Engineering Case #542840)=============== If a Disconnect event was defined and a connection was dropped using DROP CONNECTION, the value of event_parameter('DisconnectReason') would have been incorrect when evaluated inside the event handler. This has been fixed. ===============(Release Build - Engineering Case #541857)=============== Transactions blocked on a row lock placed by an INSERT, UPDATE, or an isolation level 2 or 3 FETCH, may have waited on the wrong connection, or may have waited indefinitely (until the transaction was forcibly aborted). For this to have occurred, the connection holding the lock must have been in the process of disconnecting when the transaction blocked. While correctness was not affected, application performance could have suffered. This has now been fixed. ===============(Release Build - Engineering Case #543006)=============== If an application was using a JDBC based Remote Data Access server to fetch long multi-byte string data, then there was a possibility the server would have crashed. This problem has been fixed. ===============(Release Build - Engineering Case #543002)=============== An HTTP server response returning an error status, such as "404 Not Found", was returned in the server's language and the Content-Type header incorrectly specifies charset=ISO-8859-1. This has been fixed so that HTTP status messages are now always returned in the English language. Therefore the Content-Type header charset=ISO-8859-1 will now be correct. ===============(Release Build - Engineering Case #542977)=============== If a connection was using the CLR External Environment, and the CLR External Environment was left idle for ten minutes or so, then that connection would no longer have been able to make CLR calls, even though other connections were able to use the CLR External Environment without difficulty. This problem has now been fixed. Note that a simple workaround to the problem is to execute: STOP EXTERNAL ENVIRONMENT CLR on the connection that is having difficulty executing CLR calls. Unfortunately, stopping the CLR External Environment will have the side effect of dropping all static variables for that particular connection. ===============(Release Build - Engineering Case #542959)=============== The Interactive SQL utility's (dbisqlc) OUTPUT statement was incorrectly using the value (NULL) for null values, instead of using a blank value. This has been fixed. This can be worked around by using dbisql or by correcting the output_nulls Interactive SQL option using the statement: set option output_nulls = '' ===============(Release Build - Engineering Case #544641)=============== When running on Windows systems, the server could have taken longer than necessary to shutdown, or could even have crashed during the shutdown process. This has now been fixed. ===============(Release Build - Engineering Case #542514)=============== In a SQL Anywhere SOAP response, binary data types greater than 250 bytes in length were not base64 encoded. This has been fixed, and applies to SQL Anywhere SOAP services that have been defined with DATATYPE ON or DATATYPE OUT. ===============(Release Build - Engineering Case #542524)=============== If an application on a Unix system used the iAnywhere JDBC driver to connect to a DB2 server using a 64-bit DB2 ODBC driver, then calling the Connection.getTransactionIsolationLevel() method may have crashed the client. This problem has been fixed. ===============(Release Build - Engineering Case #542523)=============== It was possible for a mirroring connection (i.e. a connection from one server to another server in a high availability configuration) to have failed with no error message being written to the console. This has been fixed. ===============(Release Build - Engineering Case #542522)=============== In rare cases, executing an invalid ALTER PROCEDURE statement could have caused a server crash or an incorrect error message. This has been fixed. ===============(Release Build - Engineering Case #542519)=============== If an application made a large number of remote calls to fetch data from a JDBC based Remote Data Access server, then there was a chance the server would have crashed. For this problem to have occurred, the remote table and/or column names must have been longer than 30 characters. This problem has now been fixed. ===============(Release Build - Engineering Case #536541)=============== If an application attempted to update or delete from a proxy table joined with a local table, then the server may have failed an assertion, or crashed. The server will now correctly give error -728 'Update operation attempted on non-updatable remote query'. ===============(Release Build - Engineering Case #542397)=============== The DISH service does not set the HTTP Content-Type response header, which has occasionally caused Internet Explorer 7 to fail to render the WSDL. This has been fixed so that the response headers now include Content-Type: text/xml; charset="utf-8". Note, the charset qualifier is not included in 9.0.2 since its output is in database character set. This change is in accordance with the WSDL 1.1 specification, see http://www.w3.org/TR/wsdl#_Toc492291097. ===============(Release Build - Engineering Case #542208)=============== A query using a CONTAINS search condition over a MANUAL or AUTO refresh index that searched multiple columns, would never have returned rows where the first search column was NULL, even if the others were not NULL and had matches. This is fixed. ===============(Release Build - Engineering Case #542139)=============== Sybase Central would have reported errors when attempting to browse a database that had the quoted_identifier option set to Off. SQL statements sent to the database had reserved words that were used as system table columns quoted (for example, SYS.SYSTAB."encrypted"). This did not work if the quoted_identifier option was Off, so the plug-in now temporarily sets it to On. ===============(Release Build - Engineering Case #542175)=============== The names of objects in the transaction log were not being qualified with owner name for some statements. Now, object names in the transaction log will be qualified with the owners names when the latter are not specified for the following : - the REFERENCES clauses of CREATE and ALTER TABLE statement - the TABLE, [MATERIALIZED] VIEW, PRIMARY KEY, COLUMN and INDEX clauses of the COMMENT ON statement - DROP and ALTER INDEX statements ===============(Release Build - Engineering Case #541630)=============== Queries using the CONTAINS search conditionwith phrases longer than three words, or adjacent NEAR operators with more than three words, could have returned false matches. This happened if all of the pairwise conditions match, but in different places in the string. For example, for the phrase "a b c" the pairwise conditions are the existence of "a b", "b c" and "a * c" where * means any word. Therefore, the string 'a b x b c x a x c' will match this phrase even though it should not. The problem is now fixed. ===============(Release Build - Engineering Case #541060)=============== The server, in rare circumstances, could have hung updating string columns. This has been fixed. ===============(Release Build - Engineering Case #541870)=============== Some versions of Windows Vista are misidentified as Windows Server 2008. Among other places, this would have shown up in the server console window, and with the 'platform' property. The GetVersion system call is unable to distinguish between Server 2008 and Windows Vista. This was corrected by changing the Getversion function to GetVersionEx. ===============(Release Build - Engineering Case #541772)=============== Calling the system function property('FunctionMaxParms',0) would have returned NULL, instead of the correct value 0. This has been fixed. This corresponds to the maximum number of arguments for the abs function. ===============(Release Build - Engineering Case #541770)=============== If an application connected to a database with a multi-byte character set made a remote procedure call using one of the JDBC remote server classes, then there is a chance the server could have either hung or crash. For this to have occurred, the remote procedure must return a result set containing long character columns, and the proxy procedure must not have initially been defined with a proper result clause, This problem has now been fixed. ===============(Release Build - Engineering Case #541756)=============== When an application used one of the C External Environments to return a result set back to the server, returning a NULL value would have either resulted in a conversion error or a crash of the external environment. This problem has now been fixed. ===============(Release Build - Engineering Case #541744)=============== If a CREATE EXISTING TABLE command was used to create a proxy table to a remote server using one of the JDBC remote server classes, then the server would have leaked memory. This problem has now been fixed. ===============(Release Build - Engineering Case #541742)=============== Virtual tables were considered non-updatable, which was incorrect. The server may have crashed if an UPDATE statement targeted a virtual table. This has been fixed. ===============(Release Build - Engineering Case #541622)=============== If a Transact-SQL CREATE PROCEDURE statement appeared within a BEGIN ... END block, the syntax error given would have been "Syntax error near 'end' on line nnn", where nnn was the line corresponding to the end of the block. Now the error points to the first point at which the server detected a dialect conflict. ===============(Release Build - Engineering Case #541615)=============== If an application made a remote procedure call to a procedure that returned a result set with unsigned data types, there was a possibility that the call would have failed with a conversion error. This problem has now been fixed. ===============(Release Build - Engineering Case #541586)=============== If a CREATE EVENT statement was executed without including the owner name for the event, the statement recorded in the transaction log did not include the current user's name as the owner. This has been fixed. ===============(Release Build - Engineering Case #540387)=============== When an application made an external environment procedure call, and then issued a commit followed by another external environment call, there was a chance the server would have crashed. This problem should not show up if either the original or external connection was accessing a temporary table. It has now been fixed ===============(Release Build - Engineering Case #538306)=============== If multiple connections executed DDL statements concurrently, then, under very rare circumstances, it was possible for the server to behave incorrectly. This problem has been resolved. ===============(Release Build - Engineering Case #541322)=============== Use of the NEAR operator in a CONTAINS query may have returned incorrect results. This would have occurred when using a MANUAL or AUTO refresh index that had been refreshed several times. This has now been fixed. ===============(Release Build - Engineering Case #541313)=============== The 'blocking' option was not included in the result set of the sa_conn_properties() stored procedure. This has been corrected. ===============(Release Build - Engineering Case #541297)=============== If a GRANT or REVOKE of EXECUTE permission for a procedure did not include the procedure's owner, the entry in the transaction log would also not have included the procedure's owner. This has been fixed. ===============(Release Build - Engineering Case #541201)=============== When running Application Profiling, the start_time and finish_time columns of the sa_diagnostic_request table were incorrectly set. The column start_time was set to the correct start time plus the value from the duration_ms column, while the column finish_time was set to the correct start time plus twice the value from the duration_ms column. This has now been corrected. ===============(Release Build - Engineering Case #540569)=============== Statements using EXISTS() subqueries with INTERSECT and EXCEPT may have returned incorrect results. This would have occurred when at least one of the select lists inside the EXISTS() subquery used "*". This has now been fixed. For example: select filename, file_id from t1 where ( exists (select * from t1 except select * from t2) OR exists (select * from t2 except select * from t1) ) ===============(Release Build - Engineering Case #536805)=============== Grouping queries containing a CUBE, ROLLUP or GROUPING SETS clause may have returned incorrect results. The query must also have had a HAVING clause with at least one null sensitive predicate (e.g., 'T.C IS NULL' , 'T.C IS NOT NULL' ). This has been fixed. An example: select dim1, dim2, sum (val1), stddev (val2) from tt group by cube (dim1, dim2) having dim1 is not null or dim2 is not null ===============(Release Build - Engineering Case #541200)=============== Some missing items to the graphical and long plans have been added as follows: 1 - HAVING predicate was not dumped in the long plan for any GroupBy physical operator. 2 - HAVING predicate was not dumped for GroupBySortedSets physical operators in the graphical plan. 3 - The number of extension pages was missing in "Table Reference" section of the graphical plan. 4 - The 'Estimated Cache Pages' was missing in the long plan. ===============(Release Build - Engineering Case #541175)=============== It was possible, although likely rare, for the server to crash on shutdown. This has been fixed. ===============(Release Build - Engineering Case #540789)=============== If several connections attempted to concurrently execute CREATE, DROP or ALTER statements for a global temporary table, or its indexes, the server could have crashed. This has been fixed so that a global temporary table and its indexes can no longer be altered or dropped if other connections have previously referenced the table until those connections have disconnected. ===============(Release Build - Engineering Case #534471)=============== The server performs an implicit commit before and after the execution of a CREATE INDEX statement. The act of performing a commit following execution releases any locks obtained by the server during the creation of the index. If the create statement failed due to an error, then the server could have failed to release the locks obtained before the point of failure. There was no other user visible impact and the held locks were released when the connection next performed a COMMIT or ROLLBACK. This has been corrected so that the server now release the held locks automatically. ===============(Release Build - Engineering Case #541470)=============== If a procedure or view was created containing an expression that included subtraction of a negative constant, the procedure or view would not have been stored correctly. This has been fixed. ===============(Release Build - Engineering Case #541055)=============== Some CONTAINS queries may have intermittently taken much longer than they should (e.g. minutes rather than seconds with a query of several frequently occuring words and 1-2Gb of indexed text). This has been fixed fixed. ===============(Release Build - Engineering Case #540048)=============== When attempting to set the non_keywords option to a value that contained a keyword already listed in the current value of the non_keywords option, an invalid option setting error would have been reported. This has been fixed. ===============(Release Build - Engineering Case #540921)=============== Attempting to access a remote server defined using one of the JDBC classes, could have caused the server to crash if Java failed to start. This problem has now been fixed. ===============(Release Build - Engineering Case #540575)=============== When in Profiling Mode in Sybase Central, clicking the Index Consultant, or DBISQL, icon for a statement on the Details tab, could have resulted in a syntax error. The problem was caused by syntax errors in SQL statements used by Sybase Central, which have now been fixed. ===============(Release Build - Engineering Case #540708)=============== If a failover occurred in a mirroring system, automatic checkpoints would not have occurred on the new primary server. Stopping and restarting both servers would have corrected the problem. This has been fixed. ===============(Release Build - Engineering Case #540703)=============== When attempting to execute a query that references a proxy table mapped to a DB2 table, and one of the columns in the DB2 table was of type "varchar for bit data", there was a possiblility that fetching data from the proxy column would have resulted in data truncation. This problem does not exist for BLOB, "char for bit data" and "long varchar for bit data" DB2 columns. The has now been fixed. ===============(Release Build - Engineering Case #540681)=============== Running out of non-cache memory may have caused the server to hang. This has been fixed. ===============(Release Build - Engineering Case #537555)=============== Dropping a table could, in rare circumstances, have caused the server to fail assertion 102806 "Unable to delete row from SYSTABLE". This has been fixed. ===============(Release Build - Engineering Case #540557)=============== If the operating system's character set did not match the database's character set, non-ASCII server messages obtained using the system procedure sa_server_messages(), would have been mangled. The server was not converting from the database's character set to the operating system's character set before returning the text. This has been fixed. ===============(Release Build - Engineering Case #540536)=============== Certain complex regular expression patterns could have caused the server to hang for a few seconds or more. Patterns which could have caused this problem were unlikely to be used in practice, as they needed to be over 100 characters long and have certain unlikely characteristics. This has been fixed so that regular expression patterns that could have caused the server to hang will now generate the error "Statement size or complexity exceeds server limits" (-890). ===============(Release Build - Engineering Case #540530)=============== Depending on the language and character set of the operating system, the usage message could have been truncated. Running under an English language locale did not expose this problem. A buffer used for character set translation was under-sized. This has been corrected. ===============(Release Build - Engineering Case #541202)=============== Statements using derived tables on the null supplying side of a left outer joins may have returned syntax errors. For this to have occurred, the derived table must have been unflattenable (i.e. it contained GROUP BY, ORDER BY, etc.) and have been used in the null-supplying side of the outer join. There must also have existed a predicate in the ON condition, which was local to the derived table (e.g., "ON .... DT.C = 10 .... "), and referenced the derived table column with a complex expression. This has now been fixed. ===============(Release Build - Engineering Case #540393)=============== If a DSN pointed to a Web Edition server, the ODBC Administrator would have given the error "This server is not licensed to support 'ODBC' connections" when the "Test Connection" button was used. This has been fixed. ===============(Release Build - Engineering Case #540392)=============== Using the Ping utility (dbping) with the -m command line option (use ODBC driver manager) to attempt to connect to the Web Edition server would have resulted in the error "This server is not licensed to support 'ODBC' connections". This has been corrected. ===============(Release Build - Engineering Case #540380)=============== On AIX 5.3 systems, the ApproximateCPUTime connection property could have returned a value that was impossibly large. This has been fixed. ===============(Release Build - Engineering Case #540371)=============== In rare circumstances, the server could have crashed while disconnecting, if the connection had created temporary procedures. This has been fixed. ===============(Release Build - Engineering Case #540369)=============== If request level logging of procedures was enabled, and a FORWARD TO statement was executed on a remote server from an Open Client or jConnect application, then there was a chance the server would have crashed. This problem did not occur if a non-TDS based client was used, or if request level logging of procedures was not enabled. This has been fixed. ===============(Release Build - Engineering Case #532086)=============== If a server had many concurrent connections using Java in the database support, then there was a chance the server could either have hung, or crashed intermittently. These hangs or crashes could also have occurred at server shutdown time. These problems have now been fixed. ===============(Release Build - Engineering Case #540219)=============== If an application called a procedure that references a proxy table, and that procedure was subsequently used in the FROM clause of a SELECT statement along with the WITH clause, then there was a chance the the server would have crashed. This problem has now been fixed. ===============(Release Build - Engineering Case #540205)=============== If a remote server was defined using one of the Remote Data Access JDBC classes, then changing the value of the quoted_identifier option would not have resulted in changing the value of the quoted_identifier option on the remote. This problem has now been fixed. ===============(Release Build - Engineering Case #540071)=============== If an application used a prepared statement to insert an empty string via a parameter marker into a long varchar column of a proxy table, then the server may have hung, or have given a strange error. Note that inserting an empty string as a string literal works just fine. This problem has now been fixed. ===============(Release Build - Engineering Case #541073)=============== On AIX 6, 64-bit software would not have found the LDAP support libraries, even if they were in the LIBPATH. The location of the LDAP system libraries was changed in AIX 6. The 64-bit library is in: /opt/IBM/ldap/V6.1/lib64/libibmldap.a and the 32-bit library is in: /opt/IBM/ldap/V6.1/lib/libibmldap.a This has been fixed. Note that you still need to ensure that the directory with the LDAP libraries are in the LIBPATH. For example, for 64-bit libraries: export LIBPATH=/opt/IBM/ldap/V6.1/lib64:$LIBPATH and for 32-bit libraries: export LIBPATH=/opt/IBM/ldap/V6.1/lib:$LIBPATH As a work around to use SQL Anywhere LDAP support with AIX 6, create links in /usr/lib as follows (must be root): cd /usr/lib ln -s /opt/IBM/ldap/V6.1/lib64/libibmldap.a libibmldap64.a ln -s /opt/IBM/ldap/V6.1/lib/libibmldap.a ===============(Release Build - Engineering Case #540094)=============== In rare circumstances, an outgoing mirroring connection attempt to a partner, or to the arbiter, may have hung indefinitely. This has been fixed. ===============(Release Build - Engineering Case #539807)=============== On Mac OS X systems, if the server was started on a non-default port (i.e. other than 2638), and with an IPv6 address as the value for the MyIP option, a UDP listener would not have been started on the default port. As a result, the server would not have been able to locate the server via broadcasts unless the sever's port was explicitly specified in the client's connection string. This has now been fixed. ===============(Release Build - Engineering Case #539609)=============== When running in In-Memory, No-Write mode, only one LOAD TABLE statement was allowed to execute on the database at a time. This was due to the fact that LOAD TABLE, when not running in In-Memory mode, uses the checkpoint log for its page-level undo information, and there can only be one page-level undo operation active on a given database at a time. However, the In-Memory No-Write mode does not use a checkpoint log and therefore has no need of page-level undos. This has been fixed for performance reasons. As a consequence, when running in No-Write mode, multiple, concurrent LOAD TABLE statements may now be active at any point in time, to the same or different tables. ===============(Release Build - Engineering Case #538698)=============== The 'tempfilename' property would have returned a value when running in In-Memory mode, even though neither supported In-Memory modes use a temporary file. This has been fixed so that the 'tempfilename' property now returns NULL when the server is running in In-Memory mode. ===============(Release Build - Engineering Case #539308)=============== On Windows CE devices, the text of the server usage message was mangled. The message box dialog on CE was expecting utf-16 text, but was incorrectly being passed OS charset text. This has been fixed. ===============(Release Build - Engineering Case #539113)=============== Attempting to execute queries with some illegal constructs involving the CONTAINS search condition, couls have lead to a server crash. This has been fixed. ===============(Release Build - Engineering Case #539095)=============== If a mirroring server was accidentally started a second time, the second instance could have crashed after displaying an error. This has been fixed. ===============(Release Build - Engineering Case #537786)=============== As of version 11.0.0, DML operations on temporary tables are allowed to have full transactional semantics (i.e. commit and rollback) on read-only databases. However, the support for this feature was not fully enabled. This has been corrected. Additionally, the creation of savepoints for temporary objects on read-only databases is also now supported. ===============(Release Build - Engineering Case #538883)=============== If the ansi_close_cursors_on_rollback option was set to 'ON', and request logging of plans was enabled, the server could have crashed. This has been fixed. ===============(Release Build - Engineering Case #538862)=============== If ALTER DATABASE UPGRADE was executed twice, using the same connection, the second execution would have failed. The upgrade scripts did not remove some temporary objects used by the scripts. This has been fixed. ===============(Release Build - Engineering Case #539091)=============== The 64-bit server for Sun Solaris performed poorly when executing queries. This has been fixed. ===============(Release Build - Engineering Case #538737)=============== When a mirror server was started in preferred mode, it was possible for the synchronization between the primary and the mirror to have failed. This has now been fixed. ===============(Release Build - Engineering Case #537337)=============== Calling the ODBC function SQLGetProcedureColumns() would have failed with the error -143 "Column 'remarks' not found" when using a SQL Anywhere ODBC driver from a version prior to 10.0 and connected to version 10.0 or later server. This was due the ODBC drivers prior to version 10.0 referencing the SYSPROCPARM.remarks column in the SQLGetProcedureColumns() function, which had been dropped in version 10.0 and later database files. The SYSPROCPARM.remarks column has been re-added as a constant NULL. ===============(Release Build - Engineering Case #538547)=============== The search conditions SIMILAR TO and REGEXP, and the fuction REGEXP_SUBSTR() could have given incorrect results for some patterns if the string being searched was more than 250 bytes in length. The search string could be 250 bytes in length if it contained as few as 63 characters and the database character set was multi byte (including NCHAR strings). It was possible that a pattern would not have matched a string that it should have. In rare cases the server could even have crashed. This has now been fixed. ===============(Release Build - Engineering Case #538305)=============== The server console's checkpoint begin and end messages were not being displayed when the server was run in 'in memory' mode with Checkpoint only (-im c). This has been fixed. ===============(Release Build - Engineering Case #538303)=============== If while executing an ATTACH TRACING statement, the tracing server was stopped, the server being traced could have crashed. This has been fixed. ===============(Release Build - Engineering Case #537391)=============== A connection may have held table or row locks even after a DDL statement had failed. This has been fixed. ===============(Release Build - Engineering Case #538146)=============== Under some update patterns, concurrent changes to text indexes created with the IMMEDIATE REFRESH clause, could have caused assertion failure 110400. This has now been fixed. ===============(Release Build - Engineering Case #538128)=============== Attempting to upgrade the mirrored database in a mirroring system, using the Upgrade utility (dbupgrad), or by executing an ALTER DATABASE UPGRADE statement, would have resulted in transaction log entries which could not be replayed on the mirror server. An error will now be given if an upgrade is attempted on a database which is currently being mirrored. ===============(Release Build - Engineering Case #538098)=============== The space previously used by deleted rows was not being reclaimed and reused on the mirror server of a mirroring system. As a result, the mirror server's database could have grown faster than the database on the primary server. This space would have eventually be reclaimed if the mirror server became the primary server. This has been fixed. ===============(Release Build - Engineering Case #537923)=============== Execution of some queries involving procedure calls could caused a server crash. This is fixed. ===============(Release Build - Engineering Case #535799)=============== Executing queries using SELECT FIRST or SELECT TOP N, referencing proxy tables to a remote DB2 server, would have failed with a syntax error. DB2 does not support the FIRST and TOP N syntax; instead, the query must use FETCH FIRST ROW ONLY for FIRST, or FETCH FIRST N ROWS ONLY for TOP N. This problem has now been fixed. ===============(Release Build - Engineering Case #537800)=============== If an application executed a remote query with a malformed field or dotted reference in the select list, then it was possible that the server could have crashed. An example of such a query is: select c1.ref(), max( c2 ), c2 from t1 where c1.ref() is a meaningless expression. This problem has now been fixed and a proper error message will be returned to the application. ===============(Release Build - Engineering Case #537748)=============== When running the server in 'in memory' mode, the server would still have enforced the per-connection temporary space limit, even though no temporary files are used when running in 'in memory' mode. This has been fixed. ===============(Release Build - Engineering Case #537610)=============== Some queries with an illegal CONTAINS search condition could have caused the server to crash. This has now been fixed. ===============(Release Build - Engineering Case #537616)=============== Under rare circumstances, the server could have gone into an infinite loop after a non-recurring scheduled event was run. Any attempts to communicate with the database on which the event was scheduled would have blocked. This has been fixed. ===============(Release Build - Engineering Case #537560)=============== It was possible for calls to DB_Property( 'DriveType' ) on AIX systems to erroneously return "UNKNOWN". A buffer used to enumerate the various mounted filesystems may have been too small. This has been fixed. ===============(Release Build - Engineering Case #537399)=============== The search condition REGEXP, and the system function REGEXP_SUBSTR(), were treating _ (underscore) and % (percent) as meta characters to match any character or any characters respectively. Also, if a caret (^) was in a character class, but not the first character after the open square bracket (for example [a-e^d]), then it was treated as a subtraction character class operator. These behaviours were different than other tools such as Perl, Java, .NET, etc. This has now been fixed so that _ and % are not meta characters for REGEXP and REGEXP_SUBSTR(); and a caret which is not the first character after the open square bracket now matches a caret. The search condition SIMILAR TO has not been changed. For SIMILAR TO, _ matches one character, % matches any number of characters and [a-e^d] matches a, b, c and e. ===============(Release Build - Engineering Case #537177)=============== The search conditions SIMILAR TO and REGEXP, when used with the sub-character classes [[:upper:]] and [[:lower:]], were case insensitive on a case insensitive database. This has been fixed so that [[:upper:]] only matches upper case characters and [[:lower:]] only matches lower case characters, regardless of the database case sensitivity. ===============(Release Build - Engineering Case #537164)=============== The server assigns a unique object id for every object created in the database. The object ids are stored in the catalog table SYS.ISYSOBJECT. When objects are deleted, their ids are reused for new objects when the ids being released are at the end of the currently allocated range. Under concurrent execution of DDL operations it was possible for the server to avoid reusing some object ids even when it was possible to do so. There was no likely adverse effect of this deficiency, which has now been corrected. ===============(Release Build - Engineering Case #537153)=============== On AIX systems, in some very rare circumstances, the server could have crashed while listening for network broadcasts. This has been fixed. ===============(Release Build - Engineering Case #537126)=============== When running on multiprocessor machines, statements with joins may have caused a server crash in rare conditions. This is now fixed. ===============(Release Build - Engineering Case #536808)=============== The server tracks dependencies of views on other views and tables. If a view referenced another view and the view definition of the referenced view was "flattened" or "inlined" within that of the referencing view, then the server could have failed to correctly record the dependency information. The server now behaves correctly when recording dependency information in this situation. Any existing views can have their dependency information recorded correctly by being recompiled. ===============(Release Build - Engineering Case #536739)=============== The server could could have raised assertion 102802 - "Unable to undo index changes resulting from a failed column alteration" if an ALTER statement failed, or was cancelled. This has now ben fixed. ===============(Release Build - Engineering Case #536594)=============== If an external function that was defined to return an integer value was assigned to a variable declared as INT, a "Value out of range for destination" error would have been given. This has been fixed. ===============(Release Build - Engineering Case #536588)=============== If an application connected using a TDS based client (i.e. jConnect, iAnywhere JDBC) and attempted to use a procedure in the FROM clause of a SELECT statement, then the TDS client may have reported a TDS protocol error. This problem has now been fixed. ===============(Release Build - Engineering Case #536388)=============== In rare situations, a busy HTTP server may have timeouted a connection as the request was queued, causing the server to crash. This has been fixed. ===============(Release Build - Engineering Case #536015)=============== The ALTER VIEW RECOMPILE statement can be used to rebuild the view definition of an existing view. Among other things, the statement causes the schema of the view columns to be regenerated. If column permissions, as opposed to table permissions, have been granted on a view, then the recompilation could have failed with a foreign key constraint violation on SYS.SYSCOLUMN. The server now remembers all the column permissions on the view that exist before the recompile statement is executed. After the view has been recompiled, the server automatically restores the old column permissions based on column name look-ups in the new view definition. Note that if a column of the view that no longer exists after the recompilation will have the old permissions lost. A workaround is to drop the column permissions and to restore them after the view recompilation. See also Engineering case 534294 for a related issue. ===============(Release Build - Engineering Case #534294)=============== The server keeps track of the dependencies of views on other tables and views. When the schema of a table is modified by using the ALTER TABLE statement, the server automatically and atomically recompiles all views whose view definitions depend upon the schema of the table being modified. All views that can be compiled without errors with the new table schema are rebuilt persistently in the catalog and remain valid after reflecting the changes in the table schema. Views that fail to compile are left in a state where the server automatically tries to recompile them in the future. If column permissions, as opposed to table permissions, had been granted on a view dependent on the table being modified, the execution of ALTER TABLE could have failed with referential integrity violations on SYS.SYSTABCOL. This has been corrected so that the server now automatically attempts to restore the old column permissions on views that are recompiled as a consequence of ALTER TABLE. Permissions on columns that no longer exist in the recompiled view(s) are lost. See Engineering case 536015 for a related issue. ===============(Release Build - Engineering Case #535988)=============== Attempting to setting the inline or prefix amount of a blob column to 32768 on a 32K pagesize database would have failed with the error: 'Illegal column definition: Column 'xxx' inline value '-32768' is invalid" This has now been fixed. A workaround is to use the value 32767. Doing so does not affect the amount of inline space available for the column as there is always some page overhead that is unusable for prefix data. ===============(Release Build - Engineering Case #535804)=============== Values for SOAP input TIME and DATETIME data types were incorrectly converted to the server's locale if the value contained a negative time zone offset, with a nonzero minute field, i.e. GMT-03:30 (Newfoundland). This has been fixed. In addition the processing of DATE values has modified with this change. The TZ offset if provided with an input DATE value is now ignored, and the TZ offset is no longer appended to an output DATE value (within the HTTP/SOAP response). ===============(Release Build - Engineering Case #535662)=============== A SQL Anywhere JSON SERVICE may have returned unencoded control characters when the server wrote content that was greater than 256 bytes. This has been fixed. Strings containing control characters, such as newline, are now always encoded (i.e. "\n" is returned rather than 0x0A). ===============(Release Build - Engineering Case #535643)=============== Cancelling an ALTER TABLE statement for a large table, may have left the database in a corrupt state. This has been fixed. ===============(Release Build - Engineering Case #535592)=============== If a CREATE EXTERNLOGIN statement was executed with an empty string for the password, the password recorded in the transaction log would have been incorrect. This has been fixed. ===============(Release Build - Engineering Case #535363)=============== The encrypted form of a user password that had been set by a CREATE USER, or an ALTER USER, statement could have been interpreted incorrectly if the transaction log was translated by the Translation utility (dbtran) and the resulting SQL file re-executed. This was likely to be a problem only for databases using multi-byte character sets, and has now been fixed. ===============(Release Build - Engineering Case #535215)=============== The server supports the ANSI MERGE statement, with some vendor extensions, which can be utilized to merge data from one source into another. Under certain circumstance, the MERGE statement could have behaved incorrectly. As an example, if the MERGE statement was instructed to update multiple rows of the target table based on the same matching conditions, then the values visible for the new row within a BEFORE UPDATE row level trigger could have been incorrect. This problem has been resolved. ===============(Release Build - Engineering Case #534927)=============== Control of an HTTP session time-out duration was not passed to subsequent HTTP requests belonging to the same session if a TEMPORARY HTTP_SESSION_TIMEOUT database option had been set (in a previous HTTP request belonging to the session). The scope of the problem applied to all TEMPORARY database options set within an HTTP session context. The problem was due to user id being reset for each HTTP request. This has been corrected so that an HTTP request within a session context will no longer reset its user id if it is identical to the user id of the current service. The problem remained however if an HTTP session was used to call a service that specified a different user id. A SA web application using HTTP sessions should only use TEMPORARY and/or USER specific options when all requests within the HTTP session context access SA services defined with the same user id. Similarly, accessing an authenticated SERVICE would require that the HTTP request belonging to a session provide the same user id from request to request. To address this, a new HTTP OPTION called SessionTimeout has been added to make HTTP session time-out criteria persistent in all cases. It can be set from within an HTTP request that has defined, or will define, a SessionID. The context of the setting is preserved throughout the HTTP session, until it expires, is deleted or changed (with a subsequent SA_SET_HTTP_OPTION call). - New SA_SET_HTTP_OPTION option SessionTimeout The value of this HTTP OPTION is specified in minutes. It is subject to the minimum and maximum constraints of the HTTP_SESSION_TIMEOUT database option. A newly created session is implicitly assigned the current or default PUBLIC/USER HTTP_SESSION_TIMEOUT. The following example sets a given HTTP session time-out to 5 minutes: call SA_SET_HTTP_OPTION('SessionTimeout', '5'); An empty value resets the option to its default value, or as set by the PUBLIC or USER scope HTTP_SESSION_TIMEOUT database option. call SA_SET_HTTP_OPTION('SessionTimeout', ''); // resets the time-out to 30 minutes - the default value of the HTTP_SESSION_TIMEOUT database option SET OPTION PUBLIC.HTTP_SESSION_TIMEOUT=1 // New HTTP sessions calling SA_SET_HTTP_OPTION('SessionTimeout', '') set session time-out to 1 minute SET OPTION USERA.HTTP_SESSION_TIMEOUT=15 // New HTTP sessions calling SA_SET_HTTP_OPTION('SessionTimeout', '') set session time-out to 15 minutes for USERA NOTE: HTTP session default criteria is derived from the current PUBLIC/USER HTTP_SESSION_TIMEOUT database option setting. Any subsequent changes to this option will not implicitly affect existing HTTP sessions. The default timeout setting for HTTP sessions that always use the same user id remains unchanged. However, an HTTP request belonging to a session that calls a service with an alternate user id will force its cache to be cleared and the option defaults of the current user to be loaded. Therefore, when the session switches users all TEMPORARY options are lost and the current PUBLIC/USER options are assigned. - New CONNECTION_PROPERTY('SessionTimeout') Returns the time-out value in minutes for a given database connection belonging to an HTTP session. The value is the current setting for SA_SET_HTTP_OPTION('SessionTimeout', 'X'). A value of 0 is returned if the database connection does not belong to an HTTP session. As before, the HTTP_SESSION_TIMEOUT database option may be queried to determine the PUBLIC/USER default values. - Summary of changes TEMPORARY and USER scope options are preserved when HTTP requests belonging to a session execute SA services defined with a specific (the same) user id. SessionTimeout HTTP_OPTION has been added to provide an HTTP session context time-out criteria. Its use is recommended in place of setting a TEMPORARY HTTP_SESSION_TIMEOUT database option since it is guaranteed to persist for the life of the session. ===============(Release Build - Engineering Case #534963)=============== The server tracks dependencies of views on other views and tables. If a table is referenced by other views, attempting to execute an ALTER TABLE statement on the referenced table could have caused the server to crash under certain circumstances. This has been fixed, the server now carries out the ALTER properly. A workaround is to disable the dependent view before executing the ALTER statement, followed by a re-enabling of the view. ===============(Release Build - Engineering Case #534931)=============== A query that did a scan of an index when the isolation level was set snapshort, could have returned extra rows. This has now been corrected. ===============(Release Build - Engineering Case #530287)=============== Indexes containing values longer than approx 250 bytes could have become corrupt when an entry was deleted from the index. This has now been fixed. ===============(Release Build - Engineering Case #534356)=============== Very occasionally, the Interactive SQL utility may not have started when the fast launcher option was turned on. This problem has been fixed. ===============(Release Build - Engineering Case #534496)=============== An expression that converted an integer value to a NUMERIC or a DECIMAL, could have leaked memory in the server if an overflow error was generated. If enough of these expressions were evaluated, server execution could have been impaired. This has been fixed. ===============(Release Build - Engineering Case #534358)=============== Use of any of the TLS options "certificate_name", "certificate_unit", or "certificate_company" would have caused connections to fail with a "TLS handshake failure" error. This has been fixed. As a workaround, the options "name", "unit", and "company" can be used. ===============(Release Build - Engineering Case #534333)=============== When calling the system function REGEXP_SUBSTR() with non-ASCII characters, it could have returned an incorrect result, possibly consisting of invalid characters. The input strings were being cast to NCHAR values, and then the resulting NCHAR output was treated as a CHAR, resulting in garbled output if the database character set was not UTF8. This has been fixed. ===============(Release Build - Engineering Case #534324)=============== Statements that appeared in stored procedures may have used a cached execution plan (see Plan caching in the documentation). In some cases, a stale value of a builtin function could have been returned for subsequent executions of the statement. This has now been corrected. The following builtin functions were affected by this issue: connection_extended_property connection_property db_extended_property db_property estimate estimate_source event_condition event_condition_name event_parameter experience_estimate http_body http_header http_variable index_enabled index_estimate next_connection next_database next_http_header next_http_variable next_soap_header property rewrite soap_header varexists watcomsql For web services based on sessions, connection properties such as SessionLastTime could also have been affected by this (among other builtins). This incorrect behaviour was masked in version 10.0.1 for web services using sessions. ===============(Release Build - Engineering Case #534321)=============== The server could have crashed when processing an HTTP request that required character set conversion. This has been fixed. ===============(Release Build - Engineering Case #533724)=============== The server would have crashed if the sa_locks() system procedure was executed when it was running in bulk operation mode (-b server command line option). This has been fixed. ===============(Release Build - Engineering Case #535637)=============== If execution of a LOAD TABLE statement failed, and the table was large, database corruption could have resulted. The server may have freed a page twice. This has been fixed. ===============(Release Build - Engineering Case #535627)=============== The database properties CleanablePagesAdded and CleanablePagesCleaned could have reported that there were pages to clean when in actuallity there were none. This would have happened if a dbspace with cleanable pages was dropped. This has now been fixed. ===============(Release Build - Engineering Case #534168)=============== Altering a column with an IMMEDIATE REFRESH text index would have caused the server to fail an assertion. This is fixed. ===============(Release Build - Engineering Case #534147)=============== The server could have crashed following many concurrent updates and/or inserts to a large indexed table. This has now been fixed. ===============(Release Build - Engineering Case #534132)=============== If many rows had been deleted from the end of an index, and the server was under heavy load for some period of time after that, there was a chance that the server could have crashed. ===============(Release Build - Engineering Case #536001)=============== When autostopping a database, the server could have failed assertion 201137 - "Concurrent outstanding file growth requests." This would have been very rare, and timing dependeding. It was also possible to see this assertion when shutting down the server while a DDL operation, typically a long running one, was underway. This has now been fixed. ===============(Release Build - Engineering Case #533793)=============== If a server had multiple databases loaded, each with a different character set, the database name returned by the system function "db_property('Name', <dbid>)" could have been improperly character set converted. This could have made the name returned appear garbled. For this to have occurred, the database ID specified by "<dbid>" must have been different from the ID of the database of the connection. This has now been fixed. ===============(Release Build - Engineering Case #533802)=============== Execution of a SELECT statement that referenced a procedure call in the FROM clause could have resulted in a server crash. For this to have occurred, the connection must have had several cursors open, or have had several prepared statements. This has now been fixed. ===============(Release Build - Engineering Case #533600)=============== When using a derived table in a remote query, if one or more columns from the derived table were referenced in the WHERE clause of the query, and the query was going to be processed in full passthru, then the engine would have returned with a "correlation name not found" error. This problem has now been fixed. ===============(Release Build - Engineering Case #533055)=============== If a LIKE predicate contained specific forms of patterns, and it referred to a column contained in an index, then it was possible for the server to crash when opening the statement containing the LIKE predicate. This has been fixed. ===============(Release Build - Engineering Case #532819)=============== If a START DATABASE statement or an attempt to autostart a database on an already-running server, failed due to an alternate server name conflict, a second attempt to start the database with the same (conflicting) alternate server name would have succeeded when it should have failed as well. This has now been fixed. ===============(Release Build - Engineering Case #532796)=============== If a database was started with an alternate server name on an already-running server, in rare cases, subsequent TCP connection attempts to the server may have failed. This has been fixed. ===============(Release Build - Engineering Case #533028)=============== If a database contained materialized views, and one of the base tables referenced by a materialized view contained foreign key constraints, then the Unload utility (dbunload) could have generated a reload script that would have failed to execute. The reload script would have contained ALTER TABLE ... ADD FOREIGN KEY statements after the creation of materialized views. The server now allows the reload script to execute without errors. Note, a work-around is to manually edit the reload script to make the reload work. ===============(Release Build - Engineering Case #533010)=============== When using the new ULODBC class to map a proxy table to a table within a non-UTF8 MBCS UltraLite database, and then attempting to fetch string data from that proxy table, there was a chance the data would have had additional garbage characters. This problem has been fixed. ===============(Release Build - Engineering Case #532850)=============== Executing a CREATE EXISTING TABLE statement to create a proxy table when the remote table has an unsupported index on it, could have caused the statement to fail. This problem has now been fixed. ===============(Release Build - Engineering Case #539620)=============== In certain rare and highly timing sensitive cases, the server could have hung when shutting down, if an xp_cmdshell() procedure was still running. This has been fixed. ===============(Release Build - Engineering Case #532668)=============== The SORTKEY function did not allow the first parameter to be BINARY if the second parameter (the collation id) was not an integer. Similarly, COMPARE did not allow either of the first two parameters to be BINARY if the third parameter (the collation id) was not an integer. For example, SORTKEY( cast( 'a' as binary ), 'dict' ) would have reported the error "Cannot convert weCHAR values. ===============(Release Build - Engineering Case #532280)=============== The server could have behaved erroneously when new procedures were created from within event handlers, or after having executed the SETUSER statement. Although rare, in the worst case a user could have been allowed to be dropped while still connected. These problems have been corrected so that the server now behaves correctly. ===============(Release Build - Engineering Case #532276)=============== A large query containing a 'WITH' clause could have crashed the server. The server was failing to recognize a SYNTACTIC_LIMIT error for such queries. This has now been corrected. ===============(Release Build - Engineering Case #531160)=============== If a statement used a keyset operator, it was possible for the statement to evaluate expressions that should not be evaluated. In order for this failure to appear, the statement must contain some unflattened views or derived tables (such as grouped, distinct, or top-N views). Keyset operators are used to support values sensitive cursors, and they are also used for some UPDATE, DELETE or MERGE statements. This has been fixed. For example, in the following statement, a division by zero error could be incorrectly returned for a keyset-driven (value sensitive) cursor. select if TMS_1.x = 'zzz' and 1/QT2.y > 0 then 12 endif from ( SELECT x, y FROM TMS_2 GROUP BY x,y ) AS QT2 join TMS_1 ON TMS_1.x = QT2.x ===============(Release Build - Engineering Case #532626)=============== In certain rare situations, it was possible for the server to hang when starting a database. This has been fixed. ===============(Release Build - Engineering Case #530994)=============== The SQL Anywhere server allows for the creation of tables with a very large number of columns and/or indexes. The speed at which the server processes operations involving such large schemas has now been significantly improved. ===============(Release Build - Engineering Case #532254)=============== A server that had registered itself with LDAP tried could have crashed when trying to start a database using an alternate server name, if an error occurred in reading the saldap.ini file. This has been fixed. ===============(Release Build - Engineering Case #532185)=============== SQL Anywhere keeps track of dependencies of views on other views and tables. For view definition queries that involve more than two UNION, EXCEPT or INTERSECT branches and/or sub-queries, the server's computation of the dependency information could have been incorrect, leading to erroneous behaviour. This has beed fixed so that the server now computes the dependency information correctly. Note, any existing views compiled with an older version of the server will continue to have potentially incorrect dependency information in the catalog. Existing views can be made to have the correct dependency information by being recompiled, either implicitly during a DDL operation on one of the referenced tables, or explicitly. ===============(Release Build - Engineering Case #531334)=============== On Linux systems, starting a database that is stored on a non-tmpfs based ramdisk could have failed. This has been fixed. Note, a work around is to use a tmpfs based ramdisk, or start the server with the -u (use buffered disk I/O). ===============(Release Build - Engineering Case #530776)=============== When a database created by a newer version for SQL Anywhere (eg version 11) was started by an older version of SQL Anywhere (eg version 10), the server would have read some pages, other than the definition page, from the database before verifying that the capabilities of the file and server were compatible. The server now tests the capability bits of a database file against the capabilities supported by the server sooner in the database startup process. There are no known user-visible effects caused by checking the capabilities later, other than when starting an encrypted database created by newer software, the server will no longer prompt for an encryption key before reporting that the capabilities are incompatible. ===============(Release Build - Engineering Case #530920)=============== During diagnostic tracing with at least one tracing level of type optimization_logging_with_plans, an incorrect row size could have been reported for a table that had been created immediately before the statement referencing the table was executed. This has been fixed. ===============(Release Build - Engineering Case #500507)=============== If a proxy table referred to a table in a DB2 database and had a BLOB column, then attempting to insert data into the BLOB column would have caused syntax errors. Note that this problem did not exist if the column was instead defined as "LONG VARCHAR FOR BIT DATA", which more closely mapped to the SA "long binary" datatype. Nevertheless, the problem with inserting into DB2 BLOB columns has now been fixed. ===============(Release Build - Engineering Case #538480)=============== In rare circumstances, the server could have crashed while disconnecting if -zl, -zp, sa_server_option( 'RememberLastStatement', 'YES' ) or sa_server_option( 'RememberLastPlan', 'YES' ) were used. This has been fixed. ===============(Release Build - Engineering Case #530576)=============== The http_encode() function was not encoding the 0x1f character. This has been fixed. This character is now encoded to "%1F". ===============(Release Build - Engineering Case #530273)=============== If there were more than 100 connections actively using Java in the database support at the same time, then the JVM would have crashed, or the server could have hung. This problem has now been fixed. ===============(Release Build - Engineering Case #530318)=============== When diagnostic tracing was enabled, with PLANS or PLANS_WITH_STATISTICS as the tracing type, some plans or cursor information could have failed to have been saved. Alternatively, some plans that did not fit the timing cut-off in ABSOLUTE_COST or RELATIVE_COST_DIFFERENCE conditions, could have benn incorrectly saved. These problems have now been fixed. ===============(Release Build - Engineering Case #530302)=============== Attempting to executing a batch which did not take a host variable, but included the :var syntax, could have resulted in a communication error. The :var syntax can be used in a CREATE or ALTER SERVICE statement. This has now been fixed. ===============(Release Build - Engineering Case #530039)=============== When a connection is unexpectedly terminated, a message is displayed in the server console containing the AppInfo string for the client. This message was incorrectly being truncated at 255 bytes. This has been fixed. SQL Anywhere Server - Sybase Central Plug-in ===============(Release Build - Engineering Case #548721)=============== If the CREATE SYNCHRONIZATION PROFILE statement was used to create a synchronization profile with embedded whitespace in the options string, then Sybase Central was not able to parse the string and display the option values on the Synchronization Profile property sheet. This has been fixed. ===============(Release Build - Engineering Case #548895)=============== Sybase Central could have created a dialog, property sheet or wizard whose window was larger than the screen. This would have made it difficult to work with the window. This has been fixed so that Sybase Central now ensures that dialogs, property sheets and wizards are no longer than the screen. ===============(Release Build - Engineering Case #548716)=============== When the server was started with a command line that specified -xs option (comma-separated list of web protocols) without a port, the server 'Overview' did not show the default port. This has been fixed. ===============(Release Build - Engineering Case #548619)=============== When using the Foreign Key wizard to create a foreign key, or the Foreign Key Change Settings dialog to drop and re-create a foreign key with new settings, then the "Allows null" setting chosen would have been reversed. That is, if to allow nulls was chosen, then the foreign key would have been created to prohibit nulls, and vise versa. This has now been corrected. ===============(Release Build - Engineering Case #548431)=============== Sybase Central could have crashed when pasting a column in the table editor. The problem would only have occurred if a new column was added, but a name for the new column had not yet been specified. This has been fixed. ===============(Release Build - Engineering Case #492814)=============== A user without administrator permission was unable to start, stop or delete SQL Anywhere services on a Windows 2003 machine, even if that user had been granted permission by an administrator to control those services. This has been fixed. ===============(Release Build - Engineering Case #498540)=============== When connected to a database mirroring system, viewing the Database Mirroring section of the Overview tab in Sybase Central would have displayed an incorrect value for the primary server's state file when the full path for the state file was specified on the server's command line. This has been corrected. ===============(Release Build - Engineering Case #547779)=============== When creating a maintenance plan, the SQL for the plan's event handler would not always have been displayed in the database's Executed SQL tab. Instead the event SQL would have contained "HANDLER null". This problem would only occur if the handler did not include an SMTP or MAPI password. This has been fixed. ===============(Release Build - Engineering Case #547594)=============== In the Maintenance Plan wizard, if the checkbox "Validate database pages" was selected, then the generated event handler would have validated tables and materialized views as well, even if the checkbox "Validate tables and materialized views" was not selected. This has been fixed. ===============(Release Build - Engineering Case #547593)=============== When in the Maintenance Plan wizard, if the checkbox for "Disallow logins while the maintenance plan is running" was checked, then logins would have been disallowed for all databases running on the server. Now, logins are disallowed only for the database in which the maintenance plan is defined. ===============(Release Build - Engineering Case #547385)=============== In rare circumstances, Sybase Central could have crashed when selecting a task in the tasks list. This has been fixed. ===============(Release Build - Engineering Case #547033)=============== Opening the property sheet for a table that had an embedded quote in its name or in its owner's name, would have caused Sybase Central to generate an invalid SQL statement causing an error. This has been fixed. ===============(Release Build - Engineering Case #547035)=============== Attempting to use an UltraLite remote server with the Migrate Database wizard would have caused Sybase Central to crash. This has been fixed. ===============(Release Build - Engineering Case #546038)=============== Sybase Central could occasionally report an internal error when a table header on the "Data" tab was clicked in order to sort the data. This has been fixed. ===============(Release Build - Engineering Case #545760)=============== The SQL tab for a Trigger, View, Procedure or Event could have contained stale SQL, if the object's SQL was modified and saved to the database in a separate window (opened using the "Edit in New Window" menu item). The problem would only have occurred when the object's SQL tab was displayed in the right pane before the object was modified and saved to the database in the separate window, and the object's SQL was modified and saved to the database in the separate window while the object's SQL tab was not displayed in the right pane of the main Sybase Central window. A similar problem would have occurred if a maintenance plan was modified after having shown its corresponding event's SQL tab. The event's SQL tab would have displayed stale SQL. In both cases, pressing F5 to refresh Sybase Central would have show the object's up-to-date SQL. Pressing F5 is now no longer necessary, as Sybase Central has been corrected to keep such objects' SQL up-to-date. ===============(Release Build - Engineering Case #545646)=============== Creating a new connection profile by copying an existing profile, could have resulted in the copy having the wrong plugin type. This has been fixed. ===============(Release Build - Engineering Case #545546)=============== When using the Create Database wizard, if a collation's punctuation sensitivity was changed to a value other than its default, then the wizard would have failed to create the database. This has been fixed. ===============(Release Build - Engineering Case #543491)=============== Sybase Central could have crash while attempting to fetch the messages for a server. This has been fixed. ===============(Release Build - Engineering Case #543943)=============== When using the Table editor to create a column or modify its data type, if the data type was set in the column's property sheet, then extraneous NO INDEX or COMPRESSED clauses could have been added to the CREATE TABLE or ALTER TABLE statement. This has been fixed. ===============(Release Build - Engineering Case #543803)=============== On the "Request Logging" page of a server's property sheet, the drop-down list adjacent to the "All connections to the following database:" radio button would actually have listed connections, not databases. This has been fixed. ===============(Release Build - Engineering Case #543689)=============== Sybase Central could have crashed, if when attempting to change a table's primary key from within the Table Editor the primary key was dropped, but could not be re-created. This has been fixed. ===============(Release Build - Engineering Case #543658)=============== If the property sheet for a column was opened and its comment updated when an index or text index was selected in the tree, then the updated comment would not have appeared in the right pane. This has been fixed. ===============(Release Build - Engineering Case #543254)=============== The value for the "EncryptedPassword" connection parameter was visible in clear text on the "Advanced" page of the "Connect" window. This has been fixed. ===============(Release Build - Engineering Case #543380)=============== Clicking the "Create a synchronization subscription" task for a MobiLink user would have caused nothing to happen. Now, the "Create Synchronization Subscription Wizard" is opened. ===============(Release Build - Engineering Case #543100)=============== The table editor would have allowed marking all columns in a table for deletion. If this was attempted in multiple operations; that is, by selecting some of the columns and pressing the Delete key, and then selecting the remaining columns and pressing the Delete key again. In such cases, attempting to save the table would have failed while attempting to delete the last column in the table. This has been fixed. Now it is no longer possible to mark all columns for deletion. Attempting to do so displays an error message. ===============(Release Build - Engineering Case #542949)=============== Sybase Central would sometimes have failed to populate the All Connected Users tab and failed to graph statistics on the Performance Monitor tab. These problems have been fixed. ===============(Release Build - Engineering Case #534966)=============== Sybase Central did not allow creating, modifying or deleting services for the MobiLink Listener utility (dblsn), the Broadcast Repeater utility (dbns11), and the SQL Anywhere Volume Shadow Copy Service (dbvss11). Attempting to open the properties for one of these types of services would have caused Sybase Central to crash. These problems have been fixed. ===============(Release Build - Engineering Case #540984)=============== The Connection page of the property sheets for publications, MobiLink users and synchronization subscriptions, would have ignored an object's CommunicationType setting and would always have selected the TCP/IP radio button. This has been fixed. ===============(Release Build - Engineering Case #540729)=============== Attempting to cancel the Migrate Database wizard would have caused Sybase Central to crash. This has been fixed. ===============(Release Build - Engineering Case #540725)=============== The Migrate Database wizard could have failed to display messages in the messages dialog if it was connected to two or more databases running on the same server. The wizard was listening for asynchronous messages on the wrong connection. This has been fixed. ===============(Release Build - Engineering Case #539756)=============== On systems other than Windows, the Database Documentation wizard would have displayed the generated HTML files in a poorly formatted way. There was nothing wrong with the HTML files, it was just that the component used to display them was inadequate. This has been corrected so that the wizard now attempts to find an installed web browser and uses that to display the files instead. Note, users can always view the documentation using whatever browser they choose, as a work around to this issue. There was nothing wrong with the HTML files. It was just that the component used to display them was inadequate. Users can always view the documentation using whatever browser they choose to work around this issue. ===============(Release Build - Engineering Case #538931)=============== The Create Service Wizard would have provided default paths for 32-bit executables when 64-bit executables were available on a 64-bit version of Windows. This has been corrected so that default paths for 64-bit executables are now provided if they are available; otherwise, default paths for 32-bit executables are provided. ===============(Release Build - Engineering Case #538920)=============== The Database Documentation wizard would have reported an unhelpful error message when a user, which was not a member of the SYS group, logged in . The wizard used a number of queries which referenced system tables without the appropritate creator qualifier. This has been fixed. ===============(Release Build - Engineering Case #538863)=============== The Database Documentation Wizard could have crashed Sybase Central if it ran out of memory. A number of changes have been made to reduce the amount of memory needed to generate documentation, so that it now reports an out-of-memory error and leaves the program in a state where it can safely continue working. ===============(Release Build - Engineering Case #537558)=============== A side effect of the combined fixes for Engineering cases 533936 and 536335 was to cause Sybase Central to crash when attempting to expand the table tree view in the MobiLink plugin. This problem has now been fixed. ===============(Release Build - Engineering Case #537575)=============== Sybase Central would have crashed if it was connected to the utility database and then connected to another database running on the same server. This has been fixed. ===============(Release Build - Engineering Case #535817)=============== Sybase Central was not able to attach to a tracing db when the server was set to ignore all broadcasts (-sb 0), and no PORT number was specified. This has been fixed. Note, this is a follow-up to Engineering case 530790. ===============(Release Build - Engineering Case #534774)=============== Non-disabled materialized views were described as having a status of "Valid". Now, the correct term "Enabled" is used, and the term "Valid" is used only for non-materialized views. ===============(Release Build - Engineering Case #534292)=============== When run on non-Windows platforms, the Server Message Store wizard would have crashed after leaving the second page. This has been fixed. In related issues, the toolbar button for opening this wizard was missing, and the "Create a client message store" item should have been removed from the Task list on non-Windows machines, but was not. These have been fixed as well. ===============(Release Build - Engineering Case #533830)=============== If at some point during the current session the Views folder, or a materialized view in the tree, was selected then Sybase Central could have caused shared locks to be held on all manual, valid, non-initialized materialized views. These locks would have prevented the refreshing of any such materialized view via another connection, for example from an ISQL session. This has been fixed. ===============(Release Build - Engineering Case #532636)=============== The list of statistics displayed on a version 10 or later server's Statistics tab was incomplete; specifically, it excluded statistics introduced in version 10. This has been fixed. ===============(Release Build - Engineering Case #532807)=============== The Server Message Store wizard could have failed to complete with the message "Could not install QAnywhere support. Request to start/stop database denied". This would have occurred if a server was already running and it was not started with the "-gd DBA" or "-gd all" command line options, and "Create an ODBC data source" was checked in the wizard. This has now been fixed. ===============(Release Build - Engineering Case #531716)=============== The HTML files created by the "Generate Database Documentation" feature of the plug-in would have contained titles that Internet Explorer 7 could not display if Sybase Central was running on a non-English machine. This has been fixed. Note, this problem did not affect Internet Explorer 6 or Firefox 2.0.0. ===============(Release Build - Engineering Case #530587)=============== When viewing the server messages from the SQL Anywhere Console utility (dbconsole0 or from the Sybase Central, there was a possibility that messages could have been duplicated or lost. This has been fixed. ===============(Release Build - Engineering Case #530790)=============== When running the Application Wizard, Sybase Central would have failed to connect to the tracing database if the server had been started with broadcast ignored (-sb 0). This has been corrected. Sybase Central now will include the machine name and port in the connection string when attaching to the tracing database. ===============(Release Build - Engineering Case #529855)=============== Sybase Central would have crashed with a NullPointerException if a message's property sheet was opened and the message had properties with null values. This has been fixed. ===============(Release Build - Engineering Case #529826)=============== The user count in the overview database diagram could have been incorrect. This has been fixed. SQL Anywhere Server - Utilities ===============(Release Build - Engineering Case #553719)=============== The Unload utility (dbunload) was not able to rebuild a pre-Version 10 database if the variable SATMP was unset, but variable ASTMP was set. Dbunload would have returned a connection error in this case. This has been fixed. Note, as workaround the SATMP variable can be set. ===============(Release Build - Engineering Case #552501)=============== The Export wizard could have crashed when exporting to ASE, using the ASE Organic ODBC driver, into a new table. This has been fixed. ===============(Release Build - Engineering Case #552493)=============== When rebuilding databases on Windows Mobile devices, the Unload utility (dbunload) could have failed with the error "Table SYSPROCP not found". If the unload was successful, reloading the new database by running the resulting reload.sql file with the Script Execution utility (dbrunsql) could have failed with the error "Cursor not open" when executing a call statement. Both of these problem have now been corrected. ===============(Release Build - Engineering Case #552473)=============== When attempting to export results to an Oracle database using the iAnywhere Oracle ODBC driver, the Export wizard would have inappropriately prompted for a database name and then reported a NullPointerException when the "Next" button was clicked. This has been fixed. The "Database" combobox is no longer displayed in this case. ===============(Release Build - Engineering Case #552454)=============== The Import Wizard would have shown an empty combobox of databases when importing from an Oracle database. Clicking on the combobox would have caused the Interactive SQL utility to report a NullPointerException. This has been fixed. The combobox is now hidden in this case. ===============(Release Build - Engineering Case #547254)=============== The Interactive SQL utility (dbisql) could have reported an internal error if the "Run Script" menu item was used to execute a script file that caused dbisql to close. This has been fixed. ===============(Release Build - Engineering Case #541310)=============== If dbunload was used to attempt reloading a version 9 or earlier database that needed recovery, the dbunload support engine would have failed an assert and shut down. The assert failure has been fixed, but pre-version 10 databases needing recovery still cannot be reloaded with dbunload. If such a reload is attempted, dbunload will now display the error message "Failed to autostart server". The database will need to be started using using a pre-10 server, and if it then recovers successfully, it can be reloaded after the pre-10 server is shut down. ===============(Release Build - Engineering Case #546439)=============== The Interactive SQL utility would have reported an internal error if the OUTPUT statement operated on a result set that contained a UNIQUEIDENTIFIER column. This has been fixed. ===============(Release Build - Engineering Case #545902)=============== If The Interactive SQL utility (dbisql) could not load the DBLIB library it would have crashed, rather than reporting the problem and degrading gracefully. This has been fixed. ===============(Release Build - Engineering Case #545641)=============== The Interactive SQL utility (dbisql) could have crashed if the Query Editor window was open and the database connection was lost. This has been fixed. ===============(Release Build - Engineering Case #545627)=============== Clicking the "File/Run Script" menu item to run a script file could have caused the Interactive SQL utility to crash with an "Out of memory" error. This has been fixed so that a more ordinary error message is displayed, and running the script is gracefully aborted. This problem could have occurred when the script was very large (thousands of lines) and especially if it contained unclosed block statements. ===============(Release Build - Engineering Case #545543)=============== Unloading and reloading a 9.0.2 db could have failed with a 'capability not found' error if the 9.0.2 db had remote servers defined and contains capabilities that do not exist in later versions. This problem has now been fixed. The unload/reload scripts now check for the existence of each capability in SYSCAPABILITYNAME prior to issuing the ALTER SERVER ... CAPABILITY statement. ===============(Release Build - Engineering Case #545454)=============== The Interactive SQL utility (dbisql) could have crashed if the iAnywhere JDBC-ODBC driver was not installed correctly. This has been changed so that dbisql gives an error message instead. ===============(Release Build - Engineering Case #545251)=============== The MobiLink Listener (dblsn), with IP tracking off (-ni) or default UDP listening off (-nu), may have shutdown unexpectedly after the first notification. This problem was introduced by the changes made for Engineering case 535235. This has now fixed. ===============(Release Build - Engineering Case #544101)=============== The initial width of the "Plan Viewer" window could have been too narrow to display all of its contents. As a result, the "Get Plan" button could have been hidden. This has been fixed. ===============(Release Build - Engineering Case #463887)=============== Deployment Wizard installs containing ADO.Net components would have failed without a good error message when trying to register the .Net components on a system with no .Net framework installed. This has been fixed so that the install now checks for the framework if it is required, and issues a warning. ===============(Release Build - Engineering Case #544614)=============== Pressing the F2 key while inserting or updating a row in the "Results" pane table, would have resulted in an internal error. This has been fixed by ignoring the F2 key if editing mode is already entered. ===============(Release Build - Engineering Case #544612)=============== If a row was inserted into a database table using the table in the "Results" panel, and the table contained a non-nullable TIME, DATE, or TIMESTAMP column, the column was initially filled with the current time or date in a format that was not necessarily parsable by the database. This has been fixed. ===============(Release Build - Engineering Case #542967)=============== If the Unload utility (dbunload) was used to unload an existing database with comments on text indexes or text configurations, the comments were not unloaded. This has been fixed. ===============(Release Build - Engineering Case #541053)=============== A query containing an EXITS() predicate and returning distinct rows may have generated an incorrect result set. For this to have occurred the EXISTS predicate must have been able to be flattened into the main query block, and a KEYSET root must have been used for the query. The incorrect result set may contain duplicate rows. This problem has now been fixed. ===============(Release Build - Engineering Case #539085)=============== A number of changes have been made to improve the performance of the Interactive SQL utility over networks with high latency. All the changes are related to minimizing the number of server requests. ===============(Release Build - Engineering Case #543367)=============== Clicking the "Options" button in the Query Editor window did not automatically select the "Query Editor" tab in the "Options" window as it did in previous versions of Interactive SQL. This has been corrected. ===============(Release Build - Engineering Case #543248)=============== If a comment was created for a primary key, the comment would not have been unloaded by the Unload utility (dbunload). This has been fixed. ===============(Release Build - Engineering Case #543231)=============== The OK button on the "Connect" dialog could have failed to do anything if all of the following were true: 1. The "Fast launcher" option was enabled 2. The "Connect" window was opened and left open in one DBISQL window 3. A "Connect" window was opened and closed from another DBISQL window This has been fixed. To workaround the problem, close the "Connect" window and reopen it. ===============(Release Build - Engineering Case #543135)=============== When the Interactive SQL utility (dbisql) was started with the -q "Suppress non-critical messages" command line option, it did not suppressing the following warnings: - "Interactive SQL is currently configured to quit if a SQL statement fails to execute" - "You are connected to an database which is not explicitly supported" - "ODBC tracing is currently enabled" This has been corrected and these warnings are now suppressed when "-q" is used. ===============(Release Build - Engineering Case #543011)=============== If the Windows desktop was used to associate ".sql" files with the Interactive SQL utility (dbisql), double-clicking a ".sql" file would probably not have launched dbisql. This has been fixed so that now it does, as long as the desktop was told to open the file with "dbisql.exe" (i.e. NOT "dbisql.com"). Before this change, the only reliable way to associate .SQL files with dbisql was to use the "Make Interactive SQL the default editor..." check box in the "Options" window. ===============(Release Build - Engineering Case #542656)=============== When run on Windows Vista systems, selecting "Make Interactive SQL the default editor for .SQL files and plan files" in the "Options" dialog, did not make Interactive SQL the default editor. This has been fixed. ===============(Release Build - Engineering Case #542622)=============== If a database contained userids which had been assigned non-default login policies, running the Extraction utility (dbxtract) would have generated a reload script containing references to those users, even though some of them might not be defined in the extracted database. This has been fixed. ===============(Release Build - Engineering Case #542199)=============== Attepting to start the Interactive SQL utility (dbisql), or any of the other Java administration tools, may have failed with a error that it could not load MSVCR71.DLL. This occurred if the machine does not already have MSVCR7.DLL in the path. This has been fixed. ===============(Release Build - Engineering Case #541736)=============== Under some rare, timing-dependent circumstances, the Interactive SQL utility (dbisql) could have crashed after closing one of the windows used to view long result values. This has been fixed. ===============(Release Build - Engineering Case #541188)=============== When run on Unix systems, the Interactive SQL utility (dbisqlc) would have crashed opening the Options->Configure menu. This has been fixed. ===============(Release Build - Engineering Case #540826)=============== The window which showed long binary column values would have shown incomplete (truncated) data and a corrupt image if the column held a graphic and the result set did not contain the table's primary key. Now, instead of showing partial data, an error message is displayed which advises users on how to remedy the problem. A similar problem affected the display of long text values, and it has also been fixed. ===============(Release Build - Engineering Case #541335)=============== Windows that display long text result values did not consistently warn that only a portion of the value was being displayed. Specifically, if the value was longer than 65536 characters, but the maximum trunction length was set even higher, no warning was displayed. This has been fixed. ===============(Release Build - Engineering Case #541173)=============== The following problems with GIF files have been fixed in the window used to display binary column values: 1. When inserting a GIF file into a binary column, a thumbnail is now displayed. Previously, the thumbnail remained empty. 2. The image format and dimensions were not displayed when viewing a binary column value which contained a GIF image. ===============(Release Build - Engineering Case #540823)=============== If a case-sensitive database was created prior to version 10 and was initialized with collation 857TRK, the Unload utility (dbunload) would have failed to unload it correctly. This has been fixed. ===============(Release Build - Engineering Case #540800)=============== The Interactive SQL utility (dbisqlc) could have incorrectly reported a syntax error when executing an INPUT statement if the user or table name required quoting to be a valid identifier. This has been fixed. ===============(Release Build - Engineering Case #540797)=============== Printing results in landscape orientation did not use the full page area. The print attribute which specified the page margins did not reverse the printing area width and height when printing in landscape. This has been corrected. ===============(Release Build - Engineering Case #540092)=============== The Interactive SQL utility could have crashed if a DESCRIBE statement was executed together with an OUTPUT statement that immediately followed it. This has been fixed. ===============(Release Build - Engineering Case #539637)=============== The Check for Updates feature in the Interactive SQL utility (as well as all the graphical administration tools) would always have returned "Unable to contact update server". This has been fixed. ===============(Release Build - Engineering Case #539356)=============== The Interactive SQL utility (as well as all the graphical administration tools) did not work with authenticated servers. This has been corrected. ===============(Release Build - Engineering Case #538912)=============== Right-clicking on a result set, then selecting the item "Copy/Copy Cell" from the menu, would only have copied the cell value if the cell had previously been left-clicked. This has been corrected so that left-clicking is no longer necessary. ===============(Release Build - Engineering Case #538099)=============== Attempting to copy a large number of values in the "Results" pane could have caused Interactive SQL (dbisql) to crash. This has been foxed so that an error message is now displayed and the copy is aborted. ===============(Release Build - Engineering Case #536543)=============== During diagnostic tracing, CONNECT and DISCONNECT request, as well as other information, could have been missing for a connection. DISCONNECT request were missing for some user connections, and CONNECT request and all statistics were missing for internal connections. This has been fixed. As well, some internal connections will be logged with both CONNECT and DISCONNECT requests, while others will not be displayed. ===============(Release Build - Engineering Case #537170)=============== The Interactive SQL utility (dbisql) would have crashed when the Plan Viewer window was oipened if the SQL Anywhere plugin was not registered. This has been fixed. ===============(Release Build - Engineering Case #536130)=============== The OUTPUT statement would have written VARBINARY values to TEXT files incorrectly. This has been fixed. ===============(Release Build - Engineering Case #534156)=============== If the 'datasource', 'host', or 'port' command line options were used, dbisql would not have started, but would not have reported an error. This has been corrected so that these options are now accepted and processed correctly. ===============(Release Build - Engineering Case #454612)=============== When a database containing tables with autoincrement columns was rebuilt, the default and historical behavior was for the server to calculate the next available value for each of these columns based on the current contents of the tables. In most cases, this iwa sufficient; however, if rows had been deleted from the "end" of the range of values, this would have resulted in values being re-used, which in some cases was not desirable. To force the current value of SYSTABCOL.max_identity to be preserved across a database rebuild, the Unload utility's (dbunload) "-l" option can be used. This will cause calls to sa_reset_identity() to be added to the generated reload.sql script for each table containing an autoincrement value. ===============(Release Build - Engineering Case #534003)=============== In graphical plans, the operator for a table accessed using an index-only scan was drawn as a table-scan operator, not as an index-scan operator. This has been fixed. ===============(Release Build - Engineering Case #533994)=============== The "Messages" tab could have remained selected after executing a statement which returned result sets. This has been corrected so that the first result set tab is now always selected. ===============(Release Build - Engineering Case #532450)=============== It was possible for execution of an OUTPUT statement to cause the statement, which generated the previous results, to be reexecuted unnecessarily. Reexecution of the statement could have resulted in poor performance, or error messages if the statement could not be reexecuted (for example, because it was a stored procedure call with side-effects). This has now been fixed. ===============(Release Build - Engineering Case #531768)=============== UltraLite appeared in the list of databases to which the Interactive SQL utility could connect on Solaris and OS/X machines. UltraLite is not supported on either of these platforms, and so UltraLite databases have been removed from the user interface on these platforms. ===============(Release Build - Engineering Case #531577)=============== When editing an unsigned column value, if a value larger than the largest signed value was entered, zero would have been incorrectly saved as the column value. This has been fixed so that the value entered is now saved. ===============(Release Build - Engineering Case #531523)=============== Cancelling a statement could have taken several seconds if the statement returned more than 500K of data as text, and it was configured to display results as text. This has been fixed. ===============(Release Build - Engineering Case #531314)=============== Double-clicking a .SAPLAN file on a Windows machine did not always work properly. The new "Plan Viewer" window was not automatically activated. If the "Fast launcher" option was on, the wrong plan file could have been opened under some circumstances. Both of these problems have been fixed. ===============(Release Build - Engineering Case #530930)=============== The bold title text that appears on the "Advanced" page of the "Connect" window was not displayed consistently. Specifically, the text (e.g. "AppInfo [APP]") would not have been displayed if the Connect Assistant was not initially visible when the "Connect" window was opened, and was then made visible before the "Advanced" page was initially selected. This has now been fixed, as well as a fix for an intermittent problem that caused the description field at the bottom of the "Advanced" page from being too short to display more than one line. ===============(Release Build - Engineering Case #530597)=============== The option to continue executing statements after encountering an error with an Interactive SQL statement (such as INPUT, OUTPUT, READ, PARAMETERS, DESCRIBE) was not given. Now it is. This problem did not affect normal SQL statements. ===============(Release Build - Engineering Case #530539)=============== Pressing ALT+I in the "Add to Favorites" dialog did not set the focus to the list of favorites folders. This has been corrected so that now it does. ===============(Release Build - Engineering Case #530533)=============== The detailed results from the "Test Connection" tool in the "Connect" dialog could have contained corrupt characters when running on Windows systems. This would have occured when the language for non-Unicode programs (i.e. the "system locale") was set to something other than English (e.g. Japanese), and the machine's location was set to a country which in which English is spoken (e.g. United States). The non-English characters were corrupted. This has been fixed. ===============(Release Build - Engineering Case #530427)=============== The table selection page of the Export wizard contained two controls with the same mnemonic ('e'). This has been fixed. ===============(Release Build - Engineering Case #530309)=============== the component that displayed an explanation of the selected connection parameter on the "Advanced" page of the "Connect" dialog, was unreasonably short on Japanese systems. This has been fixed. ===============(Release Build - Engineering Case #499958)=============== Pasting more than a couple of million characters into dbisql could have caused the editor to become unresponsive, and eventually report an out of memory error. This has been fixed so that a check is now done to determine if there is enough memory to insert the text and display an error message if there is not. SQL Remote for Adaptive Server Anywhere - SQL Remote Message Agent ===============(Release Build - Engineering Case #479191)=============== When SQL Remote was scanning the active transaction to determine which operations to send, it was possible for the process to have crashed when it had reached the end of the active transaction log. This has been fixed. Sybase Central Java Viewer - Java Viewer ===============(Release Build - Engineering Case #550096)=============== Attempting to open the Column property sheet for a column with a system-defined default value of the form "global autoincrement(n)", where n is one or more decimal digits, would have caused Sybase Central to crash. This has been fixed. UltraLite - HotSync Conduit ===============(Release Build - Engineering Case #536374)=============== HotSync may have logged a -305 error for a synchronization failure, and potentially other database corruption. This has been fixed. UltraLite - Runtime Libraries ===============(Release Build - Engineering Case #555989)=============== It was possible that the last download timestamp for one or more publications would not have been updated after receiving and applying the download from the server. This has been fixed. ===============(Release Build - Engineering Case #547234)=============== When the UltraLite SQL functions length() and char_length() were used on LONG VARCHAR columns, the results were incorrectly the lengths of the strings in bytes, rather than characters. Note that some characters require multiple bytes internally. The function byte_length() is used to determine the length in bytes of the string. This has been fixed. ===============(Release Build - Engineering Case #495369)=============== The performance of some queries has degraded from what it was in version 9. Further optimizations have been added so that the performance has been restored. ===============(Release Build - Engineering Case #535591)=============== An error would have been reported if a string of connection, or synchronization, parameters used parentheses inside a sublist. For example: stream=http(host=myhost;url_suffix=root/(MyName)/ml;port=80) This has now been fixed. ===============(Release Build - Engineering Case #532846)=============== Columns with data types of LONG BINARY or LONG VARCHAR were not stored correctly during a synchronization download. This has now been corrected. UltraLite - UL Java Provider for Sybase Central ===============(Release Build - Engineering Case #546330)=============== In the UltraLite plug-in, it is possible to view the data of a table by choosing the table in the left pane, and clicking on the “Data” tab in the right pane. When this was done though, subsequent attempts to change the schema of the database could have failed with the error “A schema upgrade is not currently allowed”. A result set created when viewing the data was not explicitly closed. This has been fixed. ===============(Release Build - Engineering Case #496281)=============== The ml_remote_id option would have incorrectly been set to the string value 'null' when reset using the UltraLite plugin. This has been fixed. ===============(Release Build - Engineering Case #533270)=============== The default Precision and Scale values for an UltraLite database are 30, 6 respectively. When creating a table using the plug-in for Sybase Central, these values were used as defaults for numeric columns, even when the database’s default Precision and Scale values were different. This has been fixed. ===============(Release Build - Engineering Case #533264)=============== Synchronization profiles were incorrectly appearing in the Extended Database Properties tab of an UltraLite database’s property sheet. This has been corrected. UltraLite - UltraLite Engine ===============(Release Build - Engineering Case #556292)=============== Output host variables for SQL statements would not have been updated when using the UltraLite engine if a warning had been triggered. This has been fixed. ===============(Release Build - Engineering Case #538324)=============== Attempting to create a table with a varchar(36) column with a default of newid() would have failed with a syntax error. The column could have been later altered to add the newid() default, but the generated default values would have been garbage. These two bugs have now been fixed. ===============(Release Build - Engineering Case #540390)=============== A comparison between an integer and a BINARY value (in a SQL statement) would have caused a conversion error, 'Cannot convert numeric to a binary'. This has been corrected. ===============(Release Build - Engineering Case #532638)=============== Incorrect results may have been obtained from queries when there was a LIKE search condition combined with an ORDER BY ... DESC clause, when both of these clauses specified a column that was the first column in an index. For example: SELECT * FROM MyTable WHERE col LIKE 'abc%' ORDER BY col DESC The implementation of LIKE predicates with reversed index scans was erroneous. This has now been corrected. UltraLite - UltraLite.NET ===============(Release Build - Engineering Case #533729)=============== The 64-bit version of the UltraLite .NET component could have throw an "Unknown ULDbType" exception when opening a table. This has been fixed. UltraLite - Utilities ===============(Release Build - Engineering Case #541739)=============== When deploying a synchronization model for an UltraLite remote database to a SQL file, then using Interactive SQL to run the SQL file, errors could have occurred for DROP statements if the object did not exist, or CREATE statements if the object already existed. A user would have had to choose to ignore these errors. This has been fixed. Now, the generated SQL file uses Interactive SQL options to suppress errors that can be ignored. ===============(Release Build - Engineering Case #540349)=============== The UltraLite Initialize Database utility (ulinit) would have reported a syntax error if the reference database contained a foreign key on a table with the keyword 'name'. Ulinit was failing to quote the table name in the foreign key statement generator. This has been fixed. ===============(Release Build - Engineering Case #535586)=============== If an index was defined in the reference database as: create index idx on t(a asc, b asc, c asc) The UltraLite Initialize Database utility (ulinit) would have created the index as: create index idx on t(c asc, b asc, a asc). reversing the order of the columns. This has been corrected and ulinit will now create the index in the same order as the reference database. UltraLiteJ - Runtime ===============(Release Build - Engineering Case #553775)=============== While synchronizing a large download using "direct TCP" on BlackBerry devices (not through the BES), the synchronization would have failed with "... Max connections opened". This has been fixed. Note: For IDENT BlackBerry devices, the default is Direct TCP connections. For non-IDENT BlackBerry devices, the default is BES connections. Using the URL suffix ";deviceside=false" forces Direct TCP connections. ===============(Release Build - Engineering Case #552293)=============== Execution of a query with a left outer join could have caused database corruption when the null-supplying table supplied a null row, and that table was subsequently updated. This has now been corrected. ===============(Release Build - Engineering Case #540354)=============== UltraLiteJ could have thrown an ArrayIndexOutOfBounds exception during sync if a column in the consolidated could have stored more characters than the remote column. For this fix to be effective mlodbc11.dll must be 11.0.0.1541 or later. ===============(Release Build - Engineering Case #550525)=============== If a communication error occurred during the last few bytes of the upload, or first few bytes of the download, UltraLiteJ would have assumed that the upload failed and revert the progress for it. In this scenario, MobiLink may have actually accepted the upload and thus its progress offsets would conflict with the client. This has been fixed. ===============(Release Build - Engineering Case #548981)=============== The pages allocated for temporary tables was not being recovered after an abnormal shutdown. This has been corrected. ===============(Release Build - Engineering Case #548173)=============== Repeated update synchronizations, that is where existing client rows are updated, could have caused unnecessary database growth. A row storage problem has now been corrected. ===============(Release Build - Engineering Case #545105)=============== The DatabaseInfo methods getDbFormat and getRelease, would have returned incorrect values. Additionally, getRelease now returns a String which reflects both the release version and the build number. ===============(Release Build - Engineering Case #545000)=============== SELECT DISTINCT with more than 16 select-list items would have caused an exception to be thrown. A DISTINCT optimization should have tested that there were 16 or fewer select-list items and failed when that was not so. The omitted test has now been added. ===============(Release Build - Engineering Case #544689)=============== All database pages for a table may not have been freed when the table was dropped. This has now been fixed. ===============(Release Build - Engineering Case #544525)=============== If a publication that had been previous used in a synchronization was dropped, the next publication created would not have been able to synchronize due to a progress offset error from MobiLink. This has been fixed. ===============(Release Build - Engineering Case #544350)=============== A user could have dropped a publication whose upload was in an unknown state. For example, the synchronization failed due to a communication error before the upload acknowledgement was received from MobiLink. Dropping a publication whose upload status is unknown could result in lost upload data or duplicate uploads. This has been fixed. Attempting to drop a publication in such a state will now result in a SQLE_SYNC_STATUS_UNKNOWN error. ===============(Release Build - Engineering Case #541439)=============== Certain SQL statements would have returned null after being prepared. This has been corrected. ===============(Release Build - Engineering Case #543375)=============== Failure of a statement which was partially executed and involved either clobs or blobs, could have caused unneccessary database growth. Blobs and clobs were not being correctly discarded following statement failure. This has been corrected. ===============(Release Build - Engineering Case #543548)=============== The version number built into the UltraLiteJ.jad file for RIM BlackBerry deployment would sometimes have been incorrecting generated. This has been fixed. ===============(Release Build - Engineering Case #542768)=============== Incorrect parameters to the system functions LEFT(), RIGHT() and INSERTSTR() could have caused a Java exception. This has been fixed. ===============(Release Build - Engineering Case #542763)=============== UltraLite databases could have grown unnecessarily when blobs and clobs were updated. Pages from blobs/clobs on deleted rows were not bing properly released. This has been corrected. ===============(Release Build - Engineering Case #542213)=============== Executing queries with temporary tables may have caused the database to grow unbounded. Row pages and schema pages were not bing properly released for temoporary tables. This has been corrected. ===============(Release Build - Engineering Case #543552)=============== In a scenario where a table had a large number of initial inserts followed by a large number of deletes, inserts or updates, where the number of deletes that had taken place were always greater than the number of inserts, the database may have become corrupted. These operations may have occur via program initiated operations, or via synchronization operations. This has been fixed. Existing databases that have not yet been corrupted will be fixed when the UltraLiteJ library is updated. ===============(Release Build - Engineering Case #541062)=============== If an UltraLiteJ synchronization had failed, the next synchronization could have sent the wrong set of last download times. This has been fixed. ===============(Release Build - Engineering Case #540579)=============== Attempting to connect to a partially constructed RIM BlackBerry database could have caused a NULL POINTER exception. It was assumed that an existing RIM BlackBerry database would contain a page[0]. This situation now causes an UltraLiteJ exception to be thrown. ===============(Release Build - Engineering Case #540388)=============== UltraLite databases restrict the ORDER BY clause, when used with UNION, to referencing select list items by ordinal value rather than by name. Violations of this restriction was not diagnosed correctly in some situations. UltraLiteJ has been corrected to now issue the exception SQLE_INVALID_ORDER, to be consistent with other versions of UltraLite. ===============(Release Build - Engineering Case #540275)=============== Incorrect results would have been obtained when evaluating expressions with hexadecimal constants that were larger than integer values. This has been fixed. ===============(Release Build - Engineering Case #540263)=============== An UltraLiteJ database may have expanded needlessly, especially in the presence of updates, either via SQL statements or synchronizations. The routine to search free space on an existing page was not always recognizing when there was room to contain a row. This has been corrected. ===============(Release Build - Engineering Case #539358)=============== Multiple ORDER BY expressions could have caused an exception when there existed an index with fewer columns than the number of ORDER BY expressions. This has been fixed. ===============(Release Build - Engineering Case #539128)=============== If an UltraLiteJ database had a publication defined that contained only some of the synchronizable tables, and that publication was synchronized, any changes waiting to be uploaded in the tables that were not yet sync'ed would have been lost. They would still have been in the database, but would have been marked as having been uploaded. Also, UltraLiteJ was incorrectly identifying to MobiLink that tables being synchronized were in all publications currently sync'ed and UltraLiteJ was incorrectly sending the last download time of publications. Both of these problems have been fixed. ===============(Release Build - Engineering Case #539257)=============== If an UltrLiteJ synchronization failed, an error complaining about a dropped connection would sometimes have been printed to the log. This has been fixed. ===============(Release Build - Engineering Case #538743)=============== When attempting to use a MobiLink Java Start class that made use of UltraLiteJ, an error similar to "<Main> [-10150] Linkage error while loading class: 'jdbssint' Error description: 'ianywhere/ultralitej/Configuration'" would have occurred, and the server would have failed to start. The problem was due to class name conflicts, which have been corrected. ===============(Release Build - Engineering Case #538700)=============== UltraLiteJ did not work with cookie injecting proxy servers, such as the Relay Server. This has been fixed. Note that on the BlackBerry, the MDS may cache cookies for the devices that go through it, and so UltraLiteJs cookie behaviour may be different from other remotes. In particular, cookies sent to the remote may be cached for longer than the duration of a sync. When using a proxy other than the Relay Server, ensure that the optional cookie fields, defined in RFCs 2109 and 2965 dealing with cookie caching, are properly set, or disable this feature in your MDS. The Relay Server is unaffected by this caching, but other cookie injecting proxies may be affected by it. ===============(Release Build - Engineering Case #534837)=============== Predicates with AND, OR and NOT expressions along with UNKNOWN could have produced incorrect results. This has now been corrected. ===============(Release Build - Engineering Case #534586)=============== Information about column defaults was not being reloaded on subsequent connections after the default information was created. This resulted in column defaults not being automatically generated for NULL columns on INSERTS. Loading of the additional field has now been implemented. ===============(Release Build - Engineering Case #534402)=============== Incorrect results were possible when executing queries with a LEFT OUTER JOIN and a WHERE clause whose elements are all from the left hand side of the join. This has been corrected. ===============(Release Build - Engineering Case #534404)=============== The comparison of two NULL values would have erroneously resulted in TRUE, instead of UNKNOWN. This has now been corrected. ===============(Release Build - Engineering Case #533327)=============== Certain illegal column domains were not being diagnosed, such as VARCHAR(-1). This has been corrected. UltraLiteJ - Utilities ===============(Release Build - Engineering Case #551589)=============== The batch file uljdbtserv.cmd did not work when SQL Anywhere was installed in a path that contained spaces. It also relied on environment variables other than SQLANY11. These problems have now been fixed.