SQL Anywhere Bug Fix Readme for Version 11.0.1, build 3158



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

Contents



Description of download types

Bug Fixes

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

Minor 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



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

================(Build #2524 - Engineering Case #648497)================ When a consolidated was running on an Oracle server, the MobiLink server would not have advanced the next_last_download timestamp value (it is used for generating the download in the next synchronization) after it had run for certain time, even if a synchronization did contain a download request. After this occurred, the MobiLink server would have downloaded the same rows over and over again. This has now been fixed. The work around is to restart the MobiLink server. ================(Build #2156 - Engineering Case #563839)================ The SQL Passthrough feature was originally written as a plugin to the MobiLink server in Java. A number of issues were found, including using extra database connections, which needed to be addressed. The feature has now been re-written as a core part of the MobiLink server, so it no longer requires a Java VM on startup. When SQL Passthrough was being used, ie. when there was at least one row in the the ml_passthrough_script table, the MobiLink server could have used twice the number of consolidated database connections than necessary, (ie. up to twice the -w value). When creating these extra connections, the MobiLink server would, during a synchronization, make another consolidated database connection, perform some work, disconnect that connection, then resume the synchronization. In other words, penalizing each synchronization with the time/cost of connecting and disconnecting to the consolidated database. Besides the performance and database connection penalties, these connects/disconnects could also have made the MobiLink server reach OS socket limits faster, potentially causing failures. Most MobiLink clients (ie. dbmlsync, dbtools sync interface, dbmlsync ActiveX integration component, and all UltraLite runtimes -- except UltraLiteJ, which doesn't support SQL Passthrough) have been updated as part of this fix. This change will cause newer clients to fail if run against an the 11.0.1 GA server. Thus MobiLink clients of version 11.0.1 2156 or later will require a MobiLink server of version 11.0.1 2156 or later.

SQL Anywhere - ODBC Client Library

================(Build #2145 - Engineering Case #558108)================ Calling the function SQLGetTypeInfo() would have returned an incorrect AUTO_UNIQUE_VALUE column value in the result set for non-numeric types. The value return would have been 0, but according to the ODBC specification a NULL should have been returned. ODBC specificatrion for AUTO_UNIQUE_VALUE : Whether the data type is autoincrementing: SQL_TRUE if the data type is autoincrementing. SQL_FALSE if the data type is not autoincrementing. NULL is returned if the attribute is not applicable to the data type or the data type is not numeric. The behaviour has been corrected to follow the ODBC specification.

SQL Anywhere - Server

================(Build #2584 - Engineering Case #663991)================ Under some circumstances, queries with cached plans and queries containing complex correlated subqueries may have returned incomplete results if they were executed as parallel plans. This has been fixed. Note, a workaround is to disable intra-query parallelism (set MAX_QUERY_TASKS=1). ================(Build #2509 - Engineering Case #642313)================ Execution of the statement "BACKUP DATABASE DIRECTORY '' TRANSACTION LOG RENAME TRANSACTION LOG ONLY" would have left a gap in the offsets between the renamed transaction log and the live transaction log. This would have affected replication, synchronization and the ability to recover from backups. This has been fixed. ================(Build #2272 - Engineering Case #580735)================ In rare circumstances, transaction log corruption could have occurred, or the server could have haved assertion 100918 ('Invalid redo log page header'), shortly after restarting a database. The probability of this happening on any given database restart was approximately 1/pagesize (ie. for 4K pages, the probability is approximately 0.0002). The corruption was likely to go undetected, and the assertion was unlikely to fire in most cases. However, sites using Mobilink or SQL Remote would have been alerted to the presence of such corruption by errors occurring during synchronization. This has now been fixed.



11.0.1 New Features

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


MobiLink - Java Plugin for Sybase Central

================(Build #2189 - Engineering Case #566207)================ The QAnywhere plug-in for Sybase Central now supports the connection retry command line options for the Agent (see Engineering case 561067).

MobiLink - QAnywhere client

================(Build #2604 - Engineering Case #668833)================ The dbmlsyc command line option -qi prevents the tray icon or window from being displayed. This behaviour is identical to the -qi option of the database server. The option has existed since 11.0.1, but was not referenced in the usage text or the documentation. The usage text has been corrected ================(Build #2184 - Engineering Case #561122)================ The .NET QAManagerBase class now supports ExceptionListener delegates, which allows for applications to be notified of QAExceptions that occur while receiving messages on the background thread. The following are the relevant APIs: /// <summary> /// ExceptionListener delegate definition. /// </summary> /// <param name="ex">The exception that occurred.</param> /// <param name="msg">The message that was received, or null if the message /// could not be constructed.</param> public delegate void ExceptionListener( QAException ex, QAMessage msg ); /// <summary> /// Sets an <see cref="ExceptionListener"/> delegate to receive QAExceptions /// when processing QAnywhere messages asynchronously. /// </summary> /// <param name="address">The address of messages.</param> /// <param name="listener">The exception listener to register.</param> public void SetExceptionListener( string address, ExceptionListener listener ); In 10.0.x and later, the .NET and Java QAManagerBase class now supports exception listeners. The .NET and Java QAManagerBase class now supports a property, RECEIVER_INTERVAL, that represents the maximum wait interval (in milliseconds) in the background receiver thread for receiving messages. The default is 60000 milliseconds. As with other QAManager properties, this property must be set before calling an Open() method. The .NET and Java QAManagerBase class now supports a ReOpen() method that can be called in an ExceptionListener or MessageListener to re-establish connections to the message store database. Following is the API description. /// <summary> /// Reopens the QAManagerBase. This re-establishes connections to the message /// store, without releasing any resources. This method may called in a /// message or exception listener, and in that case it is not necessary to /// call Start() again. This method simply executes Close() then Open() if /// not called in a listener, and in that case Start() must be called to /// restart receiving of messages. /// </summary> /// <exception cref="iAnywhere.QAnywhere.Client.QAException"> /// if there is a problem reopening the manager. /// </exception> public void ReOpen(); ================(Build #2167 - Engineering Case #561067)================ The QAnywhere Agent (qaagent) now attempts to reconnect to the message store database when the connection is dropped. Notes: - The initial database connection will be retried a given number of times if the first connection fails - Command line options for connection retries and retry delay: -cr <n> (n is the number of retries to connect after a failure) -cd <n> (n is delay, in seconds, between retries) - The defaults are 3 retries with a 10 second delay between retries - If all retries fail, the QAnywhere Agent displays an error and waits to be shut down - If a database connection fails during operation, the QAnywhere Agent will go through termination steps, including finalizing connections, terminating threads and external processes, and then re-starts.

MobiLink - QAnywhere server

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

MobiLink - Relay Server

================(Build #2724 - Engineering Case #692340)================ Machine and OS information have now been added to the Relay Server Outbound Enabler log. As well, timezone offset information has been added to the Relay Server and the Outbound Enabler logs.

MobiLink - SA Client

================(Build #2410 - Engineering Case #559636)================ MobiLink clients, except UltraLiteJ, now support a new network protocol option on Windows Mobile and desktop, 'network_adapter_name', which allows clients to explicitly specify the name of the network adapter to be used to connect to a MobiLink server. Example: "network_adapter_name=Serial on USB". ================(Build #2352 - Engineering Case #573222)================ Support for FIPS 140-2 certified encryption has now been added to 64-bit Windows for UltraLite (except UltraLiteJ) and MobiLink clients . If the "FIPS-approved Strong Encryption" feature is not already installed, proceed as follows after applying the EBF: - From Add & Remove Programs, select SQL Anywhere 11 and click the Change button. - Select the Add option and enter the Add-on Registration Key and click Next. - In the dialog, ensure that the "FIPS-approved Strong Encryption" feature is selected and proceed. If the "FIPS-approved Strong Encryption" feature is already installed, proceed as follows after applying the EBF: - From Add & Remove Programs, select SQL Anywhere 11 and click the Change button. - Select the Modify option and de-select the "FIPS-approved Strong Encryption" feature, to temporarily remove it, and proceed. - Again from Add & Remove Programs, select SQL Anywhere 11 and click the Change button. - Select the Modify option and select the "FIPS-approved Strong Encryption" feature and proceed. ================(Build #2249 - Engineering Case #571810)================ MobiLink clients (except for UltraLiteJ) now cache the host socket address to avoid extra calls to socket methods, such as getaddrinfo, inet_addr, and gethostbyname, for non-persistent HTTP and HTTPS synchronizations. ================(Build #2241 - Engineering Case #571233)================ When the -pi option 'ping MobiLink server' was used on the MobiLink client (dbmlsync) command line, dbmlsync would have returne an exit code of 0 (indicating success), even if it was unable to contact the Mobilink server. This has been fixed, and a non-zero exit code will now be returned in this case.

MobiLink - Streams

================(Build #2586 - Engineering Case #665140)================ For MobiLink clients that support ECC TLS, support has now been added for RFC 4492 and 256-bit AES ECC cipher suites as well, in addition to the Draft 3 128-bit AES ECC cipher suite they previously supported. ================(Build #2450 - Engineering Case #632359)================ For 11.0.1, ECC curve support for MobiLink end-to-end encryption has been reduced to the same 7 ECC curves supported by the createcert and createkey utilities and by SA's TLS support. For 12.0.0, ECC curve support for end-to-end encryption, the createcert and createkey utilities, and for the TLS protocol for both MobiLink and SA, has been extended to support the 15 curves recommended by NIST: sect163k1 sect283k1 sect571k1 secp256r1 sect163r2 sect283r1 sect571r1 secp384r1 sect233k1 sect409k1 secp192r1 secp521r1 sect233r1 sect409r1 secp224r1 ================(Build #2426 - Engineering Case #626480)================ An extension to the TLS protocol for session renegotiation has been made to fix a recently discovered vulnerability (RFC 5746). Although SQL Anywhere software is not directly vulnerable, third-party servers that it communicates through may be vulnerable. SA clients now support this TLS extension which will allow vulnerable third-party servers to be secured.

MobiLink - Synchronization Server

================(Build #2825 - Engineering Case #706828)================ The MobiLink server now supports bulk upload for sync tables that contain LOBs when the consolidated database is running on an Oracle server. The bulk upload feature would have previously been disabled when a sync table contained LOBs. The number of rows uploaded by each batch is controlled by -s command line option. Note, the iAS ODBC driver for Oracle must be upgraded to the same EBF level as the MobiLink server when the consolidated database is running on an Oracle server and the synchronization tables contain CLOBs or BLOBs. ================(Build #2412 - Engineering Case #623106)================ New http, https and oe stream options have been added to the MobiLink server that will cause it to print additional errors, analogous to the errors printed by the -vf option. Usage: -x http(...;log_bad_request={yes|no}) -x https(...;log_bad_request={yes|no}) -x oe(...;log_bad_request={yes|no}) The default value for these noew options is "no". If log_bad_request is enabled and a request disconnects before the server receives a complete set of HTTP headers, the server will print these errors: [-10117] Stream Error: Failed reading an incomplete HTTP request [-10117] Stream Error: This connection will be abandoned because of previous errors If log_bad_request is enabled and a request contains an unknown User-Agent or unknown request type, the server will print these errors: [-10117] Stream Error: Unknown HTTP User-Agent or request type [-10117] Stream Error: This connection will be abandoned because of previous errors This option is most useful when debugging network issues. For example, you can connect to the ML server using a web browser on the remote device and if the device can reach the server, then these errors will be printed. ================(Build #2375 - Engineering Case #607881)================ The MobiLink server would have reported error -10152 if a Java class loaded for scripting contained overloaded methods, and would have failed with an AmbiguousMatchException if a .NET class contained overloaded methods. This restriction has been lifted. This is most useful for the authenticate_parameters script, as now remotes can send different numbers of authentication parameters and the MobiLink server will choose the method that most closely matches those parameters. For example, suppose a class Test exists: public class Test { public static String auth( InOutInteger status, String user_name, String p1, String p2 ) { return "insert into j_authparm_T2 (pk, c1, c2, c3) values (?,?,?,?)"; } public static String auth( InOutInteger status, String user_name, String p1, String p2, String p3 ) { return "insert into j_authparm_T2 (pk, c1, c2, c3, c4) values (?,?,?,?,?)"; } } Then the auth method can be registered as the script for the authenticate_parameters event: call ml_add_java_connection_script( 'the version', 'authenticate_parameters', 'Test.auth' ) and invoking dbmlsync with different -ap switches will give different behaviour: "-ap parm1,parm2" will call the first 'auth' overload "-ap parm1,parm2,parm3" will call the second 'auth' overload "-ap parm1" will print the error, "[-10362] No overload matching 'auth(ianywhere.ml.script.MLInOutInteger, java.lang.String, java.lang.String)' was found in class 'Test'", because there are not enough parameters to call any of the overloads "-ap parm1,parm2,parm3,parm4" will invoke the second 'auth' overload, but the returned SQL will cause error "[-10094] Expecting 3 authentication parameter(s) from client, but received 4 for script insert into j_authparm_T2 (pk, c1, c2, c3, c4) values (?,?,?,?,?)" because the MobiLink server will accept a Java or .NET authentication_parameters script if it has the same number of parameters or fewer, but SQL authentication_parameters scripts must match the exact number of parameters. Some future version of the server may place that restriction on Java and .NET authentication_parameters scripts as well. ================(Build #2352 - Engineering Case #609449)================ FIPS 140-2 certified encryption is now supported by the MobiLink server on 64-bit (x64) Windows. If the "FIPS-approved Strong Encryption" feature is not already installed, proceed as follows after applying the EBF: - From Add & Remove Programs, select SQL Anywhere 11 and click the Change button. - Select the Add option and enter the Add-on Registration Key and click Next. - In the dialog, ensure that the "FIPS-approved Strong Encryption" feature is selected and proceed. If the "FIPS-approved Strong Encryption" feature is already installed, proceed as follows after applying the EBF: - From Add & Remove Programs, select SQL Anywhere 11 and click the Change button. - Select the Modify option and de-select the "FIPS-approved Strong Encryption" feature, to temporarily remove it, and proceed. - Again from Add & Remove Programs, select SQL Anywhere 11 and click the Change button. - Select the Modify option and select the "FIPS-approved Strong Encryption" feature and proceed. ================(Build #2144 - Engineering Case #558085)================ The MobiLink server now supports two new command options, -vR show the remote ID in each logging message -vU show the ML user name in each logging message When both -vR and -vU are specified, the MobiLink server will add the remote ID and the MobiLink user to each message logged: yyyy-mm-dd hh:mm:ss. <sync_id> ({remote_id},{user_name}) When started with -vR and without -vU, the prefix will be just the remote_id: yyyy-mm-dd hh:mm:ss. <sync_id> (remote_id,) and the MobiLink user name will be empty. When started with -vU and without -vR, the prefix will be just the user name: yyyy-mm-dd hh:mm:ss. <sync_id> (,user_name) and the remote ID will be empty. The new feature may be useful for MobiLink users who are running the MobiLink server with the command options -on or -os, as the logging messages for a synchronization can span multiple MobiLink server logging files, which makes it is hard to find out the remote ID and MobiLink user name for a given sync ID from such logs. This extra logging information will only apply to the synchronization threads. For the main thread of the MobiLink server, the logging messages will still contain the following prefix, yyyy-mm-dd hh:mm:ss. <Main> because there is no remote ID or MobiLink user name for the main thread. These two command line options will not be affected by the -v+ option, that is, the MobiLink server will not add the remote ID or the ML user name into its logging messages, even if the -v+ option is used. Therefore, the description for the -v+ option has been changed to - "show all verbose logging specified with lower case letters".

MobiLink - Utilities

================(Build #2604 - Engineering Case #668832)================ The dblsn command line option -qi prevents the tray icon or window from being displayed. This behaviour is identical to the -qi option of the database server. The option has existed since 11.0.1, but was not referenced in the usage text or the documentation. The usage text has been corrected ================(Build #2586 - Engineering Case #666801)================ The Redirector for Apache on Windows now supports Apache 2.2.15. This newer webserver offers enhanced security. ================(Build #2267 - Engineering Case #580574)================ The Apache Redirector is now available for Apache 2.2 on Linux. The new file is named mod_iaredirect.so, and is located in <install-dir>/mobilink/redirector/apache/v22.

MobiLink - iAS Branded ODBC Drivers

================(Build #2138 - Engineering Case #584322)================ The following new features have been added to the iAnywhere Solutions ODBC driver for Oracle: 1) In order to determine if a stored procedure returns a result set, or if a procedure uses Oracle VARRAYs, the iAnywhere Solutions Oracle ODBC driver needs to describe the stored procedure through Oracle OCI functions. The driver now provides an extra connection parameter, ProcOwner (long form) or POwner (short form), which is used to by tyen driver to describe all the stored procedures invoked by the application. This parameter can be given as followis: -c "uid=...;pwd=...;procowner=my_procedure_owner;..." 2) The iAnywhere Solutions ODBC driver for Oracle now supports VARRAYs used by packaged procedures.

SQL Anywhere - ADO.Net Managed Provider

================(Build #2788 - Engineering Case #703288)================ When using a "managed resource only" deployment (such as Microsoft's ClickOnce) for .NET applications, delivering SQL Anywhere native dlls through this mechanism may have been a problem. A demonstration project DeploymentUtility (with source code) has been added to help with this. It adds SQL Anywhere native dlls as embedded resources, and copies them to a local drive when a .NET application is deployed. ================(Build #2777 - Engineering Case #701776)================ Support has now been added for Visual Studio 2012. The utility SetupVSPackage will now create the proper registry keys for Visual Studio 2012. ================(Build #2771 - Engineering Case #700458)================ Support has now been added to the SQL Anywhere ADO.NET provider for latest release of Microsoft Entity Framework - EF 4.3. The major new feature of EF 4.3 is migration tools which enable the user to keep track of the data model changes. ================(Build #2758 - Engineering Case #689781)================ The ADO .Net provider now supports Microsoft Entity Framework 4.2. To use the new Entity Framework 4.2, it must be added to Visual Studio projects using the Visual Studio tool NuGet. ================(Build #2666 - Engineering Case #682773)================ EF 4.1 is the latest release of Microsoft Entity Framework. The major new feature of EF 4.1 is "Code First". Support has now been added for Code First. Code First enables a different development workflow: defining data model objects by simply writing C# or VB.NET classes mapping to database objects without ever having to open a designer or define an XML mapping file. Optionally, additional configuration can be performed by using data annotations or the Fluent API. Model can be used to generate a database schema or map to an existing database. Here's an example which creates new database objects using the model: using System; using System.Collections.Generic; using System.ComponentModel.DataAnnotations; using System.Data.Entity; using System.Data.Entity.Infrastructure; using System.Linq; using iAnywhere.Data.SQLAnywhere; namespace CodeFirstExample { [Table( "EdmCategories", Schema = "DBA" )] public class Category { public string CategoryId { get; set; } [MaxLength( 64 )] public string Name { get; set; } public virtual ICollection<Product> Products { get; set; } } [Table( "EdmProducts", Schema = "DBA" )] public class Product { public int ProductId { get; set; } [MaxLength( 64 )] public string Name { get; set; } public string CategoryId { get; set; } public virtual Category Category { get; set; } } [Table( "EdmSuppliers", Schema = "DBA" )] public class Supplier { [Key] public string SupplierCode { get; set; } [MaxLength( 64 )] public string Name { get; set; } } public class Context : DbContext { public Context() : base() { } public Context( string connStr ) : base( connStr ) { } public DbSet<Category> Categories { get; set; } public DbSet<Product> Products { get; set; } public DbSet<Supplier> Suppliers { get; set; } protected override void OnModelCreating( DbModelBuilder modelBuilder ) { modelBuilder.Entity<Supplier>().Property( s => s.Name ).IsRequired(); } } class Program { static void Main( string[] args ) { Database.DefaultConnectionFactory = new SAConnectionFactory(); Database.SetInitializer<Context>( new DropCreateDatabaseAlways<Context>() ); using ( var db = new Context( "DSN=SQL Anywhere 12 Demo" ) ) { var query = db.Products.ToList(); } } } } Here's another example which maps to an existing database: using System; using System.Collections.Generic; using System.ComponentModel.DataAnnotations; using System.Data.Entity; using System.Data.Entity.Infrastructure; using System.Linq; using iAnywhere.Data.SQLAnywhere; namespace CodeFirstExample { [Table( "Customers", Schema = "GROUPO" )] public class Customer { [Key()] public int ID { get; set; } public string SurName { get; set; } public string GivenName { get; set; } public string Street { get; set; } public string City { get; set; } public string State { get; set; } public string Country { get; set; } public string PostalCode { get; set; } public string Phone { get; set; } public string CompanyName { get; set; } public virtual ICollection<Contact> Contacts { get; set; } } [Table( "Contacts", Schema = "GROUPO" )] public class Contact { [Key()] public int ID { get; set; } public string SurName { get; set; } public string GivenName { get; set; } public string Title { get; set; } public string Street { get; set; } public string City { get; set; } public string State { get; set; } public string Country { get; set; } public string PostalCode { get; set; } public string Phone { get; set; } public string Fax { get; set; } [ForeignKey( "Customer" )] public int CustomerId { get; set; } public virtual Customer Customer { get; set; } } public class Context : DbContext { public Context() : base() { } public Context( string connStr ) : base( connStr ) { } public DbSet<Contact> Contacts { get; set; } public DbSet<Customer> Customers { get; set; } } class Program { static void Main( string[] args ) { Database.DefaultConnectionFactory = new SAConnectionFactory(); Database.SetInitializer<Context>( null ); using ( var db = new Context( "DSN=SQL Anywhere 12 Demo" ) ) { foreach ( var customer in db.Customers.ToList() ) { Console.WriteLine( "Customer - " + string.Format( "{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9}", customer.ID, customer.SurName, customer.GivenName, customer.Street, customer.City, customer.State, customer.Country, customer.PostalCode, customer.Phone, customer.CompanyName ) ); foreach ( var contact in customer.Contacts ) { Console.WriteLine( " Contact - " + string.Format( "{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9}, {10}", contact.ID, contact.SurName, contact.GivenName, contact.Title, contact.Street, contact.City, contact.State, contact.Country, contact.PostalCode, contact.Phone, contact.Fax ) ); } } } } } } Additional assembly references need to be add to run these examples: EntityFramework, iAnywhere.Data.SQLAnywhere.v4.0, System.ComponentModel.DataAnnotations, System.Data.Entity. ================(Build #2598 - Engineering Case #667520)================ A new command line option 'uninstallall' (or 'ua') has been added to SetupVSPackage.exe. When specified, the 'uninstallall' option will cause SetupVSPackage to remove all versions of SQL Anywhere assemblies from the Global Assembly Cache. For example: SetupVSPackage.exe /ua ================(Build #2476 - Engineering Case #637146)================ Two xml mapping files have been added to support SQL Server 2008 Integration Services: - MSSqlToSA.xml --- mapping SQL Server 2008 data types to SA data types. - SAToMSSql10.xml --- mapping SA data types to SQL Server 2008 data types. These files will be installed to "%SA%\Assembly\V2" folders. The utility SetupVSPackage.exe will copy them to, or remove them from, the "%SQL Server 2008 Dir%\DTS\Binn" folder. ================(Build #2456 - Engineering Case #633600)================ Some Visual Studio integration related problems were not handled by SetupVSPackage.exe, but were problems caused by SA installer when installing the SA ADO.NET provider and the SA Visual Studio Integration Package. Some of these problems were 1. Incorrect machine.config file. 2. SA ADO.NET provider assemblies were not added to GAC. 3. SA ADO.NET provider assemblies did not show up in Visual Studio Add Reference dialogbox. 4. Visual Studio failed to create DataSets or Entity Framework Models using SA data sources. Re-installation of SQL Anywhere was usually required to fix these problems. Now all Visual Studio integration related code has been implemented in SetupVSPackage.exe, and any Visual Studio integration problem should be fixed by running SetupVSPackage. It will perform the following tasks: 1. Add / Remove assemblies of SA ADO.NET provider and integration package to / from GAC. 2. Register or unregister SA ADO.NET provider in machine.config. 3. Create registry keys for SA integration package 4. Create registry keys for Visual Studio Add Reference dialogbox. 5. Copy / Remove SSDLToSA12.tt to / from Visual Studio 2010 folder (%VS_DIR%\Common7\IDE\Extensions\Microsoft\Entity Framework Tools\DBGen). 6. Register or unregister SA ADO.NET provider in %SQL Server 2008 DIR%\100\DTS\ProviderDescriptors\ProviderDescriptors.xml which is used by SQL Server Integration Service. 7. Setup Visual Studio IDE for SA integration package. SetupVSPackage.exe is executed by the SQL Anywhere installer when installing or uninstalling SQL Anywhere, but SetupVSPackage.exe can be run separately. Two versions of SetupVSPackage.exe will be installed: 1. %SQLANY%\Assembly\V4\SetupVSPackage.exe - This version is built using .NET Framework 4, this version should be used if .NET Framework 4 is installed. 2. %SQLANY%\Assembly\V2\SetupVSPackage.exe - This version is built using .NET Framework 2, this version should be used if .NET Framework 4 is not installed. A performance issue when running SetupVSPackage.exe for Visual Studio 2008 and 2010 has also been fixed. ================(Build #2438 - Engineering Case #629284)================ The Visual Studio "Add Connection" wizard will display SQL Anywhere and Adaptive Server Anywhere ODBC Data Source names in the pick list when the SQL Anywhere .NET provider is used for the connection. SQL Anywhere integration with Visual Studio has been improved to also show Sybase IQ ODBC Data Source names in the pick list. ================(Build #2420 - Engineering Case #624809)================ Support for .NET Framework 4 and Visual Studio 2010 has now been added to the SQL Anywhere ADO.Net provider. Three versions of the provider are installed. One for .NET 2.0 / 3.0, one for .NET 3.5, and one for .NET 4.0. Each version contains both assembly and policy files. Here is a list of the files: (1) .NET 2.0 / 3.0 ...\Assembly\V2\iAnywhere.Data.SQLAnywhere.config ...\Assembly\V2\iAnywhere.Data.SQLAnywhere.dll ...\Assembly\V2\iAnywhere.Data.SQLAnywhere.xml ...\Assembly\V2\policy.11.0.iAnywhere.Data.SQLAnywhere.dll (2) .NET 3.5 ...\Assembly\V3.5\iAnywhere.Data.SQLAnywhere.v3.5.config ...\Assembly\V3.5\iAnywhere.Data.SQLAnywhere.v3.5.dll ...\Assembly\V3.5\iAnywhere.Data.SQLAnywhere.v3.5.xml ...\Assembly\V3.5\policy.11.0.iAnywhere.Data.SQLAnywhere.v3.5.dll (3) .NET 4.0 ...\Assembly\V4\iAnywhere.Data.SQLAnywhere.v4.0.config ...\Assembly\V4\iAnywhere.Data.SQLAnywhere.v4.0.dll ...\Assembly\V4\iAnywhere.Data.SQLAnywhere.v4.0.xml ...\Assembly\V4\policy.11.0.iAnywhere.Data.SQLAnywhere.v4.0.dll ...\Assembly\V4\SSDLToSA11.tt The iAnywhere.Data.SQLAnywhere assembly reference can be added in Visual Studio with the Add Reference dialog. Use the one depending on the .NET project as follows: iAnywhere.Data.SQLAnywhere for .NET 2 should be used for .NET 2.0 / 3.0 projects iAnywhere.Data.SQLAnywhere for .NET 3.5 should be used for .NET 3.5 projects iAnywhere.Data.SQLAnywhere for .NET 4 should be used for .NET 4 projects SSDLToSA11.tt is used for generating database schema DDL for Entity Data Models. The SQL Anywhere installer copies this file to the Visual Studio 2010 directory. The DDL Generation property should be set to this file when generating database schema DDL for Entity Data Models.

SQL Anywhere - DBLIB Client Library

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

SQL Anywhere - JDBC Client Library

================(Build #2424 - Engineering Case #625011)================ The iAnywhere and SQL Anywhere JDBC drivers only supported the PreparedStatement methods addBatch() and executeBatch(). Support has now been added for the Statement methods addBatch(), clearBatch() and executeBatch(). Due to the fact that the JDBC specification is unclear on the behaviour of Statement.executeBatch(), the following notes should be considered when using this method with these JDBC drivers: 1) Processing of the batch stops immediately upon encountering a SQL exception or result set. If processing of the batch stops, then a BatchUpdateException will be thrown by Statement.executeBatch(). Calling getUpdateCounts() on the BatchUpdateException will return an integer array of row counts where the set of counts prior to the batch failure will contain a valid non-negative update count; while all counts at the point of the batch failure and beyond will contain a -1. Casting the BatchUpdateCount to a SQLException will provide additional details as to why batch processing was stopped. 2) The batch is only cleared when Statement.clearBatch() is explicitly called. As a result, calling Statement.executeBatch() repeatedly will re-execute the batch over and over again. In addition, calling Statement.execute( sql ) or Statement.executeQuery( sql ) will correctly execute the statement with the "sql" argument, but will not clear the underlying batch. Hence, calling Statement.executeBatch() followed by Statement.execute( sql ) followed by Statement.executeBatch() will execute the set of batched statements, then execute "sql" and then execute the set of batched statements again. ================(Build #2128 - Engineering Case #553310)================ An application that uses the iAnywhere JDBC driver must now have the jodbc.jar built with the same build number as the dbjodbc and mljodbc shared objects. If the jar and shared objects are out of sync, a SQLException will be thrown at connect time and the connection will be refused. ================(Build #2112 - Engineering Case #549932)================ The iAnywhere JDBC driver has supported the PreparedStatement.addBatch() and PreparedStatement.executeBatch() methods for quite some time now, but, these methods were only supported for INSERT statements. These methods will now also be supported for UDATE and DELETE statements, provided the underlying connection is to an SA server. If the underlying connection is to a non-SA server, then these methods will still only be supported for INSERT.

SQL Anywhere - ODBC Client Library

================(Build #2490 - Engineering Case #638755)================ When an ODBC application made a SQLTables() call, the TABLE_TYPE column in the result set identified materialized views as MATERIALIZED VIEW. While doing so was not against the ODBC specification, there was nevertheless a problem with applications like Microsoft Access and Crystal Reports, which filter out anything that is not marked as TABLE, VIEW, SYSTEM TABLE, ALIAS, SYNONYM, GLOBAL TEMPORARY or LOCAL TEMPORARY. Therefore, the TABLE_TYPE value returned for materialized views has been changed to be VIEW. In addition, a new connection parameter has been added to ODBC which allows a specific string to be defined that is returned in the SQLTables() result set for materialized views. This new connection parameter is called MATVIEW, and is a string that will be returned in the TABLE_TYPE column for materialized views. For example, to have the SQLTables() function return materialized views as type TABLE, connect as follows: uid=dba;pwd=sql;eng=...;matview=table This new option can be used to override this default and return to the previous behaviour. The same string is also used when SQLTables() is called with an explicit TableType filter. ================(Build #2328 - Engineering Case #594888)================ The performance of ODBC metadata functions, such as SQLPrimaryKeys, SQLTables, and SQLColumns, has been improved for case-sensitive databases. This performance improvement will not occur for case-sensitive databases if SQLSetStmtAttr is called to set the SQL_ATTR_METADATA_ID attribute to SQL_TRUE. However, by default, this attribute is set to SQL_FALSE. When set to SQL_FALSE, case-sensitive databases will now enjoy the same performance as case-insensitive databases. Please note that when the SQL_ATTR_METADATA_ID attribute is set to SQL_TRUE, the string arguments to metadata functions are treated as identifiers, not strings (or patterns like "co%"). Identifiers can be delimited, in which case leading and trailing spaces are removed. Identifiers need not be delimited, in which case trailing spaces are removed. ================(Build #2266 - Engineering Case #578617)================ On Unix systems, an ANSI-only (no wide call support) ODBC driver is now available. The name of the driver is libdbodbcansi11_r. Only a threaded variant is provided. On Mac OS X, in addition to the dylib, the driver is also available in bundle form (dbodbcansi11_r.bundle). Certain frameworks, such as Real Basic, do not work with the dylib and require the bundle. The regular SQL Anywhere ODBC driver treats SQLWCHAR strings as UTF-16 strings. Starting in SQL Anywhere 10, when Unicode support in the Unix ODBC drivers was first introduced, the driver could not have been used with some ODBC driver managers, such as iODBC, which treated SQLWCHAR strings as UTF-32 strings. When dealing with Unicode-enabled drivers, these driver managers would translate narrow calls from the application to wide calls into the driver. An ANSI-only driver gets around this behaviour, allowing the driver to be used with such driver managers, as long as the application does not make any wide calls. Wide calls through iODBC, or any other driver manager with similar semantics, remain unsupported.

SQL Anywhere - OLEDB Client Library

================(Build #2514 - Engineering Case #645959)================ Microsoft SQL Server has introduced two data types DBTYPE_DBTIME2 and DBTYPE_DBTIMESTAMPOFFSET that are not part of the OLE DB specification. Support for conversions between these two types and DBTYPE_STR, DBTYPE_WSTR, DBTYPE_DBDATE, DBTYPE_DBTIME, and DBTYPE_DBTIMESTAMP has now been added to the SQL Anywhere OLE DB provider. DBTYPE_DBTIME2 differs from DBTYPE_DBTIME in that fractional seconds are included. The type corresponds to the Microsoft SQL Server TIME data type. DBTYPE_TIMESTAMPOFFSET adds support for a timezone offset (hours/minutes). The type corresponds to the Microsoft SQL Server DATETIMEOFFSET data type.

SQL Anywhere - Other

================(Build #2685 - Engineering Case #685973)================ If a user's path contained a large number of directories and/or contained directories located on mapped network drives, the first connection attempt made by an application could have been slow. This has been fixed. A workaround is to create an empty file called saldap.ini (assuming the LDAP feature is not being used) in the installation bin32/bin64 directory. ================(Build #2558 - Engineering Case #657471)================ The PHP external environment and the PHP driver now support PHP versions 5.3.3, 5.3.4, and 5.3.5. ================(Build #2272 - Engineering Case #580788)================ The EBF installers for Linux are now capable of installing FIPS components. To initially install the components, the setup script must be invoked with the -regkey (alias -k) command line option, and be passed a registration key that entitles the installation of the FIPS componenents. e.g., ./setup -k <FIPS registration key> or ./setup -regkey <FIPS registration key> It is not possible to specify the registration key through the EBF Installer UI itself. Subsequent invocations of the EBF install will then update previously installed FIPS components without needing to specify a registration key. ================(Build #2166 - Engineering Case #563352)================ Prebuilt binary libraries for PHP 5.2.8 have now been added.

SQL Anywhere - Server

================(Build #3052 - Engineering Case #747805)================ For Syntax 2 of the DELETE statement and Syntax 2 of the UPDATE statement the error detection behaviour of the server has been improved. These two syntax forms allow an additional FROM clause that may contain the table-name of the updated or deleted table, for example: DELETE FROM [owner.]table_1 [ [ AS ] correlation-name ] FROM [owner.]table_1 [ [ AS ] correlation-name ] ... WHERE ... and UPDATE [owner.]table_1 [ [ AS ] correlation-name ] SET columns_1 = ... FROM [owner.]table_1 [ [ AS ] correlation-name ] ... WHERE ... If the DELETE or UPDATE clause and the additional FROM clause have a table reference that contains the same table name, in the above example "table_1", then the server can only decide whether both are identical table references if one of the following conditions is true: - both table references are not qualified by specifying a user ID - both table references are qualified by specifying a user ID - both table references are specified with a correlation name In cases where the server cannot decide whether the above table references are identical or not it will now return an SQL error to prevent the user from unintended semantics like deleting and updating to many rows. ================(Build #2905 - Engineering Case #725019)================ The syntactical construct "numeric( precision, scale )" would have returned the error "Syntax error near ')'" if the scale value was greater than the precision value. This has been fixed so that the syntax error message now contains the scale value. ================(Build #2785 - Engineering Case #700997)================ On Windows systems, the error "R6025 - pure virtual function call" would have caused a dialog box to be opened, even if the executable should not interact with the desktop. This has been fixed so that no dialog box is now opened. ================(Build #2761 - Engineering Case #695258)================ A new connection-level property 'NumLocalTempTables' has been added that returns the number of local temporary tables in use by the connection. Note that even when a local temporary table is dropped or falls out of scope, it is still considered to be "in use" until the next commit. ================(Build #2561 - Engineering Case #657712)================ Additional information is now saved for graphical and long plans. This additional information includes: - Known values for expressions are now dumped in the plans. For example, a stored procedure parameter known at the optimization time is dumped as 'parm1[100]' if its name is 'parm1' and its known value is '100'. - For long plans generated by the application profiling, extra information related to the optimization process is now dumped. For example, 'Plan [ Total Cost Estimate: 3.5657, Costed Best Plans: 1, Costed Plans: 13, Optimization Time: 0.074541, Estimated Cache Pages: 590 ]' This type of information is already present for long plans generated by calling the explanation() function. - Information related to the cached plan of a statement is now dumped in its long plan. - Predicates used to generate fence posts for a partial index scan are now dumped in the long plans generated by the application profiling. This type of information is already present for long plans generated by calling the explanation() function. Also, graphical plans with statistics saved during tracing did not actually contain any statistics. This has been fixed. ================(Build #2526 - Engineering Case #649437)================ Version 9.0.x has an optimization for a very large number of WHERE predicates that are in Disjunctive Normal Form (DNF), which was not implemented starting with version 10.0.0. For example: WHERE (T.A1 = c11 and T.A2 = c12 and ... and T.Ak =c1k) OR ..... (T.A1 = cN1 and T.A2 = cN2 and .... and T.Ak =cNk) AND (other predicates) The values for c11, c12, ..., cNk are constants, and N is large. The following sargable IN predicates were generated from the original predicates: T.A1 IN {c11,c21, ..., cN1} AND ... T.Ak IN { c1k, ..., cNk} If there existed an index on table T with a prefix on any combination of the columns T.A1, ..., T.Ak, then a partial index scan using the sargable IN predicates could have been chosen in the best access plan. For example, if an index 'idx1' existed on T < A2, Ak > then the partial index scan [ {c12, ..., cN2} JNL {c1k, ..., cNk} JNL T <idx1>] may have been used in the best access plan. The original predicate would still have been applied after the index scan as a postfilter. This optimization was not implemented starting with SA 10.0.0, as multiindex scans introduced in SA 11.0.0 and enhanced in SA 11.0.1 provided more general access methods using any combination of UNION and INTERSECTION of indexes. Multiindex scans performed better than the above optimization for small to medium size DNF predicates. However, multiindex scans can be inefficient when the number of predicates is large, for example, DNF predicates having 1,000 or more terms. This new feature addresses, in a very general way, these extreme cases and other cases when multiindex index scans use the same index. A multicolumn inmemory table is built with the exact combinations used in a DNF term, and this table is joined with the index scan. In the example above, if an index 'idx2' on T<A1, A2,..., Ak> exists, the access method [{(c11,c12,...,c1k), (c21,c22,...,c2k),..., (cN1, cN2, ..., cNk)} JNL T<idx2>] will be built. Prior to this change the following multiindex scan was considered: T<idx2: (c11,c12,...,c1k)> UNION T<idx2: (c21,c22,...,c2k)> UNION ... UNION T<idx2: (cN1,cN2,...,cNk)> This multiindex scan could have been inefficient if N was greater than 1,000. ================(Build #2482 - Engineering Case #625314)================ It is now possible to use the Script Execution utility (dbrunsql) to reload a database without displaying the GUI, but still log output messages (results) to a file. Previously, if the -q option was not used the dbrunsql gui was shown regardless of the -g setting. Now, the -q and -g switches work together. If -g- is specified, the GUI will not be shown except for error messages. The -q option now only controls if data and warning messages shall be output to the GUI, the console, and/or an output file. ================(Build #2459 - Engineering Case #629411)================ The database option UUID_HAS_HYPHENS has been re-added. It can have the values On (default) and Off. If a uniqueidentifer value is converted to a string, then the string contains hyphens if the option value is On. ================(Build #2414 - Engineering Case #623610)================ Processor topology detection for x86/x64 processors has been improved to detect new SMT processors correctly (ie processors with multiple threads per core that are not the older "hyperthread" implementation). Previously, a quad-core i7 (for example) with two threads per core would be detected as 8 cores rather than 4 cores with 2 threads per core. The algorithm for distributing database server threads among logical processors when using less than the maximum concurrency permitted (via the database server -gtc switch) now correctly takes the 3-level chip/core/thread topology into consideration. Generally, this change does not affect licensing since association of a logical processor with the actual chip containing each logical processor was still correct in the old code with the possible exception of some newer Intel 6-core processors. On Mac OS X where the operating system does not provide interfaces to control processor affinity, exact processor topology cannot be determined, so SQL Anywhere treats each logical processor as a separate package or "socket". On multicore and SMT processors, OSX users should purchase the correct license for the hardware they are using, but install a license that will allow the correct amount of concurrency. For example on a quad-core i7 with two threads per core, purchase a license for 1 CPU "socket" but install a license for 8 cpu "sockets" since each processor thread will be treated as a separate CPU socket. Feature tracking code has also been changed so that the 3-level topology, CPU brand string and CPU info registers (which do not form a unique machine identifier) are reported when crash reports are sent to Sybase. ================(Build #2413 - Engineering Case #622024)================ If an application attempted to perform an integrated login from one Windows machine to a SQL Anywhere database server running on a different Windows machine; and the machine that the database server was running on was not the domain controller; and the Windows userid that the application was using was not explicitly mapped in the database; and the application was expecting that the server would instead map the application's Windows userid to a Windows user group on the Domain Controller, then there was a chance the integrated login would fail to map the Windows group. For example: 1) suppose the domain controller was Windows machine DC, and 2) suppose the application was running on Windows machine App with Windows userid AppUser, and 3) suppose the database server was running on Windows machine SAServ with Windows userid ServUser, and 4) suppose the domain controller had a Windows user group GRP of which AppUser was a member, and 5) suppose the database did not grant explicit integrated login privileges to AppUser but instead had granted integrated login privileges to GRP instead, then there was a chance that the application would fail to establish an integrated login to the db userid that GRP was mapped to. This problem has now been fixed. ================(Build #2412 - Engineering Case #560044)================ In some cases, an error was generated for expressions that contained only values that were known at open time. For example, the following generated a "division by zero" error: select if 1=0 then 1/0 else 42 endif val This problem occurred because the expression '1/0' was evaluated as part of building the access plan for the query. Constant expression trees were evaluated at open time in a bottom-up fashion so that the value can be used at execution time (avoiding multiple evaluations and supporting optimizations). In some cases, the expression was not actually needed, as in the above example with an IF expression. In these cases, the constant folding process could have generated an error that would not have been returned if the constant literals were replaced with field references. This has been changed. Errors generated during constant folding are no longer returned at open time. Instead, the constant expression tree is left in its original structure and evaluated at execution time if the value is needed. This execution-time evaluation will generate the related error if the value is actually needed. ================(Build #2399 - Engineering Case #619595)================ The SQL Anywhere Optimizer now has a new source type for the selectivity estimations of atomic predicates of the form "T.X = R.X", namely JOIN. A selectivity estimation has the "JOIN" source type if it is computed using (1) Primary Key - Foreign Key referential integrity constraints; (2) unique constraints; (3) join histograms. The SQL Anywhere Optimizer uses selectivity estimation sources when redundant predicates are present in a query. Different sources have different qualities, hence predicates with better sources are used when competing predicates are present. ================(Build #2382 - Engineering Case #674702)================ Assertion failure messages now include a database name where available. ================(Build #2344 - Engineering Case #605668)================ If an application that was connected via jConnect or Open Client attempted to insert or retrieve a datetime or time value, then the date portion of the value was limited to January 1, 1753 or later, and the time portion was restricted a precision of 1/300th of a second. Now, if an application uses newer versions of jConnect and Open Client, then the date portion of datetime values will span the full range from 0001-01-01 to 9999-12-31, and the time portion will now be handled in microsecond precision. ================(Build #2256 - Engineering Case #575760)================ When there is only one connection, the maximum number of prefetch rows has been increased to 10000. If there is more than one connection, the maximum number of prefetch rows remains unchanged at 1000. Performance may improve when all of the following conditions are met: - an application has only one connection - fetching a result set with many thousands of rows - each row in the result set has small number of columns - the data size of the fetched columns is small - prefetch is enabled - the connection is over TCP/IP (shared memory connections are not likely to see a significant performance improvement) ================(Build #2250 - Engineering Case #570650)================ Using the TRANSACTION LOG TRUNCATE clause on the BACKUP DATABASE statement could have lead to the error "Assertion failed: 100910 Error renaming transaction log file before deleting it." This would have occurred when the user under which the server was running did not have delete permissions on the directory where the transaction log was located. Now, the server no longer deletes and re-creates the transaction log file, instead it truncates the file to one page. This should also prevent any interaction with virus scanners and disk defragmenters, which was often the case when files were being created. ================(Build #2236 - Engineering Case #571620)================ OEMs now have the ability to prevent users from saving connection passwords with favorites. To do this, add the (new) "allowPasswordsInFavorites" directive to the "dbisql" section of the OEM.INI file: [dbisql] allowPasswordsInFavorites=false Allowable values for this directive are "true" and "false". The default is "true". If this directive is added to OEM.INI, and its value is "false", the visible change is in the "Add to Favorites" window: the checkbox called "Save the connection password" will not be visible, and will be assumed to be unselected. ================(Build #2195 - Engineering Case #566651)================ A SERVICE may invoke a procedure that explicitly sets the 'Connection' and 'Content-Length' HTTP response headers using the SA_SET_HTTP_HEADER system procedure. The setting of the 'Content-Length' was ignored, and the setting of 'Connection:close' implicitly disabled chunked-mode transfer encoding. Changes have been made to provide greater control over SQLAnywhere HTTP server responses. The following is a summary of the new behaviour: Client is HTTP/1.0: The server does not support Keep-Alive and Chunk-mode operation for this HTTP version. By default the server never sets the 'Transfer-Encoding' header and always sets 'Connection: close' header, shutting down the connection once the response has been sent. A SERVICE procedure may set the 'Content-Length' header but setting the 'Connection' header is ignored. Client is HTTP/1.1: By default the server responses use chunked-mode transfer encoding and automatically set the 'Transfer-Encoding: chunked' header. If the SERVICE procedure explicitly sets a 'Content-Length' header to some value, then the 'Content-Length' header is sent in place of the 'Transfer-Encoding' header and the response body is not chunk-mode encoded. Note: It is an error for a SERVICE procedure to set both a 'Content-Length' and 'Transfer-Encoding' header. The server will assume 'Connection: keep-alive' if the client does not send a 'Connection' request header. If a client explicitly sends a 'Connection: close' request header and/or the SERVER procedure explicitly sets 'Connection: close' the server will shutdown the connection once the response has been sent. Setting Content-Length In most cases data will need to be buffered in order to calculate the Content-Length. Therefore, it is recommended to use chunk-mode transfer encoding whenever possible. If 'Content-Length' must be set, then care must be taken to ensure that the result-set is not character set translated when the response is composed. It is recommended that the 'CharsetConversion' http option is set to off when returning textual data. Also, setting 'Content-Length' should only be done within a TYPE 'RAW' SERVICE since some services (i.e. 'HTML', 'JSON') add content to the response. A check has been added to ensure that the actual length of the response matches the value of 'Content-Length' header. If the values do not match then the server will shutdown the connection, once the response has been sent, regardless of whether or not a 'Connection: keep-alive' response header has been sent. ================(Build #2167 - Engineering Case #563394)================ Execution of LOAD TABLE statement will now use asynchronous IO in order to improve performance. Actual performance gains will vary depending on hardware and database configuration but tests have shown an approximate doubling of performance. Asynchronous IO is only used when accessing a local data file (not a client file, etc). ================(Build #2148 - Engineering Case #559813)================ The server would have reported the number of processors detected and some imposed limits. The messages have been changed so that they will now report: - number of processors detected (changed format) - processor limits imposed by Edition, licenses purchased, and -gt option - max number of processors that will be used Also, the Edition limit that is imposed during licensing is now also imposed by the server itself. For some Unix systems, the number of processors used can not be limited. If the number to be used exceeds the per-processor license limitation, an additional message is reported, and is unchanged from previous versions. ================(Build #2144 - Engineering Case #558084)================ A new tailoring of the Japanese UCA collation has been added which defines primary-level differences between all Hiragana letters, as well as primary-level differences between all Katakana letters. This new tailoring will permit correct equality comparisons of Hiragana and Katakana letters in case-insensitive collations. The new collation is used by specifying a collation of UCA(locale=ja;sorttype=direct;...). ================(Build #2142 - Engineering Case #557527)================ A SQL Anywhere HTTP client function was only able to return a varchar data type. Support has now been added to the HTTP client so that it can also be defined to return binary, varbinary or long binary data types, i.e.: CREATE function client() RETURNS long binary URL 'http://localhost/image_service/...' TYPE 'HTTP:GET' Note, this change only extends the semantic meaning of the returned value, declaring the return data type as binary does not change the behaviour at the transport level. Textual data may still be converted to the database character set based on Content-Type HTTP header or SOAP envelope encoding criteria. ================(Build #2141 - Engineering Case #557363)================ By default (or with SET 'HTTP(CH=auto)') an SA HTTP client procedure would have sent its HTTP request using chunk mode transfer encoding when posting data that was greater than 2048 bytes. If the server rejected the request with a 501 "Not Implemented" or 505 "HTTP Version Not Supported" status, the procedure would have automatically re-issued the request without using chunk transfer encoding. When in default mode, an SA client would not have used chunk transfer encoding when posting data that was less than 2048 bytes in length. This has now been changed so that the data byte limit is now 8196 bytes, from 2048 bytes, and the status 411 "Length Required" has been added to its criteria for re-issuing the request without using chunk mode transfer encoding. ================(Build #2139 - Engineering Case #555976)================ With the release of SA 10.0.0, identifiers were restricted such that they could no longer include double quotes or backslashes. Unfortunately, if an application wants to create an externlogin to a remote SQL server using secure logins, then the remote login needs to be specified in the form user\domain. As a result, the remote login specification of a create externlogin statement has now been extended to accept both identifiers and strings. Note that no catalog changes have been made; hence, the remote login specification is still restricted to 128 bytes. ================(Build #2124 - Engineering Case #552503)================ SQL statements which don't contain Transact-SQL OUTER JOINs, OUTER JOINs, KEY JOINs, or NATURAL JOINs will now skip some of the optimizations implemented in the server, which will improve the DESCRIBE time.

SQL Anywhere - Sybase Central Plug-in

================(Build #2780 - Engineering Case #704191)================ Changes have been made to Sybase Central to allow it to run with the Java 1.7 runtime. Note, this change also relates to the Interactive SQL utility as well. Sybase Central and the Interactive SQL utility were not reviewed for compatibility. ================(Build #2121 - Engineering Case #551700)================ Column widths in the debugger Details panel were not persistent. This has been fixed so that column widths are saved in user preferences.

SQL Anywhere - Utilities

================(Build #2572 - Engineering Case #662054)================ When deploying, the directory used by the Interactive SQL utility, Sybase Central, the Console utility, and the MobiLink Monitor, can now be specified. To do this, an OEM.ini file must be deployed along with these utilities. The file must contain the following lines: [preferences] directory={preferences files directory| where "preferences_files_directory" is a fully-qualified directory name, e.g. "c:\work\prefs". The directory name should not end in a separator (backslash on Windows; forward slash on Unix and Mac OS X). Preferences files include: .isqlPreferences12_32 .isqlPreferences12_64 .isqlHistory12 .jlogon12 .textCompleter12 .SybaseCentralEditor610 .scUserPreferences610_32 .scUserPreferences610_64 among others. ================(Build #2520 - Engineering Case #641296)================ When choosing to localize with the Deployment wizard, the Installation Wizard would have appeared localized, but Language was not set in the registry on the target machine. This has been corrected so that the SQL Anywhere Language registry entry is now set to match the deployment language. ================(Build #2314 - Engineering Case #539772)================ Installs created by the SQL Anywhere Deployment wizard would only have appeared in the Add or Remove Programs list in Control Panel, for the users that installed the MSI. This behaviour has been changed. The install will now appear in the Add or Remove Programs list for all users. ================(Build #2269 - Engineering Case #581403)================ It is now possible to specify the ESCAPE connection parameter in the "Connect" dialog when connecting to SQL Anywhere servers. Note, this new feature is actually available for use with all the graphical administration tools. ================(Build #2158 - Engineering Case #561127)================ By default, the reload.sql script generated by the Unload utility (dbunload_) includes calls to a temporary procedure (sa_unload_display_table_status) to display progress messages when loading tables and creating indexes. The -qr command line option will now suppress generation of these calls.

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

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

UltraLite - Runtime Libraries

================(Build #2512 - Engineering Case #645529)================ When run on Windows desktop, UltraLite now supports long paths when creating, opening, or deleting databases. ================(Build #2315 - Engineering Case #590030)================ A new "OR REPLACE" clause can now be optionally specified in the CREATE SYNCHRONIZATION PROFILE statement. If this clause is present, and the profile named in the statement already exists, then it will be replaced. Otherwise, it will be created. ================(Build #2139 - Engineering Case #556527)================ A new network protocol option 'http_buffer_responses' has been added. When set to 'On', HTTP packets from MobiLink will be completely streamed into an intermediary buffer before being processed, instead of processing the bytes as they are read off the wire. Syntax: http_buffer_responses = { off | on } Protocols: HTTP, HTTPS Default: off Because of the extra memory overhead required, this feature should only be used to work-around HTTP sync stability issues. In particular, the ActiveSync proxy server for Windows Mobile devices will throw away any data that is not read within 15 seconds after the server has closed its side of the connection. Because MobiLink clients process the download as they receive it from MobiLink, there is a chance they will fail to finish reading an HTTP packet within the allotted 15 seconds causing synchronization to fail with stream error code STREAM_ERROR_READ, when synchronizing using non-persistent HTTP. By specifiying 'http_buffer_responses=On', the client will read each HTTP packet in its entirety into a buffer before processing any of it, thereby beating the 15 second timeout.

UltraLite - Utilities

================(Build #2226 - Engineering Case #568866)================ The UltraLite Initialize Database utility (ulinit) is used to create an UltraLite database, based on information in the SQL Anywhere database that it is connected to. If the schema being extracted from the SQL Anywhere database contained elements that UltraLite did not support (like column datatypes or default values), the utility would have failed. Ulinit has been changed so that by default, it will attempt to create an UltraLite database that comes as close as possible to the SQL Anywhere database. For example, if a column in the SQL Anywhere database included the DEFAULT TIMESTAMP clause (a default that UltraLite does not support), a warning is generated and a default of CURRENT TIMESTAMP is generated instead. In particular, if a default in the SQL Anywhere database is not supported in the UltraLite database, the default value is ignored and creation continues. This enhancement was made because, in some cases, it’s possible the SQL Anywhere tables cannot be modified, and yet a reasonable UltraLite alternative is available. The ulinit utility also now has a –f switch that can be used to make the utility fail if the exact schema does not match (in other words, the old behavior is given and the utility will fail). This fix also addressed a problem where warnings were emitted into the SQL file if the ulinit utility was run with –l.

UltraLiteJ - Runtime

================(Build #2709 - Engineering Case #690250)================ The UltraLiteJ runtime now supports restartable HTTP synchronizations. With restartable HTTP enabled, UltraLiteJ applications can tolerate network interruptions, so synchronizations will fail less often on unreliable networks. Restartable HTTP is disabled by default. To enable, use the following new methods on the StreamHTTPParms class: /** * Enables or disables restartable HTTP. With restartable HTTP enabled, * UltraLiteJ can tolerate network interruptions, so synchronizations will fail * less often on unreliable networks. * <p> * To use restartable HTTP, both UltraLiteJ and the MobiLink server must have * applied CR#690250. * * @param isRestartable Pass true to enable restartable HTTP, and false to * disable. The default is false. * @see #isRestartable() */ public void setRestartable( boolean isRestartable ); /** * Returns true if restartable HTTP will be used, and false otherwise. * * @return Whether restartable HTTP will be used. * @see #setRestartable(boolean) */ public boolean isRestartable(); To use this change, both remotes and servers must be upgraded. It is safe to upgrade only one of the remote or the server, as long as setRestartable is not called on the remote. ================(Build #2661 - Engineering Case #681088)================ Memory usage for large downloads containing both deletes and/or updates has been improved, particularly in respect to the number of object handles used on BlackBerry devices. Downloads that delete or update tables with many columns will benefit most from this new algorithm. Note, row limiting is required to make use of this improvement. ================(Build #2653 - Engineering Case #680231)================ Databases which are accessed with row limiting enabled (see ConfigPersistent.setRowMinimumThreshold and setRowMaximumThreshold) will now always lazy load indexes. ================(Build #2309 - Engineering Case #584478)================ BlackBerry devices with OS 4.2 or later, may now read and write UltraLiteJ databases to either the internal flash or the SD (media) Card, in addition to the previously supported persistent store. While the persistent object store of BlackBerry devices is faster, it has limited capacity and is shared with RAM and program storage. Newer devices such as the Bold, Storm and Tour have internal flash (Bold and Storm have almost 1GB) and many devices support SD Cards. Persistent store is 3-4 times faster than internal flash, and internal flash is faster than SD cards. Databases stored on internal flash (URIs begining with "file:///store/") or media cards ("file:///SDCard/") can keep more rows in memory, and/or use a bigger cache to improve performance. Databases names must follow the format for a fully qualified, absolute path file name as described in the file URL format as part of IETF RFCs 1738 and 2396. That RFC dictates that a file URL takes the form: file://<host>/<path> In the form above, <host> is the fully qualified domain name of the system on which the <path> is accessible, and <path> is a hierarchical directory path of the form: <root>/<directory>/<directory>/.../<name>. For BlackBerry devices, the internal flash is accessed using URIs starting with file:///store/ (case sensitive) while the SD media card is accessed using URIs starting with file:///SDCard/ (case sensitive). File paths are case insensitive except for the host portion which is case sensitive. Percent (%) characters have special meaning and relative paths (directories "." and "..") are not allowed. For more information on file name restrictions, please consult the BlackBerry JDE (4.2 or later) API Reference for the javax.microedition.io.file package. The following example creates a configuration for using the media card. The database is store in the directory "ulj" and is called "test.ulj". // BlackBerry media card Sample - use file:///store/ulj/test.ulj // for internal flash Connection conn; ConfigFileME config = DatabaseManager.createConfigurationFileME( "file:///SDCard/ulj/test.ulj" ); try { conn = DatabaseManager.connect(config); } catch(ULjException ex) { conn = DatabaseManager.createDatabase(config); // Create the schema here. } To maintain support for BlackBerry 4.1 devices, a new distribution directory UltraLite\UltraLiteJ\BlackBerry4.2 has been added which contains files for 4.2 or later devices. BlackBerry 4.1 devices and simulators should continue to use the UltraLite\UltraLiteJ\J2meRIM11files. BlackBerry 4.2 and later devices can use either distribution if they do not require SD card or internal flash storage. The UltraLiteJ Database Transfer tool has not been updated. ================(Build #2266 - Engineering Case #578636)================ Support has now been added for the SQL statements CREATE PUBLICATION, ALTER PUBLICATION and DROP PUBLICATION. This change also includes support for publication predicates.



11.0.1 Bug Fixes

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

MobiLink - Java Plugin for Sybase Central

================(Build #2563 - Engineering Case #658860)================ Sybase Central would have crashed when using the QAnywhere plugin to define a property for a connector and the property was given both a blank name and value. Now, the creation of properties with blank names is prevented, as these are meaningless in any case. A message box indicating that the property name must not be empty is displayed. ================(Build #2558 - Engineering Case #657284)================ The MobiLink Server log file viewer in Sybase Central might not have listed all synchronizations in a given log file separately if the log file contained messages from more than one run of the MobiLink Server. This has been fixed. ================(Build #2558 - Engineering Case #657068)================ In the MobiLink Server Log File Viewer, selecting a synchronization could have resulted in the window becoming unresponsive if the synchronization contained hundreds of thousands of messages. This has been fixed. Also, it was noticed that synchronizations were not initially listed in chronological order if the log file contained output for more than one run of the MobiLink Server. This has also been fixed. ================(Build #2541 - Engineering Case #653058)================ When creating a rule with a "Custom" schedule type, the schedule that was saved could have been incorrect if "Run rule every" was turned off in the "Schedule Editor" window. The rule was saved such that it was run every 10 minutes. This has been fixed. ================(Build #2539 - Engineering Case #652577)================ Sybase Central could have crashed while the property sheet for a client message store was open, if adding a new property was started, but then the action was cancelled. This has been fixed. ================(Build #2512 - Engineering Case #637326)================ An error could have occurred when deploying a Synchronization Model for an ASE consolidated database when a synchronized table had a MONEY or SMALLMONEY column and conflict resolution was enabled for the table mapping. ASE would have reported the error "Can't specify a length or scale on type 'money'" when deployment tried to create a temporary table for conflict resolution, and incorrectly specified the length and scale for MONEY columns. This would also have occurred for a Microsoft SQL Server consolidated database with a synchronized table having a MONEY or SMALLMONEY column, and for an IBM DB2 consolidated database with a synchronized table having a LONG VARCHAR column. These problems have been fixed. Now the generated SQL does not specify length or scale for MONEY or SMALLMONEY columns with ASE and Microsoft SQL Server, or for LONG VARCHAR with IBM DB2. ================(Build #2486 - Engineering Case #639298)================ Creating a server message store would have fail when attempting to create a new, encrypted SQL Anywhere database for the store. This has been fixed. ================(Build #2486 - Engineering Case #637481)================ UltraLite client message stores created from Sybase Central did not have their store IDs set, even if a store ID was given in the Client Message Store wizard. Lack of the store ID would have caused a warning message to be displayed when attempting to disconnect from the database and stop the agent from Sybase Central. This has been fixed. ================(Build #2468 - Engineering Case #635336)================ The MobiLink Server Log File Viewer would have shown empty user names and remote IDs in its "Synchronizations" and "Details" panels when running on a non-English Solaris, Mac OS X, or French Linux system, and Sybase Central was set up to run in that non-English language. This has been fixed. ================(Build #2465 - Engineering Case #634933)================ Deploying a Synchronization Model with the "Run this wizard initialized with last deployment settings" option would have given an empty field for the location of the UltraLite database file, instead of using the location from the last deployment. A workaround is to use the Browse button to pick the previously deployed UDB file. This has been fixed. ================(Build #2451 - Engineering Case #632446)================ The MobiLink server stream options set in the Deploy Synchronization Model wizard would not have been set in the batch file created to run the MobiLink server. This has been fixed. A workaround is to edit the generated batch file to add the stream options. ================(Build #2441 - Engineering Case #630082)================ The "Apply" button in the client properties window (for a given server store) was not enabled correctly, and when it was enabled, it did not consistently apply the changes. This has been fixed. ================(Build #2441 - Engineering Case #630073)================ The contents of the combobox in the "Schedule Editor" window could have been truncated on some systems, depending on which font was being used by Sybase Central. This has been fixed. ================(Build #2426 - Engineering Case #626459)================ A UDP Gateway's property sheet would have shown the default destination port as -1. This has been corrected so that the correct value of 5001 is now shown. ================(Build #2423 - Engineering Case #625625)================ Sybase Central would have generated an error when attempting to create a notifier, gateway or carrier with any of the following characters in its name: '[', ']', '^', '%', '_'. A similar error would have occurred when attempting to rename a notifier, gateway or carrier and any of these characters were used in the new name. This has been fixed. ================(Build #2422 - Engineering Case #624555)================ When adding a new table to the remote database schema in a synchronization model, if the remote schema was based on a consolidated database other than SQL Anywhere, and the table was referenced by foreign keys in other tables already copied from the consolidated schema to the remote schema, then an internal error would have occurred. This has been fixed. Note, a workaround is to add the table to the remote schema by using the Update Schema menu item to update the remote schema. ================(Build #2418 - Engineering Case #624574)================ Attempting to connect to a newly created message store at the end of the Client Store wizard could have failed there already was network server running the computer and its "-gd ALL" option was not used. This has been fixed. ================(Build #2417 - Engineering Case #624405)================ Adding a member to an empty destination alias would have caused a crash. This has been fixed. ================(Build #2411 - Engineering Case #622889)================ When entering a file location in the Deploy Synchronization Model wizard, typing in a file name that did not include the folder would have resulted in an error when clicking Next. This has been fixed. A workaround is to specify the folder. ================(Build #2403 - Engineering Case #620496)================ When deploying a synchronization model to a new remote database, if the remote database schema had multiple foreign keys to multiple non-primary key columns in a table, a deployment error could have occurred with the following description: "Error for: Method makeUniqueConstraints threw exception for reference $HELPER in template script-defs\remote.vm" This has been fixed. ================(Build #2357 - Engineering Case #606888)================ When redeploying a synchronization model to a SQL Anywhere remote database using the wizard initialized with the last settings, the extended options for the SQL Anywhere client could have been corrupted. This has been fixed. ================(Build #2345 - Engineering Case #605823)================ For an IBM DB2 synchronization model, any events with comments would have had the comments lost when deploying the model directly to a DB2 consolidated database. Thus the special "--{ml_ignore}" comment to ignore a script, would have been lost. This has been fixed. A workaround is to deploy to file and run the deployed file. ================(Build #2344 - Engineering Case #605675)================ For a MySQL synchronization model, any events with comments would have had the comments lost when deploying the model directly to a MySQL consolidated database. Thus the special "--{ml_ignore}" comment to ignore a script, would have been lost. This has been fixed. A workaround is to deploy to a file, and then run the deployed file. ================(Build #2340 - Engineering Case #596235)================ When deploying a Synchronization Model to a new UltraLite database, if the remote schema had LONG NVARCHAR columns, an error would have occurred because UltraLite does not support LONG NVARCHAR columns. This has been fixed so that a warning is now given, and a LONG VARCHAR column is used instead in the new UltraLite database. ================(Build #2338 - Engineering Case #595997)================ When using a Synchronization Model with a Microsoft SQL Server consolidated database that had a table with a UNIQUEIDENTIFIER or TIMESTAMP primary key column, and using snapshot download and downloading of deletes, the following error would have occurred for the generated download_delete_cursor script: [-10002] Consolidated database server or ODBC error: ODBC: [Microsoft][ODBC SQL Server Driver]Restricted data type attribute violation This has been fixed. ================(Build #2316 - Engineering Case #590243)================ Sorting a list of messages on the "Messages" and "Archived Messages" tabs by the "Status Time" column, would not have sorted the messages correctly. The comparator for the date column had been based on the string representation of the date, rather than the date itself. This has been fixed. ================(Build #2306 - Engineering Case #587246)================ If a synchronization model was created that contained mappings with errors, and then the mappings were deleted or disableds, the sync model could still not have been deployed. The workarounds to this were to either recreate or enable the mapping, or manually edit the sync model file and remove the scripts with errors. This has been fixed. ================(Build #2275 - Engineering Case #581613)================ When deploying a Synchronization Model that added a timestamp column to a MySQL consolidated table for timestamp-based downloads, existing rows would never have been downloaded because of MySQL bug #17392. This bug caused the new timestamp column to have values of 0, instead of the column default. A would around for this problem has been implemented. An UPDATE statement is now generated to follow the generated ALTER TABLE statement that adds the timestamp row. A manual workaround is to update the timestamp column for each row where it is zero, after the column is added. ================(Build #2260 - Engineering Case #576501)================ If a Synchronization Model had a table mapping that was upload-only or download-only, then attempting to synchronize would have caused a warning that some scripts were missing. This has ben fixed by generating ignored scripts for the unneeded upload or download scripts, which suppressed the warnings. A workaround is to disable the warning, or create dummy scripts. ================(Build #2258 - Engineering Case #576500)================ When a Synchronization Model was being generated for a MySQL database, columns that had been defined as nchar and nvarchar in the MySQL database, would have been mapped as char and varchar in the Synchronization Model. This has been fixed. ================(Build #2255 - Engineering Case #575517)================ When using the Table Mapping editor, changed the sorting order of table mappings in the GUI may have displayed a prompt to save the model, even though no changes were made. This has been fixed. ================(Build #2255 - Engineering Case #575516)================ When editing a Synchronization Model, deleting the "timestamp column name" (or another text box's contents) and then trying to switch to another Synchroniation Model without saving changes, would have caused an error to occur. This has been fixed. ================(Build #2252 - Engineering Case #574352)================ If a Synchronization Model was deployed to a location that contained a space in the name, or the deployed model contained a space in the name, then the remote and consolidated script files would not have functioned correctly. This has now been corrected. A workaround is to manually edit the files and quote any file paths that contained spaces. ================(Build #2252 - Engineering Case #574348)================ When deploying a Synchronization Model, and using a secure stream, the Deploy Wizard's Secure Stream Server Certificate page incorrectly referred to an "Identity certificate file" and the File dialog opened by the Browse button only showed certificate files (with .crt and .cer extensions). The wizard should have listed identity files (with a private key as well as a certificate, and .id file extension by iAnywhere convention). This has been fixed. Now the page is called "Secure Stream Server Identity", which refers to an "identity file", and the File dialog by default shows only identity files with .id extension, although listing .crt and .cer files is still an option (in case the .id extension is not used). A workaround is to change the filter to show all file types and choose an identity file. ================(Build #2250 - Engineering Case #573839)================ In the Synchronization Model wizard, when creating a model using a consolidated database and an existing remote database, the mapping editor's column headings could have been incorrect. In particular, the "Consolidated Table" column would have incorrectly been labelled "Mapping Direction". This has been fixed. ================(Build #2243 - Engineering Case #572123)================ When deploying a Synchronization Model on Unix systems, generated .sh files were not created with executable permissions set. A workaround was to run "chmod a+x" on all of the .sh files. This has been fixed. Now executable permission is set for everyone when .sh files are generated. ================(Build #2242 - Engineering Case #572124)================ Opening a previously deployed and saved Synchronization Model file with a new remote database, and then trying to deploy it using the last settings, would have failed with a file error while recreating the remote database. This has now been fixed. A workaround is to manually delete the remote database and transaction log before redeploying. ================(Build #2242 - Engineering Case #572122)================ When a Synchronization Model was created and deployed on Unix systems, the created .sh files had statements like "if [[ value == value ]] ". The "[[", " ]]" and "==" were syntactically incorrect, causing error messages. This has been fixed. Also when running an mlsrv.sh file with an argument that contained spaces, such as "dsn=SQL Anywhere 11 Demo", would have failed. The connection string is now quoted within the file to correct this. ================(Build #2237 - Engineering Case #571671)================ When editing a synchronization model's mappings with the table or column mapping editors, typing a Ctrl or Alt key combination could have initiated editing of the focused cell and either selected or opened a menu. This has been corrected so that typing a Ctrl or Alt key combination only performs the latter operation, and does not initiate editing. ================(Build #2235 - Engineering Case #571282)================ When creating a synchronization model, if a custom download subset was choosen, without specifying one or more tables to join, then the download_cursor events would not have been generated. Instead errors like the following would have appeared as comments in the Events editor: /* * ERROR: Unexpected error encountered while generating event. * Error for: RHS of #set statement is null. Context will not be modified. table-scripts\download_cursor.vm * [line 59, column 8] */ This problem only happened in the New Synchronization Model wizard, not when custom download subset was enabled in the Mappings editor. The problem has been fixed for new synchronization models. To work around the problem, in the Mappings editor change the Download Subset (Dnld. Sub.) to None and then back to Custom, then switch back to the Events editor. ================(Build #2233 - Engineering Case #570923)================ If a database error occurred when trying to install or update the MobiLink System Setup, the error message would have included the SQL statement that was being executed, which could have lead to the message box being too large for the screen. This has been fixed. Now the SQL statement is only shown when the Details are shown. ================(Build #2217 - Engineering Case #569122)================ When deploying a synchronization model to an UltraLite remote database, the batch file generated to run ulsync had an example CONNECTION string that incorrectly used my_db.db, rather than my_db.udb. A correct CONNECTION string in the batch file is now generated. ================(Build #2165 - Engineering Case #562962)================ The QAnywhere message transmission status code which formerly displayed as "Local", is now displayed as "Do_not_transmit". This change was made to match the documentation. ================(Build #2157 - Engineering Case #559653)================ When connected to an authenicated SQL Anywhere database from the MobiLink plug-in in Sybase Central using the "Generic ODBC DSN" option, the connection would have been read-only. This has been fixed. ================(Build #2149 - Engineering Case #558915)================ When deploying a Synchronization Model to file, any characters in .SQL files that are not supported by the OS console code page would be changed to a substitution character, even though the character would have been displayed correctly in the MobiLink plug-in. This has been fixed so that .SQL files now use UTF-8 character encoding. The generated .bat or .sh file is still written using the console code page, since it must run in a console, but the UTF-8 character encoding is now specified when the Interactive SQL utility is invoked in the .bat or .sh file. ================(Build #2147 - Engineering Case #558739)================ After deploying a synchronization model with logical deletes to a DB2 consolidated database, and then synchronizing, either of the following synchronization errors would have occurred for the MobiLink server (depending on the database setup): [IBM][CLI Driver][DB2/NT] SQL1216N Graphic data and graphic functions are not supported for this database. SQLSTATE=56031 [IBM][CLI Driver][DB2/NT] SQL0104N An unexpected token "N''" was found following ", ?, ?, ?, ?, ''". Expected tokens may include: "<space>". SQLSTATE=42601 This has been fixed. A workaround is to deploy to a file and edit the consolidated SQL file to change instances of four single quotes to two single quotes. ================(Build #2137 - Engineering Case #555809)================ The Server Message Store would have been unable to connect to the store after creating it, if an encryption password was specified. This has been fixed. ================(Build #2136 - Engineering Case #555453)================ If an encryption key was specified, it was not possible to create a server message store when running on Linux systems. This has been fixed. ================(Build #2135 - Engineering Case #555054)================ Sybase Central was allowing the modification or deletion of the QAnyNotifier_client notifier. Doing so could have caused problems with QAnywhere. To prevent any problems, it is now only possible to modify the notifier's description, polling interval and event SQL. ================(Build #2135 - Engineering Case #555007)================ Sybase Central could have crashed when attempting to change the visible columns (via View -> Choose Columns...), or column widths, while the MobiLink 11 node was selected in the tree. In addition, when in Model mode, the list of columns under the View -> Sort menu would sometimes not have contained all the displayed columns when the MobiLink 11 node was selected in the tree. Both of these issues have now been fixed. ================(Build #2132 - Engineering Case #554265)================ If more than one message store connection was open, and the connections were broken from outside of Sybase Central, attempting to then disconnect from within Sybase Central could have caused Sybase Central to crash. This has been fixed.

MobiLink - Monitor

================(Build #2571 - Engineering Case #661035)================ When deploying a Synchronization Model for an existing remote database and only deploying to file, the generated Windows batch file would have failed when execute. For example, a "You are not connected to a database" error could have occurred when the batch file tried to apply the generated SQL file to the remote database. This has been fixed. To workaround the problem, change this line in the generated batch file: set CONNECTION=%1 to this: set CONNECTION=%~1 ================(Build #2562 - Engineering Case #658482)================ When a MobiLink Monitor instance that already had a horizontal scroll bar, was connected to a MobiLink server, the Utilization Graph time scale (if Utilization Graph was enabled) would have been different than the Chart time scale. After being connected long enough for the horizontal scroll bar to be redisplayed, the scroll bar position would have been incorrect and the Overview Marquee Tool would have fluctuated between the inconsistent time scales. This has been fixed. A workaround is to use the Marquee Tool, or change the zoom to fix the display, or disable the Utilization Graph to prevent the problem. ================(Build #2560 - Engineering Case #657979)================ The MobiLink Monitor's Zoom To Selection menu or toolbar button might not have panned to the selected synchronization until it was used a second time. This has been fixed. ================(Build #2541 - Engineering Case #653055)================ Any parameters entered on the MobiLink Monitor's command line with a Multibyte Character Set would have been mangled. This has been fixed. ================(Build #2439 - Engineering Case #629597)================ The initial position of the main window for the MobiLink Monitor could have placed the window underneath the Windows task bar. This has been fixed. Note, this problem also affected the Interactive SQL utility, Sybase Central, and the SQL Anywhere Console utility. ================(Build #2439 - Engineering Case #606840)================ When running on Windows Vista or Windows 7 systems, menu items that toggle a property on or off would not always have shown the check mark next to the menu item's text. Similarly, menu items that choose a value from a mutually exclusive set of values would not always have shown a sphere next to the currently selected value. Both of these problems have been fixed. ================(Build #2165 - Engineering Case #562833)================ When the MobiLink Server had a large number of synchronizations running concurrently (in the range of 10000), a MobiLink Monitor connected to it could have become unresponsive, and not displayed new information in a timely manner. This has been fixed. ================(Build #2144 - Engineering Case #554383)================ In the MobiLink Monitor Details Table, if the optional column "connection_retries", or optional columns starting with "download_" or "sync_", were enabled, the column labels for these columns would have been misaligned by one or two columns. A similar problem would have occurred when exporting to a database, where that data was exported to incorrect columns in the database tables. Both of these problems have been fixed.

MobiLink - QAnywhere client

================(Build #2837 - Engineering Case #713390)================ In some circumstances, such as a transient connection error to the database server, the MobiLink Client process (dbmlsync) that was launched by the QAnywhere agent could have terminated prematurely. When this occurred, the QAnywhere agent could not perform any message transmission, and the only remedy was to restart the QAnywhere agent. This has been fixed by adding the capability to the QAnywhere agent to restart dbmlsync if it detects that the dbmlsync process has terminated. ================(Build #2805 - Engineering Case #706554)================ The QAnywhere Agent could have failed to start if it could not automatically upgrade the message store in some cases. This problem was introduced by the changes for Engineering case 696917. For 11.0.1.2781 until 2804, the qaagent would have failed to start with message stores created with a qaagent from 11.0.1.2780 and before. For 12.0.1.3711 until 3725, the qaagent would have failed to start with message stores created with a qaagent from 11.0.1.2781 until 2804, or with a qaagent from 12.0.1.3711 and before, or with a qaagent from 12.0.0. This has been fixed. A workaround for this problem is to recreate the message store using qaagent -si, if that is possible. ================(Build #2605 - Engineering Case #669235)================ When starting the QAnywhere Agent (qaagent) with the command line option "-qi", the MobiLink Listener and the MobiLink Client processes were not also launched with "-qi" options, resulting in system tray icons on Windows Mobile devices. This has been corrected. ================(Build #2575 - Engineering Case #662456)================ On a Windows Mobile device, the QAnywhere Agent (qaagent) would have sometimes given the following error messages at start up: E. 2011-03-14 08:33:50. Error registering with DBLSN code: -1 The error message was displayed in a message box, even when qaagent was executed in quiet mode. This has been fixed. Now, qaagent is more tolerant to dblsn slowness at startup. Also, a message box is not displayed when qaagent is executed in quiet mode (-q or -qi), and the message is logged in the qaagent console and log file. ================(Build #2513 - Engineering Case #645659)================ Under some conditions, the QAManager Close() method could have taken up to a minute to return. This has been fixed. The Close() method will now always complete in a reasonable amount of time. ================(Build #2512 - Engineering Case #645665)================ When a message was received by the QAManager.GetMessage method when the QAManager was opened in AcknowledgementMode.IMPLICT_ACKNOWLEDGEMENT and the QAnywhere Agent was running with automatic policy, it was possible that the acknowledgement would not have been transmitted to the receiver until the next time the message store was synchronized with the MobiLink server. This has been fixed. Now the received message is immediately acknowledged. ================(Build #2490 - Engineering Case #640241)================ In rare circumstances, the QAnywhere C++ client could have deleted a received and acknowledged message before the acknowledged status was transmitted back to the sender. This has been fixed. ================(Build #2438 - Engineering Case #629277)================ The QAnywhere Standalone Clients would not synchronize when expected to in two cases. The first case occurred if a sync request was made while another synchronization was already taking place. It was expected that another sync will begin once the current one has finished, but this did not always happen. The second case occurred if a sync request was made while using a Transactional Manager. It was expected that only sync requests resulting from changes to the database will be delayed until the transaction is committed. However, this delay was occurring for other types of sync requests as well. These two cases have now been fixed. ================(Build #2414 - Engineering Case #624352)================ When run on a Windows CE device, the QAnywhere Agent for UltraLite would have failed to connect with a MobiLink server running on the desktop through ActiveSync, if no -x option was specified. The QAnywhere Agent was using "host=localhost" for its stream parameters when no -x option was specified. Now, the agent does not specify stream parameters in this case, letting the UltraLite sync stream choose the default host IP address. ================(Build #2410 - Engineering Case #622720)================ Application using the Ultralite runtime would have sometimes looped endlessly following a synchronization stream error. This has been fixed. ================(Build #2379 - Engineering Case #616015)================ The QAnywhere Agent could have failed with the error: "Internal error: Too many MESSAGE ... FOR CONNECTION messages". This has been fixed. ================(Build #2316 - Engineering Case #590374)================ Calling the QAManager.close() method, immediately after receiving a message asynchronously, could have caused the manager to hang indefinitely. This has been fixed ================(Build #2297 - Engineering Case #584873)================ If the QAnywhere Agent for Ultralite was running using the automatic policy, and a message was sent during a loss of communication with the QAnywhere server, then the message would not have been sent upon re-establishing communication. This has now been fixed so that and unsent messages will be sent shortly after that connection is re-established. A workaround for this problem is to perform an action that will trigger a synchronization (eg. send another message, call triggerSendReceive, etc.) ================(Build #2282 - Engineering Case #583194)================ The QAnywhere Standalone Clients were not adhering to the synchronization policies as they are defined in the documentation. In several scenarios, the clients would trigger synchronizations even though the policy requirements were not satisfied, although it was never the case that a synchronizations didn't occur when one should have. This has been fixed so that the clients now synchronize only at the appropriate times as defined by the policies. ================(Build #2253 - Engineering Case #574698)================ The QAnywhere Java clients could have gone into an endless loop, with 100% CPU usage, if it attempted to uncompress a message whose content has become somehow corrupted. This has been fixed so that the clients now return a suitable error message to indicate that it failed to retrieve the message. ================(Build #2253 - Engineering Case #574693)================ The QAnywhere Agent for UltraLite would have given a misleading error message if an invalid username or password was specified in the connection string. The error message that was being generated looked like: Internal error: SQLCODE: -108, SQLSTATE: [] Source statement: SET OPTION isolation_level=read_committed QAnywhere Agent failed to initialize message store This has been fixed so that the agent now returns error code -103 as expected ================(Build #2246 - Engineering Case #572968)================ A small amount of memory was being leaked on every synchronization by the QAnywhere Agent for Ultralite. This has been fixed. ================(Build #2218 - Engineering Case #616017)================ The QAnywhere Agent would have failed to upgrade 9.0.2 message stores that were created with SQL Anywhere 9.0.2 builds 3654 and later. This has been fixed. ================(Build #2211 - Engineering Case #569012)================ The "UserAgent" HTTP header for QAnywhere/MobiLink communications previously only specified "QAnywhere/11.0.1", and "QAnywhereUL/11.0.1", for SQL Anywhere and UltraLite clients respectively. It did not differentiate between data synchronization and listener components. This has been fixed. Now, the header specifies "QAnywhereSync/11.0.1" for a SQL Anywhere data sync client, "QAnywhereULSync/11.0.1" for a UltraLite data sync client, and "QAnywhereLsn/11.0.1" for a MobiLink listener client. ================(Build #2184 - Engineering Case #565667)================ The methods QAManagerBase.SetMessageListener and QAManagerBase.SetExceptionListener would have throw a QAException with error code COMMON_NOT_OPEN_ERROR, when called before an Open() call. This has been fixed. Now, SetMessageListener and SetExceptionListener can be called any time after the creation of a QAManagerBase object, as in earlier versions of QAnywhere.

MobiLink - QAnywhere server

================(Build #2537 - Engineering Case #651880)================ The reply-to address for messages originating from a Weblogic 10.3 JMS server were formatted in such a way that they could not have been resolved by the JMS connector. This has been fixed. ================(Build #2372 - Engineering Case #614034)================ When a 9.0.2 QAnywhere client synchronized, the MobiLink server would have displayed the following errors: Expecting 1 parameters in script, but only found 4: update ml_qa_global_props set modifiers = ?, value = ? where client = ? and name = ? Unable to open upload_update . This has been fixed by a change to the upload_update script for the table ml_qa_global_props, version ml_qa_2. ================(Build #2365 - Engineering Case #611361)================ Using Sybase Central to cancel a system message that resided in a QAnywhere Client database would have resulted in an unhandled Null Pointer Exception. This has been fixed ================(Build #2327 - Engineering Case #593120)================ The QAnywhere server could have stopped sending and receiving messages with an Enterprise Messaging Server, through its JMS connector, when connectivity to the EMS was interrupted and subsequently restored. This has been fixed. ================(Build #2307 - Engineering Case #585035)================ The QAnywhere server could have stopped sending/receiving messages with an Enterprise Messaging Server, through its JMS connector, when a SQLException was thrown by the JDBC driver. This has been fixed. Where possible, the QAnywhere server should recover gracefully from exceptions thrown by the JDBC driver and continue processing messages. ================(Build #2222 - Engineering Case #564639)================ When MobiLink servers with QAnywhere messaging were set up in a server farm, push notifications could have stopped working in some circumstances. In particular, if the MobiLink server(s) handling synchronization requests from QAnywhere clients were different from the server that initiated the push notification (as would have been the case if the notifications were the result of outbound JMS messages in a server running a JMS connector), only the first push notification would have been sent, and no further notifications would have been sent. This has now been fixed. It should be noted that, in a MobiLink server farm deployment, there could be a latency of at most the automatic rules evaluation period to send a push notification to a client as a result of an outbound message to that client. This is due to scalabilty factors in a situation where there is a high volume of outbound messages being processed by the MobiLink server. ================(Build #2214 - Engineering Case #568986)================ Performing a PutMessage operation from the Java QAnywhere Client using UltraLite, or from the Standalone Java QAnywhere Client, would have resulted in a memory leak equal to the size of the content of the message. This has been fixed. ================(Build #2188 - Engineering Case #558510)================ A table in the QAnywhere for Ultralite schema could have been created improperly, resulting in a failure to initialize the message store with the error (-131) "param 1: timestamp". This has been fixed ================(Build #2166 - Engineering Case #563143)================ When a QAnywhere consolidated database contained a large number of messages that satisfied a delete rule, and the MobiLink server was shut down, the server would not have actually terminated until all messages had been deleted, which could have been a very long period of time. When delete rules are executed, old messages are deleted in batches of 100 at a time until there are no more messages satisfying the delete condition. However, there was no mechanism to stop the execution of delete rules on MobiLink server shutdown. Such a mechanism has now been added for delete and archive rules. ================(Build #2144 - Engineering Case #557938)================ It was possible for a deadlock to have occurred in the database server if the QAnywhere server was performing delete rules and archiving messages at the same time. Furthermore, the exception thrown by this deadlock exposed another problem in the QAnywhere server error handling where it was possible for a transaction to be left open, causing other connections to block due to unreleased table locks. Both of these issues have been fixed. ================(Build #2141 - Engineering Case #556974)================ Using a QAnywhere JMS connector to communicate with a Websphere MQ JMS provider could have resulted in the following two issues: - The MobiLink server could have reported the error "The property name 'JMSTimestamp' is reserved and cannot be set." when Sending a message from a QAnywhere application to the JMS connector. - The ReplyToAddress of a QAnywhere message originating from a Websphere JMS provider could have contained a malformed queue name. Both of these issues have been corrected. ================(Build #2120 - Engineering Case #551751)================ Attempting to use the QAnywhere Server to cancel a message in an Ultralite Client Message Store would have failed with a NullPointerException. This problem was more likely to occur when using the Sybase Central plugin to connect to an Ultralite client database and then attempting to cancel a message. This has been fixed. ================(Build #2114 - Engineering Case #550080)================ In the Sybase Central QAnywhere Plugin, if when connected to a server message store a client was created, and then the view refreshed, the newly created client would not have been displayed. This has been fixed.

MobiLink - Relay Server

================(Build #2776 - Engineering Case #701382)================ The Relay Server and the Outbound Enabled log files contained an error in the UTC time zone offset log line. This has been fixed. The correct log line now reads: "Time zone offset from UTC in minutes:" ================(Build #2773 - Engineering Case #701212)================ The Relay Server responded with an HTTP 401 status code when the client accessing the backend farm didn't fulfill the client security requirement specified by the client_security property in the backend_farm section in the Relay Server configuration. The message had a typo that has now been corrected to: "The backend farm rejected this client security" ================(Build #2755 - Engineering Case #697289)================ When the Relay Server extension name in the URL was specified with some uppercase characters, the Relay Server extension may have crashed. The Relay Server would have recovered, but active requests involved in the crashing process would have failed. This has been fixed so that uppercase character are now acceptable. Note: The farm name and server id in the URL remain case sensitive. ================(Build #2753 - Engineering Case #697450)================ The Relay Server Outbound Enabler may have crashed in a Relay Server farm environment. This has been fixed. ================(Build #2725 - Engineering Case #692346)================ The Relay Server Outbound Enabler would have crashed after showing the usage text due to an invalid parameter. This has been fixed. ================(Build #2689 - Engineering Case #686415)================ Relay Server shutdown may have taken unnecessarily long, or even crashed. This would have occurred if the shutdown was requested when a new client session was waiting for backend server assignment while all Outbound Enablers of the backend farm had been disconnected. This has been fixed. ================(Build #2688 - Engineering Case #686237)================ Relay Server web server extensions may have crashed if the URL contained redundant leading forward slashes. This has been fixed. ================(Build #2680 - Engineering Case #684808)================ When a back-end server aborted reading a request, for example due to some early detectable protocol error, the Outbound Enabler may have caused further protocol errors later on for other requests. This has been fixed. ================(Build #2680 - Engineering Case #684721)================ The rs_client.dll may have crashed when parsing a malformed response header. This has been fixed so that the Relay Server will response with an http 400 instead of crashing. ================(Build #2665 - Engineering Case #682648)================ When using the local Relay Server reconfiguration utility on Linux Apache to change the Relay Server configuration, or to archive the Relay Server log, the utility would not exit once complete. This has been fixed. ================(Build #2657 - Engineering Case #681059)================ The usage text for the Relay Server Outbound Enabler was incorrectly listing 'identity_name' as a value for the -cr option. The value 'identity_name' has now been removed . ================(Build #2657 - Engineering Case #680920)================ The ISS Application Pool Process (w3wp.exe) may have crashed some time later after handling a request with a URL ending with the Relay Server extension. ================(Build #2628 - Engineering Case #675317)================ Under extreme load conditions, the Relay Server may log errors on shared memory operations. This logging operation may have crashed the web server worker process. Also, for 12.x Relay Servers, the line label for such logging has the format of <pricessId.threadId.ShmDebug>. The threadId could have been wrong. Both of these problem have now been fixed. ================(Build #2624 - Engineering Case #674187)================ A web server worker thread may have crashed when it failed to load the localized language resource (e.g dblge12.dll). The reasons for the failure may have included the file not being found due to path and registry info, or the account associated with the worker did not have permission to read the resource. The symptom was a truncated log line with a missing end-of-line. This has been fixed so that the crash will no longer occur and an unlocalized error message is displayed regarding the loading error. ================(Build #2624 - Engineering Case #674120)================ A web server worker may have crashed when logging lengthy debug messages that had not been localized. This has been fixed. ================(Build #2603 - Engineering Case #668791)================ When the Relay Server Outbound Enabler failed a backend connection test, it may have crashed, or have been unable to recover even after the backend became available again. This has been fixed. ================(Build #2593 - Engineering Case #666845)================ The Relay Server admin and monitor extensions may have slowly leaked memory. Eventually, admin or monitoring requests would have failed without any trace in the HTTP error log, IIS access log, or in the Relay Server log. This problem has been fixed so that recycling is no longer necessary. To workaround this problem, users may setup application pool recycling for the admin and monitoring extension. ================(Build #2583 - Engineering Case #664283)================ Relay Server enable/disable events were not broadcast to connected Outbound Enablers. For example, disabling the last Relay Server from a Relay Server farm was not going to suffer the issue described in Engineering case 664284, but when adding a Relay Server to the Relay Server farm, it would also not have woken up the Outbound Enablers to start utilizing the new Relay Server. The user workaround is to restart the Outbound Enabler. This problem has been fixed. ================(Build #2583 - Engineering Case #664139)================ When a Relay Server starts up, its description was logged and the startup verbosity was applied properly, but those values were not stored correctly for later consumption. Such as for the admin tool to export the configuration or for the next configuration update to properly determine if an updated was required. This problem has been fixed. ================(Build #2583 - Engineering Case #661112)================ It was possible for synchronizations to fail if any of the 'certificate_name', 'certificate_company', or 'certificate_unit' parameters were supplied, even though the value of these parameters matched the corresponding field values in the server's certificate, if they were encoded as Unicode in the server's certificate. This has been corrected. ================(Build #2581 - Engineering Case #663835)================ When the Outbound Enabler shut down, on going client requests may have taken 3 times the application timeout value to abort. This has been fixed. ================(Build #2577 - Engineering Case #663061)================ Proxy support for the Relay Server Outbound Enabler may only have worked with HTTPS against some HTTP 1.1 proxy servers. The down channel using HTTP instead of HTTPS would have connected successfully at first but then would have been dropped by the proxy after a period of being idle. This problem is proxy specific and it does not affect all HTTP proxy environments. This problem has been fixed in the Relay Server so that an update to the Outbound Enabler is not required (see Engineering case 662749). The workaround is to use HTTPS, or apply the Outbound Enabler fix from case 662749. ================(Build #2572 - Engineering Case #661849)================ When using the Service utility (dbsvc) to start a Relay Server service with a large configuration on a slow machine, it may have reported startup errors while the service was still in the pending start state. A fix was made to the Relay Server to correct this problem. ================(Build #2570 - Engineering Case #661225)================ A network environment that was sensitive to HOST header inspection on http traffic, may have caused the Outbound Enabler to fail to connect to the Relay Server, or it may have connected to the wrong server. This has been fixed. ================(Build #2570 - Engineering Case #660995)================ When connected to a Relay Server, and no Outbound Enabler providing the backend service had connected yet, the connection was expected to timeout within the application timeout time specified by the client. However on IIS7, some J2SE http clients may have become stuck writing to a server that was no longer reading and eventually failed the write and then perform a delayed internal retry without processing the response sent by the web server. This change modifies the Relay Server to provide the expected fail fast experience according to the timeout against such J2SE clients. ================(Build #2557 - Engineering Case #656716)================ The Relay Server could have leaked heap memory under the following conditions: - On the response to the first HTTP request in the session, or specifically, anytime a cookie was set, if the response was long and came in small packets. - A small number of bytes were leaked on Upchannel and Dnchannel creation. This has been fixed. ================(Build #2555 - Engineering Case #657026)================ The MobiLInk server would immediately refuse to startup, if it could not make any connections to the consolidated database, even when it was running as a Windows service. This behaviour has changed so that the MobiLink server will retry to make connections, when it is running as a Windows services. The retries are once a minutes for ten minutes. If it still cannot make a connection after that, it will refuse to startup. ================(Build #2540 - Engineering Case #652735)================ When a Relay Server shuts down, it notifies connected Relay Server Outbound Enablers (RSOE) to perform an internal shutdown before the RSOE enters recovery mode. The RSOE also notifies the Relay Server via the down channel when the the RSOE shutdown is completed. The HTTP subsystem used on IIS7.5 prevented a Relay Server from receiving the shutdown notification reliably and in turn caused an unnecessary hard shutdown of the Relay Server after a 100 sec delay. This has been fixed so that the Relay Server now handles this case properly as a graceful soft shutdown without a delay. ================(Build #2540 - Engineering Case #652382)================ The Relay Server did not work with a Relay Server Outbound Enabler (RSOE) that was behind an HTTP 1.0 proxy. The Relay Server has now been fixed to adapt to HTTP version downgrades done by an HTTP 1.0 proxy, and is needed when working with a 12.0.1 RSOE in conjunction with a HTTP 1.0 proxy. ================(Build #2538 - Engineering Case #652243)================ MobiLink clients using persistent HTTP 1.0 connections may fail occasionally when using the Relay Server. The failure was isolated to synchronizations that ran into a rare timing problem. This has been corrected. ================(Build #2526 - Engineering Case #649044)================ When a backend server drops a connection without providing any HTTP response, IIS ver7 may inject "200 OK" as a response to the client. This may have caused MobiLink clients to be fooled to spin into an infinite loop by repeatedly getting 200OK at high frequency. This change will allow the Relay Server to detect this case and explicit send a "400 Bad request with on backend server response" response. ================(Build #2513 - Engineering Case #645223)================ The Relay Server for IIS7 could have unexpectedly disconnected persistent http connections after finishing relaying a server response. This has been fixed. ================(Build #2507 - Engineering Case #644112)================ When the backend machine was under heavy load, a standalone Relay Server Outbound Enabler may have reported the following internal error HandleNotification: Error receiving for sidx=<session_index> system error ({error code}) With this change, the error is now less likely to occur. ================(Build #2505 - Engineering Case #643812)================ When a backend server was using an id longer than 44 characters, the client may not have been able to access the backend server. This has been fixed. ================(Build #2501 - Engineering Case #643019)================ In rare situations, data corruption may have occurred during up channel renewal when the backend server was under high load. By default, channel renewal occurs whenever 2G of data has been uploaded to the Outbound Enabler. Since the up channel renewal mechanism has been replaced by chunk encoding in the version 11.0 Apache Relay Server, and all IIS Relay Servers, this issue only applies to version 12.0 Apache or IIS Relay Servers working against older Outbound Enablers (earlier than 11.0.1.2446) which don't support chunking. Up to 64k of upload data could have been lost when this problem occurred. This problem has now been fixed. ================(Build #2499 - Engineering Case #642827)================ The Relay Server for IIS7 would have failed to stream Afaria downloads, and was causing the Afaria client to timeout. This has been fixed. ================(Build #2482 - Engineering Case #638473)================ If a Relay Server Outbound Enabler (rsoe) was successfully connected to a Relay Server, and the Relay Server was restarted while the rsoe was still running, then the server extension of the Relay Server could have crashed upon receiving the rsoe's new up channel connect request. This crash would have occurred if the rsoe tried to connect with configurations that invalidated the (already running) rsoe authentication, such as changing the farm or server id, that the rsoe was using. This has been fixed. ================(Build #2481 - Engineering Case #638268)================ When connecting a device that supports the OMA Device Management protocol directly to an Apache based Relay Server, the device would have displayed an error stating “Invalid Host Address”. The Afaria Server still provisions the device, but the Afaria OMA-DM Server logs state: "... authentication: no credentials in message “. When sending the response back to the client, the Relay Server (when run on systems other than Linux) was incorrectly setting the content-type header as text/plain instead of application/vnd.syncml.dm+wbxml. This has now been fixed. ================(Build #2480 - Engineering Case #638153)================ If none of the $SATMP, $TMP, $TMPDIR or $TEMP environment variables were set and the Relay Server State Manager (rshost) was started without the -o command line option specified, rshast would have failed to start. Under these conditions, rshost uses '/' as the root directory and fails due to write premissions. This has been fixed. ================(Build #2465 - Engineering Case #635062)================ The Relay Server Outbound Enabler (RSOE) could have failed to connect to an Apache Relay Server, with the error message "HTTP chunk length too long". The same RSOE would not have reproduced this error with a Microsoft IIS webserver. This has been fixed. ================(Build #2458 - Engineering Case #633685)================ Under rare situation, the Relay Server Outbound Enabler (RSOE) may have crashed during channel renewal. This has been fixed. ================(Build #2451 - Engineering Case #632434)================ Version 11.x of the Relay Server is not compatible with version 7 of Microsoft's Internet Information Server (IIS7). The Relay Server has now been updated to support IIS7. New IIS7 set up instructions will be available in %sqlany11%\MobiLink\RelayServer\IIS\iis7_setup.txt. ================(Build #2427 - Engineering Case #627403)================ If the Relay Server Outbound Enabler (RSOE) lost connectivity to the Relay Server, and was attempting to restart the worker threads at the same time that it was about to time out a thread working an active request, it was possible for the RSOE to have crashed. This has now been fixed. ================(Build #2414 - Engineering Case #623805)================ The Relay Server State Manager (rshost) could have crashed if initialization failed before a log file was successfully created. Failure to create the log file, empty config file or missing required sections, were some of the conditions that could have lead to the crash. This has been fixed. ================(Build #2384 - Engineering Case #616997)================ Relay Server Ooutbound Enabler could have been slow in connecting to a backend server when it used a host name, instead of a dotted IP address, in the -cs option. This connect performance issue has been fixed. Using a host name in the -cs switch should no longer causes performance issues. The workaround is to use dotted ip address. ================(Build #2380 - Engineering Case #616239)================ Under sustained high load from a Relay Server, the Outbound Enabler may not have performed well enough, resulting in client timeouts. A performance improvement has been made to the Outbound Enabler to correct this problem. ================(Build #2379 - Engineering Case #616040)================ When the Relay Server Outbound Enabler console was opened with high verbosity logging set, the Outbound Enabler performance could have been significantly degraded. This has been fixed by removing log information at verbosity level 1 and above from the console display, but leave them in the log file only. To restored the old behavior of displaying all information to the console, use the new -dl command line option. ================(Build #2379 - Engineering Case #615861)================ The Relay Server Outbound Enabler was over using memory for buffering upward data. This has been fixed. ================(Build #2378 - Engineering Case #615813)================ The Relay Server does not support running more than one Outbound Enabler per backend server if they are started with the same backend server id. If this limitation for a unique backend server id was violated, some traffic to that backend server may either have failed, or suffered slowness. This problem has been fixed. The Relay service to other backend servers is no longer affected by this issue. The second and subsequent instances are not functional. ================(Build #2373 - Engineering Case #615828)================ The Relay Server Outbound Enabler (RSOE) could have sporadically crashed on startup. This has been fixed. ================(Build #2373 - Engineering Case #614976)================ The Relay Server Outbound Enabler (RSOE) may not have relayed backend server responses when under a sustained high load of requests. The problem was more likely to occur when the network between the client and Relay Server (RS), as well as the network between the RS and the RSOE, were both very fast while the backend server machine was relatively slow in processing. Turning on high RSOE verbosity in such situation would have caused this problem to be more likely to occur. A fix has now been made in the RSOE to solve this problem. ================(Build #2373 - Engineering Case #614245)================ When more than one Relay Server Outbound Enabler (RSOE) in the same backend server farm used the same server id to connect to the Relay Server, the Relay Server would have reported that there was a conflict, and let the newer RSOE instance win over the existing RSOE connection. There was a small chance that the old RSOE connection may have reported the error "Internal error! Freeing already freed memory!" during the disconnect process. Although the memory manager in versions 11.0.1 2335 or higher of the Relay Server is immune from such memory problems, and will keep working normally, a fix has been made to further stop the cause of this memory problem in order to stop the internal error from occuring at all. ================(Build #2362 - Engineering Case #609944)================ When running the Relay Server Outbound Enabler (ROSE) and the backend server on slow machines, the RSOE may have failed to notify the Relay Server (RS) that the backend connection for a non-persistent http request had been closed, which would have caused the RS to hold on to resources for an extended period of time, making the RS less scalable. This problem has been fixed. ================(Build #2361 - Engineering Case #610141)================ When the Relay Server State Manager was run on Linux with the -os command line option, it would have generated many small archive output log files once the archiving process had started. The logger's size counter wasn't being reset after successfully generating the first output archive file. This has now been fixed. ================(Build #2357 - Engineering Case #608747)================ The Relay Server Outbound Enabler may have reported session mismatch errors when an Afaria client disconnect their POST channel. This has been fixed. ================(Build #2353 - Engineering Case #605873)================ Two minor problems have been corrected: 1) The logging of unilitialized session indexes has been fixed 2) Reword logging of backend socket closing activities to "DoneReceive EOF" instead of "disconnecting" or "socket close" ================(Build #2350 - Engineering Case #606826)================ An incomplete startup of the Relay Server on Linux due to resource limitations, may have left many persistent System V semaphores behind. This would have caused a permanent semaphore resource drain to the system until they were either manually deleted, or the system was rebooted. This issue has now been fixed. ================(Build #2350 - Engineering Case #606658)================ When shuting down the Relay Server for Apache on Linux, one persistent System V semaphore for IPC was being leaked between Relay Server components. This has been fixed. ================(Build #2347 - Engineering Case #606660)================ When working with clients that don't support communication liveness, such as MobiLink 9.x clients, the Relay Server will timeout a client after being idle for 8 minutes, if the web server has not timed out the client earlier. Increasing the web server liveness timeout will not resolve the situation. The solution is to use the IAS-RS-App-Timeout-Minute header in the http request. For example, to set a 20 minute timeout for a big download with a MobiLink version 9.x client, simply add custom_header=IAS-RS-App-Timeout-Minute:20 to the HTTinkP synchronization communication option. This timeout header is an existing but undocumented feature in all released version of the Relay Server. There is no software change involved. ================(Build #2346 - Engineering Case #605874)================ When the Relay Server Outbound Enabler (RSOE) timed out an up channel connection, the RSOE would have recovered the connection, but it may have resulted in an invalid opcode being received in error from the Relay Server, and then cause the RSOE to disconnect both the up and down channels and restart. This is now fixed so that the RSOE will handle the reconnect properly without causing a more substaintial restart before restoring the service. ================(Build #2345 - Engineering Case #605818)================ The Relay Server Outbound Enabler (RSOE) may not have issued timely liveness packet on the down channel when the backend server was loaded. This may have caused a down channel read timeout on the Relay Server. Also, the Relay Server may not have issued timely liveness packets on the up channel when the it was loaded, This may have caused an up channel read timeout on the RSOE. Both of these problems are now fixed. ================(Build #2344 - Engineering Case #605843)================ When non-persistent http was used, and there was a significant latency for the backend server to close the socket after writing all response bytes and before the next request of the same session come into the Relay Server Outbound Enabler (RSOE), the RSOE may have mistakenly failed the new request when the Relay Server timed out waiting for the close of the previous request. This has been fixed. ================(Build #2343 - Engineering Case #605412)================ If client_security (or server_security) was set to 'on' in the Relay Server for Apache running on Linux, the Relay Server may have unnecessarily failed the client's (or Outbound Enabler's) HTTPS requests. This has been fixed. ================(Build #2343 - Engineering Case #605071)================ The Relay Server, in general, is not forward compatible with future versions of the Relay Server Ooutbound Enabler (RSOE). Changes have now been made which will allow future version of RSOE to fallback to a protocol version that is compatible with the Relay Server in use at the time. New Relay Servers will no longer reject connections from newer RSOEs, but will request a protocol version adjustment. This fix also contains an independent change that allows the RSOE to work with legacy 11.0.x Relay Servers without patching the Relay Server with the capability to request a protocol version adjustment. Heterogeneous Relay Server farms, with a mix of new and old Relay Servers, has also been enabled by this change. This can be useful in progressive Relay Server farm upgrades. Here is the compatibility matrix following this change: RS RS 11.0.0.ga-1529 11.0.0.1530 and up 11.0.1.ga and up 12.0 beta and up RSOE 11.0.0.ga-1529 YES YES RSOE 11.0.0.1530 and up NO YES 11.0.1.ga and up 12.0 beta and up ================(Build #2342 - Engineering Case #605032)================ Under rare situation, the Relay Server may have notified the Relay Server Ooutbound Enabler (RSOE) to disconnect a stale backend connection when the HTTP response had been completed, but the RSOE didn't indicate that the backend server connection had been completed within a tolerable latency. When this happened on a request that was not the first one of a HTTP session, the Relay Server didn't fill in available OE and session indexes to optimize the lookup of the backend session, and caused the RSOE to perform extra work to lookup the session. The RSOE was also logging misleading invalid indices because of this. This problem has now been corrected. ================(Build #2342 - Engineering Case #605029)================ When the Relay Server Outbound Enabler (RSOE) loses a connection to the Relay Server, it will attempt to recovery the connection at a rate controlled by the -d switch. The reattempt may have unnecessarily failed, causing more reattempts before the service was restored. This has been fixed. The fix also improves error reporting on the RSOE so that it will report the HTTP response code and message in an error in cases when the web server rejects the request before it reaches the Relay Server extension. ================(Build #2336 - Engineering Case #595745)================ After a session was interrupted due to client disconnecting from the Relay Server, the Relay Server Outbound Enabler (RSOE) may have logged cancelled operations on the session using incorrect backend connection context information. This has been fixed. Along with this fix, a typo was corrected where sfp was being logged as spf. ================(Build #2336 - Engineering Case #595744)================ After an HTTP request failure, the Relay Server Outbound Enabler (ROSE) would have unnecessarily failed an HTTP client retrying an HTTP request on the session using the acquired session cookie. This has been fixed by adding support in RSOE for this kind of resume. ================(Build #2336 - Engineering Case #595502)================ The Relay Server may have incorrectly reported that shared memory was exhausted and then failed to relay further traffic after a rare memory abuse. This fix improves the memory manager by detecting and reporting incidents when a block of shared memory is freed by more than one process, and will allow the Relay Server to continue following the abuse. The detection was added without introducing extra computational overhead. The error report has the following format in the relay server log: E. 2009-10-22 14:39:32. <1036.440.ShmDebug> Internal Error! Freeing already freed memory!: 00011390 The error message is useful in reporting issue to tech support so that we can identify defects in the higher level logic and eliminate the source of the rare abuse. ================(Build #2333 - Engineering Case #595104)================ The Relay Server may be set up to autostart by the first RSOE connection. Concurrent autostarts were unnecessarily failing some of the RSOE connections that attempted to spawn the state manager (rshost.exe), but lost the race. This left those losing RSOE connections in an idle failed startup state, requiring users to restart them. The following error message would have been shown on the RSOE console and log file: 400 Auto started rshost.exe but it exited with return code <?>. This has been fixed by suppressing the startup error for the failed connections, as long as the connections can attach to the stage manager started by others. ================(Build #2333 - Engineering Case #594914)================ The Relay Server had been relying on standard http cookie reflection or header reflection from the client to maintain affinity of the http session. However, some mobile devices suffer from thin http support, where both cookie and header reflection are not supported. So, the Relay Server Outbound Enabler (RSOE) now injects an IAS-RS-AFQ header at the first HTTP request of all session. The value of the header is the affinity token for the rest of the request belonging to the session. The backend server is responsible for transporting the affinity token to their client in their application protocol. The client is responsible for inserting the following query parameter to the query string of the subsequent responding URL. IAS-RS-AFQ=<affinity_token> The relay server will respect this affinity control when affinity information was not found in standard cookie nor in proprietary header. ================(Build #2332 - Engineering Case #594922)================ The Relay Server at log level 3+ will produce packet header logging in the RS-OE protocol. The Relay Server at log level 5+ will also produce packet header logging plus the hex dump of the payload. This has been changed to now suspress level 3 packet header logging when verbosity level is 5 or above. ================(Build #2332 - Engineering Case #594917)================ Backend farm Outbound Enabler security requirements and client security can be specified by client_security and/or backend_security properties of the backend farm in the Relay Server configuration file. These setting were not enforced though until the first Relay Server configuration update. This problem has now been fixed so that these setting are enforced immediately after Relay Server startup. ================(Build #2331 - Engineering Case #595624)================ The Relay Server Outbound Eeabler (RSOE) will verify routing of the relayed packets, and issue session mismatch errors when a routing issue occurs. One of the verifications was checking against a session finger print (sfp). The error message contained useful elements like session index, observed sfp and expected sfp, but the message being logged in the RSOE log was mangled so that it was not possible to use the detail information in the message to diagnose routine issues effectively. This has now been corrected. ================(Build #2270 - Engineering Case #580636)================ The Relay Server can be started automatically by the first Relay Server Outbound Enabler (RSOE) connection, but the connection may have failed within 1.5 seconds if the Selay Server's configuration file was too big. Thhe Relay Server will eventually have finished starting, but the RSOE would not have attempted to reconnect to the Relay Server. This has been fixed by allowing 15 seconds for the Relay Server to startup before giving up the the RSOE connection. RSOE reconnect attempts will be fixed in a separate issue. ================(Build #2262 - Engineering Case #576448)================ When run on Unix systems, if the redirector was configured to route to more than one backend, and one of the backend servers went down, the redirector could have failed to route requests to the live backend. In this case, the redirector would have added the error message "No machine is available to handle request" to the error log. This has been fixed. ================(Build #2255 - Engineering Case #575539)================ If the Relay Server Outbound Enabler (RSOE) was connected to an Apache RelayServer, and then RSHOST was shutdown through a command line (rshost -s), then this would have caused the RSOE's up channel to enter a loop and issue an "Invalid opcode!" error message. This has been fixed. ================(Build #2226 - Engineering Case #570144)================ The Relay server's configuration file has a 64k size limit that, if exceeded, can caused the Relay Server to fail on start up. This limit has been removed. This limit was not affecting dynamic growth of configuration. ================(Build #2221 - Engineering Case #575538)================ When the Relay Server Outbound Enabler's attempts to re-establish its channels to a Relay Server failed (for example, RelayServer still down), it could have occasionally quit further attempts. This has been fixed. ================(Build #2218 - Engineering Case #569516)================ The Relay Server Outbound Enabler (RSOE) may have produced bad http requests. While relaying a packet of a http request, the RSOE would have reconnected to the backend server when the connection was lost, even if it was at the request boundary, producing a bad http request. This has been fixed by introducing a reconnect retry at request boundaries to improve robustness, and replace reconnect with an error for non-boundary packets. ================(Build #2214 - Engineering Case #569513)================ When an error or a timeout was detected between request phases of an http request-response cycle, the Relay Server outbound Enabler was not disconnecting the backend in a timely manner. This has been corrected. ================(Build #2211 - Engineering Case #569520)================ Dynamically added backend server farms, or servers, may have been incorrectly disabled. This is fixed. ================(Build #2176 - Engineering Case #577984)================ When the Relay Server Outbound Enabler (rsoe) was shutdown, the message "<UpChannel-xxxx> networkRead: interrupted error errCode: 218, sysCode: 0" was written to the log file. This is a lower level error indicating the blocking read operation had been interrupted. This error message is redundant and confusing, and has been removed. An informational message will still be printed at a higher level. ================(Build #2166 - Engineering Case #563132)================ An adddition fix was needed to avoid a boundary mis-routing problem introduced by the original fix for Engineering case 561378. ================(Build #2164 - Engineering Case #563118)================ If a communication error occurred at an early stage of the Relay Server Outbound Enabler (rsoe) attempting to establish the up channel with the Relay Server, the RSOE would have continued to fail to reconnect forever. This has been fixed. The workaround is to restart the RSOE. ================(Build #2164 - Engineering Case #563117)================ When the Relay Server Outbound Enabler (rsoe) was started with http instead of https (i.e. -cr https=1;... ), it would not have been able to communicate with a newly added relay server. The workaround is to restart rsoe. This has been fixed. ================(Build #2157 - Engineering Case #561816)================ The Relay Server State Manage (rshost) would have crashed if its configuration file was missing or invalid, or if a non-switched command line argument was used (i.e. one that was not preceded with '-' in Unix, or '-' or '/' in Windows). This has been fixed. ================(Build #2156 - Engineering Case #561378)================ The Relay Server Outbound Enabler could have logged one of the following error messages in the log file: "Failed to retrieve session[x]" or "Session mismatch: session[x].snum=y instead of z" or "Session mismatch: session[x].sfp=y instead of z". when a client unexpectedly disconnected from a Relay Server in the middle of sending a request, or receiving a response. These errors would have happened in a Relay Server farm environment with more than one Relay Servers in the farm and in particular, in the general case when using an Afaria client or a QAnywhere client running a listener. This has now been fixed. ================(Build #2119 - Engineering Case #552638)================ The Relay server may have run out of shared memory when under high load. This was more likely to have occurred when the Relay Server was hosting a large number of backend servers. This has been fixed by leaving spare room in shared memory according to the startup configuration. The user specified amount of shared memory is left for relaying traffic.

MobiLink - SA Client

================(Build #3014 - Engineering Case #743027)================ HTTP Basic authentication in persistent HTTP synchronizations could have reported the error: -1305: MobiLink communication error -- code: 216. This has been fixed. Note, this fix also applies to UltraLite and UltraLiteJ for Android. ================(Build #2991 - Engineering Case #740636)================ The MobiLink user password and new password could have been shown in MobiLink server log files in plain text. This would have occured if the password and new password, as named-parameters, were referenced in any user authentication scripts, and the MobiLink server was running with the –vc command line option. This as been corrected. Now the MobiLink server will replace the password and new password with asterisks "*", and then log them. ================(Build #2912 - Engineering Case #726952)================ The MobiLink Client would not have reported error messages generated by the MobiLink server for a synchronization where progress offsets were checked against the server values at the beginning of the synchronization and found to be different from the server side values. This has been fixed. ================(Build #2902 - Engineering Case #724701)================ When MobiLink clients starts up, it deletes temporary files left by any previous instance of the software that might have exited abnormally. This cleanup was not occurring when the SATMP environment variable was set. This has been fixed. ================(Build #2807 - Engineering Case #706541)================ In a mirroring system, if the mirror or a copy node was stopped around the time the primary performed a transaction log operation that required more than one page, the next time the mirror or copy node was started it could have asserted or crashed. The most likely assertion failure error numbers were 100902, 100903 or 100904. This has been fixed. ================(Build #2608 - Engineering Case #670360)================ The SQL Anywhere synchronization/replication components, including the MobiLink client (dbmlsync) and SQL Remote (dbremote), could have given the error 'No off-line transaction log file found and on-line transaction log starts at offset XXXXX'. This would have occurred: 1) if no transaction-logs-directory was given on its command line; and 2) if the length of the transaction log name including its absolute path was greater than 128 bytes. This problem is now fixed and the length of the transaction log name plus its absolute path has been extended to 1024 bytes. ================(Build #2575 - Engineering Case #662639)================ When a SQL Anywhere database is used as a remote database, the MobiLink client (dbmlsync) generates a remote ID which is a GUID for the database during the first synchronization. This remote ID is used by the Mobilink server to identify the remote. MobiLink keeps a list of synchronizing remotes in the ml_database table. When a blank padded SA database was used as a remote, a remote ID would have been generated during the first synchronization, sent to the MobiLink server and stored in the ml_database table. On all subsequent synchronizations, a blank padded version of the remote id would then have been sent. The results of this were: 1) The server would not have been recognized on the second sync that the same remote was synchronizing and would treat the second sync as a first sync. That is to say the server would not have used state information it had from the first sync when processing the second. Third and subsequent sync's were not affected. This would have had no impact unless the first synchronization had failed. 2) Two entries would have been made in the ml_database table for each remote. One would contain the blank padded remote id and the other would contain the unpadded id. This behaviour has now been fixed. Now, on first synchronization the remote_id assigned to the remote database will be blank padded. ================(Build #2551 - Engineering Case #655953)================ Several memory leaks have been fixed in the MobiLink client. These leaks would primarily affect applications using the dbmlsync API. ================(Build #2543 - Engineering Case #653930)================ The Console utility could have stopped refreshing database and/or server properties after changing the set of properties which were displayed, even after it was restarted. The problem was sensitive to the speed with which properties were selected or unselected. This has been fixed. ================(Build #2535 - Engineering Case #650856)================ Synchronizations using HTTP-based communication protocols (including HTTP, HTTPS and other encrypted HTTP protocols) could have failed intermittently. When synchronizations failed, they would do so after the download had been applied and committed, and would have reported an error message like: "Data read failed. Requested 2 bytes but got 0 bytes." When this occurred the MobiLink server would have reported the error: "Connection was dropped due to lack of network activity". These failures were only likely to occur when applying the download to the remote database took longer than the stream timeout interval, which is 4 minutes by default. This problem has now been resolved ================(Build #2529 - Engineering Case #647851)================ During HTTPS synchronizations, MobiLink clients could have crashed in MobiLink's RSA encryption library. This has been fixed. ================(Build #2492 - Engineering Case #638770)================ When using the Dbmlsync API (either the C++ or .Net version), events are retrieved using the GetEvent method. One of the events that might be returned is DBSC_EVENTTYPE_PROGRESS_INDEX, which includes an integer that is supposed to be between 0 and 1000 and indicates how close the current phase of synchronization is to completion. This value is intended to be used to update a progress indicator. Occasionally, the DBSC_EVENTYPE_PROGRESS_INDEX events would have been generated with values greater than 1000. This happened during the log scan phase of synchronization, when the -x command line option or the LogRenameSize sychronization profile option was used. It could also happen if operations were occurring to the remote database during synchronization. This has been fixed. The index should now always be between 0 and 1000. ================(Build #2481 - Engineering Case #638242)================ In rare situations, when multiple instances of the MobiLink client (dbmlsync) were run concurrently on the same machine, one or more of the instances may have crashed. It was possible that this problem might also have manifest itself as corrupt data sent to the MobiLink server, but that would have been extremely unlikely. This behaviour has been fixed. ================(Build #2477 - Engineering Case #637333)================ When using the ADO.NET Provider with a .NET Framework 4.0 Client Profile, Visual Studio 2010 generated some compile errors. This problem has been fixed. ================(Build #2474 - Engineering Case #636557)================ Attempting to delete properties and transmission rules from the clients defined within a Server Message Store, could have failed either with or without an error message. This has been fixed. ================(Build #2466 - Engineering Case #635072)================ Specifying a single, empty authentication parameter on the dbmlsync commandline, or using a synchronization profile, would have caused dbmlsync to report "out of memory". For example specifying the following on the commandline would have caused the error: -ap "" This problem has been fixed. Note, a workaround is to specify the parameter using a single comma. For example -ap , This passes a single empty authentication parameter but does not cause the "out of memory" error. ================(Build #2376 - Engineering Case #615855)================ The MobiLink client (dbmlsync) could have crashed on shutdown when run on linux systems. This problem also affected applications using dbmlsync through the dbtools interface. They could have crashed when DBToolsFini was called. This has now been fixed. ================(Build #2375 - Engineering Case #614625)================ The MobiLink client would have ignored the command line option -a. This has been fixed. ================(Build #2358 - Engineering Case #609062)================ The MobiLink client (dbmlsync) was leaving a small fixed amount of memory unfreed on shutdown. This should not have been visible to users, and has now been fixed. ================(Build #2335 - Engineering Case #594317)================ If a synchronization had failed during the download, but before MobiLink had been able to generate any data for the download, then the MobiLink server would have placed the synchronization in the restartable state. When the same remote database synchronized again, there was a chance that the MobiLink server would not have been able to find the previous synchronization to cancel it, preventing the remote database from synchronizing. This problem has now been fixed. A workaround to this problem would be to stop and start the MobiLink server. ================(Build #2317 - Engineering Case #590633)================ Symbols from the Dbmlsync C++ API could pollute the user's default namespace. These symbols are now segregated into their own namespace named "DbmlsyncClient11". Existing Dbmlsync C++ API applications will still be able to compile without modification, since the dbmlsynccli.hpp header file now also includes "using namespace DbmlsyncClient11". Those wishing to exclude the USING command, and be forced to reference the symbols using the namespace, can define a macro called MULTIPLE_DBMLSYNC_API_VERSIONS in their source code. ================(Build #2272 - Engineering Case #580190)================ If an error had occurred while the MobiLink client (dbmlsync) was applying a download, and there had also been referential integrity errors that dbmlsync could not resolve, then dbmlsync would have reported that the download had been committed, even though it had been rolled back. This has been corrected so that dbmlsync now correctly reports that the download was rolled back. ================(Build #2268 - Engineering Case #579404)================ If MobiLick Client (dbmlsync) had been running as a server, and a client application had executed the ShutdownServer() method, the exit code from the dbmlsync executable would have been EXIT_FAIL, which indicated a general failure. This would also have resulted in the progress message text changing to "Synchronization Failed" on shutdown, although it was difficult to see on a desktop system. The dbmlsync executable now returns EXIT_OKAY in this situation, which also results in the progress message text changing to "Synchronization Succeeded" on shutdown. ================(Build #2244 - Engineering Case #572196)================ It was possible for the MobiLink client (dbmlsync) to have sent an incorrect last download timestamp up to the MobiLink server, if dbmlsync had been running on a schedule, and ALL of the following had occurred during the last synchronization : 1) All of the data in the download stream had been applied, but had not yet been committed to the remote database. 2) An SQL Error had been generated by dbmlsync before the download had been committed. Examples of errors that could have occurred include an error occurring in the sp_hook_dbmlsync_download_ri_violation or the sp_hook_dbmlsync_download_end hooks, or an error occurring as dbmlsync had attempted to resolve referential integrity issues. 3) Another hook had been defined in the remote database that would have executed on another connection. For example, the sp_hook_dbmlsync_download_log_ri_violation or the sp_hook_dbmlsync_all_error hooks would have executed on a separate connection. This problem has now been fixed, and the proper last download timestamp is now sent up to the MobiLink server in the synchronization when this situation occurs. ================(Build #2228 - Engineering Case #570503)================ When using secure streams and an invalid TLS handshake occured, the MobiLink server could have waited for a full network timeout period before disconnecting. This has been fixed. The MobiLink server will now immediately terminate the network connection with a "handshake error" error message. ================(Build #2217 - Engineering Case #569013)================ MobiLink clients and the certificate utilities would have failed to read PEM-encoded trusted certificates files which contained blank lines before the first PEM header. The PEM parsing code has now been modified to skip leading white space characters. ================(Build #2205 - Engineering Case #567932)================ Client-side certificates can now be used to authenticate MobiLink clients to third party server and proxies. The following two synchronization parameters have been added to provide support for this feature: identity - Indicates the file that contains the client's identity. An identity consists of the client certificate, the corresponding private key, and, optionally, the certificates of the intermediary certificate authorities. This parameter is equivalent to MobiLink server's 'identity' parameter. identity_password - An optional parameter that specifies the password used to encrypt the private key found in the identity file. It is only required if the private key in the identity file is encrypted. This parameter is equivalent to MobiLink server's 'identity_password' parameter. Note that MobiLink clients cannot authenticate directly to the MobiLink server using client-side certificates. They can only be used to authenticate to third-party servers and proxies which have been configured to accept client-side certificate authentication and are sitting between the client and MobiLink server. Also note, this feature is not supported in UltraLiteJ, and because of ECC compatibility issues between different versions of Certicom's Security Builder libraries, it is also not supported when using ECC TLS. It is only supported for RSA TLS. ================(Build #2182 - Engineering Case #563844)================ The MobiLink client (dbmlsync) would have occationally reported the error: Failed writing remote id file to '<filename>' Despite the error, synchronizations would have continued successfully, and the remote id file would have appeared on the disk in good order. This problem has been fixed. ================(Build #2181 - Engineering Case #565441)================ Changes have been made to the MobiLink client to accomodate the changes made to the MobiLink server for Engineering case 563839. Therefore, running the 11.0.1 GA MobiLink server with SQL passthrough enabled (i.e. rows have been added to the ml_passthrough_script table), with 11.0.1 MobiLink clients (dbmlsync) from an EBF will cause synchronizations to fail with the message: This client is newer than your MobiLink server. You must upgrade your MobiLink server before you can synchronize. In order to resolve this problem, the MobiLink server must be upgraded as well. As a temporary work around, SQL Passthrough can be disabled by deleting all the rows in the ml_passthrough_script table and restarting the Mobilink server. ================(Build #2166 - Engineering Case #563171)================ The MobiLink server would have failed synchronizations from version 10.0.1 and later clients, when they connected via HTTP. The error would have been 'HTTP error 404' (not found), and most clients would have reported this as the error. This has been fixed. ================(Build #2158 - Engineering Case #562027)================ When running on Sun SPARC systems, the MobiLink client (dbmlsync) would have complained about "missing transaction log files", if there were any offline transaction log files bigger than 2GB. This problem now been fixed. ================(Build #2156 - Engineering Case #560943)================ The dbmlsync ActiveX component was not able to launch the dbmlsync application properly on Windows if some or all of the dbmlsync options are given by a file, and the dbmlsync command line contained the option @filename. This problem has now been fixed. ================(Build #2136 - Engineering Case #555444)================ When synchronizing using HTTPS through an HTTP proxy, MobiLink clients would have incorrectly appended the url_suffix to the HTTP CONNECT request, which could have caused some proxies and servers to fail. This has been fixed. ================(Build #2122 - Engineering Case #551953)================ It was possible for the MobiLink client .NET API to have thrown an unhandled socket exception when attempting to disconnect from a socket that had been forcibly closed by the operating system. This exception is now caught and handled within the dbmlsync .NET API. ================(Build #2119 - Engineering Case #551433)================ Calling to the StartServer or WaitForServerShutdown methods when using the Dbmlsync .NET API, would have caused problems for some values of the timeout parameter. If the timeout value was greater than 2147483647, the WaitForServerShutdown method would always have returned DBSC_ERR_TIMED_OUT, and the StartServer method would also have returned DBSC_ERR_TIMED_OUT, unless the call was able to connect to an existing dbmlsync server on the port specified. The calls will now treat values greater than 2147483647 as equivalent to DBSC_INFINITY.

MobiLink - Streams

================(Build #2725 - Engineering Case #692598)================ An HTTPS synchronization could have failed on 64-bit Windows with STREAM_ERROR_SECURE_HANDSHAKE, depending on what trusted certificates were provided. This failure would have been more likely to occur when using the OS's CA certificate store. Certicom has provided updated libraries which correct this problem. ================(Build #2718 - Engineering Case #691654)================ MobiLink clients that output localized error messages, now output a more detailed error message for connection failures on Windows desktop and devices, in addition to doing so for network read and write errors as they did before. ================(Build #2657 - Engineering Case #681078)================ TLS and HTTPS synchronization would have failed when the client attempted to use a client-side identity with an unencrypted private key. The error reported would have been: "Unable to read the private key". This has now been fixed. ================(Build #2588 - Engineering Case #665837)================ The changes for Engineering case 661112 introduced a bug where the MobiLink client could have crashed, or the check of the certificate_name, certificate_company, or certificate_unit could have failed, if any of the certificate fields were encoded as Unicode in the server's certificate. This has been fixed. ================(Build #2546 - Engineering Case #650719)================ After a failed download, an attempt to restart the download may have failed and reported a "Protocol Error" or a read failure. This has been fixed. ================(Build #2541 - Engineering Case #653470)================ MobiLink clients (except UltraLiteJ) could have failed to authenticate to third party servers or proxies when using digest HTTP authentication. In particular, if the third party server's or proxy's response contained nextnonce attribute in the Authentication-Info header. This has been fixed. ================(Build #2521 - Engineering Case #649135)================ MobiLink clients (except UltraLiteJ) could have failed to authenticate to third party servers when using digest HTTP authentication. In particular, it would have failed when the algorithm was "MD5-Sess" instead of "MD5". This has been fixed. ================(Build #2482 - Engineering Case #638492)================ For MobiLink clients, except UltraLiteJ, it was possible to receive an "Out of memory" or STREAM_ERROR_MEMORY_ALLOCATION error during TLS or HTTPS synchronizations. Incorrectly attempting a very large memory allocation has bee fixed. ================(Build #2344 - Engineering Case #488676)================ The HTTP option 'buffer_size' was limited to 64000 (64KB). On slow networks and/or large uploads or downloads, the overhead due to HTTP could have been significant. The 'buffer_size' option is now limited to 1000000000 (1GB). When using slow networks to perform HTTP or HTTPS synchronizations, tests could be done with larger values for 'buffer_size' to see if synchronization times improve. For versions 11.0.1 and up, this change only applies to the -xo option of the MobiLink server. The -x option already allows larger values. ================(Build #2236 - Engineering Case #571465)================ If a network error occurred in the MobiLink Monitor, the SQL Anywhere Monitor, QAnywhere, or the Notifier, there could have been garbage characters trailing the error string. For example: "The server monitor was unable to contact the MobiLink server. The host 'mlstress02' is still available. Error: Timed out trying to read 128 bytes. rWms" This has been fixed. ================(Build #2203 - Engineering Case #567754)================ When providing a list of DER-encoded trusted root certificates to a MobiLink client for TLS synchronization, the client only accepted the first item in the list and ignored the rest. There was no problem if the list of certificates was PEM-encoded. This has been fixed. Note that this problem affected all MobiLink clients except UltraLiteJ. ================(Build #2159 - Engineering Case #562083)================ The MobiLink server could have silently ignored bad HTTP requests. In particular, subsequent requests received by MobiLink server B, for a session started in MobiLink server A, would have been silently ignored. The error was particularly likely to appear if an HTTP intermediary was misbehaving and sending different HTTP requests for the same session to different MobiLink servers. This has been fixed, and this case will now issue an error.

MobiLink - Synchronization Server

================(Build #2953 - Engineering Case #734077)================ Synchronizations with large downloads could have been slowed by up to the liveness timeout when using HTTP, if a network interruption occurred. This has been fixed. ================(Build #2932 - Engineering Case #729427)================ The MobiLink server could have crashed when using HTTP and a misconfigured HTTP proxy. The server now reports an error and kills the synchronization when this occurs. ================(Build #2915 - Engineering Case #727360)================ The MobiLink server may have crashed if the upload stream contained updates for tables with BLOB or spatial columns. Other requirements were that the updates caused conflict updates, and the script version contained conflict detection/resolution scripts. This problem is now fixed. ================(Build #2915 - Engineering Case #727357)================ If a version 16 or later MobiLink client connected to a version 12 or earlier MobiLink server, the server would have printed a confusing error. It will now print an 'unrecognized version' error. ================(Build #2892 - Engineering Case #723017)================ On Mac OS X 8 systems, the MobiLink Server may have failed to start, with startup error “Unable to bind socket”. This has been fixed. ================(Build #2831 - Engineering Case #706878)================ The MobiLink server could have crashed when a TIMESTAMP column was fetched from Oracle using the .NET-ODBC bridge. This has been fixed. ================(Build #2823 - Engineering Case #710432)================ The MobiLink server could have crashed if a failed download using HTTP was restarted. This has been fixed. ================(Build #2807 - Engineering Case #707061)================ The MobiLink server could have crashed if it had an HTTPS listening port. This has been fixed. ================(Build #2775 - Engineering Case #701349)================ It was possible to call PreparedStatement.setTime for columns that were not times or dates in the MobiLink direct row API. This has been corrected. ================(Build #2775 - Engineering Case #701347)================ The varchar(max) and varbinary(max) types in Microsoft SQL Server did not work when using the MobiLink .NET-ODBC bridge. This has been fixed. ================(Build #2775 - Engineering Case #701343)================ Unnecessary cast exceptions could have occurred when using the MobiLink .NET direct row API with SMALLINT and TINYINT columns. This has been fixed. ================(Build #2775 - Engineering Case #701342)================ The following remote types were not supported by the MobiLink Java and .NET direct row APIs: NCHAR NVARCHAR LONG NVARCHAR VARBIT LONG VARBIT XML This has been fixed. ================(Build #2747 - Engineering Case #695119)================ The MobiLink server would not have accepted any status-check requests sent by clients who had lost the last synchronization status. When a status-check request was received, the MobiLink server would have repoprted the error: [Sybase][ODBC Driver][SQL Anywhere]Authentication violation (ODBC State = 08001, Native error code = -98) and then failed the request when all the following conditions were met: 1) The consolidated database was running on an OEM version of a SQL Anywhere server; 2) The consolidated database had been restarted since the MobiLink server was started; and 3) A client required a status-check because it did not get a full response in the last sync request that contained an upload. These problem is fixed now. The immediate work around for this problem is to restart the MobiLink server. ================(Build #2721 - Engineering Case #691327)================ If the Notifier had encountered an unexpected error (such as a deadlock) when executing one of the Notifier events, subsequent attempts to execute the same Notifier Event would have resulted in an "Invalid Cursor State" error. This has been corrected so that the Notifier no longer reports the "Invalid Cursor State" error on subsequent attempts. Stopping and starting the MobiLink Server would also have resolved the issue. ================(Build #2709 - Engineering Case #689194)================ When synchronizing with a SQL Anywhere remote using the MobiLink client running on a non-English operating system, it was possible for the following message to be generated by the MobiLink server: Gtk-CRITICAL **:gtk_text_buffer_emit_insert:assertion 'g_utf8_validate (text, len, NULL)' faild This problem has been fixed. As a consequence, the message output in the MobiLink server log when a synchronization request is received from a SA remote will change from: Request from "Dbmlsync Version 16.0.0.3940" for: remote ID: ... to: Request from "Dbmlsync 16.0.0.3940" for: remote ID: ... ================(Build #2685 - Engineering Case #686041)================ The MobiLink server would have reported an unnecessary protocol error when the first command of a request was a NOOP. This has been corrected. ================(Build #2677 - Engineering Case #547730)================ If a corrupted UltraLite or SQL Anywhere remote client synchronized with a MobiLink server, it was possible for protocol errors to be generated. When this occurred, the MobiLink server console log would have shown the text: I. <1> failed reading command with id:%d and handle:%d I. <1> Synchronization complete This has been fixed. Now, the error message "[-10001] Protocol Error: 400" will be displayed and a synchronization error will be reported. ================(Build #2662 - Engineering Case #678983)================ The MobiLink server could have crashed when synchronizing using HTTP. This has been fixed. ================(Build #2660 - Engineering Case #681620)================ If the MobiLink server was started with an identity file containing an unencrypted private key, it would have fail to start with error "Unable to read the private key.". This has been corrected. ================(Build #2635 - Engineering Case #655780)================ The method MLResultSet.getBigDecimal(L/java/lang/String;) unnecessarily threw a 'method not supported' exception. This has been fixed. ================(Build #2609 - Engineering Case #669465)================ The MobiLink server could have crashed when handling restartable downloads and the restartable download cache was too small to hold all possible restartable downloads at one time. This has been fixed. ================(Build #2582 - Engineering Case #632219)================ The MobiLink server running in a server farm against the cluster edition of a consolidated database, would have shutdown too quickly when the node the MobiLink server was connecting to was killed or shut down. This problem has been fixed. When the MobiLink server detects the database connection unusable, it will now attempt to re-establish a connection and pause for 1 second before each retry. By default, the number of retries is 3. Therefore, it would allow the ODBC driver to switch the MobiLInk server database connections to another node within 3 seconds. If the failover of the consolidated database takes more than 3 seconds, the MobiLink server command line option -cr <num> can be used to change the number of retries. ================(Build #2568 - Engineering Case #660428)================ The MobiLink server could have crashed during shutdown if user spawned Java threads printed to System.out or System.err after the ShutdownListeners were notified of shutdown. This has been made much less likely to happen. A work around is to ensure all user threads are stopped before the ShutdownListeners return. ================(Build #2562 - Engineering Case #658453)================ When using MobiLink synchronization and timestamp-based downloads with an Oracle Real Application Cluster (RAC) system, there is a chance of missing rows to be downloaded if the clocks of the Oracle cluster nodes differ by more than the time elapsed between the MobiLink server fetching the next last download timestamp and fetching the rows to be downloaded. This problem is unlikely on a RAC system with synchronized node clocks, but the likelihood increases with larger node clock differences. A workaround is to create either a modify_next_last_download_timestamp or modify_last_download_timestamp script to subtract the maximum node clock difference. Note that at least since version 10i, Oracle has recommended using Network Time Protocol (NTP) to synchronize the clocks on all nodes in a cluster, and NTP typically runs by default on Unix and Linux. With cluster nodes properly configured to use NTP, their clocks should all be within 200 microseconds to 10 milliseconds (depending on the proximity of the NTP server). Since Windows Server 2003, the Windows Time Service implements the NTP version 3 protocol and it runs by default. Also, as of version 11gR2, Oracle Clusterware includes the Oracle Cluster Time Synchronization Service (CTSS) to either monitor clock synchronization or, if neither NTP or Windows Time Service is running, it will actively maintain clock synchronization. However CTSS and Windows Time Service are less accurate than NTP, To avoid missing rows when Oracle RAC node clocks differ by up to one second more than the time between fetching the next_last_download_timestamp and the rows to be downloaded, now the MobiLink server will subtract one second from the next_last_download_timestamp fetched from the consolidated database, if 1) the Oracle account used by the MobiLink server has execute permission for SYS.DBMS_UTILITY, 2) the consolidated database is an Oracle RAC system, and (only for MobiLink version 12.0.0 and up) 3) there is no generate_next_last_download_timestamp script. For Oracle RAC node clocks that may differ by greater amounts, you can avoid the problem by defining a generate_next_last_download_timestamp, modify_next_last_download_timestamp or modify_last_download_timestamp script to compensate for the maximum node clock difference. ================(Build #2539 - Engineering Case #652609)================ When using Oracle as a back-end database, synchronizations may have failed with the error ORA-08207. This has been fixed. ================(Build #2538 - Engineering Case #652263)================ The usage text for the Relay Server Outbound Enabler didn't describe what were the valid options for the -cr option. This has been corrected so that the values are now listed for the tcp options, server certificate options, and client certificate options. In addition, http authentication options, proxy options, and proxy authentication options, have been added in version 12.0.1. ================(Build #2528 - Engineering Case #647345)================ The data for an upload stream may not have been fully uploaded into the consolidated database if the consolidated database was running on Microsoft SQL Server and errors occurred in the upload. For this to have occurred, the connection property, XACT_ABORT must have been set 'ON' in the consolidated database, and the handle_error script must have returned 1000 (skip the row and continue processing). This problem has now been fixed. ================(Build #2518 - Engineering Case #646269)================ The MobiLink Server could have crashed under heavy load if the client load was a mix of old (prior to version 10) and new (version 10 or later) clients. THis has now been fixed. A work around is to specify the -cn switch with a value of the twice the value of -w plus 1. Eg. if using the default value of -w (5), specify -cn 11. Version 12 is not affected as it no longer supports old clients. ================(Build #2510 - Engineering Case #642568)================ If a synchronization failed with a protocol error, some later synchronization could have failed with a translator or right truncation error. It was also possible that instead of failing, the later sync could have made use of the failed syncs to, for example, insert it into the consolidated. These issues have been fixed. ================(Build #2493 - Engineering Case #639825)================ The 32-bit authentication value sent to MobiLink clients was being truncated to 16-bits. This has been fixed. In order to use this fix, both clients and server must be updated. If the use of this fix is not required, it is not necessary to upgrade both the clients and server. ================(Build #2490 - Engineering Case #639012)================ The script events publication_nonblocking_download_ack, nonblocking_download_ack and generate_next_last_download_timestamp may have incorrectly been passed the client Remote ID. This would have occurred for non-SQL scripts as well as SQL scripts that used the question mark notation. This has been fixed so that the Remote ID is no longer passed to these scripts. Note that the documentation is correct. ================(Build #2489 - Engineering Case #637309)================ The MobiLink server could have crashed at the end of a version 9 or earlier synchronization request, or while processing the upload stream from a version 10 or later synchronization request. Also, the MobiLink server was not able to distinguish between empty strings in varchar(8) or smaller columns, binary(16) or smaller values made of only 0s, the integer 0, and null values when filtering the download. This could have caused rows to be incorrectly filtered from the download. For example, if an empty string was uploaded in a row, and the only difference between a downloaded row and that uploaded row was that the empty string became null, the row would have been ommitted from the download and the remote would not have received that update. These issues have been fixed. ================(Build #2477 - Engineering Case #636715)================ The iAS ODBC driver for Oracle would have returned a wrong value for a parameter indicator through the ODBC API, SQLBindparameter( ..., c_type, ..., param_type, ..., &indicator ), if it was called with the following parameters: 1) the C data type of the parameter was SQL_C_WCHAR or SQL_C_CHAR 2) the type of parameter was SQL_PARAM_INPUT_OUTPUT, but the corresponding parameter used in the SQL statement was input-only Due to this problem, the data for the user-defined named parameters in the MobiLink server may have been truncated after each use when the named parameter was defined as {ml u.varname} and the parameter used in the SQL statement was input-only. This has now been fixed. ================(Build #2476 - Engineering Case #637169)================ Starting with Visual Studio 2010, class libraries built with with the default project settings will no longer work with a MobiLink server running with its default CLR version.  There are two workarounds for this: 1) Change the target Framework of the VS project. When creating a new project, there is a drop down above the list of project types that contains ".NET Framework 4"; change this to ".NET Framework 2.0", ".NET Framework 3.0", or ".NET Framework 3.5".  If a version 4 project has already been created, change the target framework by right-clicking on the project in the Solution Explorer, and selecting "Properties" in the context menu.  The target framework can be set on the "Application" tab. When changing the target framework, there is no longer access to .NET 4.0 features; to use newer features, use the next workaround. 2) Tell the MobiLink server to load the version 4 framework. To do this, add -clrVersion=v4.0.30319 to the -sl dnet options.  The "30319" is the specific build number of the framework installed and may be different on your machine.  To find the correct version, look in the .NET install location, which is typically "c:\WINDOWS\Microsoft.NET\Framework\".  The clrVersion to specify is the v4.0 sub-directory there. ================(Build #2459 - Engineering Case #622866)================ If the MobiLink Server had been started with the "-xo http" or "-xo https" command line options to accept http[s] synchronizations from version 9 or lower MobiLink clients, and the port that was listening for synchronizations received an HTTP request from an HTTP client other than an UltraLite or SQL Anywhere MobiLink client (for example, a web browser), the MobiLink Server would have reported an HTTP error to the HTTP client, posted an error to the ML Server log, but would not have freed the worker thread in the ML Server. Multiple requests from other HTTP clients would have eventually resulted in no threads available to handle additional synchronizations. This has now been fixed, and the worker thread is returned to the pool of available worker threads after the error is reported. ================(Build #2454 - Engineering Case #632869)================ Using the -ppv command line option ("print periodic performance values") could have degraded the MobiLink server's performance if there were many unsubmitted error reports. This was most noticable when using -ppv 1, and there were more than one thousand unsubmitted reports. This has been fixed by removing the NUM_UNSUBMITTED_ERROR_RPTS value from the -ppv output. The number of unsubmitted error reports can still be found by using the SQLAnywhere Monitor for MobiLink, or by counting the lines output by "dbsupport -lc". ================(Build #2451 - Engineering Case #632519)================ Changes made to INOUT script parameters in .NET scripts were ignored unless the script accepted all the possible parameters for the event. This has been fixed. ================(Build #2448 - Engineering Case #632040)================ On 64-bit systems, it was possible for the JDBC driver to crash if some statement attributes were queried. This has now been fixed. ================(Build #2447 - Engineering Case #631119)================ If the empty string was passed into an SQLNativeSQL or SQLPrepare function, it was possible for the iAS Oracle ODBC Driver to have crashed. This has been fixed. The SQLPrepare function will now return the error "Invalid string or buffer length", and the SQLNativeSQL function will now simply set the out parameters to the empty string as well. ================(Build #2443 - Engineering Case #631280)================ The MobiLink Server could have hung or crashed on MacOSX 10.6 systems when the server was run as a daemon (using the -ud command line option). This has been fixed. ================(Build #2436 - Engineering Case #629058)================ A Java VM running inside the MobiLink server could have run out of memory if the server had many requests with different script versions and some sync scripts made calls to DBConnectionContext.getConnection(). This has been fixed. ================(Build #2428 - Engineering Case #626617)================ Synchronization requests from clients prior to version 11 that were using a UTF8-encoded database, would have failed against 64-bit MobiLink servers running on Unix systems. This has been fixed. Note, this problem does not occur with the 32-bit versions of the MobiLink server. ================(Build #2401 - Engineering Case #623115)================ Sometimes, when printing the error -10193, "Unable to load Assembly ... into domain ...", the MobiLink server would have failed to print why it failed to load the assembly. Also, the MobiLink server would have spuriously printed this error whenever it failed to find a class in the loaded assemblies. These issues have now been fixed. ================(Build #2401 - Engineering Case #620985)================ The MobiLink server would have reported the error, ".NET CLR Host encountered unexpected error." (SQLCODE -10167), instead of error, "Assembly '%1!s!' does not contain '%2!s!'" (SQLCODE -10172), when a .NET method could not be found. This has been fixed. ================(Build #2380 - Engineering Case #616196)================ Older MobiLink clients (prior to Version 10) would have caused the server to log a Protocol Error, when attempting to restart a download. This has been fixed. Restartable downloads for older clients is not supported, so the server will now log the restart failure and send a status code to the client. ================(Build #2376 - Engineering Case #614417)================ The MobiLink server could have crashed when processing a synchronization request from a client, if the client was older than version 10 and was syncing UUID columns. This has been fixed. ================(Build #2376 - Engineering Case #611373)================ The MobiLink server could have occasionally given the following error: A downloaded value for table 'table_name' (column #column_number) was either too big or invalid for the remote schema type and then aborted the synchronization, when a client was trying to download data from a table that contained NCHAR, NVARCHAR or LONG NVARCHAR columns, even when NCHAR, NVARCHAR or LONG NVARCHAR data was uploaded in a previous synchronization. This problem has now been fixed. ================(Build #2365 - Engineering Case #611414)================ When using the iAS Oracle ODBC driver, attempting to execute an INSERT, UPDATE, or DELETE statement with SQLExecDirect immediately after executing a SELECT statement with the same statement handle, would have failed with the following error message: ORA-24333: zero iteration count This problem is fixed now. ================(Build #2363 - Engineering Case #609707)================ When running the MobiLink server in a server farm, it was possible for the MobiLink server to have printed errors to the MobiLink log that dealt with problems on operations to the ml_active_remote_id table. These errors are now suppressed, and more meaningful warnings or errors are printed to the MobiLink log. ================(Build #2344 - Engineering Case #605651)================ The MobiLink server would have thrown the exception IllegalCastException when assigning the null reference to the Value property of an IDataParameter when using the MobiLink Direct Row API to download data. This has been fixed. A work around is to assign DBNull.Value instead. ================(Build #2321 - Engineering Case #591002)================ The changes for Engineering case 582782 could have caused the MobiLink server to be much slower for small sync than servers without the fix. This problem would have occurred when a consolidated database was running on an Oracle RAC. The slowness is in the Oracle server: fetching the minimum starting time of the open transactions from gv$transaction can take as much as a couple of seconds and it is much slower than from v$transaction. This has now been corrected. ================(Build #2320 - Engineering Case #589236)================ The MobiLink server could have crashed following a failed synchronization. This has now been fixed. ================(Build #2315 - Engineering Case #590061)================ If a MobiLink server had a connection from a MobiLink Monitor, or a SQL Anywhere Monitor, it could have hung while printing warning 10082, "MobiLink server has swapped data pages to disk ... ". This was due to a deadlock between the thread printing the warning and a thread sending a monitor event. This has been fixed. ================(Build #2297 - Engineering Case #585456)================ The queue lengths in the Utilization Graph of the MobiLink Monitor could have been incorrect and the RAW_TCP_STAGE_LEN, STREAM_STAGE_LEN, HEARTBEAT_STAGE_LEN, CMD_PROCESSOR_STAGE_LEN metrics printed by the -ppv option could also have been incorrect. These issues have now been corrected. ================(Build #2296 - Engineering Case #585258)================ The MobiLink server would not have shown any script contents, if the scripts were written in Java or .NET, even when the verbose option (-vc) was specified in its command line. This problem is fixed now. ================(Build #2288 - Engineering Case #584310)================ Download performance of the MobiLink server has been improved for tables that contain no BLOB columns, when the consolidated database is running on Microsoft SQL Server. ================(Build #2280 - Engineering Case #581426)================ When the number of concurrent synchronizations was greater than the maximum number of concurrent active synchronizations specified by the -sm command line option, the MobiLink server would have quietly rejected any synchronization requests without showing any error or warning messages. This has been fixed. The MobiLink server will now issue the following warning message: [10101] Synchronization request from client '?' was rejected where ? is the rejected remote ID. A more complete description of this warning code can be found in the documentation. ================(Build #2279 - Engineering Case #582782)================ When a consolidated database was running on an Oracle RAC, the MobiLink server could have skipped rows being downloaded to remote databases in a time-based download. In the following situations, rows modified in the Oracle database could be missed from the download stream: 1) the MobiLink server connected to one node on an Oracle RAC; 2) another application, A connected to another node on the same Oracle RAC; 3) application A modifies rows in a synchronization table without commit; 4) a MobiLink client, R1 issues a synchronization request that contains a time-based download from this table; 5) the MobiLink server completes the synchronization request successfully; 6) A commits its transaction; Then the rows modified by application A would not be down loaded to remote R1. This problem has now been fixed. Note, as a result of this change, the Oracle account used by the MobiLink server must now have permission for the GV_$TRANSACTION Oracle system view instead of V_$TRANSACTION. Only SYS can grant this access. The Oracle syntax for granting this access is: grant select on SYS.GV_$TRANSACTION to <user-name> ================(Build #2278 - Engineering Case #582589)================ If 10 MobiLink Monitors or SQL Anywhere Monitors connected to the same MobiLink server, and the last to connect then disconnected, then the MobiLink server could have crashed. This has been fixed. ================(Build #2275 - Engineering Case #581755)================ An undocumented feature could have prevented a MobiLink server from starting when multiple MobiLink servers were trying to start at the same time, against the same consolidated database. The error displayed would have been: <main> [-10002] Consolidated database server or ODBC error: ODBC: [Sybase][ODBC Driver][SQL Anywhere]Primary key for table 'ml_property' is not unique: Primary key value("'ML','server_info','release_version''") (ODBC State = 23000, Native error code = -193) when the consolidated database was running on a SQL Anywhere server. This problem has now been fixed. ================(Build #2272 - Engineering Case #580222)================ If the MobiLink Server had been started with "-s 1" command line option, to indicate that the server should always apply changes to the consolidated database one row at a time, then the MobiLink Server would still have executed SAVEPOINT commands. SAVEPOINT commands are not needed when running in single row mode, so they are no longer executed when the MobiLink Server had been started with "-s 1". ================(Build #2260 - Engineering Case #577142)================ The MobiLink server would not have skipped a script that was defined to be ignored, if the script contained white space (spaces, tabs, and/or line-breaks) before the special prefix, '--{ml_ignore}'. This problem is fixed now. ================(Build #2248 - Engineering Case #573456)================ On Windows x64 systems, attempting to start the MobiLink server with the -xo command line option (specify network protocal and options for version 8 and 9 clients), would have failed with a missing dll error if HTTPS was requested. The dll mlhttps11.dll was missing from the install. This has been corrected. ================(Build #2236 - Engineering Case #567906)================ The MobiLink server could have crashed when multiple -x options were specified on the command line, with at least one being HTTP and another being HTTPS. This could have happened, for example, when a VPN connection was created or dropped in the middle of a non-persistent HTTP/HTTPS synchronization, and the network intermediaries were set up such that one path resulted in HTTP and the other resulted in HTTPS. This has been fixed. ================(Build #2235 - Engineering Case #570690)================ The "Longest Active Synchronization Time" and the "Longest Active Wait for a Database Worker Thread" metrics were incorrect in the SQL Anywhere Monitor, and the monitoring values printed by the -ppv options LONGEST_SYNC and LONGEST_DB_WAIT, would have been incorrect. These metrics in the Monitor had the incorrect sign, but the absolute values were correct; essentially the graph was drawn upside down. A side effect of this is that the alert on these metrics would never be raised. These issues have been fixed. ================(Build #2229 - Engineering Case #570656)================ If a MobiLink synchronization script included the two characters "ui" inside an {ml ...} structure for named parameters, and the "ui" characters were not part of a named parameter, then MobiLink would have incorrectly replaced the "ui" with a question mark when it sent the command to the consolidated database. For example, the following script would have had no problem, since the "ui" in this case was part of the named parameter "build": INSERT INTO t1(pk,build) VALUES ( {ml r.pk}, {ml r.build}) However, the following script would have failed, because the "ui" in the column list for the insert would have been replaced: {ml INSERT INTO t1(pk,build) VALUES ( r.pk, r.build )} This has now been fixed. ================(Build #2222 - Engineering Case #565844)================ When using MobiLink servers in a server farm (by specifying the -ss command line option), servers could have crashed and/or unexpectedly caused failed synchronizations. The problem was more noticeable in environments with poor network quality or where retries after synchronization failures occurred very quickly after the original synchronization. This has been fixed. ================(Build #2222 - Engineering Case #563535)================ Worker threads are created to process the stream data from clients, and perform the database activities for each synchronization. Two sets of workers were being created, one set for pre version 10 clients, and another set for current clients (version 10 and later). Now, when the -xo switch is not specified, the MobiLink server no longer creates the threads to process the old client requests. ================(Build #2211 - Engineering Case #574337)================ If MobiLink servers were running in a server farm against a very busy consolidated database, some of the MobiLink servers may have shutdown automatically, due to the fact that they were no longer able to maintain their liveness to the consolidated database. To fix this problem, a new MobiLink server command line option to supply server farm database connection parameters has been added: -ca "keyword=value;..." This new option can be used to let the MobiLink servers connect to another database that is running on a less busy database server, and then the MobiLink servers will use this second database to maintain their state information for the server farm. This second database can be running on an SA, ASE, Microsoft SQL Server, Oracle, DB2, or MySQL database server. However, it must contain the MobiLink server system objects. Note, the -ca command line option must be the same for all the MobiLink servers across the same server farm, otherwise, redundant synchronizations may not be detected and data inconsistency can happen. ================(Build #2190 - Engineering Case #565651)================ If an application executed a query like "select ... for t where c = v', where c was a char or varchar column, v was as variable of type nchar or nvarchar, and t was a proxy table to a remote table in Microsoft SQL Server, then the query would have failed with SQL Server reporting the error "The data types varchar and ntext are incompatible in the equal to operator." This problem has now been corrected. ================(Build #2182 - Engineering Case #564829)================ When the MobiLink server was listening for HTTP and/or HTTPS requests, and a load balancer or any other utility (eg. the RSOE) performed a simple TCP/IP connect, then an immediate close without sending any bytes, the MobiLink server would have taken four minutes to time out the socket. If too many such connections happened in a short time, the MobiLink server could have run out of sockets earlier than necessary. This has been fixed. ================(Build #2170 - Engineering Case #563592)================ When run on Windows systems, both the MobiLink server and the Relay Server Outbound Enabler (RSOE) could have held onto sockets for longer than necessary. This would have caused both to use up sockets faster than necessary, possibly exhausting system socket limits. With the RSOE, needless timeouts could also have occurred. This behaviour was particularly evident with non-persistent HTTP/HTTPS connections, and appeared to be very much OS and machine dependent. This has been fixed. ================(Build #2168 - Engineering Case #563405)================ The MobiLink server could have crashed if a IDataReader returned by MLUploadData was not closed. If the server didn't crash it would have leaked memory. The crash would have occurred at a random time after the synchronization completed. This has been fixed. Note that enclosing the use of the IDataReader in a 'using' block will automatically close it. ================(Build #2167 - Engineering Case #563404)================ Synchronizations could have failed with protocol errors when some, but not all, of the parameters for a delete command in the .NET irect row API were set to DBNull.Value or null. This has been fixed so that an exception will be thrown when attempting to execute the command. ================(Build #2158 - Engineering Case #562039)================ The start times for synchronizations reported by the MobiLink Monitor and the MobiLink Server, when used with the -vm option, could have been incorrect if the MobiLink Server had been running for several days. Also, the output for the -vm option could have been incorrect if a request used non-blocking download acks, and phase durations reported by -vm option could have been slightly different than phase times reported by the MobiLink Monitor. These issues have now been fixed. ================(Build #2157 - Engineering Case #561813)================ The MobiLink server could have crashed when using the -xo option ("specify network protocol and options for version 8 and 9 clients"). Monitoring pre-10.0.0 synchronizations would also have had erratic behaviour. These issues have been fixed. ================(Build #2145 - Engineering Case #558232)================ The MobiLink Monitor has a default filter which highlights failed synchronizations in red. Failed synchronizations logged by the MobiLink Server were not being shown in the Monitor in red as the server was telling the Monitor that every sync was successful. This has been fixed. ================(Build #2143 - Engineering Case #557686)================ The MobiLink server could not start in a server farm if the consolidated databases were running on DB2 or DB2 mainframe database servers, and the MobiLink server in the farm was requested to start with a liveness setting from the ml_property table (the ml_property table in the consolidated database contained a liveness value for the server farm). This problem has now been fixed. ================(Build #2136 - Engineering Case #555616)================ he MobiLink server was allocating more memory than necessary and thus wasting memory. The amount wasted was approximately equal to 13% of the -cm option value. This has now been fixed. ================(Build #2135 - Engineering Case #555034)================ Push notifications over a SYNC gateway may have stopped working after the listener reconnected. The was timing dependent and was more likely to have occurred when there was a proxy, a redirector, or a relay server being used between the listener and the SYNC gateway of the MobiLink server. The listener may have reconnected to the SYNC gateway when the IP address of the remote device had been changed, when the QAAgent registered with the listener on startup, or a communication error had occurred. This problem has now been fixed. ================(Build #2129 - Engineering Case #553748)================ When using the iAS ODBC driver for Oracle, calling SQLColAttribute with an attribute code of SQL_DESC_TYPE_NAME would not have returned the type names of columns. This has now been fixed. ================(Build #2124 - Engineering Case #552321)================ If an error or warning occurred when commiting, the MobiLink server would not have reported any error or warning messages. If it was an error, the MobiLink server would have just failed the synchronization request without giving any reasons. This problem is fixed.

MobiLink - Utilities

================(Build #2661 - Engineering Case #681788)================ Version information was missing from mlnotif.jar, so an ianywhere.ml.notifier.BuildNum class with a static main method that prints the version with build number to System.out, has been added. ================(Build #2586 - Engineering Case #665200)================ The redirector for Apache could have crashed during a synchronization. This has been fixed. ================(Build #2583 - Engineering Case #664140)================ Sometime the MobiLink Listener (dblsn) could have taken a few minutes to shutdown if the shutdown was initiated by the QAnywhere Agent (qaagent). This problem has been fixed. ================(Build #2538 - Engineering Case #652249)================ The title line of the usage screen for the QAnywhere Stop utility (qastop) may have contained an untranslated character. This has been fixed. ================(Build #2467 - Engineering Case #635175)================ When there was a design problem in the Notifier property (e.g. user defined a request_cursor referencing an unknown column), the Notifier would have reported the SQLException on MobiLink server startup, but the error report did not contain enough context information to pinpoint the issue efficiently. The Notifier would also have produced repeated NullPointerException in the MobiLink log after it failed to start. This has been fixed to add context information in addition to the SQLException and stop the Notifier from running if it has encountered a design problem. The following is an example output after the fix. <Main> [-10133] java.lang.Exception: Notifier(Simple).request_cursor: Failed to prepare request cursor <Main> [-10133] at ianywhere.ml.notifier.Notifier.connectDB(Notifier.java:390) <Main> [-10133] at ianywhere.ml.notifier.Scheduler.connectDB(Scheduler.java:360) <Main> [-10133] at ianywhere.ml.notifier.Scheduler.run(Scheduler.java:428) <Main> [-10133] at java.lang.Thread.run(Thread.java:619) <Main> [-10133] Caused by: java.sql.SQLException: [Sybase][ODBC Driver][SQL Anywhere]Column 'bogus_content' not found <Main> [-10133] at ianywhere.ml.jdbcodbc.IConnection.nativePrepareStatement(Native Method) <Main> [-10133] at ianywhere.ml.jdbcodbc.IConnection.prepareStatement(IConnection.java:554) <Main> [-10133] at ianywhere.ml.notifier.Notifier.connectDB(Notifier.java:388) <Main> [-10133] ... 3 more <Main> <SISI><Scheduler(0:1)>: Shutdown <Main> <SISI><Scheduler(0:1)>: Disconnected from database ================(Build #2453 - Engineering Case #631731)================ When starting the MobiLink Monitor with the -o or -c command line options, the result of the session should have been saved when the MobiLink server terminated, or the user manually disconnected from the MobiLink server. In the latter case, the output was not being saved and the Monitor was not shutting down. This has now been fixed. ================(Build #2452 - Engineering Case #631946)================ An error on startup of the MobiLink server on Mac OS X systems, would have displayed text that was prefixed by random characters and/or yellow highlighting. This has been corrected. ================(Build #2451 - Engineering Case #631733)================ When connecting the MobiLink Monitor to a MobiLink server, any authentication error resulted in a poor error message from the Monitor, like: "Got unexpected data when receiving authentication result. Check version of MobiLink server (opcode=0)" This has been fixed to provide more information on the problem. The most common authentication error is now: "Invalid userid or password (auth_status=NNNN)" Other errors, for example due to an expired password, are similar. ================(Build #2451 - Engineering Case #631643)================ Changes made for Engineering case 585456 caused the queue lengths in the Utilization Graph of the MobiLink Monitor, the RAW_TCP_STAGE_LEN, STREAM_STAGE_LEN, HEARTBEAT_STAGE_LEN, CMD_PROCESSOR_STAGE_LEN metrics printed by the -ppv option, and the queue lengths available in the SQL Anywhere Monitor, to possibly have been reported as larger than they actually were. These issues have been fixed. ================(Build #2415 - Engineering Case #624041)================ If the action command in the message handler did not contain any arguments, the MobiLink Listener may have crashed. This has been fixed. ================(Build #2409 - Engineering Case #622058)================ When MobiLink listeners were connected to a MobiLink server via a persistent sync gateway connection, shutting down the listener would have caused the MobiLink server to report "Ping request failed" as an informational message. This message was non-harmful, but misleading. The MobiLink server will now report "Listener request completed" instead. ================(Build #2276 - Engineering Case #581829)================ The MobiLink Listener (dblsn)would have failed to query an optimal polling interval from secondary MobiLink servers, as the primary notifier was not broadcasting the polling interval to secondary servers. This affected a light weight poller dblsn, but not application using the light weight poller API directly. This has now been corrected. ================(Build #2275 - Engineering Case #580191)================ Spacy tokens need to be quoted with double quotes. If the quoted token further contains spacy sub token then nested double quotes are need, and they need to be escaped with escape sequence. This was not working correctly when used in a MobiLink Listener (dblsn) configuration file. For example: -l "subject=$remote_id; content=sync cardealer; action='run dbmlsync.exe -c \"filedsn=c:\my fdsns\CarDealer.dsn\" -ot dbmlsync.log -k -e sa=on';" This works correctly on the command line, because the tokenizer of the commandline processor in the OS supports escaping double quotes using a backslash, but using the same command in a configuration file would have failed. This problem has been fixed by improving the common configuration file parsing routine to support <slash><slash> and <slash><double quote> as escape sequences for <slash> and <double quote> respectively. The escape mechanism is effective only inside a quoted token. ================(Build #2274 - Engineering Case #581417)================ Light weight polling against a secondary MobiLink server that is in a MobiLink server farm, may have failed. This is now fixed. ================(Build #2227 - Engineering Case #570369)================ The listener may not have substituted action variables properly in some cases. The light weight polling handler would have substituted the variables $ml_user, $ml_password and $ml_connect with undefined values, as they were thought to be irrelevant in unauthenticated light weight polling. This has been fixed. They will be substituted properly into the action string and, if they are not specified, the values will be empty. Action variables in irrelevant contexts would have been substituted with undefined values as well. This is too is fixed, by not not be substituting them at all. For example, using $poll_key in the action string of a non-light-weight-polling handler will now result in $poll_key without substitution instead of an undefined result. ================(Build #2218 - Engineering Case #569510)================ HTTP light weight polling may have failed with communication errors. This has been fixed. ================(Build #2218 - Engineering Case #569509)================ The MobiLink Listener would have gone into an infinite loop light weight polling continuously, without respecting the polling interval, when communication errors continue to occur. This has now been corrected.

MobiLink - iAS Branded ODBC Drivers

================(Build #2874 - Engineering Case #719402)================ Messages generated by the iAS ODBC driver for Oracle could have contained unreadable characters at the end, if the message length was equal to or greater than 256 characters. This problem is now fixed. ================(Build #2564 - Engineering Case #657721)================ There was a memory leak in the iAS ODBC driver for Oracle. The memory leak would have occurred when an application tried to make a connection but the ODBC driver was not able to obtain a valid database connection. This problem has now been fixed. ================(Build #2495 - Engineering Case #640205)================ In some cases, the iAS ODBC driver for Oracle could aborted the operation and given the following Oracle error: ORA-03145: I/O streaming direction error This would have occurred when the driver was used to send NULL BLOBs to a table in an Oracle database and then the rows were fetched back from this table using the same database connection, and the Oracle database was running with a multi-byte character set. This has now been fixed. ================(Build #2473 - Engineering Case #632612)================ The iAnywhere ODBC driver for Oracle could have crashed, if an application made a request to convert an invalid SQL statement (for instance, a SQL statement containing a '{' that was not followed by 'call') to native SQL by calling SQLNativeSQLW. This has been fixed. ================(Build #2455 - Engineering Case #632889)================ When using the iAS Oracle ODBC Driver, a call to SQLGetStmtAttr that queried the SQL_ATTR_CONCURRENCY, SQL_ATTR_CURSOR_TYPE, SQL_ATTR_CURSOR_SENSITIVITY or SQL_ATTR_QUERY_TIMEOUT attributes could have returned a random value for the attribute. The driver now throws an "Optional feature not implemented" error (SQL State HYC00) for the SQL_ATTR_CONCURRENCY, SQL_ATTR_CURSOR_TYPE, and SQL_ATTR_CURSOR_SENSITIVITY attributes. When the SQL_ATTR_QUERY_TIMEOUT is queried, a zero is returned, and no error is reported. ================(Build #2451 - Engineering Case #631405)================ If a result set contained a column with ROWID values, the iAnywhere Oracle driver would have returned invalid OUT parameters from calls to SQLColAttribute for the SQL_COLUMN_TYPE and SQL_DESC_DISPLAY_SIZE identifiers. As a workaround, the select statement could use ROWIDTOCHAR(ROWID) instead of ROWID. This has been fixed so that the calls to SQLColAttribute will now describe the column in the result set as a SQL_WCHAR of length 18. ================(Build #2436 - Engineering Case #628952)================ The MobiLink server would have shown the following error: Invalid Date-time segment. Year value out of range and aborted any synchronization requests, if the consolidated database was running on an ASE server with a database that was using a multi-byte charset, and the MobiLink server was running on a Windows system that was using a non-English Date format. This problem has now been fixed. ================(Build #2436 - Engineering Case #627776)================ On big-endian machines, the 64-bit iAS ODBC driver could have returned random values when an application was trying to retrieve the following statement attributes: SQL_ATTR_METADATA_ID SQL_ATTR_ROW_NUMBER SQL_ATTR_ROW_ARRAY_SIZE SQL_ATTR_PARAMSET_SIZE SQL_ATTR_MAX_LENGTH SQL_ATTR_MAX_ROWS The driver was using SQLUINTEGER for these statement attributes. It has been corrected to now use SQLULEN. ================(Build #2428 - Engineering Case #626951)================ The iAS Oracle ODBC driver could not detect connection status correctly when a connection was forcibly disconnected by the server. Due to this problem, an application, such as the MobiLink server, might not re-establish a new connection and would have reported the same errors repeatedly. This problem is fixed now. ================(Build #2278 - Engineering Case #579837)================ The iAnywhere Solutions Oracle ODBC driver could not recognize synonyms of stored procedures. Thus an application, such as the MobiLink server, that uses this driver was not able to execute procedure synonyms if the DSN used by the application was configured with the "Procedure returns results" check box checked. This problem has now been fixed. ================(Build #2271 - Engineering Case #573625)================ If an application asked for the connection status through the following ODBC API SQLGetConnectAttr( hdbc, SQL_ATTR_CONNECTION_DEAD, ... ) after an error occurred, the iAnywhere Solutions ODBC driver for Oracle could told the application that the connection was still alive, even though the connection had actually been killed, or had timed out. If this problem occurred for the MobiLink server main connection, in most cases, the server would have displayed the following messages: [10009] MobiLink table 'ml_scripts_modified' is damaged [-10020] Unable to flush scripts and refused any synchronization requests. This MobiLink server would then have needed to be be restarted in order to carry on any synchronization. This problem is fixed now. ================(Build #2265 - Engineering Case #578401)================ The iAnywhere Solutions ODBC driver for Oracle could have held the socket descriptor and service handle, even when the database connection had been disconnected. This could have resulted in the driver running out of service handles with the following error: "ORA-12519: TNS:no appropriate service handler found". The OCI function, OCIServerDetach, was missing in the logoff function. This has now been corrected. ================(Build #2250 - Engineering Case #574354)================ The iAS ODBC driver for Oracle could have crash in a stored procedure call, if the stored procedure contained char or varchar type INOUT parameters, and the data length of these parameters was greater than 2000 bytes (1000 bytes for driver versions, 9.0.2 and 10.0.1). This has now been fixed. ================(Build #2203 - Engineering Case #567794)================ If the MobiLink Server was connected to an Oracle consolidated database, and an event was defined that called a stored procedure within a package, it was possible for a crash to have occurred in the iAnywhere Oracle ODBC Driver, which would in turn crash the MobiLink Server. This problem has now been fixed. ================(Build #2157 - Engineering Case #561820)================ The iAS ODBC driver for Oracle could have leaked memory when fetching binary data (CLOB, BLOB, NCLOB, LONG VARCHAR, and LONG RAW) from an Oracle database. This problem would only have occurred when sending the fields as part of the MobiLink download stream to the remote. This has now been fixed. ================(Build #2139 - Engineering Case #556326)================ Applications running on Unix systems, and using the iAS ODBC driver for Oracle, could have received an "Out of memory" error when calling SQLTables, SQLColumns, SQLPrimaryKeys, SQLForeignKeys, SQLProcedureColumns, SQLProcedures, or SQLStatistics. This problem has now been fixed.

MobiLink - scripts

================(Build #2837 - Engineering Case #712456)================ When using the DBRowReader class, it was possible for all the values in a long column to be erroneously returned as NULL. This has been fixed.

SQL Anywhere - ADO.Net Managed Provider

================(Build #3130 - Engineering Case #760873)================ Named parameter lookup performed poorly. The GetInputParameterValues method has now been rewritten to improve the speed of named parameter lookup. ================(Build #3126 - Engineering Case #759830)================ An application using the ADO.Net Manager Provider could have failed with the error “Unable to load DLL ‘dbdata16.dll’” when calling SAConnectionStringBuilder.ToString. Ths has now been corrected. ================(Build #3113 - Engineering Case #758073)================ The Visual Studio 2010 compiler could have crashed when generating Entity Data Models. This has now been fixed. ================(Build #3070 - Engineering Case #750915)================ The SABulkCopy method would have thrown an exception when using SQL Server as the data source. This has now been corrected. ================(Build #3061 - Engineering Case #750008)================ In a multithreaded ADO.NET application, there was a possibility for process execution to hang, or for an exception to occur. Three problems were identified and corrected. ================(Build #3057 - Engineering Case #749295)================ The Dispose function of SATransaction did not automatically do a rollback. This nhas now been corrected. ================(Build #3013 - Engineering Case #742857)================ When reading Long Varchar or Long Binary columns using SADataReader, the results could have been truncated to 65535 chars. This has now been fixed. ================(Build #3000 - Engineering Case #741721)================ Calling the SAConnection.ConnectionString property could have caused the provider to crash with a NullReferenceException. This has now been fixed. ================(Build #2976 - Engineering Case #738144)================ In rare circumstances, calling SAConnection could have throw a NullReferenceException when the ConnectionString property was accessed. This has now been fixed. ================(Build #2957 - Engineering Case #735130)================ Using the Entity Framework in an ASP.NET MVC application could have caused a NullRferenceException. The provider was not checking if the Type.FullName was null before calling the method Type.FullName.StartsWith. This has been corrected. ================(Build #2926 - Engineering Case #728589)================ Calling Entity Framework SaveChanges could have caused a NullReferenceException if the entity model had properties with “fixed” concurrency mode. This has now been fixed. ================(Build #2901 - Engineering Case #723698)================ A client application could recieved the exception OptimisticsConcurrencyException when updating tables with computed columns. This has now been fixed. ================(Build #2894 - Engineering Case #721637)================ An ADO .Net application could have failed to fetch from a proxy table with blob columns. The error returned would have been: “Cursor is restricted to FETCH NEXT operations”. This problem has now been fixed. ================(Build #2891 - Engineering Case #721757)================ The Password field in the connection string (file App.config) could have been inadvertently removed during execution when running the Entity Framework application. This problem has been fixed. ================(Build #2871 - Engineering Case #718762)================ The “Function Import” construct within the Entity Framework would have failed with a NullReferenceException for return types of "None". This problem has been fixed. ================(Build #2871 - Engineering Case #718761)================ SABulkCopy would have failed with an OutOfMemoryException when copying large tables using a DataReader. This problem has been fixed. ================(Build #2870 - Engineering Case #717363)================ The ADO.NET provider was generating inefficient queries, using CHARINDEX, for some Entity Framework functions, such as StartsWith, EndsWith, and Contains. This problem has been fixed. ================(Build #2868 - Engineering Case #718046)================ When creating an ADO.NET Entity Data Model using an existing stored procedure, some of the SQL Anywhere data types were not mapped correctly. This would have been seen when clicking the "Get Column Information" button in the "Add Function Import..." dialog. This has been corrected. ================(Build #2855 - Engineering Case #716390)================ N ADO .Net client application could have received a NullReferenceException when updating entities using Fixed concurrency mode. This problem has been fixed. ================(Build #2813 - Engineering Case #707922)================ UPDATE statements generated by the Entity Framework could have failed with a syntax error if the table being updated had a uniqueidentifier key column. This problem has been fixed. ================(Build #2812 - Engineering Case #707952)================ When using a version 10.0, 11.0 or 12.0 of ADO.NET provider with a version 9.0 server, the .NET string parameters are incorrect mapped to nvarchar. This problem has been fixed. ================(Build #2795 - Engineering Case #704978)================ Updating an entity could have returned incorrect values for computed columns. ================(Build #2773 - Engineering Case #699241)================ Using the SQL Anywhere ADO .NET Data Provider, the continuous closing and reopening of a pooled connection was slower than it was under version 9.0.2. This problem has been corrected. SAConnection conn = new SAConnection( connectString ); conn.Open(); . . . conn.Close(); ================(Build #2772 - Engineering Case #700928)================ The Entity Framework migration tools could have thrown an exception if the schema name of an entity set was not specified. For example: public class BlogContext : DbContext { public DbSet<Blog> Blogs { get; set; } } [Table( "Blogs" )] // [Table( "Blogs", Schema = "GROUPO" )] public class Blog { public int BlogId { get; set; } public string Name { get; set; } public string Url { get; set; } public int Rating { get; set; } } This has now been fixed. ================(Build #2725 - Engineering Case #692504)================ Entity Famework queries could have returned incorrect result when using parameters. This has been fixed. ================(Build #2709 - Engineering Case #690295)================ An IIS web server application could have crashed after running for a few days. This has now been fixed. ================(Build #2707 - Engineering Case #689764)================ The assembly names of version 3.5 and 4.0 providers in the policy config file were not correct. This meant that version 3.5 and 4.0 policy files did not redirect old versions to a newer version. This has been corrected ================(Build #2685 - Engineering Case #687578)================ Applications using the .Net provider could have crashed after running for some time. In rare occasions, the provider could have attempted to drop a prepared statement twice. This has now been fixed. ================(Build #2674 - Engineering Case #683999)================ When calling the method SADataReader.GetSchemaTable, the SQL Anywhere provider creates two prepared statements which were not dropped immediately in some situations. Actually, the statements are dropped either when the SACommand objects (created in SADataReader.GetSchema Method as local variables) are garbage collected, or when creating a new command and the number of prepared statements has exceeded the 'max_statement_count' option. Still, the SADataReader.GetSchema method has now been modified to dispose of the commands within the SADataReader.GetSchema method. This will drop the prepared statements immediately. ================(Build #2665 - Engineering Case #682662)================ A small amount of memory was leaked when an application using the ADO.NET interface executed a distributed transaction. This has now been fixed. ================(Build #2662 - Engineering Case #681915)================ A client application could have failed with an AccessViolationException, instead of a normal communication error, when a connection was dropped. This problem has been fixed. ================(Build #2629 - Engineering Case #675805)================ It is possible, although rare, for the machine.config file to contain multiple registered SQL Anywhere ADO.NET providers. When unregistering, the SetupVSPackage.exe utility only removed one SQL Anywhere ADO.NET provider from the machine.config file. This problem has been fixed so that SetupVSPackage.exe now looks for all registered SQL Anywhere ADO.NET providers. ================(Build #2612 - Engineering Case #671397)================ The following Entity Framework datetime functions were not mapped to SQL Anywhere functions: AddDays, AddHours, AddMicroseconds, AddMilliseconds, AddMinutes, AddMonths, AddSeconds, AddYears, DiffHours, DiffMicroseconds, DiffMilliseconds, DiffMinutes, DiffMonths, DiffSeconds, DiffYears. For example: Entities db = new Entities(); var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays( x.OrderDate, DateTime.Now ) > 100 ); string trace = ( ( ObjectQuery ) query ).ToTraceString(); This problem has been corrected by adding new function handlers for mapping Entity Framework datetime functions to the SQL Anywhere functions 'DATEADD' and 'DATEDIFF'. ================(Build #2604 - Engineering Case #669227)================ On systems running Windows Vista or later, when using the Visual Studio Add Connection wizard the SQL Anywhere .NET provider listed USER DSNs only in the ODBC Data Sources drop-down list. The SYSTEM DSNs are omitted. This problem has been corrected. The SetupVSPackage tool must be run to install this fix. It should be noted that on 64-bit Windows, only the 64-bit SYSTEM DSNs are listed (after this correction). Any 32-bit SYSTEM DSNs are not displayed. In Visual Studio 2008's design environment (which is 32-bit on 64-bit platforms), the Test Connection button will attempt to establish a connection using the 32-bit equivalent of the 64-bit DSN. If the 32-bit DSN does not exist, the test will fail. ================(Build #2600 - Engineering Case #668141)================ Calling the method SATcpOptionsBuilder.ClientPort could have caused the exception InvalidCastException to have been thrown. For example: SATcpOptionsBuilder options = new SATcpOptionsBuilder( "localonly=yes;port=6873" ); string cport = options.ClientPort; This problem has been fixed. ================(Build #2600 - Engineering Case #667672)================ The Entity Framework function 'DiffDays' was not mapped to the SQL Anywhere function 'Days'. For example: Entities db = new Entities(); var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays( x.OrderDate, DateTime.Now ) > 100 ); string trace = ( ( ObjectQuery ) query ).ToTraceString(); This problem has been fixed. ================(Build #2599 - Engineering Case #667762)================ SetupVSPackage.exe would have failed to add some dlls to the Global Assembly Cache on 64 bit Windows systems. This problem has been fixed. Also, a new command line option 'salocation' (or 'sal') has been added to SetupVSPackage to allow specifying the SQL Anywhere install location. If 'salocation' is specified, SetupVSPackage will use it to locate the necessary dlls. If 'salocation' is not specified, SetupVSPackage will use SQL Anywhere registry keys to locate the dlls. ================(Build #2597 - Engineering Case #667441)================ Misleading error messages would have been returned to the client when opening a connection using an invalid DSN. This problem has been fixed. ================(Build #2589 - Engineering Case #667927)================ The SQL Anywhere .NET Provider, running in 64-bit mode, might have inadvertently attempted to load a 32-bit language resource DLL (e.g., dblgen12.dll) and failed with an error. This problem has been corrected. ================(Build #2581 - Engineering Case #663470)================ On CE devices, if multiple applications were running simultaneously, the library dbdata.dll could have been deployed multiple times to the temp directory. This problem has been fixed. Additionally, the version number has been added to the native dll name (i.e. dbdata12.dll). This will allow running multiple versions of the provider simultaneously on Windows CE. ================(Build #2571 - Engineering Case #661459)================ The .NET provider was incorrectly assuming that a Sybase IQ 12.7 server supported the NCHAR datatype. This resulted in a failure to establish a connection to a Sybase IQ 12.7 server. This problem has been fixed. ================(Build #2560 - Engineering Case #657542)================ The results of an Entity DAta Model query could have been non-deterministic. For example, having a GridView with the properties "AllowPaging" and "AllowSorting" set to "True", would have returned a "Result is non-deterministic" warning (SQLCODE 122). This has been fixed by adding an ORDER BY clause to the generated SQL. ================(Build #2553 - Engineering Case #656481)================ An application using the ADO .Net provider, and calling the method SAConnection(), could not have successfully connected to an IQ 12.7 server. A run-time error (iAnywhere.Data.SQLAnywhere.SAException) would have occurred when the provider tried to parse the server version string. This problem has been resolved. ================(Build #2547 - Engineering Case #654446)================ If there were multiple applications running simultaneously, the ADO.NET provider could have failed to load dbdata.dll. This has now been fixed. ================(Build #2535 - Engineering Case #651510)================ Execution of the utility SetupVSPackage, would have shown an error: "Object reference not set to an instance of an object." if machine.config file did not have the entry <DbProviderFactories>. This problem has been fixed. ================(Build #2529 - Engineering Case #649763)================ If an application connected with autostop=yes, and subsequently made a CLR external environment call, then the CLR external environment could have crashed when the application disconnected. This problem has now been fixed. ================(Build #2515 - Engineering Case #646349)================ The SQL Anywhere BINARY datatype was mapped to SQL Server's BINARY datatype. This could have resulted in incorrect values when exporting SQL Anywhere tables to SQL Server, as the SQL Anywhere BINARY datatype is variable length, and the SQL Server BINARY datatype is fixed length. This has been corrected by mapping the SQL Anywhere Binary datatype to SQL Server's VARBINARY datatype. ================(Build #2505 - Engineering Case #643822)================ Schema locks were not being released when the execution of ExecuteReader() encountered an exception. If a BeginTransaction was called, a Rollback or Commit should be called by the application to release the locks. Now, if BeginTransaction is not called, the transaction will be automatically rolled when an exception is encountered. ================(Build #2501 - Engineering Case #643230)================ The datatypes sysname and uniqueidentifierstr were both being mapped to char(0) in Micrsoft's SQL Server Integration Services. This has been corrected so that sysname is now mapped to varchar(30), and uniqueidentifierstr is now mapped to char(36). ================(Build #2501 - Engineering Case #642563)================ When running the install generated by the Deployment wizard, the ADO.NET provider was not registered correctly. Running the utility setupvspackage.exe manually after the install finished would have correctly registered the .NET provider. This has now been fixed. ================(Build #2500 - Engineering Case #642971)================ The utility SetupVSPackage.exe would have thrown the error "Object reference not set to an instance of an object.", if the .NET Framework 4.0 was not installed. This problem has been fixed. ================(Build #2493 - Engineering Case #640786)================ Calls to the GetSchema method would have return an error when the restrictions vector size was less than the total number of restrictions. For example, if 2 restrictions were specified for a schema rowset that took up to 3 restrictions, the GetSchema call would have resulted in an error indicating that 3 restrictions were expected. The error was due to the fact that the array size is 2, not 3. This problem has been fixed. ================(Build #2492 - Engineering Case #640589)================ The utility SetupVSPackage.exe did not modify the file machine.config for the 64 bit .NET Framework. The machine.config file is now updated for both the 32 bit and 64 bit Frameworks on 64 bit Windows. ================(Build #2490 - Engineering Case #640239)================ The SetupVSPackage.exe utility did not update SQL Server Integration Services mapping files and the ProviderDescriptors.xml file for 64 bit DTS on 64 bit Windows. This problem has been fixed. ================(Build #2482 - Engineering Case #637909)================ Executing a stored procedure and fetching the result set would have thrown the exception "Index was outside the bounds of the array" if the stored procedure selects results from a local temporary table with blob columns. The provider was determining the row buffer length prior to opening the cursor, this has been corrected so that it is done after the cursor has been opened. ================(Build #2480 - Engineering Case #638231)================ The property SAConnection.State would have indicated that the connection was still open even after the connection had been dropped. This has now been corrected. ================(Build #2479 - Engineering Case #637725)================ The Available objects list would have been empty when creating SQL Server Integration Services data source view. This problem has been fixed. ================(Build #2465 - Engineering Case #634919)================ The utility SetupVSPackage.exe did not modify the Global Assembly Cache (GAC) or the machine.config file if Visual Studio was not installed. This problem has been fixed. ================(Build #2463 - Engineering Case #634504)================ SQL Anywhere ODBC data sources were not listed in Visual Studio's Add Connection dialogbox on 64 bit Windows systems. This has now been fixed. ================(Build #2456 - Engineering Case #637453)================ With the changes for Engineering case 576252, support for SQL Anywhere Explorer and SQL Anywhere Toolbar was disabled for Visual Studio version 2010. Now, SQL Anywhere Explorer and SQL Anywhere Toolbar have been disabled for Visual Studio versions 2005 and 2008 as well. ================(Build #2452 - Engineering Case #632608)================ The performance for fetching BLOB columns was much slower compared with the managed OLE DB provider. This problem has been corrected. ================(Build #2444 - Engineering Case #631249)================ The result sets returned by calls to SAConnection.GetSchema( "Columns" ) and SAConnection.GetSchema( "DataTypes" ) could have been incorrect. This has been fixed. ================(Build #2443 - Engineering Case #631026)================ When using the ADO.NET provider to insert long binary, varchar or nvarchar values with a SQL_BINARY, SQL_VARCHAR or SQL_NVARCHAR parameter type, the parameter type that is passed to the server will be changed to SQL_LONGBINARY, SQL_LONGVARCHAR or SQL_LONGNVARCHAR if the length of the value to be inserted is greater than 32767 bytes. ================(Build #2443 - Engineering Case #630913)================ If some columns had been dropped from a table, SAConnection.GetSchema( "Columns" ) could have returned incorrect ORDINAL_POSITION values for that table. This has been fixed. ================(Build #2443 - Engineering Case #630911)================ Some result sets returned by by the method SAConnection.GetSchema() were not sorted. This has been corrected. ================(Build #2443 - Engineering Case #630909)================ Calls to the method SADataAdapter.Update() in batch update mode would have hung when updating large tables. This has been fixed. ================(Build #2442 - Engineering Case #630542)================ In the SADataReader's schema table, , the SCALE property for Date, DateTime, DateTimeOffset, SmallDateTime, Time, Timestamp, and Timestamp with time zone columns, has been changed to 6. ================(Build #2442 - Engineering Case #630540)================ The method SAConnection.ServerVersion() has been changed to return normalized version strings that match the strings returned by SqlConnection.ServerVersion(). ================(Build #2442 - Engineering Case #630408)================ The method SAConnection.GetSchema() would have returned incorrect data. Database objects owned by system accounts were being included in the result sets. They are now excluded. ================(Build #2439 - Engineering Case #629758)================ The SAConnection.GetSchema method returned incorrect schema data for the DataTypes schema set and the DataSourceInformation schema set. This problem was found using the SQL Server Integration Service's Import and Export Wizard. This has now been corrected. ================(Build #2438 - Engineering Case #629304)================ The values for DataSourceProductVersion and DataSourceProductVersionNormalized returned by the SAConnection.GetSchema method didn't match the ADO.NET specification. The normalized version string should have been like nn.nn.nn.nnnn. For example, SQL Server 2008 would return "DataSourceProductVersion = 10.00.1600, DataSourceProductVersionNormalized = 10.00.1600". SQL Anywhere was returning "DataSourceProductVersion = 12.0.0.1234, DataSourceProductVersionNormalized = 12.0.0". This has now been corrected. ================(Build #2435 - Engineering Case #628587)================ A multithreaded application could have failed to load the unmanaged dll. This has now been corrected. ================(Build #2432 - Engineering Case #625219)================ A prepared statement was not being dropped when an exception occurred while calling the method SACommand.ExecuteReader. This problem has been fixed. ================(Build #2431 - Engineering Case #627780)================ The Start Server in Background utility (dbspawn) would have failed to start a database server if the full path to the server executable was given and that path contained a space. This has now been fixed. ================(Build #2411 - Engineering Case #622789)================ Applications running on on Windows 7 64 bit systems could have crashed when canceling the methods EndExecuteReader or EndExecuteNonQuery. This problem has been fixed. ================(Build #2397 - Engineering Case #619719)================ ADO.Net client applications could have hung in very rare circumstances when fetching data readers. This problem has been fixed. ================(Build #2388 - Engineering Case #617699)================ The message "Statement interrupted by user" was not being returned after a user canceled a command. This problem has been fixed. ================(Build #2388 - Engineering Case #617178)================ The asynchronous command execution ( BeginExecuteReader and BeginExecuteNonQuery ) could have been blocked by exclusive table locks. This problem has been fixed. ================(Build #2352 - Engineering Case #606683)================ The build number on policy.11.0.iAnywhere.Data.SQLAnywhere.dll is incorrect. This has been corrected. ================(Build #2344 - Engineering Case #605792)================ If an internal connection was the cause of a diagnostic message, it might have been identified with the phrase 'another user'. A more descriptive string identifying the connection will now be used. For example, one might now get a diagnostic message such as: User 'Cleaner' has the row in 'x' locked (SQLCODE: -210; SQLSTATE: 42W18) ================(Build #2334 - Engineering Case #595100)================ The Connect to Database dialog had strings overlapping text boxes. The "Connection String:" string and the "Specify Custom User" string overlapped their text boxes. This has been corrected. ================(Build #2325 - Engineering Case #591833)================ The ADO.NET provider could have failed to unpack and load dbdata.dll. A race condition has been fixed. ================(Build #2302 - Engineering Case #586217)================ Methods in the SADataReader clase could have returned an incorrect fraction for datetime and time columns. This has now been corrected. ================(Build #2272 - Engineering Case #580607)================ User Impersonation on IIS caused Win32Exception "Access is denied". This has been fixed. ================(Build #2266 - Engineering Case #577974)================ Using an ADO.NET Entity Data Model object with an ASP.NET Web Site project did not work correctly. This has been corrected. ================(Build #2265 - Engineering Case #578172)================ Calls to the methods SADataReader and SADataAdapter would not have returned any data for temporary tables. An AutoCommit when opening a data reader would have dropped temporary tables. This has now been fixed. ================(Build #2257 - Engineering Case #576252)================ Support for SQL Anywhere Explorer and SQL Anywhere Toolbar has been disabled for Visual Studio 2010. They still support Visual Studio versions 2005 and 2008. ================(Build #2182 - Engineering Case #565104)================ The php process may have crashed after completing a php external environment call. This has been fixed.

SQL Anywhere - DBLIB Client Library

================(Build #2916 - Engineering Case #725206)================ A FETCH RELATIVE {offset}, where the offset was greater than 1, could have failed with a "Connection was terminated" error if the fetch was not the first fetch on the cursor, and prefetch was enabled for the fetch. For this to have ocurred, the rows between the last fetch and the requested rows row had to have values that were greater than 250 bytes. This has been fixed. As a workaround, prefetch can be disabled. ================(Build #2786 - Engineering Case #703452)================ If a SQL Anywhere client application exited abnormally, System V semaphores that were allocated by the SA libraries were not cleaned up. This problem affected all Unix platforms except Solaris, and has now been fixed. ================(Build #2730 - Engineering Case #693539)================ The changes for Engineering case 635466 introduced a problem where, on machines under heavy load, TCP connection attempts could have failed with an incorrect error code. On certain operating systems, the connection attempt could have hung. This has been fixed. ================(Build #2653 - Engineering Case #680183)================ In rare timing-dependent cases, a multi-threaded client application that made simultaneous connection attempts from different threads may have crashed. This has been fixed. ================(Build #2602 - Engineering Case #668603)================ In rare cases, an application could have failed to connect because of a TCP/IP communication link failure. No specific reason for the failure would have been logged to the file specified by the LOGFILE connection parameter. This has been fixed. Note, this problem affected the .Net provider, the ODBC, JDBC and OLEDB drivers as well. ================(Build #2567 - Engineering Case #660204)================ Specifying a TCP timeout value of more than 2147 seconds could have caused connection failures. This has been fixed. ================(Build #2566 - Engineering Case #659643)================ An application could have crashed if it was attempting an Integrated Login or Kerberos connection and the connection to the server was lost. This could have occurred if the server was stopped or terminated during the connection. This has been fixed. ================(Build #2509 - Engineering Case #643421)================ If an application was attempting to connect to a server and the server shut down between the time the protocol connection was made and the time the database connection was attempted, the application could have crashed. This has been fixed. ================(Build #2495 - Engineering Case #641485)================ Attempting to make a connection with invalid TCPIP protocol options could have caused a crash in the client library. This has been fixed. ================(Build #2478 - Engineering Case #635466)================ When making a TCP connection to a remote machine that was unavailable (i.e. powered off, network cable unplugged, etc.), the time taken to time out could have been far longer than the value of the TIMEOUT parameter. This has been fixed. ================(Build #2443 - Engineering Case #631023)================ SA Clients on Mac OS X systems would have received the error "TLS handshake failure" (SQLCODE -829) when attempting to connect using TLS/RSA to a server running on a different operating system. This has been fixed. Note: Engineering case 626480 included new versions of the Certicom and OpenSSL libraries. This problem only affects Mac OS X clients with these new libraries connecting to servers on a different operating system also with these new libraries. ================(Build #2400 - Engineering Case #619937)================ An embedded SQL application that attempted to fetch into a sqlvar of type DT_VARCHAR, DT_NVARCHAR or DT_BINARY, with a negative sqllen, could have crashed due to a memory overrun. A negative sqllen with these types is invalid and should never be passed to DBLib. DBLib has now been fixed to make the memory overrun less likely. ================(Build #2377 - Engineering Case #615254)================ If a percent character "%" was used in a RAISERROR statement, then retrieving the error using sqlany_error() would have returned garbage characters for the percent character. This has been fixed. ================(Build #2360 - Engineering Case #609708)================ When using the SQL Anywhere C API and binding parameters for prepared statements and calling sqlany_execute() multiple times, the second and subsequent calls to sqlany_execute() would have failed with the error "Cursor already open". The problem was introduced as part of the changes for Engineering case 560351. This has now been fixed. ================(Build #2360 - Engineering Case #609704)================ When calling the SQL Anywhere C API function sqlany_clear_error() the resulting SQLSTATE value would have been set to the empty string instead of "00000". This has been fixed. ================(Build #2353 - Engineering Case #607330)================ The SQL Anywhere C API was fetching the TINYINT data type as a signed value. This has been fixed. ================(Build #2316 - Engineering Case #590383)================ On UNIX systems, there were directories left in the temporary directory, with names of the form __SQLAnyCli__X_Y, where X is a process number and Y is an alphanumeric number. This usually happened when a SQL Anywhere client application was terminated abnormally. An example of this was the PHP driver running within the Apache web server. This has been fixed. ================(Build #2291 - Engineering Case #584721)================ When using the SQL Anywhere C API, no error information was returned when a connection attempt failed. This problem was introduced as part of a previous fix to dbcapi, and has now been corrected. ================(Build #2247 - Engineering Case #573228)================ When concurrent connection requests were made to servers running on multi core or multi processor Unix systems, connections could, in rare cases, have hung, received communication errors, or otherwise failed. This has been fixed. ================(Build #2203 - Engineering Case #567417)================ The DBLib client library could have crashed if there was a language resource problem, such as a missing language dll or .res file. In order for this crash to have occurred, db_init must have been called at least twice, and then another dblib call must have been made (such as db_string_connect or EXEC SQL CONNECT). This has been fixed, and db_init will now return 0 on language resource problems. ================(Build #2183 - Engineering Case #565255)================ A multi-threaded embedded SQL application could have crashed if db_fini was called with the last active SQLCA at the same time as db_init was called with another SQLCA. The crash was very timing dependent. A race condition has been corrected. ================(Build #2150 - Engineering Case #559632)================ An embedded SQL PREPARE or OPEN request could have caused the application to crash in rare cases, if the connection was dropped before, or during, the request. This has been fixed. ================(Build #2149 - Engineering Case #559600)================ Executing a "MESSAGE .. TO CLIENT FOR CONNECTION conn-id IMMEDIATE" statement shortly before the target connection abnormally disconnected could have resulted in the message callback being called after an API request returned an error. The abnormal disconnect could have been caused by a liveness timeout, idle timeout, DROP CONNECTION, server shut down, or other conditions. Depending on the application's message callback routine, this could have resulted in a crash or other incorrect behaviour. This has been fixed so that the message callback will not be called after an API request has returned an error due to an abnormal disconnect. ================(Build #2136 - Engineering Case #555450)================ Column names that are greater than 29 bytes in length were being truncated. This has been fixed.

SQL Anywhere - JDBC Client Library

================(Build #3047 - Engineering Case #747898)================ When using the SQL Anywhere JDBC driver, if two or more addBatch calls are followed by an executeBatch and then the application used executeUpdate in non-batched mode, the application would have crashed. This problem has been fixed. A work-around is to use addBatch/executeBatch for all executions of the prepared statement once addBatch/executeBatch has been used. ================(Build #2951 - Engineering Case #733726)================ If an application using the SQL Anywhere JDBC Driver failed to explicitly close all open connections before attempting to exit, then there was a chance the Java VM would have crashed. This was most noticeable on Unix platforms. This problem has now been fixed. ================(Build #2946 - Engineering Case #732853)================ Attempting to create a Mobilink project using Sybase Central on a 64-bit platform could in some cases have caused Sybase Central to crash. This problem was most noticeable on Solaris and Mac platforms. The problem has now been fixed. ================(Build #2935 - Engineering Case #722245)================ Calling PreparedStatement.setNull() and passing in a SQL type of java.sql.Types.NULL, would have incorrectly returned a “bad datatype” error. This problem has now been fixed and java.sql.Types.NULL is now allowed in setNull() calls. ================(Build #2903 - Engineering Case #725201)================ If an application loaded the SQL Anywhere JDBC Driver into a private ClassLoader, there was a small chance that the application would have crashed when the private ClassLoader was garbage collected. This problem has now been fixed. ================(Build #2876 - Engineering Case #719089)================ A JDBC application that connected using the SQL Anywhere JDBC driver, and then subsequently exited with a large number of connections still open, could in rare cases crash or hang. This problem has now been fixed. ================(Build #2801 - Engineering Case #705368)================ If a JDBC application using the SQL Anywhere JDBC Driver called the "autoGeneratedKeys" overload of Connection.prepareStatement(), Statement.execute() or Statement.executeUpdate() with Statement.NO_GENERATED_KEYS, then the JDBC driver would incorrectly throw a "generated keys not supported" exception. This problem has now been fixed and calling these overloads with Statement.NO_GENERATED_KEYS now simply calls the "non-autoGeneatedKeys" overload. ================(Build #2728 - Engineering Case #693005)================ If a JDBC application was launched, and no language resource DLL or shared object was located, the application would have gone into a loop consuming virtual memory until an "out-of-memory" error occurred. This problem has been fixed. ================(Build #2696 - Engineering Case #687796)================ If an application using the SQL Anywhere JDBC driver attempted to exit, then there was a very small chance the client would crash on non-MacOS systems; however, on MacOS systems, the crash would have occurred every time. This problem has now been fixed. Note that the original problem was introduced with the fix for Engineering case 680183. ================(Build #2540 - Engineering Case #652739)================ If an application prepared a batch insert using the SQL Anywhere JDBC driver, and the last row in the batch involved a call to setNull() and the datatype passed to setNull() was different than the previous set of setX calls for that column, then there was a chance the JDBC driver would have inserted incorrect data. This problem has now been fixed. For example, the following set of calls would have inserted incorrect data into the table test: PreparedStatement pstmt = con.prepareStatement( "insert into test values(?,?)" ); pstmt.setInt(1, 1001); pstmt.setString(2, "this is row #1" ); pstmt.addBatch(); pstmt.setInt(1, 2001); pstmt.setString(2, "this is row #2" ); pstmt.addBatch(); pstmt.setInt(1, 3001); pstmt.setString(2, "this is row #3" ); pstmt.addBatch(); // note the fact that we are switching datatypes below pstmt.setNull(1, java.sql.Types.SMALLINT); pstmt.setString(2, "this is row #4" ); pstmt.addBatch(); pstmt.executeBatch(); Again, note that this problem would not have occurred if instead of using java.sql.Types.SMALLINT, the application instead used java.sql.Types.INTEGER. In addition, if the call to setNull() was not in the last row of the batch, then again this problem would not have occurred, even if the application switched datatypes for the setNull() call. ================(Build #2497 - Engineering Case #642015)================ Due to an uninitialized variable in the iAnywhere JDBC driver, applications using the driver (such as the MobiLink server) could have crashed when trying to access a result set. This problem has now been fixed. ================(Build #2483 - Engineering Case #638600)================ When connected using the SQL Anywhere JDBC 4.0 driver, calling DatabaseMetaData.getProcedureColumns() would have returned a result set with the DATA_TYPE column in the metadata result set containing an incorrect JDBC data type for nchar, nvarchar and longnvarchar columns. This problem has now been fixed. ================(Build #2483 - Engineering Case #638273)================ While connected using the SQL Anywhere or iAnywhere JDBC drivers, attempting to use setNull() in a batch update may have caused the JDBC driver to throw a datatype mismatch SQLException if the datatype specified within the setNull() call differed from other non-null set calls to the same column within the batch update. This problem has now been fixed and the datatype mismatch will now only be thrown if a non-null set call of a different type is made on the same column within a batch update. ================(Build #2444 - Engineering Case #631045)================ If an application attempted to establish a connection using the ASADataSource class available with the SQL Anywhere JDBC driver, then the application would have received a ClassCastException. This problem has now been fixed. Note that in addition to supporting the ASADataSource class, the SQL Anywhere and iAnywhere JDBC drivers now offer an SADataSource class as well. ================(Build #2444 - Engineering Case #630475)================ If an application used the SQL Anywhere JDBC driver to obtain the ResultSet from a call to DatabaseMetaData.getPrimaryKeys(), then the driver would incorrectly return a ResultSet that was sorted by catalog, schema, table name and key sequence. This has now been fixed and the ResultSet is now sorted by column name instead. Note that this fix is only for the SQL Anywhere JDBC driver. The iAnywhere JDBC driver will continue to return a ResultSet based on ODBC sorting standards. ================(Build #2394 - Engineering Case #619037)================ If an application opened multiple database metadata result sets, and the application closed the metadata result sets appropriately, there was still a chance that the iAnywhere JDBC driver would have closed one of the open metadata result sets, even though the application had not reached the limit of 3 metadata result sets open at any given time. This problem has now been fixed. ================(Build #2389 - Engineering Case #618212)================ If an application connected using the iAnywhere JDBC driver, and then subsequently called one of the read() overloads of ResultSet.getBlob().getBinaryStream(), if the blob value was a non-NULL zero length long binary value, then the read() method would have incorrectly returned 0, instead of -1 to signal the end of the input stream. This problem has now been fixed. Note, this problem was introduced by the changes for Engineering case 609739. ================(Build #2365 - Engineering Case #609739)================ When an application retrieved a Blob object by calling ResultSet.getBlob(), and the application subsequently retrieved the Blob's InputStream by calling Blob.getBinaryStream(), the applications performance would have been severely impacted if the application called InputStream.read( byte[] ) or InputStream.read( byte[], int, int ) on the Blob InputStream. This problem has now been fixed. Note that a workaround is to use Blob.getBytes() directly, instead of using the Blob InputStream. ================(Build #2362 - Engineering Case #610533)================ If an application retrieved a ResultSet via a DatabaseMetaData call, and the application subsequently retrieved the underlying Statement object of that ResultSet by calling ResultSet.getStatement(), then attempting to close that DatabaseMetaData Statement object could have crashed the application. The problem with closing DatabaseMetaData Statement objects has now been fixed. Note that in general, applications do not explicitly need to close DatabaseMetaData Statement objects; hence the chances of an application crashing due to this problem are rare. Closing the ResultSet of a DatabaseMetaData call is not uncommon and not affected by this. ================(Build #2360 - Engineering Case #609736)================ If an application had a connection that was holding on to table locks, and the same application had other connections that were blocked in the server waiting for the table locks to be released, then there was a chance the application would have hung if the connection holding on to the table locks subsequently called Connection.createStatement(). This problem has now been fixed. ================(Build #2357 - Engineering Case #608751)================ If an application called IBlob.getBytes() with a position value <= 0, or a length value < 0, then the getBytes() method would have incorrectly returned NULL. The JDBC driver now correctly throws a SQLException for these cases. ================(Build #2357 - Engineering Case #608750)================ If an application called ResultSet.getObject() on an unsigned smallint, int or bigint column, then the JDBC driver may have given a conversion error. This problem has now been fixed such that calling ResultSet.getObject() on an unsigned column will now promote the datatype. Hence, calling ResultSet.getObject() on an unsigned smallint column will now return an int; similarly, an unsigned int column will now return a long, and an unsigned bigint column will now return a BigDecimal. It should be noted that most applications prefer to have full control on the column object so it is always better to use one of the getShort(), getInt(), getLong() and getBigDecimal() methods explicitly rather than using an implicit method like getObject(). ================(Build #2355 - Engineering Case #608106)================ If an application called ResultSet.getObject() on a tinyint column, and the column value ranged from 128 to 255, then the JDBC driver would have incorrectly thrown a SQLException with a conversion error. This problem has now been fixed. ================(Build #2332 - Engineering Case #594666)================ If an application called the ODBC function ResultSet.getCursorName(), then the iAnywhere JDBC Driver would have returned a truncated cursor name. The JDBC driver was incorrectly assuming that the returned length from SQLGetCursorNameW was in bytes, when in fact the value returned is in characters. This problem has been fixed, and the full cursor name is now properly returned. ================(Build #2331 - Engineering Case #594327)================ If an application called the method DatabaseMetaData.getDatabaseProductVersion() on a closed Connection object, then the iAnywhere JDBC Driver would have thrown a NullPointerException, instead of returning the appropriate SQLException. This problem has now been fixed. ================(Build #2331 - Engineering Case #593347)================ An application connected using the iAnywhere JDBC Driver, and calling the method PreparedStatement.setBlob() to insert a blob of length between 64M and 256M, would have seen the insert take much longer than if the application used the method PreparedStatement.setBinaryStream() instead. This problem has now been fixed, and in addition, also improves the performance of using PreparedStatement.setBinaryStream(). Note that using setBlob() requires significantly less memory than using setBinaryStream(), and also, for blob values greater than 256M in size, setBlob() may actually be the only option. ================(Build #2296 - Engineering Case #585013)================ If an application executed Connection.prepareStatement(), or Connection.prepareCall(), on one connection, and the prepare request took a long time, then attempting to execute Connection.createStatement(), Connection.prepareStatement(), or Connection.prepareCall() on a different connection would have ended up blocking until the original prepare returned. This problem has now been fixed. ================(Build #2273 - Engineering Case #581029)================ The fix for Engineering case 571029 would have caused the Interactive SQL utility to give an "optional feature not implemented" error when exporting data to Excel. This problem has now been fixed. ================(Build #2273 - Engineering Case #580599)================ The SQL Anywhere JDBC driver getTimeDateFunctions() call did not return the correct names for the CURRENT_DATE, CURRENT_TIME, and CURRENT_TIMESTAMP functions. It returned "current date,current time,current timestamp" instead of "current_date,current_time,current_timestamp". The same problem also existed in the iAnywhere JDBC driver. These problems have now been fixed. ================(Build #2271 - Engineering Case #580174)================ If an application using the iAnywhere JDBC driver, created a scrollable, updateable Statement or PreparedStatement, created a ResultSet object off of the Statement or PreparedStatement object, called ResultSet.updateRow() to perform a positioned update of a row in the ResultSet, and then positioned the ResultSet to a row before the updated row, attempting to call next() to go beyond the updated row would have failed. A similar problem exists if the application positions the ResultSet beyond the updated row and then tries to call previous(). Both problems have now been fixed. ================(Build #2270 - Engineering Case #580012)================ The changes for Engineering case 576257 resulted in a substantial performance improvement within the iAnywhere JDBC driver when fetching a large number of Date, Time or Timestamp values. New changes, which build on these earlier changes, make fetching Date, Time and Timestamp values even faster, when using the iAnywhere JDBC driver. ================(Build #2267 - Engineering Case #578990)================ If an application called DatabaseMetaData.getSystemFunctions(), the string returned would have contained the functions named dbname and username. The correct function names are database and user. This problem has now been fixed. ================(Build #2261 - Engineering Case #577532)================ An application running under a Java VM in server mode, and fetching a large result set, will now retrieve the result set much faster. ================(Build #2257 - Engineering Case #576257)================ Changes have been made to the iAnywhere JDBC driver in order to improve fetch times for Date, Time and Timestamp values. Applications that are fetching a large number of Date, Time and/or timestamp values from the same ResultSet object, will now see a large improvement. ================(Build #2237 - Engineering Case #571625)================ If an application called DatabaseMetaData.getCatalogs(), DatabaseMetaData.getSchemas() or DatabaseMetaData.getTableTypes(), then the JDBC driver would have leaked a very small amount of memory. This problem has now been fixed. ================(Build #2237 - Engineering Case #571624)================ If an application executed a query that generated a warning, and that warning was attached to a Statement, PreparedStatement, CallableStatement or ResultSet object, and the object was subsequently closed without calling clearWarnings() first, then the JDBC driver would have leaked memory. This problem has now been fixed. ================(Build #2234 - Engineering Case #571029)================ If an application attempted to execute a batch with a long binary or long varchar column, and the values within the long columns were large, and the batch size was also reasonably large, then the iAnywhere JDBC driver may have given an 'out of memory' dialog, even though the Java VM still had lots of memory available. This problem has now been fixed. ================(Build #2233 - Engineering Case #570903)================ In very rare circumstances it was possible for the SQL Anywhere JDBC driver to have caused a crash in the Java VM. The Hotspot log generated for the crash would most likely have indicated that the crash occurred while attempting to construct a class cast exception. This has been fixed. ================(Build #2218 - Engineering Case #569316)================ If an application connected using the iAnywhere JDBC driver and created a very large batch, containing either long binary or long varchar parameters, then executing the batch may have given a strange out of memory error dialog after which the application would have crashed. The driver has now been modified to allow such large batches to be executed; however, any such batches that require a very large amount of contiguous memory to be allocated will be executed one row at a time, instead of being batched. In addition, whenever the driver decides to execute a batch one row at a time, a SQLWarning will be returned on the executeBatch() call indicating that the "batch was executed in single row mode due to memory limitations". ================(Build #2173 - Engineering Case #563736)================ If an ODBC DSN explicitly specified an isolation level, and that DSN was then used within the Interactive SQL utility (dbisql), then the isolation level specification would have been ignored. This problem has been fixed. ================(Build #2149 - Engineering Case #556757)================ If a JDBC application called ResultSetMetaData.getColumnTypeName() with an invalid column index, then the application may have crashed. This problem has been fixed. ================(Build #2134 - Engineering Case #554880)================ If the Server Monitor was used to monitor several servers, and one or more of those servers were down, then it was likely that the server monitor requests would have started to time out, and cause communication errors within the browser. This problem has now been fixed. ================(Build #2133 - Engineering Case #554764)================ When running on heavily loaded Unix systems, applications using a large number of connections may have crashed. This has been fixed. ================(Build #2130 - Engineering Case #554067)================ A Windows application using the iAnywhere JDBC driver, could have hung if all of the following conditions were true: 1) the application installed a message handler connections 2) the application shared a connection amongst multiple threads 3) one of the threads executed a statement that returned an asynchronous message 4) at the same time another thread used the same connection and called createStatement(), prepareStatement() or prepareCall(), before the asynchronous message was returned from the server This problem has now been fixed. ================(Build #2127 - Engineering Case #552888)================ If an application called PreparedStatement.setBlob(), and if the underlying java.sql.Blob implementation misbehaved, then there was a chance that the iAnywhere JDBC driver would have failed when the PreparedStatement was executed. Workarounds have now been implemented in the iAnywhere JDBC driver to attempt to handle the Blob implementation misbehaviour. ================(Build #2124 - Engineering Case #552314)================ If an application called the ResultSet.getBlob() method, and if fetching the blob should have thrown a valid SQLException, then quite often the exception would not have been thrown and an empty blob would have instead been returned to the client. This problem has now been fixed. ================(Build #2122 - Engineering Case #551978)================ If an application called ResultSet.getString() on a uniqueidentifier column, the iAnywhere JDBC driver would have incorrectly returned a string of binary bytes. This problem has now been fixed and the iAnywhere JDBC driver now returns a properly formatted GUID string.

SQL Anywhere - ODBC Client Library

================(Build #2994 - Engineering Case #740842)================ When using the ODBC Data Source Administrator to configure a SQL Anywhere 11 ODBC data source, the Database File “Browse” button would have returned a truncated string. Only the first 7, or 3 characters, of the file path are returned (depending on bitness). This problem has now been fixed. ================(Build #2808 - Engineering Case #707201)================ In rare low-memory situations, a client application could have crashed on startup if TCP/IP was being used. This has now been fixed. ================(Build #2738 - Engineering Case #694658)================ If a double-precision floating-point object (SQLDOUBLE) was not aligned on an 8-byte boundary on a Windows Mobile ARM-based device, the SQL Anywhere ODBC driver would have incorrectly issued the following error message when an attempt was made to reference the object (for example, using SQLGetData()): [Sybase][ODBC Driver]Invalid string or buffer length On the ARM hardware platform, a double-precision value consists of two 32-bit words and, when held in memory, the two words must appear consecutively and must both be word-aligned (i.e., a multiple of 4). The ODBC driver has now been corrected to check for an alignment that is a multiple of 4, not 8. ================(Build #2701 - Engineering Case #680039)================ A memory leak could have occurred when using the SQL Anywhere ODBC driver in such a way that the driver was repeatedly loaded and unloaded by the Microsoft ODBC Driver Manager on Windows Vista and Windows 7. This could have occurred when repeatedly creating and subsequently freeing the ODBC Environment as part of calling the SQL Anywhere ODBC driver. This problem occurs under Windows Vista and Windows 7 only as a result of a bug in Microsoft's SHELL32.DLL for these two operating systems. An Activation Context object is leaked on each load of the DLL. A workaround has been developed to avoid the problem. Another way to avoid the problem is to create and destroy the ODBC Environment only once in an application and connect/disconnect as often as desired. SQLAllocHandle( SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv ); SQLSetEnvAttr( henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0 ); loop connect/disconnect many times endloop SQLFreeHandle( SQL_HANDLE_ENV, henv ); Note, Microsoft has published http://support.microsoft.com/kb/2624911, which describes the problem with Windows Vista and Windows 7. ================(Build #2678 - Engineering Case #684608)================ ODBC/JDBC escape syntax incorrectly required uppercase keywords like IN or FROM in scalar functions like POSITION and EXTRACT. For example: select {fn extract(month from '2011-05-07')}, {fn position('b' in 'abc')} would have failed with syntax errors. If an uppercase keyword was used, the query would have succeeded: select {fn extract(month FROM '2011-05-07')}, {fn position('b' IN 'abc')} This problem has been fixed. Note: In Interactive SQL, the braces { and } must be doubled-up (i.e. {{ and }} ). ================(Build #2666 - Engineering Case #682755)================ Multithreaded client applications (e,g., ODBC, OLEDB, ADO.NET applications) could have crashed with a memory access violation, or leaked memory, when attempting simultaneous connections to a server. This problem has been fixed. ================(Build #2619 - Engineering Case #669581)================ If an application attempted to perform a wide or batched insert, and the application did not bind or set enough parameters to match the number of parameters within the prepared INSERT statement, and the wide insert or batch insert size was greater than 1, then the application would have crashed. This problem has now been fixed. ================(Build #2615 - Engineering Case #672184)================ If an application attempted to perform a wide insert using the SQL Anywhere ODBC driver, or a batched insert using the SQL Anywhere JDBC driver, then there was a very small chance the application would crash if the system was low on memory or under stress. This problem has now been fixed. ================(Build #2560 - Engineering Case #657826)================ When using the Microsoft ODBC Data Source Administrator, a crash may have resulted if an encrypted password had been specified and the "Test Connection" button was used. This has been fixed. ================(Build #2528 - Engineering Case #649644)================ The ODBC driver could not properly handle the following SQL statement because it thought it was improperly formed: create table [ab'cd] (i int ) This has now been fixed so that the driver now supports table names with embedded quotes enclosed in brackets. ================(Build #2514 - Engineering Case #645952)================ The ODBC functions SQLColumns and SQLProcedureColumns incorrectly returned a NULL value for the CHAR_OCTET_LENGTH column for XML and ST_GEOMETRY data types. ST_GEOMETRY is a new data type supported by SQL Anywhere in version 12. This has been fixed and the correct value of 2147483647 is now returned. ================(Build #2514 - Engineering Case #645948)================ The LITERAL_PREFIX and LITERAL_SUFFIX characters returned by SQLGetTypeInfo for binary data types were apostrophes. If these characters were used in an INSERT statement, the value stored was incorrect. For example: Store binary 0x1234 into column. INSERT INTO test (binary_col) VALUES ('1234'); The result is 0x31323334. If the LITERAL_PREFIX was 0x and the LITERAL_SUFFIX was NULL, then the value stored was correct. INSERT INTO test (binary_col) VALUES (0x1234); This problem has been corrected. The following types will now return 0x in the LITERAL_PREFIX column and NULL in the LITERAL_SUFFIX column: long binary varbinary binary ================(Build #2485 - Engineering Case #638900)================ If a certain statement was prepared and described that returned no result set, and then a DDL statement caused the same statement to return a result set, client statement caching could have caused the statement to be redescribed incorrectly. This was a client statement caching peformance optimization, and before this change, there was no way to disable this incorrect behavior. For example, the following statements executed in dbisql would have returned an error on the second call foo() statement: create or replace function foo() returns int begin return 1; end; call foo(); create or replace procedure foo() begin select 2; end; call foo(); This has been fixed so that if client statement caching is disabled by setting the max_client_statement_cached option to 0 for the connection, such a statement is now described correctly. ================(Build #2479 - Engineering Case #637743)================ Calls to SQLGetTypeInfo() would have returned the wrong UNSIGNED_ATTRIBUTE column value for TINYINT. The TINYINT datatype is an unsigned type so the column should have contained a 1 rather than a 0. This problem has been fixed so that the UNSIGNED_ATTRIBUTE column result now agrees with the result returned by SQLColAttribute(SQL_DESC_UNSIGNED) for a TINYINT column. ================(Build #2460 - Engineering Case #634189)================ If a connection string was made up of parameters coming from the connection string and from the data source, and the UID and PWD/ENP parameters were not all in the connection string or all in the data source, the PWD/ENP parameters would have been ignored. For example, if DSN "foo" contained a UID but no PWD, then the connection string "DSN=foo;PWD=secret" would ignore the PWD field. This has been fixed. ================(Build #2436 - Engineering Case #628843)================ If an application connected to a 64-bit Linux server subsequently used the ASE ODBC driver to query proxy tables mapped to an ASE server, and the proxy tables contained long varchar or long binary data, then the long data might have been returned with extra characters or bytes. This problem has now been fixed. ================(Build #2430 - Engineering Case #627634)================ The ODBC driver did not support setting of the SQL_ATTR_METADATA_ID attribute for connections using SQLSetConnectAttr(). This setting governs how the string arguments of catalog functions are treated. However, the driver does support this attribute at the statement level using SQLSetStmtAttr(). For SQLSetConnectAttr(), the ODBC driver returned a "driver not capable" error. This problem has been corrected. If the setting for SQL_ATTR_METADATA_ID is SQL_TRUE, the string argument of catalog functions are treated as identifiers. The case is not significant. For nondelimited strings, the driver removes any trailing spaces and the string is folded to uppercase. For delimited strings, the driver removes any leading or trailing spaces and takes literally whatever is between the delimiters. If the setting is SQL_FALSE, the string arguments of catalog functions are not treated as identifiers. The case is significant. They can either contain a string search pattern or not, depending on the argument. The default value is SQL_FALSE. The following example changes the default setting for the entire connection. rc = SQLSetConnectAttr( hdbc, SQL_ATTR_METADATA_ID, (SQLPOINTER)SQL_TRUE, SQL_IS_UINTEGER ); This setting is important for case-sensitive databases. For example, the table name "customers" does not match the table name "Customers" in a function such as SQLPrimaryKeys() unless the SQL_ATTR_METADATA_ID attribute has been set to SQL_TRUE. ================(Build #2424 - Engineering Case #625933)================ If an application that was connected to a server running on a big endian machine attempted to query data via the Remote Data Access feature with the 64-bit ASE ODBC driver, then there is a chance the server would have incorrectly reported a truncation error. This problem has now been fixed. ================(Build #2403 - Engineering Case #619613)================ The ODBC functions SQLPrimaryKeys() and SQLForeignKeys() would have returned an incorrect name for the primary key identifier (PK_NAME). It should return the PRIMARY KEY constraint name, but was returning the table name (the "default" primary key name). This problem has been fixed. ================(Build #2388 - Engineering Case #616385)================ When making continuous ODBC connections and disconnections, using the ANSI entry points to SQLConnect() and SQLDisconnect(), a memory leak would have occurred in the application. The UNICODE versions of SQLConnect() and SQLDisconnect() (i.e., SQLConnectW() ) were not affected by this problem. The process heap will continue to grow as the application loops. This problem has been fixed. See also Engineering case 608095. ================(Build #2366 - Engineering Case #611168)================ ODBC drivers support standard escape sequences in bound data as a driver-independent way to specify date and time literals, outer joins and procedure calls. The SQL Anywhere driver was failing to recognize these escape sequences when embedded in a bound parameter that contained a Unicode string. This has been fixed. ================(Build #2360 - Engineering Case #608728)================ If a connection string was made up of parameters coming from different sources (i.e. the connection string itself, DSNs or file DSNs, SQLCONNECT environment variable), and the UID and PWD/ENP parameters were not specified in the same source, the PWD/ENP would have been ignored. For example, if DSN "foo" contained a UID but no PWD, then the connection string "DSN=foo;PWD=secret" would ignore the PWD field. This has been fixed. ================(Build #2356 - Engineering Case #608095)================ When continually making ODBC connections/disconnections, using SQLConnect()/SQLDisconnect(), a memory leak would have occurred in the application. The process heap would continue to grow as the application looped. This has been fixed. ================(Build #2329 - Engineering Case #593676)================ When using the SQL Anywhere ODBC driver, the transaction isolation level can be set with a call to the ODBC function SQLSetConnectAttr(). The following is an example for setting the transaction isolation level to "readonly-statement-snapshot": SQLSetConnectAttr( dbc, SA_SQL_ATTR_TXN_ISOLATION, (SQLPOINTER)SA_SQL_TXN_READONLY_STATEMENT_SNAPSHOT, SQL_IS_INTEGER ); The following isolation level options are available. SQL_TXN_READ_UNCOMMITTED SQL_TXN_READ_COMMITTED SQL_TXN_REPEATABLE_READ SQL_TXN_SERIALIZABLE SA_SQL_TXN_SNAPSHOT SA_SQL_TXN_STATEMENT_SNAPSHOT SA_SQL_TXN_READONLY_STATEMENT_SNAPSHOT When any of the "snapshot" isolation levels were selected, the ODBC driver would have set the transaction isolation level incorrectly upon connecting to the server. The following is an example of a SET statement that was executed: SET TEMPORARY OPTION isolation_level = readonly-statement-snapshot; This would have resulted in a syntax error and the server options would not have been changed. This problem has been fixed. The ODBC driver will now generate the following correct syntax with quotes around the isolation level value. SET TEMPORARY OPTION isolation_level = 'readonly-statement-snapshot'; ================(Build #2325 - Engineering Case #592784)================ Calls to the ODBC function SQLGetTypeInfo() always returned 0 in the CASE_SENSITIVE metadata column for the XML data type. For case-sensitive databases, string comparisions of columns and variables of type XML is case sensitive. Therefore, SQLGetTypeInfo() has been fixed to returned 1 in this case. ================(Build #2308 - Engineering Case #587036)================ If a LONG VARCHAR column containing multi-byte data was fetched by the OLE DB provider, the resulting string may have contained appended null characters. As a result, the Length attribute of the string (e.g., strTxt.Length) may have been larger than expected. This problem has been fixed. ================(Build #2275 - Engineering Case #581793)================ If a SQL_NUMERIC or SQL_DECIMAL value had a precision sufficiently greater than the bound precision, then an internal buffer would have been overrun. For example, if a bound column was defined as DECIMAL(10,2), and the precision described by the input SQL_NUMERIC_STRUCT parameter value was 40, then an internal buffer would have been overrun. This problem has been fixed. ================(Build #2271 - Engineering Case #579219)================ Calling the function SQLGetInfo() function with the SQL_SQL92_STRING_FUNCTIONS information type returns a bitmask indicating which SQL 92 functions are supported by the database server. The following bits should not be returned: SQL_SSF_CONVERT SQL_SSF_SUBSTRING SQL_SSF_TRIM_BOTH SQL_SSF_TRIM_LEADING SQL_SSF_TRIM_TRAILING as SQL Anywhere does not support the above SQL 92 functions (e.g., SELECT TRIM(BOTH ' ' FROM ' abc '). Only the following following bits should be returned. SQL_SSF_LOWER SQL_SSF_UPPER This problem has been fixed. ================(Build #2266 - Engineering Case #579816)================ A new connection parameter has been added to the ODBC driver. This parameter (ESCAPE) allows you to specify the escape character used in the LIKE clause of SQL statements generated by the ODBC driver when returning a list of tables or columns. By default the ODBC driver uses the tilde character (~), but some applications do not properly query the ODBC driver to see what escape character is used, and assume that it is the backslash character (\). With this new connection parameter, users can specify the escape character in the connection string to make these applications work properly. "DSN=My Datasource;UID=xxx;PWD=xxx;ESCAPE=\;ENG=myserver" ================(Build #2253 - Engineering Case #574746)================ If an unknown connection parameter was provided to the ODBC driver, the driver would have given the error: "Parse Error: Invalid or missing keyword near '<unknown parameter>'". Some applications (for example, Crystal Reports in some cases) generate connection parameters which are unknown to SQL Anywhere, which resulted in connection failures. This has been fixed so that unknown connection parameters are now ignored. This returns the ODBC driver to the Adaptive Server Anywhere 9.x and earlier behavior. ================(Build #2253 - Engineering Case #574710)================ When the SQL Anywhere Monitor was run on Linux systems, and used to monitor a large number of resources, there is a very good possibility that the Monitor would have performed poorly. This problem only existed after applying the 11.0.1 build 2222 EBF. This problem has now been fixed. ================(Build #2252 - Engineering Case #573990)================ When calling the SADataReader.GetBytes method into a binary or varbinary column with a null buffer, it would have thrown the exception "no current row of cursor". This problem has been fixed. ================(Build #2250 - Engineering Case #573824)================ The 32-bit Unix versions of the SQL Anywhere ODBC Driver Manager (libdbodm) would have leaked a very small amount of memory for every statement handle that was allocated and subsequently freed. The memory leak problem has now been fixed. Note that the memory leak does not exist with the 64-bit Unix versions of the SQL Anywhere ODBC Driver Manager, and that the SQL Anywhere ODBC Driver Manager does not exist on Windows platforms. It should also be noted that several SQL Anywhere components on Unix platforms use the SQL Anywhere ODBC Driver Manager implicitly, and are therefore impacted by this problem. In particular, the server will use the SQL Anywhere ODBC Driver Manager for performing Remote Data Access operations; as well, the Mobilink Server uses the SQL Anywhere ODBC Driver Manager to talk to the consolidated database. Also, the iAnywhere JDBC driver uses the SQL Anywhere ODBC Driver Manager to make connections. ================(Build #2183 - Engineering Case #565110)================ When binding a column in ODBC, the column type, a buffer and a length are specified. For static types (int, long, double, time, etc) the ODBC driver ignores the length specified because the length is constant. The ODBC driver should have been treating SQL_GUID columns as static as well, but was incorrectly respecting the length specified, which sometimes resulted in truncated values. This has been fixed. ================(Build #2182 - Engineering Case #565054)================ Calling the ODBC functiom SQLColAttribute( ..., SQL_DESC_BASE_COLUMN_NAME, ... ) could have incorrectly returned the correlation name, instead of the base column name. This has been fixed so that the base column name is returned. If there is no base column, the column alias is returned. Note, this fix requires both an updated ODBC driver and server. ================(Build #2173 - Engineering Case #563848)================ If an ODBC application called SQLColAttribute() on a long varchar, long nvarchar or long binary column, with an attribute value of SQL_DESC_DISPLAY_SIZE, then the ODBC driver would have incorrectly returned the value 65535. This problem has been fixed and the driver now returns the value 2147483647. ================(Build #2152 - Engineering Case #549800)================ The SQL Anywhere ODBC driver incorrectly described a column of type NCHAR as SQL_WVARCHAR (-9), instead of SQL_WCHAR (-8), when the odbc_distinguish_char_and_varchar database option was set 'off'. In the following SQL statement, the two columns should be described as SQL_WCHAR and SQL_WVARCHAR respectively. select cast('abc' as nchar),cast('abc' as nvarchar) This problem did not affect calls to SQLColumns(), but it did affect calls to SQLDescribeCol(). This problem has been fixed. The odbc_distinguish_char_and_varchar option is intended for CHAR columns only. It is provided for backwards compatibility with older versions of the SQL Anywhere ODBC driver. For backwards compatibility, the odbc_distinguish_char_and_varchar option is set 'off' by default. When odbc_distinguish_char_and_varchar option is set 'on', the ODBC driver will describe CHAR columns as SQL_CHAR, rather than SQL_VARCHAR. ================(Build #2148 - Engineering Case #559402)================ In previous versions of SQL Anywhere, a password connection parameter was not written to a FILEDSN (.dsn file). Beginning with version 11.0.0, the password is written to the .dsn file in the format "Password={some pwd}". This behavior is not in keeping with the spirit of the ODBC specification which states, "the PWD keyword is not stored in a .dsn file". This change in behavior occurred as a result for a change to the SQL Anywhere ODBC driver to return "Password={some pwd}", instead of "PWD={some pwd}" in the connection string. Also, "Userid=user" was returned instead of "UID=user". The Microsoft driver manager only recognizes the UID and PWD forms of the connection parameters, which caused it to add the Password parameter. This problem has been corrected. The SQL Anywhere ODBC driver will now return "UID={user};PWD={some pwd}" in the connection string, as it did in earlier versions. This will result is the Driver Manager no longer including the password. ================(Build #2148 - Engineering Case #559383)================ When configuring an ODBC FileDSN on Windows, NEWPWD=* incorrectly showed up in the Advanced tab of the configuration dialog. The NEWPWD=* parameter was not actually added to the FileDSN though. This has been fixed. ================(Build #2147 - Engineering Case #551956)================ When the TargetType parameter to the ODBC function SQLGetData() is SQL_C_DEFAULT, the driver selects the default C data type based on the SQL data type of the source.   For NCHAR types, the Microsoft ODBC driver selects a SQL_C_CHAR binding. Microsoft acknowledges in its knowledgebase article http://support.microsoft.com/default.aspx/kb/293659 that to do so is an error, but states that it does this to support older legacy applications. The SQL Anywhere ODBC driver selected a SQL_C_WCHAR binding. This caused problems with applications like Microsoft Access, that expected the Microsoft ODBC behaviour. This problem in Access could have been seen when setting up a linked table using the SQL Anywhere ODC driver to a database table containing NCHAR, NVARCHAR, or LONG NVARCHAR column types. The resulting table columns were displayed with "#deleted" values. To conform to the Microsoft ODBC driver behaviour, the SQL Anywhere ODBC driver has been changed. Now, the SQL Anywhere ODBC driver selects a SQL_C_CHAR binding for NCHAR, NVARCHAR, and LONG NVARCHAR (including NTEXT) types when the "MS Applications ( Keys In SQLStatistics)" checkbox is selected in the ODBC Administrator configuration dialog for SQL Anywhere datasources. This option can also be specified as the connection parameter "KeysInSQLStatistics=YES" in a SQL Anywhere ODBC driver connection string. This change affects any ODBC function, like SQLBindCol, SQLBindParameter, and SQLGetData, where SQL_C_DEFAULT can be specified. ================(Build #2144 - Engineering Case #557955)================ Calls the function SQLGetInfo() would have incorrectly returned SQL_CB_NULL for SQL_CONCAT_NULL_BEHAVIOR. As the result of the server concatenating a string and NULL is the string, calls to SQLGetInfo() have now been corrected to return SQL_CB_NON_NULL for SQL_CONCAT_NULL_BEHAVIOR. ================(Build #2144 - Engineering Case #555236)================ SQLColumns returns a result set including COLUMN_SIZE, BUFFER_LENGTH, and CHAR_OCTET_LENGTH among other things. For a column typed NCHAR(30) or NVARCHAR(30), the COLUMN_SIZE was returned as 30 and the BUFFER_LENGTH as 30. The BUFFER_LENGTH should have been 60. For CHAR_OCTET_LENGTH, NULL is returned, whereas it should have ben 60 as well. From the ODBC standand: "COLUMN_SIZE": For character types, this is the length in characters of the data; The defined or maximum column size in characters of the column or parameter (as contained in the SQL_DESC_LENGTH descriptor field). For example, the column size of a single-byte character column defined as CHAR(10) is 10. "BUFFER_LENGTH": The defined or the maximum (for variable type) length of the column in bytes. This is the same value as the descriptor field SQL_DESC_OCTET_LENGTH. "CHAR_OCTET_LENGTH": The maximum length in bytes of a character or binary data type column. For all other data types, this column returns a NULL. These problems have been fixed. ================(Build #2143 - Engineering Case #555059)================ When using Microsoft's AppVerifier (a development/debugging tool), the tool may have reported various errors, such as the use of an invalid handle in client libraries (ODBC, dblib, etc) or in the database server. These problems have been fixed and the database server and client libraries now run cleanly under AppVerifier. Note, without the use of AppVerifier it would have been extremely rare for users to encounter these problems. ================(Build #2138 - Engineering Case #555963)================ If an NCHAR, NVARCHAR, or LONG NVARCHAR parameter was bound as SQL_C_DEFAULT, the binding would have defaulted to SQL_C_CHAR, instead of SQL_C_WCHAR. This has been corrected. ================(Build #2138 - Engineering Case #555617)================ When calling SQLForeignKeys(), the result set was not returned in the correct sort order. According to the ODBC standard, the sort orders are: 1. If the foreign keys associated with a primary key are requested, the result set is ordered by FKTABLE_CAT, FKTABLE_SCHEM, FKTABLE_NAME, and KEY_SEQ. 2. If the primary keys associated with a foreign key are requested, the result set is ordered by PKTABLE_CAT, PKTABLE_SCHEM, PKTABLE_NAME, and KEY_SEQ. This has now been corrected. ================(Build #2130 - Engineering Case #554080)================ Applications which used the EncryptedPassword connection parameter could have crashed when attempting to connect. This has been fixed.

SQL Anywhere - OLEDB Client Library

================(Build #3035 - Engineering Case #746688)================ The following improvements and bug fixes have been made to the SQL Anywhere OLE DB provider: 1. When a column cannot be fetched in its entirety, set status to DBSTATUS_S_TRUNCATED instead of DBSTATUS_S_OK and length to actual length, not amount fetched. 2. IRowsetUpdate methods InsertRow/Update should insert rows in manual commit mode (i.e., commit in batches) rather than autocommit each row. 3. Improved support for DBTYPE_DBTIMESTAMPOFFSET data types. 4. In order to identify columns that are DEFAULT AUTOINCREMENT, IColumnsInfo::GetColumnInfo now sets the DBCOLUMNFLAGS_ISROWVER bit for those columns. Microsoft defines a column with this attribute as a non-writable versioning column (such as the SQL Server TIMESTAMP) which suits SQL Server. Note, however, that SQL Anywhere supports versioning columns that are writable. 5. Corrected failure to describe money/smallmoney as DBTYPE_CY (currency type). Also corrected OLE DB schema queries DBSCHEMA_COLUMNS, DBSCHEMA_PROCEDURE_COLUMNS, and DBSCHEMA_PROCEDURE_PARAMETERS results for DBTYPE_CY. 6. Corrections to schema rowset information (DBSCHEMA_COLUMNS, DBSCHEMA_PROCEDURE_COLUMNS, and DBSCHEMA_PROCEDURE_PARAMETERS) for datetime/time precision and scale. 7. Corrections to “run-time” information for datetime/time precision and scale. 8. Add "DATETIME" to list of DBPARAMBINDINFO.pwszDataSourceType types for SetParameterInfo (SQL Server uses this undocumented type name). Type names are usually of the form “DBTYPE_xxx” (for example, “DBTYPE_I4”, “DBTYPE_STR”, “DBTYPE_DBTIMESTAMP”). 9. Adjust GetConversionSize values for TIME, DATETIME, DATETIMEOFFSET data types (only 6 fractional digits are supported by SQL Anywhere). 10. Fixed memory leak caused by failure to free rows whose refcount is 0 in Update(). 11. Fixed possible memory corruption in calls to IRowsetChange::SetData, IRowsetChange::InsertRow, ISequentialStream::Write, and IRowChange::SetColumns. 12. Fixed performance problem when DataConvert is used when no conversion is required. 13. The LoadCommand, DeleteCommand, and SaveCommand methods of the ICommandPersist interface did not qualify system tables references with an owner name. This has been corrected. 14. The OLE DB provider accepts two cbBookmark values, 1 which is the “short” DBBMK_FIRST/LAST value, and 4 or 8 depending on the bitness of the provider. The 64-bit provider flags “4” was an illegal value for cbBookmark. The 32-bit provider flags “8” was an illegal value for cbBookmark. The OLE DB provider should accept both 4 and 8 as the length of a bookmark value and fetch the appropriate 32-bit/64-bit bookmark value from memory. This problem has been corrected. The fix affects IRowsetLocate::GetRowsAt, IRowsetLocate::Compare, RowsetLocate::GetRowsByBookmark, IRowsetLocate::Hash, and IRowsetScroll::GetApproximatePosition, and IRowsetExactScroll::GetExactPosition. Both 32-bit and 64-bit providers now support 4-byte and 8-byte bookmark values, in addition to 1-byte values. ================(Build #2989 - Engineering Case #740334)================ The ICommandPersist interface methodes, LoadCommand, DeleteCommand, and SaveCommand, did not qualify system tables references with an owner name. This has been corrected. ================(Build #2945 - Engineering Case #732743)================ Original description for Engineering case 706876: A Microsoft Data Link Error could have occurred with newer versions of Microsoft software when using the SQL Anywhere OLE DB provider. When the Test Connection button was clicked, the following message would have been displayed when the error occurred: Test connection failed because not all properties can be set. Window Handle (BAD VALUE) Continue with test connection? [Yes] [No] The message was informational only and Yes can be clicked. If the credentials and other connection information were correct, the connection succeeded. This problem has been fixed. Instead of returning a NULL window handle to the Microsoft software, the OLE DB Window Handle property is now marked as unsupported, which removes the warning message. === The solution to this problem was incorrect. Some applications require support for the Window Handle property and terminate if not supported (e.g., ROWSETVIEWER application). The problem has been corrected. The Window Handle property value was improperly described as 32-bit in a 64-bit application. ================(Build #2881 - Engineering Case #720592)================ If the values 'SYSTEM TABLE', ‘SYSTEM VIEW’ or 'GLOBAL TEMPORARY' were specified as the TABLE_TYPE restriction for either of the SQL Anywhere OLE DB DBSCHEMA_TABLES or DBSCHEMA_TABLES_INFO rowsets, an empty rowset was returned. If ‘TABLE’, ‘VIEW’, or ‘TEXT’ was specified as the TABLE_TYPE restriction, there was no problem. This problem has been corrected. To correct the problem in an existing database, the Upgrade utility must be used once the problem resolution fix (EBF) has been installed. ================(Build #2806 - Engineering Case #706876)================ A Microsoft Data Link Error could have occurred with newer versions of Microsoft software when using the SQL Anywhere OLE DB provider. When the Test Connection button was clicked, the following message would have been displayed when the error occurred: Test connection failed because not all properties can be set. Window Handle (BAD VALUE) Continue with test connection? [Yes] [No] The message was informational only and Yes can be clicked. If the credentials and other connection information were correct, the connection succeeded. This problem has been fixed. Instead of returning a NULL window handle to the Microsoft software, the OLE DB Window Handle property is now marked as unsupported, which removes the warning message. ================(Build #2664 - Engineering Case #683425)================ Additional changes were required for Engineering case 681396, where the server may not start on HP-UX machines if there were many network interfaces. The description for case 681396 mentioned Unix systems, but this problem was actually limited to HP-UX only. A border case, as well as IPv6, were corrected as well. ================(Build #2662 - Engineering Case #683161)================ A multithreaded application using the SQL Anywhere oledb driver could have crashed with an access violation when a rowset was released. This problem was introduced by the changes for Engineering case 662986, and has now been fixed. ================(Build #2662 - Engineering Case #681419)================ Multi-threaded OLEDB applications could have experienced an access violation when a rowset was released. This problem was introduced by the changes made for Engineering case 662896 and has now been fixed. ================(Build #2579 - Engineering Case #662896)================ When using the OLEDB provider, if a statement was prepared, executed, and then the ADO MoveFirst() (OLE DB RestartPosition() ) method was called when the cursor type was forward-only, the statement would have become unprepared. Subsequent attempts to execute the prepared statement would then have failed. This problem has been corrected. ================(Build #2563 - Engineering Case #658887)================ The OLE DB DBSCHEMA_FOREIGN_KEYS rowset returned the following indicated integer values for the UPDATE_RULE or DELETE_RULE referential actions. CASCADE 0 if referential action is NULL 1 SET NULL 2 SET DEFAULT and RESTRICT 3 These values, derived from the ODBC SQLForeignKeys result set, did not match the following OLEDB constants defined for these referential actions. DBUPDELRULE_NOACTION = 0x0 DBUPDELRULE_CASCADE = 0x1 DBUPDELRULE_SETNULL = 0x2 DBUPDELRULE_SETDEFAULT = 0x3 Furthermore, the DBSCHEMA_FOREIGN_KEYS rowset should have returned strings rather than integers for the UPDATE_RULE or DELETE_RULE referential actions. The OLE DB specification states: If a rule was specified, the UPDATE_RULE or DELETE_RULE value is one of the following: "CASCADE" — A <referential action> of CASCADE was specified. "SET NULL" — A <referential action> of SET NULL was specified. "SET DEFAULT" — A <referential action> of SET DEFAULT was specified. "NO ACTION" — A <referential action> of NO ACTION was specified. Providers should return NULL only if they cannot determine the UPDATE_RULE or DELETE_RULE. In most cases, this implies a default of NO ACTION. Also, the fix for Engineering case 620136 did not handle the situation when there was no declared Primary Key in the primary table but there were table or column (not nullable) Unique Constraints that permitted the addition of foreign keys. These problems have been fixed. The Upgrade utility should be used to update the OLE DB schema rowset support in any database used with ADO, ADOX or OLE DB. ================(Build #2539 - Engineering Case #651383)================ As of the changes for Engineering case 633120, a SQL query producing multiple result sets was not handled correctly by the SQL Anywhere OLE DB provider. This problem has now been corrected. The cursor is no longer closed after the first result set is processed. ================(Build #2514 - Engineering Case #645953)================ The DBSCHEMA_PROVIDER_TYPES rowset schema incorrectly returned 0x in the LITERAL_PREFIX column for varbit types. The apostrophe character (') is now returned in the LITERAL_PREFIX and LITERAL_SUFFIX columns instead. ================(Build #2500 - Engineering Case #642865)================ The SQL Anywhere OLE DB provider was ignoring the Location and Initial Catalog connection parameters. This problem has been fixed. "Location" can now be used to specify the host name and port of the database server. The form is hostname:port (e.g., username-pc:3628). "Location" is mapped to the SQL Anywhere "Host" connection parameter for version 12 or later and the "CommLinks" connection parameter for version 11 or earlier. "Initial Catalog" can now be used to specify the database to connect to when more than one database has been started by a SQL Anywhere database server. "Initial Catalog" is mapped to the SQL Anywhere "DatabaseName" (DBN) connection parameter. ================(Build #2499 - Engineering Case #642980)================ A number of corrections and improvements have been made to the SQL Anywhere OLE DB schema rowset support procedures: - If a catalog name is specified as one of the schema restrictions, the procedure will make sure it matches the current catalog. If it does not, a single row will be returned with NULLs. - Any rowset that can return a catalog name in a column will now return the current database name in that column instead of NULL. - The rows returned in the DBSCHEMA_PROVIDER_TYPES rowset have been slightly reordered for better results with Microsoft tools. This was done since Microsoft tools ignore the BEST_MATCH column and use the first row that matches the datatype it is searching for. - In the DBSCHEMA_PROVIDER_TYPES schema, the XML datatype will now set the DATA_TYPE column to 141 (DBTYPE_XML), the IS_LONG column to 1 and return 2GB instead of 32767 for COLUMN_SIZE. - In the DBSCHEMA_PROVIDER_TYPES schema, the TIMESTAMP WITH TIME ZONE datatype will now set the DATA_TYPE column to 146 (DBTYPE_DBTIMESTAMPOFFSET). This is supported in version 12 or later of SQL Anywhere. - An entry for the REAL datatype was missing from the DBSCHEMA_PROVIDER_TYPES rowset. This row has been added. To install these updates into a database, the Upgrade utility (dbupgrad), or the ALTER DATABASE UPGRADE statement can be used. ================(Build #2494 - Engineering Case #641092)================ The changes for Engineering case 633120, introduced a problem with returning a character string column value when the length of the column value was not bound by the consumer (i.e., the consumer does not provide a pointer to a length field). In this special case, the returned string value should be null-terminated. This has been fixed. ================(Build #2490 - Engineering Case #639712)================ The OLE DB provider's TABLES, TABLES_INFO, and VIEWS schema rowset support procedures do not identify MATERIALIZED VIEWs and TEXT CONFIGURATION objects correctly. Materialized views are now reported as "VIEWS", and text configuration objects are now identified as "TEXT", in the TABLE_TYPE column. Also, the OLE DB provider's TABLES schema rowset included an unnecessary and undocumented column "PREFIXSYSOWNED". This column has been removed from the rowset to match similar behavior of the stored procedure than produces theTABLES_INFO schema rowset. The OLE DB provider's TABLE_CONSTRAINTS schema rowset support procedure fails with the error "Column 'check' not found". This has been fixed. The Upgrade utility (dbupgrad) should be used to update the OLE DB schema rowset support in any database used with ADO, ADOX or OLE DB. ================(Build #2484 - Engineering Case #638848)================ A few improvements have been made to ADOX/OLEDB table creation. Long types are now mapped to SQL Anywhere long types. For example, an adLongVarChar column is now mapped to "LONG VARCHAR" instead of "CHAR(0)". Wide types are now mapped to SQL Anywhere nchar types instead of char types. For example, adWChar is now mapped to "NCHAR" and adLongVarWChar is now mapped to "LONG NVARCHAR". An adSingle column with no specifed precision will now default to REAL rather than FLOAT(0), which generated a syntax error. An adDecimal column with no specified precision and scale will now default to DECIMAL rather than DECIMAL(0,0), which generated a syntax error. An adNumeric column with no specified precision and scale will now default to NUMERIC rather than NUMERIC(0,0), which generated a syntax error. An adLongVarBinary column will map to the IMAGE type rather than BINARY(0), which generated a syntax error. An adCurrency column is now supported and will map to a column of type MONEY. An adDate column is now supported and will map to a column of type DATETIME. If a table or column name is not defined, OLEDB will no longer fault with a NULL pointer reference. Instead, the name "undefined" will be used. The following code fragment is a VBScript example for creating a table using ADOX statements. Set db = CreateObject( "ADOX.Catalog" ) Set ntable = CreateObject( "ADOX.Table" ) ntable.Name = "testTable" ntable.Columns.Append "Col_1", adNumeric ntable.Columns.Append "Col_2", adDate ntable.Columns.Append "Col_3", adChar, 32 ntable.Columns.Append "Col_4", adVarChar, 32767 ntable.Columns.Append "Col_5", adLongVarChar ntable.Columns.Append "Col_6", adLongVarWChar db.Tables.Append ntable ================(Build #2464 - Engineering Case #634664)================ The Microsoft SQL Server Reporting Services 2008 application uses the Linked Server mechanism to communicate via OLE DB to a SQL Anywhere server. It can send EXEC statements of the following form to the SQL Anywhere OLE DB provider: EXEC owner.procedure_name :parm1, :parm2, ... where :parm1, etc. are bound parameters. The SQL Anywhere OLE DB provider has been improved to now handle this syntax. ================(Build #2455 - Engineering Case #633120)================ Microsoft's SQL Server 2005/2008 Replication software allocates a 0x200 byte buffer for the TYPE_NAME column of the DBSCHEMA_PROVIDER_TYPES rowset. It then creates a DBBINDING structure identifying the length of the buffer as 0x300 bytes. When the SQL Anywhere OLE DB provider initializes the buffer with nulls, a stack overrun occurs and Microsoft's Replication software faults. As a work-around for Microsoft's bug, the SQL Anywhere OLE DB provider will no longer initialize the consumer's buffer with nulls. ================(Build #2454 - Engineering Case #633125)================ Improvements to the DBSCHEMA_PROVIDER_TYPES rowset have been made to make it more consistent with Microsoft SQL Server. ================(Build #2445 - Engineering Case #631330)================ Some inconsistencies between SQL Anywhere OLE DB column metadata information and run-time column information caused problems with accessing tables via the Microsoft SQL Server "Linked Server" mechanism. These problems affected NCHAR, NVARCHAR,LONG NVARCHAR, VARBIT, LONG VARBIT, and TIMESTAMP WITH TIME ZONE columns. The TIMESTAMP WITH TIMEZONE data type is new to version 12.0.0. These problems have been fixed. Table rows inserted using the OLE DB OpenRowset/InsertRows methods are now done with autocommit turned off. Once the inserts are completed, the rows are committed. For the complete fix to this problem, use the Upgrade utility (dbupgrad) to upgrade existing databases with fixes for the OLE DB schema rowset support (metadata support). ================(Build #2439 - Engineering Case #629606)================ When using SQL Server Integration Services (SSIS), an attempt to migrate tables between SQL Anywhere/Sybase IQ and SQL Server databases would have failed. This problem has been corrected. Note, if the Data Flow consists of more than 10 tables that are to be migrated to SQL Server from a SQL Anywhere server, the Personal server should not be used since each table is moved asynchronously on a separate connection (i.e., more than 10 simultaneous connections will be made to the SQL Anywhere server and the number of simultaneous connections is limited with the Personal server). ================(Build #2438 - Engineering Case #627407)================ .NET applications using the SQL Anywhere OLE DB provider may have failed with the following error for OleDbDataReader.Close(): "Reader Exception: Attempted to read or write protected memory. This is often an indication that other memory is corrupt." This has been fixed. ================(Build #2438 - Engineering Case #627266)================ An "Out of Memory" assertion may have been raised by the SQL Anywhere OLE DB provider, which may have been indicative of heap corruption. This problem may arise when binding parameters that are described as DBTYPE_IUNKNOWN (a type used for LONG VARCHAR parameters). This problem has been fixed. ================(Build #2402 - Engineering Case #620289)================ If the length for a data column was described as SQL_NTS (-3), the SQL Anywhere OLE DB provider would not have computed the correct length for the column on 64-bit platforms. This problem has been fixed. Note, this problem was seen with SQL Server Integration Services applications on 64-bit Windows platforms, it does not appear in ADO applications. ================(Build #2402 - Engineering Case #620287)================ The SQL Anywhere OLE DB provider would have leaked memory if the InsertRow method was called with no row handle return pointer. For example,         HRESULT hr = rowset::InsertRow( hChapter, hAccessor, pData, NULL ); would have resulted in a memory leak, since phRow (the 4th argument) is NULL. This problem may have occurred when using the provider with SQL Server Integration Services (SSIS). This problem has been fixed. ================(Build #2401 - Engineering Case #620136)================ The SQL Anywhere OLEDB provider's result sets for PRIMARY_KEYS and FOREIGN_KEYS did not show the correct constraint name (PK_NAME column). Instead, they listed the table name. This problem has now been corrected. ================(Build #2387 - Engineering Case #617397)================ By default, the OLE DB provider indicates, through a property settting, that it does not support returning multiple result sets, although the provider is capable of doing so. An undocumented connection option "ASA Multiple Results=TRUE" will enable the returning of multiple result sets. The provider has been changed so that returning of multiple results sets is now supported by default. More specifically, DBPROP_MULTIPLERESULTS is now set to DBPROPVAL_MR_SUPPORTED by default. If desired, the connection option "ASA Multiple Results=FALSE" can be used to change the property value to DBPROPVAL_MR_NOTSUPPORTED. However, there is no known benefit to using this option. ================(Build #2365 - Engineering Case #611017)================ When the OLE DB provider's GetNextRows method was called, the next row would not have been read if the previous row had NULL column values. This problem was introduced by the changes for Engineering case 605058, and has now been fixed. ================(Build #2350 - Engineering Case #606642)================ If a division by zero error occurred in a result set, the SQL Anywhere OLE DB provider would have returned DB_S_ENDOFROWSET instead of 0x800a000b (divide by zero). For example, the following SELECT statement will result in a division by zero error if the column value for "num" is 3: SELECT num/(num-3) FROM divisionby0 This problem has been fixed. ADO will now set the correct error number (11) and description (Division by zero) from the error code returned by OLE DB. ================(Build #2347 - Engineering Case #606229)================ When using the SQL Anywhere OLE DB provider, a memory leak cpuld have occurred when fetching data LONG VARCHAR or long VARBINARY columns. This problem has been fixed. ================(Build #2344 - Engineering Case #605803)================ When uploading data into a SQL Anywhere database from Microsoft SQL Server using the Linked Server mechanism, SQL Server could have reported that it had received inconsistent metadata information and failed the upload. This was due to the SQL Anywhere OLE DB provider returning inconsistent column lengths for VARCHAR and NVARCHAR columns when using the UTF8 character set collation. For example, an NVARCHAR(100) column length would have been reported as 400, which is the octet length for this column using the UTF8 collation, but the "ulColumnSize" field of the DBCOLUMNINFO structure should contain the maximum length in characters for DBTYPE_STR and DBTYPE_WSTR columns, not the maximum length in bytes. This problem has been corrected. ================(Build #2344 - Engineering Case #605058)================ If a client-side cursor UPDATE was performed using the SQL Anywhere OLE DB provider, and the column was of type VARCHAR(n), where n was greater than or equal to 256 and the column value was originally NULL, then an error message similar to the following would have been issued by ADO: Row cannot be located for updating. Some values may have been changed since it was last read. The OLE DB provider was failing to return DBSTATUS_S_ISNULL for the column value and returned an empty string instead. This caused ADO to generate an UPDATE statement with a WHERE clause expression of the form "column = ?" and a bound value of '' (a zero-length string). This problem has been fixed. ADO will now generate an UPDATE statement with a WHERE clause expression of the form "column IS NULL". A workaround is to use a server-side cursor. ================(Build #2316 - Engineering Case #590210)================ The SQL Anywhere OLE DB provider implementation of IMultipleResults::GetResult() returned an incorrect 'rows affected' count for inserts, updates, and deletes. In this situation, the result returned by OleDbCommand.ExecuteNonQuery(), which called the GetResult() method, was -1. This problem has now been fixed to return the correct 'rows affected' count. ================(Build #2266 - Engineering Case #575490)================ Wide-fetching a query that referenced a proxy table could have returned the last row multiple times, instead of returning no rows and the SQLE_NOTFOUND warning. This has been fixed. ================(Build #2254 - Engineering Case #574697)================ If a NUMERIC INOUT parameter was bound as SQL_PARAM_INPUT_OUTPUT, the result that was returned to the caller was always 0. For example: CREATE PROCEDURE _TEST_PROC ( @IN_VAL1 NUMERIC(7, 0), @IN_VAL2 NUMERIC(7, 0), @OUT_VAL NUMERIC(7, 0) OUTPUT ) AS BEGIN SET @OUT_VAL = @IN_VAL1 + @IN_VAL2 END If the statement "CALL PROCEDURE _TEST_PROC( 100, 200, ? )" was prepared, and the third parameter was bound as SQL_PARAM_INPUT_OUTPUT, the result after execution was 0. It should have been 300. If the parameter was bound as SQL_PARAM_OUTPUT, the result returned was correct.This problem has been fixed. Note that in the above Transact SQL procedure, OUT_VAL is an INOUT parameter, since Transact SQL parameters are always INPUT and the addition of the OUTPUT clause makes them INOUT. ================(Build #2175 - Engineering Case #564435)================ In an ADO/OLE DB application, when a UNIQUEIDENTIFIER (or GUID) was used as a parameter in a query, an error message like "Cannot convert 0x to a uniqueidentifier" may have resulted, or the query may simply have failed to return any results. This problem has been fixed. Sample schema: create table uuidtable( pkey int, uuid uniqueidentifier, stringform uniqueidentifierstr ); Sample query: select * from uuidtable where uuid = ? The following .NET/OLE DB example shows typical uniqueidentifier parameter binding: OleDbCommand cmd = new OleDbCommand(txtSQLStatement.Text.Trim(), _conn); OleDbParameter param1 = new OleDbParameter(); param1.ParameterName = "@p1"; param1.DbType = System.Data.DbType.Guid; cmd.Parameters.Add(param1); cmd.Parameters[0].Value = new Guid("41dfe9f9-db91-11d2-8c43-006008d26a6f"); ================(Build #2133 - Engineering Case #554998)================ When ADO asks for the schema information related to a query (e.g., SELECT * FROM Products), it requests a number of attributes like "IDNAME", "TABLENAME", etc. The SQL Anywhere OLE DB provider returns a DBID for schema rowset columns that matches Microsoft's declared DBID. For example, the schema column DBCOLUMN_IDNAME is defined in Microsoft's OLEDB.H header file as follows: extern const OLEDBDECLSPEC DBID DBCOLUMN_IDNAME = {DBCIDGUID, DBKIND_GUID_PROPID, (LPOLESTR)2}; This is what the OLE DB provider would return as the DBID for the "IDNAME" column. This strategy works for many ADO methods that request schema information. However, the following example illustrates a problem with the ADO RecordSet Save() method. Dim strConnection = "PROVIDER=SAOLEDB;ServerName=demo;DatabaseName=demo;USERID=DBA;PASSWORD=sql" Dim strSQLStatement = "SELECT ID, Name FROM Products" Dim strXMLLocation = "c:\\temp\\products.xml" Dim objADOConnection As New ADODB.Connection Dim objADORecordSet As New ADODB.Recordset objADOConnection.Open(strConnection) objADORecordSet.Open(strSQLStatement, objADOConnection, ADODB.CursorTypeEnum.adOpenStatic, ADODB.LockTypeEnum.adLockOptimistic) If Not (objADORecordSet.EOF And objADORecordSet.BOF) Then objADORecordSet.MoveFirst() objADORecordSet.Save(strXMLLocation, ADODB.PersistFormatEnum.adPersistXML) End If For reasons unknown, the ADO RecordSet Save() method returns the error "catastrophic failure". The SQL Anywhere OLE DB provider has been changed to return only the "property ID" part of the DBID. This is equivalent to returning the following structure. extern const OLEDBDECLSPEC DBID DBCOLUMN_IDNAME = {NULL, DBKIND_PROPID, (LPOLESTR)2}; This permits the ADO RecordSet Save() method to complete successfully.

SQL Anywhere - Other

================(Build #3052 - Engineering Case #748538)================ Specifying the command line option -nogui after the option -silent when running the UNIX setup script would have caused the -silent flag to be ignored. This has been fixed. The -nogui option now has no effect if -silent is specified at any point. A workaround is to avoid specifying -nogui when doing a silent install. ================(Build #3052 - Engineering Case #748535)================ The Linux GTK and Mac OS X UI installer improperly reported insufficient disk space if there was more than 2 TB of available disk space. This has been fixed. A workaround is to use setup -nogui to avoid the use of the graphical installer. Alternatively, install to a smaller disk drive. ================(Build #2952 - Engineering Case #733922)================ When run on Unix systems, the uninstaller always returned an error code of 1. This has been fixed. ================(Build #2867 - Engineering Case #716908)================ Attempting to upgrade a database initialized with software prior to version 10, to version 10 or higher, on a computer running Linux that uses a 3.x kernel may have failed. This was most likely on systems with more than 4 GB of RAM, or with 32-bit software. This has now been fixed. ================(Build #2860 - Engineering Case #566705)================ In the PHP external environment, calling phpinfo() would have showed no useful information for the sqlanywhere_extenv module. This has been fixed. Now, server version information, as well as the names of the server, database, and user are displayed. ================(Build #2837 - Engineering Case #713568)================ Mini-dump files generated by SQL Anywhere software on Linux system could have been unusable. This problem was most likely to occur if the process being dumped was using a large number of threads (> 480). This has now been fixed. ================(Build #2776 - Engineering Case #701922)================ Use of some of the HTTP samples verbatim in a production system could have caused exposure to Cross Site Scripting (XSS) issues. This has been fixed. Note that it is highly recommended that application developers and DBAs always review their web application code for possible security vulnerabilities before they are put into production. The Open Web Application Security Project (https://www.owasp.org) contains more information on how to secure your web application. ================(Build #2738 - Engineering Case #695079)================ When connected via jConnect, the procedure used to query the primary key metadata of a table would have returned too many rows if the table had a primary key column that was also a foreign key reference to another table. This problem has now been fixed. Note, an ALTER DATABASE UPGRADE will need to be performed on existing databases in order to get the new jConnect metadata procedures. ================(Build #2737 - Engineering Case #695772)================ When creating a custom MSI install using the deployment wizard, two properties were not being set correctly: UpgradeCode and ProductVersion. This has been fixed so that they are now set correctly. ================(Build #2722 - Engineering Case #689954)================ An ODBC application could have crashed when attempting to connect if a thread was unable to be started. This has been fixed. ================(Build #2701 - Engineering Case #687835)================ If an MSI install was built using the Deployment wizard, and Sybase Central was selected but Interactive SQL was deselected, the subsequent install of Sybase Central would have failed on exit. The error: Interactive SQL could not be launched. Please change the plug-in properties and add the isql.jar file to its path. was due to Sybase Central expecting ISQL.jar to be installed. This has been corrected by adding a dependency on ISQL.jar when an install of Sybace Central is created. ================(Build #2696 - Engineering Case #686304)================ When SQL Anywhere components were running in the isolated session 0 (ie, the services session) of Vista and later Windows operating systems, but were not actually running as services, the components could have attempted to display GUI elements. Due to session 0 isolation, these GUI elements were not accessible to users. To execute as a non-service within session 0, the program was likely to have been launched as a child of a service. On Vista and later versions of Windows, SQL Anywhere components now suppress GUI components when running in session 0 rather than just when running as a service. ================(Build #2687 - Engineering Case #685289)================ When performing an archive backup via an external backup provider, the database server provided incorrect min_iosize & max_iosize parameters to the provider when calling the syb_defineapi() function. Generally, the min_iosize was set to what is actually the server's maximum IO size and max_iosize was set to 512K. Usually, the min_iosize was larger than the max_iosize. This problem has been fixed by setting the min_iosize to 2K and the max_iosize to the server's actual max buffer size. ================(Build #2604 - Engineering Case #669435)================ On Unix systems, when using the Service utility (dbsvc) to create a service for the MobiLink client (dbmlsync), the following error would have been reported: svc_t_dbmlsync: No such file or directory This was due to the file svc_t_dbmlsync not having been installed in the bin32/dbsvc_scripts directory. This has been corrected. ================(Build #2596 - Engineering Case #667902)================ SQL Anywhere EBF installs would have failed to update the SQL Anywhere Monitor (Developer) database (samonitor.db) if the SQL Anywhere Monitor had been used after the EBF build date. This has now been fixed. ================(Build #2585 - Engineering Case #665004)================ When trying to connect using the Ruby DBI interface, the driver did not raise an error if the username/password was invalid. Instead it silently failed. This has been fixed. ================(Build #2563 - Engineering Case #659357)================ Running the Deployment wizard when SQL Anywhere had been installed to directory with a path containing multi-byte characters would have caused the generation of the MSI to fail with an error like: "C:\Sy签署\SQL Anywhere 12\bin32\dblib12.dll (Not Found)". This has been fixed. ================(Build #2560 - Engineering Case #657748)================ When using the Microsoft ODBC Data Source Administrator, an attempt to create a DSN that used a FIPS Certificate may have resulted in a crash. The has been fixed. ================(Build #2553 - Engineering Case #656162)================ When building a CAB file to deploy SQL Anywhere for Windows Mobile, a start menu folder "sqlany12" would have been created, the folder name should have been "sqlany11". This has been corrected. ================(Build #2522 - Engineering Case #647854)================ When running the fetchtst tool for testing the performance of queries (in samples-dir\SQLAnywhere\PerformanceFetch) on a SQL statement larger than 10K, fetchtst may have crashed. This has now been fixed. ================(Build #2518 - Engineering Case #647005)================ The CE Deployment Wizard Installer would have throw an exception when clicking the 'Deploy to Mobile Device Now' button on a system which did not have ActiveSync installed. This has been fixed so that the following error is now issued: Error: Microsoft Activesync is not installed. CEAppMgr.exe is not detected. .CAB file will not be deployed. ================(Build #2501 - Engineering Case #642996)================ If a database encrypted with AES_FIPS or AES256_FIPS was copied to a CE device, the server would have been unable to start it. This has been fixed. ================(Build #2495 - Engineering Case #640776)================ When running an MSI install that was generated by the Deployment wizard, the ulodbc11.dll was not self registered. This has now been fixed. ================(Build #2494 - Engineering Case #640110)================ When executing a remote procedure call to an ASE server, if the procedure involved output parameters, then there was a chance the call would have failed with the remote error "output parameters will only be returned from this stored procedure when you use only parameter markers to pass parameter values". This problem has now been fixed and the remote call should now execute correctly. ================(Build #2490 - Engineering Case #640109)================ The deployment wizard was failing when attempting to register one of our v4.0 .Net assemblies on systems where version 4.0 of the .NET framework was not installed. This has been fixed. ================(Build #2490 - Engineering Case #633118)================ The Deployment Wizard did not deploy V3.5 and V4.0 .Net assemblies. They have now been added to the list of files we deploy. ================(Build #2483 - Engineering Case #638738)================ Windows CE applications, including SA utilities, requiring aygshell.dll to be present on the device or they would not have loaded. This worked fine on Windows Mobile 5 and later devices, but not for non-Windows Mobile CE 5.0 and 6.0 devices. This has been corrected by trying to dynamically load aygshell.dll if it is present, and skip these functions otherwise. For non-Windows Mobile CE devices, buttons are displayed on the main window for shutdown/hide/etc, instead of relying on creating menus accessible via softkeys since this would require aygshell.dll. ================(Build #2451 - Engineering Case #627649)================ The PHP driver would have crashed when trying to open multiple result sets using SASQL_USE_RESULT or sasql_real_query() and sasql_use_result(). This has been fixed. ================(Build #2445 - Engineering Case #630338)================ If the option row_counts was set to 'On', the system procedures sa_performance_statistics and sa_performance_diagnostics did not return a result set, and the procedure sa_describe_query caused an assertion failed 109512 error. These problems have been fixed. ================(Build #2424 - Engineering Case #625465)================ When deploying SQL Anywhere using the Deployment wizard, the PHP Extenv DLLs: (php-<PHP version>_sqlanywhere_extenv11.dll) and PHP SQL Anywhere DLLs (php-<PHP_version>_sqlanywhere.dll) were included, but not the file dbcapi.dll. This has been corrected so that dbcapi.dll is now deployed as well. ================(Build #2418 - Engineering Case #619195)================ Generating an MSI install using the Deployment Wizard, should have included these files: IANYWHERE.MOBILINK.CLIENT.DLL IANYWHERE.DATA.SQLANYWHERE.DLL but they were not included in the assembly/v2 directory. These files were being deployed directly into the GAC, but were not being put into the assembly/v2 directory. This has been corrected, and they are now installed into both locations. ================(Build #2399 - Engineering Case #614818)================ When deploying support for dbunload to a windows CE device, the following scripts were missing: unloadold.sql, optdeflt.sql and opttemp.sql. These are now deployed to the device. ================(Build #2395 - Engineering Case #616656)================ When using the SQL Anywhere PHP module, and binding a null numeric value to a statement with sasql_stmt_bind_param_ex, the null value would have been converted to a 0. This resulted in a 0 being passed in the statement instead of the desired null value. Resetting the variable to null after binding would have given the desired behavior. This has now been fixed. ================(Build #2391 - Engineering Case #618014)================ The TableViewer ADO.Net sample application queries SYSTABLE to determine the table list to display. That query would have incorrectly returned text index tables, if defined, which cannot be directly manipulated. If a query was subsequently issued using a text index table, the error SQLE_TEXT_CANNOT_USE_TEXT_INDEX would have occurred. The query has now been rewritten to only display base tables. Additional changes to the application were also made to improve usability. First, functionality that required an active database connection such as the Execute button are disabled if there is no active connection. Second, a simple SELECT statement is generated based on the table selected from the table list control. ================(Build #2379 - Engineering Case #616031)================ On Unix systems other than Linux, JAR files were installed with 0700 permissions, which meant that they were only usable by the user who ran the install. This has been fixed so that executables, shared objects, and shell scripts are now installed with 0555 permissions, while the permissions of all other files will be 0444. As a workaround, the following command may be run to fix the permissions of the JAR files: find $SQLANY11 -name "*.jar" -exec chmod 444 {} \; ================(Build #2373 - Engineering Case #610982)================ When installing SQL Anywhere on a Windows system that used a multibyte character set as the ANSI code page, the SQL Anywhere performance monitor counters may not have been registered correctly and no error message would have been displayed. At startup, the server would have displayed the message "Unable to initialize NT performance monitor data area; server startup continuing". This problem has now been fixed. ================(Build #2362 - Engineering Case #607874)================ The SQL Anywhere C API version of DBD::SQLAnywhere perl driver did not fetch floating point/double values correctly (incorrect values would have been returned). This problem has been fixed. ================(Build #2350 - Engineering Case #596034)================ Attempting to run a silent install using an MSI file created by the Deployment wizard, could have failed with the error: Error 2769: Custom Action CAD_writeStrings did not close 3 MSIHANDLEs. This has been corrected by no longer using MSIHANDLEs in custom actions, but rather using PMSIHANDLE variables, which are automatically freed when they go out of scope. ================(Build #2346 - Engineering Case #606014)================ When the script sqlanydb.py was run, it would not have propagated some fetch-related errors to the application. This has been fixed. Support has been added for Connection and Cursor .messages and .errorhandler attributes as outlined in PEP 249. Support has been added for SPARC 64 (and other platforms where sizeof(c_void_p) != sizeof(c_int)). ================(Build #2343 - Engineering Case #605386)================ When any of the Java based administration tools (Interactve SQL, Sybase Central, Mobilink Monitor, DBConsole) were launched on Mac OS X systems, two copies of the admin tool icons were being displayed on the Dock. This has been fixed. ================(Build #2343 - Engineering Case #605385)================ When installing 11.0.1 on Mac OS X 10.6 (Snow Leopard), the registration key panel had problems displaying the key as entered. Sometimes, nothing would have been displayed, other times mangled characters would have been displayed. This has been fixed. ================(Build #2309 - Engineering Case #587699)================ If the DBTools function DBSynchronizeLog() was called when no callback routines (errorrtn, msgrtn, warningrtn, logrtn, progress_msg_rtn, progress_index_rtn, msgqueuertn, confirmrtn) were defined, it would have crashed. This problem has been fixed. It is no longer necessary to define all callback routines. A workaround is to define each of the callback routines. Example: a_sync_db sync; . . . sync.confirmrtn = (MSG_CALLBACK) ConfirmCallback; ================(Build #2293 - Engineering Case #584722)================ When installing EBFs on Unix systems, the installer would not have applied the updates if the destination directory included spaces. This has been fixed. ================(Build #2275 - Engineering Case #577512)================ Sybase Central plugins for Ultralite & QAnywhere were not being registered when deployed by the Deployment wizard. This has now been corrected. ================(Build #2267 - Engineering Case #580590)================ The SQL Anywhere Python Database interface now supports the ability to register callbacks to control how database types are mapped into Python objects when results are fetched from the database server. Callbacks are registered using the new module-level "register_converter" method. This method should be called with the database type as the first parameter, and the conversion function as the second parameter. For example, to request that sqlanydb.py create Decimal objects for data in any column described as having type DT_DECIMAL: import sqlanydb import decimal def convert_to_decimal(num): return decimal.Decimal(num) sqlanydb.register_converter(sqlanydb.DT_DECIMAL, convert_to_decimal) Converters may be registered for the following database types: DT_DATE DT_TIME DT_TIMESTAMP DT_VARCHAR DT_FIXCHAR DT_LONGVARCHAR DT_STRING DT_DOUBLE DT_FLOAT DT_DECIMAL DT_INT DT_SMALLINT DT_BINARY DT_LONGBINARY DT_TINYINT DT_BIGINT DT_UNSINT DT_UNSSMALLINT DT_UNSBIGINT DT_BIT DT_LONGNVARCHAR ================(Build #2267 - Engineering Case #579233)================ When using the SQL Anywhere Python database interface (sqlanydb.py) the Cursor.rowcount attribute value was inaccurate under when calling executemany. The rowcount attribute was set to the number of rows affected/returned by the last execute in the series. This has been fixed. The rowcount attribute will now contain the sum of the row counts of the executes (or -1 if unknown). Also, when the server returned an estimated, rather than an exact row count, Cursor.rowcount was set to a negative number, the absolute value of which was the estimate. Cursor.rowcount will now be set to -1 in this case. ================(Build #2266 - Engineering Case #578859)================ The GUI launchers for the 11.0.1 Administration Tools no longer worked after Java for Mac OS X v10.5 Update 4 was installed. The following error messages would have appeared in the logs: [JavaAppLauncher Warning] Java application launched from PPC or bad stub. Relaunching in 32-bit, and tagging sub-processes to prefer 32-bit with $JAVA_ARCH=i386. [JavaAppLauncher Error] This process is [i386] and was re-exec'd from [i386], but for some reason we are trying re-exec to []. [JavaAppLauncher Error] unable to find a version of Java to launch This has been fixed. There are two workarounds: 1. Use the command line launchers instead of the GUI launchers. 2. Run the following from a terminal: . <SQL Anywhere 11 Installation Directory>/System/bin64/sa_config.sh for TOOL in DBConsole.app InteractiveSQL.app MobiLinkMonitor.app SybaseCentral.app ; do chmod +w "$SQLANY11/../$TOOL/Contents/MacOS/ JavaApplicationStub" ; cp /System/Library/Frameworks/JavaVM.framework/ Versions/A/Resources/MacOS/JavaApplicationStub64 "$SQLANY11/../$TOOL/ Contents/MacOS/JavaApplicationStub" ; done Note, the portion of the script from "for" to "done" should be one single line. ================(Build #2265 - Engineering Case #578385)================ Following an initial install of version 11.0.1, the installer would have left incorrect information as to the version of the documentation that was installed, 11.0.0 instead of 11.0.1. Any method of checking for documentation updates, via the web page, at the end of install, using dbsupport, or using the Admin Tools, would then have used the incorrect version. This has now been corrected. ================(Build #2261 - Engineering Case #577714)================ The ADO.Net sample program LinqSample was not working correctly. This has now been fixed. ================(Build #2260 - Engineering Case #577334)================ When using the SQL Anwhere C API (drivers for PHP, Perl, Python, and Ruby), applications executing RAISERROR with a user-defined error, would have seen the correct error code returned, but the error message was returned as "Unknown error". This has been fixed. ================(Build #2260 - Engineering Case #577092)================ Previously, the SQL Anywhere Python driver (sqlanydb.py) raised an OperationalError for all database errors. The driver now raises an IntegrityError for the following SQLCODEs: SQLCODE Error -193 Primary key for table '%1' is not unique : Primary key value ('%2') -194 No primary key value for foreign key '%1' in table '%2' -195 Column '%1' in table '%2' cannot be NULL -196 Index '%1' for table '%2' would not be unique ================(Build #2244 - Engineering Case #572549)================ On Solaris systems with a non-UTF8 locale (eg. GB18030), when installing SQL Anywhere to a path containing MBCS characters, the installer would have failed to register the Sybase Central plugins. This has now been fixed. ================(Build #2242 - Engineering Case #586604)================ On Solaris systems, if the directory /usr/ucb precedes /bin and /usr/bin in the PATH, the installer could have failed. Fixed by prepending /bin and /usr/bin to our local copy of PATH. ================(Build #2240 - Engineering Case #564857)================ In very rare circumstances, SQL Anywhere .NET provider could have crashed the work process in IIS. This problem has been fixed ================(Build #2235 - Engineering Case #571253)================ When installing only the MobiLink components on Linux systems using the 1.0.1 GA install, the dbfhide utility was not installed. This utility should be installed, as it is used for both MobiLink and Relay Server setup. This has been corrected. ================(Build #2226 - Engineering Case #570115)================ Character set translation wasn't being done properly by the SQL Anywhere Python driver. Unicode encoding and decoding errors were possible, as well as incorrect translations. This has been fixed so that conversions are based on the connection's CharSet property. ================(Build #2214 - Engineering Case #569114)================ The SQL Anywhere Monitor, when installed by the standalone installer, was not able to monitor MobiLink servers. The standalone installer was not installing the library mljstrm11.dll as part of the SQL Anywhere support component. This problem does not exist in the edition of SQL Anywhere Monitor included with SQL Anywhere. This has been fixed. ================(Build #2211 - Engineering Case #568657)================ Signed and unsigned short values were not being translated properly by the SQL Anywhere Python interface. Attempting to use short values would have resulted in errors like "struct.error: bad char in struct format" or "struct.error: unpack requires a string argument of length 1". This has been fixed. ================(Build #2202 - Engineering Case #567590)================ The SQL Anywhere Monitor was setting redundant HTTP headers which would have caused the browser-based interface to function incorrectly when using SSL on Internet Explorer. This has been fixed by removing the redundant HTTP headers. ================(Build #2195 - Engineering Case #566703)================ The PHP external environment was passing strings as LONG VARCHAR, which was causing character set conversion between the server and the PHP process. This would have corrupted binary data. This has been corrected so that all strings are now passed as LONG BINARY, which means that no character set conversion will be done. ================(Build #2194 - Engineering Case #566711)================ The PHP external environment process would have crashed if the system procedures sa_http_php_* were called from the Interactive SQL utility, or anywhere outside of an HTTP server request. This has been fixed ================(Build #2194 - Engineering Case #566688)================ Prebuilt binary libraries for PHP 5.2.9 have now been added. ================(Build #2194 - Engineering Case #561831)================ The PHP external environment, when used in the HTTP context, was not sending the appropriate HTTP status code back to the client. This has been fixed. ================(Build #2187 - Engineering Case #565891)================ When run on Unix systems, the server would have crashed or hang if a client application attempted to connect and disconnect in a tight loop. Another symptom may have been that the client would have received the following error: -832 Connection Error: Found server but communication error occurred. For this to have occurred, the connection must have been via shared memory, the application must have previously connected and disconnected successfully so as to unload the client libraries (ODBC, DBLIB, or DBCAPI), and the time between the last disconnect and the new connect was within 10ms. This has been fixed. ================(Build #2182 - Engineering Case #561825)================ The PHP external environment did not expose all of the $_SERVER fields during an HTTP request, as specified by the CGI/1.1 specification. This has been fixed. ================(Build #2173 - Engineering Case #563832)================ The Windows makefiles for the PerformanceFetch, PerformanceInsert, and PerformanceTransaction SQL Anywhere samples could not have been used to build the sample applications, as they referenced directories that no longer existed in the version 11.0 installation. This has now been fixed. ================(Build #2151 - Engineering Case #560351)================ Columns of type UNIQUEIDENTIFIER were being fetched in binary format in the SQL Anywhere C API (php, Perl, Python and Ruby), where as they should have been returned as strings. This has been fixed. ================(Build #2150 - Engineering Case #559864)================ Connecting, disconnecting, and reconnecting using the same connection handle would have caused error -298 "Attempted two active database requests" in dbcapi. For example: conn = sqlany_new_connection(); sqlany_connect( conn, <connection_string> ); sqlany_disconnect( conn ); sqlany_connect( conn, <connection_string> ); The last sqlany_connect() call would have returned error -298. This has been fixed. The workaround is to call sqlany_free_connect() and allocate and new handle. ================(Build #2148 - Engineering Case #558984)================ The JDBC sample applications incorrectly contained references to the SQL Anywhere 10 ODBC driver. This has been fixed. Comments were also added that explain the DriverManager.registerDriver and DriverManager.getConnection code. ================(Build #2139 - Engineering Case #556340)================ Applications fetching data from an NCHAR column that was greater than 32767 bytes, using the Perl, Python, PHP, or Ruby drivers, may have crashed. This has been fixed. ================(Build #2135 - Engineering Case #555024)================ When the server was run on Unix systems, the PHP external environment would have reported all errors, warnings, etc, even when PHP was explicitly configured not to do so. This has been fixed. ================(Build #2129 - Engineering Case #553491)================ The Apache redirector module would have crashed when used with the Sun built Apache web server that currently ships with the Solaris operating system. This has been fixed. ================(Build #2114 - Engineering Case #550418)================ The Python module would have sent all "string" host variable data as varchar data. This would have resulted in an unwanted character set conversion when the desired type was binary. This has been fixed. As well, Python scripts can now pass an instance of sqlanydb.Binary in the variable data list. This will cause the value to be sent as binary data.

SQL Anywhere - SNMP Extension Agent

================(Build #2537 - Engineering Case #651707)================ The iAnywhere.mib file that shipped with the SNMP agent was not SMI compliant. This has been fixed. Note that this change did not affect the software itself. ================(Build #2468 - Engineering Case #635419)================ Attempting to retrieve the uid_has_hyphens option setting through the SNMP interface would always have returned NULL. This has been fixed.

SQL Anywhere - Server

================(Build #3156 - Engineering Case #764411)================ If the first line of the HTTP response from an outbound client HTTP request was split across two or more packets then the server would have failed to accept the response from the remote server. This has been fixed. ================(Build #3146 - Engineering Case #761039)================ Under exceptionally rare circumstances, the server may have crashed when executing UPDATE or DELETE statements that bypass the optimizer if the number of columns of the table was evenly divisible by 32, and all the column values were needed in the statement and an index had been chosen. This has been fixed. ================(Build #3113 - Engineering Case #662248)================ In rare, timing and data-dependent cases, the server could have hung or crashed during execution of parallel query plans. This has now been fixed. ================(Build #3112 - Engineering Case #757009)================ When the server executed an ALTER TABLE statement, or loaded the table definition of a table with a unique index (primary key, table/column unique constraint or unique index) it did not derive the unique property to non-unique declared indexes that were defined on a superset of the columns of a unique index. For example: If a table has a primary key on columns (col1, col2) and there is another index on columns (col2, col3, col1) then this other index is unique as well. The optimizer relies very much on this unique property of an index for cardinality estimation. So the server may have used an non-optimal plan if above conditions were true. This has now been fixed. ================(Build #3110 - Engineering Case #757492)================ When a multibyte character string with a truncated last character was unloaded, the last two bytes of a character may be added to the end of the string as ASCII characters. This has been fixed. ================(Build #3110 - Engineering Case #757146)================ Under rare circumstances, the server could have crash when executing an ALTER MATERIALIZED VIEW … IMMEDIATE REFRESH statement. This has been fixed. ================(Build #3106 - Engineering Case #748976)================ If a database had one or more of the following public options set differently: - ansinull=On - conversion_error=On - divide_by_zero_error=On - sort_collation=Internal - string_rtruncation=On , and the specified value was then set as a temporary option for the connection creating a materialized view, recovery of the CREATE MATERIALIZED VIEW statement would have failed. This has been fixed. Note that the fix applies only to the CREATE statement executed with the fixed version of the server. ================(Build #3100 - Engineering Case #755524)================ Under rare circumstances, queries using hash filters could have caused the server to crash. This was more likely in environments with a heavy load, and/or cursors held open for long periods of time. This has been fixed. ================(Build #3100 - Engineering Case #750513)================ The server could have crashed if a TDS based connection sent a cancel request and a cursor close request at the same time for the same connection. Note that the cancel request could have either been sent explicitly by the application or implicitly by the underlying driver due to a query timeout. This problem has now been fixed. ================(Build #3097 - Engineering Case #753721)================ The row-level update triggers and referential update actions may have incorrectly fired for unchanged columns if the UPDATE statement was executed by SQL Remote and caused an update conflict. This has been fixed. ================(Build #3078 - Engineering Case #752201)================ If a procedure was defined with the special values SQLCODE or SQLSTATE as parameters, and the procedure was used in the FROM clause of SELECT statement, it was possible that the server could have crashed. This has been fixed. ================(Build #3061 - Engineering Case #749170)================ When invoked with a very large integer value, the hours() function could have returned an incorrect result. For example, hours function invoked with a ’12:00’ time and a very large integer argument would return a value like ’22:44’. This has been fixed. ================(Build #3039 - Engineering Case #746586)================ In rare cases, the server may have crashed or returned an incorrect SQL error if the UPDATE clause of a bypass update statement had an invalid subselect as table-expression. This has been fixed. ================(Build #3033 - Engineering Case #696753)================ Under rare circumstances, executing a CREATE TEMPORARY PROCEDURE statement could have crashed the server. This has now been fixed. ================(Build #3030 - Engineering Case #745468)================ If a Directory Access server accessed a file with a size over 4GB, the file length would have been reported as a size smaller than 4GB. This has been fixed. ================(Build #3024 - Engineering Case #704468)================ If deadlocks arose between connections using parallel execution plans, the deadlock may not have been detected. Additionally, another connection later contending for the same locks could have caused the server to crash. This has been fixed. A workaround is to set the option MAX_QUERY_TASKS to 1 for transactions that are known to participate in deadlocks. ================(Build #3017 - Engineering Case #743871)================ If the query of a cursor used the OrderedGroupBy algorithm in its execution plan, and was used to perform fetches that reversed direction of the scan, incorrect results could have been returned. This could have been observed for a cursor that fetched the first row, then second, then returned to the first row of an aggregate query. This has been fixed. ================(Build #3003 - Engineering Case #742010)================ A mirror server or copy node could have crashed if snapshot isolation was enabled and read-only connections were committed or rolled back. This has been fixed. ================(Build #2997 - Engineering Case #726235)================ Under rare, timing and execution plan dependent circumstances, execution of a parallel query plan could have caused the server to hang. This has been fixed. A workaround is to disable intra-query parallelism for affected queries. ================(Build #2996 - Engineering Case #647836)================ Runtime errors (for example, conversion errors) during the execution of parallel plans may have caused the server to crash. This was most likely to have occurred when running spatial queries. This has been fixed. ================(Build #2992 - Engineering Case #740651)================ If the Unload utility (dbunload) was run on a database that had a user with an expired password, or if a new user had been created that was forced to change their password on first login, the resulting reload script would have contained an ALTER USER statement that would have failed with a syntax error. This problem has been fixed. The correct "ALTER USER <user-id> FORCE PASSWORD CHANGE ON" syntax is now correctly generated in the reload script. ================(Build #2989 - Engineering Case #701648)================ Procedure profiling results would have shown an invalid execution time if the total execution time of the request exceeded 4,294,967,295 microseconds. This has been fixed. ================(Build #2986 - Engineering Case #697936)================ A statement could have failed with an error (Assertion 106104 failed) if the statement contained an aggregate function AGG( agg_arg ) where: - agg_arg was a complex expression - a complex sub-expression of the agg_arg was used in the WHERE (or in an ON condition) - the optimizer selected an execution strategy involving "distinct-by-rowids" (for example, there was an EXISTS subquery) This problem has been fixed. For example, the following query could have caused the SELECT statement to fail with the assertion failure error: create table T_DBR_1( x int ); create table T_DBR_2( x int ); insert into T_DBR_1 select row_num from sa_rowgenerator(1,10); insert into T_DBR_2 select row_num from sa_rowgenerator(1,100); commit; select count(*), sum( complex_expr1+2 ) from ( select case R1.x*10 when 11 then R1.x end case complex_expr1 , 99+R2.x as complex_expr2 from T_DBR_1 R1 left join T_DBR_2 R2 on R1.x = R2.x where exists ( select * from dbo.rowgenerator R3 where R3.row_num+1 = R1.x ) ) D where complex_expr1 <> 12 or complex_expr2+2 <> 11 ================(Build #2986 - Engineering Case #681579)================ For certain queries containing the built-in function ARGN(), the ARGN() expression may either have returned an incorrect value due to incorrectly matching an earlier case in the expression, or caused the server to crash. The probability of either failure was very small, and depended on both the database page size and the query text; however, the failure was deterministic for a given database and query text. This has been fixed. ================(Build #2985 - Engineering Case #733306)================ The server would have returned the error "Correlation name ... not found" for a query when the following conditions were true: - the query contained a proxy table and a nested query block with an outer reference - the nested query block used a view with a non-flattable select statement - the outer reference in the nested query block could have been pushed into the select statement of the view For example, in the following query T1 is a proxy and would have returned the error "Correlation name 'V0' not found". create view V1 as select 2 as col1 union select 1; select ( select col1 from V1 where col1 = V0.c21 ) as D from T2 V0, T1; This has been fixed. ================(Build #2984 - Engineering Case #739187)================ If an application executed the STOP JAVA or STOP EXTERNAL ENVIRONMENT statement for a database scoped external environment (i.e java or clr), then the server and external environment resources associated with the connection would be correctly cleaned up, but the external environment executable would not have been shut down. This problem has been corrected and the executable will now shut down when the STOP JAVA or STOP EXTERNAL ENVIRONMENT CLR statement is explicitly executed and there are no other connections using the database scoped external environment. ================(Build #2982 - Engineering Case #738994)================ If the mirror tried to take over as primary and failed, in rare cases it was possible for the database on the mirror to have become corrupted. The most likely case of this occurring involved the connection between the two partners being dropped for some reason, and then the mirror server or database being shut down while the mirror was in the middle of attempting to take over as primary. This has been fixed. ================(Build #2982 - Engineering Case #738756)================ If an operation on the database had executed trigger actions that included UPDATE PUBLICATION commands, and that operation was also implicitly rolled back because of an error in the trigger (such as a referential integrity violation), then it was possible for SQL Remote (dbremote) to have sent operations that would have been rolled back in the database. The Log Translation utility (dbtran) may have also shown operations as committed in the translated transaction log that were rolled back. This issue has now been fixed ================(Build #2981 - Engineering Case #738955)================ In rare timing dependent cases, when the primary server was shutdown, the mirror could have failed to take over as primary. In versions 11 and 12, both the primary and mirror could have both appeared to have hung for two minutes while the primary was shutting down. This has been fixed. ================(Build #2979 - Engineering Case #738617)================ In exceptional rare circumstances, the server may have crashed while trying to use the string value of a column DEFAULT or COMPUTE definition. This may have occurred after resetting the column's DEFAULT or COMPUTE definition using ALTER TABLE. Restarting the database after executing the ALTER TABLE prevents the problem. This has been fixed. ================(Build #2979 - Engineering Case #736687)================ Queries with predicates of the form '( T.X = <constant expression> OR T.X = <constant expression> OR ...)' may have had unoptimal plans if the <constant expression> was a variable, host variable, or aliased constant. This has been fixed. ================(Build #2976 - Engineering Case #738276)================ For specific types of views and procedures using a WINDOW specification, it was possible for the server to crash when processing a query referencing the view or procedure. This has now been fixed. ================(Build #2973 - Engineering Case #693319)================ The sql functions set_bit() and get_bit() incorrectly accepted the value 0 for the bit-position parameter. This has been fixed. Now these functions return an error. ================(Build #2970 - Engineering Case #737186)================ In rare, timing dependent cases, executing the "ALTER DATABASE SET PARTNER FAILOVER" statement could have hung. If this occurred, the server itself was not hung, but the server on which the statement was executed would not accept connections to the database being failed over. This has been fixed. As a workaround, the server that was running as the primary could be stopped, or the database that was running as the primary could be stopped by connecting to the utility database and executing the STOP DATABASE statement. ================(Build #2970 - Engineering Case #737184)================ It was possible for a mirror server running multiple mirrored databases to have hung, have had connection timeouts, failed, or have had poor performance. These problems were more likely as the number of mirrored databases running on the server increased. This has been fixed. As a workaround, the -gn value could be increased. ================(Build #2970 - Engineering Case #737159)================ If two separate connections had set the PRIORITY connection option, and the database shut down unexpectedly so as to required automatic recovery, it was possible for the database to fail the automatic recovery with assertion 100904: Failed to redo a database operation (id=#, page_no=0x#, offset=0x###) Error: Permission denied: you do not have permission to set the option 'PRIORITY' This has been fixed. An upgraded database server will now be able to recover the database successfully. ================(Build #2970 - Engineering Case #736806)================ Under rare circumstances, evaluation of very complex expressions could have caused the server to crash. This has been fixed. ================(Build #2970 - Engineering Case #731731)================ When running on Solaris systems, if the server had accepted a new connection, but the client side closed its socket right away, the TCP listener would have been stopped and the message "TCP Listener shutting down (130)" was be displayed on the server console. This has been fixed. ================(Build #2969 - Engineering Case #736547)================ Under rare circumstances, evaluation of a query with complex expressions could have caused a server crash. This has been fixed. ================(Build #2969 - Engineering Case #725690)================ Under rare circumstances, if recovery operations performed on a database included changes affecting immediate text indexes, there was a potential for triggering assertions failures or server crashes. There is also a potential for generating incorrect score values or incorrect results for subsequent queries using the text index. These problems have now been corrected. ================(Build #2958 - Engineering Case #674545)================ If a function that can be inlined was invoked with an argument that was an expression with restrictions on where in the query it can appear (for example, an aggregate function), a syntax error could have beeen returned. This has been fixed. ================(Build #2957 - Engineering Case #735358)================ In rare situations in a high availability setup with TLS connections, it was possible for the primary server to hang while doing a commit. This is the same fix that was done for Engineering case 674782, but now available on Unix platforms. ================(Build #2957 - Engineering Case #735267)================ When using Snapshot isolation, a statement-level or transaction-level snapshot may remain active while other transactions completed. Previously, the time to close the snapshot was proportional to O(N^2) for N transactions that completed with the snapshot open. With one hundred thousand transactions, this could have taken over a minute to close a single snapshot. With one million transactions, this could have taken over 100 days to close a single snapshot. During this time, other transactions were not allowed to start or stop. The server would have appeared to be fully busy on a single core. This performance has been improved; for one hundred thousand transactions, the new algorithm completes in 13 milliseconds (compared to 80205 milliseconds previously). Further, it was possible for the server to crash with specific access plans relating to viewing snapshot meta-data. This has also been fixed. A best practice is to ensure that the number of transactions tracked by the server is minimized; for example, by keeping the length of transaction snapshots short (commit as soon as possible). For statement-level snapshots, the snapshot is closed when the statement is closed. For cursors opened WITH HOLD (for example, using ODBC), the snapshot will not be closed when a COMMIT or ROLLBACK is performed; it is delayed until the statement is closed. Best practice recommends closing these cursors promptly. The sa_snapshots() procedure can be used to monitor active snapshots and sa_transactions() monitors transactions being tracked due to snapshots. ================(Build #2954 - Engineering Case #732453)================ If an application made a Java External Environment call to a Java method that made server side requests, then the Java External Environment may have hung when the Java method created or prepared a large number of server-side statements but did not explicitly close statements that were no longer needed. This problem has now been fixed. ================(Build #2952 - Engineering Case #734049)================ If the trigger definition resulting from ALTER TRIGGER statement execution conflicted with an existing trigger, the original trigger could have been deleted, and a wrong error returned. This has been fixed. This change also introduces a change in the algorithm used to decide the order of firing triggers when an ORDER clause is not specified, or multiple triggers with the same order and combination of events were created. For example, this may change the order in which triggers created with “UPDATE ORDER 2”, “UPDATE, DELETE ORDER 2” and “UPDATE OF <col> ORDER 2” are fired. Note that documentation explicitly recommends specifying different ORDER values for triggers with the same event. If your database contains such sets of triggers, and the order of firing is important, please alter the triggers to reorder them accordingly. In general, both UPDATE ORDER 1 and UPDATE OF <col> ORDER 1 triggers will fire before any UPDATE … ORDER 2 triggers are fired. A unique ordering between UPDATE and UPDATE OF <col> triggers is still recommended. ================(Build #2952 - Engineering Case #732745)================ If a SELECT statement with an INTO clause contained a variable in the select list, then the temporary table was created with a not-nullable or nullable column definition depending on the value of the variable. This has been fixed. The column definition will now always be nullable in this context. ================(Build #2949 - Engineering Case #731211)================ A query of the form “select * from T, R where T.X IN (R.X, T.Y )” may have had a suboptimal execution plan if an index existed on the column T.X. This has been fixed. ================(Build #2948 - Engineering Case #733313)================ The mirror partner server in a mirroring setup may have failed to take over immediately as primary, and instead restarted, when the primary mirrored database became unavailable but the server was still running. This could have happened when the primary mirror server was shutting down, or if the “STOP DATABASE” statement has been used on the primary server. This has been fixed. ================(Build #2942 - Engineering Case #732156)================ Validating a database on a server with concurrent activity could have resulted in failed assertions, or a server crash. This has now been fixed. ================(Build #2942 - Engineering Case #730149)================ On rare occasions the server would have crashed on shutdown when running on Linux systems. The crash would have occurred when stopping shared memory connections. This problem has now been fixed. ================(Build #2936 - Engineering Case #726536)================ When using the START EXTERNAL ENVIRONMENT statement to start a connection-scoped external environment, and then disconnecting later on without actually making any external environment calls to the connection-scoped external environment, then there was a small chance the server would have crashed. This problem has now been fixed. ================(Build #2935 - Engineering Case #725391)================ If an Open Client or jConnect application attempted to perform a positioned update on a table that had an NCHAR based column in the primary key, then there was a chance the application would have hung. This problem has now been fixed. Note that this problem did not affect non-TDS based clients. ================(Build #2933 - Engineering Case #724507)================ In rare circumstances, a server that was running diagnostic tracing to a remote server may have crashed if the diagnostic tracing server or database stopped, or if the diagnostic tracing server or database stopped and tracing was detached at the same time. This has been fixed. ================(Build #2929 - Engineering Case #729394)================ In very rare cases, a database could have failed to start with the error "Fatal error: undo log corrupted after log rename". In order for this to have occurred, all of the following needed to be true: 1) a connection to the database had an outstanding transaction 2) while there was this outstanding transaction, the transaction log was renamed or truncated 3) the database had no free pages and needed to grow during the checkpoint that was part of renaming or truncating the transaction log 4) the connection from 1) still had an outstanding transaction during the last checkpoint before the database stopped or was backed up 5) the database was not shut down cleanly, or it was backed up 6) attempting to start the database from 5) required recovery and could have in rare cases failed with the error "Fatal error: undo log corrupted after log rename". Other failures may have been possible if all of the above conditions applied. This has been fixed to avoid corrupting the undo log. ================(Build #2929 - Engineering Case #724355)================ In very rare circumstances, the server may have crashed while performing a query sort operation if the sort key was very long and the query was low on cache space. This has been fixed. ================(Build #2927 - Engineering Case #729006)================ Creating a procedure with a right curly-bracket "}" in procedure_name(e.g CREATE PROCEDURE “P1{}”()…) would have failed. This has been fixed. ================(Build #2926 - Engineering Case #728597)================ Crashes and data corruption were possible due to silent I/O failures on Red Hat Linux 6, as well as other Linux distributions with kernel versions greater than 2.6.38. The most likely manifestation of this bug was assertion 200505 ("checksum failure on page x"). This problem is related to a possible bug in the transparent huge pages (THP) feature introduced in these operating system versions. Red Hat bug 891857 has been created to track this issue. The problem can be triggered by calling an external environment, xp_cmdshell, or other procedure that causes a fork while other I/O is occurring. A known limitation with the Linux kernel limits the use of fork while doing O_DIRECT I/O operations. Essentially what can happen is that the data can come from or go to the wrong process’ memory after the fork. SQL Anywhere performs O_DIRECT I/O operations according to the documented safe usage. However, THP appears to cause further problems and the O_DIRECT I/O data comprising database page reads/writes appears to get lost. This has been fixed by disabling THP on the SQL Anywhere cache memory where possible. We are working with Red Hat to identify a solution within the operating system. There are two possible workarounds: 1. disable THP on a system-wide basis with one of the following methods: echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled boot with transparent_hugepage=never 2. disable O_DIRECT I/O for database file reads/writes with one of the following methods: use the -u flag on the server command line set SA_DISABLE_DIRECTIO=1 in the environment before starting the server Transparent huge pages cannot be disabled just for the SQL Anywhere cache memory on Red Hat Enterprise Linux 6. SQL Anywhere now disables direct I/O if transparent huge pages are enabled and cannot be disabled on a per-allocation basis. A warning will be printed as the database file is being opened to indicate that direct I/O is disabled due to this bug. This is similar to how SQL Anywhere handles file systems that do not support direct I/O. Customers using RHEL 6 who wish to continue using direct I/O should use the previously-stated command to disable THP at the system level. ================(Build #2923 - Engineering Case #728458)================ The server may have behaved badly, including crashes or corruptions, when using a recent version of Linux with glibc 2.11 or higher. This has been fixed. ================(Build #2923 - Engineering Case #728449)================ When using communication compression on HP-UX, or on Linux with a recent glibc version, a communication error could have occurred on the compressed connection. This has been fixed ================(Build #2915 - Engineering Case #727315)================ Under rare circumstances, the server may have crashed if RememberLastStatement was turned on and a statement being executed was too complex. This has been fixed. ================(Build #2913 - Engineering Case #727087)================ If a stored procedure statement contained an OPENXML statement with a variable used in an XPATH value, or a CONTAINS condition with a variable used in the query parameter, then the statement could have failed incorrectly with an error: -134 "Feature 'OPENXML with non-constant query' not implemented" -1159 "Non-constant or unknown text query string." In order for the error to be returned, the variable must have been used in a larger expression such as a cast or string concatenation. The failure would have occurresd intermittently, for example on the 11th execution of the statement. This has been fixed. ================(Build #2913 - Engineering Case #726951)================ In rare timing dependent cases, if the primary server was stopped, the mirror server would have failed to take over as the new primary server. This has been fixed. ================(Build #2912 - Engineering Case #726945)================ Attempting to start external environments would have failed if an Version 10.0 database, with a large number of objects, was upgraded. This problem has now been fixed. ================(Build #2911 - Engineering Case #726715)================ The server could in some cases, have crashed while performing a BCP IN request if an error was generated while servicing the BCP request. This problem has now been fixed. ================(Build #2910 - Engineering Case #726388)================ Some XML documents could have caused the server to allocate excessive memory while processing OPENXML. This has been fixed. These types of documents now return the error: -890 "Statement size or complexity exceeds server limits" In some cases, a statement processing an XML document could not have been stopped by cancelling or dropping the connection. This has been fixed ================(Build #2910 - Engineering Case #723960)================ Under specific circumstances, the server could have crashed when applying updates via SQL Remote. This has been fixed. ================(Build #2910 - Engineering Case #720804)================ If a backwards index scan blocked on a locked row, it would have continued onto the next row after it resumed, rather than retrying the current row. This has been fixed. ================(Build #2908 - Engineering Case #725820)================ If a high availability partner was stopped while it was attempting to determine its role, the database may have been corrupted. If this corruption occurred, attempting to start the database would likely fail with the 100904 assertion "Failed to redo a database operation." This has now been fixed. As a workaround, when stopping a mirror partner that is currently determining the role with an affected build, it is recommended that the server is terminated instead of stopped normally. If this database corruption occurs, the database is corrupted but the transaction log is not. The database can be fully recovered by applying the current transaction log file(s) to a backup. ================(Build #2908 - Engineering Case #725718)================ When running the server on Linux systems with a recent glibc version, the server could have crashed. This was more likely when a system with many CPUs was being used. This has now been fixed. The only reliable workaround is to use an older version of glibc. ================(Build #2906 - Engineering Case #725553)================ A client request which required a server to server request could have hang if the server to server connection was dropped while the client request was using it. For example, if a client request (such as a commit) resulted in writing to the transaction log on a primary high availability server, and the connection to the mirror (the server to server connection) dropped while the client request was attempting to send log pages to the mirror, the client request could have hung. Similarly, this could have occurred during a client request if a connection to a diagnostic server dropped during the client request. Note that only the single client request was hung and the server was still operating normally otherwise. This has been fixed so that the client request will not hang. As a workaround, the client connection that is hung can be dropped using DROP CONNECTION. This will cause the client connection to immediately report an error. ================(Build #2906 - Engineering Case #725110)================ Under rare circumstances, the server may have crashed when the system procedure sa_locks() was trying to collect row locking information for global temporary tables. This has been fixed. ================(Build #2905 - Engineering Case #725392)================ When setting options using the system procedure sa_server_option(), the documentation states that 'YES/NO' as well as 'ON/OFF' can be used for any settings that accept Boolean values. There were two options that would accept 'ON/OFF', but not 'YES/NO', ProcedureProfiling and DeadlockLogging. This has been fixed. ================(Build #2903 - Engineering Case #725197)================ Using the PHP external environment in an HTTP request, could have returned an HTTP status code of 500 even when it was successful. This was most likely to happen on Windows systems, and has now been fixed. ================(Build #2903 - Engineering Case #724550)================ The CacheFree server statistic could have underflowed and presented extremely large values. This has been fixed. ================(Build #2901 - Engineering Case #724543)================ In very rare cases, the server could have crashed while parsing a request-level log file using the system procedure sa_get_request_times(). This problem was introduced by the changes for Enginnering case 722122, and has now been fixed. ================(Build #2899 - Engineering Case #711401)================ Under rare circumstances, snapshot transactions could have caused the server to fail assertions 200505, 200610, 201501, or 201503. This was more likely to have occurred when other connections had rollbacks of large transactions underway. This has been fixed. ================(Build #2898 - Engineering Case #723710)================ On Mac OS X systems, use of the server option -um allows the server to run with a GUI (through DBLauncher). It was not displayed though in the server's usage message. This has now been corrected. ================(Build #2894 - Engineering Case #723096)================ If the SQL Anywhere server was registered with an ActiveDirectory LDAP server and an LDAP error occurred at just the right time, the LDAP entry could have been corrupted. When the server then shutdown, no new server with the same server name would have been able to start. This has been fixed. ================(Build #2894 - Engineering Case #722466)================ In rare circumstances, preforming bulk inserts and deletes of large amounts of data may have caused the server to fail assertion 200130. This has been fixed. ================(Build #2893 - Engineering Case #722972)================ Server may have run out of memory and crashed when executing the system procedure sa_get_request_times(), especially when running with databases that had large page sizes. This has been fixed. ================(Build #2893 - Engineering Case #722440)================ In rare timing dependent cases, two partners attempting to determine roles could have restarted their databases unnecessarily a number of times until their role was finally determined. Also, in rare timing dependent cases, a running copy node that was able to reconnect to its parent server could unnecessarily have restarted its database. In order for this to have occurred, the parent server would needed to have been unavailable for long enough for the copy node to connect to the root or alternate parent. These issues have been fixed. ================(Build #2893 - Engineering Case #721977)================ Under very rare circumstances, the server may have crashed when encountering a thread deadlock during a login packet receive. This has been fixed ================(Build #2893 - Engineering Case #719334)================ The cardinality estimation for an index with descending (DESC) columns may have been incorrect. This has been fixed. The conditions for this issue to happen, for a query Q, were: 1 - The index on the table T was of the form <X1, …, Xk, …> with k > 1 2 - The first k-1 columns in the prefix of the index had predicates of the form T.Xi = constant in the query Q 3 - The column k had the predicate of the form T.Xk \theta constantk (\theta n {<, <=, >, >=}), or T.Xk between constantk and constank+1 in the query Q 4 - The column T.Xk was declared DESC in the index. ================(Build #2891 - Engineering Case #721394)================ The server may have failed assertions 111706, 111707, or 201200, if a procedure call was used in a SELECT statement, one of the specified arguments exceeded its declared parameter size, and the procedure used the argument in a DML statement. This has been fixed. ================(Build #2887 - Engineering Case #716538)================ An addition fix was required for Engineering case 714656, where the server could have crashed when auto-starting a database. ================(Build #2885 - Engineering Case #721070)================ The REGEXP search condition and the REGEXP_SUBSTR function could have incorrectly matched or failed to match regular expressions with ^ or $ followed immediately by a character that had special meaning in a regular expression if it was escaped. For example, REGEXP_SUBSTR( 'A', '^A' ) was incorrectly returning NULL. This has been fixed. ================(Build #2885 - Engineering Case #721039)================ Dropping a connection that had previously made an external environment call to a connection scoped external environment, could, in very rare cases, have caused the server to crash. This problem has now been fixed. ================(Build #2884 - Engineering Case #720462)================ Under very rare circumstances, the server may have crashed when running the system procedures sa_char_terms or sa_nchar_terms, or some internal text index related procedures, with invalid arguments. This has been fixed. ================(Build #2882 - Engineering Case #720811)================ A high availability mirror or a copy node server running on Windows could have failed assertion 112002 during a transaction log rename. This has been fixed. If the high availability mirror was busy applying log pages, failing over due to the other partner being preferred, or due to the ALTER DATABASE SET PARTNER FAILOVER statement, could have been delayed for a minute or more. This has also been fixed. ================(Build #2882 - Engineering Case #720489)================ In very rare timing dependent cases, when a high availability mirror was taking over as primary, it could have hung or failed assertions 100924 or 100925. In order for this to have occurred, the mirror must have had active read-only connections using temporary tables and performing commits or rollbacks, as well as certain other conditions. This has been fixed. ================(Build #2880 - Engineering Case #720384)================ Under very rare circumstances, the server may have crashed when running the procedure sp_forward_to_remote_server, or any of the Remote Data Access procedures (i.e sp_remote_columns, sp_remote_tables, etc). This has been fixed. ================(Build #2880 - Engineering Case #720298)================ Under rare circumstances, calling the system procedure sa_index_statistics() could have caused the server to crash. This has been fixed. ================(Build #2879 - Engineering Case #719710)================ Executing an ALTER TABLE statement on an empty table could have caused a server crash on a subsequent table scan of the table. This has been fixed. ================(Build #2878 - Engineering Case #719397)================ Under rare conditions, the server or client library could have crashed when attempting an LDAP operation (eg. registering the server, searching LDAP for servers when connecting). This has been fixed. ================(Build #2877 - Engineering Case #719932)================ In a mirroring setup during a forced failover, it was possible for the new mirror to get stuck in a situation where the database would print the following error to the console log: “primary not available or mirror log longer than primary”, and proceed to restart. This could often be fixed by executing a transaction on the new primary after the failover was complete. This bug has been fixed, and the mirror server should now start up without difficulty. ================(Build #2875 - Engineering Case #719220)================ In rare timing dependent cases, the changes for Engineering case 713113 mau have caused a mirror or copy node to fail assertion 100927 when starting the database. The assertion text was "Transaction log page number 0x<first-hex-number> from parent or partner is not expected page number 0x<second-hex-number>", where the first-hex-number was one lower then second-hex-number. If this assertion failure occurred, restarting the mirror or copy node should succeed. This has been fixed. ================(Build #2874 - Engineering Case #719503)================ The server would have failed assertion 107400 - Internal parse tree error, if a query used proxy tables and contained a common table expression in a derived table, and the derived table was flatted. This has been fixed ================(Build #2872 - Engineering Case #717944)================ In rare cases, calling the system procedure sa_transactions(), may have lead to a server crash. This has been fixed. ================(Build #2872 - Engineering Case #715843)================ In rare cases, attempting to use nested procedures with nested transactions and internally generated temporary tables would have failed assertion 201501, 101412, 200505 or others. This problem has now been fixed. ================(Build #2871 - Engineering Case #674549)================ The server may have failed assertions 111706, 111707, 106808, or 201200, if the recursive subquery of a recursive common table expression returned a larger select-list item value than its corresponding select-list item in the initial subquery. The problem only happened if the recursive subquery performed a join operation to rows added during previous iterations. This has been fixed so that the server now returns the error "Recursive column %1: conversion from '%2' to '%3' loses precision ". ================(Build #2869 - Engineering Case #718525)================ In very rare situations, the server could crash when using the OPENSTRING clause, string concatenation, substring operation, or attempting to execute a LOAD TABLE statement. The problem was most likely to have occurred when cache pressure was very high. This problem has been fixed. ================(Build #2867 - Engineering Case #718369)================ Attempting to insert a string literal containing multi-byte characters into an nchar based proxy column may have actually inserted mangled data into the remote column, if the local database character set was not UTF8. This problem has now been fixed. Note that inserting multi-byte character data using an nchar based variable or column as the source works fine. As a result, using an nchar based variable instead of a string literal is a possible work around for this problem. ================(Build #2867 - Engineering Case #717966)================ The time to process an HTTP or HTTPS request that contained a large number of input variables may have been longer than expected. This has been fixed. ================(Build #2867 - Engineering Case #717024)================ Attempting the execute a CREATE EXISTING TABLE that referenced a remote server using IBM's NotesSQL ODBC driver version 8.5.1 would have resulted in mangled column names. The statement would likely have failed with a Syntax error (SQLCODE=-131, ODBC 3 State=42000). This problem has now been fixed. ================(Build #2864 - Engineering Case #718122)================ If a connection updated a table and subsequently left a cursor open past a COMMIT or ROLLBACK, other connections would not have been able to lock the entire table in share mode (i.e. LOCK TABLE t IN SHARE MODE) until the updating connection closed the cursors and did a COMMIT or ROLLBACK. This has been fixed. ================(Build #2862 - Engineering Case #717316)================ In some circumstances, the server could have crashed, failed assertions, or rarely, could have returned incorrect data, when working with tables that contained more than eight thousand columns. This has been fixed. Note, a database with more than eight thousand columns that is run with a server that contains this fix cannot be run on an older server. Doing so will result in startup error -1007 "Unable to start specified database: '%1' is an invalid transaction log" on the older, unfixed server. ================(Build #2861 - Engineering Case #717784)================ On Windows 8 and Windows 2012 systems, the platform-related properties would have indicated an "unrecognized Windows version". Support for these two platforms has now been added. ================(Build #2859 - Engineering Case #717313)================ Archive backups would have suspended checkpoints until the next COMMIT or ROLLBACK. This would have prevent checkpoints, and commands that implicitly issued checkpoints, from running until that point. This has been fixed. ================(Build #2858 - Engineering Case #716544)================ Explicitly passing in NULL as the 3rd parameter (algorithm) to the encrypt or decrypt function would have resulted in the error: "The string is too long (Parameter 3)" SQLCODE -973, rather than having the encryption/decryption default to AES128. This has been fixed. Not specifying the third parameter at all would have worked properly. ================(Build #2850 - Engineering Case #715615)================ Under rare circumstances, database recovery could have held locks on a new text index. This has been fixed. Also, text index validation could have returned an error later than necessary. This has been fixed in version 12.0.1 and later. ================(Build #2850 - Engineering Case #715583)================ It was possible to create duplicate indexes for a table in a case-sensitive database if the only difference between the index names was case or accent. For example, both foo and Foo could have been created with same or different definitions. This has now been fixed. ================(Build #2849 - Engineering Case #715909)================ The output from the system procedure sa_locks() could have been incorrect, in that it may have missed reporting some row locks. This has now been corrected. This was a reporting problem only, and did not affect actual locking behaviour. ================(Build #2849 - Engineering Case #715687)================ When the server collects information about database pages to be used for cache warming in the next database start, it also incorrectly collected information about pages that the database cleaner task reads. This has been fixed so that page recording no longer includes pages read by the cleaner since these pages are different each time. ================(Build #2847 - Engineering Case #715597)================ Performance of statements that select from a stored procedure call is slightly improved when the call results in a SQLError. ================(Build #2847 - Engineering Case #715309)================ The server was incorrectly accepting the special values NaN, INF, and INFINITY for double and float data types when receiving host variable values. This has been fixed. Now the server will set the SQL error "Value NaN/INF out of range for destination". ================(Build #2846 - Engineering Case #714899)================ The server would have returned error code 503 when attempting a connection to an ESMTP server using xp_startsmtp. This has been fixed. ================(Build #2845 - Engineering Case #707918)================ In rare cases, a query using a parallel NestedLloopsJoin could have caused the server to crash. This has been fixed. A workaround is to disable intra-query parallelism for the affected query. ================(Build #2844 - Engineering Case #714776)================ In rare timing dependent cases, a high availability mirror or copy node could have incorrectly failed with the assertion 100927. The assertion could have occurred just after the mirror or copy node had connected to its partner or parent and had just started synchronizing. This has been fixed. ================(Build #2844 - Engineering Case #714656)================ The server could have crashed when starting a database. If the server was in the process of shrinking the cache, references to memory that were no longer available were possible. This has now been fixed. ================(Build #2842 - Engineering Case #714440)================ In a high availability system, a forced or preferred server fail-over could have failed to restart the database on the primary server if all of the following conditions held: - the database character set was different from the operating system character set - the database name (or alias) contained characters other than 7-bit ASCII characters - an "ALTER DATABASE SET PARTNER FAILOVER" statement was executed, or a preferred partner was defined and the current primary was the non-preferred partner. This has been fixed. ================(Build #2836 - Engineering Case #711791)================ Recursive queries can not contain aggregate functions. When written using a window (OVER clause), aggregates were improperly allowed. In some cases this could have lead to the server crashing under certain system conditions. This has been fixed, queries with windowed aggregate functions now correctly give an error. ================(Build #2834 - Engineering Case #713113)================ In rare timing dependent cases, a mirror or copy node could have crashed or failed assertions (the most likely assertion was 100927). This could have occurred when very frequent transactions were committed on the primary and the mirror or copy node was not applying the operations as fast as it was writing them (i.e. db_property( 'LastWrittenRedoPos' ) is significantly more than db_property( 'CurrentRedoPos' )). This has been fixed. ================(Build #2834 - Engineering Case #712884)================ In very rare timing dependent cases, if a mirroring primary failed over and then failed back, one partner could have received a log mismatch error and shutdown, and transactions that had been submitted could have been lost. Specifically, in order for this to have occurred with partners S1 and S2: - S1 must initially have been the primary, failed or otherwise have shutdown, causing a failover to S2 - S2 took over as primary - while S1 was restarting, S2 must have lost quorum and have been shutting down In which case it was possible for S1 to have become primary again, even though it was missing the transactions from when S2 was primary. This has been fixed to ensure that S1 will not be primary in this case, and S2 will continue to be primary once it restarts. ================(Build #2833 - Engineering Case #712722)================ Under rare circumstances, rollback of a DML statement that affected a table with at least one immediate text index defined could have caused production assertion failure 200112. This has been fixed. ================(Build #2832 - Engineering Case #711139)================ Under exceptionally rare conditions, the server may have crashed while accepting a new shared memory connection, if the client application exited during connect request processing. This has been fixed. ================(Build #2829 - Engineering Case #711803)================ If the encrypt() or decrypt() functions were called with a non-null string but a null encryption key, the functions returned null. This has been fixed. An encryption key is required, so these functions will now raise an error if the encryption key is null. ================(Build #2824 - Engineering Case #710285)================ Under rare circumstances, a server may have crashed while opening the result set cursor of a batch or stored procedure when the cursor's query was a cached simple SELECT. This has been fixed. A workaround is to turn plan caching off (option Max_plans_cached = 0). ================(Build #2823 - Engineering Case #710072)================ Under certain rare circumstances, calling the system procedure sa_locks() could have caused the server to fail a fatal assertion. This has now been fixed. ================(Build #2820 - Engineering Case #709909)================ In rare, timing depending cases, the server could have crashed. This was more likely to have occurred when multiple database events could start and stop concurrently on multi-core computers. This has been fixed. ================(Build #2820 - Engineering Case #668716)================ In rare circumstances, a database with snapshot isolation enabled could have triggered an assertion while updating values indexed by an immediate text index. This problem required high contention on the base table. This has been fixed. ================(Build #2817 - Engineering Case #709203)================ If a jConnect or Open Client connection prepared a statement and called a stored procedure with a set of host variables, then the server could have crashed, or returned an odd "variable already exists" error, if the stored procedure had a parameter or variable named @p0. This problem has now been fixed. ================(Build #2815 - Engineering Case #708518)================ Mirroring copy nodes could have hung on shutdown with one core at 100% utilization. ================(Build #2813 - Engineering Case #708199)================ The server would have returned a syntax error when trying to specify "client" as a secure feature to be enabled or disabled (-sf command line option). This has been fixed. ================(Build #2811 - Engineering Case #707037)================ In rare timing dependent cases, a high availability partner or copy node server could have crashed. Additionally, in rare cases, the arbiter could have reported the following message to the console: "arbiter already has two connections". These problems could have occurred when a partner detected loss of quorum, when a copy node was attempting to connect back to its original parent after being connection to an alternate parent or the root server, or if a connection between mirror servers failed. This has been fixed. ================(Build #2810 - Engineering Case #707529)================ If the primary server failed in some timing dependent cases, the mirror server could have failed to take over as primary. When this problem occurred, the mirror database would have restarted and be attempting to determine its role until the primary was restarted, or the ALTER DATABASE ... FORCE START statement was executed on the mirror server. This has been fixed. ================(Build #2808 - Engineering Case #707002)================ The request for the graphical plan of a statement would have caused the server to crash if the statement contained an IN predicate and the list consisted of only host variables and an In List algorithm was chosen for it. This has been fixed. ================(Build #2807 - Engineering Case #707019)================ When the database server was running a database whose page size was smaller than the cache's page size, dynamic cache sizing could have chosen a cache size that was too small, which could have resulted in a performance penalty. This problem has been fixed. ================(Build #2806 - Engineering Case #706724)================ The server was failing to redirect an HTTP request made to a secure web-service (requiring HTTPS protocol) when the request specified an ipv6 address. This has been fixed. ================(Build #2805 - Engineering Case #706510)================ A server would have leaked memory, and may eventually have run out of memory, if a very large number of Open Client or jConnect secure password connection requests were made. This problem has now been fixed. ================(Build #2803 - Engineering Case #706174)================ If a High Availability partner server encountered a disk full condition, is was possible for both partners to hang. This has been fixed so that the partner that encounters the disk full condition stops immediately. The other server should be able to continue as the primary or take over as the primary. Taking over requires that the primary and mirror were synchronized. ================(Build #2801 - Engineering Case #696617)================ If the database option PUBLIC.Java_vm_options was set to contain only spaces, then the server would have crashed when the JAVA external environment was started. This problem has now been fixed. ================(Build #2800 - Engineering Case #704801)================ Cursors over SELECT statements referencing proxy tables could have returned errors in the presence of publications for some of the tables. The error depends of how complex the publications are. A typical error would be "assertion failed: 102604 - Error building sub-select". This has been fixed. ================(Build #2800 - Engineering Case #703234)================ If a parallel backup with backup option WITH CHECKPOINT LOG RECOVER had finished its write pass but had disk I/O errors during its completion pass, then, in exceptionally rare circumstances, the backup may have incorrectly been marked as valid and no SQL error was returned. Also, if a parallel backup of the database file was cancelled after its read pass then the server may have crashed. Both problems have now been fixed. ================(Build #2799 - Engineering Case #640952)================ On Solaris systems, the server would have failed to start if the filesystem for the temporary file ($SATMP) was of a size greater than 4TB. This problem has now been fixed. ================(Build #2795 - Engineering Case #704057)================ If a database was created with 9.0.2.4029 or earlier, with any version of 10.0.0, or with 10.0.1.4072 or earlier, then upgraded (using the Upgrade utility or ALTER DATABASE UPGRADE) to a newer build of SQL Anywhere, the Unload utility could have erroneously generate SQL to re-create the jConnect-related objects "jdbc_functioncolumns" and "sp_jdbc_getfunctioncolumns" which are, after the builds indicated, included automatically in newly created databases. Similarly, if a database was created with any version of 10.0.0, and then upgraded to any version of 10.0.1 or later, the Unload utility could erroneously have generate SQL to re-create the SQL Anywhere internal function "sa_ansi_standard_packages". During a reload, these problems would have generated a message such as the following: ***** SQL error: Item 'jdbc_functioncolumns' already exists These problems have been fixed. ================(Build #2795 - Engineering Case #701364)================ Queries with derived tables or views using UNION, EXCEPT, INTERSECT orRECURSIVE constructs may have returned incorrect results. For this problem to have occurred at least one child of the derived table or view would have had a LIMIT, window function, or DISTINCT clause, and there was a predicate referring only to the columns of the derived table or the view in the main query block. This has been fixed. ================(Build #2795 - Engineering Case #697900)================ Attempting to execute a long SQL statement to create a stored procedure could have failed with a "parse stack overflow" error (SQLCODE -131). This problem may also have occurred when parsing a long and nested SQL statement. This has been fixed. ================(Build #2786 - Engineering Case #702733)================ This change extends the fix for Engineering case 693560. In this case, the parallel hash filter could deadlock if a runtime error occurred while it was fetching. This has now been fixed. ================(Build #2786 - Engineering Case #672447)================ Under very rare circumstances, frequent transaction log renames may have left small portions of logs that overlapped. This has been fixed. ================(Build #2785 - Engineering Case #703225)================ If a database had been created with a server from a version prior to 11.0.0, and it contained a proxy table with an index, then unloads of this database using a server from version 11.0.0 or later' would have generated an incorrect CREATE INDEX statement containing the IN "SYSTEM" clause. This has been fixed. ================(Build #2785 - Engineering Case #703104)================ When translating a transaction log with certain types of corruption, the Log Translation utility could have terminated silently, without reporting a problem. To the user, it would have appeared as if the translation completed successfully. This problem has been fixed. ================(Build #2785 - Engineering Case #703083)================ If the number of databases on the command line was near to or greater than the server concurrency setting (-gn), then the server could have crashed, or reported any of various assertion failures, during startup. The Personal Server was particularly susceptible since its default concurrency is only 20. This problem has been fixed. ================(Build #2785 - Engineering Case #703079)================ If there were connections on the mirror database, or a copy node for a mirror database, that were modifying a temporary table at the same time as the transaction log was renamed, then the copy node or mirror could have failed in timing depending cases. In particular, the mirror server or copy node could have crashed or the transaction log on the mirror server or copy node could have been corrupted. This has been fixed. ================(Build #2785 - Engineering Case #702738)================ The server could have become deadlocked when updating blobs in a table with articles or triggers. This has now been corrected. ================(Build #2785 - Engineering Case #701652)================ When shutting down a database server on a Windows machine with a SQL Anywhere Volume Shadow Service (VSS) writer service active, the database server could have logged the message "Registered with the SQL Anywhere Volume Shadow Copy Service writer." many times to the console log. This problem has been fixed. ================(Build #2785 - Engineering Case #696467)================ In very rare circumstances, the database server could have consumed 100% of 1 CPU when shutting down, or when stopping a database. This problem has now been fixed. ================(Build #2784 - Engineering Case #702296)================ When generating a reload.sql script, the server did not double-up single quotes and backslash characters in constant strings for dbspace file names in the CREATE DBSPACE statement, directory server paths in the CREATE SERVER statement, or AT location clauses of the CREATE EXISTING TABLE statement. As a result running the reload script would have failed and the generated objects would not have worked. This has been fixed. ================(Build #2783 - Engineering Case #702931)================ In very race cases, the server would have consumed 100% CPU usage while attempting to stop a database. For this to have occurred, the database being stopped needed to make heavy use of scheduled events. This has been fixed. ================(Build #2781 - Engineering Case #702731)================ In rare, timing dependent cases when using High Availability or Read-Only Scale Out, it may have been possible for the server to crash, hang, behave in unexpected ways, or have an incorrect state. This has been fixed. ================(Build #2781 - Engineering Case #701339)================ The server may have crashed when using a cached query plan if the plan useed a row column variable in a Distinct Hash strategy and the row column variable was of type string or numeric. Row column variables are column names that are used with a REFERENCING table alias name from the CREATE TRIGGER. This has been fixed. ================(Build #2781 - Engineering Case #696917)================ With the QAnywhere .NET client, the elapsed time to queue messages was substantially slower than that of version 9.0.2. Several performance optimizations have been made, bringing the timings closer to those for version 9.0.2. Note that the SQL client API is no longer supported by default. If the SQL client API is needed, the QAnywhere message store must be initialized using qaagent -si with the new option -sqlapi. ================(Build #2780 - Engineering Case #698526)================ Windows 7 and Windows 2008R2 support systems with more than 64 logical processors; however, it does so by partitioning them into "groups" with no more than 64 processors in each group. Unless an application takes additional measures to take advantage of multiple processor groups, the application will execute only within one processor group and be unaware that other processors are available. Previously, SQL Anywhere would only recognize and utilize the processors in the group to which it was assigned by the OS at startup, but now SQL Anywhere recognizes and supports all processors on Windows 7, Windows 2008R2. For more information on Windows processor groups, see the following: http://blogs.msdn.com/b/saponsqlserver/archive/2010/09/28/windows-2008-r2-groups-processors-sockets-cores-threads-numa-nodes-what-is-all-this.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/dd405503 In addition to supporting more than 64 processors on Windows, SQL Anywhere now uses the hardware topology as reported by Windows for license enforcement on all supported versions of Windows except Windows 2003 and Windows XP 64-bit edition where the operating system is known to misrepresent the actual topology. Previously, SQL Anywhere relied solely on its own hardware detection on x86 and x64 Windows platforms. By relying on the topology reported by Windows, SQL Anywhere will have a more consistent view of the topology when running in a VM. These processor topology changes include fixes on other platforms too. On Solaris prior to this change, if the standalone engine was run within a processor set it would bind itself to a single random processor in the set. Now if the standalone engine is run within a processor set, it binds to the lowest numbered processor in the set. Outside of a processor set, the behaviour has not changed: we bind to the lowest processor that is not bound to any set. Also on Solaris, the database server considered processors that were online but non-interruptible as offline. SQL Anywhere would not bind to such a processor. This problem has also been fixed. SQL Anywhere now properly avoids processors that are offline when the server starts; however, no attempt is made to adapt to processors that are taken offline or brought online during runtime. ================(Build #2779 - Engineering Case #701151)================ Read-only connections on an OEM server were not able to drop local temporary database objects. This has been fixed. ================(Build #2777 - Engineering Case #687840)================ The initial primary mirror server could have crashed or not correctly processed requests in rare timing dependent cases after executing the "ALTER DATABASE SET PARTNER FAILOVER" statement. This problem could have also occurred when a preferred partner server became available after being disconnected. This has been fixed. ================(Build #2772 - Engineering Case #700426)================ If files were opened concurrently by two threads of the same process on Windows Mobile / Windows CE devices, the two threads could have been assigned the same POSIX file handle number and IO could then have been directed to the wrong file. This problem, given the nature of Windows Mobile devices, was very unlikely to occur and has been fixed. Also, a structure used to query the OS version on Windows Mobile / Windows CE devices was not initialized correctly; however, it is not believed ever to have caused a problem. This problem has also been fixed. ================(Build #2772 - Engineering Case #700309)================ If there was an apostrophe in a user name or table name, a verbose unload (dbunload -v or an unload in Sybase Central) would have failed, and would have reported a syntax error similar to the following: ***** SQL error: Syntax error near 'xxx' on line 1 Also, during reload, extra apostrophes would be displayed in progress messages containing table, index, view, procedure or trigger names. This problem has been fixed. ================(Build #2769 - Engineering Case #695788)================ In rare, timing dependent cases, the server may have failed fatal assertion 101412 - "Page number on page does not match page requested". This has now been fixed. ================(Build #2768 - Engineering Case #689696)================ In exceptionally rare circumstances, the server may have failed with assertion errors 200130, 200131, 200106, 108701, or others, on index pages. The problem was seen on multi-core machines under very high index contention, that included index updates and deletes. This has been fixed. ================(Build #2765 - Engineering Case #697188)================ When starting the database server, an error is reported (by displaying the usage text) if a non-numeric parameter is passed where a numeric parameter is expected. For example: dbeng12 -n jcs -c nonsense However, if the argument to -c started with the a character associated with memory units (k, m, g), no usage text was displayed. For example: dbeng12 -n jcs -c garbage dbeng12 -n jcs -c magic dbeng12 -n jcs -c k This has been corrected so that the usage text is now displayed. ================(Build #2761 - Engineering Case #693111)================ On Windows Mobile / CE, database files were not always properly flushed when necessary. The file metadata was the most likely data not to have been flushed, and assertion failure 201129 (File shorter than expected) was the most likely corruption to be seen in the event of a full power outage (eg if the CE device battery runs out). This problem has been fixed. Also, the server's '-u' (use buffered IO) command line switch was ignored on Unix platforms that supported direct IO. This problem has also been fixed. ================(Build #2759 - Engineering Case #698201)================ The Server could have been unresponsive for a long period of time when a backup was starting. This has now been corrected. ================(Build #2759 - Engineering Case #696638)================ Using an ALTER TABLE statement to change the length of a string column (char, [long] varchar, [long] binary) that used default INLINE/PREFIX values, would also have explicitly set the INLINE/PREFIX values for that column if there was data in the table. This has been fixed. ================(Build #2753 - Engineering Case #697593)================ If a row was inserted while a REORGANIZE TABLE process was running, and the inserted row's primary key was greater than the highest primary key at the time the REORGANIZE started, the server could have possibly entered into an infinite loop and consumed 100% of 1 CPU without terminating. The operation could, however, be cancelled. This problem has been fixed. ================(Build #2753 - Engineering Case #697235)================ The changes for Engineering case 695216 introduced problems with certificate files (for example, supplying an ECC certificate when an RSA certificate was expected) which would have yielded the error message "An identity password must be specified", even if a password was specified. This has been fixed. In this example, the correct error message is now "An ECC certificate was supplied where an RSA certificate was expected.". ================(Build #2752 - Engineering Case #685156)================ The server may have crashed if a procedure debugger connection disconnected before a debuggee connection was able to get attached to the debugger. This has been fixed. ================(Build #2749 - Engineering Case #696816)================ Transaction log corruption could have occurred at the mirror or copy nodes of a high availability or read-only scale-out system if the following sequence of events took place: 1) The transaction log was renamed (and a new one started) at the end of a backup of the primary 2) The mirror or copy node caught up and applies some operations from new transaction log 3) The mirror or copy node lost connection with its partner or parent 4) The mirror or copy node reestablished connection with its partner or parent Note that if the mirror or copy node restarted prior to reconnecting, corruption would not have occurred. If corruption did occur, an 'invalid transaction log' assertion failure on the mirror or copy node was the most likely outcome. This problem has been fixed. Also, if a copy node (call it CN) has a parent that was not the primary (call it NP), it was possible for CN to stop applying transactions altogether. CN would have remained running as a read-only node but it would not have applied transactions until the database was manually restarted. For CN to enter this state, the following sequence of events must have occurred: 1) CN and NP become disconnected or CN just wasn't running yet 2) NP renamed the transaction log and started a new one (which happens as a result of copying actions performed at the primary) 3) CN and NP reconnect (or CN was started) In this case, CN will now display a "Recovery complete" message in the console log. ================(Build #2748 - Engineering Case #696394)================ Execution of a procedure with a very large argument list may have crashed the server. The crash would have occurred if statement needed to be copied (e.g. a remote server statement or a SELECT INTO statement), and a server worker thread ran out of stack. This has been fixed. ================(Build #2744 - Engineering Case #695774)================ Attempting to execute a grouped query with a complex ORDER BY expression could have failed with the error: "Assertion failed: 106105 Unexpected expression type ..". This would have occurred if the complex ORDER BY expression referenced a base table column from the GROUP BY clause - such as "T.X +1", where T.X is a base table column in the GROUP BY clause; and the base table column T.X was eliminated from the GROUP BY clause based on functional dependencies. This has now been corrected. ================(Build #2744 - Engineering Case #695242)================ On some systems with multiple physical processor packages (ie multiple sockets) using certain Intel x86/x64 processors, including Intel Xeon E5630, the detection of processor geometry could have been incorrect. Too few packages would have been detected but the correct number of logical processors would still have been detected (with some assigned to the incorrect package). This problem was similar to, but different from, Engineer case 666639, and has now been fixed. ================(Build #2744 - Engineering Case #695095)================ When executing a REORGANIZE TABLE statement, the server could have unnecessarily allocated an amount of memory that was proportional to the number of rows in the table. These allocations could have affect performance, and could have caused the cache to grow or, if the cache grew to its limit, could have caused a 'dynamic memory exhausted' failure. This problem has been fixed. ================(Build #2742 - Engineering Case #695495)================ When connected to an older 10.x database, creating a remote server and then attempting to utilize the remote server would likely have caused an incorrectly foreign key violation error. This problem has now been fixed. ================(Build #2738 - Engineering Case #695216)================ If the server was started with a TLS/HTTPS identity file that required a password, but none was supplied, an unhelpful error message was given ("Error parsing certificate file, error code 20763"). This has been fixed; the error message is now "An identity password must be specified". ================(Build #2737 - Engineering Case #694479)================ Attempting to use a server or the Java-based administration tools with large amounts of memory on a Linux system with kernel versions between 3.0 and 3.3 may have resulted in improper system memory calculation. This problem could have manifest itself in many ways. The server may have reported insufficient memory, or may have reported a very low value for its cache size, even when a large amount of system memory is available, e.g.: 8192K of memory used for caching Minimum cache size: 8192K, maximum cache size: 8192K The Java-based administration tools may also report the following error: Invalid maximum heap size: -Xmx0m This has been fixed. ================(Build #2735 - Engineering Case #692307)================ In blank padded and case insensitive databases using INSERT ON EXISTING UPDATE when updating a value which was logically equivalent but physically different could have failed due to constrain violations. This has been fixed. The server now does constraint checking using logical representations. ================(Build #2734 - Engineering Case #694143)================ When using the CREATE ENCRYPTED TABLE DATABASE statement on a fully encrypted database, the resulting database had all table and index pages encrypted, rather than only the pages for encrypted system tables. This has been fixed. ================(Build #2734 - Engineering Case #694137)================ There were two problems with attempting to encrypt a table using the ALTER TABLE <table_name> ENCRYPTED statement: 1. Executing the ALTER TABLE statement incorrectly succeeded on a database that did not support encrypted tables (i.e. one that is not encrypted or fully encrypted). 2. If a database was created with version 10 to support encrypted databases, but was being executed on a version 11 or later server, the same ALTER TABLE statement would have fail with error -1047 "This database does not support encrypted tables". These problems have now been fixed. In the first case, the ALTER statement will now return error -1047, and in the second case, the ALTER statement will succeed. ================(Build #2734 - Engineering Case #694002)================ In extremely rare timing dependent cases, the server could have hung when the db_property function was called. The only known case of this occurring involved mirror servers, but this problem may have affected servers not involved in mirroring. This has now been fixed. ================(Build #2734 - Engineering Case #693938)================ In very rare circumstances, the server could have become deadlocked or hung. In some cases , database mirroring would have been involved and very specific timing was required; however, the problem could have occurred in other situations and would also have required very specific timing. This problem has now been fixed. ================(Build #2732 - Engineering Case #693819)================ When the server was running with the -fips command line option (Requires that only FIPS-approved algorithms should be used for strong database and communication encryption), it was still able to start simple-encrypted databases. This has been fixed, such databases will now fail to start. ================(Build #2732 - Engineering Case #488685)================ Database recovery could have failed if the transaction log being recovered contained statements which caused checkpoints and recovery needed to be restarted. This has been fixed. ================(Build #2729 - Engineering Case #690768)================ In order to prevent the possibility of having two primary servers running at the same time when there was no connection between the two partners, the arbiter would have refused a role switch from "mirror" to "primary" if it had a connection to the current primary. If a mirroring partner server was unable to connect to its partner server after the connection dropped, it was possible for the server to be unable to decide whether to take the role of primary or mirror server. A work around for this problem was to use the syntax "ALTER DATABASE <mymirroreddb> FORCE START" to force the database to start up as primary, and should only have been used if there was no other primary server running. This problem has been fixed, and the server should now be able to decide to take a role of either "primary" or "mirror" server. ================(Build #2726 - Engineering Case #692867)================ The changes for Engineering case 677962 introduced a situation where, in rare timing dependent cases, a server could have hung when it was shutting down a database which was a high availability mirror or a copy node. This has been fixed. ================(Build #2726 - Engineering Case #692583)================ In some rare cases, the server would have hung when a connection queried another connection's LastStatement property. This has been fixed. The work-around is to not use the -zl command line option, or to turn off the RememberLastStatement server option. ================(Build #2725 - Engineering Case #692617)================ When the dbisqlc OUTPUT_FORMAT option 'ASCII' was renamed to 'TEXT' in version 11.0.0, the ability to generate the old format that dbisqlc called 'TEXT', which was fixed-width with column headers, was lost. Now, setting the OUTPUT_FORMAT to 'COLUMNS' will generate the old TEXT format. ================(Build #2724 - Engineering Case #692216)================ A problem with TDS secure logins has been corrected. ================(Build #2721 - Engineering Case #690133)================ When connected via jConnect or Open Client, retrieving the metadata of a long nvarchar or ntext column may have incorrectly indicated that the column was a long binary value. This problem has now been fixed. ================(Build #2716 - Engineering Case #691178)================ Attempting to make a Kerberos connection with a large Kerberos ticket could have failed with the error "Kerberos login failed". This would have occurred with a Kerberos ticket size approaching 8K, which was possible if the ticket was part of a large number of Active Directory groups. This has been fixed. ================(Build #2714 - Engineering Case #691036)================ When using the -sf server option to disable certain features other than "database", the CREATE DATABASE statement could have failed. This has been fixed. ================(Build #2713 - Engineering Case #690075)================ Events run on temporary connections, but those connections did not always have the correct locale information. In particular, functions such as errormsg() would have returned strings encoded in the OS character set rather than in the database character set. This problem has been fixed. ================(Build #2709 - Engineering Case #690254)================ When request logging is enabled with ALL or PLAN, the server may have crashed if the following sequence occurred: - Connection A opened a cursor that included fetching rows from a procedure - Connection B dropped the procedure used by connection A - Connection A then closed its cursor This problem has been fixed. ================(Build #2708 - Engineering Case #690114)================ Recovery could have failed if an operation in the transaction log required access to a feature that was secured on the command line via the -sf option. The operation could have entered the log, either by having the operation performed on a server where the feature was not secured, or if security was permitted, on the given connection via the -sk server option and setting the secure_feature_key option to match. The failure would have been displayed as assertion number 100904 "Failed to redo a database operation". This has now been fixed. Note, not all secured features add entries to the transaction log. For example, the READ_FILE secured feature blocks access to xp_read_file which would not get logged; however, the REMOTE_DATA_ACCESS secured feature blocks access to statements such as CREATE SERVER does get logged. ================(Build #2708 - Engineering Case #689614)================ In rare cases in a mirroring system, where a mirror server lagged far behind the primary in applying changes, it was possible for the primary and mirror server to hang. This has been fixed. ================(Build #2706 - Engineering Case #689511)================ In some extremely rare cases, the transaction log may not have been committed to disk when a COMMIT operation was performed. Also, if a transaction only modified temporary tables, it was possible that the transaction log would have been committed to disk although it didn't need to be. These problems have been fixed. ================(Build #2706 - Engineering Case #689464)================ The Property() function would have displayed negative values for the server properties 'HttpPorts' and 'HttpsPorts' when the port numbers were above 32768. This has been fixed. ================(Build #2706 - Engineering Case #689193)================ The changes for Engineering case 682512 introduced a problem where stopping a high availability primary server while it was connected to its partner (mirror) server could have resulted in the database not being able to start. Specifically, in timing dependent cases, attempting to restart the primary mirror server could fail with the "Database cannot be started -- <database name> not expecting any operations in transaction log". This has been fixed. ================(Build #2705 - Engineering Case #689315)================ When connected via jConnect or Open Client to a blank padded UTF8 database and a non-nullable char(n) value was fetchesd, the client may have experienced protocol errors if n was less than 3. This problem was introduced by the fix for Engineering case 686183 and has now been fixed. ================(Build #2702 - Engineering Case #688788)================ In rare timing dependent cases, if a mirror server was using all available workers, it was possible for the server to hang, or for a mirror database to not restart after loss of quorum. The maximum number of workers is defined by -gnh (in version 12) or by -gn (in version 11). This has been fixed. ================(Build #2702 - Engineering Case #687749)================ A query using aggregate functions may have caused a server crash if its select list contained a derived table with an outer reference to the query, and the outer reference did not appear in the queries group by list. At least one of the following conditions must also have been trun: 1) The derived table contained a procedure call in its FROM clause and the procedure argument expression contained the outer reference. 2) The derived table contained a OPENSTRING clause in its FROM clause and its value expression contained the outer reference. 3) The derived table contained another derived table and the outer reference was inside this other derived table. The below query shows an example of condition 3). select ( select V0.e from ( select T3.e from T3 where T3.e = T2.c ) V0 ) c1, max(T1.b) as c2 from T1 join T2 on T1.a = T2.c This problem has been fixed. The engine will now correctly return the error SQLE_INVALID_GROUP_SELECT, since the outer reference column has to be specified in the GROUP BY clause. Specifying the outer reference column in the GROUP BY clause (in the above example: group by T2.c) is also the work around to this problem. ================(Build #2702 - Engineering Case #686791)================ In a mirroring system, if the primary server made changes faster than the mirror server could apply them, and if the connection between the two servers was dropped, in rare timing dependent cases, the mirror server could have hung with 1 CPU at 100%. Stopping the server or the database during the 100% CPU hang would have succeeded. This has now been fixed. ================(Build #2701 - Engineering Case #686407)================ In rare cases where a primary server lost its connections to both the mirror and the arbiter servers as a checkpoint was performed, the next time the primary and mirror servers were connected and attempted to synchronize, the mirror server may have reported the error: 'Database "<name>" mirroring: database is not compatible with primary; files must be replaced' and then stop with the message: 'Database server shutdown due to incompatible files for database mirroring'. This has been fixed so as to reduce the possibility of this occurring. In rare cases this could still occur and the database running on the current primary must be manually copied or backed up to the mirror server so that the server can successfully synchronize again. Note, this extends the changes made by Engineering case 660851. ================(Build #2698 - Engineering Case #688019)================ When connected to the utility database (utility_db), if a statement that was not supported was prepared, the PREPARE may not have generated an error when it should have. This has been fixed so that the unsupported prepare now returns the error "Permission denied: you do not have permission to execute a statement of this type." ================(Build #2698 - Engineering Case #687393)================ Under very rare circumstances, a server could have crashed during backup if many connections are committing transactions at the same time. Live backups were the most likely to suffer from this problem. This has been fixed. No workaround is known. ================(Build #2698 - Engineering Case #685566)================ When a mirror or diagnostics connection to another server was attempted the "Using broadcast address of: ..." message was logged to the console when it should not have been. This has been fixed so that this message is only logged if the -z server option is used. ================(Build #2697 - Engineering Case #687998)================ While extremely rare, the server may have crashed while executing a query that referenced proxy tables. The problem has now been fixed. ================(Build #2696 - Engineering Case #687761)================ The dbisqlc utility would have reported a syntax error whenever it tried to execute a 'STOP SERVER' statement. This problem has been fixed. The statement used to be 'STOP ENGINE ...' and dbisqlc did support (and continues to support) that variant; however, it was never updated when the statement was changed to 'STOP SERVER'. ================(Build #2696 - Engineering Case #687596)================ When shutting down a server that was running as a Windows service, the server could have crashed. Although the problem was only seen when shutting down an interactive service on Windows XP by using the 'Shutdown' button on the server window, the problem was a timing issue and could have occurred when the server was shut down in other ways. The problem has been corrected. ================(Build #2695 - Engineering Case #687447)================ In rare, timing dependent cases the server could have had incorrect behaviour when a connection had at least 20 prepared statements with cached prepared statements, or at least 20 cursors open. The incorrect behaviour could have varied, and the only known symptom was incorrectly returning the error "Resource governor for 'prepared statements' exceeded", but it may also have been possible for server crashes or assertions to have occurred. This has now been fixed. ================(Build #2695 - Engineering Case #687411)================ When an ALTER DATABASE UPGRADE statement is executed, events are suspended in order to avoid having active connections while upgrading. Once upgrading is done, events are re-enabled. Running simultaneous ALTER DATABASE UPGRADE statements could have left events permanently suspended on the server. No events on any database would have been executed. This problem has been fixed. Also, when upgrading a single database, the server suspended events for all databases that were running. This was unnecessary and the server now only suspend events in the database that is being upgraded. ================(Build #2693 - Engineering Case #686202)================ For recurring scheduled events, there were several errors in how end times were computed: 1. If an end-time was specified (i.e., "BETWEEN start-time AND end-time"), then: a. Seconds were being ignored. For example, an end-time of '23:59:59' was being interpreted as '23:59:00'. b. The end-time was tested as an exclusive endpoint rather than an inclusive endpoint, contrary to the documentation of the BETWEEN ... AND clause. For example, the schedule "BETWEEN '9:00' AND '17:00' EVERY 60 MINUTES" would cause the event to fire last at 16:00, rather than 17:00. 2. If an end-time was not specified (i.e., "START TIME start-time"), the end-time for each day was implicitly being treated as '23:59:00' exclusive, instead of '23:59:59' inclusive. The combined effect of these error were that no scheduled events would fire in the minute from 23:59:00 until midnight. This has been fixed. ================(Build #2693 - Engineering Case #685149)================ When execution of a stored procedure or user defined function was cancelled by the user and an error handler within the stored procedure was invoked, an incorrect SQLCODE (0 or the error code of a different error that occurred prior to the cancel) could have been reported. An incorrect error message could also have been reported by the ERRORMSG() function. This has been fixed. ================(Build #2689 - Engineering Case #686561)================ If any of the following occurred while starting a database, the server could have crashed, although it would only occur in very rare situations: 1. An error was encountered while starting the database 2. Logs were being applied to a database at startup with -a, -ad or -ar but the -as switch was not used 3. The engine was requested to stop while the database was starting. This has now been fixed. ================(Build #2689 - Engineering Case #686409)================ If an IPv6 address that included a port number was specified in square brackets, rather than parenthesis, the server or client libraries would not have parsed it correctly. For example, if a connection string included ";HOST=[<ipv6_addr>]:<port>", the error "No IP address found for [<ipv6_addr>]:port." This has been fixed. Note, this applies to addresses in connection strings (using the LINKS or HOST parameters), the -x and -xs switches on the server, and URLs in web service procedures. ================(Build #2689 - Engineering Case #686183)================ If an application using the UTF8 character set connected via jConnect or Open Client to a blank padded non-UTF8 database and fetched a non-nullable char(n) value, then the returned value would have been blank padded to n*3 bytes. This problem has now been fixed. ================(Build #2689 - Engineering Case #685574)================ When unloading a database, ALTER INDEX ... RENAME statements were not being added to the reload.sql file when an index or unique constraint had been renamed. This has been fixed. ================(Build #2689 - Engineering Case #670470)================ If the server received an OS error for a disk write to the database file, transaction log file or temporary file, and the written size was zero, then it may have incorrectly reported a disk full error. This has been fixed. As well, disk write error messages will now print the file name and the OS error code. ================(Build #2688 - Engineering Case #686204)================ Cancelling an external environment call that was in the process of returning a large result set, could in very rare cases have caused the server to crash. This problem has now been fixed. ================(Build #2688 - Engineering Case #686203)================ Cancelling an external environment call call immediately after making the external call, could in very rare cases have caused the server to crash. This problem has now been fixed. ================(Build #2688 - Engineering Case #686036)================ Attempting to make a Remote Data Access connection to an Oracle database, using an ODBC driver other than the iAnywhere Oracle ODBC driver, could have caused the server to crash when running on a Unix system. This problem has now been fixed. ================(Build #2685 - Engineering Case #685733)================ The server could have unnecessarily consumed 100% of one CPU in certain circumstances as described below. These problems have been fixed. - In certain cases when a copy node lost its connection to its parent and then encountered a log mismatch with the parent after it reconnected, a single CPU would remain at 100% utilization indefinitely. - When cancelling a CREATE EVENT statement while processing a procedure profile (sa_procedure_profile, sa_procedure_profile_summary), a single CPU would have remained at 100% utilization until no connections were processing profile information - While waiting for connections to drop when yielding to a mirroring partner, a CPU would have remained at 100% utilization until all connections were dropped. ================(Build #2685 - Engineering Case #684891)================ If a query plan used multiple nested-loops outer joins then a cursor positioning using FETCH RELATIVE 0 may have returned the next row in the forward direction, instead of refetching the current row. This has been fixed. A possible work-around for the problem is to use an insensitive or keyset-driven cursor type. ================(Build #2684 - Engineering Case #685559)================ If a non-recurring event was run on a read-only database, or had the "FOR ALL" clause, indicating it could run on a mirror or copy node, the server could have hung with 1 CPU at 100% after the event ran. Non-recurring events are events with a SCHEDULE clause that does not specify EVERY or ON. This has been fixed. ================(Build #2682 - Engineering Case #685323)================ If the server's ports (-x) or web protocols command line option (-xs) contained certain multibyte characters, the server could have failed to start up and would have displayed the server's usage message or window. This problem has been fixed. ================(Build #2677 - Engineering Case #684340)================ When certain fatal errors occurred (particularly "dynamic memory exhausted"), the version 11.0 server attempts to create a cache.dmp file to describe the contents of cache at the time of the failure. When using an AWE cache, the server could have crashed while generating this dump file. The server had already encountered a fatal error and would need to be restarted anyway, but the crash prevented generating the dump file that would have allowed analysis of the allocation problem. This has been fixed so that the server no longer crashes when creating the cache.dmp file. Note, SQL Anywhere version 12.0 does not attempt to generate a cache.dmp file. ================(Build #2677 - Engineering Case #684335)================ An explicit or implicit cursor describe that should have failed could have caused the server to crash. An example of a describe cursor that is expected to fail is if the describe is cancelled. This has been fixed so that server no longer crashes. ================(Build #2677 - Engineering Case #682530)================ When unloading a database, the DESC clause was not being added to statements in the reload.sql file when creating Primary and Foreign Keys with a descending sequence. This has been fixed. ================(Build #2676 - Engineering Case #668109)================ Attempting to start two High Availability partner servers without state files (for example, starting them for the first time) could have, in rare timing dependent cases, failed to have one server start as the primary. If this occurred, one partner started as the mirror, and the other partner server looped indefinitely attempting to determine which role it should take. This has been fixed. Also, if a mirror server was in the middle of taking over as the primary when it was shutdown, the database shutdown could have hung until any remaining connections were disconnected. This has been fixed. ================(Build #2674 - Engineering Case #683728)================ In some situations, the server may have crashed while executing an ALTER SYNCHRONIZATION PROFILE statement with the MERGE clause. The maximum size of the new profile string was being calculated incorrectly. This has been fixed. ================(Build #2674 - Engineering Case #680767)================ When unloading a database, incorrect CREATE TEXT CONFIGURATION of external term breakers and prefilters were being generated in the reload,sql file. This has been fixed. ================(Build #2673 - Engineering Case #681963)================ If a statement similar to the statement below was used in a stored procedure, function, or trigger, a syntax error may have been incorrectly returned. The statement must have containeds both MATCH and DELETE or INSERT clauses. This has been fixed. For example: create or replace PROCEDURE test1( ) BEGIN ALTER TABLE ixddl6 ADD CONSTRAINT FK_primary FOREIGN KEY (x) REFERENCES ixddl5(pk) match unique simple on delete set null END ================(Build #2673 - Engineering Case #680779)================ When unloading a database, the ALTER TABLE statement to generate unique constraints in the reload.sql file did not include the CLUSTERED keyword for clustered unique constraints. This has now been corrected. ================(Build #2670 - Engineering Case #683385)================ If an application that was connected using Open Client or jConnect executed a Transact SQL batch that contained an undefined host variable, then there was a chance the server would have crashed. This has now been fixed so that batch will fail with a "not enough values for host variables" error. ================(Build #2669 - Engineering Case #683384)================ Additional changes have been made for Engineering case 678817. Outbound HTTP worker threads could have hung indefinitely because the server was not broadcasting a notification. ================(Build #2668 - Engineering Case #683025)================ If the connection making an http or https request was closed while the request was still executing, and that request was in turn making a request to a mirror server (for high availability or read-only scale-out), or making a request to a diagnostic server, the server could have hung or fail in some other way. This has been fixed. In high availability or read-only scale-out, if the connection to the primary or parent server was dropped just after the mirror or copy node had determined its role, the mirror or copy node could have failed to start with the errors: "database is not compatible with primary; files must be replaced" and "Database server shutdown due to incompatible files for database mirroring." This has been fixed. Note that attempting to restart the mirror or copy node after receiving this error should succeed in this case. ================(Build #2665 - Engineering Case #682512)================ If a high availability partner was shutdown while it was the primary, its partner took over as primary, and then the partner that was shutdown was restarted, it could have failed to start with the errors: "database is not compatible with primary; files must be replaced" and "Database server shutdown due to incompatible files for database mirroring." This has been fixed. ================(Build #2664 - Engineering Case #681396)================ If an Unix machine had many network interfaces (hard to say how many), starting the server may have failed. The only error message displayed was "TCPIP communication link not started". This has been fixed. ================(Build #2662 - Engineering Case #682246)================ If an application attempted to cancel a query that involved one or more proxy tables, then the cancel request would have, in some rare cases, been ignored. This problem has now been fixed. ================(Build #2662 - Engineering Case #681796)================ In a High Availability system, if the primary was processing changes faster than the mirror could apply them, it was possible that the primary could have hung. This has been fixed. ================(Build #2662 - Engineering Case #681755)================ In a high availability setup, if both partners accessed the arbiter at the same time, the arbiter could have crashed or behaved incorrectly. This has been fixed. ================(Build #2661 - Engineering Case #681398)================ The server could have crashed while using the UNLOAD statement to unload data with 'APPEND ON' to a file if that file was also being deleted by some other process. This has been fixed ================(Build #2658 - Engineering Case #676340)================ The database server could have taken longer than expected to perform a backup. During such a backup other database requests may have appeared to stall, and connections to the server may also have been impacted. This should only have occurred if the total size of database files was larger than 5 GB. This has been fixed. ================(Build #2657 - Engineering Case #680726)================ If a server identity file with an unencrypted private key was provided to the server, the server would have refused to use it, reporting "Error parsing certificate file, error code 4113". This has been fixed. Note that this problem would not be seen on Mac OS X systems. ================(Build #2656 - Engineering Case #675738)================ Some statements, like CREATE TEXT INDEX and CREATE MATERIALIZED VIEW, record the current database option values that exist at the time the statement was executed in the transaction log. The server would have returned the assertion failure error 100904 - "Invalid option '<option-name>' -- no PUBLIC setting exists", if there was not public setting for one of these options during startup recovery, or when applying changes on a mirror server. This has been fixed. ================(Build #2654 - Engineering Case #680196)================ An application that connected using jConnect version 7 would have found that certain DatabaseMetaData calls returned incorrect results or unexpected errors. These metadata problems have now been corrected. Note that a database upgrade is needed in order to get this fix. ================(Build #2653 - Engineering Case #677165)================ In specific circumstances, it was possible for the server to fail assertion 101519. This has been fixed. ================(Build #2651 - Engineering Case #678942)================ There was a small chance that some statistics could have been reported incorrectly if parallel plans were used. Statistics affected include lock count, and the various io counts. This has been fixed. ================(Build #2649 - Engineering Case #679580)================ The server could have crashed if a table was being dropped at the same time as a virtual table was being created. This has been fixed. ================(Build #2648 - Engineering Case #677430)================ In extremely rare cases, inserting data into a compressed column that had a blob index may have resulted in the blob index becoming corrupt. This could have resulted in assertion failures if the data was accessed randomly (i.e. using substr(), right(), or similar), and would also have resulted in validation failures. This has been fixed. Note: existing corrupted blob indexes must be dropped and recreated after the fix is applied. This can be done using: alter table <table> alter <column> no index alter table <table> alter <column> index ================(Build #2643 - Engineering Case #678259)================ A SQL Anywhere http procedure call may, on rare occasions, have caused the server to crash. This has been fixed. ================(Build #2643 - Engineering Case #678144)================ A high availability partner server that was under heavy load could have hang when a thread deadlock occurred. This has been fixed so that a request will now receive the error: "All threads are blocked". ================(Build #2642 - Engineering Case #676210)================ Execution of a SET REMOTE OPTION would have failed if the value of the setting was larger then 256 bytes. This was due to the schema of the ISYSREMOTEOPTION table which has a 255 byte limit on the length of the settings column. The server has been changed to provide a more appropriate error message. ================(Build #2640 - Engineering Case #676996)================ The database server, running a database in read-only mode, could have crashed during database validation. This would only have occurred in very rare circumstances. This has been fixed. ================(Build #2639 - Engineering Case #677515)================ Running REORGANIZE TABLE on a table with foreign key indexes when the database was under heavy update/delete load, had a chance of corrupting the table. Specifically, the indexes on the table would have contained more values then the table itself. This has been fixed. ================(Build #2639 - Engineering Case #677251)================ If an embedded SQL application or a stored procedure first opened a READ ONLY cursor on a simple SELECT query qualifying for optimizer bypass, and later opened an UPDATE cursor for the same query, a positioned update to the second cursor could have failed with SQLCODE -192 ("Update operation attempted on non-updatable query"). This has been fixed. For the error to occur in version 11, the first cursor would need to be explicitly declared FOR READ ONLY, because FOR UPDATE is the default (c.f. documentation for DECLARE CURSOR statement). In version 12.0.0 and later, cursor updatability depends upon cursor type (c.f. documentation for SELECT and PREPARE statements) but defaults to FOR READ ONLY for ESQL. ================(Build #2639 - Engineering Case #671017)================ In a certain virtual machine implementation, CPU topology detection (which is performed at server startup) could spin consuming 100% of a single logical CPU. The VM software had bugs which reported CPU information to the guest operating system in a manner that does not meet Intel's specifications. Changes have now been made so that SQL Anywhere can tolerate the bugs in the VM software without affecting correct CPU detection in other nvironments. ================(Build #2638 - Engineering Case #677962)================ When a database was shut down (for example, as part of server shutdown) and the database was a high availability mirror or a read-only scale-out copy node, the server could have hung in rare timing dependent cases. If the server was hung due to this problem, there would have been messages like the following in the server console: A write failed with error code: (6), The handle is invalid. Fatal error: disk full when writing to "???" This has been fixed. ================(Build #2637 - Engineering Case #677327)================ In some cases, SQL Anywhere HTTP procedures and the HTTP server would have failed to process received chunked mode transfer encoded data when the chunk length meta-data contained leading zeros. This has been fixed. ================(Build #2634 - Engineering Case #675326)================ When run on a Windows Mobile device, the server could have crashed if the "Authentication parameters" field in an existing "SYNCHRONIZATION PROFILE" was modified. This has now been fixed. ================(Build #2634 - Engineering Case #672573)================ Using either mixed case or upper case when specifying the ".dll" portion of the assembly name in a CLR external environment procedure, could have caused the external environment to fail to run the specified method within the assembly. For example, an external name clause like: external name 'MyTest.DLL::MyNameSpace.MyTestClass.MyMethod() int' would have failed to execute MyNameSpace.MyTestClass.MyMethod, but an external name clause like: external name 'MyTest.dll::MyNameSpace.MyTestClass.MyMethod() int' would successfully find and execute MyMethod. This problem has been fixed. Note that a workaround is to simply lower case the ".dll" portion of the assembly name. ================(Build #2633 - Engineering Case #676332)================ UPDATE statements with complex table expressions may have caused a server crash. At least the following conditions must have been true: 1. The UPDATE statement is using the syntax: UPDATE [ row-limitation ] table-expression [, ...] ] SET set-item[, ...] [ WHERE search-condition ] [ ORDER BY expression [ ASC | DESC ] , ...] [ OPTION( query-hint, ... ) ] 2. The statement must have had at least two query blocks (e.g., a derived table, subselect, subqueries). 3. The 'table expression' contained a Left Outer Join at the root of the tree 4. The Left Outer Join was a redundant join. Removing the Left Outer Join from the original statement generates an equivalent statement. This has been fixed. For example: update LP join PR on PR.PR1 = LP.LP1 join LS on LS.LS2 = PR.PR2 join SC on SC.SC1 = LS.LS2 left outer join PC on PC.PC1 = LS.LS1 set LP.LP2 = LS.LS1 where PR.PR3 = 10 and LS.LS3 = 20 and SC.SC2 = 30 and SC.SC2 = (select max(id) from product ) ================(Build #2631 - Engineering Case #674917)================ Under rare conditions, the server could have crashed when processing queries with intra-query parallelism. This has been fixed. The crash can be worked around by disabling intra-query parallelism by setting the database option MAX_QUERY_TASKS=1. ================(Build #2630 - Engineering Case #676007)================ The server would have failed to rename the request log correctly if the option RequestLogNumFiles was set to 1. This has been fixed. ================(Build #2628 - Engineering Case #644908)================ After an ALTER TABLE statement, some views may have been incorrectly marked as INVALID. The problem only occurred for views in which the altered table occurs multiple times in the logical expansion of the view definition. This has been fixed. ================(Build #2627 - Engineering Case #671906)================ When processing an UPDATE statement, the server could have constructed erroneous values for the OLD table that would have been created for AFTER ROW or AFTER STATEMENT triggers. This could have lead to incorrect results if the AFTER trigger referenced these values, or could have resulted in the statement failing with an SQL error. The problem would have occurred if and only if the following conditions hold: 1) The UPDATE statement modifies a table that had a primary key, UNIQUE constraint, or unique index. 2) The UPDATE statement modified a column included in the primary key, UNIQUE constraint, or unique index, such that the new value matched a value already existing in the index. 3) The modified table had an AFTER ROW or AFTER STATEMENT trigger This problem has been corrected. ================(Build #2626 - Engineering Case #674782)================ If a server involved in a high availability mirroring system had active TLS connections, the server may have hung indefinitely due to a thread deadlock. This has been fixed. ================(Build #2626 - Engineering Case #674753)================ In rare, timing depending cases, a primary, mirror or copy node server could have hung while shutting down. This has been fixed. ================(Build #2626 - Engineering Case #674704)================ If a directory access server was queried, and one of the files was owned by a user that did not exist on the system where the server was running, then the server would have crashed. This problem has now been fixed. ================(Build #2626 - Engineering Case #674537)================ Simple INSERT statements referencing a table with an article defined with a non-empty WHERE and/or SUBSCRIBE BY clause could have occasionally failed with a "Column not found" error for the column referenced in either WHERE or SUBSCRIBE BY clause. Re-execution of the same INSERT would, in most cases, have succeeded with no error. This has been fixed. ================(Build #2625 - Engineering Case #674550)================ Calling the system function WRITE_CLIENT_FILE could have incorrectly resulted in the error "Client library reported a permissions error accessing object ('<FILENAME>') during transfer" if there were multiple READ_CLIENT_FILE or WRITE_CLIENT_FILE calls in a batch, procedure, or function referring to the same client file name. This could have happened if the client executed a batch or procedure, which in turn called other functions or procedures which ended up doing multiple READ_CLIENT_FILE or WRITE_CLIENT_FILE calls during the execution of the batch or procedure that was executed by the client. This has been fixed by explicitly closing the file at the end of the function call. The file was previously closed at the end of the request. ================(Build #2624 - Engineering Case #674582)================ The server would have crashed when inserting several values lower then MIN_DBL (about 1e-306, which is the smallest double which can be stored in normalised format) which still can be stored using denormalized double values. This was fixes by forcing all of the denormal double values to be rounded down to zero. ================(Build #2624 - Engineering Case #674320)================ After a MANUAL or AUTO REFRESH text index was renamed, it may not have been found by subsequent statements. This has been fixed. Note that restarting the database server eliminates the problem ================(Build #2619 - Engineering Case #673844)================ The server may have crashed while attempting to log a deadlock error between connections. For this to have happened, the Log_deadlocks option needed to have been set to 'on', and at least one of the connections that was participating in the deadlock needed to be executing a query that had a parallel plan. There are two possible workarounds: 1) Turn off intra-query parallelism by setting the Max_query_tasks option to 1, or 2) Set the Log_deadlocks option to 'off' This problem has been fixed. ================(Build #2619 - Engineering Case #673212)================ 1) If one TCP/IP address for one partner server in the partner/mirror/primary server connection string in the MIRROR SERVER or -xp configuration was correct, but the TCP/IP address for the other mirror partner server was incorrect, it was possible for the primary server to have skipped performing checkpoints indefinitely. This could only occur with the incorrect TCP/IP address configuration and if the mirror servers contained the fix for Engineering issue 660851. This has been fixed so that the primary server checkpoints normally. 2) If a High Availability or read-only scale-out server failed to connect to another server, there may not have been any indication of the failed connect. This has been fixed by logging a message to the console for each failed connection. 3) A High Availability or read-only scale-out server may have displayed the message "... recovery n% complete" where n was a number less than zero or much greater than 100. This has been fixed. ================(Build #2618 - Engineering Case #675686)================ The server may have failed assertion 101412 - "Page number on pages does not match page requested", if the database/connection option 'chained' was set to 'off'. This has been fixed. ================(Build #2618 - Engineering Case #673173)================ The fix for Engineering case 661622 missed the situation where a subselect that referenced two tables from the main query block, and was equated to a constant, could also have caused the server to fail an assertion or crash . For example: Select * from T1, T2 where 10 = (select e1 from R where p(R,T1, T2) ) and .. This has now been fixed. ================(Build #2618 - Engineering Case #672858)================ The server could have crashed if a table was being dropped at the same time as a proxy table was being created. This has been fixed. ================(Build #2618 - Engineering Case #647802)================ The server may have failed assertion 106104 "field unexpected during compilation" for queries containing correlated subselects in the WHERE clause. The WHERE subselect predicate must have been of the form "T.X = (subselect referencing R.Y)" where R.Y was an outer reference. This has now been fixed. ================(Build #2617 - Engineering Case #667001)================ If a stored procedure or a user defined function with the hidden definition appeared on the stack when an error occurred, subsequent call to the TRACEBACK function could have returned the statements from the hidden definition. This has been fixed so that the output of the TRACEBACK function now contains the string '<hidden>' instead of the statements from the hidden procedures or user defined functions. ================(Build #2616 - Engineering Case #672749)================ If the two partner databases in a mirroring configuration were both starting up at the same time, while the servers that were hosting them were attempting to shut down, both servers could have hung. This problem has been fixed. ================(Build #2614 - Engineering Case #672077)================ Executing a query that joined two or more External Environment result sets could have caused the server to crash if the join resulted in a very large result set. This problem has now been fixed. ================(Build #2614 - Engineering Case #672076)================ When inserting a string literal value into a time or timestamp column of a proxy table, if the string literal contained more than 3 digits of precision within the fractional seconds portion of the time/timestamp value, then the fractional seconds would have been truncated to 3 digits of precision. This problem has now been fixed. Note that this fix only applies to ODBC based Remote Data Access servers. The fractional seconds precision will still be truncated to 3 digits of precision for JDBC based Remote Data Access servers. ================(Build #2614 - Engineering Case #671911)================ The system function OPENSTRING allows a text file to be parsed and interpreted as a relational table. The schema for OPENSTRING can be explicitly specified or can be provided by means of an existing database table. If a remote (IQ or other proxy) table was used to specify the OPENSTRING schema then the server can behave erratically, including crashing. This problem has now been resolved. ================(Build #2613 - Engineering Case #671711)================ The changes for Engineering case 624047 could have caused a server running high availability mirroring, or a read-only scale-out copy node, to fail assertion 200131. The failure was timing dependent, and required accessing an empty table with an index from a read-only connection. This has been fixed. ================(Build #2612 - Engineering Case #659138)================ In exceptionally rare cases, the server may have crashed if two procedure debuggers had been attached to a database and one of them disconnected while a new connect request for a user to debug was being executed. This has been fixed. ================(Build #2612 - Engineering Case #655524)================ A MERGE statement on a table that had a column with DEFAULT AUTOINCREMENT would have increased the autoincrement value for every matching row independently of whether the value had already been used for an INSERT or not. This behaviour has been improved so that the server only generates a new autoincrement value if the matching branch is an INSERT and the value will be used. ================(Build #2610 - Engineering Case #670990)================ If the number(*) function was used in the VALUES clause of an INSERT statement, then the server would have returned a non-fatal assertion error 106103. This has been fixed so that the correct error is now returned. ================(Build #2610 - Engineering Case #670838)================ In rare timing dependent cases, if a High Availability mirror server was in the process of taking over as the primary, it could have failed. The 201120 assertion failure could have been logged to the console log. This problem could only have affected servers containing the fix for Engineering issue 663964. This has been fixed. ================(Build #2609 - Engineering Case #670486)================ In exceptionally rare cases, the server could have crashed when executing a non-parallel query that contains a hash join. The crash would only have occurred if all of the following conditions were true: - the probe input of the hash join had already consumed a lot of memory for hash tables - a child of the hash join returned an error - a hash based parent query node of the hash join needed to allocate memory for the hash table and is restricted by the memory governor, so that it had to acquire memory from other hash based query nodes. This problem has been fixed. ================(Build #2609 - Engineering Case #670403)================ When a database was shut down (for example, as part of server shutdown) and the database was a high availability mirror or a read-only scale-out copy node, the server could have hung in rare timing dependent cases. If the server was hung due to this problem, there would have been messages like the following in the server console: A write failed with error code: (6), The handle is invalid. Fatal error: disk full when writing to "???" This has been fixed. ================(Build #2609 - Engineering Case #669965)================ A database server using web services could have crashed in very rare situations when an HTTP connection was shutdown. This has been fixed. ================(Build #2609 - Engineering Case #669448)================ When performing a backward index scan (a rare occurrence) while there were heavy concurrent updates to the index, there was a small chance that the server could have made a comparison to a random value with unpredictable results. This has been fixed. ================(Build #2607 - Engineering Case #670202)================ In rare timing dependent cases, a primary, mirror or copy node server could have crashed or hung. Also in rare timing dependent cases, partner servers starting for the first time could have fail to have chosen a primary after the changes for Engineering case 663964. These problems have been fixed. ================(Build #2607 - Engineering Case #669633)================ The SQL Anywhere Server provides a system procedure sa_refresh_materialized_views() that can be used to refresh all currently stale materialized views. Invoking the procedure with an argument value of 0 would have caused an error to be reported if at least one of the materialized views failed to be refreshed. This procedure is invoked by the reload script generated by the Unload utility when executed with the "-g" command line switch. This problem has now been resolved. ================(Build #2606 - Engineering Case #669431)================ When attempting to cancel a Remote Data Access request to an ODBC based remote server, there was a very small chance that the server would have become unresponsive if all three of the following was true: - the local server was running on a Windows based system - the local server had a restricted (or small) number of CPUs or cores (either due to the limitations of the server machine or VM, or as a result of using the -gt or -gtc command line option) - the remote server was not defined to utilize the new "driver=SQL Anywhere Native" feature This problem has now been fixed. ================(Build #2604 - Engineering Case #668989)================ In rare timing dependent cases, a transaction which was successfully committed on a primary server could have been lost. In order for there to have been a chance of this occurring, all of the following needed to be true: - the application was connected to a primary server that lost quorum (the server lost the connection to both the mirror and arbiter servers) - the application stayed connected to this server (the old primary server) even though the network connection to other servers dropped - the application was in the middle of committing a transaction between the time that the old primary server lost its connection to the mirror and arbiter server, and when the old primary server restarted as the new mirror server because it lost quorum - the old mirror server took over as the new primary (the mirror server must have been able to connect to the arbiter server for this to occur) This has been fixed so that the application may now receive the new error for this situation, "The transaction may not be committed because the primary server lost quorum." ================(Build #2602 - Engineering Case #663056)================ In exceptional rare situations the server could have crashed or failed assertions 106808, 100913, or 111706 if very long property values are queried. This has been fixed by truncating property values to the max varchar length of 32000 bytes. ================(Build #2600 - Engineering Case #659608)================ When making an external environment call, if the external environment procedure made a server side request that ended up leaving a cursor on a temporary table open, then the server could have crashed when the connection was closed. This problem has now been fixed. ================(Build #2599 - Engineering Case #667901)================ If an application connected via jConnect and then subsequently attempted to use the {} JDBC escape sequence when making a stored procedure call, then there was a chance the server would have returned an incorrect "variable @p0 not found" error at the time the stored procedure statement or result set was closed. This problem has now been fixed. ================(Build #2599 - Engineering Case #667900)================ If the Transact-SQL ROWCOUNT option was used to limit the number of rows returned by a cursor, the cursor may have skipped the first row in the result set in some cases. This incorrect behaviour only occurred for queries in which optimization was bypassed, and the plan contained a SortTopN operator, rather than a RowLimit operator. This incorrect behaviour was introduced as part of the fix for Engineer case 653706, and has now been fixed. ================(Build #2599 - Engineering Case #667686)================ If an application attempted to cancel or drop a connection that was in the process of making a connection-scoped external environment call, then there was a very small chance the server would have crashed. This problem has now been fixed. ================(Build #2599 - Engineering Case #660691)================ When accessing a directory or file using a Directory Access Server, if the name of the directory or file contained a multi-byte character where one of the bytes in the character was 0x5C, then the Directory Access Server would have failed to find the directory or file. This problem has now been fixed. ================(Build #2598 - Engineering Case #667314)================ If more than one connection attempted to install or remove Java external environment objects at the same time, then there was a chance the server would have crashed or failed assertions. This problem has now been fixed. ================(Build #2596 - Engineering Case #666731)================ Under rare circumstances, the server could have hung when values for WHERE or SUBSCRIBE BY clauses were being changed in a table with an article. This has been fixed. This fix covers additional cases that were not covered by Engineering case 654952. ================(Build #2595 - Engineering Case #667142)================ In very rare timing dependent cases, the server could have crashed when a database was stopping. Also in rare cases, it was possible for an automatically started database to not automatically stop when there where no longer any connections to it. Both of these problems have now been fixed. ================(Build #2593 - Engineering Case #661440)================ In rare cases, the server may have crashed while performing DDL and DML operations concurrently. This has been fixed. ================(Build #2592 - Engineering Case #666639)================ The detection of processor geometry (number of physical processors, cores and threads) was incorrect for certain Intel x86/x64 processors, including the Intel Xeon E5405. The server would have detected all cores and threads as belonging to a single physical processor. This problem has been corrected. ================(Build #2592 - Engineering Case #660211)================ In rare circumstances, calling the system procedures sa_locks, sa_describe_shapefile, st_geometry_dump, sa_list_cursors, or sa_mirror_server_status, could have caused the server to crash, or could have caused unpredictable behaviour. The problem was more likely to have occurred when small cache sizes were used. This problem has been fixed. ================(Build #2589 - Engineering Case #665657)================ The problems described here affect Windows CE 5.x kernels only. Note that Windows Mobile 6 platforms use the Windows CE 5.x kernel. With version 11.x, the server was not able to create a cache larger than 32MB. Attempting to do so would have caused the error "Not enough memory". With version 12.x, the server would have automatically and erroneously restricted the cache size to a size smaller than 32MB. The default maximum cache size was erroneously restricted to a value less than 32MB. The "percentage" notation for cache sizes (eg, "-c 50p") erroneously based the percentage on a value that was less than 32MB, rather than the total system memory as documented. These problems have been corrected. ================(Build #2589 - Engineering Case #665630)================ Upgrading a database that had been created with the -dba switch (to set the DBA username and password) could have failed. This has been fixed. ================(Build #2589 - Engineering Case #635353)================ The server could have hung when a connection disconnected, or was dropped. This was more likely to have occurred if the server was under heavy load. This has been fixed. ================(Build #2588 - Engineering Case #665799)================ On Windows systems, a minidump might not have been generated under certain circumstances. This has been fixed. ================(Build #2587 - Engineering Case #665684)================ If an application attempted to establish a Remote Data Access connection to an ASE server, and that connection request failed over to a different ASE server, then the Remote Data Access connection request would have failed. This problem has now been fixed. ================(Build #2587 - Engineering Case #665524)================ An exclusive table lock on a non-transactional global shared temporary table could have caused the server to crash on subsequent INSERT, UPDATE or DELETE statements. This has been fixed. All conditions must have been met (non-transactional, shared global temp table, and LOCK TABLE WITH EXCLUSIVE) for the crash to have occurred. If any of these three can be relaxed, the crash will be avoided. ================(Build #2587 - Engineering Case #665522)================ The attachment specified by the attachname parameter of the system procedure xp_sendmail() may not have been received properly by the recipient's mail client. This has been fixed. ================(Build #2587 - Engineering Case #661066)================ If a range of values was supplied for the TCP/IP option ClientPort, connection attempts may have been slow if the server was not found, or if multiple hosts were supplied for the Host option. This has been fixed. ================(Build #2586 - Engineering Case #665325)================ When validating a database using the VALIDATE statement or the Validation utility (dbvalid), the operation could not have been cancelled. This has been fixed. ================(Build #2586 - Engineering Case #665158)================ For servers that support ECC TLS, support has now been added for RFC 4492 and 256-bit AES ECC cipher suites as well, in addition to the Draft 3 128-bit AES ECC cipher suite they previously supported. ================(Build #2586 - Engineering Case #661622)================ Execution of a query with a subselect predicate correlated on two different tables from the main query block may have caused an assertion failure in the server. This has now been fixed For example: Select * from T1, T2 where T1.X = (select e1 from R where p(R,T1, T2) ) and .. The predicate "T1.X = (select e1 from R where p(R,T1, T2) )" has a subselect and references both tables T1 and T2 from the main query block. ================(Build #2584 - Engineering Case #664865)================ In rare timing dependent cases, after a primary server relinquished ownership and had became the mirror server, it may not have received log page updates from the new primary. A high availability primary server relinquishes ownership when the partner is preferred, or due to a ALTER DATABASE SET PARTNER FAILOVER statement. If this problem occurred, restarting the mirror server would have caused it to start receiving log updates again. This has been fixed. ================(Build #2584 - Engineering Case #664695)================ In rare situations, the server could have erroneously reported the error "Not enough memory" at startup. This problem has been corrected. ================(Build #2584 - Engineering Case #661036)================ Activity executing on the utility_db could have caused a crash, memory corruption, or other unpredictable behaviour, if the cache were to shrink at the same time. This problem has been fixed. ================(Build #2583 - Engineering Case #664348)================ In very rare timing dependent cases, the server could have crashed or hung on shutdown if there were active client requests during shutdown. The databases would have already been stopped before the failure, so there was no chance of data loss. This has been fixed. ================(Build #2583 - Engineering Case #664292)================ In rare situations, the server could have crashed if a log truncation or rename (dbbackup -x or -xo or -r) took place while the server was processing a large number of transactions, especially long-running transactions. This has been fixed. No workaround for this problem is known, except to avoid performing log truncation or renaming when the server is handling large numbers of inserts, updates or deletes. ================(Build #2583 - Engineering Case #664247)================ If the system procedure sa_get_user_status() was run on a database with an extremely high number of user definitions, the procedure would have blocked DDL statements and could not have been cancelled until its result had been materialized. This has been fixed. ================(Build #2579 - Engineering Case #663459)================ Attempting to autostart a database server on Windows CE when one was already running was incorrectly giving the error: "Unable to start specified database: server exit code -11728" (where the number could vary). This has been fixed to return the correct error: "Database server already running" Note that on Windows CE only one database server can be running at a time, even if when attempting to start a second server with a different name. ================(Build #2576 - Engineering Case #663283)================ The server may have chosen less that optimal plans for queries with predicates of the form 'T.X=(unknown expression)' if an index on T(X) existed. The '(unknown expression)' could have been, for example, a variable whose value was not used for queries inside the procedures, or could have been a complex expression (i.e. "R.Y+1"). This has now been fixed. ================(Build #2574 - Engineering Case #662452)================ Attempting to start a connection-scoped external environment, and then canceling the start request before the external environment completed the startup process, could have caused the server to crash. This problem has now been fixed. ================(Build #2572 - Engineering Case #661633)================ Execution of an "UPDATE ... PUBLICATION ... WHERE .." statement with a complex WHERE clause may have caused the server to crash. This has been fixed. ================(Build #2572 - Engineering Case #660851)================ When a primary server lost its connections to both the mirror and arbiter servers as a checkpoint was performed, the database on the primary may not have been recoverable. Typically, it would fail assertion 100904. This has been fixed. Similarly, in cases where a primary server lost its connections to both the mirror and arbiter servers as a checkpoint was performed, the next time the primary and mirror servers were connected and attempt to synchronize, the mirror server may have in rare situations reported "Database "<name>" mirroring: database is not compatible with primary; files must be replaced" and then stop with the message "Database server shutdown due to incompatible files for database mirroring". This has been fixed to reduce the possibility of this occurring. It is possible for this to still occur, so then the database running on the current primary must be manually copied or backed up to the mirror server so that the server can successfully synchronize again. The primary server could have hung, again in rare situations, if only one of the two connections between it and the mirror server was dropped, for example due to a liveness timeout. This has been fixed. When the mirror server was becoming the primary server there was a small possibility it could have hung after reporting it was starting a checkpoint and then reporting it was recovering. This has been fixed. ================(Build #2571 - Engineering Case #661453)================ If the distance parameter of the proximity search condition contained letters, the server could have silently failed, and returned some result, instead of reporting an error. This has been fixed. For example, the following query would not report an error and would behave as if the full text query was 'apple NEAR[2] oranges': SELECT * FROM t CONTAINS( 'apple NEAR[ 2b ] oranges' ) Note that the following query was correctly reporting an error: SELECT * FROM t CONTAINS( 'apple NEAR[ b ] oranges' ) ================(Build #2569 - Engineering Case #662466)================ Some potential security issues have been fixed. ================(Build #2569 - Engineering Case #660834)================ The server could have hung for thirty seconds or more when it was establishing a mirror or diagnostics connection to another server. This has been fixed. ================(Build #2569 - Engineering Case #660629)================ When connected to an ASE 15.5 server and attempting to make a remote request to SQL Anywhere, there was a chance the request would have failed with an "unkown token 35" error. This problem has now been fixed. Note that this problem only affected remote requests from ASE to SQL Anywhere. The problem did not affect making remote requests from SQL Anywhere to ASE via Remote Data Access. ================(Build #2569 - Engineering Case #660446)================ Performing a backup with a TRANSACTION LOG RENAME would have caused read-only connections to the database on the mirror server to be dropped. This has been fixed. ================(Build #2569 - Engineering Case #659115)================ The server may have crashed if a query block contained an alias definition and the expression of the alias used columns that could be folded as a constant, (in the example below, alias v011 can be folded as a constant if column T2.a2 was created as NOT NULL), and the alias name was used in a subselect of the query block and in the GROUP BY clause of the query block. For example: select if T2.a2 is null then 99999 else 11111 endif as v011, (select count(*) from T1 where T1.a1 = v011) as c from T2,T3 where T2.a2 = T3.a3 group by v011 This has been fixed. ================(Build #2569 - Engineering Case #658330)================ Execution of an INSERT ON EXISTING UPDATE statement, with CASCADE as the foreign key update option, would have resulted in a foreign key constraint violation error when updating values which were logically the same, but had different physical representation. For example, in case insensitive database changing 'EMPLOYEE' to 'employee'. This has been fixed. ================(Build #2568 - Engineering Case #660248)================ If an application connected via jConnect or Open Client and made an external environment call that returned a result set, then the server may have crashed. This problem has now been fixed. ================(Build #2567 - Engineering Case #660235)================ On Windows Vista and later operating systems, whenever a new server executable had to be launched in order to autostart a database, launching the executable may have failed when a relative path to the server executable was specified. For example, dbspawn mybin\dbsrv12.exe -n myserver my.db, or using "...;start=mybin\dbsrv12.exe..." in a connection string, could have fail to launch the server executable. This problem has been fixed. ================(Build #2567 - Engineering Case #660194)================ Execution of a query on a Directory Access proxy table with a WHERE clause that contained a predicate of the form "file_name = variable", may have sometimes run very slowly while running very quickly most other times. This problem has now been fixed such that the query performance is now consistently fast from one run to the next. ================(Build #2567 - Engineering Case #660057)================ If a foreign key was created with both MATCH and CHECK ON COMMIT clauses, and the database subsequently required recovery, recovery would have failed when replaying the statement from the transaction log. This has been fixed. ================(Build #2567 - Engineering Case #660024)================ In version 10, web service requests sent to a server acting as mirror would have been redirected to the same port on the primary server. Starting with version 11, this redirection no longer happens. In version 12, the documentation was updated to reflect the change in behavior. No change in behavior from earlier builds of version 11 should be seen with this software change. ================(Build #2567 - Engineering Case #652949)================ The trigger operation condition 'UPDATE( {column-name} )' did not return TRUE if the column value had been changed by a previously running BEFORE UPDATE row-level trigger only. This has been fixed. ================(Build #2566 - Engineering Case #659639)================ When making a Java external environment call, if the stored procedure had an argument of type char (note that this is a single char value rather than a java.lang.String), and a NULL value was passed in for the char argument, then the server would have failed the request with a Java NullPointerException. It should be noted that the Java VM would have continued to run in this situation and the connection was still able to make subsequent Java external environment calls. This problem has now been fixed such that passing a NULL char value to a Java external environment call will result in a char with zero value being passed down to the Java method. Again, it should be noted that this problem does not affect passing NULL string values to java stored procedures. ================(Build #2566 - Engineering Case #659631)================ If an application enlisted a connection within a DTC transaction and then subsequently attempted to perform a DTC commit on the transaction after explicitly unenlisting it first, then the application would have hung until the server was shut down. This problem has now been fixed and the commit request will now immediately fail as expected. ================(Build #2566 - Engineering Case #613299)================ Queries involving indexes could return incorrect results, and using tools such as the Validate Database Wizard in Sybase Central, or the Validation utility, could have reported index corruption when there was in fact none. For this to have occurred, the index must not have been unique and there must be many consecutive rows with the same indexed value. This has been fixed. ================(Build #2564 - Engineering Case #658985)================ Unexpected deadlocks could have occurred when using the UPDLOCK hint at isolation level 3. For example, if two transactions issued the statements SELECT t.c FROM t WITH (UPDLOCK) WHERE t.pk = 1 UPDATE t SET c = 2 WHERE t.pk = 1 concurrently at isolation level 3, a deadlock would have occurred if both connections managed to issue the SELECT before either issued the UPDATE. This has been fixed. ================(Build #2564 - Engineering Case #658849)================ If an application on a Unix system attempted to make a TCP/IP connection to a server that was not running, the connection attempt may have failed with error code -832 "Found server but communication error occurred". This has been fixed, the correct error code should be -100 "Database server not found". ================(Build #2563 - Engineering Case #658114)================ The server would have crashed if a SELECT statement useed the FOR XML EXPLICIT clause, and a null value was used for the CDATA directive. This has been fixed ================(Build #2563 - Engineering Case #657823)================ The fix for Engineering case 620136 did not handle the situation where there was no declared Primary Key in the primary table but there were table, or column, (not nullable) Unique Constraints that permit the addition of foreign keys. This problem has been corrected. ================(Build #2563 - Engineering Case #656998)================ Remote queries with many aliases in grouped derived tables may have taken a long time to execute. This has been fixed. ================(Build #2563 - Engineering Case #647077)================ When run on Mac OS X systems, the server would have exited with the error "Failed to become daemon" if both the -um and -ud command line options were specified. This was due to a limitation in the OS X GUI infrastructure. This has been fixed. The -um flag is now ignored if -ud is specified. A workaround is to use dbspawn instead of -ud. ================(Build #2562 - Engineering Case #657621)================ If a server (S2) acting as mirror saw a dropped connection to the primary server (S1) after a temporary network outage, it could have attempted to become primary while S1 was still running. S2 would then have failed during startup because S1 still owned the alternate server name for the database. This error would also have caused S2 to shut down. If S1 needed to restart, it would have been unable to take ownership of the database because S2 was unavailable and the arbiter's state had been updated to indicate that S2 was the owner. Also, when a server acting as primary (S1) accepted an inbound connection from the mirror (S2), S1 attempted to make an asynchronous outbound connection to S2 if one did not already exist. If this connection attempt failed, S2 would have failed to receive updates from S1. These problems have now been fixed. ================(Build #2561 - Engineering Case #658302)================ If many contiguous index entries were removed from an index with no intervening inserts, concurrent snapshot transactions could have seen incorrect results, and in rare circumstances, foreign rows could have been added without matching primary rows. This has been fixed. ================(Build #2561 - Engineering Case #658121)================ On some Windows machines, attempting to make a TCP connection to a Personal Server on the same machine may have failed. This has been fixed. ================(Build #2561 - Engineering Case #657987)================ The server could have crashed, or failed assertion 200114, when processing a LIKE predicate. This has been fixed. ================(Build #2560 - Engineering Case #634900)================ The server may have become deadlocked while acquiring shared latches. This has now been corrected. ================(Build #2559 - Engineering Case #655956)================ If a server was handling a large number of requests, and a large number of those requests made external environment calls that resulted in server side calls coming back into the server and those server side calls were similar in nature, then there was a chance that the server would have crashed when one or more of the connections making external environment calls closed. This problem has now been fixed. ================(Build #2558 - Engineering Case #657586)================ If a call was made to the Java external environment, and the stored procedure had an argument of type tinyint and a NULL value was passed in for the tinyint argument, then the server would have failed the request with a NullPointerException. It should be noted that the Java VM would continue to run in this situation and the connection was still able to make subsequent Java external environment calls. This problem has now been fixed such that passing a NULL tinyint value to a Java external environment call will result in a byte with zero value being passed down to the Java method. ================(Build #2558 - Engineering Case #657520)================ In very rare cases, the server asserts with assertion error 102300 "File associated with given page id is invalid or not open" if request level debugging is turned on and includes plan logging and there are schema changes around. This has been fixed. To work around the problem plan caching can be turned off (option Max_plans_cached = 0) or plan logging can be turned off (switch -zr without "plan" and "all"). ================(Build #2558 - Engineering Case #654801)================ The SQL Anywhere Optimizer may have incorrectly pruned, without costing, optimal plans during query optimization. This has been fixed. This incorrect pruning would most probably have affected the final execution plans for complex, but inexpensive (i.e., the optimal plan has a small runtime) queries. ================(Build #2556 - Engineering Case #656264)================ When connected to a database that had the same character set as the OS, and a query like the following was executed: SELECT ... FROM dirtab WHERE file_name = '...' where dirtab was a directory access table and the file_name string literal contained non-ASCII characters, there was a chance the server would have crashed. This problem has now been fixed. ================(Build #2555 - Engineering Case #656847)================ If a derived table was joined with the rest of the query using a Join Nested Loops operator, the performance of the query may have suffered when the derived table had to be computed many times due to many rows generated by the left hand side of the Join Nested Loops. The optimizer was choosing such a plan if the estimated number of rows of the left hand side was very small. If this estimation was wrong (e.g., the optimizer estimates one row for the left hand side but in reality the left hand side produces 1,000 rows), the derived table was computed many, many times during execution. This has been fixed so that the optimizer considers only Join Hash or Join Sort Merge operators for the derived tables if it is correct to do so. ================(Build #2554 - Engineering Case #656650)================ The system procedure sa_db_list() did not validate its database id parameter if the value was a positive integer. This would have resulted in a single row result set containing the value provided. Now, if the value is not a valid database id, the procedure will return an empty result set. ================(Build #2554 - Engineering Case #655981)================ Values for the ApproximateCPUTime property is never expected to decrease between calls, as it represents an estimate of accumulated CPU time for a connection. However, for connections that had accumulated approximately 1000 seconds of CPU time, the counter could have periodically receded by approximately 400 seconds. ================(Build #2552 - Engineering Case #656272)================ The INSERT ON EXISTING SKIP statement did not report the correct number of inserted and updated rows using @@rowcount and sqlcount. This has now been corrected. ================(Build #2552 - Engineering Case #655749)================ Execution of an INSERT ... ON EXISTING SKIP statement did not report the correct number of inserted and updated rows using @@rowcount and sqlcount. This has been fixed ================(Build #2551 - Engineering Case #655972)================ The fix for Engineering case 636018 missed a case, which has now been corrected. Description of case 636018: Queries involving indexes containing long values could have returned incorrect results. Index corruption was possible, but not likely.. ================(Build #2550 - Engineering Case #654938)================ In rare cases, a corrupt TCP packet could have caused the server to crash. The server now validates the packet header before do anything with the packet. If it is corrupt, the packet is dropped. ================(Build #2548 - Engineering Case #654952)================ Under rare circumstances, the server could have hung when SUBSCRIBE BY values were being changed for an article while large numbers of connections were updating tables in the database. This has now been fixed. A workaround is to avoid changing SUBSCRIBE BY values simultaneously with connections performing INSERT, UPDATE or DELETE operations. ================(Build #2546 - Engineering Case #654790)================ In very rare cases, the server may have crashed with a floating point exception when slightly loaded. This has been fixed. ================(Build #2544 - Engineering Case #654284)================ The server could have crashed if the STOP SERVER or STOP ENGINE statement was called from an event or HTTP connection. This has been fixed. Note that the 'STOP SERVER' syntax is new to version 12 (older servers support 'STOP ENGINE'). ================(Build #2544 - Engineering Case #654259)================ The changes for Engineering case 650489 may have caused execution remote procedure calls to an ASE remote server to fail with a strange "unchained transaction mode" error. This problem has now been fixed. ================(Build #2544 - Engineering Case #620095)================ Several stability problems existed with parallel queries when using low-memory strategies, which could have lead to server hangs or crashes. These have been fixed. A workaround for these problems is to disable parallelism by setting the option MAX_QUERY_TASKS=1 for all affected queries. ================(Build #2543 - Engineering Case #653591)================ Attempting to attach tracing to an older version database file could have caused the server to crash. This has been fixed so that attempting to attach tracing to an older version file now returns the error "ATTACH TRACING could not connect to the tracing database" (-1097). ================(Build #2543 - Engineering Case #653590)================ Diagnostic tracing, or application profiling to LOCAL DATABASE could not be used when the server was started with the command line option -sb 0 (disable broadcast listener). This has been corrected. A workaround is to manually supply a connection string (ATTACH TRACING TO <connstr>) with the DoBroadcast=NO option, rather than using the LOCAL DATABASE clause. ================(Build #2543 - Engineering Case #556778)================ The return values of the built-in functions user_id() and suser_id() may have incorrectly been described as not nullable even if the function argument was not nullable. This may have lead to the assertion error 106901 "Expression value unexpectedly NULL in write". This has been fixed so that the functions' results are always described as nullable. ================(Build #2542 - Engineering Case #653588)================ If tracing was suddenly detached (because, for example, the server receiving the tracing data was shut down) at the same time as a deadlock occurred, a deadlock victim may have failed to write a ROLLBACK to the transaction log. This may have lead to an incorrect partial commit of a deadlocked transaction. This has been fixed. This problem is expected to be very rare. ================(Build #2542 - Engineering Case #653245)================ The value for the column "columns" for the system view SYS.SYSFOREIGNKEYS is generated using a LIST() function, but the function did not include an ORDER BY and so the result returned could have varied. This has been fixed by adding an ORDER BY clause. Note, the system view must be recreated by upgrading or rebuilding the database for the new view definition to be used. ================(Build #2542 - Engineering Case #652911)================ If an INSTALL JAVA UPDATE statement was executed to update an existing java class, the server would have incorrectly added a new system object id rather than reuse the already assigned object id. This problem has now been fixed. ================(Build #2541 - Engineering Case #653706)================ The 'TOP limit START AT startat' and 'LIMIT limit OFFSET offset' constructs now support 1 - simple arithmetic expressions for 'limit', 'offset', 'startat' arguments; 2 - TOP supports the 'ALL' limit indicating that all rows are to be returned after the specified 'startat'; 3 - the maximum value for (limit + offset) is now 9223372036854775807 = 2^64-1 The new grammar is as follows: TOP range_expression range_offset TOP T_ALL range_offset LIMIT range_expression [OFFSET range_expression] range_expression: integer_or_var | '(' simple_expression ')' simple_expression: integer_or_var | simple_expression '+' simple_expression | simple_expression '-' simple_expression | simple_expression '*' simple_expression | '(' simple_expression ')' range_offset: /* empty */ | T_START T_AT range_expression ================(Build #2541 - Engineering Case #653052)================ Using the system procedure xp_sendmail with an attachment larger than about 55 kB may have resulted in the attachment being corrupted. This has been fixed. ================(Build #2541 - Engineering Case #648799)================ In some cases, the server could have returned an error ("Parameter error") for a statement using OPENSTRING with a VALUE specifying a field reference or other complex expression. For example, the following sequence could generate this error: declare local temporary table T_strs( str long varchar ); insert into T_strs values ('1,a1\n2,a2'), ('3,b1\n4,b2'); select * from T_strs T cross apply openstring( value T.str ) with( a char(10) ) as O This has been fixed. Statements such as the above are now processed correctly without an error. ================(Build #2540 - Engineering Case #652791)================ If a statement for a directory access table failed with the error SQLSTATE_OMNI_REMOTE_ERROR, and this statement was the last statement of the transaction then all subsequent remote server statements of this connection would have failed with the same error. This has been fixed. ================(Build #2539 - Engineering Case #652543)================ The server may have crashed during inserts into a view, if the view column was not a base table column. This has been fixed. Now the correct error SQLSTATE_NON_UPDATEABLE_VIEW is returned. ================(Build #2538 - Engineering Case #652411)================ If an error occurred accessing the tape drive when beginning a tape backup, the BACKUP statement may have hung. This has been fixed. ================(Build #2538 - Engineering Case #652253)================ In some rare cases, when run on HP, AIX, and Solaris systems the server may have crashed on shutdown. This has been fixed. ================(Build #2538 - Engineering Case #652221)================ In some cases, calling a web services stored procedure may have crashed the server. This has been fixed. ================(Build #2538 - Engineering Case #651694)================ If the connections between servers in a mirroring system used encryption, the primary server could have hung when performing an operation which required exclusive access to the database (e.g. a checkpoint) if other update activity was also occurring. This has been fixed. ================(Build #2537 - Engineering Case #652107)================ If a foreign key had both ON UPDATE and ON DELETE actions, renaming a column referenced by the foreign key could have caused one of the system triggers to be deleted and the other to be left unchanged. A trigger for an ON UPDATE action could have been converted to an ON DELETE action. This has been fixed. ================(Build #2537 - Engineering Case #651846)================ On Windows systems, the performance monitor might not have displayed counter values provided by the server. Typically this would have happened when a shared memory client that was attached to the server terminated abnormally. Counter values should not display for subsequent servers until all processes holding handles to the dead server (e.g. shared memory clients) are terminated. This has been fixed. ================(Build #2536 - Engineering Case #651729)================ In some rare cases, the server may have hung if diagnostic tracing had been enabled. This has been fixed. ================(Build #2536 - Engineering Case #651658)================ On Windows systems, SQL Anywhere provides a version 1 (registry) performance provider. Windows should generate WMI classes automatically after the counter dll is registered, but these classes were generated only after instances of these objects (i.e. server, database and connection) existed in a process running in session 0 (i.e. as a service in Vista and up). This has been fixed. ================(Build #2535 - Engineering Case #651169)================ If a database containing a table with a uniqueidentifier column was unloaded using the Unload utility (dbunload) with one of the external unload options (-xi or -xx), and the resulting reload.sql script was executed using the Interactive SQL utility, a conversion error would have been reported. This has been fixed. A workaround is to avoid using -xx or -xi when rebuilding the database. ================(Build #2535 - Engineering Case #650740)================ Execution of a DROP DATABASE statement would have failed if the automatically generated database alias name was an invalid identifier. This has been fixed. ================(Build #2534 - Engineering Case #651029)================ On Linux builds where the kernel was compiled to support something other than 1024 processors, the database server could have failed to detect the correct processor geometry and could have crashed. This problem has been fixed. Note that recent Linux kernels have been built with support for up to 4096 processors. ================(Build #2534 - Engineering Case #650489)================ If an application made a remote procedure call that made changes to a remote database and then subsequently called ROLLBACK, the changes would not have been rolled back on the remote database that the remote procedure call affected, but would have been rolled back locally and on the other remote databases that the local connection modified. This problem has now been fixed. ================(Build #2533 - Engineering Case #650829)================ The Validate utility, or the VALIDATE utility, could have reported spurious orphaned blobs if there were indexes containing long values. This has been fixed. ================(Build #2532 - Engineering Case #647154)================ The denial-of-service attack addressed by the changes for Engineering case 610115 could still have occurred if idle timeout had been turned off on the server using the command line option -ti 0, or the system procedure sa_server_option('IdleTimeout',0). If the idle_timeout value was not 0, the server was not susceptible. This has now been corrected. ================(Build #2531 - Engineering Case #650352)================ Procedure profiling showed statements that executed in under 1 millisecond as using zero time, even when those statements were executed many times. This has been fixed. ================(Build #2531 - Engineering Case #650337)================ Queries with an outer join having the same base table as the preserved and null-supplying sides could have returned incorrect result sets. Conditions where this could happen: 1. the outer join is of the form : T as T1 LEFT OUTER JOIN T as T2 ON(p) 2. the ON predicate p has only equijoins, and at least two equijoins 3. p is of the form : T1.c1 = T2.c1 and T1.c3 = T2.c2 4. there exists an unique index on T < c1,c2> This has been fixed. ================(Build #2531 - Engineering Case #649978)================ Under rare circumstances, some statements involving proxy tables could have missed expression checking. This has been corrected. ================(Build #2530 - Engineering Case #649928)================ Sending large attachment files via SMTP using the system Procedure xp_sendmail() may have crashed the server. This problem was introduced by the changes made for Engineering case 643590, and have now been fixed. ================(Build #2530 - Engineering Case #649868)================ A brief network outage in a mirroring environment could have resulted in one of the servers reporting "Alternate server name in use"; or the former mirror server restarting, but not becoming the primary server. This has been fixed. ================(Build #2529 - Engineering Case #649797)================ An index containing long values could have become corrupted if the table was subsequently altered to add columns, remove columns that did not appear in the index, or change the nullability of a column not appearing in the index. Also, for this to have happened, entries must have been deleted from the index. This has been fixed. ================(Build #2528 - Engineering Case #649475)================ If a JDBC application connected via jConnect called the method DatabaseMetaData.getSchemas(), then the server would have failed the request with the error "the 'FileVersion' property is no longer supported". This problem has now been fixed and the proper list of userids is now returned to the application. ================(Build #2527 - Engineering Case #649795)================ Queries over indexes could have returned incorrect results if long index entries (greater than ~240 bytes) appeared in the index, with index corruption a possibility. This has been fixed. ================(Build #2527 - Engineering Case #648786)================ If the primary server in a mirroring system lost quorum, just as an update caused log pages to be sent to the mirror, the primary server could have hung. This has been fixed. ================(Build #2526 - Engineering Case #648518)================ In very rare cases, the server may have crashed if the cache was low on memory and a SELECT statement contained a very large IN list predicate. This has been fixed. The server will now return the error SQLSTATE_SYNTACTIC_LIMIT. ================(Build #2526 - Engineering Case #648179)================ The server could have entered a state where it would consume 100% of a single CPU (ie. one 'core') and never leave that state. The problem was caused by a race condition when more than one thread simultaneously attempted to reference a foreign key index for the very first time; however, the effects of the race condition may not be observed until the server attempts to shut down. This problem has been fixed. ================(Build #2526 - Engineering Case #648158)================ Attempting to use an index in a non-system dbspace with a database that was upgraded from 10.x, would have caused an assertion. This has been fixed. ================(Build #2525 - Engineering Case #648790)================ After applying the fix for Engineering case 635815, if an application executed a statement of the form: INSTALL JAVA [NEW | UPDATE] JAR 'jar-name' FROM expression then there was a chance the server would have crashed. This problem has now been fixed. ================(Build #2525 - Engineering Case #648493)================ If Perseat licensing was used, the error "Database server connection limit exceeded" may have been reported when it should not have. In order for this have occurred, in addition to Perseat licensing, the -gm server option, or http connections to disabled databases, must have also been used. When this problem occurred, the first time the error was reported was correct behaviour, but after disconnecting connections, the error may have continued when it should not have. This has now been fixed. ================(Build #2525 - Engineering Case #647682)================ Key constraint checking and validation errors were possible when indexing long index values if the relative position of the corresponding index columns (foreign and primary) within their respective tables were not identical. This has been fixed. ================(Build #2525 - Engineering Case #646858)================ Under very rare circumstances, the server could crash during database cleaner execution. This has been fixed. ================(Build #2524 - Engineering Case #640821)================ It was possible to get the following validation errors: Page x of database file "<database file name>" references a table (y) that doesn't exist or Orphaned page (x) found in database file "<database file name>". The database server could have left some pages in a state where they cannot be reused. The database would have continued to function normally in this state but it is possible to regain the lost pages by rebuilding the database file. This most likely would have occurred in a non-system dbspace, and has now been fixed. ================(Build #2522 - Engineering Case #647663)================ A server running as the primary in a mirroring system could have hung when the mirror server was started. This was more likely to occur after the fix for Engineering case 637057 was applied. This has been fixed. ================(Build #2522 - Engineering Case #646703)================ In rare circumstances, reading a substring of a value from a compressed column (not starting at the first byte) could have caused assertion failure 201501 - "Page ... for requested record not a table page". Note that the Interactive SQL utility (dbisql) fetches long values in pieces, so selecting the value using dbisql (without using substrings) may cause this problem. This only happens on compressed columns with blob indexes. This has been fixed. ================(Build #2521 - Engineering Case #647225)================ Attempts to edit table data in the "Results" panel would have failed with the error "Savepoint ... could not be found.", if the Transact-SQL transaction mode was Unchained. This has been fixed. Note that the default transaction mode is Chained. ================(Build #2521 - Engineering Case #645801)================ In an environment with each server in a mirroring system having two network connections, each on one of three separate networks, so that a failure in one of the networks would still allow two of the nodes to communicate, a network outage could have resulted in both partner servers acting as a primary server. This has been fixed. ================(Build #2520 - Engineering Case #647495)================ On recent versions of Linux (with SELinux enabled), programs with executable stacks were forbidden. The program would have failed to start with an error like: dbeng12: error while loading shared libraries: libdbserv12_r.so: cannot enable executable stack as shared object requires: Permission denied This would have potentially happened with any SQL Anywhere binary, and has now been fixed. A work around is to either disable SELinux, or run execstack -c on the problematic binaries. ================(Build #2520 - Engineering Case #647331)================ Execution of an extremely complicated remote query that needed to be processed in either no passthrough or partial passthrough mode, could have resulted in a server failure. The server now properly returns error -890. ================(Build #2520 - Engineering Case #643642)================ Revoking all table permissions from a grantee that were granted by a particular grantor did not always remove the corresponding SYSTABLEPERM row. This has now been fixed. ================(Build #2519 - Engineering Case #647187)================ When attempting to insert a string into a proxy table that was the result of calling a builtin function, if the builtin function returned an empty string, then there was a chance that the Remote Data Access layer would have inserted a NULL value instead. For example, a statement like: INSERT INTO my_proxy_table(my_column) SELECT RTRIM( ' ' ) may have inserted NULL instead of '' into to my_proxy_table. This problem has now been fixed. ================(Build #2519 - Engineering Case #647076)================ When starting the server on recent versions of Linux using the -ux or -ui command line options, or when auto-starting a server that required a GUI-based evaluation splash screen, the server may have crashed or hang. The crash would have occurred mostly on recent versions of Linux running a GTK theme engine (e.g. Clearlooks). The hang could have happened with any supported GTK version after dismissing the evaluation splash screen. This has now been fixed. A workaround is to run without the GUI. ================(Build #2519 - Engineering Case #647066)================ The Stored Procedure Debugger was sometimes unable to set breakpoints for statements in procedures that should have allowed breakpoints. This has been fixed. ================(Build #2519 - Engineering Case #645664)================ Attempting o unload and reload a database that contained a proxy table with a unique constraint would have failed with the error: "feature 'alter remote table' not implemented ". This problem has now been fixed. The "alter table...add unique" statement is no longer unloaded for proxy tables. ================(Build #2519 - Engineering Case #643763)================ Execution of a query block that output a string constant could have caused the server crash if the optimizer chose a parallel execution plan. The likelyhood of such a crash increased under high server load and when the query occurred inside a stored procedure. This problem has now been fixed. For version 12.0.0, this problem was most likely to be encountered when using string literals in different blocks of a Union, as follows: SELECT 'String1', col1, col2 FROM table1 WHERE predicate1 UNION SELECT 'String2', col1, col2 FROM table2 WHERE predicate2 For versions prior to 12.0.0 this problem was much more obscure, and likely required a constant string occurring both in a non-simple output expression and in a WHERE clause predicate. This has been fixed. ================(Build #2518 - Engineering Case #646830)================ In very rare cases, the server may have crashed using long identifiers in SQL statements. This has been fixed. ================(Build #2517 - Engineering Case #646687)================ If a large number of concurrent connections simultaneously executed remote queries that required partial or no passthrough processing, and several of the queries made heavy usage of aliases, then the server could have crashed. This problem has now been fixed. ================(Build #2517 - Engineering Case #641328)================ A statement such as the following could have incorrectly given an error: select row_num, if row_num < 1 then 1+row_num/0 endif x from rowgenerator order by x option(force no optimization) The sub-expression 1+row_num/0 should never be evaluated as the condition row_num<1 is never true. However, in a simple statement processed by bypassing the query optimizer, if a Sort was needed to order the rows of the result, an error could be incorrectly given. This problem has been fixed. ================(Build #2514 - Engineering Case #645926)================ If an Open Client or jConnect application attempted to prepare and execute a statement with a large number of parameters, then the server would have failed the request, or in rare cases, could have crashed. This problem has now been fixed. ================(Build #2513 - Engineering Case #645635)================ HTTP requests made to SQL Anywhere services that utilize the built-in HTTP Session mechanism (created with sa_set_http_option) may, on rare occasions, have caused the server to crash. This has been fixed. ================(Build #2512 - Engineering Case #644526)================ If a long index entry (the equivalent of a 250 character or longer ASCII string) was deleted from an index, there was the possibility of index corruption and the server crashing. This has been fixed. ================(Build #2512 - Engineering Case #644508)================ A SQL Anywhere HTTP procedure may have failed when configured with a PROXY clause to connect through an Apache forwarding proxy version 2.0.X. This has been fixed. Changes have also been made to improve WebClientLogging (-zoc) messages when connecting through a proxy. ================(Build #2511 - Engineering Case #645138)================ In very rare cases, a primary mirroring server could have crashed on shutdown if the database was being updated. This has been fixed. ================(Build #2511 - Engineering Case #643936)================ Unexpected column names could have been reported for complex expressions in the SELECT list of a statement. The problem mostly affected queries over views, for which the name of the base table column, rather than the name of the view column, could have been reported. For example, consider the following table and view: CREATE TABLE admin_group.employee( pk INTEGER PRIMARY KEY, fname CHAR(100) NOT NULL, lname CHAR(100) NOT NULL, cname CHAR(100) ); CREATE VIEW admin_group.v AS SELECT e.fname AS first_name, e.lname AS last_name, e.cname AS company_name FROM admin_group.employee e; In the query: SELECT <expr> FROM admin_group.v; the following expressions would have been described with the base table column names: CAST( first_name AS VARCHAR(100)) (first_name) This has been fixed so that both of the expressions above will now be described as 'first_name'. Additionally, expressions such as ISNULL( <col1>, <col2> ) could have been described differently depending on the nullability of the first column. For example, ISNULL( first_name, company_name ) would have been described as 'fname', whereas ISNULL( company_name, first_name ) would have been described as 'isnull( employee.fname as first_name,employee.cname as company_name)'. For consistency, both of the above expressions will now be described by unparsing the expression. ================(Build #2511 - Engineering Case #595494)