SQL Anywhere Bug Fix Readme for Version 12.0.1, build 3769
Choose a range of build numbers for which to display descriptions. For example if you want to see what was fixed since the last EBF you applied then change 3152 to the build number of that last EBF. Click Update Readme to make those changes take effect. to Update Readme
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.
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
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.
================(Build #3320 - Engineering Case #663991)================
Under some circumstances, queries with cached plans and queries containing
complex correlated subqueries may have returned incomplete results if they
were executed as parallel plans. This has been fixed.
Note, a workaround is to disable intra-query parallelism (set MAX_QUERY_TASKS=1).
================(Build #3315 - Engineering Case #661791)================
A query containing a join between two or more tables could have returned
an incorrect result if the executed query plan used an Index-Only Scan of
some index T_idx over table T. For the problem to have occurred, a column
T.col must have participated in a non-equality join predicate (e.g. "T.col
< S.col", or "T.col BETWEEN S.col1 AND S.col2"), and there
must have existed one or more columns in index T_idx preceeding T.col that
did not participate in equality predicates. This has been fixed.
================(Build #3549 - Engineering Case #687157)================
Upload rows sent by clients might not have been applied to the consolidated
database on a SQL Anywhere or Sybase IQ database server if a redundant synchronization
request was received by the MobiLink server, and the MobiLink server aborted
the request with the following error:
User 'a_ml_user_name' has the row in 'ml_database' locked (ODBC State =
40001, Native error code = -210)
The new synchronization must also have contained an upload that included
upload rows for multiple synchronization tables, and reused the database
connection that was used for processing the redundant synchronization. This
problem is fixed now.
Note, all connections used by a MobiLink server are shown in the MobiLink
server logging file with a prefix SPID when a minimal verbosity is specified
in the MobiLink command line.
================(Build #3347 - Engineering Case #668833)================
The dbmlsyc command line option -qi prevents the tray icon or window from
being displayed. This behaviour is identical to the -qi option of the database
server. The option has existed since 11.0.1, but was not referenced in the
usage text or the documentation. The usage text has been corrected
================(Build #3362 - Engineering Case #671955)================
The new property "ianywhere.qa.server.disableDeleteRules" has been
added to the QAnywhere server properties that can be specified in the configuration
file that can appear after the -m option of the MobiLink command. When set
to True (default is False), this property disables the message delete rules
and archiving processes that automatically run while the server is running.
This property would normally not be used, but it is useful, along with the
property "ianywhere.qa.server.disableNotifications", in the scenario
where more than one MobiLink server is running on a given consolidated database,
and the servers are not in a server farm configuration. In this case, the
MobiLink servers must be configured such that only one of the servers is
running message delete rules and the QAnywhere notifier.
================(Build #3726 - Engineering Case #706387)================
Three new flow control elements have been introduced, allowing the Relay
Server to detect potential dangers proactively, and urgently signal the Outbound
Enabler to throttle back on pushing data down to the Relay Server in an isolated
per client manner. These new elements are:
Per client shared memory consumption
Per client virtual memory consumption
Global shared memory level
This change also introduces a new user control in the Relay Server configuration:
[backend_farm]
max_client_buffer = <memory size>
When the Relay Server consumes more than the "max_client_buffer"
amount of virtual memory to buffer server response for a slow reading client,
an urgent flow control signal will be sent to the Outbound Enabler to pause
reading further server responses for this client. The Relay Server will signal
the Outbound Enabler to resume the reading responses for the client when
the client has consumed enough of the responses until only half of "max_client_buffer"
worth of server responses for the client is left in the Relay Server. The
default value of "max_client_buffer" is 1M. The "max_client_buffer"
property can be adjusted online and the change takes effect immediately without
restarting the Relay Server.
Similarly, per client shared memory is also being monitored, and isolated
per client throttling was added. There is no user control for this element
of the flow control system, as this element doesn't directly prevent shared
memory exhaustion but it prevents deadlocking of the down-channel.
Monitoring of the global shared memory level has also been added, so that
flow control can be triggered on any client even if their personal quota
has not yet been reached. No new user control has been introduced for this
element of the flow control system, but the behavior of the existing "shared_mem"
control in the Relay configuration has changed. Previously, this value was
used only for specifying the extra amount of shared memory for buffering
traffic and state tracking, in addition to the amount implied by the configuration.
The property had an effect of an amount equal to its size on the startup
allocation. Online adjustment to the value had no effect on the total allocation
until the Relay Server is restarted. Now, this property has an effect of
an amount three times its value on the startup allocation of shared memory,
and is broken down as follows:
- one third for buffering traffic and state tracking where user thought
is enough at startup time.
- one third for future online growth of the number of tenants, and backend
farm size of the tenants.
- one third as an extra blanket inside the auto calculated shared memory
low water mark for triggering flow control.
The sum of these values are pooled together for all functional needs without
usage partitioning. The factoring is for calculating the gross startup amount
and also users to understand the new implications of online adjustment of
this value. Online adjustment to this value still has no effect on the total
allocation, but it does change the global shared memory low water mark for
triggering flow control. Because of one third factor as a blanket inside
the low water mark, users can make adjustments to the flow control behavior
without restarting the Relay Server.
Here are some new usages of the shared_mem property in terms of online adjustments:
The administrator doesn't foresee growth in number of tenants and/or their
size and so wants to reduce the shared memory low watermark in order to reduce
triggering of unnecessary flow control. The shared_mem property can be reduced
online. The change doesn't decrease allocation until restart, but it does
reduce the blanket amount immediately by an amount equal to the change.
The administrator has seen some of the following after their Relay Server
had been running for some time:
Substantial growth in number of tenants
Substantial growth in size of the backend farm
Substantial growth in number of clients
Growth in http response size
Addition of slower clients or slower network to the clients
Upgraded to faster network between RS and OE
and wants to increase the global shared memory low water mark so that flow
control kicks sooner to protect against global shared memory exhaustion.
This can be done by increasing "shared_mem" online without restarting
the Relay Server. The change doesn't increase allocation until restart but
it increase the blanket amount immediately by an amount equal to the change.
The "shared_mem" value to now allowed to be bigger than 4G.
This change has extended the existing protocol between the Relay Server
and the Outbound Enabler so that upgrading to a new Outbound Enabler is required
for this feature. The new Relay Servers and Outbound Enablers are backward
compatible with older versions, but flow control cannot take place and so
the Relay Server is not protected against memory exhaustion.
Before these changes, the Relay Server can run out of resource due to reaching
the hard limit of shared memory or reaching the limit on virtual memory.
This could have had different causes, including, but not limited to, an increase
in the number of clients or backend farms/servers, http response size, and
sustained slow reads from clients. Some exhaustion may have lead to deadlocks
and the symptom may not have been fatal as current Relay Servers will resolve
the deadlock, but the requests could still have been failed and shared resources
were blacked-out during the deadlock period.
sers might experience
================(Build #3724 - Engineering Case #694165)================
An interactive quick setup feature has been added to help users running on
an Apache web server to configure the web server for Relay Server, create
a demo application, and generate a Quick Reference guide.
This quick setup is divided into two main steps:
1- Configure the Apache web server for Relay Server
Run ap-setup.sh script, which consists of the following sections:
1. Introduction
2. Validation
3. Create Backup
4. Deploy the Relay Server
5. Deploy the SimpleTestApp page and Quick Reference
6. Introduction to test setup script (part two)
2- Create and start Relay Server test services
Run rs-test-setup.sh script, which consists of the following sections:
1. Introduction
2. Create and deploy Relay Server and Outbound Enabler test services
3. Start the Apache web server and the test services
4. Launch the SimpleTestApp
5. Launch the Relay Server status page
6. Generate and launch the Quick Reference guide
7. Shut down
================(Build #3546 - Engineering Case #695497)================
Only the status page via the rs_admin.dll and rs_mionitor.dll provides full
breakdown of status of all farms and servers and the amount of info can be
overwhelming for large deployment like hosting environment. The status page
via rs_client.dll or rs_server.dll only provides a single Relay Server wide
status summary, and the user cannot pinpoint their query to a specific farm
for backend server. This change introduces the following two new query parameters
for all status pages.
ias-rs-farm=<backend-farm-id>
ias-rs-server=<backend-server-id>
Use of ias-rs-server requires ias-rs-farm to be specified as well. The comparison
of the value of these parameters are case sensitive but the name of these
parameters are case insensitive. These new parameter can be applied to the
status page url via all of the 4 existing extensions and they can co-exist
with the ias-rs-refresh-sec parameter.
Example status page url:
http:\\my.com\rs\admin\rs_admin.dll?ias-rs-farm=myfarm&ias-rs-server=myserver
http:\\my.com\rs\client\rs_client.dll?ias-rs-farm=myfarm&ias-rs-status-refresh-sec=20
When addressing rs_client.dll or rs_server.dll while IAS-RS-SERVER is not
specified, individual server status will still be reported but the server
name are hidden by label of this format: "_#<enumeration>_".
In the cases of farm or server not found. The status page will still response
with basic RS server information together with an error reporting what was
not found. In those cases, no status information of any kind are reported
but the viewer can still verify if they have a successful access to the extension
of their choice.
The pin-pointed status url shares the pre-existing refresh control and it
can be used as a basic service monitor in a browser.
================(Build #3519 - Engineering Case #692340)================
Machine and OS information have now been added to the Relay Server Outbound
Enabler log. As well, timezone offset information has been added to the Relay
Server and the Outbound Enabler logs.
================(Build #3477 - Engineering Case #687786)================
An interactive quick setup feature has been added to help users with deploying
Relay Server components to Microsoft IIS 6.0 on Windows Server 2003. This
is being provided as an alternative to the manual procedure documented in
the Relay Server Guide.
Setup is automated but also interactive. It creates a demo application and
a Quick Reference Guide to assist in subsequent Relay Server server maintenance.
The Quick Reference is launched automatically as part of the setup.
Setup is comprised of the following major steps:
1. Introduction
2. Customization
3. Create a Backup
4. Deploy and Start the Relay Service
5. Generate and Launch the Quick Reference
6. Launch the Relay Server Status Page
7. Launch the SimpleTestApp Client
8. Shut down
To deploy the Relay Server components to Microsoft IIS 6.0 on Windows Server
2003, run rs-setup.bat from the SQLANY12%/RelayServer/IIS/quicksetup_iis6
directory
================(Build #3475 - Engineering Case #688116)================
Support has now been added to the Relay Server to allow it to extract identity
information from client certificate and then forward them in HTTP headers
that SAP Gateway or Web Dispatcher understands. To turn on the feature for
a backend farm, set the following new backend farm property in the Relay
Server configuration file:
forward_x509_identity = yes
In the case were there is a chain of SAP intermediaries, the client identity
headers may already present in the request. However not all clients may be
granted a permission to act as such forwarder. So the default behavior is
to replace the existing headers with the identity of the forwarder. To grant
permission for a forwarder to forward its client identity without being overwritten
by its identity, the following new pair of backend farm properties may be
in the Relay Server configuration file:
forwarder_certificate_subject = <match-string>
forwarder_certificate_issuer = <match-string>
The <match-string> is used to check against a serialized form of the
corresponding compound name field in the certificate. A '?' can be used to
match any character and a '*' can be used to match any string. A '\' can
be used as the leading escape character for '?', '*' or '\' of they need
to be matched literally.
For example:
forwarder_certificate_subject = 'CN = mySapWD??.my.com, OU = Sybase, O
= SAP, *'
forwarder_certificate_issuer = 'CN = quicksigner, OU = security department,
O = my coop, L = my city, S = my state, C = my country'
To obtain the subject or issuer string of a forwarder, simply perform a
forwarding without setting up the match requirement. The following error
messages in the Relay Server log will reveal the full subject or issuer which
fails the default empty match-string:
Forwarder certificate subject '<full-subject-string>' does not match
pattern '' required in farm '<farm>'
Forwarder certificate issuer '<full-issuer-string>' does not match
pattern '' required in farm '<farm>'
================(Build #3475 - Engineering Case #663987)================
The Relay Server Outbound Enabler is now able to initiate SSL connections
to the backend server. In the -cs option, HTTPS=1 is used to enable an SSL
connection to the backend server. When SSL is enabled, the -cs option can
take the values 'trusted_certificates', 'identity' and 'identity_password'
for server and/or client authentication.
================(Build #3467 - Engineering Case #686057)================
An optional ias-rs-status-refresh-sec query parameter has been added to the
status url for controlling the auto refresh rate of the status page. A refresh
interval of 0 means auto refresh is not wanted and users are expected to
use the refresh button on the browser to refresh the status. The following
information was also added to the status page:
- Service start time in UTC.
- Status capture time in UTC.
- Status refresh interval, or indication that manual refresh is expected.
================(Build #3588 - Engineering Case #687570)================
A .NET Policy DLL and the associated iAnywhere.MobiLink.Client.config file
are now installed and configured. The .NET Policy DLL will allow .NET applications
compiled against any build of v12.x of the iAnywhere.MobiLink.Client assembly
to automatically re-direct to the most recent build of the assembly installed
on the machine, if the desired build of the assembly could not be located
on the machine. Before these files were installed and configured, an application.config
file or machine.config file could have been used to get the same functionality.
================(Build #3537 - Engineering Case #693928)================
When the StartServer method in the dbmlsync API is used to start a dbmlsync
server, the dbmlsync commandline is now obfuscated making it harder for someone
with access to the machine to discover the dbmlsync commandline.
================(Build #3563 - Engineering Case #697061)================
The sample certificates in rsaroot.crt and rsaserver.id have been regenerated
using SHA1 and 2048-bit RSA keys. The original certificates used MD5 and
1024-bit keys.
================(Build #3758 - Engineering Case #713455)================
Support has been added to the MobiLink Server for consolidated databases
running on Microsoft SQL Server 2012 servers with the Microsoft native ODBC
driver named SQL Server Native Client 11.0, version 2011.110.xxx.xx. This
support is limited to Microsoft Windows only.
================(Build #3744 - Engineering Case #706828)================
The MobiLink server now supports bulk upload for sync tables that contain
LOBs when the consolidated database is running on an Oracle server. The bulk
upload feature would have previously been disabled when a sync table contained
LOBs. The number of rows uploaded by each batch is controlled by -s command
line option.
Note, the iAS ODBC driver for Oracle must be upgraded to the same EBF level
as the MobiLink server when the consolidated database is running on an Oracle
server and the synchronization tables contain CLOBs or BLOBs.
================(Build #3590 - Engineering Case #700276)================
The MobiLink server now supports the Oracle XMLTYPE data type. This Oracle
data type can be mapped to the SA/UL XML data type. However, the Oracle
database server does actually validate the data before storing it into a
XMLTYPE column and SA/UL does not. Therefore, users must make sure the upload
XML data are valid XML documents.
Small XML documents with a length less than or equal to 32 KB can be uploaded
into and downloaded from an Oracle database with Oracle PL/SQL statements.
However, when the length of XML documents is great than 32 KB, the upload
XML documents may need to be uploaded into a (global) temporary table by
the upload_insert and upload_update scripts and the upload data can then
be converted and stored into the actual sync table in the end_upload_rows
or end_upload script.
The following section gives sample upload and download scripts to upload
and download XMLTYPE objects between an Oracle consolidated and SQLAnywhere
remote databases. Here we assume our upload table is defined as
create table test (pk int not null primary key, c1 XMLTYPE)
in the Oracle consolidated database and
create table test (pk int not null primary key, c1 XML)
in the SA remote database. Then the upload and download scripts for the
test table could be defined below:
1) All XML documents are less than or equal to 32KB long:
The upload and download scripts can be written as
a) upload_insert:
declare v_pk integer; v_c1 clob; x_c1 xmltype;
begin
v_pk := {ml r.pk};
v_c1 := {ml r.c1};
x_c1 := XMLTYPE.createXML( v_c1 );
insert into test values( v_pk, x_c1 );
end;
b) download_cursor:
select pk, XMLSERIALIZE( content c1 ) from test
This upload_insert script works well, when the XML data length is less than
or equal to 32 KB. However, if the XML data length is greater than 32 KB,
the Oracle server could complain with the following error:
ORA-01460: unimplemented or unreasonable conversion requested
when the MobiLink server was trying to execute the upload_insert script
with the upload data.
2) Some of the XML documents are greater than 32KB long:
If there are any XML documents greater than 32 KB long, we are not able
to use Oracle PL/SQL to upload data into the Oracle XMLTYPE columns. To
work-around this problem, the upload XML data needs to be uploaded in a global
temporary table:
a) upload_insert:
The upload_insert script will upload the XML documents into a global temporary
table in the Oracle consolidated database and the global temporary table
is defined as
create global temporary table tmp_test (pk int, c1 CLOB)
then the upload_insert script can written as
insert into tmp_test values( {ml r.pk}, {ml r.c1} )
Please note, the c1 column in the temporary table must have the CLOB data
type.
b) end_uoload_rows:
The end_upload_rows script first retrieves the XML documents from the global
temporary table, converts it to XML documents, and then stores the XML data
into the test table. Here is the end_upload_rows script:
insert into test (pk, c1) (select pk, XMLTYPE.createXML(c1) from tmp_test
================(Build #3574 - Engineering Case #696647)================
A new NetworkData class has been added to the Java and .NET scripting APIs
to give access to HTTP headers and client-side certificates used in a request.
A NetworkData object can be obtained by calling the getNetworkData method,
or getting the NetworkData property of the DBConnectionContex class in Java
or .NET, respectively. Collection of the network data must be explicitly
enabled by adding "collect_network_data=1" to your -x options.
To collect client-side certificates, trusted_certificates=<certificate
file> must be added to -x options. The client-side certificates are not
yet available for MacOS, but that will be added in a future EBF.
The class documentation for the Java class follows:
/**
* Contains information about the network streams for a synchronization.
* This is useful if you wish to authenticate against some other server
in
* the enterprise using the client-side certificate and HTTP headers.
*
* To enable collection of network stream data, add collect_network_data=1
to
* your -x switches. This adds additional per sync memory overhead to store
* the data. If using TLS or HTTPS with client-side certificates, add
* trusted_certificates=<certificate file> to have the server ask
the client to send
* a certificate during the TLS handshake, incurring a time and network
cost.
*
* You can obtain a NetworkData object by invoking the getNetworkData method
* of the DBConnectionContext class. When using HTTP or HTTPS, it will
contain
* the header data for the last HTTP request received by the server before
the
* authenticate scripts are invoked.
*
* @see DBConnectionContext
*
* @examples
* The following example shows how to get a NetworkData object from the
* DBConnectionContext, and prints the data it contains to the log.
*
* <pre>
* public class OrderProcessor {
* DBConnectionContext _cc;
*
* public OrderProcessor( DBConnectionContext cc ) {
* _cc = cc;
* }
*
* // The method used for the authenticate_user event.
* public void AuthUser() {
* NetworkData nd = _cc.getNetworkData();
* if( nd != null ) {
* if( nd.isHTTP() ) {
* System.out.println( "http" );
* String user_agent = nd.getHTTPHeaderValue( "user-agent"
);
* System.out.println( " user-agent: " + user_agent.substring(
0, user_agent.indexOf( '/' ) ) );
* } else {
* System.out.println( "no http" );
* }
* if( nd.isTLS() ) {
* System.out.println( "tls" );
* CertPath certs = nd.getCertificateChain();
* if( certs != null ) {
* System.out.println( " client-side cert:"
);
* int n = 1;
* for( Certificate c : certs.getCertificates() ) {
* System.out.println( " cert " + n++
);
* X509Certificate c509 = (X509Certificate) c;
* System.out.println( " Subject: "
+ c509.getSubjectX500Principal().getName() );
* System.out.println( " Issuer: "
+ c509.getIssuerX500Principal().getName() );
* }
* } else {
* System.out.println( " no client cert"
);
* }
* } else {
* System.out.println( "no tls" );
* }
* if( nd.isEndToEndEncrypted() ) {
* System.out.println( "e2ee" );
* } else {
* System.out.println( "no e2ee" );
* }
* } else {
* System.out.println( "NULL networkdata" );
* }
* }
* }
*
* </pre>
*/
public interface NetworkData
{
/**
* Returns true if this sync is using HTTP or HTTPS, and false otherwise.
*
* @return True if this sync is using HTTP or HTTPS, and false otherwise.
*/
public boolean isHTTP();
/**
* Returns the value of the last header received by the server with
the supplied
* name.
*
* @param the header name to the return the value for
*
* @return the last header value associated with the supplied header-name
*
* @see NetworkData#getHTTPHeaderValues
* @see NetworkData#getHTTPHeaders
*/
public String getHTTPHeaderValue( String name );
/**
* Returns all the header values received by the server associated
* with the supplied name.
*
* @param the header name to the return the values for
*
* @return the header values associated with the supplied header-name
*
* @see NetworkData#getHTTPHeaderValue
* @see NetworkData#getHTTPHeaders
*/
public List<String> getHTTPHeaderValues( String name );
/**
* Returns a Map that maps header names to a List of header-values.
*
* @return a Map containing all the headers received by the server.
*
* @see NetworkData#getHTTPHeaderValue
* @see NetworkData#getHTTPHeaderValues
*/
public Map<String, List<String> > getHTTPHeaders();
/**
* Returns true if this sync is using TLS, and false otherwise.
*
* @return True if this sync is using TLS, and false otherwise.
*/
public boolean isTLS();
/**
* Returns a java.security.cert.CertPath containing any certificates
* sent by the client. The certificates are all
* java.security.cert.X509Certificate objects.
*
* This function will return a non-null value only if isTLS() is true,
* the client supplies a certificate using the "identity"
stream
* parameter, and the trusted_certificates option is set on the server.
* A non-null CertPath will contain the certificates in order,
* from the self-signed certificate to the peer certificate.
*
* @return A CertPath containing the X509 certificates that identify
the
* client, or null if no such certificates were provided.
*/
public java.security.cert.CertPath getCertificateChain();
/**
* Returns true if this sync is end-to-end encrypted, and false otherwise.
*
* @return True if this sync is end-to-end encrypted, and false otherwise.
*/
public boolean isEndToEndEncrypted();
}
This method was added to the Java DBConnectionContext class:
/**
* Returns information about the network streams for a synchronization.
* This is useful if you wish to authenticate against some other server
in
* the enterprise using the client-side certificate and HTTP headers.
*
* To enable collection of network stream data, add collect_network_data=1
to
* your -x switches. This adds additional per sync memory overhead
to store
* the data.
*
* @return information about the network streams used for the request,
or
* null if collection has not been enabled.
* @see NetworkData
*/
NetworkData getNetworkData();
The .NET class documentation follows:
namespace iAnywhere.MobiLink.Script
{
/// <summary>
/// Contains information about the network streams for a synchronization.
/// </summary>
/// <remarks>
/// This is useful if you wish to authenticate against some other server
in
/// the enterprise using the client-side certificate and HTTP headers.
///
/// To enable collection of network stream data, add collect_network_data=1
to
/// your -x switches. This adds additional per sync memory overhead
to store
/// the data. If using TLS or HTTPS with client-side certificates,
add
/// trusted_certificates=<certificate file> to have the server
ask the client to send
/// a certificate during the TLS handshake, incurring a time and network
cost.
/// You can obtain a NetworkData object by invoking the getNetworkData
method
/// of the DBConnectionContext class. When using HTTP or HTTPS, it
will contain
/// the header data for the last HTTP request received by the server
before the
/// authenticate scripts are invoked.
///
/// </remarks>
/// <example>
/// The following example shows how to get a NetworkData object from
the
/// DBConnectionContext, and prints the data it contains to the log.
/// <code>
/// using iAnywhere.MobiLink.Script;
/// using System.Collections.Generic;
/// using System.Security.Cryptography.X509Certificates;
///
/// public class OrderProcessor {
/// DBConnectionContext _cc;
///
/// public OrderProcessor( DBConnectionContext cc ) {
/// _cc = cc;
/// }
///
/// public void AuthUser() {
/// NetworkData nd = _cc.NetworkData;
/// if( nd != null ) {
/// if( nd.IsHTTP ) {
/// PrintLn( "http" );
/// string user_agent = nd.GetHTTPHeaderValue( "user-agent"
);
/// PrintLn( " user-agent: " + user_agent.Substring(
0, user_agent.IndexOf( '/' ) ) );
/// } else {
/// PrintLn( "no http" );
/// }
/// if( nd.IsTLS ) {
/// PrintLn( "tls" );
/// X509Certificate2Collection certs = nd.ClientCertificates;
/// if( certs != null ) {
/// PrintLn( " client-side cert:" );
/// int n = 1;
/// foreach( X509Certificate2 x509 in certs ) {
/// PrintLn( " cert " + n++ );
/// PrintLn( " Subject: " + x509.SubjectName.Name
);
/// PrintLn( " Issuer: " + x509.IssuerName.Name
);
/// }
/// } else {
/// PrintLn( " no client cert" );
/// }
/// } else {
/// PrintLn( "no tls" );
/// }
/// if( nd.IsEndToEndEncrypted ) {
/// PrintLn( "e2ee" );
/// } else {
/// PrintLn( "no e2ee" );
/// }
/// } else {
/// PrintLn( "NULL networkdata" );
/// }
/// }
/// }
/// </code>
/// </example>
public interface NetworkData
{
/// <summary>
/// Returns true if this sync is using HTTP or HTTPS, and false otherwise.
/// </summary>
/// <returns>
/// True if this sync is using HTTP or HTTPS, and false otherwise.
/// </returns>
bool IsHTTP {
get;
}
/// <summary>
/// Returns true if this sync is using TLS or HTTPS, and false otherwise.
/// </summary>
/// <returns>
/// True if this sync is using TLS or HTTPS, and false otherwise.
/// </returns>
bool IsTLS {
get;
}
/// <summary>
/// Returns the existing connection to the MobiLink consolidated database.
/// </summary>
bool IsEndToEndEncrypted {
get;
}
/// <summary>
/// Returns the value of the last header received by the server with the
supplied
/// name.
/// </summary>
/// <param name="name"> the header name to the return the
value for </param>
/// <return>
/// The last header value associated with the supplied header-name.
/// </return>
///
/// <seealso cref="GetHTTPHeaderValues"/>
/// <seealso cref="HTTPHeaders"/>
///
string GetHTTPHeaderValue( string name );
/// <summary>
/// Returns all the header values received by the server associated with
/// the supplied name.
/// </summary>
/// <param name="name"> the header name to the return the
values for </param>
/// <return>
/// The header values associated with the supplied header-name.
/// </return>
///
/// <seealso cref="GetHTTPHeaderValue"/>
/// <seealso cref="HTTPHeaders"/>
///
IList<string> GetHTTPHeaderValues( string name );
/// <summary>
/// Returns a dictionary that maps header names to a list of header-values.
/// </summary>
/// <return>
/// A dictionary of header name-value pairs.
/// </return>
///
/// <seealso cref="GetHTTPHeaderValue"/>
/// <seealso cref="GetHTTPHeaderValues"/>
///
IDictionary<string, IList<string> > HTTPHeaders {
get;
}
/// <summary>
/// Returns an X509Certificate2Collection containing any certificates
/// sent by the client.
/// </summary>
/// <remarks>
/// This function will return a non-null value only if isTLS() is
true,
/// the client supplies a certificate using the "identity"
stream
/// parameter, and the trusted_certificates option is set on the server.
/// A non-null CertPath will contain the certificates in order,
/// from the self-signed certificate to the peer certificate.
/// </remarks>
/// <return>
/// An X509Certificate2Collection containing the X509 certificates
that identify
/// the client, or null if no such certificates were provided.
/// </return>
X509Certificate2Collection ClientCertificates {
get;
}
}
}
The following property was added to the .NET DBConnectionContext:
/// <summary>
/// Returns information about the network streams for a synchronization.
/// </summary>
/// <remarks>
/// This is useful if you wish to authenticate against some other server
in
/// the enterprise using the client-side certificate and HTTP headers.
///
/// To enable collection of network stream data, add collect_network_data=1
to
/// your -x switches. This adds additional per sync memory overhead to
store
/// the data.
/// </remarks>
///
/// <returns> information about the network streams used for the
request, or
/// null if collection has not been enabled.
/// </returns>
///
/// <seealso cref="NetworkData"/>
NetworkData NetworkData {
get;
}
================(Build #3557 - Engineering Case #698198)================
The -x option of the MobiLink Server now supports the trusted_certificates
option when encryption is in effect. The option is comparable to and symmetric
with the client-side option of the same name (see Engineering case 696697).
The usage is:
mlsrvXX ... -x tls(...;trusted_certificates=certificate_file) ...
mlsrvXX ... -x https(...;trusted_certificates=certificate_file) ...
Used in the simplest way, the trusted_certificates option provides validation
of clients, but without other capabilities like certificate revocation lists.
To implement a certificate revocation list and otherwise integrate with your
enterprise certificate infrastructure, you'll need to make use of the NetworkData.ClientCertificates
API, described in the email forwarded below.
The simplest example to illustrate this is:
client --> ML server --> Enterprise certificate infrastructure
Use the trusted_certificates option to ensure the client certificate is
valid, then use the NetworkData.ClientCertificates API to further authenticate
the certificate in the authenticate_user script (written in Java or .NET).
================(Build #3540 - Engineering Case #693344)================
The MobiLink server and clients now support certificates signed using SHA-2.
Previously, only MD5 and SHA-1 were supported.
Also, the Certificate Viewer utility (viewcert) will now also correctly
display the signature algorithm for certificates signed using SHA-2.
================(Build #3727 - Engineering Case #706817)================
The Certificate Creation and Certificate Viewer utilities (createcert and
viewcert) will now encode unencrypted RSA private keys using PKCS #1 instead
of PKCS #8, if provided a new '-p1' option. This is useful when creating
certificates for use with Apache since it expects unencrypted RSA private
keys to be encoded using PKCS #1 (SQL Anywhere software always expects private
keys to be encoded with PKCS #8). Encrypted keys and ECC keys will continue
to be encoded using PKCS #8 regardless of whether the '-p1' option is specified.
================(Build #3490 - Engineering Case #688892)================
When running mlgenreplayapi with a non-existent recorded protocol file, and/or
using the -d switch with a non-existent directory, no error messages was
displayed at the console. However, if the -o or -ot switch was used, the
errors were logged in the log file. Now, if no -o or -ot options are specified
for mlreplay and mlgenreplayapi, all output goes to stdout.
As well, mlgenreplayapi will now create the directory specified by the -d
option (the directory in which to put the generated code) when it does not
exist.
================(Build #3347 - Engineering Case #668832)================
The dblsn command line option -qi prevents the tray icon or window from being
displayed. This behaviour is identical to the -qi option of the database
server. The option has existed since 11.0.1, but was not referenced in the
usage text or the documentation. The usage text has been corrected
================(Build #3758 - Engineering Case #713388)================
Support for the latest release of .NET Framework, .NET 4.5, has now been
added. The following features are new in the .NET Framework 4.5 RC:
1. Asynchronous Programming
The new asynchronous programming feature provides a simple technique to
make code asynchronous.
Asynchronous code can make the user interface of client applications more
responsive, it can also make server applications more scalable. Writing asynchronous
code has traditionally involved installing a callback (also called continuation)
to express the logic that occurs after the asynchronous operation finishes.
This complicates the structure of asynchronous code as compared with synchronous
code.
.NET 4.5 allows call into asynchronous methods without using callbacks,
and without splitting code across multiple methods or lambda expressions.
The 'async' modifier specifies that a method is asynchronous. When calling
an async method, a task is returned. When calling an 'await' statement against
the task, the current method exits immediately. When the task finishes, execution
resumes in the same method.
Calling an async method does not allocate any additional threads. It may
use the existing I/O completion thread briefly at the end.
The following methods were added in SQL Anywhere ADO.NET provider to support
asynchronous programming:
SAConnection.OpenAsync
SACommand.ExecuteDbDataReaderAsync
SACommand.ExecuteNonQueryAsync
SACommand.ExecuteReaderAsync
SACommand.ExecuteScalarAsync
SADataReader.GetFieldValueAsync
SADataReader.IsDBNullAsync
SADataReader.NextResultAsync
SADataReader.ReadAsync
SABulkCopy.WriteToServerAsync
Here are some examples:
internal async Task Execute()
{
using (SAConnection conn = new SAConnection("DSN=SQL Anywhere
16 Demo"))
{
SACommand command = new SACommand("select 1", conn);
int result = MethodAsync(conn, command).Result;
command = new SACommand("select top 10 * from SalesOrders",
conn);
using (DbDataReader reader = await command.ExecuteReaderAsync())
{
while (await reader.ReadAsync())
Console.WriteLine(String.Format("{0}", reader[0]));
}
}
}
private async Task<int> MethodAsync(SAConnection conn, SACommand
cmd)
{
await conn.OpenAsync();
await cmd.ExecuteNonQueryAsync();
return 1;
}
private async Task ExecuteSqlTransaction()
{
using (SAConnection connection = new SAConnection("DSN=SQL
Anywhere 16 Demo"))
{
await connection.OpenAsync();
SACommand command = connection.CreateCommand();
SATransaction transaction = await Task.Run<SATransaction>(()
=> connection.BeginTransaction());
command.Connection = connection;
command.Transaction = transaction;
command.CommandText = "Delete From Departments Where (DepartmentID
= 777 OR DepartmentID = 888)";
await command.ExecuteNonQueryAsync();
command.CommandText = "Insert into Departments(DepartmentID,
DepartmentName) VALUES (777, 'HR')";
await command.ExecuteNonQueryAsync();
command.CommandText = "Insert into Departments(DepartmentID,
DepartmentName) VALUES (888, 'Supporting')";
await command.ExecuteNonQueryAsync();
await Task.Run(() => transaction.Commit());
Console.WriteLine("Both records are written to database.");
}
}
private async Task AsyncSqlBulkCopy()
{
using (SAConnection conn = new SAConnection("DSN=SQL Anywhere
16 Demo"))
{
await conn.OpenAsync();
DataTable dt = new DataTable();
using (SACommand cmd = new SACommand(selStmt, conn))
{
SADataAdapter adapter = new SADataAdapter(cmd);
adapter.Fill(dt);
using (SABulkCopy bcp = new SABulkCopy(conn))
{
bcp.DestinationTableName = destTable;
await bcp.WriteToServerAsync(dt);
}
}
}
}
2. SACredential class.
A new class SACredential has been added for setting the credentials outside
of the connection string via the new Credential property of SAConnection.
Now the developer can create a SACredential object with a UserId and a SecureString
Password to hold the credential values of a connection. This helps mitigate
the memory dump vulnerability of keeping the User Name and Password in the
connection string.
Here's an example:
private void OpenConnection()
{
SecureString password = new SecureString(); // txtPassword.SecurePassword;
password.MakeReadOnly();
SACredential credential = new SACredential( "dba", password
);
using ( SAConnection conn = new SAConnection( "DSN=SQL Anywhere
16 Demo", credential ) )
{
conn.Open();
}
}
================(Build #3714 - Engineering Case #703288)================
When using a "managed resource only" deployment (such as Microsoft's
ClickOnce) for .NET applications, delivering SQL Anywhere native dlls through
this mechanism may have been a problem. A demonstration project DeploymentUtility
(with source code) has been added to help with this. It adds SQL Anywhere
native dlls as embedded resources, and copies them to a local drive when
a .NET application is deployed.
================(Build #3706 - Engineering Case #701776)================
Support has now been added for Visual Studio 2012. The utility SetupVSPackage
will now create the proper registry keys for Visual Studio 2012.
================(Build #3594 - Engineering Case #700458)================
Support has now been added to the SQL Anywhere ADO.NET provider for latest
release of Microsoft Entity Framework - EF 4.3. The major new feature of
EF 4.3 is migration tools which enable the user to keep track of the data
model changes.
================(Build #3495 - Engineering Case #689781)================
The ADO .Net provider now supports Microsoft Entity Framework 4.2. To use
the new Entity Framework 4.2, it must be added to Visual Studio projects
using the Visual Studio tool NuGet.
================(Build #3429 - Engineering Case #682773)================
EF 4.1 is the latest release of Microsoft Entity Framework. The major new
feature of EF 4.1 is "Code First". Support has now been added for
Code First.
Code First enables a different development workflow: defining data model
objects by simply writing C# or VB.NET classes mapping to database objects
without ever having to open a designer or define an XML mapping file. Optionally,
additional configuration can be performed by using data annotations or the
Fluent API. Model can be used to generate a database schema or map to an
existing database.
Here's an example which creates new database objects using the model:
using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Linq;
using iAnywhere.Data.SQLAnywhere;
namespace CodeFirstExample
{
[Table( "EdmCategories", Schema = "DBA" )]
public class Category
{
public string CategoryId { get; set; }
[MaxLength( 64 )]
public string Name { get; set; }
public virtual ICollection<Product> Products { get; set; }
}
[Table( "EdmProducts", Schema = "DBA" )]
public class Product
{
public int ProductId { get; set; }
[MaxLength( 64 )]
public string Name { get; set; }
public string CategoryId { get; set; }
public virtual Category Category { get; set; }
}
[Table( "EdmSuppliers", Schema = "DBA" )]
public class Supplier
{
[Key]
public string SupplierCode { get; set; }
[MaxLength( 64 )]
public string Name { get; set; }
}
public class Context : DbContext
{
public Context() : base() { }
public Context( string connStr ) : base( connStr ) { }
public DbSet<Category> Categories { get; set; }
public DbSet<Product> Products { get; set; }
public DbSet<Supplier> Suppliers { get; set; }
protected override void OnModelCreating( DbModelBuilder modelBuilder
)
{
modelBuilder.Entity<Supplier>().Property( s => s.Name
).IsRequired();
}
}
class Program
{
static void Main( string[] args )
{
Database.DefaultConnectionFactory = new SAConnectionFactory();
Database.SetInitializer<Context>( new DropCreateDatabaseAlways<Context>()
);
using ( var db = new Context( "DSN=SQL Anywhere 12 Demo"
) )
{
var query = db.Products.ToList();
}
}
}
}
Here's another example which maps to an existing database:
using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Linq;
using iAnywhere.Data.SQLAnywhere;
namespace CodeFirstExample
{
[Table( "Customers", Schema = "GROUPO" )]
public class Customer
{
[Key()]
public int ID { get; set; }
public string SurName { get; set; }
public string GivenName { get; set; }
public string Street { get; set; }
public string City { get; set; }
public string State { get; set; }
public string Country { get; set; }
public string PostalCode { get; set; }
public string Phone { get; set; }
public string CompanyName { get; set; }
public virtual ICollection<Contact> Contacts { get; set; }
}
[Table( "Contacts", Schema = "GROUPO" )]
public class Contact
{
[Key()]
public int ID { get; set; }
public string SurName { get; set; }
public string GivenName { get; set; }
public string Title { get; set; }
public string Street { get; set; }
public string City { get; set; }
public string State { get; set; }
public string Country { get; set; }
public string PostalCode { get; set; }
public string Phone { get; set; }
public string Fax { get; set; }
[ForeignKey( "Customer" )]
public int CustomerId { get; set; }
public virtual Customer Customer { get; set; }
}
public class Context : DbContext
{
public Context() : base() { }
public Context( string connStr ) : base( connStr ) { }
public DbSet<Contact> Contacts { get; set; }
public DbSet<Customer> Customers { get; set; }
}
class Program
{
static void Main( string[] args )
{
Database.DefaultConnectionFactory = new SAConnectionFactory();
Database.SetInitializer<Context>( null );
using ( var db = new Context( "DSN=SQL Anywhere 12 Demo"
) )
{
foreach ( var customer in db.Customers.ToList() )
{
Console.WriteLine( "Customer - " + string.Format(
"{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9}",
customer.ID, customer.SurName, customer.GivenName,
customer.Street, customer.City,
customer.State, customer.Country, customer.PostalCode,
customer.Phone, customer.CompanyName ) );
foreach ( var contact in customer.Contacts )
{
Console.WriteLine( " Contact - " +
string.Format( "{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}, {9}, {10}",
contact.ID, contact.SurName, contact.GivenName,
contact.Title, contact.Street, contact.City,
contact.State, contact.Country, contact.PostalCode,
contact.Phone, contact.Fax ) );
}
}
}
}
}
}
Additional assembly references need to be add to run these examples: EntityFramework,
iAnywhere.Data.SQLAnywhere.v4.0, System.ComponentModel.DataAnnotations, System.Data.Entity.
================(Build #3338 - Engineering Case #667520)================
A new command line option 'uninstallall' (or 'ua') has been added to SetupVSPackage.exe.
When specified, the 'uninstallall' option will cause SetupVSPackage to remove
all versions of SQL Anywhere assemblies from the Global Assembly Cache.
For example:
SetupVSPackage.exe /ua
================(Build #3292 - Engineering Case #659363)================
The Timeout, SendBufferSize, and ReceiveBufferSize TCP options now have upper
limits. Values specified above these limits will result in connection failure
(-832). The limits are:
Timeout: 3600 seconds
SendBufferSize: 1048576 bytes (1 MB)
ReceiveBufferSize: 1048576 bytes (1 MB)
================(Build #3515 - Engineering Case #691979)================
The SQL Anywhere JDBC 4 Driver (sajdbc4.jar) now contains the proper manifest
information to allow it to be loaded as an OSGI bundle.
================(Build #3371 - Engineering Case #674389)================
On Windows desktop platforms, the Winsock version 1 library has been replaced
by the Winsock version 2 library. As a result, Wsock32.lib has been replaced
by Ws2_32.lib. A few applications (MobiLink, Relay Server) that need Microsoft
additional functionality, such as TransferFile, also include Mswsock.lib.
The result is the elimination of the Wsock32 DLL and a smaller execution
time footprint (36K less).
Note, this change also affects the ADO .NET provider, the OLE DB provider,
MobiLink server, Relay Server Outbound Enabler, database server, all SA software
requiring TCPIP running on Windows.
================(Build #3466 - Engineering Case #685973)================
If a user's path contained a large number of directories and/or contained
directories located on mapped network drives, the first connection attempt
made by an application could have been slow. This has been fixed. A workaround
is to create an empty file called saldap.ini (assuming the LDAP feature is
not being used) in the installation bin32/bin64 directory.
================(Build #3284 - Engineering Case #657471)================
The PHP external environment and the PHP driver now support PHP versions
5.3.3, 5.3.4, and 5.3.5.
================(Build #3711 - Engineering Case #700997)================
On Windows systems, the error "R6025 - pure virtual function call"
would have caused a dialog box to be opened, even if the executable should
not interact with the desktop. This has been fixed so that no dialog box
is now opened.
================(Build #3625 - Engineering Case #691732)================
The database server now accepts the -gta command line option to control which
logical processors the database server is permitted to use. The argument
to -gta is a comma-separated list of processor numbers and/or ranges.
For example:
-gta 3,5-7
allows the database server to run on processors 3, 5, 6 and 7.
The lower endpoint of a range may be omitted in which case it is assumed
to be zero. The upper endpoint of a range may be omitted in which case it
is assumed to be the highest cpu known to the OS. The database server will
only use logical processors specified by -gta but it may not use all of them
if the license does not allow it, or if one or more of the specified logical
processors does not exist or is offline. If the set of processors specified
by -gta exceeds the license limits, the server will use the lowest-numbered
logical processors specified by -gta up to but not exceeding the license
limits. In particular, the server does not choose logical processors in the
order listed by -gta and it does not attempt to maximize concurrency within
the license limit and the specified
-gta option. If the set of processors specified by -gta does not match any
online processors, the server acts as if -gta was not specified and uses
up to the licensed number of processors starting at processor 0.
Note that -gta cannot be used at the same time as -gt or -gtc. A usage message
will be
displayed when -gta is used with either -gt or -gtc.
================(Build #3605 - Engineering Case #696064)================
A new collation '1252BIN' has been added that is based on the windows-1252
character set but has a binary sort ordering. As with the other binary collations,
ordering isn't quite binary when it is used in a case-insensitive database.
For case-insensitve 1252BIN collations, upper case letters A-Z sort as if
they were lower case (ie, greater than the backquote '`' character).
================(Build #3579 - Engineering Case #695258)================
A new connection-level property 'NumLocalTempTables' has been added that
returns the number of local temporary tables in use by the connection. Note
that even when a local temporary table is dropped or falls out of scope,
it is still considered to be "in use" until the next commit.
================(Build #3553 - Engineering Case #696323)================
Localized server resources for the French language have now been enabled
on Linux systems.
================(Build #3518 - Engineering Case #692243)================
The [NOT|AUTO] COMPRESSED option is now supported in the OPTIONS list of
the OPENSTRING clause. This is useful for reading in files created using
UNLOAD with the COMPRESSED option.
================(Build #3517 - Engineering Case #692127)================
A new database server property, 'ProcessID', has been added. This proberty
returns the PID of the server process.
================(Build #3508 - Engineering Case #691168)================
Load table operations were not permitted on temporary tables in a read-only
database, even though other DML operations (INSERT/UPDATE/DELETE/TRUNCATE)
were. This has been fixed.
Note, as expected no data is logged to the transaction log in this case.
================(Build #3507 - Engineering Case #691167)================
The request timing counters record the number of times, and the duration,
a connection blocks waiting for various resources (disk accesses, locks,
etc.). These counters were normally only available when the server was run
with the -zt option, or when enabled with sa_server_option('RequestTiming',
'on'). As of this change, the ReqTimeBlockIO and ReqCountBlockIO properties
are always available, regardless of the -zt setting. These properties are
cheap to maintain, relative to the others, because the time required to wait
for a disk access is much larger than that required to update the property.
================(Build #3489 - Engineering Case #688888)================
The ENCRYPTED KEY option of the OPENSTRING clause can now specify a variable
name rather than a string.
For example:
create variable mykey varchar(50);
set mykey='TheActualEncryptionKey';
select * from openstring(...) with (...) option (encrypted key mykey);
================(Build #3418 - Engineering Case #678806)================
The ENCRYPTED KEY '<key>' clause is now supported in the openstring
OPTIONS clause. This is useful for reading in files created using UNLOAD
with the ENCRYPTED clause.
================(Build #3393 - Engineering Case #677104)================
Current login policy allowed putting a restriction over the number of failed
login attempts a user can make before the user's account is locked. However,
this restriction did not apply to users with DBA authority. Regardless of
the number of failed login attempts, a DBA user was always allowed to login
if correct credentials are provided. This made DBA accounts vulnerable to
brute force attacks. This has been changed with the new option, max_failed_login_attempts.
The value of this option is also applied to users with DBA authority. However,
to prevent complete database lock down, an automatic unlock time of 1 minute
is also applied. At the time of database restart, a DBA user will also be
allowed to make one failed login attempt, regardless of the number of failed
login attempts stored in the catalog.
================(Build #3370 - Engineering Case #673210)================
The NodeType connection parameter is used by read-only scale-out to possibly
redirect a connection to a different server. Previously, NodeType supported
the values DIRECT, PRIMARY and COPY. Support has now been added for MIRROR
and READONLY values.
MIRROR - When the NodeType connection parameter is set to MIRROR, and you
have connected to a copy node or the primary server, the connection is redirected
to the mirror server.
READONLY - When the NodeType connection parameter is set to READONLY, and
you have connected to a copy node or the primary server, the connection is
redirected to the copy node in its branch with the lowest load. If there
are no copy nodes, the connection is redirected to the mirror server. If
you have connected to the mirror node the connection is accepted since the
mirror server does not know the status of the copy nodes. READONLY is used
to connect to any read-only server, either a copy node or the mirror.
================(Build #3338 - Engineering Case #667668)================
The following two extensions have been made to the -xa option:
1) The dbn= value can be "*", which means any database can use
this server as an arbiter.
2) The auth= value can be:
a) omitted, which means no validation of the authentication string provided
by a mirror server is done.
b) a single value, which means all databases must use the same authentication
string.
c) a list of values with the same number of entries as specified by dbn=
(i.e. previous behavior)
================(Build #3287 - Engineering Case #657712)================
Additional information is now saved for graphical and long plans. This additional
information includes:
- Known values for expressions are now dumped in the plans. For example,
a stored procedure parameter known at the optimization time is dumped as
'parm1[100]' if its name is 'parm1' and its known value is '100'.
- For long plans generated by the application profiling, extra information
related to the optimization process is now dumped. For example, 'Plan [ Total
Cost Estimate: 3.5657, Costed Best Plans: 1, Costed Plans: 13, Optimization
Time: 0.074541, Estimated Cache Pages: 590 ]' This type of information is
already present for long plans generated by calling the explanation() function.
- Information related to the cached plan of a statement is now dumped in
its long plan.
- Predicates used to generate fence posts for a partial index scan are now
dumped in the long plans generated by the application profiling. This type
of information is already present for long plans generated by calling the
explanation() function.
Also, graphical plans with statistics saved during tracing did not actually
contain any statistics. This has been fixed.
================(Build #3707 - Engineering Case #704191)================
Changes have been made to Sybase Central to allow it to run with the Java
1.7 runtime.
Note, this change also relates to the Interactive SQL utility as well. Sybase
Central and the Interactive SQL utility were not reviewed for compatibility.
================(Build #3589 - Engineering Case #699988)================
When Sybase Central attempted to execute SQL that used a secured feature,
an error would have been reported immediately. Now, a prompt is displayed,
allowing the server's secure feature key to be specified, after which the
original SQL statement is re-executed.
Note that the server must be started with a secure feature key (-sk) to
make use of this feature.
================(Build #3596 - Engineering Case #701470)================
The Certificate Viewer utility (viewcert) now accepts the -q parameter, which
will suppress all output from the command, including error messages.
================(Build #3561 - Engineering Case #697020)================
Parameters for the Certificate Viewer utility (viewcert) can now be put into
a response data file and viewcert can be called as: viewcert @data.
================(Build #3363 - Engineering Case #672080)================
The following new entry point has been added to the dbtools library:
DBLogFileInfo function
Obtains the log file and mirror log file information of a non-running database.
Prototype
short DBLogFileInfo ( const a_log_file_info * );
Parameters
A pointer to a structure. See a_log_file_info structure
.
Return value
A return code, as listed in Software component exit codes
.
Remarks
The DBLogFileInfo function returns the log file and mirror log file paths
of a non-running database file. Note that this entry point will only work
for databases that have been created with SQL Anywhere 10.0.0 and up.
-----------------------------------------------
Here is the necessary information for the new a_log_file_info structure:
typedef struct a_log_file_info {
unsigned short version; // set this to DB_TOOLS_VERSION_NUMBER
MSG_CALLBACK errorrtn;
const char * dbname; // database file name spec
const char * encryption_key; // database file encryption key
char * logname; // buffer for returning log file name
size_t logname_size; // size of the logname buffer
char * mirrorname; // buffer for returning mirror log file name
size_t mirrorname_size; // size of the mirrorname buffer
void * reserved; // reserved for internal use, must set to NULL
} a_log_file_info;
================(Build #3300 - Engineering Case #662054)================
When deploying, the directory used by the Interactive SQL utility, Sybase
Central, the Console utility, and the MobiLink Monitor, can now be specified.
To do this, an OEM.ini file must be deployed along with these utilities.
The file must contain the following lines:
[preferences]
directory={preferences files directory|
where "preferences_files_directory" is a fully-qualified directory
name, e.g. "c:\work\prefs". The directory name should not end
in a separator (backslash on Windows; forward slash on Unix and Mac OS X).
Preferences files include:
.isqlPreferences12_32
.isqlPreferences12_64
.isqlHistory12
.jlogon12
.textCompleter12
.SybaseCentralEditor610
.scUserPreferences610_32
.scUserPreferences610_64
among others.
================(Build #3299 - Engineering Case #661493)================
The certificate utilities, Certificate Viewer (viewcert), Certificate Creation
(createcert), and Key Pair Generator (createkey), now run on 64-bit Windows.
================(Build #3346 - Engineering Case #668757)================
SQL Remote for SQL Anywhere (dbremote) now supports HTTP and HTTPS as a message
type for SQL Remote messages for remote databases. Users wishing to use the
HTTP or HTTPS message type from a remote database will configure the remote
database using the SET REMOTE OPTION command, in the same way that the FILE,
FTP and SMTP message type is configured. The HTTP/HTTPS message type uses
the following control parameters that are set by the SET REMOTE OPTION statement:
• url : Specify the server name or IP address and optionally the port number
of the HTTP server being used, separated by a semi-colon. If requests are
being passed through the Relay Server, you can optionally add an URL suffix
to indicate which server farm the request should be passed to. url=’server-name[:port-number][url_suffix]’
• https : Specify whether to use HTTPS (https=YES) or HTTP (https=NO).
• certificate : To make a secure (HTTPS) request, a client must have access
to the certificate used by the HTTPS server. The necessary information is
specified in a string of semicolon-separated key/value pairs. You can use
the file key to specify the file name of the certificate, or you can use
the certificate key to specify the server certificate in a string. You cannot
specify a file and certificate key together. The following keys are available:
file : The file name of the certificate.
certificate : The certificate itself.
company : The company specified in the certificate.
unit : The company unit specified in the certificate.
name : The common name specified in the certificate.
Certificates are required only for requests that are either directed to
an HTTPS server, or can be redirected from a non-secure to a secure server.
Only PEM formatted certificates are supported.
certificate=’key=value[:key=value]'
• user : The HTTP server user ID. Authenticates to third-party HTTP server
and gateways using RFC 267 Basic Authentication. user=’userid’
• password : The HTTP server password. Authenticates to third-party HTTP
server and gateways using RFC 267 Basic Authentication. password=’password’
• debug : When set to YES, all HTTP commands and response are displayed
in the output log. This information can be used for troubleshooting HTTP
support problems. The default is NO.
• proxy : Specifies the URI of a proxy server. For use when SQL Remote must
access the network through a proxy server. Indicates that SQL Remote is to
connect to the proxy server and send the request to the message server through
it. proxy=’http://proxy-server[:port-number]’
• client_port : Identifies the port number on which SQL Remote communicates
using HTTP. It is provided for and recommended only for connections through
firewalls that filter "outgoing" TCP/IP connections. You can specify
a single port number, ranges of port numbers, or a combination of both. Specifying
a low number of client ports could result in SQL Remote being unable to send
and receive messages if the operating system has not released the ports in
a timely manner after SQL Remote closes the port on a previous run. client_port=’nnnn[-mmmm]’
Unlike the FTP or SMTP message type, which relies on a third-party FTP or
E-mail server, the HTTP message type makes use of the web services functionality
that exists in the SQL Anywhere database engine to act as
the HTTP server, which we refer to as a "message server". In order
to setup the message server, you only need to run the sr_add_message_server
on the consolidated database, and ensure that the database server has
been started with the -xs http[s] switch. If starting the HTTP[S] listener
on a database server hosting the consolidated database is a performance or
security concern, then you can use a separate database server, as long as
the database you run sr_add_message_server on has identical SQL Remote definitions
to your consolidated database. For more information on how to setup a consolidated
database to be a message server, how to setup a separate message server,
or how to use the Relay Server to forward HTTP requests from remote database
to the message server, please read the tutorials and full documentation.
The SQL Remote documentation has been updated to include information about
the new message type. In the SQL Anywhere installation directory, see:
documentation/en/pdf/sqlremote1201.pdf
================(Build #3276 - Engineering Case #655157)================
If there were any missing messages, SQL Remote would have asked for a resend
after it had reached its receive polls given by the -rp option. This resend
logic could have caused the publisher to re-scan the transaction log(s) and
slow down replicating new transactions, especially on heavy load databases.
This has been changed so that when a message in a multi-part message series
(SQL Remote will generate multiple messages for a single transaction to form
a multi-part message when the transaction is too big to fit in a single message)
is missing, SQL Remote will not immediately ask for a resend, if the received
messages are not followed by any messages that contain a commit or any messages
that belong to another multi-part message series. This new logic will help
users who
need to shut down or kill SQL Remote when it is sending multi-part messages
to its subscribers.
================(Build #3713 - Engineering Case #701779)================
For the UltraLite C++ API, methods using wide characters (UTF-16/UCS-2) are
generally only supported for Win32. This change adds wide character support
for the character data streaming methods, on iOS. The affected methods are:
ULPreparedStatement::AppendParameterStringChunk
ULResultSet::GetStringChunk
ULResultSet::AppendStringChunk
================(Build #3480 - Engineering Case #687980)================
UltraLite is now supported on the Pocket PC 2003 platform. Support for TLS
and HTTPS sync encryption, however, is not available for this platform.
================(Build #3339 - Engineering Case #667716)================
A new name type ul_name_type_qualified has been added to ul_column_name_type
in tjhe header ulcpp.h. When this new name type is used in conjunction with
the GetColumnName function in the ULResultSetSchema class, a qualified name
for the associated column in the ResultSet can be obtained, if possible.
If the column represents a correlated table, then that qualified name is
used; if the column represents a table column, then that qualified name is
used; if the column has an alias name, then that name is used. Otherwise,
an empty string is returned.
================(Build #3308 - Engineering Case #663307)================
UltraLite now supports the 'armv7' architecture when targeting iOS. With
the just-released Xcode and SDK versions, the default includes armv7.
================(Build #3292 - Engineering Case #659615)================
Some internal optimization algorithms have been generalized and improved.
This may change plans for queries.
================(Build #3747 - Engineering Case #708638)================
UltraLitej for BlackBerry now supports end-to-end stream encryption. Some
methods that were previously Android-only are now available for other platforms:
/** Sets the name of the file containing the end-to-end public key.
* <p>
* By default, this value is null, indicating that end-to-end encryption
is
* not used.
* <p>
* Corresponds to MobiLink client network protocol option "e2ee_public_key".
*
* @param public_key The name of RSA public key file used in the encryption.
*/
public void setE2eePublicKey( String public_key );
/** Get the name of the file containing the end-to-end public key.
*
* @return the name of the file containing the end-to-end public key.
*/
public String getE2eePublicKey();
And there are also BlackBerry-specific methods to change the encryption
type. ECC end-to-end encryption is available only for BlackBerry.
/**
* Pass this to setE2eeType to use RSA-based end-to-end encryption
*/
public final short E2EE_RSA = 0;
/**
* Pass this to setE2eeType to use ECC-based end-to-end encryption
*/
public final short E2EE_ECC = 1;
/**
* Set the type of end-to-end encryption to use. Pass one of StreamHTTPParms.E2EE_RSA
or
* StreamHTTPParms.E2EE_ECC. The default is StreamHTTPParms.E2EE_RSA.
* <p>
* Only available on BlackBerry. ECC encryption is not supported on
other platforms.
*
* @see StreamHTTPParms.E2EE_RSA
* @see StreamHTTPParms.E2EE_ECC
* @param type One of E2EE_RSA or E2EE_ECC
*/
public void setE2eeType( short type );
/**
* Returns the end-to-end encryption type being used.
* <p>
* Only available on BlackBerry. ECC encryption is not supported on
other platforms.
* @return the end-to-end encryption type being used
*/
public short getE2eeType();
The public key used must be DER encoded.
The public key needed for end-to-end encryption can either be stored on
an SD card or the device object store. When using an SD card, the parameter
to setPublicKey should have the form "sdcard://<path>" where
"<path>" is the absolute path to the file on the card. e.g.
"file:///SDCard/ulj/public_key.der". When using the object store,
use the file transfer utility built into ULj to download the file from the
MobiLink server. To use file transfer to transfer a key it must have an
extension of ".der".
================(Build #3747 - Engineering Case #708578)================
UltrLitej for BlackBerry and J2SE now support zlib stream compression. Some
methods that were previously Android-only are now available for other platforms:
/** Enables or disables ZLIB compression.
* <p>
* By default, ZLIB compression is disabled
* <p>
* Only available for Android and BlackBerry
* <p>
* Corresponds to MobiLink client network protocol option "compression=zlib".
*
* @param enable Set to true to enable ZLIB compression, or false to
disable
* ZLIB compression.
*/
public void setZlibCompression( boolean enable );
/** Sets the download window size for ZLIB compression.
* <p>
* Only available for Android and BlackBerry
* <p>
* Corresponds to MobiLink client network protocol option "zlib_download_window_size".
*
* @param size The compression window size specification, inclusively
* ranging from 9 to 15. This parameter is the base two
* logarithm of the window size. (the size of the history
* buffer)
*/
public void setZlibDownloadWindowSize( int size );
/** Sets the upload window size for ZLIB compression.
* <p>
* Only available for Android and BlackBerry
* <p>
* Corresponds to MobiLink client network protocol option "zlib_upload_window_size".
*
* @param size The compression window size specification, inclusively
* ranging from 9 to 15 for Android and 10 to 15 for BlackBerry.
* This parameter is the base two
* logarithm of the window size. (the size of the history
* buffer)
*/
public void setZlibUploadWindowSize( int size );
================(Build #3747 - Engineering Case #708576)================
UltraLitej for BlackBerry and J2SE now support basic HTTP authentication.
New methods have been added to StreamHTTPParms:
/**
* Sets the userid and password used for Basic HTTP authentication as
* described in RFC 2617.
* <p>
* With Basic authentication, passwords are included in HTTP headers
in
* clear text; however, you can use HTTPS to encrypt the headers and
* protect this password.
*
* @param userid The userid to use
* @param password The password to use
*/
public void setHTTPUserIDAndPassword( String userid, String password
);
/**
* Returns the userid previously set by setHTTPUserIDAndPassword.
*
* @returns The userid previously set by setHTTPUserIDAndPassword
*/
public String getHTTPUserID();
/**
* Returns the password previously set by setHTTPUserIDAndPassword.
*
* @returns The password previously set by setHTTPUserIDAndPassword
*/
public String getHTTPPassword();
================(Build #3747 - Engineering Case #708575)================
UltraLitej for BlackBerry and J2SE now support custom HTTP headers. New
methods have been added to StreamHTTPParms:
/** Adds a message header to each HTTP request. If addCustomHTTPHeader
is called
* more than once with the same name parameter, the values are concatenated
together
* into a comma-seperated list.
* <p>
* The following standard headers are set by ULj and cannot be changed
using
* addCustomHTTPHeader: Connection, Content-Length, User-Agent, Content-Type,
and
* Content-Length. Other headers may also be modified by the Java VM.
* <p>
* Not available on Android. On Android, specify a custom_header parameter
using
* setExtraParameters
*
* @param name The name of the header
* @param value The value of the header
*/
public void addCustomHTTPHeader( String name, String value );
/** Returns a Hashtable containing the HTTP headers specified using
addCustomHTTPHeader
*
* @return Returns a Hashtable containing the HTTP
* headers specified using addCustomHTTPHeader
*/
public java.util.Hashtable getCustomHTTPHeaders();
Custom cookies can be specified by calling addCustomHTTPHeader with "Cookie"
as the header name.
================(Build #3741 - Engineering Case #709898)================
UltraLiteJ for Android now supports changing the database encryption key
as documented for UltraLite.
The following API was added:
Connection.changeEncryptionKey( String newKey )
For consistency the following APIs were added, which are equivalent to setDatabaseKey
and getDatabaseKey respectively:
ConfigPersistent.setEncryptionKey( String key )
String ConfigPersistent.getEncryptionKey()
================(Build #3723 - Engineering Case #705847)================
UltraLiteJ for Android now supports restartable downloads as documented for
C UltraLite.
The following APIs have been added:
Connection.rollbackPartialDownload()
SyncParms.setAdditionalParms( String v )
SyncParms.getAdditionalParms()
SyncParms.setKeepPartialDownload( boolean c )
SyncParms.getKeepPartialDownload()
SyncParms.setResumePartialDownload( boolean c )
SyncParms.getResumePartialDownload()
SyncResult.getPartialDownloadRetained()
================(Build #3712 - Engineering Case #703229)================
Performance improvements have been made when adding rows sequentially into
an index. For example, a table whose primary key consists of an autoincrement
column, or an initial download with a download cursor that sorts the download
by primary key. When doing single inserts, UltraLiteJ now does less page
reads and writes. When doing a block of inserts, the page read and writes
may remain the same but CPU work has been greatly reduced.
================(Build #3605 - Engineering Case #702006)================
Indexes in UltraLiteJ now support index hashing using the "WITH MAX
HASH SIZE x " SQL clause. Index hashing improves inserts, updates, deletes
and searches when the columns being indexed have a good distribution of values
(for example strings that do not have a common prefix) at the cost of bigger
index structures. Hashed indexes locate rows first using the hash, then
direct row comparison to differentiate rows with the same hash value. If
the hash size is sufficiently big, the hash will uniquely identify a row
without needing to read and compare the row. However, if the hash size is
too big and the page size small, the index may need too many database pages
whose maintenance costs offset the benefits of hashing. Columns of type REAL,
DOUBLE, GEOMETRY, LONG BINARY and LONG VARCHAR are not hashed (LONG columns
cannot be indexed in UltraLiteJ). If the SQL statement creating an index
does not specify a hash size, the value of the Connection.OPTION_MAX_HASH_SIZE
option is used as the default.
In addition to hashing support, performance improvements were made to indexing
to reduce the number of pages written when committing inserts, updates and
deletes.
================(Build #3605 - Engineering Case #701654)================
With UltraLiteJ for Android, the validateDatabase method has been added to
the Connection class:
public void validateDatabase(
int flags,
ValidateDatabaseProgressListener listener,
String tableName )
The interfaces ValidateDatabaseProgressData, and ValidateDatabaseProgressListener
have also been added.
================(Build #3550 - Engineering Case #696240)================
With UltraLiteJ for Android, the MobiLink file transfer APIs, similar to
those for UltraLiteJ for J2SE and BlackBerry, are now supported. Specifically,
the method DatabaseManager.createFileTransfer( String fileName, int streamType,
String userName, String version ) is supported, as are the interfaces FileTransfer,
FileTransferProgressData, and FileTransferProgressListener.
================(Build #3533 - Engineering Case #694022)================
In UltraLiteJ for Android, the API StreamHTTPParms.setExtraParameters( String
) has now been added.
The classes StreamHTTPParms/StreamHTTPSParms contain a number of methods
to set MobiLink client network protocol options as properties, eg. setHost(
String ). However, there were no methods to cover all possible MobiLink
client network protocol options. This API can now be used to specify a semi-colon-delimted
list of options that are appended to the options that are generated by the
property settings for the class. The meaning of the option list for this
API is as specified in the documentation of MobiLink client network protocol
options.
================(Build #3517 - Engineering Case #690250)================
The UltraLiteJ runtime now supports restartable HTTP synchronizations. With
restartable HTTP enabled, UltraLiteJ applications can tolerate network interruptions,
so synchronizations will fail less often on unreliable networks. Restartable
HTTP is disabled by default. To enable, use the following new methods on
the StreamHTTPParms class:
/**
* Enables or disables restartable HTTP. With restartable HTTP enabled,
* UltraLiteJ can tolerate network interruptions, so synchronizations
will fail
* less often on unreliable networks.
* <p>
* To use restartable HTTP, both UltraLiteJ and the MobiLink server
must have
* applied CR#690250.
*
* @param isRestartable Pass true to enable restartable HTTP, and false
to
* disable. The default is false.
* @see #isRestartable()
*/
public void setRestartable( boolean isRestartable );
/**
* Returns true if restartable HTTP will be used, and false otherwise.
*
* @return Whether restartable HTTP will be used.
* @see #setRestartable(boolean)
*/
public boolean isRestartable();
To use this change, both remotes and servers must be upgraded. It is safe
to upgrade only one of the remote or the server, as long as setRestartable
is not called on the remote.
================(Build #3478 - Engineering Case #680231)================
Databases which are accessed with row limiting enabled (see ConfigPersistent.setRowMinimumThreshold
and setRowMaximumThreshold) will now always lazy load indexes.
================(Build #3335 - Engineering Case #667152)================
Some internal optimization algorithms have been generalized and improved.
This may change plans for queries.
================(Build #3324 - Engineering Case #665538)================
ZLIB compression has been added to UltraLiteJ for the Android. This is accomplished
with the following addition methods:
setZlibCompression( boolean )
setZlibDownloadWindowSize( int )
setZlibUploadWindowSize( int )
zlibCompressionEnabled()
================(Build #3315 - Engineering Case #664390)================
End-to-end encryption (e2ee) has been added to UltraLiteJ for the Android
platform. This was accomplished by using the new methods in the StreamHTTPSParms
interface:
void setE2eePublicKey( String file_name )
String getE2eePublicKey()
The file_name is the name of an RSA public key file used in the encryption.
================(Build #3309 - Engineering Case #663502)================
A new UltraLiteJ utility, ULjExportBuilder, has be added. This utility takes
an existing J2SE UltraLiteJ database and produces a more compact file that
can be deployed to J2SE or RIM clients. An equivalent database can then be
created from the exported file.
usage: ULjExportBuilder database-file exported-file
The required two arguments are file names. The database must not be encrypted
and must be a shadow-page database (the default).
To invoke the export functionality from a Java program, create an object
com.ianywhere.ultralitej.pgmsutility.ULjExportBuilder (there are no arguments
passed to the constructor) and then invoke the export method with one argument
which is a two-element String array containing the names of the database
and export files respectively.
The exported file can placed on a client device using, for example, a MobiLink
file transfer. The database may be imported using an import method which
has three arguments:
java.io.InputStream which is used to read the exported file
String to specify the name of the database
null (no encryption) or an EncryptionControlObject which will be used to
encrypt pages within the database.
(1) On Rim devices the methods are:
DatabaseManager.importDatabaseFileME (import to a RIM file in flash or on
an SD-card)
DatabaseManager.importDatabaseObjectStore (import to the Rim Object store)
(2) On J2SE:
DatabaseManager.importDatabaseFile (import to a file )
================(Build #3740 - Engineering Case #709761)================
When attempting to open a log file using the MobiLink Server Log File Viewer,
if the file could not be opened for any reason, an error message saying that
the file cannot be opened was displayed and then Sybase Central would have
reported an internal error. The problem which caused the internal error
has been fixed.
================(Build #3514 - Engineering Case #691891)================
If all the consolidated tables were already mapped in a synchronization,
and the New Table Mappings menu or toolbar button was used, the user would
have been incorrectly prompted to update the remote schema instead of the
consolidated schema. Also, unchecking the option to add a table to the remote
schema when adding a table mapping, would have resulted in the new table
mapping having no remote table. These problems have now been fixed.
================(Build #3483 - Engineering Case #685982)================
Updating the remote schema in a synchronization model from an UltraLite database
may have subsequently caused errors, including NullPointerException, if a
user was not specified when connecting to the UltraLite database. This would
have changed the remote tables to have no owner, but the table mappings may
still have referred to remote tables using owners. Such invalid mappings
were not detected by the program when opening a synchronization model. This
has been fixed. Owner mismatches for table mappings are now detected when
the remote table in either the remote schema or the table mapping has no
owner
.A workaround is to specify a user when connecting to the UltraLite database
to update the remote schema.
The error message displayed when a table in a table mapping can't be found
in the corresponding schema has also been fixed. The message now correctly
includes the table name that could not be found, instead of displaying '{0}'
for the table name.
Another problem is also addressed with this change. Previously if you changed
the remote table for a table mapping, some options could change to their
defaults, such as the direction changing to bidirectional. Now the synchronization
direction and other synchronization options are maintained.
================(Build #3429 - Engineering Case #682889)================
Changes made using the Interactive SQL utility might not have been automatically
committed when it was closed, if it was opened from a new MobiLink project.
This problem only affected newly created MobiLink projects. If Sybase Central
was restarted after creating the project, the problem did not happen. It
also only occurred when connect to the consolidated database using only an
ODBC data source. If explicit connection parameters were provided, the problem
did not happen. This has been fixed.
================(Build #3426 - Engineering Case #682532)================
In version 12 of the Table Mappings editor for synchronization models, if
the mapping to direction was changed to "Not synchronized" it was
not possible to use the same menu to change it back. As a work around, either
use Edit > Undo, or save the model and re-add the table mapping. This
has been fixed. Now the table mapping direction menus remain enabled after
changing the mapping direction to "Not synchronized".
================(Build #3423 - Engineering Case #681081)================
The connection string an agent uses to connect to a given remote database
can be changed by selecting the agent, then selecting a database on the "Managed
Remote Databases" panel and clicking the "Set Connection String"
menu. If the "Cancel" button was clicked on the resulting window,
the changes were made permanent, as if "OK" had been clicked instead.
This has been corrected so that the changes in the dialog are discarded when
"Cancel" is clicked.
================(Build #3423 - Engineering Case #681055)================
When setting the MobiLink client network protocol options for an Agent, it
was not possible to specificy a certificate file name if that name contained
any of the following characters: "!@#%^&()+-_". Attempting
to do so would have resulted in an error message saying there was a syntax
error in the protocol options. This message was incorrectly being display,
and is now not shown.
================(Build #3373 - Engineering Case #673646)================
It was possible to check both the "Task runs on a schedule" and
"High priority" boxes in the Remote Task Properties window. These
options are mutually exclusive, so this should have been disallowed. This
has been fixed.
================(Build #3373 - Engineering Case #673641)================
Renaming of a member of a destination alias would have caused an error message
saying that there was a problem saving the "deletion rule". Destination
alias members can now be successfully renamed without getting an error message.
When deleting the members of a destination alias, the exception generated
is now explicitly ignored if the client being deleted doesn't actually exist.
================(Build #3338 - Engineering Case #655987)================
The "Apply" button on the property sheet for a Remote Task was
not enabled when various changes were made. Now, the button is enabled correctly.
================(Build #3291 - Engineering Case #658860)================
Sybase Central would have crashed when using the QAnywhere plugin to define
a property for a connector and the property was given both a blank name and
value. Now, the creation of properties with blank names is prevented, as
these are meaningless in any case. A message box indicating that the property
name must not be empty is displayed.
================(Build #3284 - Engineering Case #657284)================
The MobiLink Server log file viewer in Sybase Central might not have listed
all synchronizations in a given log file separately if the log file contained
messages from more than one run of the MobiLink Server. This has been fixed.
================(Build #3284 - Engineering Case #657068)================
In the MobiLink Server Log File Viewer, selecting a synchronization could
have resulted in the window becoming unresponsive if the synchronization
contained hundreds of thousands of messages. This has been fixed.
Also, it was noticed that synchronizations were not initially listed in
chronological order if the log file contained output for more than one run
of the MobiLink Server. This has also been fixed.
================(Build #3281 - Engineering Case #656863)================
If a synchronization model had script errors that were fixed without opening
the Events editor or saving the model, attempting to deploy the model would
have erroneously failed because of a script error. This has been fixed.
================(Build #3280 - Engineering Case #656291)================
If a Destination Alias defined in a Server Store was deleted, the alias was
still shown in Sybase Central until the QAnywhere server completed the deletion.
That could have taken up to a minute, or could never have happened if the
QAnywhere server was not running. If deleting the alias was tried a second
time, an obscure error message would have been displayed saying that the
alias could not be deleted. Now, the Destination Alias is removed from Sybase
Central as soon as the user deletes it, the same as in earlier versions of
Sybase Central.
================(Build #3275 - Engineering Case #654759)================
Changes to the members list were not saved when the OK button in the property
sheet for a destination alias. Also, the Apply button was not enabled after
a member was added, removed, or edited. Both of these problems have now been
fixed.
================(Build #3268 - Engineering Case #653058)================
When creating a rule with a "Custom" schedule type, the schedule
that was saved could have been incorrect if "Run rule every" was
turned off in the "Schedule Editor" window. The rule was saved
such that it was run every 10 minutes. This has been fixed.
================(Build #3266 - Engineering Case #652577)================
Sybase Central could have crashed while the property sheet for a client message
store was open, if adding a new property was started, but then the action
was cancelled. This has been fixed.
================(Build #3520 - Engineering Case #693579)================
When using the "Export to Database" functionality of the MobiLink
Monitor on a 64-bit Linux systems, a dialog with an exception like the following
would have been displayed:
Error! The DBLIB library could not be loaded.
This can happen if your SQL Anywhere installation has been corrupted. You
will not be able to search for database servers.
/opt/sqlanywhere12/lib32/libdblib12_r.so.1: /opt/sqlanywhere12/lib32/libdblib12_r.so.1:
wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
Dismissing the dialog would allow the Monitor to continue, but the "Find"
button would not have been available to search for SQL Anywhere database
servers.
Workaround:
. /opt/sqlanywhere12/bin64/sa_config.sh
export LD_LIBRARY_PATH=/opt/sqlanywhere12/lib64:$LD_LIBRARY_PATH
/opt/sqlanywhere12/bin64/mlmon
================(Build #3480 - Engineering Case #687837)================
If an Overview color in the Options dialog was changed, the Overview display
would have been erased. This has been corrected. A workaround is to disable,
then re-enable, the Overview or change, then change back, the option to keep
the Overview window attached to the main window.
================(Build #3325 - Engineering Case #665535)================
When exporting to a database in the MobiLink Monitor, the values exported
to the per-table details table (called mlm_by_table by default) were the
per-sync values instead of the per-table values. This has been fixed.
================(Build #3299 - Engineering Case #661035)================
When deploying a Synchronization Model for an existing remote database and
only deploying to file, the generated Windows batch file would have failed
when execute. For example, a "You are not connected to a database"
error could have occurred when the batch file tried to apply the generated
SQL file to the remote database. This has been fixed.
To workaround the problem, change this line in the generated batch file:
set CONNECTION=%1
to this:
set CONNECTION=%~1
================(Build #3289 - Engineering Case #658482)================
When a MobiLink Monitor instance that already had a horizontal scroll bar,
was connected to a MobiLink server, the Utilization Graph time scale (if
Utilization Graph was enabled) would have been different than the Chart time
scale. After being connected long enough for the horizontal scroll bar to
be redisplayed, the scroll bar position would have been incorrect and the
Overview Marquee Tool would have fluctuated between the inconsistent time
scales. This has been fixed.
A workaround is to use the Marquee Tool, or change the zoom to fix the display,
or disable the Utilization Graph to prevent the problem.
================(Build #3286 - Engineering Case #657979)================
The MobiLink Monitor's Zoom To Selection menu or toolbar button might not
have panned to the selected synchronization until it was used a second time.
This has been fixed.
================(Build #3268 - Engineering Case #653055)================
Any parameters entered on the MobiLink Monitor's command line with a Multibyte
Character Set would have been mangled. This has been fixed.
================(Build #3759 - Engineering Case #713390)================
In some circumstances, such as a transient connection error to the database
server, the MobiLink Client process (dbmlsync) that was launched by the QAnywhere
agent could have terminated prematurely. When this occurred, the QAnywhere
agent could not perform any message transmission, and the only remedy was
to restart the QAnywhere agent. This has been fixed by adding the capability
to the QAnywhere agent to restart dbmlsync if it detects that the dbmlsync
process has terminated.
================(Build #3726 - Engineering Case #706554)================
The QAnywhere Agent could have failed to start if it could not automatically
upgrade the message store in some cases. This problem was introduced by
the changes for Engineering case 696917. For 11.0.1.2781 until 2804, the
qaagent would have failed to start with message stores created with a qaagent
from 11.0.1.2780 and before. For 12.0.1.3711 until 3725, the qaagent would
have failed to start with message stores created with a qaagent from 11.0.1.2781
until 2804, or with a qaagent from 12.0.1.3711 and before, or with a qaagent
from 12.0.0. This has been fixed.
A workaround for this problem is to recreate the message store using qaagent
-si, if that is possible.
================(Build #3349 - Engineering Case #669235)================
When starting the QAnywhere Agent (qaagent) with the command line option
"-qi", the MobiLink Listener and the MobiLink Client processes
were not also launched with "-qi" options, resulting in system
tray icons on Windows Mobile devices. This has been corrected.
================(Build #3303 - Engineering Case #662456)================
On a Windows Mobile device, the QAnywhere Agent (qaagent) would have sometimes
given the following error messages at start up:
E. 2011-03-14 08:33:50. Error registering with DBLSN code: -1
The error message was displayed in a message box, even when qaagent was
executed in quiet mode. This has been fixed. Now, qaagent is more tolerant
to dblsn slowness at startup. Also, a message box is not displayed when
qaagent is executed in quiet mode (-q or -qi), and the message is logged
in the qaagent console and log file.
================(Build #3769 - Engineering Case #715167)================
The Relay Server affinity cookies were sometime not used properly by third
party client software in cases where the same cookie was used concurrently
on different HTTP requests. In such situation, the Relay Server behaviour
was to let the latest request to take over the connection associated with
the affinity cookie. An optional backend farm property called renew_overlapped_cookie
has now been introduced. It has a default value of 'No', which maps to the
existing behavior. When renew_overlapped_cookie is set to 'Yes', the Relay
Server will detect overlap for the farm that has this property explicitly
turned on and renew the overlapping cookie by creating a brand new affinity
binding. The request with the renewal will still be routed to the same backend
server but not the same backend connection as the on going request that it
overlapped with. A new backend connection will be created instead.
Relay Server configuration example:
[backend_farm]
description = a backend server farm
id = RSTEST02.F0
renew_overlapped_cookie= yes
Online update of the of the renew_overlapped_cookie property is supported.
================(Build #3766 - Engineering Case #715033)================
The following changes have been made to the Relay Server level 4 debug log:
- The "Replaying 0 bytes ..." message was confusing and has been
suppressed.
- Added "Response headers submitted for sending" message.
- Logging Content-length expectation up front.
- Enhance Content-length replay status with remaining length.
- Added user friendly response status and header logging so that users
don't need to suffer level 5 payload logging which is heavier and less readable.
- Moved user friendly request header logging from log level 5 to log level
4 so that user don't need to suffer level 5 payload logging which is heavier
an less readable.
================(Build #3766 - Engineering Case #715025)================
A Relay Server, which doesn't produce urgent flow control packets according
to protocol, could have crashed the Outbound Enabler. No Relay Server has
been released with this problem, but a fix has been made so that the Outbound
Enabler will give an error and not crash in such situations.
================(Build #3765 - Engineering Case #714896)================
Issues with the IIS 6 and IIS& QuickSetup scripts have been corrected:
- the IIS7 auto install could not be invoked if the appcmd.exe utility
was missing. This issue has been fixed so that appcmd.exe utility is not
needed before triggering IIS7 [re]installation.
- the IIS7 Relay Server setup script could not handle a machine not having
a domain suffix.
- the IIS6 & IIS7 Relay Server setup scripts were referencing sleep.exe
which is not a standard utility on Windows. The reference has been removed.
================(Build #3758 - Engineering Case #713458)================
The Outbound Enabler was not logging requests at verbosity 1, but the Relay
Server does. This has been corrected by lowering the minimum log verbosity
level of RS_CLI_SESSION_BEGIN and RS_CLI_REQUEST_BEGIN packets in order to
have them logged at verbosity level 1 instead of 3 in the Outbound Enabler.
There will now be one log event per HTTP request at log level 1 like the
Relay Server does.
================(Build #3755 - Engineering Case #713098)================
When the Relay Server was restarted, new persistent HTTP requests from persisting
client cookies from a previous instance of the Relay Server could have caused
truncated responses on new requests from new sessions by the time the backend
server could have timed out the persistent connection of the old session.
This has been fixed. A workaround is to have clients clear their cookie cache.
The Relay Server affinity cookie is implemented as a non-persistent cookie,
standard http client implementation shouldn't persist the RS affinity cookie
across restart of the http client agent.
================(Build #3755 - Engineering Case #713024)================
The Apache setup script now generates <LocationMatch> tags instead
of <Location> tags when setting up Apache for RelayServer use. The
use of <LocationMatch> allows for a wider range of regular expressions
for URL matching, hence, reducing errors resulting from URL-mismatching.
This fix also includes changes to the location of generated rs.config and
oe.config files (used by the simple test app). The rs.config file is now
generated in the RelayServer binaries directory (containing Apache modules
and rshost), and the oe.config file is now generated in the same setup scripts
directory.
================(Build #3748 - Engineering Case #711685)================
The Relay Server was buffering the entire HTTP chunk in server response for
validation before relaying to the client at once. Some backend servers produce
large chunks, as big as many megabytes. The buffering was consuming memory,
and so reducing scalability. The large write also affected timeliness of
the flow control evaluation done interleaving on the same line of execution.
This has now been fixed by replacing the handling with streaming packets
of size no bigger than 64k regardless of chunk boundary. The validation is
still performed but now done with state tracking on the go.
================(Build #3747 - Engineering Case #711393)================
When a non-sticky load balancer was used in front of a Relay Server farm,
concurrently requesting larger responses could have resulted in an RSE4003
error. This has been fixed. The workaround is to turn HTTP stickiness on
for the load balancer, or to disable Relay Servers until only one remains
enabled.
================(Build #3746 - Engineering Case #711258)================
Some shared memory sizes and other memory usage were logged using a format
that cannot display value greater than 4 Gbytes. This has been corrected.
================(Build #3746 - Engineering Case #711219)================
Some occurances of Relay Server error messages had the backend farm and server
names in the wrong order. Errors affected were: RSF13000, RSF13001, RSF13007,
RSF14000, RSF14001, RSF14002, RSF14003. This has now been corrected.
================(Build #3741 - Engineering Case #710111)================
The Relay Server Outbound Enabler report would have reported session errors
without parameters to Relay Server, but subsequent errors may have caused
a crash. This has been fixed.
================(Build #3741 - Engineering Case #710078)================
When a cookie used by the Relay Server is not encoded properly, it should
result in a RSE1003 error, but sometime the error RSE2003 was raised instead.
This has been fixed.
================(Build #3741 - Engineering Case #709219)================
When starting the Outbound Enabler, if the machine where the Relay Server
was installed was running, but the Relay Server was not available, the Outbound
Enabler would have started, failed to gather a Relay Server peer list, and
then done nothing until it was manually shut down. This has been corrected
so that the Outbound Enabler will now loop and continue to try and gather
the Relay Server peer list until it is successful, or it is told to shut
down.
================(Build #3739 - Engineering Case #709640)================
The Relay Server Outbound Enabler uses GET requests to monitor backend server
status when the -cs command line option is used. The GET request was using
an incorrect host header that always pointed to localhost:80. This has been
fixed to respect the host and port implied by the -cs option.
================(Build #3738 - Engineering Case #709506)================
The IIS Quick Setup script has had the following enhancements:
1) When the Relay Server is loaded with a high volume of requests and payload,
transfer rate per client may thin out to a point that it cannot satisfy a
preset requirement of IIS. The result is a dropping of connections and a
Timer_MinBytesPerSecond event in the HTTPERR log. A change has been made
in section 5b of the setup script to disable this minimum transfer rate requirement.
2) The Relay Server uses a default application timeout of 8 minutes. A change
has been made in section 5b of the setup script to configure the connection
timeout value of the web server to be 1 minute higher than the default application
timeout. The client application can lower the timeout on a per request basis.
The purpose of this change is to remove timeout issue due to mismatch timeout
settings along the chain.
================(Build #3730 - Engineering Case #707729)================
The Relay Server may have exhibited undefined response behavior in some error
cases. This has been corrected.
================(Build #3729 - Engineering Case #707554)================
The following improvements have been made to the interactive quick setup
feature for the Relay Server running on an Apache web server:
- Improved script interaction, especially questions with (Y/n) choices.
Defaults have been added to speed up progress.
- Output log is now flushed timely to give complete log if script is stopped
at any time.
- Removed the option of keeping test services running to overcome a hanging
problem.
- Wording has been improved in several places.
================(Build #3729 - Engineering Case #707534)================
The Relay Server is designed to overload the up-channel liveness for notifing
the Outbound Enabler in the case the down-channel is not connected. This
gives the Outbound Enabler a chance to increase down-channel puncture data,
as the web server can be be set up to buffer the request to a certain amount
before passing to the extension for handling and takeover the rest of the
reading of the request. This issue was introduced in 12.0.1 when HTTP authentication
support was added to the Outbound Enabler, where the test request will fool
the Relay Server into thinking the down-channel connection was successful.
This fix is to change the Relay Server to deal with the Outbound Enabler
behavior change.
================(Build #3729 - Engineering Case #707124)================
Mixing different versions of Relay Server components together on a single
server is not supported and may have lead to crashes in some combinations.
Now, the SQL Anywhere version and build number are used to detect conflicts.
Any conflicts are reported via the following HTTP response status:
500 Abort due to version of this Relay Server extension conflicts with
the version of the running rshost
Note, this change also fixes some error responses that didn't terminate
the header list with \r\n.
================(Build #3728 - Engineering Case #707078)================
When a Relay Server received a request with cookie pointing to a backend
that was no longer connected, the Relay Server would have done unnecessary
processing and reported twice the request to be aborted with verbosity level
2 or higher. This extra processing has now been removed.
================(Build #3728 - Engineering Case #707033)================
When a property was repeated in a section of the Relay Server configuration
file, or when a section header separating two sections of the same type of
object was missing, the Relay Server would have started without complaints,
silently overriding repeated properties. This behaviour has now been corrected
to abort the startup with an error.
================(Build #3728 - Engineering Case #706846)================
The Relay Server would have had the client expire the affinity cookie for
the case where the Outbound Enabler detected a request specific error and
reported the error back to the Relay Server. This didn't cover other error
cases where the Relay Server had enough information to also have the client
to give up the Relay Server affinity cookie. This fix is to add cookie expiry
for those uncovered cases as well. The Relay Server will also response to
the client with cookie expiry if the backend server responds to the client
with HTTP 400 or higher.
This fix also strengthens validation of the cookie format, improves HTTP
status codes, and provides finer HTTP status messages for easier diagnosis.
The responses being changed are summarized in the following table:
New response New response expires cookie? Old response as a record
of behavior change
500 Relay server failed creating client traffic record n 500 Relay
server error
500 Relay server failed initializing server access n 500 Relay server
error
500 Relay server failed writing locking request list n 500 Relay server
error
500 Relay server failed creating request n 500 Relay server error
500 Relay server failed initializing request n 500 Relay server error
500 Relay server failed adding initialized request n 500 Relay server
error
401 The backend farm client_security property in the
Relay Server configuration disallow this type of client transport y 401
The backend farm rejected this client security
500 Relay server failed initializing backend farm access n 500 Relay
server error
400 Bad affinity query y 401 Bad affinity query
400 Bad session id y 401 Bad session id
404 Backend farm is missing from URL y 404 Not found
404 Backend farm not found y 404 Not found
503 The backend farm is currently disabled n 404 The backend farm
is currently disabled
400 Backend server encoded in cookie not found y --No change --
400 Bad request with no response from backend server y --No change--
Note, the HTTP status messages will remain generic for the Relay Server
for Apache, which may not follow the new status codes. This Relay Server
for Apache issue will be addressed as a separate platform dependent issue
which is independent to this one.
================(Build #3726 - Engineering Case #706812)================
The Relay Server Outbound Enabler may have crashed when it was running with
a Relay Server farm, and the backend server was under heavy load or busy,
then went down or became unresponsive. This problem has been corrected.
================(Build #3725 - Engineering Case #705997)================
The Relay Server could have deadlocked after an I/O error with a client while
receiving a large http response. The Outbound Enabler would have tried to
recover, but would have failed with an RSE3003 error (displayed in the Relay
Server log) until the original up-channel failed with error RSE3009. After
that, the Outbound Enabler up-channel retry would have resulted in the error
RSF13002 being displayed in the Relay Server log over and over until the
Relay Server was restarted. New sessions accessing the same backend farm
would have resulted in the error RSF14001. This has been fixed by allowing
the Relay Server to recover from this deadlock state without causing any
Relay Server fatal errors, and the backend service should recover successfully.
================(Build #3718 - Engineering Case #695549)================
When the ias-rs-status-refresh-sec url query parameter was specified on a
status page url, the Relay Server would have returned the error: HTTP 404
"Not Found". This has been fixed.
================(Build #3710 - Engineering Case #702818)================
If a client with an old cookie accessed a blacked out backend service, the
subsequent requests when the backend server comes back up will suffer load
latency under low load situations. This has been fixed.
================(Build #3709 - Engineering Case #702528)================
The SQL Anywhere Monitor for Relay Server was the only means to observe the
breakdown of time costs in different phases of a request, response processing.
There were two issues with this:
1. The numbers rendered through the browser were aggregated and averaged
across all requests going to the same backend server. So individual request
tracing was not viewable.
2. The Monitor was not included in any rebundling of the Relay Server.
The verbose logging (-v 4) of the Relay Server Outbound Enabler (RSOE) of
the DoneReceive event has now been enhanced to include a Since Last Sent
(sls) number. The sls measures number of millisecond elapsed since the completion
time of the last send that occurred on the same socket that had just completed
a receive operation. This can be used as a measure of the backend server
processing time, which includes the communication cost of sending the last
packet (as the OS can declare completion before the packet is actually flushed)
between the RSOE and the backend server (which normally should be minimal
when they are local to each other). Here is a sample log line:
<Backend-0000> DoneReceive: sidx=0 ridx=0 socket=01227b58 sfp=f6c1ee75
len=65514 usage=8192 (12%) sls=0
If the backend server also reports a value for the overall request-response
processing time, the associated sls value can be used to verify the qualify
of the measurement without need to insert third party sniffing tools, which
may, in some cases, change the network topology and invalidate the study.
================(Build #3639 - Engineering Case #704622)================
The opcode parameter in the Relay Server error RSE4007 was not logged properly.
This has been fixed.
Note: this change is fixed the English resource only.
================(Build #3605 - Engineering Case #701651)================
Relay Server Outbound Enabler up channel packet header logging is enabled
by setting the verbosity level (-v) to 3 or higher. The logs are useful for
the analysis of certain issues. Two of the packet headers were carrying incomplete
information:
<UpChannel-0000> 499 RS_CLI_SESSION_BEGIN(snum=0000 sfp=995770b6
ridx=0)
<UpChannel-0000> 557 RS_CLI_REQUEST_BEGIN(oidx=0 snum=0000 sfp=995770b6
ridx=0 sidx=0)
This has been fixed to complete the logging like the following:
<UpChannel-0000> 499 RS_CLI_SESSION_BEGIN(snum=0000 sfp=7329322a
ridx=0 appt=2 per=1)
<UpChannel-0000> 557 RS_CLI_REQUEST_BEGIN(oidx=0 snum=0000 sfp=7329322a
ridx=0 sidx=0 appt=2 per=0)
================(Build #3604 - Engineering Case #701382)================
The Relay Server and the Outbound Enabled log files contained an error in
the UTC time zone offset log line. This has been fixed. The correct log line
now reads: "Time zone offset from UTC in minutes:"
================(Build #3599 - Engineering Case #701212)================
The Relay Server responded with an HTTP 401 status code when the client accessing
the backend farm didn't fulfill the client security requirement specified
by the client_security property in the backend_farm section in the Relay
Server configuration. The message had a typo that has now been corrected
to:
"The backend farm rejected this client security"
================(Build #3596 - Engineering Case #700803)================
Client software is expected to have full control of Relay Server affinity
using standard HTTP cookie reflection, or proprietary Relay Server affinity
header reflection. However, as the Relay Serve usage evolved to cover many
kinds of clients, some client software behaves unreasonable in the sense
that it was stubbornly reusing the same invalid cookie repeatedly after an
error. The expected behavior was either the client software would have discarded
the cookie after error, or add an IAS-RS-AF=new URL query parameter to restart
a new application session with a new cookie. The Relay Server cookie can
become invalid for various reasons including application timeout, Relay Server
farm member removal, communication error between OE and the backend server,
and others. If the client software doesn't conform to the expectation, the
application could have been stuck with an invalid cookie until it was deleted
manually. This fix is to have the Relay Server explicitly instruct the client
software to expire the cookie immediately when the Relay Server knows the
affinity has became invalid. Again, not all stubborn client software can
benefit from this, but those that support expires cookie attribute (pre-RFC
Netscape draft spec for cookies) should.
================(Build #3596 - Engineering Case #700788)================
Affinity cookies assigned by the Relay Server could have become invalid to
the Outbound Enabler over time when the Relay Server was being removed from
a Relay Server farm. An Outbound Enabler receiving such a request will trigger
an unnecessary internal restart that drops other innocent requests. This
has been fixed so that the Outbound Enabler will report an OE_SESSION_ERROR
to the Relay Server without affecting other ongoing requests.
================(Build #3596 - Engineering Case #700759)================
Some wording in the Relay Server quick setup script has been corrected. The
software is not affected by this change.
================(Build #3595 - Engineering Case #700715)================
Downloads of small requests while the Relay Server Outbound Enabler down
channel was under low load situation, may have suffered 200ms TCP Nagling
latency. This has been fixed by inserting a pad of Ethernet MTU size in order
to defeat the Nagling latency at the end of foreseeable download data.
================(Build #3574 - Engineering Case #698218)================
An attempt by the Relay Server to notify the Outbound Enabler to disconnect
the associated backend connection may have been mis-routed and discarded.
This would have caused a delay in closing the backend connection, together
with a SYS64 error, when the backend server eventually timed out the connection.
The conditions for this problem were:
- TCP load balancer without stickiness was used in front of a Relay Server
farm of size greater than 1; and
- an application session had more than one HTTP request; and
- the session had crossed over to a Relay Sever different from the one
where the session started and an I/O error or timeout occurred with the client
connection.
The problem was that the Outbound Enabler was misinforming the Relay Server
for a change in upward packet destination, when a session was migrated from
one Relay Server to another, on a clear request-response boundary. This has
now been fixed so that the Relay Server is protected from being misinformed
by Outbound Enablers older than 12.0.1.3574.
================(Build #3574 - Engineering Case #698082)================
An attempt by the Relay Server to notify the Outbound Enabler to disconnect
the associated backend connection may have been mis-routed and discarded.
This would have caused a delay in closing the backend connection, together
with a SYS64 error, when the backend server eventually timed out the connection.
The conditions for this problem were:
- TCP load balancer without stickiness was used in front of a Relay Server
farm of size greater than 1; and
- an application session had more than one HTTP request; and
- the session had crossed over to a Relay Sever different from the one
where the session started and an I/O error or timeout occurred with the client
connection.
The problem was that the Outbound Enabler was misinforming the Relay Server
for a change in upward packet destination, when a session was migrated from
one Relay Server to another, on a clear request-response boundary. This has
now been fixed so that the Outbound Enable is stopped from misinforming
the Relay Server.
================(Build #3573 - Engineering Case #698076)================
The Relay Server Outbound Enabler could have reported a SYS64 error ("SYS64:
The specified network name is no longer available...") with no ill effect
to the client. This would have happened when a backend server timed out the
connection, and would often have happened when the HTTP response had been
completely received by the Outbound Enabler and the connection remained idle
for an extended period of time. Receiving a SYS64 error in that case was
false alarm. This has been fixed so that this error is now suppressed and
verbosity 4 debug logging will now log this situation as "DoneReceive
EOF SYS64..." instead of "DoneReceive EOF", which is for the
normal disconnect situation. For the cases where the SYS64 happen prematurely
before the entire HTTP response has been received by the Outbound Enabler,
the Relay Server will detect the problem and report and error.
================(Build #3570 - Engineering Case #697611)================
The Relay Server Outbound Enabler (RSOE) did not log command line arguments
on startup and before detecting the availability of a backend server. The
command line arguments were only printed after detecting that a backend server
was up and while connecting to the Relay Server. This has now been fixed
so that command line arguments are printed immediately on startup so that
RSOE configurations are visible as early as possible.
================(Build #3568 - Engineering Case #697450)================
The Relay Server Outbound Enabler may have crashed in a Relay Server farm
environment. This has been fixed.
================(Build #3566 - Engineering Case #697289)================
When the Relay Server extension name in the URL was specified with some uppercase
characters, the Relay Server extension may have crashed. The Relay Server
would have recovered, but active requests involved in the crashing process
would have failed. This has been fixed so that uppercase character are now
acceptable.
Note: The farm name and server id in the URL remain case sensitive.
================(Build #3536 - Engineering Case #694605)================
SUP's Sybase Control Center (SCC) may have reported a false positive Relay
Server Outbound Enabler (RSOE) status when the up channel or down channel
failed to make direct connection to individual Relay Servers in the farm
for a sustained period of time when RSOE debug logging is turned on. This
was due to RSOE suppressing reporting repeated errors while SCC was scanning
only the tail of the RSOE log to determine status. The RSOE has now been
changed to not suppress repeated errors for this issue.
================(Build #3520 - Engineering Case #692342)================
Attempting to start the Relay Server Outbound Enabler with the command line
option "-cs status_url" would have failed. This has been fixed
and a usage text for -cs status_url, which was missing, has been added."
================(Build #3519 - Engineering Case #692346)================
The Relay Server Outbound Enabler would have crashed after showing the usage
text due to an invalid parameter. This has been fixed.
================(Build #3517 - Engineering Case #691976)================
Aggregated download throughput, using one or more Outbound Enablers, has
been improved significantly across all kinds of loads when there is bandwidth
left in the link to the Relay Server.
Running multiple OEs still remains an option to further improve throughput
over a single OE. In our test environment, it now takes about 12 OEs in order
to become network bound. Previously, even with 64 OEs with network bounding
client load (i.e. RS/OE slows down the traffic to the point that it is no
longer network bound) it was not possible to max-out the link.
When the load is not sufficient to cause a network bounding situation, the
Relay Server can now achieve close to 90% of the direct throughput where
the clients are directly accessing the backend server.
================(Build #3513 - Engineering Case #691739)================
The detailed Relay Server status page, via the rs_admin.dll and rs_monitor.dll,
were showing a heading and an empty list of fully available farms when there
were no fully available farms. This has now been changed to not show the
heading when the list is empty. The issue with partially available farms
and unavailable farms has also been fixed.
================(Build #3508 - Engineering Case #691106)================
The Relay Server Outbound Enabler's down channel would have responded slowly
to new requests when there were on-going heavy downloads. This has been fixed
by internal tuning of the Outbound Enabler's down channel. In testing, two
concurrent 1G reponses were making the Outbound Enabler take 18 sec to satisfy
another pair of clients waiting for 10x10k responses. After tuning, it took
only 0.5 sec to satisfy the lighter responses without jeopardizing the aggregated
download throughput.
================(Build #3491 - Engineering Case #689174)================
The Relay Server was sensitive to the networking environment and how quickly
the web server detected read errors (RSE3004) caused by network problems
on the down channel between the Outbound Enabler and the Relay Server. If
there was enough delay so that the Outbound Enabler had already recovered
the channels before the detection occur, the Relay Server would have failed
subsequent client requests targeting this back-end server and reported the
following warning:
W. 2011-10-28 21:23:36. <5608.2420.F5fcB0S456bR0> Server response
NOT completed. Remaining 0 of 0 bytes.
Restarting the Outbound Enabler would have resolved the issue. This has
now been fixed so that client requests will not be affected by the delay
and restarting Outbound Enabler is no longer required.
================(Build #3487 - Engineering Case #688573)================
An interactive quick setup feature has been added to help users with deploying
Relay Server components to Microsoft IIS 7.0 or 7.5 on Windows Server 2008/Windows
Server 2008 R2. This is being provided as an alternative to the manual procedure
documented in the Relay Server Guide.
Setup is automated but also interactive. It installs IIS7, turns on required
IIS7 features, configures IIS7 for Relay Server, creates a demo application
and a Quick Reference Guide to assist in subsequent Relay Server server maintenance.
The Quick Reference is launched automatically as part of the setup.
Setup is comprised of the following major steps:
1. Introduction
2. Customization
3. Install IIS7 and Required Features
4. Create a Backup
5. Deploy and Start the Relay Service
6. Generate and Launch the Quick Reference
7. Launch the Relay Server Status Page
8. Launch the SimpleTestApp Client
9. Shut down
To deploy the Relay Server components to Microsoft IIS 7.0 or 7.5 on Windows
Server 2008/Windows Server 2008 R2, run rs-setup.bat from the SQLANY12%/RelayServer/IIS/quicksetup_iis7
directory.
================(Build #3479 - Engineering Case #687776)================
The changes for Engineering case 686057 made have caused the server to crash
when using URL query parameters. This has been fixed.
================(Build #3479 - Engineering Case #687571)================
If Relay Server State Manager failed to initialize on startup during creating
the shared memory step, it did not output a detailed message with the system
error code and message. This has been corrected.
================(Build #3476 - Engineering Case #687277)================
The Relay Server Outbound Enabler (RSOE) didn't complain about typos in the
-cs and -cr command line options. For example, if trusted_certificates was
entered as trusted_certificate, RSOE would not stopped with an error right
at start-up. Also, when HTTPS related parameters were specified and HTTPS=1
was not set, RSOE would also silently attempt to make an HTTP connection.
These problem have been fixed so that RSOE will detect these problem, report
an error, and abort.
================(Build #3476 - Engineering Case #687273)================
The HTTPS parameter was not mentioned in the usage text description of the
Relay Server Outbound Enabler's -cs option, nor do any cert parameters mention
that it is required. This is also the case for the usage for the -cr option,
where HTTPS was not mentioned anywhere. Descriptions have now been added
to the usage text for these options, as well as a mention that HTTPS=1 is
required for any of the cert parameters. Also the -cs https=1 default port
was set to 80, this has now been changed to 443 instead.
================(Build #3474 - Engineering Case #679356)================
When the Relay Server state manager was started with the -os command line
option, and the Relay Server extension was published using a user account
without write permission of the folder that contained the log file, then
auto truncation of the log when the size limit was reached may have failed
on IIS7.x with a RSF11013 error where the underlying reason was system error
5 (Access is denied). This issue has been fixed.
================(Build #3471 - Engineering Case #686524)================
The SQL Anywhere Monitor was incorrectly reporting the total disk space as
the current Relay Server log's file size. This has been fixed.
================(Build #3471 - Engineering Case #686501)================
Debug logging level 3 or higher would have produced logging of OE_UPCHANNEL_CONNECT
packets with the oei field equal to "older than 12.0". This is
misleading and the packet doesn't contain such a field. The misleading information
has been removed.
================(Build #3470 - Engineering Case #686415)================
Relay Server shutdown may have taken unnecessarily long, or even crashed.
This would have occurred if the shutdown was requested when a new client
session was waiting for backend server assignment while all Outbound Enablers
of the backend farm had been disconnected. This has been fixed.
================(Build #3468 - Engineering Case #686237)================
Relay Server web server extensions may have crashed if the URL contained
redundant leading forward slashes. This has been fixed.
================(Build #3456 - Engineering Case #684808)================
When a back-end server aborted reading a request, for example due to some
early detectable protocol error, the Outbound Enabler may have caused further
protocol errors later on for other requests. This has been fixed.
================(Build #3456 - Engineering Case #684721)================
The rs_client.dll may have crashed when parsing a malformed response header.
This has been fixed so that the Relay Server will response with an http 400
instead of crashing.
================(Build #3436 - Engineering Case #683240)================
A forced termination of the web server worker process, may have caused the
Relay Server Outbound Enabler (RSOE)connection to become unrecoverable until
the rshost process was restarted. The RSOE will receive authentication error
continuously upon every recovery attempt, and the Relay Server log will continuously
report RSE3003 accordingly. The forced termination could have been caused
by killing the w3wp processes, crashes, worker process recycling or IIS configuration
update timeout waiting for outstanding requests to complete. This problem
has now been corrected so that the recovery should succeed two minutes after
the forced termination, without requiring the rshost process to be restarted.
The workaround is to restart the rshost process. This has been fixed
================(Build #3427 - Engineering Case #682648)================
When using the local Relay Server reconfiguration utility on Linux Apache
to change the Relay Server configuration, or to archive the Relay Server
log, the utility would not exit once complete. This has been fixed.
================(Build #3427 - Engineering Case #682621)================
Remote Relay Server administration operations can be initiated from Sybase
Central's Relay Server plugin, or via the Relay Server administration API.
Remote administration operations, such as Relay Server reconfiguration or
log archiving, could have caused the Linux Apache Relay Server to crash.
This has been fixed.
================(Build #3427 - Engineering Case #682561)================
The fix for Engineering case 660995 had caused an issue where client requests
that were not assigned to a backend server may have caused the IIS worker
to crash in rs_client.dll. The client request may not have been assigned
for various reasons. For example, when the Relay Server Outbound Enabler
of the backend server was not connected, or the farm was disabled. If that
happened and there were also I/O error while reading the request for discarding,
a crash could have occurred when the Relay Server tried to report the I/O
error. The crash has been fixed.
================(Build #3421 - Engineering Case #681791)================
On Windows systems, a standalone Relay Server Outbound Enabler (RSOE) may
have mistakenly identified a backend server as down or not accepting requests
during the backend ping cycle on startup. This error could have happened
if the Winsock DLL startup failed. This has now been fixed. Instead, the
RSOE will print the error message "Backend ping socket startup failed",
and backend ping attempts will stop.
================(Build #3421 - Engineering Case #681789)================
Version information was missing from rstool.jar, so an ianywhere.ml.rs.BuildNum
class with a static main method that prints the version with build number
to System.out, has been added.
================(Build #3420 - Engineering Case #681621)================
In a Relay Server farm environment, likely with non-sticky loadbalancer,
it was possible for the Outbound Enabler to leak memory in the rare case
of failing to locate the proper channel where the client request originally
came from. This has now been fixed.
================(Build #3417 - Engineering Case #681059)================
The usage text for the Relay Server Outbound Enabler was incorrectly listing
'identity_name' as a value for the -cr option. The value 'identity_name'
has now been removed .
================(Build #3416 - Engineering Case #680920)================
The ISS Application Pool Process (w3wp.exe) may have crashed some time later
after handling a request with a URL ending with the Relay Server extension.
================(Build #3391 - Engineering Case #676505)================
Under rare, timing dependent conditions, the Relay Server may have reported
a fatal error "RSF11016: Freeing already freed memory block in shared
memory". The Relay Server's shared memory manager would have protected
itself from this illegal operation and continued to operate normally. This
error may have occurred right after RSE2000, RSE3008 or Relay Server shutdown.
This has been fixed by eliminating the redundant freeing.
================(Build #3384 - Engineering Case #675317)================
Under extreme load conditions, the Relay Server may log errors on shared
memory operations. This logging operation may have crashed the web server
worker process. Also, for 12.x Relay Servers, the line label for such logging
has the format of <pricessId.threadId.ShmDebug>. The threadId could
have been wrong. Both of these problem have now been fixed.
================(Build #3376 - Engineering Case #674187)================
A web server worker thread may have crashed when it failed to load the localized
language resource (e.g dblge12.dll). The reasons for the failure may have
included the file not being found due to path and registry info, or the account
associated with the worker did not have permission to read the resource.
The symptom was a truncated log line with a missing end-of-line. This has
been fixed so that the crash will no longer occur and an unlocalized error
message is displayed regarding the loading error.
================(Build #3376 - Engineering Case #674120)================
A web server worker may have crashed when logging lengthy debug messages
that had not been localized. This has been fixed.
================(Build #3364 - Engineering Case #672213)================
The Relay Server may have become unrecoverable due to continuous errors from
the shared memory manager when one of the backend servers had been serving
more that four types of clients. This has been fixed so that a hard limit
of 1600 client types is in effect. When the new limit is reached, a graceful
error will be reported without affecting the rest of the requests.
================(Build #3345 - Engineering Case #668791)================
When the Relay Server Outbound Enabler failed a backend connection test,
it may have crashed, or have been unable to recover even after the backend
became available again. This has been fixed.
================(Build #3332 - Engineering Case #666845)================
The Relay Server admin and monitor extensions may have slowly leaked memory.
Eventually, admin or monitoring requests would have failed without any trace
in the HTTP error log, IIS access log, or in the Relay Server log. This problem
has been fixed so that recycling is no longer necessary. To workaround this
problem, users may setup application pool recycling for the admin and monitoring
extension.
================(Build #3327 - Engineering Case #664284)================
The Relay Server Outbound Enabler would have stopped discovering Relay Servers
after the last Relay Server was disabled from a server farm. The Outbound
Enabler would have become unusable until restarted. This is fixed so that
the Outbound Enabler will now attempt to discover new Relay Servers at the
rate specified by the existing Outbound Enabler -d switch.
================(Build #3323 - Engineering Case #663171)================
The Relay Server may not have responded to HTTP GET requests for non-relay
purposes. For example, using a browser to visit the rs_admin extension would
have resulted in a connection drop without a response. A load-balancer trying
to test the Relay Server service via the rs_server extension, would also
have resulted in a connection drop without a response regardless of the status
of the relay service. This has been fixed so that a useful response is now
provided when HTTP GET requests are issued against various Relay Server extensions.
================(Build #3315 - Engineering Case #661112)================
It was possible for synchronizations to fail if any of the 'certificate_name',
'certificate_company', or 'certificate_unit' parameters were supplied, even
though the value of these parameters matched the corresponding field values
in the server's certificate, if they were encoded as Unicode in the server's
certificate. This has been corrected.
================(Build #3314 - Engineering Case #664283)================
Relay Server enable/disable events were not broadcast to connected Outbound
Enablers. For example, disabling the last Relay Server from a Relay Server
farm was not going to suffer the issue described in Engineering case 664284,
but when adding a Relay Server to the Relay Server farm, it would also not
have woken up the Outbound Enablers to start utilizing the new Relay Server.
The user workaround is to restart the Outbound Enabler. This problem has
been fixed.
================(Build #3314 - Engineering Case #664139)================
When a Relay Server starts up, its description was logged and the startup
verbosity was applied properly, but those values were not stored correctly
for later consumption. Such as for the admin tool to export the configuration
or for the next configuration update to properly determine if an updated
was required. This problem has been fixed.
================(Build #3311 - Engineering Case #663936)================
On Unix systems, the second field in the Relay Server's log, which is the
thread ID, may shown a negative number. The type used to store the thread
ID value was not big enough on Unix systems, as thread IDs tend to be large,
and could have overflowed. This has now been fixed.
================(Build #3308 - Engineering Case #663261)================
The Relay Server Outbound Enabler on MacOS may have failed to receive all
download data from the backend server. If Relay Server for Apache was used,
then it would have appended a 500 HTTP error page to the data, which most
likely would have caused client failure. This has now been fixed.
================(Build #3306 - Engineering Case #663061)================
Proxy support for the Relay Server Outbound Enabler may only have worked
with HTTPS against some HTTP 1.1 proxy servers. The down channel using HTTP
instead of HTTPS would have connected successfully at first but then would
have been dropped by the proxy after a period of being idle. This problem
is proxy specific and it does not affect all HTTP proxy environments. This
problem has been fixed in the Relay Server so that an update to the Outbound
Enabler is not required (see Engineering case 662749). The workaround is
to use HTTPS, or apply the Outbound Enabler fix from case 662749.
================(Build #3305 - Engineering Case #662749)================
Proxy support for the Relay Server Outbound Enabler may only have worked
with HTTPS against some HTTP 1.1 proxy servers. The down channel using HTTP
instead of HTTPS would have connected successfully at first but then would
have been dropped by the proxy after a period of being idle. This problem
is proxy specific and is does not affect all HTTP proxy environments. This
problem has been fixed in the Outbound Enabler so that HTTP will now also
work. The workaround is to use HTTPS.
================(Build #3300 - Engineering Case #661849)================
When using the Service utility (dbsvc) to start a Relay Server service with
a large configuration on a slow machine, it may have reported startup errors
while the service was still in the pending start state. A fix was made to
the Relay Server to correct this problem.
================(Build #3298 - Engineering Case #660995)================
When connected to a Relay Server, and no Outbound Enabler providing the backend
service had connected yet, the connection was expected to timeout within
the application timeout time specified by the client. However on IIS7, some
J2SE http clients may have become stuck writing to a server that was no longer
reading and eventually failed the write and then perform a delayed internal
retry without processing the response sent by the web server. This change
modifies the Relay Server to provide the expected fail fast experience according
to the timeout against such J2SE clients.
================(Build #3291 - Engineering Case #658710)================
When the Relay Server was being reconfigured, a crash may have occurred in
the rs_client.dll, and all http requests served by the same worker process
would have failed. The web server would then have replenished the worker
pool and the Relay Server would have continued to operate with the new configuration.
The issue is highly timing sensitive and is very difficult to reproduce.
This crash has now been fixed.
================(Build #3284 - Engineering Case #655574)================
The integrated Outbound Enabler library was not being unloaded correctly
when the Mobilink server shutdown. The library eventually unloaded when the
MobiLink server executable exited and no bad side effects where observed
as a result, but this condition is now fixed.
================(Build #3283 - Engineering Case #656716)================
The Relay Server could have leaked heap memory under the following conditions:
- On the response to the first HTTP request in the session, or specifically,
anytime a cookie was set, if the response was long and came in small packets.
- A small number of bytes were leaked on Upchannel and Dnchannel creation.
This has been fixed.
================(Build #3282 - Engineering Case #657026)================
The MobiLInk server would immediately refuse to startup, if it could not
make any connections to the consolidated database, even when it was running
as a Windows service.
This behaviour has changed so that the MobiLink server will retry to make
connections, when it is running as a Windows services. The retries are once
a minutes for ten minutes. If it still cannot make a connection after that,
it will refuse to startup.
================(Build #3267 - Engineering Case #652382)================
The Relay Server did not work with a Relay Server Outbound Enabler (RSOE)
that was behind an HTTP 1.0 proxy. The Relay Server has now been fixed to
adapt to HTTP version downgrades done by an HTTP 1.0 proxy, and is needed
when working with a 12.0.1 RSOE in conjunction with a HTTP 1.0 proxy.
================(Build #3278 - Engineering Case #655989)================
Sybase Central would have crashed whenu attempting to open a Relay Server
configuration file which was zero-length, or that contained only whitespace.
This has been fixed.
================(Build #3273 - Engineering Case #654244)================
On some Chinese Windows systems, the fields for entering the MAC address
for back end servers was too narrow to see both digits of each byte of the
address. This has been fixed.
================(Build #3664 - Engineering Case #706541)================
In a mirroring system, if the mirror or a copy node was stopped around the
time the primary performed a transaction log operation that required more
than one page, the next time the mirror or copy node was started it could
have asserted or crashed. The most likely assertion failure error numbers
were 100902, 100903 or 100904. This has been fixed.
================(Build #3353 - Engineering Case #670360)================
The SQL Anywhere synchronization/replication components, including the MobiLink
client (dbmlsync) and SQL Remote (dbremote), could have given the error 'No
off-line transaction log file found and on-line transaction log starts at
offset XXXXX'. This would have occurred:
1) if no transaction-logs-directory was given on its command line; and
2) if the length of the transaction log name including its absolute path
was greater than 128 bytes.
This problem is now fixed and the length of the transaction log name plus
its absolute path has been extended to 1024 bytes.
================(Build #3341 - Engineering Case #668425)================
The MobiLink client now prints information about the operating system and
machine architecture on which it is running to the log. It also prints the
platform for which the executable was compiled. This is similar to what
the MobiLink server and the database server already do.
================(Build #3303 - Engineering Case #662639)================
When a SQL Anywhere database is used as a remote database, the MobiLink client
(dbmlsync) generates a remote ID which is a GUID for the database during
the first synchronization. This remote ID is used by the Mobilink server
to identify the remote. MobiLink keeps a list of synchronizing remotes in
the ml_database table. When a blank padded SA database was used as a remote,
a remote ID would have been generated during the first synchronization,
sent to the MobiLink server and stored in the ml_database table. On all
subsequent synchronizations, a blank padded version of the remote id would
then have been sent. The results of this were:
1) The server would not have been recognized on the second sync that the
same remote was synchronizing and would treat the second sync as a first
sync. That is to say the server would not have used state information it
had from the first sync when processing the second. Third and subsequent
sync's were not affected. This would have had no impact unless the first
synchronization had failed.
2) Two entries would have been made in the ml_database table for each remote.
One would contain the blank padded remote id and the other would contain
the unpadded id.
This behaviour has now been fixed. Now, on first synchronization the remote_id
assigned to the remote database will be blank padded.
================(Build #3298 - Engineering Case #650856)================
Synchronizations using HTTP-based communication protocols (including HTTP,
HTTPS and other encrypted HTTP protocols) could have failed intermittently.
When synchronizations failed, they would do so after the download had been
applied and committed, and would have reported an error message like: "Data
read failed. Requested 2 bytes but got 0 bytes." When this occurred
the MobiLink server would have reported the error: "Connection was dropped
due to lack of network activity". These failures were only likely to
occur when applying the download to the remote database took longer than
the stream timeout interval, which is 4 minutes by default. This problem
has now been resolved
================(Build #3278 - Engineering Case #655955)================
Several memory leaks have been fixed in the MobiLink Client.
================(Build #3278 - Engineering Case #655953)================
Several memory leaks have been fixed in the MobiLink client. These leaks
would primarily affect applications using the dbmlsync API.
================(Build #3272 - Engineering Case #653930)================
The Console utility could have stopped refreshing database and/or server
properties after changing the set of properties which were displayed, even
after it was restarted. The problem was sensitive to the speed with which
properties were selected or unselected. This has been fixed.
================(Build #3263 - Engineering Case #651692)================
When a plug-in failed to load on startup, other plug-ins may then not work
correctly. This has been fixed.
================(Build #3729 - Engineering Case #707541)================
Unnecessary HTTP headers were being sent in HTTP CONNECT requests. This
has been fixed.
================(Build #3522 - Engineering Case #692598)================
An HTTPS synchronization could have failed on 64-bit Windows with STREAM_ERROR_SECURE_HANDSHAKE,
depending on what trusted certificates were provided. This failure would
have been more likely to occur when using the OS's CA certificate store.
Certicom has provided updated libraries which correct this problem.
================(Build #3512 - Engineering Case #691654)================
MobiLink clients that output localized error messages, now output a more
detailed error message for connection failures on Windows desktop and devices,
in addition to doing so for network read and write errors as they did before.
================(Build #3444 - Engineering Case #683721)================
When the password provided by the identity_password option for an encrypted
private key for a client side certificate was incorrect, the error STREAM_ERROR_INTERNAL
was reported. Now the correct error STREAM_ERROR_BAD_PRIVATE_KEY_PASSWORD
is reported.
================(Build #3419 - Engineering Case #681404)================
A MobiLink client doing an HTTPS synchronization could have crashed if the
connection was lost. This has been fixed.
================(Build #3417 - Engineering Case #681078)================
TLS and HTTPS synchronization would have failed when the client attempted
to use a client-side identity with an unencrypted private key. The error
reported would have been: "Unable to read the private key". This
has now been fixed.
================(Build #3326 - Engineering Case #665837)================
The changes for Engineering case 661112 introduced a bug where the MobiLink
client could have crashed, or the check of the certificate_name, certificate_company,
or certificate_unit could have failed, if any of the certificate fields were
encoded as Unicode in the server's certificate. This has been fixed.
================(Build #3275 - Engineering Case #650719)================
After a failed download, an attempt to restart the download may have failed
and reported a "Protocol Error" or a read failure. This has been
fixed.
================(Build #3757 - Engineering Case #706878)================
The MobiLink server could have crashed when a TIMESTAMP column was fetched
from Oracle using the .NET-ODBC bridge. This has been fixed.
================(Build #3752 - Engineering Case #706183)================
If a DBRowReader from the MobiLink Server .NET API was used to gather binary
data from a fixed length binary column in the consolidated database, then
the binary data that was fetched would have had zeroes appended to the result
up to the maximum size of the fixed length column. This has been corrected
so that zeroes are no longer added to the result.
================(Build #3742 - Engineering Case #710432)================
The MobiLink server could have crashed if a failed download using HTTP was
restarted. This has been fixed.
================(Build #3728 - Engineering Case #707061)================
The MobiLink server could have crashed if it had an HTTPS listening port.
This has been fixed.
================(Build #3728 - Engineering Case #707039)================
Synchronizations could have hung when using HTTP if an error occurred on
the server side. This has been fixed.
================(Build #3725 - Engineering Case #705697)================
Set-Cookie HTTP headers, and sync parameters that set a cookie value to the
empty string, will now cause the cookie to be removed, preventing it from
being sent to the server in subsequent HTTP requests. Previously, the client
would report an error in this case.
================(Build #3718 - Engineering Case #704464)================
HTTP headers returned by the NetworkData Java and .NET classes were silently
truncated. This has been fixed.
Also, a bound has been placed on the total amount of header data that can
be sent in an HTTP request. If a request exceeds the bound, the server will
return an HTTP error code and abort the request. This bound is controllable
with the header_limit HTTP option. For example, "-x http(header_limit=200000)"
will raise the limit to 200000 bytes. The default value is 64000 bytes.
================(Build #3673 - Engineering Case #698075)================
The MobiLink server could have crashed while shutting down when it was using
an integrated Outbound Enabler. This has been fixed.
================(Build #3602 - Engineering Case #701348)================
Exceptions were not thrown when strings containing invalid timestamps were
assigned to TIMESTAMP WITH TIME ZONE columns in the MobiLink Java and .NET
direct row APIs. This has been fixed.
================(Build #3602 - Engineering Case #701343)================
Unnecessary cast exceptions could have occurred when using the MobiLink .NET
direct row API with SMALLINT and TINYINT columns. This has been fixed.
================(Build #3602 - Engineering Case #701342)================
The following remote types were not supported by the MobiLink Java and .NET
direct row APIs:
NCHAR
NVARCHAR
LONG NVARCHAR
VARBIT
LONG VARBIT
XML
This has been fixed.
================(Build #3599 - Engineering Case #701349)================
It was possible to call PreparedStatement.setTime for columns that were not
times or dates in the MobiLink direct row API. This has been corrected.
================(Build #3599 - Engineering Case #701347)================
The varchar(max) and varbinary(max) types in Microsoft SQL Server did not
work when using the MobiLink .NET-ODBC bridge. This has been fixed.
================(Build #3599 - Engineering Case #701344)================
A security issue with the MobiLink direct row API has been corrected.
================(Build #3553 - Engineering Case #695119)================
The MobiLink server would not have accepted any status-check requests sent
by clients who had lost the last synchronization status. When a status-check
request was received, the MobiLink server would have repoprted the error:
[Sybase][ODBC Driver][SQL Anywhere]Authentication violation (ODBC State
= 08001, Native error code = -98)
and then failed the request when all the following conditions were met:
1) The consolidated database was running on an OEM version of a SQL Anywhere
server;
2) The consolidated database had been restarted since the MobiLink server
was started; and
3) A client required a status-check because it did not get a full response
in the last sync request that contained an upload.
These problem is fixed now. The immediate work around for this problem is
to restart the MobiLink server.
================(Build #3543 - Engineering Case #695370)================
The MobiLink server could have crashed when using the DBRowReader or DBCommand
interfaces in the MobiLink .NET-ODBC bridge, if varchar or binary columns
longer than a few KB were used. This has been fixed.
================(Build #3513 - Engineering Case #691327)================
If the Notifier had encountered an unexpected error (such as a deadlock)
when executing one of the Notifier events, subsequent attempts to execute
the same Notifier Event would have resulted in an "Invalid Cursor State"
error. This has been corrected so that the Notifier no longer reports the
"Invalid Cursor State" error on subsequent attempts. Stopping
and starting the MobiLink Server would also have resolved the issue.
================(Build #3500 - Engineering Case #689194)================
When synchronizing with a SQL Anywhere remote using the MobiLink client running
on a non-English operating system, it was possible for the following message
to be generated by the MobiLink server:
Gtk-CRITICAL **:gtk_text_buffer_emit_insert:assertion 'g_utf8_validate (text,
len, NULL)' faild
This problem has been fixed. As a consequence, the message output in the
MobiLink server log when a synchronization request is received from a SA
remote will change from:
Request from "Dbmlsync Version 16.0.0.3940" for: remote ID:
...
to:
Request from "Dbmlsync 16.0.0.3940" for: remote ID: ...
================(Build #3496 - Engineering Case #689792)================
Requests to 12.0 MobiLink servers from MobiLink clients without the changes
made for Engineering case 471582, where the MobiLink client included version
and build number in each synchronization, could have ended with an "Unknown
request completed" in the MobiLink server log. Also, error "[-10344]
The remote database identified by remote ID '89d85096-0006-11e1-8000-8a42a227c45d'
is already synchronizing: orphaned UltraLite synchronization" could
have been reported for requests from MobiLink clients without this change
as well. These issues have been fixed.
================(Build #3450 - Engineering Case #547730)================
If a corrupted UltraLite or SQL Anywhere remote client synchronized with
a MobiLink server, it was possible for protocol errors to be generated. When
this occurred, the MobiLink server console log would have shown the text:
I. <1> failed reading command with id:%d and handle:%d
I. <1> Synchronization complete
This has been fixed. Now, the error message "[-10001] Protocol Error:
400" will be displayed and a synchronization error will be reported.
================(Build #3448 - Engineering Case #683720)================
If a schema change was done using the START/STOP SYNCHRONIZATION SCHEMA CHANGE
functionality, and authentication parameters were passed during synchronization,
it was possible that the authentication parameters would not have been sent
for the first synchronization after the schema change commands had been processed.
This would likely have resulted in a failed synchronization. The next synchronization
though would have been successful, and no data loss would have occurred.
This problem has now been fixed, and authentication parameters are no longer
missed.
================(Build #3446 - Engineering Case #683830)================
There were two problems in the MobiLink server remote ID locking logic that
have now been corrected:
1) When the consolidated database was running on a MySQL server, the MobiLink
server could have immediately failed a status-check request when the server
was not able to lock the remote ID;
2) When the consolidated database was running on a SQL Anywhere server,
if the remote ID could not be locked in the upload transaction, the server
would have shown the following warning message:
"Retrying the upload after deadlock in the consolidated database"
and then retried the upload transaction one more time.
================(Build #3423 - Engineering Case #678983)================
The MobiLink server could have crashed when synchronizing using HTTP. This
has been fixed.
================(Build #3420 - Engineering Case #681620)================
If the MobiLink server was started with an identity file containing an unencrypted
private key, it would have fail to start with error "Unable to read
the private key.". This has been corrected.
================(Build #3376 - Engineering Case #674250)================
When the MobiLink Server ran against a consolidated database running on Microsoft
SQL Server, the MobiLink server could have reported the following error message:
[-10002] Consolidated database server or ODBC error: ODBC: [Microsoft][SQL
Server Native Client 10.0][SQL Server]
Cannot drop the table '#elbat_yraropmet_ymmud_a_si_siht', because it
does not exist or you do not have permission.
(ODBC State = 42S02, Native error code = 3701)
This error would have occurred in one of the following situations:
1) a deadlock was detected during upload;
2) an error occurred in a trigger that was defined on an upload table; or
3) the 'XAXT_ABORT' option was set to 'ON' in one of the user-defined scripts.
This problem is fixed now.
================(Build #3354 - Engineering Case #669465)================
The MobiLink server could have crashed when handling restartable downloads
and the restartable download cache was too small to hold all possible restartable
downloads at one time. This has been fixed.
================(Build #3301 - Engineering Case #662072)================
When deploying a Synchronization Model with conflict resolution to a SQL
Anywhere or Sybase IQ database, the SQL generated to create a global temporary
table checked twice for an existing table. Although this did not cause any
errors, the generated SQL has been fixed so that it now only checks once
for an existing table before creating a global temporary table.
================(Build #3289 - Engineering Case #658453)================
When using MobiLink synchronization and timestamp-based downloads with an
Oracle Real Application Cluster (RAC) system, there is a chance of missing
rows to be downloaded if the clocks of the Oracle cluster nodes differ by
more than the time elapsed between the MobiLink server fetching the next
last download timestamp and fetching the rows to be downloaded. This problem
is unlikely on a RAC system with synchronized node clocks, but the likelihood
increases with larger node clock differences. A workaround is to create either
a modify_next_last_download_timestamp or modify_last_download_timestamp script
to subtract the maximum node clock difference.
Note that at least since version 10i, Oracle has recommended using Network
Time Protocol (NTP) to synchronize the clocks on all nodes in a cluster,
and NTP typically runs by default on Unix and Linux. With cluster nodes properly
configured to use NTP, their clocks should all be within 200 microseconds
to 10 milliseconds (depending on the proximity of the NTP server). Since
Windows Server 2003, the Windows Time Service implements the NTP version
3 protocol and it runs by default. Also, as of version 11gR2, Oracle Clusterware
includes the Oracle Cluster Time Synchronization Service (CTSS) to either
monitor clock synchronization or, if neither NTP or Windows Time Service
is running, it will actively maintain clock synchronization. However CTSS
and Windows Time Service are less accurate than NTP,
To avoid missing rows when Oracle RAC node clocks differ by up to one second
more than the time between fetching the next_last_download_timestamp and
the rows to be downloaded, now the MobiLink server will subtract one second
from the next_last_download_timestamp fetched from the consolidated database,
if
1) the Oracle account used by the MobiLink server has execute permission
for SYS.DBMS_UTILITY,
2) the consolidated database is an Oracle RAC system,
and (only for MobiLink version 12.0.0 and up)
3) there is no generate_next_last_download_timestamp script.
For Oracle RAC node clocks that may differ by greater amounts, you can avoid
the problem by defining a generate_next_last_download_timestamp, modify_next_last_download_timestamp
or modify_last_download_timestamp script to compensate for the maximum node
clock difference.
================(Build #3286 - Engineering Case #657869)================
If the MobiLink Server's memory use grew more than 4GB in less than 5 minutes,
the TRACKED_MEMORY ppv value would have been incorrect. As a consequence,
for all 12.0.1 platforms and non-Windows 12.0.0 platforms, the MobiLink server
cache could have erroneously shrunk and not recovered. This has been fixed.
A work around is to use a larger -cinit option value, and if the problem
persists to disable dynamic cache resizing by specifying the same value for
-cmax and -cmin.
Also, on 12.0.0 for Windows, the cache could have failed to stabilise.
This has also been fixed.
================(Build #3277 - Engineering Case #655780)================
The method MLResultSet.getBigDecimal(L/java/lang/String;) unnecessarily threw
a 'method not supported' exception. This has been fixed.
================(Build #3273 - Engineering Case #653183)================
The NUM_CONNECTED_SYNCS ppv metric and the "Synchronizations",
"Started Synchronization Rate", "Synchronizations Started",
and "Unknown Connected Clients" metrics incorrectly considered
syncs that had failed during the download and were waiting to be restarted
as being connected and so would show an incorrect value in the log or in
the SA Monitor. Also, as a consequence, the server would prompt for confirmation
to kill active syncs during hard shutdown even if all the syncs in the system
are waiting to be restarted. This has been fixed.
================(Build #3265 - Engineering Case #652263)================
The usage text for the Relay Server Outbound Enabler didn't describe what
were the valid options for the -cr option. This has been corrected so that
the values are now listed for the tcp options, server certificate options,
and client certificate options.
In addition, http authentication options, proxy options, and proxy authentication
options, have been added in version 12.0.1.
================(Build #3153 - Engineering Case #660428)================
The MobiLink server could have crashed during shutdown if user spawned Java
threads printed to System.out or System.err after the ShutdownListeners were
notified of shutdown. This has been made much less likely to happen. A work
around is to ensure all user threads are stopped before the ShutdownListeners
return.
================(Build #3605 - Engineering Case #701661)================
Using the Certificate Creation utility with the -c option ("Read the
signer's certificate from the specified file") could have caused it
to crash. This has been fixed.
A workaround is to use the interactive prompt instead.
================(Build #3593 - Engineering Case #700315)================
The MobiLink Replay utility could have crashed if the GetNumRecordedInserts,
GetNumRecordedUpdates, or GetNumRecordedDeletes callbacks were called from
the replay DLL with values not explicitly given by MLReplay when calling
the GetUploadTransaction callback. This has been fixed.
================(Build #3590 - Engineering Case #700132)================
The Certificate Creation utility (createcert) would have fail to create a
certificate with the error "Error occurred encoding object" when
run on a leap day, and the expiry for the certificate was not a leap year.
This has corrected.
================(Build #3571 - Engineering Case #697637)================
The MobiLink Replay utility (mlreplay) could have crashed when using the
replay API to customize uploads of tables that had no nullable, signed number,
or bit columns. This has been fixed.
================(Build #3566 - Engineering Case #697189)================
The MobiLink replay utility (mlreplay) can unpack blobs incorrectly (i.e.
using the wrong type) when determining the number of inserts, updates, and
deletes in the recorded protocol file. This has been fixed.
================(Build #3528 - Engineering Case #693325)================
The MobiLink replay utility (mlreplay) could have crashed when the version
of the recorded protocol was incompatible with the version of the replay
utility replaying it. This has now been fixed.
================(Build #3451 - Engineering Case #684361)================
The MobiLink Replay utility (mlreplay) could have read and sent row data
in the wrong order. This could have caused a crash in mlreplay, and caused
the MobiLink server to read incorrect/invalid row data resulting in a -10308
error. This has been fixed.
================(Build #3421 - Engineering Case #681788)================
Version information was missing from mlnotif.jar, so an ianywhere.ml.notifier.BuildNum
class with a static main method that prints the version with build number
to System.out, has been added.
================(Build #3344 - Engineering Case #668612)================
The MobiLink Replay utility (mlreplay) could have crashed when synchronizing
unsigned big integers using the Replay API. This has been fixed.
================(Build #3315 - Engineering Case #664140)================
Sometime the MobiLink Listener (dblsn) could have taken a few minutes to
shutdown if the shutdown was initiated by the QAnywhere Agent (qaagent).
This problem has been fixed.
================(Build #3311 - Engineering Case #663629)================
When replaying a recorded protocol file more than once with the same client
without using the –ap option, all replay sessions after the first would have
failed due to a progress mismatch warning received from the MobiLink server
(this is expected). However, the error message that appears in the MLReplay
log in this situation does not make it clear that the problem will disappear
if the –ap option is used. So, the MobiLink Replay utility has been changed
so that when it receives an unexpected progress mismatch from the MobiLink
server, an error message saying so is logged, which points the user to use
the –ap option.
================(Build #3764 - Engineering Case #707781)================
The iAS ODBC driver for Oracle could have crashed in the OCI library when
a query contained results from a proxy server if the size of the result set
was greater than the "Array size" given by the DSN. This problem
has now been fixed.
================(Build #3292 - Engineering Case #657721)================
There was a memory leak in the iAS ODBC driver for Oracle. The memory leak
would have occurred when an application tried to make a connection but the
ODBC driver was not able to obtain a valid database connection. This problem
has now been fixed.
================(Build #3759 - Engineering Case #712456)================
When using the DBRowReader class, it was possible for all the values in a
long column to be erroneously returned as NULL. This has been fixed.
================(Build #3284 - Engineering Case #657397)================
When the consolidated database was running on an Oracle server, the MobiLink
server could have displayed the error: 'ORA-00001: unique constraint ...
violated' and then refused further synchronization requests. This would have
occurred when the MobiLink server schema in the consolidated database was
upgraded from a version earlier than 11.0.0, and the synchronization request
was for a new MobiLink user and/or MobiLink remote database.
This problem has been fixed in the upgrade scripts for Oracle.
The following steps can be used to correct the problem if the Oracle consolidated
database had already been upgraded with the old upgrade scripts:
1) Shut down all MobiLink servers;
2) Execute the SQL file against the Oracle consolidated database with the
following command line:
sqlplus LoginID/Password@TNSServerName @%SQLANY12%\MobiLink\Upgrade\fix_ora.sql
Replace the LoginID, Password, and TNSServerName in the above command line
with your own login information.
================(Build #3746 - Engineering Case #711375)================
If the Remote Server name was longer than 64 characters, the system procedure
sp_servercaps() would have returned a "right truncation of string data"
error.
Example:
CREATE SERVER ABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJ
CLASS 'SAODBC'
USING 'SQL Anywhere 12 CustDB';
CALL sp_remote_tables('ABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJ');
CALL sp_remote_columns ('ABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJ',
'ULCustomer');
CALL sp_servercaps ('ABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJABCDEFGHIJ');
The first two calls succeed. The sp_servercaps() call would have failed
as the argument was limited to 64 characters, which is too short.
This problem has been fixed. The sp_servercaps() now accepts up to 128 characters.
================(Build #3732 - Engineering Case #707922)================
UPDATE statements generated by the Entity Framework could have failed with
a syntax error if the table being updated had a uniqueidentifier key column.
This problem has been fixed.
================(Build #3731 - Engineering Case #707952)================
When using a version 10.0, 11.0 or 12.0 of ADO.NET provider with a version
9.0 server, the .NET string parameters are incorrect mapped to nvarchar.
This problem has been fixed.
================(Build #3599 - Engineering Case #699241)================
Using the SQL Anywhere ADO .NET Data Provider, the continuous closing and
reopening of a pooled connection was slower than it was under version 9.0.2.
This problem has been corrected.
SAConnection conn = new SAConnection( connectString );
conn.Open();
.
.
.
conn.Close();
================(Build #3597 - Engineering Case #700928)================
The Entity Framework migration tools could have thrown an exception if the
schema name of an entity set was not specified.
For example:
public class BlogContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
}
[Table( "Blogs" )] // [Table( "Blogs", Schema
= "GROUPO" )]
public class Blog
{
public int BlogId { get; set; }
public string Name { get; set; }
public string Url { get; set; }
public int Rating { get; set; }
}
This has now been fixed.
================(Build #3520 - Engineering Case #692504)================
Entity Famework queries could have returned incorrect result when using parameters.
This has been fixed.
================(Build #3499 - Engineering Case #690295)================
An IIS web server application could have crashed after running for a few
days. This has now been fixed.
================(Build #3495 - Engineering Case #689764)================
The assembly names of version 3.5 and 4.0 providers in the policy config
file were not correct. This meant that version 3.5 and 4.0 policy files did
not redirect old versions to a newer version. This has been corrected
================(Build #3466 - Engineering Case #687578)================
Applications using the .Net provider could have crashed after running for
some time. In rare occasions, the provider could have attempted to drop a
prepared statement twice. This has now been fixed.
================(Build #3447 - Engineering Case #683999)================
When calling the method SADataReader.GetSchemaTable, the SQL Anywhere provider
creates two prepared statements which were not dropped immediately in some
situations. Actually, the statements are dropped either when the SACommand
objects (created in SADataReader.GetSchema Method as local variables) are
garbage collected, or when creating a new command and the number of prepared
statements has exceeded the 'max_statement_count' option. Still, the SADataReader.GetSchema
method has now been modified to dispose of the commands within the SADataReader.GetSchema
method. This will drop the prepared statements immediately.
================(Build #3427 - Engineering Case #682662)================
A small amount of memory was leaked when an application using the ADO.NET
interface executed a distributed transaction. This has now been fixed.
================(Build #3424 - Engineering Case #681915)================
A client application could have failed with an AccessViolationException,
instead of a normal communication error, when a connection was dropped. This
problem has been fixed.
================(Build #3387 - Engineering Case #675805)================
It is possible, although rare, for the machine.config file to contain multiple
registered SQL Anywhere ADO.NET providers. When unregistering, the SetupVSPackage.exe
utility only removed one SQL Anywhere ADO.NET provider from the machine.config
file. This problem has been fixed so that SetupVSPackage.exe now looks for
all registered SQL Anywhere ADO.NET providers.
================(Build #3359 - Engineering Case #671397)================
The following Entity Framework datetime functions were not mapped to SQL
Anywhere functions:
AddDays, AddHours, AddMicroseconds, AddMilliseconds, AddMinutes, AddMonths,
AddSeconds, AddYears, DiffHours, DiffMicroseconds, DiffMilliseconds, DiffMinutes,
DiffMonths, DiffSeconds, DiffYears.
For example:
Entities db = new Entities();
var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays(
x.OrderDate, DateTime.Now ) > 100 );
string trace = ( ( ObjectQuery ) query ).ToTraceString();
This problem has been corrected by adding new function handlers for mapping
Entity Framework datetime functions to the SQL Anywhere functions 'DATEADD'
and 'DATEDIFF'.
================(Build #3347 - Engineering Case #669227)================
On systems running Windows Vista or later, when using the Visual Studio Add
Connection wizard the SQL Anywhere .NET provider listed USER DSNs only in
the ODBC Data Sources drop-down list. The SYSTEM DSNs are omitted. This problem
has been corrected. The SetupVSPackage tool must be run to install this fix.
It should be noted that on 64-bit Windows, only the 64-bit SYSTEM DSNs are
listed (after this correction). Any 32-bit SYSTEM DSNs are not displayed.
In Visual Studio 2008's design environment (which is 32-bit on 64-bit platforms),
the Test Connection button will attempt to establish a connection using the
32-bit equivalent of the 64-bit DSN. If the 32-bit DSN does not exist, the
test will fail.
================(Build #3342 - Engineering Case #667672)================
The Entity Framework function 'DiffDays' was not mapped to the SQL Anywhere
function 'Days'.
For example:
Entities db = new Entities();
var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays(
x.OrderDate, DateTime.Now ) > 100 );
string trace = ( ( ObjectQuery ) query ).ToTraceString();
This problem has been fixed.
================(Build #3341 - Engineering Case #668141)================
Calling the method SATcpOptionsBuilder.ClientPort could have caused the exception
InvalidCastException to have been thrown.
For example:
SATcpOptionsBuilder options = new SATcpOptionsBuilder( "localonly=yes;port=6873"
);
string cport = options.ClientPort;
This problem has been fixed.
================(Build #3340 - Engineering Case #667762)================
SetupVSPackage.exe would have failed to add some dlls to the Global Assembly
Cache on 64 bit Windows systems. This problem has been fixed.
Also, a new command line option 'salocation' (or 'sal') has been added to
SetupVSPackage to allow specifying the SQL Anywhere install location. If
'salocation' is specified, SetupVSPackage will use it to locate the necessary
dlls. If 'salocation' is not specified, SetupVSPackage will use SQL Anywhere
registry keys to locate the dlls.
================(Build #3337 - Engineering Case #667441)================
Misleading error messages would have been returned to the client when opening
a connection using an invalid DSN. This problem has been fixed.
================(Build #3328 - Engineering Case #667927)================
The SQL Anywhere .NET Provider, running in 64-bit mode, might have inadvertently
attempted to load a 32-bit language resource DLL (e.g., dblgen12.dll) and
failed with an error. This problem has been corrected.
================(Build #3310 - Engineering Case #663470)================
On CE devices, if multiple applications were running simultaneously, the
library dbdata.dll could have been deployed multiple times to the temp directory.
This problem has been fixed.
Additionally, the version number has been added to the native dll name (i.e.
dbdata12.dll). This will allow running multiple versions of the provider
simultaneously on Windows CE.
================(Build #3299 - Engineering Case #661459)================
The .NET provider was incorrectly assuming that a Sybase IQ 12.7 server supported
the NCHAR datatype. This resulted in a failure to establish a connection
to a Sybase IQ 12.7 server. This problem has been fixed.
================(Build #3286 - Engineering Case #657542)================
The results of an Entity DAta Model query could have been non-deterministic.
For example, having a GridView with the properties "AllowPaging"
and "AllowSorting" set to "True", would have returned
a "Result is non-deterministic" warning (SQLCODE 122). This has
been fixed by adding an ORDER BY clause to the generated SQL.
================(Build #3280 - Engineering Case #656481)================
An application using the ADO .Net provider, and calling the method SAConnection(),
could not have successfully connected to an IQ 12.7 server. A run-time error
(iAnywhere.Data.SQLAnywhere.SAException) would have occurred when the provider
tried to parse the server version string. This problem has been resolved.
================(Build #3276 - Engineering Case #654446)================
If there were multiple applications running simultaneously, the ADO.NET provider
could have failed to load dbdata.dll. This has now been fixed.
================(Build #3718 - Engineering Case #704775)================
When multiple TLS connections were made from a single client application,
a small amount of memory would have been leaked for each connection beyond
the first. This could also have occurred in the database server, but only
when the server made outgoing TLS connections (i.e. for mirroring or to remote
servers). This has been fixed.
================(Build #3718 - Engineering Case #704775)================
When multiple TLS connections were made from a single client application,
a small amount of memory would have been leaked for each connection beyond
the first. This could also have occurred in the database server, but only
when the server made outgoing TLS connections (i.e. for mirroring or to remote
servers). This has been fixed.
================(Build #3718 - Engineering Case #704609)================
If a TLS library could not be found, or an error occurred when loading it,
the resulting error message would have contained the system charset name
rather than the name of the library. This has been fixed.
================(Build #3660 - Engineering Case #703452)================
If a SQL Anywhere client application exited abnormally, System V semaphores
that were allocated by the SA libraries were not cleaned up. This problem
affected all Unix platforms except Solaris, and has now been fixed.
================(Build #3651 - Engineering Case #705863)================
Connections from Linux clients may not have included the EXE value in connection_property(
'AppInfo' ). In particular, this affected applications where the effective
user for the application was changed. This has been fixed so that the EXE
value is now included in connection_property( 'AppInfo' ) on Linux, even
if the effective user is changed.
================(Build #3529 - Engineering Case #693539)================
The changes for Engineering case 635466 introduced a problem where, on machines
under heavy load, TCP connection attempts could have failed with an incorrect
error code. On certain operating systems, the connection attempt could have
hung. This has been fixed.
================(Build #3412 - Engineering Case #680183)================
In rare timing-dependent cases, a multi-threaded client application that
made simultaneous connection attempts from different threads may have crashed.
This has been fixed.
================(Build #3384 - Engineering Case #675293)================
If an initial connection was made to a blank-padded database, and the connection
was redirected because of the NodeType connection parameter, the connection
would have incorrectly failed with the error "Database cannot be started
-- ???". If the LogFile connection parameter was used to get more information,
the generated file would have contained the line "Communication function
i_cs_ProtocolErrorP code 0". This has been fixed.
================(Build #3352 - Engineering Case #670185)================
If a client was attempting to connect over TCP/IP to a server that had just
shut down, it is possible that the connection would have returned a SQLE_CONNECTION_ERROR
error rather than a SQLE_SERVER_NOT_FOUND. This has been fixed.
================(Build #3344 - Engineering Case #668603)================
In rare cases, an application could have failed to connect because of a TCP/IP
communication link failure. No specific reason for the failure would have
been logged to the file specified by the LOGFILE connection parameter. This
has been fixed.
Note, this problem affected the .Net provider, the ODBC, JDBC and OLEDB
drivers as well.
================(Build #3297 - Engineering Case #660204)================
Specifying a TCP timeout value of more than 2147 seconds could have caused
connection failures. This has been fixed.
================(Build #3294 - Engineering Case #659643)================
An application could have crashed if it was attempting an Integrated Login
or Kerberos connection and the connection to the server was lost. This could
have occurred if the server was stopped or terminated during the connection.
This has been fixed.
================(Build #3757 - Engineering Case #712102)================
If an application called CallableStatement/PreparedStatement/Statement.executeQuery()
and then subsequently called CallableStatement/PreparedStatement/Statement.getResultSet()
to retrieve the same result set that was generated by calling executeQuery(),
then the JDBC driver would have leaked the memory. This problem has now been
fixed.
Note, there are two workarounds for this problem, both of which are considered
better JDBC programming practices. The first is to use the ResultSet returned
by calling executeQuery() directly and thereby avoid the second unnecessary
call to getResultSet(). The other approach is to call execute() instead of
executeQuery(), followed by a call to getResultSet().
================(Build #3723 - Engineering Case #705368)================
If a JDBC application using the SQL Anywhere JDBC Driver called the "autoGeneratedKeys"
overload of Connection.prepareStatement(), Statement.execute() or Statement.executeUpdate()
with Statement.NO_GENERATED_KEYS, then the JDBC driver would incorrectly
throw a "generated keys not supported" exception. This problem
has now been fixed and calling these overloads with Statement.NO_GENERATED_KEYS
now simply calls the "non-autoGeneatedKeys" overload.
================(Build #3525 - Engineering Case #693005)================
If a JDBC application was launched, and no language resource DLL or shared
object was located, the application would have gone into a loop consuming
virtual memory until an "out-of-memory" error occurred. This problem
has been fixed.
================(Build #3480 - Engineering Case #687796)================
If an application using the SQL Anywhere JDBC driver attempted to exit, then
there was a very small chance the client would crash on non-MacOS systems;
however, on MacOS systems, the crash would have occurred every time. This
problem has now been fixed. Note that the original problem was introduced
with the fix for Engineering case 680183.
================(Build #3747 - Engineering Case #710978)================
If there were fewer SQLFreeHandle( SQL_HANDLE_ENV,... ) than SQLAllocHandle(
SQL_HANDLE_ENV,... ) calls, and at least one TCP/IP connection had been made,
unloading the ODBC driver dll, usually when the application exits, could
have taken much longer than it should have. This could also have occurred
if there were fewer SQLDisconnect calls than successful SQLConnect calls.
This has now been fixed.
================(Build #3745 - Engineering Case #711141)================
The ODBC driver could have crashed when executing a block insert statement
using data-at-execution time parameters. The problem would only have occurred
when mixing data-at-execution time parameters with regular parameters. This
has been fixed.
================(Build #3729 - Engineering Case #707201)================
In rare low-memory situations, a client application could have crashed on
startup if TCP/IP was being used. This has now been fixed.
================(Build #3726 - Engineering Case #706558)================
When executing a bulk update with SQLExecute, there was a chance that not
all rows would have been updated. If the UPDATE statement contained a WHERE
clause that did not match any rows, any subsequent rows in the batch would
have been ignored. This has been fixed.
================(Build #3579 - Engineering Case #699007)================
Calls to ODBC functions SQLGetDiagRec(with HandleType == SQL_HANDLE_ENV)
or SQLGetDiagField(with HandleType == SQL_HANDLE_ENV and DiagIdentifier==SQL_DIAG_MESSAGE_TEXT)
in the SQL Anywhere ODBC driver may caused a crash under certain circumstances.
This problem has been fixed.
================(Build #3540 - Engineering Case #694658)================
If a double-precision floating-point object (SQLDOUBLE) was not aligned on
an 8-byte boundary on a Windows Mobile ARM-based device, the SQL Anywhere
ODBC driver would have incorrectly issued the following error message when
an attempt was made to reference the object (for example, using SQLGetData()):
[Sybase][ODBC Driver]Invalid string or buffer length
On the ARM hardware platform, a double-precision value consists of two 32-bit
words and, when held in memory, the two words must appear consecutively and
must both be word-aligned (i.e., a multiple of 4). The ODBC driver has now
been corrected to check for an alignment that is a multiple of 4, not 8.
================(Build #3452 - Engineering Case #684608)================
ODBC/JDBC escape syntax incorrectly required uppercase keywords like IN or
FROM in scalar functions like POSITION and EXTRACT.
For example:
select {fn extract(month from '2011-05-07')}, {fn position('b' in 'abc')}
would have failed with syntax errors. If an uppercase keyword was used,
the query would have succeeded:
select {fn extract(month FROM '2011-05-07')}, {fn position('b' IN 'abc')}
This problem has been fixed.
Note: In Interactive SQL, the braces { and } must be doubled-up (i.e. {{
and }} ).
================(Build #3432 - Engineering Case #675119)================
If the Microsoft Firewall Client (FwcWsp.dll) was installed on a Windows
systems, applications would see a 20-second delay when the SQL Anywhere ODBC
driver was unloaded.
For example, if "Test Connection" was used when configuring a
Datasource Name (DSN), using the ODBC Datasource Administrator on a system
with Microsoft Firewall Client installed then a 20-second delay occurs after
the OK button is clicked.
A work-around has been developed for this problem. If the Firewall Client
DLL is present when the SQL Anywhere ODBC driver is unloaded, the Windows
Socket libraries are not unloaded by the driver. This avoids the 20-second
delay. In this case, the Windows Socket libraries are unloaded when the client
application terminates.
================(Build #3428 - Engineering Case #682755)================
Multithreaded client applications (e,g., ODBC, OLEDB, ADO.NET applications)
could have crashed with a memory access violation, or leaked memory, when
attempting simultaneous connections to a server. This problem has been fixed.
================(Build #3411 - Engineering Case #680039)================
A memory leak could have occurred when using the SQL Anywhere ODBC driver
in such a way that the driver was repeatedly loaded and unloaded by the Microsoft
ODBC Driver Manager on Windows Vista and Windows 7. This could have occurred
when repeatedly creating and subsequently freeing the ODBC Environment as
part of calling the SQL Anywhere ODBC driver. This problem occurs under Windows
Vista and Windows 7 only as a result of a bug in Microsoft's SHELL32.DLL
for these two operating systems. An Activation Context object is leaked
on each load of the DLL. A workaround has been developed to avoid the problem.
Another way to avoid the problem is to create and destroy the ODBC Environment
only once in an application and connect/disconnect as often as desired.
SQLAllocHandle( SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv );
SQLSetEnvAttr( henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0
);
loop
connect/disconnect many times
endloop
SQLFreeHandle( SQL_HANDLE_ENV, henv );
Note, Microsoft has published http://support.microsoft.com/kb/2624911, which
describes the problem with Windows Vista and Windows 7.
================(Build #3376 - Engineering Case #671099)================
When the ODBC driver ware loaded, part of its initialization involved loading
and initializing the system TCP/IP libraries, even in cases where TCP/IP
would not be used (eg. creating or viewing a DSN through the Data Source
utility). This could have caused delays or problems with some firewall software.
This has been fixed so that the TCP/IP libraries are now only loaded and
initialized when they will be used.
Note, this change also affect the other SQL Anywhere client libraries as
well, i.e. DBLib, OLEDB, ADO.NET, etc.
================(Build #3372 - Engineering Case #669581)================
If an application attempted to perform a wide or batched insert, and the
application did not bind or set enough parameters to match the number of
parameters within the prepared INSERT statement, and the wide insert or batch
insert size was greater than 1, then the application would have crashed.
This problem has now been fixed.
================(Build #3364 - Engineering Case #672184)================
If an application attempted to perform a wide insert using the SQL Anywhere
ODBC driver, or a batched insert using the SQL Anywhere JDBC driver, then
there was a very small chance the application would crash if the system was
low on memory or under stress. This problem has now been fixed.
================(Build #3286 - Engineering Case #657826)================
When using the Microsoft ODBC Data Source Administrator, a crash may have
resulted if an encrypted password had been specified and the "Test Connection"
button was used. This has been fixed.
================(Build #3267 - Engineering Case #652752)================
When starting dbisqlc, or an ODBC application with a connection string containing
LINKS=TCPIP, if there is an error connecting the connection dialog is displayed.
It was incorrectly defaulting to "connect to a running database on another
computer", losing the LINKS=TCPIP setting. If TCP parameters were specified,
such as LINKS=TCPIP(PORT=2638), then it worked correctly. This has now been
fixed.
================(Build #3727 - Engineering Case #706876)================
A Microsoft Data Link Error could have occurred with newer versions of Microsoft
software when using the SQL Anywhere OLE DB provider. When the Test Connection
button was clicked, the following message would have been displayed when
the error occurred:
Test connection failed because not all properties can be set.
Window Handle (BAD VALUE)
Continue with test connection?
[Yes] [No]
The message was informational only and Yes can be clicked. If the credentials
and other connection information were correct, the connection succeeded.
This problem has been fixed. Instead of returning a NULL window handle to
the Microsoft software, the OLE DB Window Handle property is now marked as
unsupported, which removes the warning message.
================(Build #3425 - Engineering Case #683425)================
Additional changes were required for Engineering case 681396, where the server
may not start on HP-UX machines if there were many network interfaces. The
description for case 681396 mentioned Unix systems, but this problem was
actually limited to HP-UX only. A border case, as well as IPv6, were corrected
as well.
================(Build #3422 - Engineering Case #683161)================
A multithreaded application using the SQL Anywhere oledb driver could have
crashed with an access violation when a rowset was released. This problem
was introduced by the changes for Engineering case 662986, and has now been
fixed.
================(Build #3422 - Engineering Case #681419)================
Multi-threaded OLEDB applications could have experienced an access violation
when a rowset was released. This problem was introduced by the changes made
for Engineering case 662896 and has now been fixed.
================(Build #3309 - Engineering Case #662896)================
When using the OLEDB provider, if a statement was prepared, executed, and
then the ADO MoveFirst() (OLE DB RestartPosition() ) method was called when
the cursor type was forward-only, the statement would have become unprepared.
Subsequent attempts to execute the prepared statement would then have failed.
This problem has been corrected.
================(Build #3291 - Engineering Case #658887)================
The OLE DB DBSCHEMA_FOREIGN_KEYS rowset returned the following indicated
integer values for the UPDATE_RULE or DELETE_RULE referential actions.
CASCADE 0
if referential action is NULL 1
SET NULL 2
SET DEFAULT and RESTRICT 3
These values, derived from the ODBC SQLForeignKeys result set, did not match
the following OLEDB constants defined for these referential actions.
DBUPDELRULE_NOACTION = 0x0
DBUPDELRULE_CASCADE = 0x1
DBUPDELRULE_SETNULL = 0x2
DBUPDELRULE_SETDEFAULT = 0x3
Furthermore, the DBSCHEMA_FOREIGN_KEYS rowset should have returned strings
rather than integers for the UPDATE_RULE or DELETE_RULE referential actions.
The OLE DB specification states:
If a rule was specified, the UPDATE_RULE or DELETE_RULE value is one of
the following:
"CASCADE" — A <referential action> of CASCADE was specified.
"SET NULL" — A <referential action> of SET NULL was specified.
"SET DEFAULT" — A <referential action> of SET DEFAULT was
specified.
"NO ACTION" — A <referential action> of NO ACTION was specified.
Providers should return NULL only if they cannot determine the UPDATE_RULE
or DELETE_RULE. In most cases, this implies a default of NO ACTION.
Also, the fix for Engineering case 620136 did not handle the situation when
there was no declared Primary Key in the primary table but there were table
or column (not nullable) Unique Constraints that permitted the addition of
foreign keys.
These problems have been fixed. The Upgrade utility should be used to update
the OLE DB schema rowset support in any database used with ADO, ADOX or OLE
DB.
================(Build #3266 - Engineering Case #651383)================
As of the changes for Engineering case 633120, a SQL query producing multiple
result sets was not handled correctly by the SQL Anywhere OLE DB provider.
This problem has now been corrected. The cursor is no longer closed after
the first result set is processed.
================(Build #3759 - Engineering Case #713568)================
Mini-dump files generated by SQL Anywhere software on Linux system could
have been unusable. This problem was most likely to occur if the process
being dumped was using a large number of threads (> 480). This has now
been fixed.
================(Build #3605 - Engineering Case #701922)================
Use of some of the HTTP samples verbatim in a production system could have
caused exposure to Cross Site Scripting (XSS) issues. This has been fixed.
Note that it is highly recommended that application developers and DBAs
always review their web application code for possible security vulnerabilities
before they are put into production. The Open Web Application Security Project
(https://www.owasp.org) contains more information on how to secure your web
application.
================(Build #3565 - Engineering Case #715904)================
Installing SQL Anywhere in silent mode on Solaris systems may have resulted
in an error like:
"The following option names are invalid or are not exposed by the
registration key provided".
This has been fixed.
================(Build #3540 - Engineering Case #695079)================
When connected via jConnect, the procedure used to query the primary key
metadata of a table would have returned too many rows if the table had a
primary key column that was also a foreign key reference to another table.
This problem has now been fixed.
Note, an ALTER DATABASE UPGRADE will need to be performed on existing databases
in order to get the new jConnect metadata procedures.
================(Build #3539 - Engineering Case #695772)================
When creating a custom MSI install using the deployment wizard, two properties
were not being set correctly: UpgradeCode and ProductVersion. This has been
fixed so that they are now set correctly.
================(Build #3518 - Engineering Case #689954)================
An ODBC application could have crashed when attempting to connect if a thread
was unable to be started. This has been fixed.
================(Build #3513 - Engineering Case #691893)================
When installing an MSI file created by the Deployment wizard, the install
would have partially completed and then failed, rolling back the install.
This has been fixed.
================(Build #3485 - Engineering Case #687835)================
If an MSI install was built using the Deployment wizard, and Sybase Central
was selected but Interactive SQL was deselected, the subsequent install of
Sybase Central would have failed on exit. The error:
Interactive SQL could not be launched.
Please change the plug-in properties and
add the isql.jar file to its path.
was due to Sybase Central expecting ISQL.jar to be installed. This has been
corrected by adding a dependency on ISQL.jar when an install of Sybace Central
is created.
================(Build #3478 - Engineering Case #686304)================
When SQL Anywhere components were running in the isolated session 0 (ie,
the services session) of Vista and later Windows operating systems, but were
not actually running as services, the components could have attempted to
display GUI elements. Due to session 0 isolation, these GUI elements were
not accessible to users. To execute as a non-service within session 0, the
program was likely to have been launched as a child of a service. On Vista
and later versions of Windows, SQL Anywhere components now suppress GUI components
when running in session 0 rather than just when running as a service.
================(Build #3476 - Engineering Case #685894)================
When running at a verbosity higher than 0, the Relay Server Outbound Enabler
was not obscuring the security token and passwords in the log file. This
has been fixed so that their values are now hidden by ******, regardless
of verbosity level.
================(Build #3467 - Engineering Case #685289)================
When performing an archive backup via an external backup provider, the database
server provided incorrect min_iosize & max_iosize parameters to the provider
when calling the syb_defineapi() function. Generally, the min_iosize was
set to what is actually the server's maximum IO size and max_iosize was set
to 512K. Usually, the min_iosize was larger than the max_iosize. This problem
has been fixed by setting the min_iosize to 2K and the max_iosize to the
server's actual max buffer size.
================(Build #3390 - Engineering Case #676364)================
The version of zlib used by the SQL Anywhere and MobiLink clients and servers
contained security vulnerabilities documented under US CERT Vulnerability
notes VU#680620 and VU#238678. These are fixed in zlib version 1.2.3. SQL
Anywhere and MobiLink clients and servers now use zlib version 1.2.5.
Links:
http://www.kb.cert.org/vuls/id/680620
http://www.kb.cert.org/vuls/id/238678
================(Build #3376 - Engineering Case #674262)================
When 64 bit versions of SQL Anywhere, MobiLink or the Relay Server were installed,
and none of the corresponding 32-bit features were installed (which is the
default feature selection), the Start menu shortcuts to dblang.exe ("Change
language to <language>") would not have worked. This has been
fixed.
================(Build #3367 - Engineering Case #672577)================
If the PATH environment variable placed earlier versions of SQL Anywhere
before version 12.0 in the path, then newdemo.bat would have launched earlier
versions of SQL Anywhere utilityes, but used the version 12 Scripts folder.
This may have resulted errors if the earlier version did not support the
same SQL language that was used by the scripts in the Scripts folder. This
problem has been fixed. The newdemo.bat file will now reference the tools
explicitly by their path.
Note, the newdemo.bat file is referenced by the SQL Anywhere documentation
whenever it is desirable to start with a newly initialised version of the
demonstration database.
================(Build #3365 - Engineering Case #672739)================
A number of edits have been made to the SQL Anywhere server, the MobiLink
server and UltraLite error messages to improve readability and to make the
wording more consistent with the SQL Anywhere documentation. These changes
include minor grammatical corrections, and changes to enforce consistency
with hyphens and capitalization. No changes were made to SQLCODE, SQLSTATE,
or ODBC error states for any of these messages.
================(Build #3364 - Engineering Case #669747)================
On Linux systems, when installing the SQL Anywhere Monitor EBF, the installer
would have removed the old copy from the samonitor_oldXX directory after
migrating samonitor.db. This behavior was different from 12.0.0 EBFs which
would always have left the old copy in the samonitor_oldXX directory. This
has been fixed.
================(Build #3364 - Engineering Case #661180)================
On Linux systems, if the SQL Anywhere Monitor EBF was installed as a non-root
user, and the SQL Anywhere Monitor service had been started by the root user,
the following error messages would have been displayed:
Migrating SQL Anywhere Monitor database
Connecting...
Can't connect to source database.
[Sybase][JDBC Driver][SQL Anywhere]Specified database not found
Rolling back files in /opt/samonitor12 ...
wc: ./.ebf_20110601-1149/samonitor.db: Permission denied
Cleaning up ...
This has been fixed so that the following error message is now displayed:
The setup program was unable to stop a running instance of SQL Anywhere
Monitor.
Please stop it manually and run the setup program again.
A workaround is to stop the SQL Anywhere Monitor service manually, then
re-run the EBF installer.
================(Build #3359 - Engineering Case #668771)================
When building a Deployment wizard install MSI, and select Chinese (ZH) as
the deployment language. progress messages would have been displayed in English.
This has been corrected so that they are now displayed in Chinese.
================(Build #3355 - Engineering Case #669408)================
On Unix, if SQL Anywhere was installed into the default location as user
A, logging in as user B and checking for updates would have failed with an
error like, "Could not check for updates." The installed.ini file
only had read and write permissions for the current user and group. This
has been fixed by giving broader permissions on the file so it could be used
by "other" users.
================(Build #3354 - Engineering Case #668766)================
When creating a 64-bit Deployment wizard MSI install, containing both 64-bit
and 32-bit software, only one set of Sybase Central plugins would have been
registered when installing on a 64-bit system. This has been corrected so
that both 32-bit and 64-bit plugins are now registered.
================(Build #3353 - Engineering Case #668768)================
After uninstalling a Deployment wizard .MSI install made with default contents,
several .JPR files would have been left behind in the SQL Anywhere 12\java
directory.
This has been fixed so that these files are now correctly uninstalled.
================(Build #3348 - Engineering Case #669407)================
When uninstalling on Solaris, it was possible to see an error like:
find: stat() error /opt/sybase/sqlanywhere12/sun/jre160/lib: no
such file or directory
This has been fixed. It should be noted that despite the error, the uninstaller
would have completed successfully.
================(Build #3345 - Engineering Case #668765)================
When running the Deployment Wizard, clearing the default MSI name in the
Destination Path page of the wizard and clicking the Next button would have
caused an unhandled exception. This occurred due to the fact that the filename
was not valid. This has been corrected by graying out the Next button if
the filename is left blank.
================(Build #3321 - Engineering Case #665004)================
When trying to connect using the Ruby DBI interface, the driver did not raise
an error if the username/password was invalid. Instead it silently failed.
This has been fixed.
================(Build #3301 - Engineering Case #669009)================
When upgrading from 12.0.0 to 12.0.1, if the 12.0.0 samples had been installed
to a non-default location, the upgrade to 12.0.1 installed any new or reorganized
samples to the default sample location. This has now been fixed.
Note that 12.0.1 EBFs can be now applied directly to 12.0.0 installations
- effectively performing an upgrade. Therefore if a 12.0.0 installation
has not yet been upgraded to 12.0.1, use of a 12.0.1 EBF with this fix will
avoid this problem. If a 12.0.0 installation had been upgraded with a build
without this fix, uninstalling the product will not remove all the sample
files. Those files will need to be removed manually.
================(Build #3298 - Engineering Case #661242)================
A silent install of SQL Anywhere Monitor in which the location of the database
(DIR_SQLANY_MONITOR) was not specified, would have caused the database to
be installed to %SystemDrive%\CommonDocFolder. This has been fixed so that
the correct default location is now used (%ALLUSERSPROFILE%\Documents\SQL
Anywhere Monitor 12).
================(Build #3298 - Engineering Case #661188)================
The 64-bit UltraLite ODBC driver (Bin64\ulodbc12.dll) was not being correctly
registered. This would have resulted in the failure of Interactive SQL and/or
Sybase Central to load an UltraLite database. The has been fixed.
Alternatively, the driver can be registered manually using the following
command:
regsvr32.exe %SQLANY12%\Bin64\ulodbc12.dll
================(Build #3295 - Engineering Case #660190)================
The folder names under %SQLANYSAMP12%\UltraLiteJ\Android\CustDB used mixed
case and in some cases were incorrect in the GA release of 12.0.1. This
caused Eclipse to fail when building the sample. This has been fixed such
that future remastered releases will use the correct case. However, EBF
installs will not fix these incorrect folder names. A workaround is as follows:
Before attempting to build the sample in Eclipse, ensure that the sub-directory
names are as show below. Note that all names are lower case and that hyphens
(-) should be used, not underscores (_), where applicable.
libs
res
src
libs\armeabi
res\drawable-hdpi
res\drawable-ldpi
res\drawable-mdpi
res\layout
res\menu
res\values
src\com
src\com\sybase
src\com\sybase\custdb
================(Build #3281 - Engineering Case #659357)================
Running the Deployment wizard when SQL Anywhere had been installed to directory
with a path containing multi-byte characters would have caused the generation
of the MSI to fail with an error like: "C:\Syç¾ç½²\SQL Anywhere 12\bin32\dblib12.dll
(Not Found)". This has been fixed.
================(Build #3769 - Engineering Case #715597)================
Performance of statements that select from a stored procedure call is slightly
improved when the call results in a SQLError.
================(Build #3769 - Engineering Case #715309)================
The server was incorrectly accepting the special values NaN, INF, and INFINITY
for double and float data types when receiving host variable values. This
has been fixed. Now the server will set the SQL error "Value NaN/INF
out of range for destination".
================(Build #3768 - Engineering Case #715473)================
In extremely rare cases, the server may have crashed on shutdown on multi-CPU
machines. This has been fixed.
================(Build #3768 - Engineering Case #715310)================
If a mirror or copy node was shutdown, and it was actively applying log operations
from the primary or its parent, the server could have failed assertion 100904
- "Statement interrupted by user". This has been fixed by not failing
this assertion when the server is in the process of shutting down.
================(Build #3768 - Engineering Case #713922)================
If a query contained two predicates on the same column T.A, of the form 'T.A
> constant' and 'T.A = R.A' , and an index on the column T.A exists, the
cardinality of the index scan
with the predicate 'T.A = R.A' was incorrectly computed always using the
predicate 'T.A > constant'. This may have affected the quality of the
best plans for such queries. This has been fixed.
================(Build #3766 - Engineering Case #714752)================
Queries using text indexes with constructs of the form CONTAINS( ... 'xxx*'
... ) may have had poor performance. This has been fixed.
================(Build #3766 - Engineering Case #707918)================
In rare cases, a query using a parallel NestedLloopsJoin could have caused
the server to crash. This has been fixed.
A workaround is to disable intra-query parallelism for the affected query.
================(Build #3765 - Engineering Case #714777)================
In rare cases, a mirroring server could have crashed if it received an invalid
request from another mirror server. This has been fixed to no longer crash.
================(Build #3765 - Engineering Case #714776)================
In rare timing dependent cases, a high availability mirror or copy node could
have incorrectly failed with the assertion 100927. The assertion could have
occurred just after the mirror or copy node had connected to its partner
or parent and had just started synchronizing. This has been fixed.
================(Build #3765 - Engineering Case #714656)================
The server could have crashed when starting a database. If the server was
in the process of shrinking the cache, references to memory that were no
longer available were possible. This has now been fixed.
================(Build #3763 - Engineering Case #714440)================
In a high availability system, a forced or preferred server fail-over could
have failed to restart the database on the primary server if all of the following
conditions held:
- the database character set was different from the operating system character
set
- the database name (or alias) contained characters other than 7-bit ASCII
characters
- an "ALTER DATABASE SET PARTNER FAILOVER" statement was executed,
or a preferred partner was defined and the current primary was the non-preferred
partner.
This has been fixed.
================(Build #3761 - Engineering Case #713914)================
For a pooled CmdSeq connection or HTTP connection, connection_property( 'ApproximateCPUTime'
) incorrectly included CPU time from before the connection was reused, and
connection_property( 'LoginTime' ) was not reset when a pooled connection
was reused. This has been fixed, so that 'ApproximateCPUTime' now only includes
time from when the application connected, and 'LoginTime' is set to the time
when the application connected.
================(Build #3759 - Engineering Case #713681)================
If the server was displaying the usage window, or was very early in the start-up
process, and the Windows machine the server was running on was suspended,
the server could have crashed when the machine was restarted. This has been
fixed.
================(Build #3758 - Engineering Case #711791)================
Recursive queries can not contain aggregate functions. When written using
a window (OVER clause), aggregates were improperly allowed. In some cases
this could have lead to the server crashing under certain system conditions.
This has been fixed, queries with windowed aggregate functions now correctly
give an error.
================(Build #3757 - Engineering Case #424085)================
When a computed column is added to a table, the expression used to generate
the column values may give an error, the actual error will depend on current
option settings and the current connected user. The following examples show
ways that a computed column may give an error in some circumstances only:
- Use an unqualified user-defined function (UDF). If the current user does
not include the UDF in the lookup path, an error is returned.
- Miss-spell a UDF name. There is no checking done when the column is added.
Any use of the table fails.
- Create the column referencing a UDF then drop it. Even if 2. is fixed,
there is no dependency tracking to prevent 3.
- Use a cast that gives an error at build time (e.g, TIME -> INT). The
table causes an error unless the Conversion_error option is Off.
- As with 1. 2. or 3. , use a sub-select referencing a table, view or procedure
that is unqualified or non-existent.
- Use features in the compute expression that cause SQL flagger errors
to be returned. If the connection options give a flagger error, the table
can not be used.
http://dcx.sybase.com/index.html#1201/en/dbusage/defining-computed-javause.html*d5e620
When the expression for a computed column gives an error, it does so for
any query that references the table (even if the table is not modified by
the statement.
As a best practice, computed columns should be defined with an expression
that is computed in the same way for all connections and all users that have
permission to read from the table.
================(Build #3755 - Engineering Case #713113)================
In rare timing dependent cases, a mirror or copy node could have crashed
or failed assertions (the most likely assertion was 100927). This could
have occurred when very frequent transactions were committed on the primary
and the mirror or copy node was not applying the operations as fast as it
was writing them (i.e. db_property( 'LastWrittenRedoPos' ) is significantly
more than db_property( 'CurrentRedoPos' )). This has been fixed.
================(Build #3755 - Engineering Case #712964)================
The server could have crashed in very rare cases while attempting to close
a connection that had previously made an external environment call if the
external environment call subsequently made a server side request that obtained
table locks which were still being held when the connection was closed. This
problem has now been fixed.
================(Build #3755 - Engineering Case #712128)================
In rare cases, the server could have hung while trying to shut down a database
if there were open connections that subsequently had open Remote Data Access
connections. This problem has now been fixed.
================(Build #3754 - Engineering Case #712884)================
In very rare timing dependent cases, if a mirroring primary failed over and
then failed back, one partner could have received a log mismatch error and
shutdown, and transactions that had been submitted could have been lost.
Specifically, in order for this to have occurred with partners S1 and S2:
- S1 must initially have been the primary, failed or otherwise have shutdown,
causing a failover to S2
- S2 took over as primary
- while S1 was restarting, S2 must have lost quorum and have been shutting
down
In which case it was possible for S1 to have become primary again, even
though it was missing the transactions from when S2 was primary.
This has been fixed to ensure that S1 will not be primary in this case,
and S2 will continue to be primary once it restarts.
================(Build #3754 - Engineering Case #712851)================
A cloud partner could have hung upon losing quorum. This problem has now
been fixed.
================(Build #3754 - Engineering Case #712722)================
Under rare circumstances, rollback of a DML statement that affected a table
with at least one immediate text index defined could have caused production
assertion failure 200112. This has been fixed.
================(Build #3754 - Engineering Case #712087)================
While using blocking timeout options in the presence of other connections
accessing referenced tables, ALTER TABLE ... DROP FOREIGN KEY statements
could have caused the server to fail assertion 102813. This has been fixed.
Now the alter table statement fails, properly displaying a locking error.
================(Build #3754 - Engineering Case #706150)================
In rare cases, a server may have received an odd ClassNotFoundException when
making a Java external environment call, even though the class had previously
been successfully loaded. This problem has now been fixed.
Note that this change also greatly improves the performance of loading classes
from the database.
================(Build #3753 - Engineering Case #711139)================
Under exceptionally rare conditions, the server may have crashed while accepting
a new shared memory connection, if the client application exited during connect
request processing. This has been fixed.
================(Build #3750 - Engineering Case #702214)================
If an application called an external environment procedure that was defined
with SQL SECURITY INVOKER and then subsequently made a stored procedure call
using the server side connection, then there was a chance the call would
have incorrectly fail with a permission denied error. This problem has now
been fixed.
================(Build #3749 - Engineering Case #711803)================
If the encrypt() or decrypt() functions were called with a non-null string
but a null encryption key, the functions returned null. This has been fixed.
An encryption key is required, so these functions will now raise an error
if the encryption key is null.
================(Build #3749 - Engineering Case #700123)================
If two connections made external calls that in turn attempted to access rows
that the other connection already had a lock on, then the server would incorrectly
hang the two connections rather than returning a deadlock error to one of
the connections involved. This problem has now been fixed.
================(Build #3748 - Engineering Case #711656)================
When fetching an unsigned int value from an sajdbc, iqjdbc or asejdbc remote
server, the returned value would always have been NULL. This problem has
now been fixed.
Note that this problem does not affect ODBC based remote servers.
================(Build #3748 - Engineering Case #708057)================
When fetching from a directory access table with a query of the form:
select ... from directory_access_table where ... file_name like 'abc%'
...
the server would have returned a syntax error. This problem only existed
if the comparison value (i.e. 'abc%') had no directory separators. For example,
a query of the form:
select ... from directory_access_table where ... file_name like 'abc\def%'
...
would have worked just fine. This problem has now been fixed.
================(Build #3748 - Engineering Case #691040)================
When fetchingd a string value containing trailing blanks from a proxy table,
the trailing blanks would have been stripped. This problem has now been fixed
and the string value will be exactly as returned by the underlying driver.
================(Build #3745 - Engineering Case #711129)================
In rare timing dependent cases, the server could have crashed if one or more
connections were using the blocking_others_timeout temporary option. This
has been fixed.
================(Build #3743 - Engineering Case #710285)================
Under rare circumstances, a server may have crashed while opening the result
set cursor of a batch or stored procedure when the cursor's query was a cached
simple SELECT. This has been fixed. A workaround is to turn plan caching
off (option Max_plans_cached = 0).
================(Build #3742 - Engineering Case #710072)================
Under certain rare circumstances, calling the system procedure sa_locks()
could have caused the server to fail a fatal assertion. This has now been
fixed.
================(Build #3740 - Engineering Case #668716)================
In rare circumstances, a database with snapshot isolation enabled could have
triggered
an assertion while updating values indexed by an immediate text index. This
problem required high contention on the base table. This has been fixed.
================(Build #3736 - Engineering Case #709203)================
If a jConnect or Open Client connection prepared a statement and called a
stored procedure with a set of host variables, then the server could have
crashed, or returned an odd "variable already exists" error, if
the stored procedure had a parameter or variable named @p0. This problem
has now been fixed.
================(Build #3736 - Engineering Case #708087)================
When using the VALIDATE TABLE or VALIDATE INDEX statements, the server could
have reported that there was an 'orphaned blob' (ie. a blob that is in the
database but not referenced by any row) when there were, in fact, no orphaned
blobs. To encounter this problem, there must have been deleted rows in the
database that contained unique blobs (not shared by any other row) and either
the deletes were uncommitted, or they had been left for the database cleaner
to remove at a later time. Rows not cleaned by the cleaner were more likely
to be seen on a read-only database, as the database cleaner is disabled for
read-only databases. This problem has been fixed.
Also when using the VALIDATE TABLE or VALIDATE INDEX statements, the server
could fail to report orphaned blobs when they did, in fact, exist. Whether
or not this problem occurred depended on random contents of memory as well
as the number of DML operations applied to the table prior to validation.
This problem has been fixed.
When reporting a validation problem, the server returns an error to the
client but also displays additional information in the server console. For
orphaned blobs, a blank message was erroneously displayed in the console.
This problem has been fixed.
================(Build #3736 - Engineering Case #707910)================
A query with many nested UNION query blocks may have taken a very long time
before query execution began. This has been fixed.
================(Build #3732 - Engineering Case #708199)================
The server would have returned a syntax error when trying to specify "client"
as a secure feature to be enabled or disabled (-sf command line option).
This has been fixed.
================(Build #3729 - Engineering Case #707553)================
In rare cases, the first time a mirror server or copy node connected to a
high availability primary or a read-only scale-out parent, the primary or
parent could have crashed. This has been fixed.
================(Build #3729 - Engineering Case #707064)================
When starting the Network Server on Windows, or calculating the 'IsPortableDevice'
server property, the server may have taken longer than necessary to obtain
information about the computer. This has been fixed, althought the difference
in the delay is not likely to be noticeable.
================(Build #3729 - Engineering Case #707002)================
The request for the graphical plan of a statement would have caused the server
to crash if the statement contained an IN predicate and the list consisted
of only host variables and an In List algorithm was chosen for it. This has
been fixed.
================(Build #3726 - Engineering Case #704963)================
If a predicate selectivity estimate was computed using a column histogram
and the lookup value was out of bound in the histogram, an index probe was
not then used for selectivity estimate. This has been fixed. This also improves
the selectivity estimates for a column for which the histogram is out of
date or contains incomplete data if an index on that column exists.
================(Build #3725 - Engineering Case #706371)================
The SQL Anywhere HTTP server may have crashed if a request was timed-out.
The crash would have occurred when a request had timed-out on a host under
very high CPU load (the server itself need not have been especially busy).
This has been fixed.
================(Build #3723 - Engineering Case #705529)================
In some cases, 64-bit servers could have crashes when executing queries using
TIMESTAMP WITH TIME ZONE values. The 32-bit server was not affected. This
has been fixed.
A workaround is either to use regular TIMESTAMP types, or use a 32-bit server.
================(Build #3723 - Engineering Case #703642)================
If a database had a user defined type based on nchar, nvarchar or long nvarchar,
then attempting to fetch a value defined with that user defined type would
have incorrectly returned a binary value when the connection was via jConnect
or Open Client. This problem has now been fixed.
Note that fetching nchar values defined with the nchar, nvarchar or long
nvarchar base datatypes is not affected by this problem.
================(Build #3723 - Engineering Case #702184)================
If an application had a Java stored procedure defined with SQL SECURITY INVOKER,
and the application subsequently called the stored procedure with two different
effective userids from the same database connection, then the server would
have incorrectly given a "table ExtEnvMethodArgs not found" error.
This problem has now been fixed.
================(Build #3723 - Engineering Case #696617)================
If the database option PUBLIC.Java_vm_options was set to contain only spaces,
then the server would have crashed when the JAVA external environment was
started. This problem has now been fixed.
================(Build #3722 - Engineering Case #704801)================
Cursors over SELECT statements referencing proxy tables could have returned
errors in the presence of publications for some of the tables. The error
depends of how complex the publications are. A typical error would be "assertion
failed: 102604 - Error building sub-select". This has been fixed.
================(Build #3721 - Engineering Case #704468)================
If deadlocks arose between connections using parallel execution plans, the
deadlock may not have been detected. Additionally, another connection later
contending for the same locks could have caused the server to crash. This
has been fixed.
A workaround is to set the option MAX_QUERY_TASKS to 1 for transactions
that are known to participate in deadlocks.
================(Build #3721 - Engineering Case #703234)================
If a parallel backup with backup option WITH CHECKPOINT LOG RECOVER had finished
its write pass but had disk I/O errors during its completion pass, then,
in exceptionally rare circumstances, the backup may have incorrectly been
marked as valid and no SQL error was returned. Also, if a parallel backup
of the database file was cancelled after its read pass then the server may
have crashed. Both problems have now been fixed.
================(Build #3720 - Engineering Case #640952)================
On Solaris systems, the server would have failed to start if the filesystem
for the temporary file ($SATMP) was of a size greater than 4TB. This problem
has now been fixed.
================(Build #3719 - Engineering Case #704057)================
If a database was created with 9.0.2.4029 or earlier, with any version of
10.0.0, or with 10.0.1.4072 or earlier, then upgraded (using the Upgrade
utility or ALTER DATABASE UPGRADE) to a newer build of SQL Anywhere, the
Unload utility could have erroneously generate SQL to re-create the jConnect-related
objects "jdbc_functioncolumns" and "sp_jdbc_getfunctioncolumns"
which are, after the builds indicated, included automatically in newly created
databases.
Similarly, if a database was created with any version of 10.0.0, and then
upgraded to any version of 10.0.1 or later, the Unload utility could erroneously
have generate SQL to re-create the SQL Anywhere internal function "sa_ansi_standard_packages".
During a reload, these problems would have generated a message such as the
following:
***** SQL error: Item 'jdbc_functioncolumns' already exists
These problems have been fixed.
================(Build #3719 - Engineering Case #701364)================
Queries with derived tables or views using UNION, EXCEPT, INTERSECT orRECURSIVE
constructs may have returned incorrect results. For this problem to have
occurred at least one child of the derived table or view would have had a
LIMIT, window function, or DISTINCT clause, and there was a predicate referring
only to the columns of the derived table or the view in the main query block.
This has been fixed.
================(Build #3719 - Engineering Case #697900)================
Attempting to execute a long SQL statement to create a stored procedure could
have failed with a "parse stack overflow" error (SQLCODE -131).
This problem may also have occurred when parsing a long and nested SQL statement.
This has been fixed.
================(Build #3713 - Engineering Case #702733)================
This change extends the fix for Engineering case 693560. In this case, the
parallel hash filter could deadlock if a runtime error occurred while it
was fetching. This has now been fixed.
================(Build #3713 - Engineering Case #693560)================
Under very rare circumstances, a server could hang if it had a large number
of processors and was executing a query with a parallel hash join. This
was more likely on systems with large numbers of cores (more than 8). This
has been fixed.
A workaround is to disable intra-query parallelism by setting option MAX_QUERY_TASKS=1.
(This only needs to be done for the statement or connection experiencing
the problem, if it can be isolated.)
================(Build #3712 - Engineering Case #703225)================
If a database had been created with a server from a version prior to 11.0.0,
and it contained a proxy table with an index, then unloads of this database
using a server from version 11.0.0 or later' would have generated an incorrect
CREATE INDEX statement containing the IN "SYSTEM" clause. This
has been fixed.
================(Build #3712 - Engineering Case #703104)================
When translating a transaction log with certain types of corruption, the
Log Translation utility could have terminated silently, without reporting
a problem. To the user, it would have appeared as if the translation completed
successfully. This problem has been fixed.
================(Build #3712 - Engineering Case #703100)================
When querying the TcpipAddresses, HttpAddresses, or HttpsAddresses properties
from a server running on a Unix platform, any IPv6 addresses may have included
a zone indicator (eg. the "%2" in "(fd77:55d:...:6a1f%2):2638".
This was not useful outside the server's machine and should not have been
included in the value of this property. This has been fixed.
================(Build #3712 - Engineering Case #703083)================
If the number of databases on the command line was near to or greater than
the server concurrency setting (-gn), then the server could have crashed,
or reported any of various assertion failures, during startup. The Personal
Server was particularly susceptible since its default concurrency is only
20. This problem has been fixed.
================(Build #3712 - Engineering Case #702738)================
The server could have become deadlocked when updating blobs in a table with
articles or triggers. This has now been corrected.
================(Build #3712 - Engineering Case #701652)================
When shutting down a database server on a Windows machine with a SQL Anywhere
Volume Shadow Service (VSS) writer service active, the database server could
have logged the message "Registered with the SQL Anywhere Volume Shadow
Copy Service writer." many times to the console log. This problem has
been fixed.
================(Build #3712 - Engineering Case #696917)================
With the QAnywhere .NET client, the elapsed time to queue messages was substantially
slower than that of version 9.0.2. Several performance optimizations have
been made, bringing the timings closer to those for version 9.0.2.
Note that the SQL client API is no longer supported by default. If the
SQL client API is needed, the QAnywhere message store must be initialized
using qaagent -si with the new option -sqlapi.
================(Build #3711 - Engineering Case #702296)================
When generating a reload.sql script, the server did not double-up single
quotes and backslash characters in constant strings for dbspace file names
in the CREATE DBSPACE statement, directory server paths in the CREATE SERVER
statement, or AT location clauses of the CREATE EXISTING TABLE statement.
As a result running the reload script would have failed and the generated
objects would not have worked. This has been fixed.
================(Build #3709 - Engineering Case #702274)================
A potential security problem with the server has been corrected.
================(Build #3709 - Engineering Case #701339)================
The server may have crashed when using a cached query plan if the plan useed
a row column variable in a Distinct Hash strategy and the row column variable
was of type string or numeric. Row column variables are column names that
are used with a REFERENCING table alias name from the CREATE TRIGGER. This
has been fixed.
================(Build #3707 - Engineering Case #702086)================
If a new IP address was added to a machine running a SQL Anywhere server,
the server may have failed to recognize the new IP address. This would only
have occurred when the server was running on a portable device (eg. laptop),
or if the -xm switch was specified. This has been fixed.
================(Build #3707 - Engineering Case #701151)================
Read-only connections on an OEM server were not able to drop local temporary
database objects. This has been fixed.
================(Build #3706 - Engineering Case #701327)================
If an application attempted to fetch data from an ADS proxy table using a
64-bit server, then there was a very good chance the server would have crashed.
This problem has now been fixed.
================(Build #3683 - Engineering Case #708826)================
In rare, timing dependant cases a copy node in a mirroring read-only-scale-out
setup may have crashed. This has been fixed.
================(Build #3683 - Engineering Case #708518)================
Mirroring copy nodes could have hung on shutdown with one core at 100% utilization.
================(Build #3683 - Engineering Case #708426)================
In rare timing dependent cases, a mirror server or copy node could have crashed
while it, or the mirrored database, was shutting down. In order for the crash
to have occurred, a copy node child must have begun to request log pages
from the stopping server. This has now been fixed.
================(Build #3680 - Engineering Case #709909)================
In rare, timing depending cases, the server could have crashed. This was
more likely to have occurred when multiple database events could start and
stop concurrently on multi-core computers. This has been fixed.
================(Build #3679 - Engineering Case #707904)================
If the root database restarted soon after a copy node connected to it, the
copy node could have, in rare timing dependent cases, crashed or failed assertions.
This has been fixed.
================(Build #3672 - Engineering Case #707037)================
In rare timing dependent cases, a high availability partner or copy node
server could have crashed. Additionally, in rare cases, the arbiter could
have reported the following message to the console: "arbiter already
has two connections". These problems could have occurred when a partner
detected loss of quorum, when a copy node was attempting to connect back
to its original parent after being connection to an alternate parent or the
root server, or if a connection between mirror servers failed. This has been
fixed.
================(Build #3670 - Engineering Case #707529)================
If the primary server failed in some timing dependent cases, the mirror server
could have failed to take over as primary. When this problem occurred, the
mirror database would have restarted and be attempting to determine its role
until the primary was restarted, or the ALTER DATABASE ... FORCE START statement
was executed on the mirror server. This has been fixed.
================(Build #3664 - Engineering Case #707019)================
When the database server was running a database whose page size was smaller
than the cache's page size, dynamic cache sizing could have chosen a cache
size that was too small, which could have resulted in a performance penalty.
This problem has been fixed.
================(Build #3661 - Engineering Case #706892)================
There are many reasons for a database, that is a partner in a High Availability
system or a copy node, to be restarted. In several cases, no reason for a
restart was logged to the console. This has been fixed so that a message
indicating the reason for a restart is now logged to the console.
================(Build #3658 - Engineering Case #706724)================
The server was failing to redirect an HTTP request made to a secure web-service
(requiring HTTPS protocol) when the request specified an ipv6 address. This
has been fixed.
================(Build #3656 - Engineering Case #706510)================
A server would have leaked memory, and may eventually have run out of memory,
if a very large number of Open Client or jConnect secure password connection
requests were made. This problem has now been fixed.
================(Build #3653 - Engineering Case #706179)================
When a server in a mirroring system tried to start up a database as a mirror
or copy node, it was possible for the server to receive a transaction log
mismatch if there was a problem connecting to the primary or the copy node's
parent server. This would have caused the database to shut down, and subsequently
the server, if no other databases were running on the server. In this particular
case, there was not actually a log mismatch, and so the database would have
restarted successfully without replacing database files. The error message
printed in the console was: "Transaction log does not match log on mirror
partner". This has been fixed.
================(Build #3653 - Engineering Case #706174)================
If a High Availability partner server encountered a disk full condition,
is was possible for both partners to hang. This has been fixed so that the
partner that encounters the disk full condition stops immediately. The other
server should be able to continue as the primary or take over as the primary.
Taking over requires that the primary and mirror were synchronized.
================(Build #3653 - Engineering Case #706158)================
A High Availability mirror server could have crashed when starting up or
restarting when it was in the "determining mirror role" phase.
The primary server must also have had a read-only scale-out copy node connected
to it, and a transaction log rename was being performed on the primary server.
This has been fixed.
================(Build #3650 - Engineering Case #704453)================
Execution of the system function USER_NAME() in a login check stored procedure
(which is set through the login_procedure database option) could have caused
a server crash. This would have occurred when using server-side connection
pooling, and has now been fixed.
================(Build #3647 - Engineering Case #705557)================
In rare timing dependent cases, it was possible for a server that was the
parent of a scale out copy node, or the primary in a scale out system, to
incorrectly fail requests with a thread deadlock error. It was also possible
(but less likely) for the parent or primary to hang. The thread deadlock
and hang were more likely when the scale out copy node could connect to the
parent or primary, but the parent or primary could not connect back, perhaps
due to an incorrect connection string for the copy node server mirror, or
due to a firewall issue. This has been fixed so that the server no longer
hangs and thread deadlock is much less likely.
================(Build #3647 - Engineering Case #705543)================
In a mirroring system, it may have been possible for a copy node to connect
to its parent and report that it was connected, but not receive log pages.
This has been fixed.
If a copy node lost its host name because of a network problem at any point,
the copy node's parent would have been unable to connect to the copy node.
This would have appeared in the logs like the copy node connected to the
parent without any problems, but the parent would have been unable to connect
back. The parent would then drop the connections and the copy node would
have made the connection again, causing an infinite cycle that caused the
copy node to be unable to stay connected or receive log pages. This has been
fixed.
If a copy node tried to connect to its parent, but was unable to resolve
the parent's host name during connection due to network problems, the copy
node would have connected to the primary and never tried to connect to its
parent again. This has been fixed.
================(Build #3647 - Engineering Case #702423)================
While a copy node server was shutting down or restarting a mirrored database,
the database may have made connections to the copy node's parent. This has
been fixed. The copy node will no longer make connections to its parent while
the database is shutting down or restarting.
================(Build #3639 - Engineering Case #704649)================
In a mirroring system, it is possible for a server to be unable to start
mirroring because its log does not match the one on its parent. Previously,
a message would have been printeded to the console indicating that a log
mismatch had occurred, with no further information. This has been corrected
so that now there is more information printed to the console of its parent
that gives further details.
================(Build #3638 - Engineering Case #704654)================
Creation of SQL Anywhere web services is not permitted on the utility_db.
An HTTP request attempting to access the utility_db may have caused the server
to crash, rather than being rejected with a "404 'Not Found'" status.
This has been fixed.
================(Build #3632 - Engineering Case #704016)================
The server could have crashed if it was serving as a mirror server and became
the primary, and a stored procedure referencing a catalog table was executed
both before and after the transition. There is no known workaround. This
has been fixed.
================(Build #3623 - Engineering Case #703079)================
If there were connections on the mirror database, or a copy node for a mirror
database, that were modifying a temporary table at the same time as the transaction
log was renamed, then the copy node or mirror could have failed in timing
depending cases. In particular, the mirror server or copy node could have
crashed or the transaction log on the mirror server or copy node could have
been corrupted. This has been fixed.
================(Build #3623 - Engineering Case #696467)================
In very rare circumstances, the database server could have consumed 100%
of 1 CPU when shutting down, or when stopping a database. This problem has
now been fixed.
================(Build #3620 - Engineering Case #702931)================
In very race cases, the server would have consumed 100% CPU usage while attempting
to stop a database. For this to have occurred, the database being stopped
needed to make heavy use of scheduled events. This has been fixed.
================(Build #3617 - Engineering Case #672447)================
Under very rare circumstances, frequent transaction log renames may have
left small portions of logs that overlapped. This has been fixed.
================(Build #3616 - Engineering Case #702731)================
In rare, timing dependent cases when using High Availability or Read-Only
Scale Out, it may have been possible for the server to crash, hang, behave
in unexpected ways, or have an incorrect state. This has been fixed.
================(Build #3613 - Engineering Case #698526)================
Windows 7 and Windows 2008R2 support systems with more than 64 logical processors;
however, it does so by partitioning them into "groups" with no
more than 64 processors in each group. Unless an application takes additional
measures to take advantage of multiple processor groups, the application
will execute only within one processor group and be unaware that other processors
are available. Previously, SQL Anywhere would only recognize and utilize
the processors in the group to which it was assigned by the OS at startup,
but now SQL Anywhere recognizes and supports all processors on Windows 7,
Windows 2008R2.
For more information on Windows processor groups, see the following:
http://blogs.msdn.com/b/saponsqlserver/archive/2010/09/28/windows-2008-r2-groups-processors-sockets-cores-threads-numa-nodes-what-is-all-this.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd405503
In addition to supporting more than 64 processors on Windows, SQL Anywhere
now uses the hardware topology as reported by Windows for license enforcement
on all supported versions of Windows except Windows 2003 and Windows XP 64-bit
edition where the operating system is known to misrepresent the actual topology.
Previously, SQL Anywhere relied solely on its own hardware detection on x86
and x64 Windows platforms. By relying on the topology reported by Windows,
SQL Anywhere will have a more consistent view of the topology when running
in a VM.
These processor topology changes include fixes on other platforms too. On
Solaris prior to this change, if the standalone engine was run within a processor
set it would bind itself to a single random processor in the set. Now if
the standalone engine is run within a processor set, it binds to the lowest
numbered processor in the set. Outside of a processor set, the behaviour
has not changed: we bind to the lowest processor that is not bound to any
set.
Also on Solaris, the database server considered processors that were online
but non-interruptible as offline. SQL Anywhere would not bind to such a processor.
This problem has also been fixed.
SQL Anywhere now properly avoids processors that are offline when the server
starts; however, no attempt is made to adapt to processors that are taken
offline or brought online during runtime.
================(Build #3606 - Engineering Case #701170)================
In rare timing dependant cases, dropping the mirror server definition for
an arbiter in a mirroring configuration could have caused the primary server
to hang. This has been fixed.
================(Build #3605 - Engineering Case #687840)================
The initial primary mirror server could have crashed or not correctly processed
requests in rare timing dependent cases after executing the "ALTER DATABASE
SET PARTNER FAILOVER" statement. This problem could have also occurred
when a preferred partner server became available after being disconnected.
This has been fixed.
================(Build #3604 - Engineering Case #701477)================
A SQL Anywhere server may have hang on shutdown with 100 percent CPU usage
if HTTP requests were concurrently in process. This has been fixed.
================(Build #3597 - Engineering Case #700903)================
In a read-only scale-out setup, it was possible for adding a copy node using
"CREATE/ALTER MIRROR SERVER ... USING AUTO PARENT" to fail with
the error "Cannot assign automatic mirror server parent", if there
were no connected servers that had available spaces in its fan-out. For example,
if the root server had ten children and had a fan out of ten, all of which
were disconnected, adding another server would fail. This has been fixed.
Under these circumstances, the new server will be added as a child of the
auto add server.
Auto-parenting uses sa_mirror_server_status() to determine what servers
are connected. In a read-only scale-out setup, it was possible for sa_mirror_server_status()
to report a copy node as connected when it was actually shut down. This would
have happened when the copy node and its parent were shut down in quick succession.
This has been fixed. Now, the copy node will appear as connected for up to
two minutes, at which point the server will be marked as disconnected.
================(Build #3597 - Engineering Case #700882)================
If a high availability mirror, or read-only scale-out copy node, needed to
restart its database, it could in rare timing dependent cases caused the
server to crash. This has been fixed.
================(Build #3596 - Engineering Case #700309)================
If there was an apostrophe in a user name or table name, a verbose unload
(dbunload -v or an unload in Sybase Central) would have failed, and would
have reported a syntax error similar to the following:
***** SQL error: Syntax error near 'xxx' on line 1
Also, during reload, extra apostrophes would be displayed in progress messages
containing table, index, view, procedure or trigger names. This problem has
been fixed.
================(Build #3595 - Engineering Case #700426)================
If files were opened concurrently by two threads of the same process on Windows
Mobile / Windows CE devices, the two threads could have been assigned the
same POSIX file handle number and IO could then have been directed to the
wrong file. This problem, given the nature of Windows Mobile devices, was
very unlikely to occur and has been fixed.
Also, a structure used to query the OS version on Windows Mobile / Windows
CE devices was not initialized correctly; however, it is not believed ever
to have caused a problem. This problem has also been fixed.
================(Build #3592 - Engineering Case #700287)================
A security issue with Remote Data Access has been fixed.
================(Build #3592 - Engineering Case #695788)================
In rare, timing dependent cases, the server may have failed fatal assertion
101412 - "Page number on page does not match page requested". This
has now been fixed.
================(Build #3591 - Engineering Case #699667)================
If an application made a Java external environment call that returned a SQLException
on a JDBC statement, then the next call to the Java external environment
would have returned with a NullPointerException if there are no other Java
calls in between. This has been fixed.
================(Build #3591 - Engineering Case #693917)================
If a copy node in a mirroring setup became unresponsive, it was possible
for its parent to hang. This has been fixed.
================(Build #3589 - Engineering Case #700008)================
Under rare circumstances, the server may have failed assertion 101413 - "Unable
to allocate a multi-page block of memory". This was more likely when
many (~5 or more) databases were running within a server, and when the server
was running with a small cache (less than 100M per database); and was more
likely to be seen when starting a new database after the server has been
running for some time. This has been fixed. A workaround is to start the
server with several extra databases, and then stop them as soon as the server
is started.
================(Build #3589 - Engineering Case #689696)================
In exceptionally rare circumstances, the server may have failed with assertion
errors 200130, 200131, 200106, 108701, or others, on index pages. The problem
was seen on multi-core machines under very high index contention, that included
index updates and deletes. This has been fixed.
================(Build #3584 - Engineering Case #699703)================
In a mirroring setup, it may have been possible for the sa_mirror_server_status()
system procedure to report that the primary server had a higher log offset
than the mirror or copy nodes, and it could have remained this way until
the server received further transactions. This has been fixed. The log offset
reported for the primary server will now report the offset that has been
pushed to any mirrored servers.
Note that this was not a problem with the mechanism that pushes log pages
to copy nodes and mirror, but with the way the offset was reported.
================(Build #3584 - Engineering Case #697188)================
When starting the database server, an error is reported (by displaying the
usage text) if a non-numeric parameter is passed where a numeric parameter
is expected. For example:
dbeng12 -n jcs -c nonsense
However, if the argument to -c started with the a character associated with
memory units (k, m, g), no usage text was displayed. For example:
dbeng12 -n jcs -c garbage
dbeng12 -n jcs -c magic
dbeng12 -n jcs -c k
This has been corrected so that the usage text is now displayed.
================(Build #3583 - Engineering Case #699537)================
If several Open Client or jConnect applications attempted to connect to a
server using the extended encrypted password protocol, then there was a very
small chance the server would crash if all of the extended encrypted password
connection requests were made at the same time. This problem has now been
fixed.
================(Build #3582 - Engineering Case #699387)================
If a server, or one of the SA client utilities, attempted to launch a secondary
application (like an external environment), then the secondary application
may have failed to start properly when the command line for the secondary
application contained characters that were not 7-bit ASCII. This problem
has now been fixed.
================(Build #3582 - Engineering Case #699214)================
In a mirroring setup of servers running on multiple host machines, it was
possible for the system procdure sa_mirror_server_status() to return incorrect
information if the hosts did not have the exact same time. In particular,
it was possible for it to appear that some servers were not receiving log
pages, even if they were up to date. This has been fixed. The "last_updated"
column in the table will always report the time relative to the server named
in the "server_name" column.
================(Build #3579 - Engineering Case #699022)================
If a server was started with the "remote_data_access" secure feature
turned on (see -sf command line option), and an application attempted to
use the secure feature and subsequently received an error indicating that
Remote Data Access was disabled, then any subsequent remote calls would incorrectly
have returned a 'cursor already open' error. This problem has now been fixed.
================(Build #3578 - Engineering Case #693111)================
On Windows Mobile / CE, database files were not always properly flushed when
necessary. The file metadata was the most likely data not to have been flushed,
and assertion failure 201129 (File shorter than expected) was the most likely
corruption to be seen in the event of a full power outage (eg if the CE device
battery runs out). This problem has been fixed.
Also, the server's '-u' (use buffered IO) command line switch was ignored
on Unix platforms that supported direct IO. This problem has also been fixed.
================(Build #3577 - Engineering Case #697936)================
A statement could have failed with an error (Assertion 106104 failed) if
the statement contained an aggregate function AGG( agg_arg ) where:
- agg_arg was a complex expression
- a complex sub-expression of the agg_arg was used in the WHERE (or in
an ON condition)
- the optimizer selected an execution strategy involving "distinct-by-rowids"
(for example, there was an EXISTS subquery)
This problem has been fixed.
For example, the following query could have caused the SELECT statement
to fail with the assertion failure error:
create table T_DBR_1( x int );
create table T_DBR_2( x int );
insert into T_DBR_1 select row_num from sa_rowgenerator(1,10);
insert into T_DBR_2 select row_num from sa_rowgenerator(1,100);
commit;
select count(*), sum( complex_expr1+2 )
from (
select case R1.x*10 when 11 then R1.x end case complex_expr1
, 99+R2.x as complex_expr2
from T_DBR_1 R1 left join T_DBR_2 R2 on R1.x = R2.x
where exists ( select * from dbo.rowgenerator R3 where R3.row_num+1 = R1.x
)
) D
where complex_expr1 <> 12
or complex_expr2+2 <> 11
================(Build #3575 - Engineering Case #698386)================
The Server could have hung in very rare cases if a connection made a Remote
Data Access request that required a remote connection to be established.
This problem has now been fixed.
================(Build #3575 - Engineering Case #696638)================
Using an ALTER TABLE statement to change the length of a string column (char,
[long] varchar, [long] binary) that used default INLINE/PREFIX values, would
also have explicitly set the INLINE/PREFIX values for that column if there
was data in the table. This has been fixed.
================(Build #3574 - Engineering Case #698236)================
The drive_model property could have returned a random string of characters
if the OS did not make the corresponding property available. This has now
been corrected.
================(Build #3574 - Engineering Case #698219)================
In very rare timing dependent cases, a copy node could have failed to connect
to its alternate parent or the root if its parent was unavailable. Additionally,
in order for this to have occurred, the copy node's connection to its parent
would have had to disconnect for some reason shortly after it connected.
This has been fixed.
================(Build #3574 - Engineering Case #698201)================
The Server could have been unresponsive for a long period of time when a
backup was starting. This has now been corrected.
================(Build #3568 - Engineering Case #697593)================
If a row was inserted while a REORGANIZE TABLE process was running, and the
inserted row's primary key was greater than the highest primary key at the
time the REORGANIZE started, the server could have possibly entered into
an infinite loop and consumed 100% of 1 CPU without terminating. The operation
could, however, be cancelled. This problem has been fixed.
================(Build #3567 - Engineering Case #697440)================
The server may have hung on shutdown if an HTTP client procedure was still
active. This has been fixed.
================(Build #3567 - Engineering Case #697439)================
On rare occasions a time-out of a SQL Anywhere web client procedure may have
caused the server to crash. This has been fixed.
================(Build #3566 - Engineering Case #697349)================
The SQL Anywhere HTTP server may have crashed due to rare error condition.
This has been fixed.
================(Build #3566 - Engineering Case #697235)================
The changes for Engineering case 695216 introduced problems with certificate
files (for example, supplying an ECC certificate when an RSA certificate
was expected) which would have yielded the error message "An identity
password must be specified", even if a password was specified. This
has been fixed. In this example, the correct error message is now "An
ECC certificate was supplied where an RSA certificate was expected.".
================(Build #3564 - Engineering Case #685156)================
The server may have crashed if a procedure debugger connection disconnected
before a debuggee connection was able to get attached to the debugger. This
has been fixed.
================(Build #3559 - Engineering Case #696816)================
Transaction log corruption could have occurred at the mirror or copy nodes
of a high availability or read-only scale-out system if the following sequence
of events took place:
1) The transaction log was renamed (and a new one started) at the end of
a backup of the primary
2) The mirror or copy node caught up and applies some operations from new
transaction log
3) The mirror or copy node lost connection with its partner or parent
4) The mirror or copy node reestablished connection with its partner or
parent
Note that if the mirror or copy node restarted prior to reconnecting, corruption
would not have occurred. If corruption did occur, an 'invalid transaction
log' assertion failure on the mirror or copy node was the most likely outcome.
This problem has been fixed.
Also, if a copy node (call it CN) has a parent that was not the primary
(call it NP), it was possible for CN to stop applying transactions altogether.
CN would have remained running as a read-only node but it would not have
applied transactions until the database was manually restarted. For CN to
enter this state, the following sequence of events must have occurred:
1) CN and NP become disconnected or CN just wasn't running yet
2) NP renamed the transaction log and started a new one (which happens
as a result of copying actions performed at the primary)
3) CN and NP reconnect (or CN was started)
In this case, CN will now display a "Recovery complete" message
in the console log.
================(Build #3556 - Engineering Case #696394)================
Execution of a procedure with a very large argument list may have crashed
the server. The crash would have occurred if statement needed to be copied
(e.g. a remote server statement or a SELECT INTO statement), and a server
worker thread ran out of stack. This has been fixed.
================(Build #3551 - Engineering Case #695095)================
When executing a REORGANIZE TABLE statement, the server could have unnecessarily
allocated an amount of memory that was proportional to the number of rows
in the table. These allocations could have affect performance, and could
have caused the cache to grow or, if the cache grew to its limit, could have
caused a 'dynamic memory exhausted' failure. This problem has been fixed.
================(Build #3549 - Engineering Case #695774)================
Attempting to execute a grouped query with a complex ORDER BY expression
could have failed with the error: "Assertion failed: 106105 Unexpected
expression type ..". This would have occurred if the complex ORDER BY
expression referenced a base table column from the GROUP BY clause - such
as "T.X +1", where T.X is a base table column in the GROUP BY
clause; and the base table column T.X was eliminated from the GROUP BY clause
based on functional dependencies. This has now been corrected.
================(Build #3549 - Engineering Case #695242)================
On some systems with multiple physical processor packages (ie multiple sockets)
using certain Intel x86/x64 processors, including Intel Xeon E5630, the detection
of processor geometry could have been incorrect. Too few packages would have
been detected but the correct number of logical processors would still have
been detected (with some assigned to the incorrect package). This problem
was similar to, but different from, Engineer case 666639, and has now been
fixed.
================(Build #3549 - Engineering Case #695082)================
Execution of a query with a query block with a FROM clause that was empty,
or contained only the DUMMY table, could have crashed the server if the WHERE
clause of this query block contained an EXISTS() predicate which could have
been flattened. This has been fixed.
================(Build #3548 - Engineering Case #695909)================
Attempting to upgrade a version 10.x database using a version 11.0.0 or later
server would likely have failed with the error: "Item 'SYSCAPABILITYNAME'
already exists" error. This problem has now been fixed.
================(Build #3547 - Engineering Case #695762)================
The ALTER SERVER server CONNECTION CLOSE statement was a DDL statement that
could not be executed in a read-only database. This has been fixed so that
the statement is now executable in a read-only database, and no longer does
an automatic commit.
================(Build #3547 - Engineering Case #695495)================
When connected to an older 10.x database, creating a remote server and then
attempting to utilize the remote server would likely have caused an incorrectly
foreign key violation error. This problem has now been fixed.
================(Build #3547 - Engineering Case #694933)================
Execution of a statement could have crashed the server, or returned incorrect
results, if the statement contained derived tables with INSERT, DELETE, UPDATE,
MERGE query blocks, and either the updated object was a simple updatable
view, or the statement was used inside stored procedures, function, triggers,
views, or batch statement. This has been fixed.
================(Build #3546 - Engineering Case #695633)================
Physical plan operators, such as base table sequential scans and joins, could
not have be parallelized if an IN filter predicate belonged to that operator.
This potentially could have caused performance degradation from earlier version
where such operators could have been parallelized. This problem did not prevent
the rest of the plan from being parallelized. For example, for a query with
four tables and an IN predicate referencing only one of the tables, only
the table referenced in the IN predicate could not have been parallelized,
while the two joins joining the rest of the three tables could have been
parallel joins. This has been fixed.
================(Build #3541 - Engineering Case #695216)================
If the server was started with a TLS/HTTPS identity file that required a
password, but none was supplied, an unhelpful error message was given ("Error
parsing certificate file, error code 20763"). This has been fixed; the
error message is now "An identity password must
be specified".
================(Build #3541 - Engineering Case #695213)================
When running on Windows systems, the server would have returned the value
of property('MachineName') truncated to 15 characters. This has been fixed
so it will now return the full name.
================(Build #3540 - Engineering Case #695084)================
Execution of a CREATE PROCEDURE statement with a number a parameters that
exceeded the limit would not have failed. Now, execution of such a statement
will fail with the error: SYNTACTIC_LIMIT 54W01 -890.
Note, the maximum number of parameters allowed is a function of the database
page size. For example, for a page size of 4k, the limit is ~3620096 parameters.
================(Build #3539 - Engineering Case #694479)================
Attempting to use a server or the Java-based administration tools with large
amounts of memory on a Linux system with kernel versions between 3.0 and
3.3 may have resulted in improper system memory calculation. This problem
could have manifest itself in many ways. The server may have reported insufficient
memory, or may have reported a very low value for its cache size, even when
a large amount of system memory is available, e.g.:
8192K of memory used for caching
Minimum cache size: 8192K, maximum cache size: 8192K
The Java-based administration tools may also report the following error:
Invalid maximum heap size: -Xmx0m
This has been fixed.
================(Build #3537 - Engineering Case #694594)================
In some cases, statements that included a DML statement in the FROM clause
could have missed some checking that is normally done on statements. This
has been fixed.
================(Build #3537 - Engineering Case #694593)================
When evaluating the DATENAME() builtin function, it was possible that the
server could have crashed. This potential problem has not been observed,
and it is now fixed.
================(Build #3537 - Engineering Case #694592)================
Evaluating particular forms of expressions in procedural code could have
caused a server crash. This has been fixed.
================(Build #3537 - Engineering Case #694591)================
When the search condition in an IF expression evaluates to UNKNOWN, the IF
expression should return NULL (not the "else" branch). For example,
the following statement returns (NULL,NULL)
select a
, if a=1 then 1 else 0 end if as b
from openstring(value ',')
with( a int ) D
If an IF expression was used as an argument to a CASE expression where the
predicate is known at open time, then the IF expression was incorrectly evaluated
so that UNKNOWN was treated as FALSE, leading to the ELSE branch being returned
instead of NULL. For example, the following statement incorrectly returned
(NULL,0,0) instead of (NULL,NULL,NULL)
select a
, if a=1 then 1 else 0 end if as b
, case when 1=1 then b end case c
from openstring(value ',')
with( a int ) D
A similar problem could occur with an IF expression used as an argument
to NULLIF.
This problem has been corrected.
================(Build #3537 - Engineering Case #666132)================
In some cases, expressions could have been evaluated with incorrect domain
information. The affected information included:
- precision and scale for NUMERIC values
- length for string values
- differences between string types (e.g., char/varchar/long varchar or
binary/varbinary/long binary)
For example, the following statement would have incorrectly returned:
a a_string
1.0000 "1.0000"
select case when dummy_col=0 then 1 else cast(2 as numeric(10,4) ) end case
a
, cast( a as varchar ) a_string
from sys.dummy
However, the following statement would have incorrectly returned:
a a_string
1 "1"
select case when 0=0 then 1 else cast(2 as numeric(10,4) ) end case a
, cast( a as varchar ) a_string
from sys.dummy
The incorrect behaviour affected expressions that were partly or fully evaluated
at query open time or in procedural code, and affected IF, CASE, NULLIF,
ARGN, COALESCE and some other related expression types. This problem has
now been fixed.
================(Build #3536 - Engineering Case #694143)================
When using the CREATE ENCRYPTED TABLE DATABASE statement on a fully encrypted
database, the resulting database had all table and index pages encrypted,
rather than only the pages for
encrypted system tables. This has been fixed.
================(Build #3535 - Engineering Case #694491)================
If the server's main heap was extremely large and fragmented, and/or an extremely
large number of SQL objects had been referenced (ie a large number of table
names, column names, etc), checkpoints could have been slower than necessary
by using more CPU than necessary. Even in extreme cases, the delay might
have been only a few seconds and might generally go unnoticed for normal
checkpoints; however, execution of a long sequence of DDL statements that
performed implicit checkpoints would have been observed as extremely slow.
The problem was caused by some in-memory cleanup that must be performed by
the server periodically and was performed on every checkpoint; however, this
cleanup doesn't need to be performed when checkpoints are executed in quick
succession. Now, SQL Anywhere will perform the cleanup during checkpoint
at most once every twenty minutes.
================(Build #3534 - Engineering Case #694137)================
There were two problems with attempting to encrypt a table using the ALTER
TABLE <table_name> ENCRYPTED statement:
1. Executing the ALTER TABLE statement incorrectly succeeded on a database
that did not support encrypted tables (i.e. one that is not encrypted or
fully encrypted).
2. If a database was created with version 10 to support encrypted databases,
but was being executed on a version 11 or later server, the same ALTER TABLE
statement would have fail with error -1047 "This database does not support
encrypted tables".
These problems have now been fixed. In the first case, the ALTER statement
will now
return error -1047, and in the second case, the ALTER statement will succeed.
================(Build #3534 - Engineering Case #692307)================
In blank padded and case insensitive databases using INSERT ON EXISTING UPDATE
when updating a value which was logically equivalent but physically different
could have failed due to constrain violations. This has been fixed. The server
now does constraint checking using logical representations.
================(Build #3533 - Engineering Case #694002)================
In extremely rare timing dependent cases, the server could have hung when
the db_property function was called. The only known case of this occurring
involved mirror servers, but this problem may have affected servers not involved
in mirroring. This has now been fixed.
================(Build #3533 - Engineering Case #693938)================
In very rare circumstances, the server could have become deadlocked or hung.
In some cases , database mirroring would have been involved and very specific
timing was required; however, the problem could have occurred in other situations
and would also have required very specific timing. This problem has now been
fixed.
================(Build #3532 - Engineering Case #693819)================
When the server was running with the -fips command line option (Requires
that only FIPS-approved algorithms should be used for strong database and
communication encryption), it was still able to start simple-encrypted databases.
This has been fixed, such databases will now fail to start.
================(Build #3531 - Engineering Case #693670)================
When a copy node server in a mirroring setup was not running an arbiter or
partner server for another database, any connections from a server running
mirroring to the copy node would have consistently dropped and reconnected
for no apparent reason. This has been fixed.
================(Build #3530 - Engineering Case #691879)================
If an IPv6 address was used in the HOST or LINKS parameters of a connection
string, on a machine that did not support IPv6, the client would have displayed
the message "No IP address found for <IPv6 address>". This
has been fixed. The error message will now read "No valid host names
or addresses given". If the LOG= parameter is also used, the message
"Ignoring IPv6 address <IPv6 address>" is written to the
log for each IPv6 address found.
================(Build #3528 - Engineering Case #693418)================
A partner mirror server could have hung when stopping the mirrored database
in rare timing dependent cases after executing an ALTER MIRROR SERVER for
the arbiter server. This problem was introduced by the changes made for Engineering
case 688291 and has now been fixed.
================(Build #3528 - Engineering Case #687999)================
In rare timing dependent cases, a transaction which was successfully committed
on a primary server could have been lost. In order for there to have been
a chance of this occurring, all of the following needed to be true:
- the application was connected to a primary server that lost quorum (the
server lost the connection to both the mirror and arbiter servers)
- the application stayed connected to this server (the old primary server)
even though the network connection to other servers dropped
- the application was in the middle of committing a transaction between
the time that the old primary server lost its connection to the mirror and
arbiter server, and when the old primary server restarted as the new mirror
server because it lost quorum
- the old mirror server took over as the new primary (the mirror server
must have been able to connect to the arbiter server for this to occur)
This problem has now been fixed.
================(Build #3527 - Engineering Case #690768)================
In order to prevent the possibility of having two primary servers running
at the same time when there was no connection between the two partners, the
arbiter would have refused a role switch from "mirror" to "primary"
if it had a connection to the current primary. If a mirroring partner server
was unable to connect to its partner server after the connection dropped,
it was possible for the server to be unable to decide whether to take the
role of primary or mirror server. A work around for this problem was to use
the syntax "ALTER DATABASE <mymirroreddb> FORCE START" to
force the database to start up as primary, and should only have been used
if there was no other primary server running. This problem has been fixed,
and the server should now be able to decide to take a role of either "primary"
or "mirror" server.
================(Build #3526 - Engineering Case #693135)================
On Mac OS X, servers or client applications that made many TCP/IP connections
requiring broadcasts to other servers could have sent many more UDP broadcast
packets than required. In extreme cases, this could have flooded the network
with UDP packets, affected an entire subnet's performance. Connection strings
such as links=tcpip (with no broadcast=) or host=hostname (with no port)
use broadcasting to other servers and could have had this problem. This has
been fixed.
================(Build #3524 - Engineering Case #692899)================
The changes for Engineering case 691204 introduced a problem where, in rare
timing dependent cases, a high availability server or a copy node server
could have crashed when shutting down, or when a DROP MIRROR SERVER statement
was executed for a connected copy node.
================(Build #3524 - Engineering Case #692867)================
The changes for Engineering case 677962 introduced a situation where, in
rare timing dependent cases, a server could have hung when it was shutting
down a database which was a high availability mirror or a copy node. This
has been fixed.
================(Build #3524 - Engineering Case #692583)================
In some rare cases, the server would have hung when a connection queried
another
connection's LastStatement property. This has been fixed.
The work-around is to not use the -zl command line option, or to turn off
the
RememberLastStatement server option.
================(Build #3522 - Engineering Case #692617)================
When the dbisqlc OUTPUT_FORMAT option 'ASCII' was renamed to 'TEXT' in version
11.0.0, the ability to generate the old format that dbisqlc called 'TEXT',
which was fixed-width with column headers, was lost. Now, setting the OUTPUT_FORMAT
to 'COLUMNS' will generate the old TEXT format.
================(Build #3519 - Engineering Case #692216)================
A problem with TDS secure logins has been corrected.
================(Build #3518 - Engineering Case #690075)================
Events run on temporary connections, but those connections did not always
have the correct locale information. In particular, functions such as errormsg()
would have returned strings encoded in the OS character set rather than in
the database character set. This problem has been fixed.
================(Build #3517 - Engineering Case #692013)================
If a copy node in a read-only scale out setup was converted to be a partner
mirror server, the primary mirror server could not have been restarted. This
has been fixed.
================(Build #3516 - Engineering Case #691662)================
DELETE query blocks (e.g. a main query block in a DELETE statement or a query
block of a DML DELETE derived table) were restricted from flattening subqueries
defined in the WHERE clause. An exception was that subquery flattening was
done if and only if the cardinality of the DELETE query block was not affected.
The restriction has now been removed, which may significantly improve the
performance of some DELETE statments. With this change, any subquery which
qualifies for flattening is flattened similar with SELECT/UPDATE query blocks.
================(Build #3515 - Engineering Case #690133)================
When connected via jConnect or Open Client, retrieving the metadata of a
long nvarchar or ntext column may have incorrectly indicated that the column
was a long binary value. This problem has now been fixed.
================(Build #3513 - Engineering Case #665176)================
The NEXTVAL operation on sequences did not return an error when executed
in a read-only database. This has been corrected. The operation should return
an error because the sequence value cannot be updated in the catalog table.
================(Build #3512 - Engineering Case #691322)================
The ENCRYPTED KEY option of the OPENSTRING statement was recently extended
to permit the encryption key to be specified as a variable (see Engineering
case 688888). In certain scenarios this feature could have caused either
a crash, or an inappropriate error - SQLCODE -851 "Decryption error:
Missing encryption key". This has been fixed.
================(Build #3512 - Engineering Case #691204)================
In a high availability mirroring configuration, it is possible to drop the
mirror server definition for a partner server currently acting as a mirror.
If the dropped server later tried to connect to the primary server as a copy
node, the primary server would still have thought the server was its partner,
rather than a copy node. This has been fixed.
Also, in a read-only scale out mirroring configuration, it is possible to
drop the mirror server definition for a copy node. If that copy node was
connected to the primary server at the time of the drop, the mirror server
definition would not have been removed from the system tables. This to has
been fixed.
================(Build #3509 - Engineering Case #691304)================
The changes for Engineering case 686407 introduced a problem for shared memory
connections where calling connection_property( 'LastReqTime' ) could have
reported an inaccurate value. This has been fixed.
================(Build #3508 - Engineering Case #691178)================
Attempting to make a Kerberos connection with a large Kerberos ticket could
have failed with the error "Kerberos login failed". This would
have occurred with a Kerberos ticket size approaching 8K, which was possible
if the ticket was part of a large number of Active Directory groups. This
has been fixed.
================(Build #3507 - Engineering Case #686428)================
In a mirroring system, it was possible for multiple servers to deadlock,
waiting for responses from each other. This has been fixed.
================(Build #3507 - Engineering Case #681739)================
In extremely rare situations, the primary server in a mirroring system could
have become deadlocked while attempting to send log pages to the mirror partner.
For the problem to have occurred, all request tasks on the primary server
must have been blocked and the connection from the primary to the mirror
must have been severed while the log pages were being sent to the mirror.
This problem has been fixed.
================(Build #3506 - Engineering Case #691036)================
When using the -sf server option to disable certain features other than "database",
the CREATE DATABASE statement could have failed. This has been fixed.
================(Build #3504 - Engineering Case #690734)================
The MIN and MAX aggregate functions would have returned an error when using
an argument of type "timestamp with time zone" or "xml":
Cannot convert timestamp with time zone to a numeric
or
Cannot convert xml to a numeric
Further, using an "numeric" before computing the aggregate. This
has been fixed. The MIN and MAX aggregates no longer attempt to cast these
types to "numeric".
================(Build #3500 - Engineering Case #690373)================
Statements with virtual tables referencing user-defined functions, and stored
procedures which qualify for in-lining, may crashed the server or returned
incorrect results. This has been fixed.
================(Build #3500 - Engineering Case #690254)================
When request logging is enabled with ALL or PLAN, the server may have crashed
if the following sequence occurred:
- Connection A opened a cursor that included fetching rows from a procedure
- Connection B dropped the procedure used by connection A
- Connection A then closed its cursor
This problem has been fixed.
================(Build #3497 - Engineering Case #690114)================
Recovery could have failed if an operation in the transaction log required
access to a feature that was secured on the command line via the -sf option.
The operation could have entered the log, either by having the operation
performed on a server where the feature was not secured, or if security was
permitted, on the given connection via the -sk server option and setting
the secure_feature_key option to match. The failure would have been displayed
as assertion number 100904 "Failed to redo a database operation".
This has now been fixed.
Note, not all secured features add entries to the transaction log. For example,
the READ_FILE secured feature blocks access to xp_read_file which would not
get logged; however, the REMOTE_DATA_ACCESS secured feature blocks access
to statements such as CREATE SERVER does get logged.
================(Build #3496 - Engineering Case #689614)================
In rare cases in a mirroring system, where a mirror server lagged far behind
the primary in applying changes, it was possible for the primary and mirror
server to hang. This has been fixed.
================(Build #3494 - Engineering Case #689464)================
The Property() function would have displayed negative values for the server
properties 'HttpPorts' and 'HttpsPorts' when the port numbers were above
32768. This has been fixed.
================(Build #3494 - Engineering Case #689193)================
The changes for Engineering case 682512 introduced a problem where stopping
a high availability primary server while it was connected to its partner
(mirror) server could have resulted in the database not being able to start.
Specifically, in timing dependent cases, attempting to restart the primary
mirror server could fail with the "Database cannot be started -- <database
name> not expecting any operations in transaction log". This has
been fixed.
================(Build #3493 - Engineering Case #689657)================
Three new properties have been added:
LastCommitRedoPos: This property is available at both the connection-level
and the database-level. The value returned is the redo log position after
the last COMMIT operation was written to the transaction log by the connection
or database.
LastWrittenRedoPos: This is a database-level property only. The value returned
is the last redo position for which a write was issued to disk. The write
is not necessarily synced to the physical medium as it may still be cached
by the OS, disk controller or disk drive.
LastSyncedRedoPos: This is a database-level property only. The value returned
is the last redo position for which a write was issued to disk and the data
was synched to the physical medium. Data prior to this position is expected
to be present on disk even in the event of a power failure.
================(Build #3493 - Engineering Case #689511)================
In some extremely rare cases, the transaction log may not have been committed
to disk when a COMMIT operation was performed.
Also, if a transaction only modified temporary tables, it was possible that
the transaction log would have been committed to disk although it didn't
need to be.
These problems have been fixed.
================(Build #3492 - Engineering Case #689315)================
When connected via jConnect or Open Client to a blank padded UTF8 database
and a non-nullable char(n) value was fetchesd, the client may have experienced
protocol errors if n was less than 3. This problem was introduced by the
fix for Engineering case 686183 and has now been fixed.
================(Build #3489 - Engineering Case #687749)================
A query using aggregate functions may have caused a server crash if its select
list contained a derived table with an outer reference to the query, and
the outer reference did not appear in the queries group by list. At least
one of the following conditions must also have been trun:
1) The derived table contained a procedure call in its FROM clause and the
procedure argument expression contained the outer reference.
2) The derived table contained a OPENSTRING clause in its FROM clause and
its value expression contained the outer reference.
3) The derived table contained another derived table and the outer reference
was inside this other derived table.
The below query shows an example of condition 3).
select ( select V0.e from (
select T3.e from T3 where T3.e = T2.c ) V0
) c1,
max(T1.b) as c2
from T1 join T2 on T1.a = T2.c
This problem has been fixed. The engine will now correctly return the error
SQLE_INVALID_GROUP_SELECT, since the outer reference column has to be specified
in the GROUP BY clause. Specifying the outer reference column in the GROUP
BY clause (in the above example: group by T2.c) is also the work around to
this problem.
================(Build #3488 - Engineering Case #688788)================
In rare timing dependent cases, if a mirror server was using all available
workers, it was possible for the server to hang, or for a mirror database
to not restart after loss of quorum. The maximum number of workers is defined
by -gnh (in version 12) or by -gn (in version 11). This has been fixed.
================(Build #3488 - Engineering Case #688581)================
In a read-only scale-out system, if the non-primary server (say S) in the
read-only scale-out tree had more than ten direct or indirect children, then
S's parent could have hung, in rare timing dependent cases. This problem
was introduced by changes made for Engineering case 681813, and has now been
fixed.
================(Build #3488 - Engineering Case #686791)================
In a mirroring system, if the primary server made changes faster than the
mirror server could apply them, and if the connection between the two servers
was dropped, in rare timing dependent cases, the mirror server could have
hung with 1 CPU at 100%. Stopping the server or the database during the
100% CPU hang would have succeeded. This has now been fixed.
================(Build #3487 - Engineering Case #686407)================
In rare cases where a primary server lost its connections to both the mirror
and the arbiter servers as a checkpoint was performed, the next time the
primary and mirror servers were connected and attempted to synchronize, the
mirror server may have reported the error: 'Database "<name>"
mirroring: database is not compatible with primary; files must be replaced'
and then stop with the message: 'Database server shutdown due to incompatible
files for database mirroring'. This has been fixed so as to reduce the possibility
of this occurring. In rare cases this could still occur and the database
running on the current primary must be manually copied or backed up to the
mirror server so that the server can successfully synchronize again.
Note, this extends the changes made by Engineering case 660851.
================(Build #3484 - Engineering Case #688435)================
An IS [NOT] DISTINCT FROM predicate may have been incorrectly evaluated for
some data types, such as string datatypes. The incorrect evaluation would
have been observed if the predicate was not used in a Hash Join, Merge Join,
or as a sargable predicate for a partial index scan. This has been fixed.
================(Build #3483 - Engineering Case #687393)================
Under very rare circumstances, a server could have crashed during backup
if many connections are committing transactions at the same time. Live backups
were the most likely to suffer from this problem. This has been fixed. No
workaround is known.
================(Build #3483 - Engineering Case #685566)================
When a mirror or diagnostics connection to another server was attempted the
"Using broadcast address of: ..." message was logged to the console
when it should not have been. This has been fixed so that this message is
only logged if the -z server option is used.
================(Build #3482 - Engineering Case #688019)================
When connected to the utility database (utility_db), if a statement that
was not supported was prepared, the PREPARE may not have generated an error
when it should have. This has been fixed so that the unsupported prepare
now returns the error "Permission denied: you do not have permission
to execute a statement of this type."
================(Build #3482 - Engineering Case #687998)================
While extremely rare, the server may have crashed while executing a query
that referenced proxy tables. The problem has now been fixed.
================(Build #3481 - Engineering Case #687973)================
Calling the system procedures sp_remote_tables or sp_remote_columns for an
ASE or MS SQL Server remote server would have failed if the catalog argument
was specified as NULL. This problem was introduced in 12.0.1 GA and has now
been fixed.
================(Build #3480 - Engineering Case #686575)================
Very complex disjuncts in the WHERE clause were not able to be used for index
scans. Now, IN predicates are generated if at all possible. These new IN
predicates can then be used to drive an index scan improving the execution
times for this type of query.
================(Build #3479 - Engineering Case #687773)================
In extremely rare cases, the server could have crashed when request level
logging was enabled. The problem has now been corrected.
================(Build #3479 - Engineering Case #687747)================
If the server was shutdown while a mirrored database was in the process of
starting on the server, the server could have crashed. This has been fixed.
================(Build #3479 - Engineering Case #686822)================
If an ALTER PUBLICATION or a DROP PUBLICATION command was executed by the
MobiLink client inside the sp_hook_dbmlsync_schema_upgrade hook, it was possible
for the command to have thrown an 100904 assertion ("Failed to redo
a database operation ...") if the database server had to replay the
operation during recovery. This has now been fixed.
================(Build #3479 - Engineering Case #665966)================
A query whose execution used a parallel HashGroupBy operator, may have returned
an incorrect result if the MIN or MAX aggregate function was used, or may
have caused the server to crash if an aggregate function was used on a numeric
or string expression. This has been fixed. A workaround for the problem is
to set the database option max_query_tasks to 1.
================(Build #3478 - Engineering Case #687761)================
The dbisqlc utility would have reported a syntax error whenever it tried
to execute a 'STOP SERVER' statement. This problem has been fixed. The statement
used to be 'STOP ENGINE ...' and dbisqlc did support (and continues to support)
that variant; however, it was never updated when the statement was changed
to 'STOP SERVER'.
================(Build #3478 - Engineering Case #687596)================
When shutting down a server that was running as a Windows service, the server
could have crashed. Although the problem was only seen when shutting down
an interactive service on Windows XP by using the 'Shutdown' button on the
server window, the problem was a timing issue and could have occurred when
the server was shut down in other ways. The problem has been corrected.
================(Build #3477 - Engineering Case #687447)================
In rare, timing dependent cases the server could have had incorrect behaviour
when a connection had at least 20 prepared statements with cached prepared
statements, or at least 20 cursors open. The incorrect behaviour could have
varied, and the only known symptom was incorrectly returning the error "Resource
governor for 'prepared statements' exceeded", but it may also have been
possible for server crashes or assertions to have occurred. This has now
been fixed.
================(Build #3477 - Engineering Case #687411)================
When an ALTER DATABASE UPGRADE statement is executed, events are suspended
in order to avoid having active connections while upgrading. Once upgrading
is done, events are re-enabled. Running simultaneous ALTER DATABASE UPGRADE
statements could have left events permanently suspended on the server. No
events on any database would have been executed. This problem has been fixed.
Also, when upgrading a single database, the server suspended events for all
databases that were running. This was unnecessary and the server now only
suspend events in the database that is being upgraded.
================(Build #3476 - Engineering Case #687264)================
The server's http log did not display the query component of the request
URI. This has been fixed.
================(Build #3476 - Engineering Case #686202)================
For recurring scheduled events, there were several errors in how end times
were computed:
1. If an end-time was specified (i.e., "BETWEEN start-time AND end-time"),
then:
a. Seconds were being ignored. For example, an end-time of '23:59:59'
was being interpreted as '23:59:00'.
b. The end-time was tested as an exclusive endpoint rather than an inclusive
endpoint, contrary to the documentation of the BETWEEN ... AND clause. For
example, the schedule "BETWEEN '9:00' AND '17:00' EVERY 60 MINUTES"
would cause the event to fire last at 16:00, rather than 17:00.
2. If an end-time was not specified (i.e., "START TIME start-time"),
the end-time for each day was implicitly being treated as '23:59:00' exclusive,
instead of '23:59:59' inclusive.
The combined effect of these error were that no scheduled events would fire
in the minute from 23:59:00 until midnight. This has been fixed.
================(Build #3476 - Engineering Case #685149)================
When execution of a stored procedure or user defined function was cancelled
by the user
and an error handler within the stored procedure was invoked, an incorrect
SQLCODE (0 or
the error code of a different error that occurred prior to the cancel) could
have been reported. An incorrect error message could also have been reported
by the ERRORMSG() function. This has been fixed.
================(Build #3475 - Engineering Case #681759)================
The database property 'PartnerState', as returned by db_property, would have
returned inaccurate results for databases that had no mirroring definitions,
but were running with mirroring enabled. This has been fixed. Now, db_property('PartnerState')
will return "null" if no partner has been defined.
================(Build #3472 - Engineering Case #686790)================
When the server was starting a database, statistics collection may be performed
on the database tables even though the statistics are not updated. This has
been corrected so that statistics collection is now disabled on a database
that is being started.
================(Build #3471 - Engineering Case #686561)================
If any of the following occurred while starting a database, the server could
have crashed, although it would only occur in very rare situations:
1. An error was encountered while starting the database
2. Logs were being applied to a database at startup with -a, -ad or -ar
but the -as switch was not used
3. The engine was requested to stop while the database was starting.
This has now been fixed.
================(Build #3471 - Engineering Case #686183)================
If an application using the UTF8 character set connected via jConnect or
Open Client to a blank padded non-UTF8 database and fetched a non-nullable
char(n) value, then the returned value would have been blank padded to n*3
bytes. This problem has now been fixed.
================(Build #3471 - Engineering Case #681921)================
If an application had an insert trigger on a local table that referenced
a proxy table, then the trigger could have failed if the remote query involved
the new row values for the trigger. This problem has now been fixed.
================(Build #3471 - Engineering Case #670470)================
If the server received an OS error for a disk write to the database file,
transaction log file or temporary file, and the written size was zero, then
it may have incorrectly reported a disk full error. This has been fixed.
As well, disk write error messages will now print the file name and the OS
error code.
================(Build #3470 - Engineering Case #686409)================
If an IPv6 address that included a port number was specified in square brackets,
rather than parenthesis, the server or client libraries would not have parsed
it correctly. For example, if a connection string included ";HOST=[<ipv6_addr>]:<port>",
the error "No IP address found for [<ipv6_addr>]:port." This
has been fixed.
Note, this applies to addresses in connection strings (using the LINKS or
HOST parameters), the -x and -xs switches on the server, and URLs in web
service procedures.
================(Build #3469 - Engineering Case #686204)================
Cancelling an external environment call that was in the process of returning
a large result set, could in very rare cases have caused the server to crash.
This problem has now been fixed.
================(Build #3469 - Engineering Case #685574)================
When unloading a database, ALTER INDEX ... RENAME statements were not being
added to the reload.sql file when an index or unique constraint had been
renamed. This has been fixed.
================(Build #3469 - Engineering Case #684769)================
In very rare cases the server may have crashed when upgrading a pre-version
12 database to version 12, if the database did not use a transaction log
file. This has been fixed.
================(Build #3468 - Engineering Case #686203)================
Cancelling an external environment call call immediately after making the
external call, could in very rare cases have caused the server to crash.
This problem has now been fixed.
================(Build #3468 - Engineering Case #686036)================
Attempting to make a Remote Data Access connection to an Oracle database,
using an ODBC driver other than the iAnywhere Oracle ODBC driver, could have
caused the server to crash when running on a Unix system. This problem has
now been fixed.
================(Build #3467 - Engineering Case #686009)================
Under some circumstances SQL Anywhere HTTP logs would have contained an empty
URI for the @U log-format place holder. This may have occurred for the following
reasons:
- HTTP METHOD was not supported,
- request URL was malformed,
- the HTTP listener specifies that the DBN was required but the database
name was not within the URL path.
This has been corrected. Now if a request has faulted due to any of the
above reasons, the HTTP method (@M) and version (@V) will emit the string
"???". The given request line is pre-pended with a ">>>"
and emitted for the (@U) format place holder.
For example:
A request of the form:
BLAH /sample/test HTTP/1.0
will emit the following for LogFormat="@M @U @V"
"??? >>> BLAH /sample/test HTTP/1.0 ???"
================(Build #3465 - Engineering Case #685733)================
The server could have unnecessarily consumed 100% of one CPU in certain circumstances
as described below. These problems have been fixed.
- In certain cases when a copy node lost its connection to its parent and
then encountered a log mismatch with the parent after it reconnected, a single
CPU would remain at 100% utilization indefinitely.
- When cancelling a CREATE EVENT statement while processing a procedure
profile (sa_procedure_profile, sa_procedure_profile_summary), a single CPU
would have remained at 100% utilization until no connections were processing
profile information
- While waiting for connections to drop when yielding to a mirroring partner,
a CPU would have remained at 100% utilization until all connections were
dropped.
================(Build #3465 - Engineering Case #684891)================
If a query plan used multiple nested-loops outer joins then a cursor positioning
using FETCH RELATIVE 0 may have returned the next row in the forward direction,
instead of refetching the current row. This has been fixed.
A possible work-around for the problem is to use an insensitive or keyset-driven
cursor type.
================(Build #3463 - Engineering Case #685559)================
If a non-recurring event was run on a read-only database, or had the "FOR
ALL" clause, indicating it could run on a mirror or copy node, the server
could have hung with 1 CPU at 100% after the event ran. Non-recurring events
are events with a SCHEDULE clause that does not specify EVERY or ON. This
has been fixed.
================(Build #3461 - Engineering Case #685318)================
The values returned in the table_page_cached and ext_page_cached columns
of the result set returned by the system procedure sa_table_stats() could
have been smaller than the number of pages that were actually cached by the
server. This problem has been corrected.
================(Build #3461 - Engineering Case #683525)================
If a partner in a mirroring environment setup that is mirroring more than
one database, it is possible to specify more than one mirror state file.
If multiple databases were started and configured on the same server without
restarting the server after configuration, this could have resulted in the
server not being able to get quorum when its partner shut down. This has
been fixed.
================(Build #3460 - Engineering Case #685323)================
If the server's ports (-x) or web protocols command line option (-xs) contained
certain multibyte characters, the server could have failed to start up and
would have displayed the server's usage message or window. This problem
has been fixed.
================(Build #3456 - Engineering Case #683717)================
When performing a database upgrade (either via the Upgrade utility (dbupgrad)
or via the ALTER DATABASE UPGRADE statement) on a database containing spatial
data, the server would have terminated with a the following error:
SQL error (-1474) -- SRID 0 is referenced by column ... of table ...
This has been fixed.
================(Build #3456 - Engineering Case #680766)================
Execution of a CREATE OR REPLACE SEQUENCE statement would have failed with
the error "Sequence <sequence name> already exists" if the
sequence already existed. This has been fixed.
The workaround is to manually drop the sequence before issuing the CREATE
statement.
================(Build #3451 - Engineering Case #682530)================
When unloading a database, the DESC clause was not being added to statements
in the reload.sql file when creating Primary and Foreign Keys with a descending
sequence. This has been fixed.
================(Build #3450 - Engineering Case #684335)================
An explicit or implicit cursor describe that should have failed could have
caused the server to crash. An example of a describe cursor that is expected
to fail is if the describe is cancelled. This has been fixed so that server
no longer crashes.
================(Build #3450 - Engineering Case #681963)================
If a statement similar to the statement below was used in a stored procedure,
function, or trigger, a syntax error may have been incorrectly returned.
The statement must have containeds both MATCH and DELETE or INSERT clauses.
This has been fixed.
For example:
create or replace PROCEDURE test1( )
BEGIN
ALTER TABLE ixddl6 ADD CONSTRAINT FK_primary
FOREIGN KEY (x)
REFERENCES ixddl5(pk)
match unique simple on delete set null
END
================(Build #3450 - Engineering Case #680769)================
When unloading a database, SEQUENCE generator comments were not included
in the reload.sql file. This has been fixed.
================(Build #3448 - Engineering Case #684096)================
In timing dependent cases, a read-only scale-out copy node could have crashed
or hung. This was more likely if the server was loaded and requests needed
to be queued because there were no idle workers (more concurrent tasks than
the current multiprogramming level). This has been fixed.
================(Build #3447 - Engineering Case #683947)================
In very rare cases, when a server shutdown was requested via the server console,
the server would have shutdown successfully, but the server console would
have stayed up. This would only have occurred on Windows machines with multiple
processors. This has been fixed.
================(Build #3447 - Engineering Case #683728)================
In some situations, the server may have crashed while executing an ALTER
SYNCHRONIZATION PROFILE statement with the MERGE clause. The maximum size
of the new profile string was being calculated incorrectly. This has been
fixed.
================(Build #3447 - Engineering Case #680767)================
When unloading a database, incorrect CREATE TEXT CONFIGURATION of external
term breakers and prefilters were being generated in the reload,sql file.
This has been fixed.
================(Build #3446 - Engineering Case #683410)================
A server in a mirroring system could have crashed when another server with
many IP addresses was connected. This has been fixed.
Note, if a server that does not have this fix, and has many IP addresses,
connects to a server with this fix, the fixed server will give a protocol
error.
================(Build #3446 - Engineering Case #680779)================
When unloading a database, the ALTER TABLE statement to generate unique constraints
in the reload.sql file did not include the CLUSTERED keyword for clustered
unique constraints. This has now been corrected.
================(Build #3446 - Engineering Case #680242)================
Procedures with a SELECT statement that called another procedure may have
become slower over time. This happened when the SELECT statement generating
the result of the inner procedure qualified for a certain type of caching.
This has now been fixed.
A workaround is to ensure that the SELECT statement inside the inner procedure
is not subject to simple query caching. If this slowdown is observed, the
workaround can be implemented by adding a predicate that is not a tautology,
but which is always known to be true for the data, to the inner select.
For example, if a certain column is always greater than zero, adding the
predicate col >= 0 is sufficient to avoid the problem. Note that simple
predicates such as 1=1 will be detected as data-independent tautologies and
removed.
================(Build #3444 - Engineering Case #683707)================
When a copy node was promoted to replace its parent via "ALTER MIRROR
SERVER ... ALTER PARENT FROM ...", or internally because a copy node
was not responding, siblings of the promoted node did not notice that their
parent had changed and would continue trying to reach their original parent.
This has been fixed.
================(Build #3436 - Engineering Case #682250)================
In a database mirroring setup using asynchronous mode, the mirror was not
responding to pages sent by the primary as quickly as it should, affecting
performance. This has been fixed and performance should be improved.
================(Build #3436 - Engineering Case #681813)================
The system procedure sa_mirror_server_status() would have returned incorrect
results when run on a copy node server, or a mirror server in a mirroring
setup. The procedure was returning results for the server's parent or partner,
and could have returned an incorrect status for a server that had been involved
in a failover. This has been fixed. The procedure will now return the correct
status for the queried server and its children.
================(Build #3435 - Engineering Case #683385)================
If an application that was connected using Open Client or jConnect executed
a Transact SQL batch that contained an undefined host variable, then there
was a chance the server would have crashed. This has now been fixed so that
batch will fail with a "not enough values for host variables" error.
================(Build #3433 - Engineering Case #683170)================
When using a CREATE OR REPLACE MIRROR SERVER server_name AS COPY USING AUTO
PARENT statement to convert a mirror server from a partner to a copy node,
server_name would have been given an invalid parent and the alternate parent
would be lost. This problem has been fixed.
================(Build #3432 - Engineering Case #683025)================
If the connection making an http or https request was closed while the request
was still executing, and that request was in turn making a request to a mirror
server (for high availability or read-only scale-out), or making a request
to a diagnostic server, the server could have hung or fail in some other
way. This has been fixed.
In high availability or read-only scale-out, if the connection to the primary
or parent server was dropped just after the mirror or copy node had determined
its role, the mirror or copy node could have failed to start with the errors:
"database is not compatible with primary; files must be replaced"
and
"Database server shutdown due to incompatible files for database mirroring."
This has been fixed. Note that attempting to restart the mirror or copy
node after receiving this error should succeed in this case.
================(Build #3431 - Engineering Case #681758)================
In a mirroring setup, copy node server console messages often said "mirror"
or "partner", causing confusion about the actual role of the server
and which server was its parent server. This has ben corrected so that the
server console messages for a copy node will now refer to the copy node itself
as "copy node", and its parent as "parent".
================(Build #3428 - Engineering Case #682762)================
Changes forn Engineering case 674559 introduced a bug which could have caused
a crash on the primary server of a mirroring system when auto-adding a copy
node. This problem has been fixed.
================(Build #3428 - Engineering Case #682756)================
If operations on a mirror server created a cycle by committing operations
on the primary server (via, for example, an OMNI connection), the primary
and mirror servers could have deadlocked on each other and appear to hang.
The problem was most likely to have been seen when the mirror server was
also attempting to shut down. This problem has been fixed.
================(Build #3427 - Engineering Case #682512)================
If a high availability partner was shutdown while it was the primary, its
partner took over as primary, and then the partner that was shutdown was
restarted, it could have failed to start with the errors:
"database is not compatible with primary; files must be replaced"
and
"Database server shutdown due to incompatible files for database mirroring."
This has been fixed.
================(Build #3425 - Engineering Case #681396)================
If an Unix machine had many network interfaces (hard to say how many), starting
the server may have failed. The only error message displayed was "TCPIP
communication link not started". This has been fixed.
================(Build #3424 - Engineering Case #682246)================
If an application attempted to cancel a query that involved one or more proxy
tables, then the cancel request would have, in some rare cases, been ignored.
This problem has now been fixed.
================(Build #3424 - Engineering Case #681765)================
One or more high availability or read-only scale-out servers could have hung
in rare timing dependent cases. This has been fixed.
================(Build #3424 - Engineering Case #681755)================
In a high availability setup, if both partners accessed the arbiter at the
same time, the arbiter could have crashed or behaved incorrectly. This has
been fixed.
================(Build #3423 - Engineering Case #681796)================
In a High Availability system, if the primary was processing changes faster
than the mirror could apply them, it was possible that the primary could
have hung. This has been fixed.
================(Build #3422 - Engineering Case #681398)================
The server could have crashed while using the UNLOAD statement to unload
data with 'APPEND ON' to a file if that file was also being deleted by some
other process. This has been fixed
================(Build #3421 - Engineering Case #681612)================
In a read-only scale-out configuration, the use of CREATE OR REPLACE MIRROR
SERVER parent-server (where parent-server is the parent to any copy node)
could have resulted in incorrect behaviour. The incorrect behaviour included
servers and/or databases stopping, or the copy node not being able to connect.
This has been fixed.
================(Build #3420 - Engineering Case #681571)================
If an application attempted to drop a connection that had a cursor on a proxy
table open, then there was a chance the server would have crashed. This
problem has now been fixed.
================(Build #3420 - Engineering Case #681545)================
If a client's character set was a multi-byte character set, the following
operations could have resulted in CHAR or NCHAR sizes larger than they should
have been:
- the columns in a table created by the SELECT ... INTO [ LOCAL TEMPORARY
TABLE ] table-name
- the columns in a view
- sa_describe_query and sa_describe_cursor domain_name_with_size and widths
- the EXPRTYPE returned data type length
These operations have been fixed to return the correct lengths.
================(Build #3419 - Engineering Case #681551)================
In rare cases, the server may have hang while trying to flush histogram statistics.
This has been fixed.
================(Build #3419 - Engineering Case #676340)================
The database server could have taken longer than expected to perform a backup.
During such a backup other database requests may have appeared to stall,
and connections to the server may also have been impacted. This should only
have occurred if the total size of database files was larger than 5 GB. This
has been fixed.
================(Build #3418 - Engineering Case #680180)================
Conversions between Date and Time datatypes during direct computation would
fail in versions 11.0 and earlier, but in version 12.0, this conversion did
not fail. This has been fixed so conversions between dates and times in version
12.0 will now also fail, as these conversions are invalid.
================(Build #3417 - Engineering Case #680726)================
If a server identity file with an unencrypted private key was provided to
the server, the server would have refused to use it, reporting "Error
parsing certificate file, error code 4113". This has been fixed.
Note that this problem would not be seen on Mac OS X systems.
================(Build #3417 - Engineering Case #680569)================
When run on Unix systems, the system procedure xp_startsmtp(), which Starts
an email session under SMTP, would have hung when called with a non-null
"trusted_certificates" argument. This has been fixed.
================(Build #3415 - Engineering Case #675738)================
Some statements, like CREATE TEXT INDEX and CREATE MATERIALIZED VIEW, record
the current database option values that exist at the time the statement was
executed in the transaction log. The server would have returned the assertion
failure error 100904 - "Invalid option '<option-name>' -- no PUBLIC
setting exists", if there was not public setting for one of
these options during startup recovery, or when applying changes on a mirror
server. This has been fixed.
================(Build #3413 - Engineering Case #679370)================
If an application had a proxy procedure defined with an INOUT or OUT parameter
of type [n][var]char(m), then calling that proxy procedure would have caused
a server crash if the remote returned a value for that parameter that was
the full m characters long. This problem has now been fixed.
================(Build #3412 - Engineering Case #680196)================
An application that connected using jConnect version 7 would have found that
certain DatabaseMetaData calls returned incorrect results or unexpected errors.
These metadata problems have now been corrected.
Note that a database upgrade is needed in order to get this fix.
================(Build #3412 - Engineering Case #678117)================
Under rare circumstances, the database server could have crashed or failed
an assertion while running diagnostic tracing on a database where a large
number of procedures, user-defined functions, triggers or events are being
invoked. This has been fixed.
================(Build #3412 - Engineering Case #677165)================
In specific circumstances, it was possible for the server to fail assertion
101519. This has been fixed.
================(Build #3411 - Engineering Case #680025)================
If a database had one or more ODBC based remote servers that used the new
"driver=SQL Anywhere Native" feature, and if more than one connection
attempted to establish a remote connection using these remote server definitions,
and if no other connection had previously established a remote server definition
using one of these remote server definitions, then there was a very small
chance that the server would have crashed on exit. This problem has now been
fixed.
================(Build #3410 - Engineering Case #679605)================
When a geometry had multiple polygons configured in a particular way, the
Union of that geometry with another polygon, which was also configured in
a particular way, would have caused a 'ring not closed' error.
A simple example of a query that demonstrates this error is:
select ST_Geometry::ST_GeomFromText( 'MultiPolygon( ( ( -10 -10, -11 -10,
-11 -11, -10 -11, -10 -10 ) ), ( ( 2 2, 2.5 1, 1 1, 1 2, 0 2, 0 0, 3 0, 3
2, 2 2 ) ) )' ).ST_Union( ST_Geometry::ST_GeomFromText( 'Polygon( ( 1 1,
2.5 1, 2 2, 1 2, 1 1 ) )' ) )
The only work around is to break up the MultiPolygon and perform the unions
in a different order.
This has been fixed.
================(Build #3410 - Engineering Case #679580)================
The server could have crashed if a table was being dropped at the same time
as a virtual table was being created. This has been fixed.
================(Build #3410 - Engineering Case #678942)================
There was a small chance that some statistics could have been reported incorrectly
if parallel plans were used. Statistics affected include lock count, and
the various io counts. This has been fixed.
================(Build #3409 - Engineering Case #679408)================
If a connection exists on the mirror server (ie, not the primary) when a
failover occurs, that connection will persist while that partner becomes
the primary. Database operations then performed by that connection (including
certain temp-table operations which are valid from read-only connections)
could have caused errors or crashes on other servers in the mirroring / HA
system. This problem has been fixed.
================(Build #3408 - Engineering Case #677430)================
In extremely rare cases, inserting data into a compressed column that had
a blob index may have resulted in the blob index becoming corrupt. This could
have resulted in assertion failures if the data was accessed randomly (i.e.
using substr(), right(), or similar), and would also have resulted in validation
failures. This has been fixed.
Note: existing corrupted blob indexes must be dropped and recreated after
the fix is applied. This can be done using:
alter table <table> alter <column> no index
alter table <table> alter <column> index
================(Build #3407 - Engineering Case #678817)================
A canceled SQL Anywhere HTTP client procedure may, on rare occasions, hang
the server. This has been fixed.
================(Build #3403 - Engineering Case #678259)================
A SQL Anywhere http procedure call may, on rare occasions, have caused the
server to crash. This has been fixed.
================(Build #3402 - Engineering Case #677515)================
Running REORGANIZE TABLE on a table with foreign key indexes when the database
was under heavy update/delete load, had a chance of corrupting the table.
Specifically, the indexes on the table would have contained more values then
the table itself. This has been fixed.
================(Build #3402 - Engineering Case #677251)================
If an embedded SQL application or a stored procedure first opened a READ
ONLY cursor on a simple SELECT query qualifying for optimizer bypass, and
later opened an UPDATE cursor for the same query, a positioned update to
the second cursor could have failed with SQLCODE -192 ("Update operation
attempted on non-updatable query"). This has been fixed.
For the error to occur in version 11, the first cursor would need to be
explicitly declared FOR READ ONLY, because FOR UPDATE is the default (c.f.
documentation for DECLARE CURSOR statement). In version 12.0.0 and later,
cursor updatability depends upon cursor type (c.f. documentation for SELECT
and PREPARE statements) but defaults to FOR READ ONLY for ESQL.
================(Build #3402 - Engineering Case #671017)================
In a certain virtual machine implementation, CPU topology detection (which
is performed at server startup) could spin consuming 100% of a single logical
CPU. The VM software had bugs which reported CPU information to the guest
operating system in a manner that does not meet Intel's specifications. Changes
have now been made so that SQL Anywhere can tolerate the bugs in the VM software
without affecting correct CPU detection in other nvironments.
================(Build #3401 - Engineering Case #677962)================
When a database was shut down (for example, as part of server shutdown) and
the database was a high availability mirror or a read-only scale-out copy
node, the server could have hung in rare timing dependent cases. If the server
was hung due to this problem, there would have been messages like the following
in the server console:
A write failed with error code: (6), The handle is invalid.
Fatal error: disk full when writing to "???"
This has been fixed.
================(Build #3401 - Engineering Case #665212)================
Statements using user-defined functions eligible for inlining could have
failed unexpectedly. This problem could have affected databases created with
earlier versions and reloaded to a version 12 database if such databases
contained views referencing inlinable user-defined functions. Such databases
could have failed to be reloaded. This has now been fixed.
================(Build #3400 - Engineering Case #677803)================
If an invalid certificate was encountered by the server running on the Mac,
the error reported may have been "Error parsing certificate file, error
code 0". This has been fixed, the error code should have been non-zero
if an error occurred.
Note, this problem also affected SQL Anywhere clients running on the Mac.
================(Build #3399 - Engineering Case #677327)================
In some cases, SQL Anywhere HTTP procedures and the HTTP server would have
failed to process received chunked mode transfer encoded data when the chunk
length meta-data contained leading zeros. This has been fixed.
================(Build #3396 - Engineering Case #676210)================
Execution of a SET REMOTE OPTION would have failed if the value of the setting
was larger then 256 bytes. This was due to the schema of the ISYSREMOTEOPTION
table which has a 255 byte limit on the length of the settings column. The
server has been changed to provide a more appropriate error message.
================(Build #3395 - Engineering Case #672573)================
Using either mixed case or upper case when specifying the ".dll"
portion of the assembly name in a CLR external environment procedure, could
have caused the external environment to fail to run the specified method
within the assembly. For example, an external name clause like:
external name 'MyTest.DLL::MyNameSpace.MyTestClass.MyMethod() int'
would have failed to execute MyNameSpace.MyTestClass.MyMethod, but an external
name clause like:
external name 'MyTest.dll::MyNameSpace.MyTestClass.MyMethod() int'
would successfully find and execute MyMethod. This problem has been fixed.
Note that a workaround is to simply lower case the ".dll" portion
of the assembly name.
================(Build #3394 - Engineering Case #675326)================
When run on a Windows Mobile device, the server could have crashed if the
"Authentication parameters" field in an existing "SYNCHRONIZATION
PROFILE" was modified. This has now been fixed.
================(Build #3393 - Engineering Case #674559)================
1) In a read-only scale out environment, if a copy node was automatically
added (no CREATE MIRROR SERVER statement was executed), but the database
server was restarted and used a different TCP/IP address or port, it would
have failed to connect properly to other mirror servers. This has been fixed
so that copy node servers and primary servers that have this fix will automatically
continue to be able to connect if the copy node's TCP/IP address or port
changes the first time the copy node connects.
2) If an ALTER MIRROR SERVER statement was executed to adjust a copy node's
connection string, that copy node may have temporarily failed to connect
properly to other servers. This has also been fixed.
================(Build #3392 - Engineering Case #676664)================
After the changes for Engineering case 661663, passing an invalid certificate
to a web procedure (i.e. CREATE FUNCTION ... URL '...' CERTIFICATE '...')
may have caused the server to crash when the procedure was executed. This
has been fixed.
================(Build #3392 - Engineering Case #676015)================
Queries involving spatial predicates over an indexed geometry column may
have failed to select a plan that used the spatial index if the table was
very large (several gigabytes at least). This has been fixed.
================(Build #3391 - Engineering Case #676495)================
1. A copy node can now act as an arbiter for the database it is copying in
a high-availability system with mirroring. The arbiter and both partners
must be running the updated software to take advantage of this change. As
before, a partner cannot act as arbiter for its own database. When defining
the arbiter to refer to a copy node, use an arbitrary mirror server name
for the arbiter that does not match the server name of any of the database
servers in the HA system. The name of the arbiter mirror server isn't actually
used for connecting. For example:
CREATE MIRROR SERVER "scaleout_child" AS COPY connection_string
= 'server=scaleout_child;host=winxp-2:6878';
CREATE MIRROR SERVER "TheArbiter" AS ARBITER connection_string
= 'server=scaleout_child;host=winxp-2:6878';
Note that there is no database server in the HA system that is running with
the server name "TheArbiter": it is just being used as a placeholder
in the mirror server definitions to hold the connection string for the arbiter.
2. Copy nodes could have reported a log mismatch error in certain cases
involving a failure of both the primary server and the arbiter. This problem
has been fixed.
3. There was a race condition that could have allowed an arbiter server
to create two separate internal states for the same mirroring system. This
problem has been fixed.
================(Build #3388 - Engineering Case #676007)================
The server would have failed to rename the request log correctly if the option
RequestLogNumFiles was set to 1. This has been fixed.
================(Build #3388 - Engineering Case #674917)================
Under rare conditions, the server could have crashed when processing queries
with intra-query parallelism. This has been fixed.
The crash can be worked around by disabling intra-query parallelism by setting
the database option MAX_QUERY_TASKS=1.
================(Build #3385 - Engineering Case #644908)================
After an ALTER TABLE statement, some views may have been incorrectly marked
as INVALID. The problem only occurred for views in which the altered table
occurs multiple times in the logical expansion of the view definition. This
has been fixed.
================(Build #3384 - Engineering Case #671906)================
When processing an UPDATE statement, the server could have constructed erroneous
values for the OLD table that would have been created for AFTER ROW or AFTER
STATEMENT triggers. This could have lead to incorrect results if the AFTER
trigger referenced these values, or could have resulted in the statement
failing with an SQL error. The problem would have occurred if and only if
the following conditions hold:
1) The UPDATE statement modifies a table that had a primary key, UNIQUE
constraint, or unique index.
2) The UPDATE statement modified a column included in the primary key, UNIQUE
constraint, or unique index, such that the new value matched a value already
existing in the index.
3) The modified table had an AFTER ROW or AFTER STATEMENT trigger
This problem has been corrected.
================(Build #3382 - Engineering Case #674782)================
If a server involved in a high availability mirroring system had active TLS
connections, the server may have hung indefinitely due to a thread deadlock.
This has been fixed.
================(Build #3382 - Engineering Case #674753)================
In rare, timing depending cases, a primary, mirror or copy node server could
have hung while shutting down. This has been fixed.
================(Build #3381 - Engineering Case #674704)================
If a directory access server was queried, and one of the files was owned
by a user that did not exist on the system where the server was running,
then the server would have crashed. This problem has now been fixed.
================(Build #3381 - Engineering Case #674537)================
Simple INSERT statements referencing a table with an article defined with
a non-empty WHERE and/or SUBSCRIBE BY clause could have occasionally failed
with a "Column not found" error for the column referenced in either
WHERE or SUBSCRIBE BY clause. Re-execution of the same INSERT would, in most
cases, have succeeded with no error. This has been fixed.
================(Build #3380 - Engineering Case #674550)================
Calling the system function WRITE_CLIENT_FILE could have incorrectly resulted
in the error "Client library reported a permissions error accessing
object ('<FILENAME>') during transfer" if there were multiple
READ_CLIENT_FILE or WRITE_CLIENT_FILE calls in a batch, procedure, or function
referring to the same client file name. This could have happened if the client
executed a batch or procedure, which in turn called other functions or procedures
which ended up doing multiple READ_CLIENT_FILE or WRITE_CLIENT_FILE calls
during the execution of the batch or procedure that was executed by the client.
This has been fixed by explicitly closing the file at the end of the function
call. The file was previously closed at the end of the request.
================(Build #3379 - Engineering Case #673173)================
The fix for Engineering case 661622 missed the situation where a subselect
that referenced two tables from the main query block, and was equated to
a constant, could also have caused the server to fail an assertion or crash
.
For example:
Select *
from T1, T2
where 10 = (select e1 from R where p(R,T1, T2) ) and ..
This has now been fixed.
================(Build #3377 - Engineering Case #674582)================
The server would have crashed when inserting several values lower then MIN_DBL
(about 1e-306, which is the smallest double which can be stored in normalised
format) which still can be stored using denormalized double values. This
was fixes by forcing all of the denormal double values to be rounded down
to zero.
================(Build #3377 - Engineering Case #674320)================
After a MANUAL or AUTO REFRESH text index was renamed, it may not have been
found by subsequent statements. This has been fixed.
Note that restarting the database server eliminates the problem
================(Build #3375 - Engineering Case #674027)================
When using read-only scale-out and the NodeType=COPY parameter, the connection
may have been incorrectly redirected to a parent node or a node which had
a higher load than the current node. Also, in very rare timing depending
cases with concurrent clients connecting with NodeType=COPY, the server could
have crashed. These problems have now been fixed.
================(Build #3375 - Engineering Case #673704)================
In very rare circumstances, the histogram cleaner could have caused the server
to crash. This has now been fixed.
================(Build #3371 - Engineering Case #673844)================
The server may have crashed while attempting to log a deadlock error between
connections. For this to have happened, the Log_deadlocks option needed to
have been set to 'on', and at least one of the connections that was participating
in the deadlock needed to be executing a query that had a parallel plan.
There are two possible workarounds:
1) Turn off intra-query parallelism by setting the Max_query_tasks option
to 1, or
2) Set the Log_deadlocks option to 'off'
This problem has been fixed.
================(Build #3371 - Engineering Case #673212)================
1) If one TCP/IP address for one partner server in the partner/mirror/primary
server connection string in the MIRROR SERVER or -xp configuration was correct,
but the TCP/IP address for the other mirror partner server was incorrect,
it was possible for the primary server to have skipped performing checkpoints
indefinitely. This could only occur with the incorrect TCP/IP address configuration
and if the mirror servers contained the fix for Engineering issue 660851.
This has been fixed so that the primary server checkpoints normally.
2) If a High Availability or read-only scale-out server failed to connect
to another server, there may not have been any indication of the failed connect.
This has been fixed by logging a message to the console for each failed connection.
3) A High Availability or read-only scale-out server may have displayed
the message "... recovery n% complete" where n was a number less
than zero or much greater than 100. This has been fixed.
================(Build #3369 - Engineering Case #675686)================
The server may have failed assertion 101412 - "Page number on pages
does not match page requested", if the database/connection option 'chained'
was set to 'off'. This has been fixed.
================(Build #3369 - Engineering Case #673014)================
When a SQL Anywhere ROOT service processes a request and queries its HTTPServiceName
connection property, its name "root" is appended to the first path
element (if one is present). This has been fixed. The HTTPServiceName for
a ROOT service is always "root".
================(Build #3369 - Engineering Case #672879)================
If a High Availability partner or copy node encountered a problem (such as
the log file being inconsistent compared to the partner or parent), it would
have shutdown the problem database. If the same server was also running one
other database (other than the database that was mirrored or a participating
in read-only scale-out) the server may have also incorrectly shutdown. This
has been fixed so that the mirror server or copy node server will only shutdown
the server if the only database running is the problem database.
================(Build #3369 - Engineering Case #672858)================
The server could have crashed if a table was being dropped at the same time
as a proxy table was being created. This has been fixed.
================(Build #3367 - Engineering Case #672749)================
If the two partner databases in a mirroring configuration were both starting
up at the same time, while the servers that were hosting them were attempting
to shut down, both servers could have hung. This problem has been fixed.
================(Build #3365 - Engineering Case #672430)================
In very rare situations, the server may have hang on shutdown, if while in
the process of shutting down the option MaxMultiProgrammingLevel was increased.
This has been fixed.
================(Build #3365 - Engineering Case #665184)================
The server would have incorrectly returned the error "XPath parser error:
syntax error at or before character 0 <--" if a stored procedure
contained a SELECT statement with an openxml clause that used a variable
for the xpath string. This has been fixed.
================(Build #3364 - Engineering Case #672207)================
When attempting to use the IS [NOT] DISTINCT FROM predicate in a query that
involved proxy tables the server would have failed the query with a strange
"unknown node type" error. This problem has now been fixed and
the IS [NOT] DISTINCT FROM predicate can now be used with proxy tables.
================(Build #3363 - Engineering Case #672077)================
Executing a query that joined two or more External Environment result sets
could have caused the server to crash if the join resulted in a very large
result set. This problem has now been fixed.
================(Build #3363 - Engineering Case #672076)================
When inserting a string literal value into a time or timestamp column of
a proxy table, if the string literal contained more than 3 digits of precision
within the fractional seconds portion of the time/timestamp value, then the
fractional seconds would have been truncated to 3 digits of precision. This
problem has now been fixed.
Note that this fix only applies to ODBC based Remote Data Access servers.
The fractional seconds precision will still be truncated to 3 digits of precision
for JDBC based Remote Data Access servers.
================(Build #3363 - Engineering Case #671911)================
The system function OPENSTRING allows a text file to be parsed and interpreted
as a relational table. The schema for OPENSTRING can be explicitly specified
or can be provided by means of an existing database table. If a remote (IQ
or other proxy) table was used to specify the OPENSTRING schema then the
server can behave erratically, including crashing. This problem has now been
resolved.
================(Build #3361 - Engineering Case #671711)================
The changes for Engineering case 624047 could have caused a server running
high availability mirroring, or a read-only scale-out copy node, to fail
assertion 200131. The failure was timing dependent, and required accessing
an empty table with an index from a read-only connection. This has been fixed.
================(Build #3360 - Engineering Case #659138)================
In exceptionally rare cases, the server may have crashed if two procedure
debuggers had been attached to a database and one of them disconnected while
a new connect request for a user to debug was being executed. This has been
fixed.
================(Build #3360 - Engineering Case #655524)================
A MERGE statement on a table that had a column with DEFAULT AUTOINCREMENT
would have increased the autoincrement value for every matching row independently
of whether the value had already been used for an INSERT or not. This behaviour
has been improved so that the server only generates a new autoincrement value
if the matching branch is an INSERT and the value will be used.
================(Build #3357 - Engineering Case #670990)================
If the number(*) function was used in the VALUES clause of an INSERT statement,
then the server would have returned a non-fatal assertion error 106103. This
has been fixed so that the correct error is now returned.
================(Build #3356 - Engineering Case #670896)================
An "HTTP 404 Not Found" error could have occurred from a web service,
if the database that contained that web service was not started at the same
time the server was started. This could have happened if the database was
started via an ODBC DSN, or with the "START DATABASE" statement.
The problem did not occur when the name of the database file was specified
on the command line when starting the server. It also would not occur if
the database name was specified when calling the web service. This has been
fixed.
================(Build #3356 - Engineering Case #670866)================
The following query would have incorrectly returned a 1 indicating the date
string was acceptable:
select isdate('1234+')
While the following query failed with a runtime error indicating the date
string was not acceptable:
select date('1234+')
This problem has been fixed. The "isdate" query now returns 0.
At a minimum, the timezone indicator (+) must be followed by hours. For
example, '2011+5' is acceptable.
Also, if a date string contained a timezone offset of "+" or "-"
and was followed by the Z (Zulu) timezone indicator (e.g., '1234-12-31+Z'),
no error was diagnosed. This has been corrected.
================(Build #3356 - Engineering Case #670838)================
In rare timing dependent cases, if a High Availability mirror server was
in the process of taking over as the primary, it could have failed. The 201120
assertion failure could have been logged to the console log. This problem
could only have affected servers containing the fix for Engineering issue
663964. This has been fixed.
================(Build #3355 - Engineering Case #669965)================
A database server using web services could have crashed in very rare situations
when an HTTP connection was shutdown. This has been fixed.
================(Build #3354 - Engineering Case #670486)================
In exceptionally rare cases, the server could have crashed when executing
a non-parallel query that contains a hash join. The crash would only have
occurred if all of the following conditions were true:
- the probe input of the hash join had already consumed a lot of memory
for hash tables
- a child of the hash join returned an error
- a hash based parent query node of the hash join needed to allocate memory
for the hash table and is restricted by the memory governor, so that it had
to acquire memory from other hash based query nodes.
This problem has been fixed.
================(Build #3354 - Engineering Case #670403)================
When a database was shut down (for example, as part of server shutdown) and
the database was a high availability mirror or a read-only scale-out copy
node, the server could have hung in rare timing dependent cases. If the
server was hung due to this problem, there would have been messages like
the following in the server console:
A write failed with error code: (6), The handle is invalid.
Fatal error: disk full when writing to "???"
This has been fixed.
================(Build #3353 - Engineering Case #669448)================
When performing a backward index scan (a rare occurrence) while there were
heavy concurrent updates to the index, there was a small chance that the
server could have made a comparison to a random value with unpredictable
results. This has been fixed.
================(Build #3352 - Engineering Case #670202)================
In rare timing dependent cases, a primary, mirror or copy node server could
have crashed or hung.
Also in rare timing dependent cases, partner servers starting for the first
time could have fail to have chosen a primary after the changes for Engineering
case 663964.
These problems have been fixed.
================(Build #3352 - Engineering Case #669633)================
The SQL Anywhere Server provides a system procedure sa_refresh_materialized_views()
that can be used to refresh all currently stale materialized views. Invoking
the procedure with an argument value of 0 would have caused an error to be
reported if at least one of the materialized views failed to be refreshed.
This procedure is invoked by the reload script generated by the Unload utility
when executed with the "-g" command line switch. This problem has
now been resolved.
================(Build #3351 - Engineering Case #647802)================
The server may have failed assertion 106104 "field unexpected during
compilation" for queries containing correlated subselects in the WHERE
clause. The WHERE subselect predicate must have been of the form "T.X
= (subselect referencing R.Y)" where R.Y was an outer reference. This
has now been fixed.
================(Build #3349 - Engineering Case #669431)================
When attempting to cancel a Remote Data Access request to an ODBC based remote
server, there was a very small chance that the server would have become unresponsive
if all three of the following was true:
- the local server was running on a Windows based system
- the local server had a restricted (or small) number of CPUs or cores
(either due to the limitations of the server machine or VM, or as a result
of using the -gt or -gtc command line option)
- the remote server was not defined to utilize the new "driver=SQL
Anywhere Native" feature
This problem has now been fixed.
================(Build #3347 - Engineering Case #668989)================
In rare timing dependent cases, a transaction which was successfully committed
on a primary server could have been lost. In order for there to have been
a chance of this occurring, all of the following needed to be true:
- the application was connected to a primary server that lost quorum (the
server lost the connection to both the mirror and arbiter servers)
- the application stayed connected to this server (the old primary server)
even though the network connection to other servers dropped
- the application was in the middle of committing a transaction between
the time that the old primary server lost its connection to the mirror and
arbiter server, and when the old primary server restarted as the new mirror
server because it lost quorum
- the old mirror server took over as the new primary (the mirror server
must have been able to connect to the arbiter server for this to occur)
This has been fixed so that the application may now receive the new error
for this situation, "The transaction may not be committed because the
primary server lost quorum."
================(Build #3346 - Engineering Case #663056)================
In exceptional rare situations the server could have crashed or failed assertions
106808, 100913, or 111706 if very long property values are queried. This
has been fixed by truncating property values to the max varchar length of
32000 bytes.
================(Build #3343 - Engineering Case #664702)================
Queries using the spatial cast function TREAT( type1 AS type2 ) could have
failed to return a syntax error when it was used incorrectly, and instead
could have returned meaningless result sets. This has been fixed.
================(Build #3342 - Engineering Case #659608)================
When making an external environment call, if the external environment procedure
made a server side request that ended up leaving a cursor on a temporary
table open, then the server could have crashed when the connection was closed.
This problem has now been fixed.
================(Build #3341 - Engineering Case #668109)================
Attempting to start two High Availability partner servers without state files
(for example, starting them for the first time) could have, in rare timing
dependent cases, failed to have one server start as the primary. If this
occurred, one partner started as the mirror, and the other partner server
looped indefinitely attempting to determine which role it should take. This
has been fixed.
Also, if a mirror server was in the middle of taking over as the primary
when it was shutdown, the database shutdown could have hung until any remaining
connections were disconnected. This has been fixed.
================(Build #3340 - Engineering Case #667930)================
In rare situations, the server could have crashed when generating or updating
a histogram for a string column. This problem has been corrected.
================(Build #3340 - Engineering Case #667901)================
If an application connected via jConnect and then subsequently attempted
to use the {} JDBC escape sequence when making a stored procedure call, then
there was a chance the server would have returned an incorrect "variable
@p0 not found" error at the time the stored procedure statement or result
set was closed. This problem has now been fixed.
================(Build #3340 - Engineering Case #667900)================
If the Transact-SQL ROWCOUNT option was used to limit the number of rows
returned by a cursor, the cursor may have skipped the first row in the result
set in some cases. This incorrect behaviour only occurred for queries in
which optimization was bypassed, and the plan contained a SortTopN operator,
rather than a RowLimit operator. This incorrect behaviour was introduced
as part of the fix for Engineer case 653706, and has now been fixed.
================(Build #3339 - Engineering Case #667686)================
If an application attempted to cancel or drop a connection that was in the
process of making a connection-scoped external environment call, then there
was a very small chance the server would have crashed. This problem has now
been fixed.
================(Build #3339 - Engineering Case #660691)================
When accessing a directory or file using a Directory Access Server, if the
name of the directory or file contained a multi-byte character where one
of the bytes in the character was 0x5C, then the Directory Access Server
would have failed to find the directory or file. This problem has now been
fixed.
================(Build #3338 - Engineering Case #667518)================
When merging recent data distribution information into a table's histogram,
the server could have allocated up to one database page worth of data outside
of the database cache and then failed to free the memory. The leak could
eventually have caused the server to fail due to a lack of memory on 32-bit
platforms, or due to lack of swap space on 32-bit or 64-bit platforms. This
has now been corrected.
================(Build #3338 - Engineering Case #667001)================
If a stored procedure or a user defined function with the hidden definition
appeared on the stack when an error occurred, subsequent call to the TRACEBACK
function could have returned the statements from the hidden definition. This
has been fixed so that the output of the TRACEBACK function now contains
the string '<hidden>' instead of the statements from the hidden procedures
or user defined functions.
================(Build #3336 - Engineering Case #667316)================
When unloading a database, the server would have incorrectly output a "dynamic
result sets" clause for non-external environment procedures in the reload.sql
file. This problem has now been fixed and the "dynamic result sets"
clause is now only output for external environment procedures.
There are a few points of note:
1) this problem would only have occurred with stored procedures that were
created using an older SA 12.0.1 server
2) this fix will only affect new procedures that are created
3) the existence of the "dynamic result sets" clause for non-external
environment procedures is in fact a no-op and does not affect performance
or behaviour of the non-external environment procedure.
================(Build #3336 - Engineering Case #667314)================
If more than one connection attempted to install or remove Java external
environment objects at the same time, then there was a chance the server
would have crashed or failed assertions. This problem has now been fixed.
================(Build #3335 - Engineering Case #667142)================
In very rare timing dependent cases, the server could have crashed when a
database was stopping. Also in rare cases, it was possible for an automatically
started database to not automatically stop when there where no longer any
connections to it. Both of these problems have now been fixed.
================(Build #3332 - Engineering Case #661440)================
In rare cases, the server may have crashed while performing DDL and DML operations
concurrently. This has been fixed.
================(Build #3331 - Engineering Case #666639)================
The detection of processor geometry (number of physical processors, cores
and threads) was incorrect for certain Intel x86/x64 processors, including
the Intel Xeon E5405. The server would have detected all cores and threads
as belonging to a single physical processor. This problem has been corrected.
================(Build #3328 - Engineering Case #666182)================
An HTTP request over a persistent keep-alive connection to a SQL Anywhere
HTTP server may have failed if a previous request on that connection had
sent an unexpected body. This has been fixed.
For HTTP methods other than POST, the body may be retrieved using HTTP_VARIABLE('TEXT')
or HTTP_VARIABLE('BODY') as dictated by the Content-Type. An HTTP POST method
is assumed to have a Content-Type of application/x-www-form-urlencoded unless
otherwise specified (as with any other HTTP method, alternate Content-Types
may be accessed using HTTP_VARIABLE('TEXT') or HTTP_VARIABLE('BODY')).
================(Build #3328 - Engineering Case #665657)================
The problems described here affect Windows CE 5.x kernels only. Note that
Windows Mobile 6 platforms use the Windows CE 5.x kernel.
With version 11.x, the server was not able to create a cache larger than
32MB. Attempting to do so would have caused the error "Not enough memory".
With version 12.x, the server would have automatically and erroneously restricted
the cache size to a size smaller than 32MB.
The default maximum cache size was erroneously restricted to a value less
than 32MB.
The "percentage" notation for cache sizes (eg, "-c 50p")
erroneously based the percentage on a value that was less than 32MB, rather
than the total system memory as documented.
These problems have been corrected.
================(Build #3328 - Engineering Case #665630)================
Upgrading a database that had been created with the -dba switch (to set the
DBA username and password) could have failed. This has been fixed.
================(Build #3328 - Engineering Case #662419)================
A mirror node in a mirroring system could have failed to recover its database
if the database used sequence generators, and the primary and mirror roles
switched between the
servers. This has been fixed so that servers can now recover logs that exhibit
this problem.
================(Build #3327 - Engineering Case #666011)================
When a root server was committing and sending log pages to a copy node, the
root server could have experienced poor performance. Root servers which had
frequent commits, and copy nodes running on slow computers or connected through
high latency connections, would have shown the most noticeable poor performance.
This has been fixed so that the performance of the copy node latency will
have a smaller affect on the root node by using the equivalent of asynchronous
log page synchronization.
When using the "SET MIRROR OPTION synchronization_mode = '<value>'"
statement, where <value> was asynchronous or asyncfullpage, the server
was incorrectly treating this as a synchronous synchronization. This has
been fixed as well.
================(Build #3326 - Engineering Case #665799)================
On Windows systems, a minidump might not have been generated under certain
circumstances. This has been fixed.
================(Build #3326 - Engineering Case #665665)================
The server could have crashed when increasing the CurrentMultiProgrammingLevel
using the system procedure sa_server_option() if there wasn't enough memory
available. This has been fixed.
================(Build #3326 - Engineering Case #661622)================
Execution of a query with a subselect predicate correlated on two different
tables from the main query block may have caused an assertion failure in
the server. This has now been fixed
For example:
Select *
from T1, T2
where T1.X = (select e1 from R where p(R,T1, T2) ) and ..
The predicate "T1.X = (select e1 from R where p(R,T1, T2) )" has
a subselect and references both tables T1 and T2 from the main query block.
================(Build #3326 - Engineering Case #635353)================
The server could have hung when a connection disconnected, or was dropped.
This was more likely to have occurred if the server was under heavy load.
This has been fixed.
================(Build #3325 - Engineering Case #665684)================
If an application attempted to establish a Remote Data Access connection
to an ASE server, and that connection request failed over to a different
ASE server, then the Remote Data Access connection request would have failed.
This problem has now been fixed.
================(Build #3324 - Engineering Case #665524)================
An exclusive table lock on a non-transactional global shared temporary table
could have caused the server to crash on subsequent INSERT, UPDATE or DELETE
statements. This has been fixed.
All conditions must have been met (non-transactional, shared global temp
table,
and LOCK TABLE WITH EXCLUSIVE) for the crash to have occurred. If any of
these three can be relaxed, the crash will be avoided.
================(Build #3324 - Engineering Case #665522)================
The attachment specified by the attachname parameter of the system procedure
xp_sendmail() may not have been received properly by the recipient's mail
client. This has been fixed.
================(Build #3324 - Engineering Case #661066)================
If a range of values was supplied for the TCP/IP option ClientPort, connection
attempts may have been slow if the server was not found, or if multiple hosts
were supplied for the Host option. This has been fixed.
================(Build #3323 - Engineering Case #665325)================
When validating a database using the VALIDATE statement or the Validation
utility (dbvalid), the operation could not have been cancelled. This has
been fixed.
================(Build #3319 - Engineering Case #661036)================
Activity executing on the utility_db could have caused a crash, memory corruption,
or other unpredictable behaviour, if the cache were to shrink at the same
time. This problem has been fixed.
================(Build #3317 - Engineering Case #664695)================
In rare situations, the server could have erroneously reported the error
"Not enough memory" at startup. This problem has been corrected.
================(Build #3317 - Engineering Case #664490)================
Cancelling a query that referenced spatial functions could have caused the
server to crash, although the probability was exceedingly small. This has
been fixed.
================(Build #3315 - Engineering Case #664348)================
In very rare timing dependent cases, the server could have crashed or hung
on shutdown if there were active client requests during shutdown. The databases
would have already been stopped before the failure, so there was no chance
of data loss. This has been fixed.
================(Build #3315 - Engineering Case #664292)================
In rare situations, the server could have crashed if a log truncation or
rename (dbbackup -x or -xo or -r) took place while the server was processing
a large number of transactions, especially long-running transactions. This
has been fixed.
No workaround for this problem is known, except to avoid performing log
truncation or renaming when the server is handling large numbers of inserts,
updates or deletes.
================(Build #3314 - Engineering Case #664247)================
If the system procedure sa_get_user_status() was run on a database with an
extremely high number of user definitions, the procedure would have blocked
DDL statements and could not have been cancelled until its result had been
materialized. This has been fixed.
================(Build #3314 - Engineering Case #663940)================
In very rare cases, a spatial query that applied one of the following methods
to a complex geometry value may have returned an incorrect result, or an
error:
1. all set operations: ST_Union, ST_Intersection, ST_Difference, ST_SymDifference
2. certain aggregation functions: ST_UnionAggr, ST_IntersectionAggr
3. certain spatial predicates: ST_Intersects, ST_Overlaps, ST_Within, ST_Disjoint,
ST_Touches, ST_Crosses, ST_Contains, ST_Relate
This has been fixed.
================(Build #3311 - Engineering Case #663596)================
Attempting to insert a variable of type long binary, varchar or nvarchr into
a proxy or IQ table that had been generated using the REPEAT() function could
have caused an incorrect value to be inserted. It should be noted that this
problem would only have occurred if the fix for Engineering case 662000 had
already been applied. This problem has now been fixed.
================(Build #3309 - Engineering Case #663459)================
Attempting to autostart a database server on Windows CE when one was already
running was incorrectly giving the error:
"Unable to start specified database: server exit code -11728"
(where the number could vary).
This has been fixed to return the correct error:
"Database server already running"
Note that on Windows CE only one database server can be running at a time,
even if when attempting to start a second server with a different name.
================(Build #3309 - Engineering Case #659115)================
The server may have crashed if a query block contained an alias definition
and the expression of the alias used columns that could be folded as a constant,
(in the example below, alias v011 can be folded as a constant if column T2.a2
was created as NOT NULL), and the alias name was used in a subselect of the
query block and in the GROUP BY clause of the query block.
For example:
select if T2.a2 is null then 99999 else 11111 endif as v011,
(select count(*) from T1 where T1.a1 = v011) as c
from T2,T3
where T2.a2 = T3.a3
group by v011
This has been fixed.
================(Build #3306 - Engineering Case #663259)================
The Remote Data Access feature is now capable of loading the SQL Anywhere
ODBC driver directly. If a remote server is defined similar to the following:
CREATE SERVER remote-server CLASS 'saodbc' USING 'driver=SQL Anywhere
Native;...'
where the the USING clause contains the key pair "driver=SQL Anywhere
Native", and the remainder of the USING clause provides all the connection
parameters necessary to successfully connect to the remote SQL Anywhere server,
then the remote data access layer will load the SQL Anywhere ODBC driver
directly and bypass the Windows ODBC Driver Manager on Windows based platforms
and the SQL Anywhere ODBC Driver Manager on UNIX platforms. The benefit to
loading the SQL Anywhere ODBC driver directly is that, although the ODBC
driver still needs to be installed, it no longer needs to be registered if
it is only being used for the remote data access support. What's more, if
there are multiple copies of the ODBC driver installed, then loading the
ODBC driver directly will guarantee that the ODBC driver for the current
server version gets used rather than one that was registered with a previous
version of SQL Anywhere. It should be noted that if the application also
makes use of non-SQL Anywhere remote servers or if there are SQL Anywhere
remote servers defined without the "driver=SQL Anywhere Native"
key pair, then the remote data access layer will still use a Driver Manager
for those other remote servers.
================(Build #3305 - Engineering Case #663283)================
The server may have chosen less that optimal plans for queries with predicates
of the form 'T.X=(unknown expression)' if an index on T(X) existed. The
'(unknown expression)' could have been, for example, a variable whose value
was not used for queries inside the procedures, or could have been a complex
expression (i.e. "R.Y+1"). This has now been fixed.
================(Build #3305 - Engineering Case #661663)================
For each outgoing HTTPS web procedure connection, a small amount of memory
was leaked which could eventually have lead to memory exhaustion. This has
been fixed.
================(Build #3303 - Engineering Case #662025)================
In some cases, the server would have displayed recovery progress messages
incorrectly when recovering a large transaction log. In this situation, either
no messages would have been displayed or an incorrect percentage would have
been displayed. This has been fixed.
================(Build #3303 - Engineering Case #661633)================
Execution of an "UPDATE ... PUBLICATION ... WHERE .." statement
with a complex WHERE clause may have caused the server to crash. This has
been fixed.
================(Build #3302 - Engineering Case #662452)================
Attempting to start a connection-scoped external environment, and then canceling
the start request before the external environment completed the startup process,
could have caused the server to crash. This problem has now been fixed.
================(Build #3302 - Engineering Case #661193)================
Atempting to call a Java external environment stored procedure or function
with a very long binary or string input argument, could have taken a very
long time to execute. This problem has now been fixed.
================(Build #3301 - Engineering Case #662000)================
Attempting to insert a variable of type LONG BINARY into a proxy could have
taken a very long time, even though the variable was only a few megabytes
in length. This problem has been resolved and the performance of inserting
LONG BINARY variables into proxy tables has been greatly improved. Note that
this fix also improves the performance of inserting LONG VARCHAR and LONG
NVARCHAR variables into proxy as well.
================(Build #3300 - Engineering Case #660851)================
When a primary server lost its connections to both the mirror and arbiter
servers as a checkpoint was performed, the database on the primary may not
have been recoverable. Typically, it would fail assertion 100904. This
has been fixed.
Similarly, in cases where a primary server lost its connections to both
the mirror and arbiter servers as a checkpoint was performed, the next time
the primary and mirror servers were connected and attempt to synchronize,
the mirror server may have in rare situations reported "Database "<name>"
mirroring: database is not compatible with primary; files must be replaced"
and then stop with the message "Database server shutdown due to incompatible
files for database mirroring". This has been fixed to reduce the possibility
of this occurring. It is possible for this to still occur, so then the database
running on the current primary must be manually copied or backed up to the
mirror server so that the server can successfully synchronize again.
The primary server could have hung, again in rare situations, if only one
of the two connections between it and the mirror server was dropped, for
example due to a liveness timeout. This has been fixed.
When the mirror server was becoming the primary server there was a small
possibility it could have hung after reporting it was starting a checkpoint
and then reporting it was recovering. This has been fixed.
================(Build #3299 - Engineering Case #661453)================
If the distance parameter of the proximity search condition contained letters,
the server could have silently failed, and returned some result, instead
of reporting an error. This has been fixed.
For example, the following query would not report an error and would behave
as if the
full text query was 'apple NEAR[2] oranges':
SELECT *
FROM t CONTAINS( 'apple NEAR[ 2b ] oranges' )
Note that the following query was correctly reporting an error:
SELECT *
FROM t CONTAINS( 'apple NEAR[ b ] oranges' )
================(Build #3298 - Engineering Case #661034)================
Under rare conditions, the server could have hung while executing a query
with multiple GROUP BY clauses. This may have occurred when the workload
executing on the server suddenly changed (i.e. if many requests arrived almost
simultaneously). This has been fixed. A workaround is to disable intra-query
parallelism for the affected query (SET TEMPORARY OPTION MAX_QUERY_TASKS=1).
================(Build #3297 - Engineering Case #660629)================
When connected to an ASE 15.5 server and attempting to make a remote request
to SQL Anywhere, there was a chance the request would have failed with an
"unkown token 35" error. This problem has now been fixed.
Note that this problem only affected remote requests from ASE to SQL Anywhere.
The problem did not affect making remote requests from SQL Anywhere to ASE
via Remote Data Access.
================(Build #3297 - Engineering Case #660446)================
Performing a backup with a TRANSACTION LOG RENAME would have caused read-only
connections to the database on the mirror server to be dropped. This has
been fixed.
================(Build #3297 - Engineering Case #658330)================
Execution of an INSERT ON EXISTING UPDATE statement, with CASCADE as the
foreign key update option, would have resulted in a foreign key constraint
violation error when updating values which were logically the same, but had
different physical representation. For example, in case insensitive database
changing 'EMPLOYEE' to 'employee'. This has been fixed.
================(Build #3296 - Engineering Case #660432)================
Creating a variable with an initial value specified as a host variable did
not give a syntax error in some cases. This has been fixed.
================(Build #3296 - Engineering Case #660248)================
If an application connected via jConnect or Open Client and made an external
environment call that returned a result set, then the server may have crashed.
This problem has now been fixed.
================(Build #3296 - Engineering Case #659870)================
Empty string values indexed by an IMMEDIATE text index were not counted towards
the total number of documents indexed, unless more than one column was indexed
and the value in at least one of the columns was neither an empty string
nor NULL. This problem caused scores for full text queries to be lower then
they should have been if all the documents were correctly counted. Additionally,
a memory leak could have occurred in this situation. This has been fixed.
Note, if a text index was created or updated using a server with this problem,
it may be necessary to rebuild the index with an updated server if problems
are encountered with the index.
================(Build #3295 - Engineering Case #660235)================
On Windows Vista and later operating systems, whenever a new server executable
had to be launched in order to autostart a database, launching the executable
may have failed when a relative path to the server executable was specified.
For example, dbspawn mybin\dbsrv12.exe -n myserver my.db, or using "...;start=mybin\dbsrv12.exe..."
in a connection string, could have fail to launch the server executable.
This problem has been fixed.
================(Build #3295 - Engineering Case #660211)================
In rare circumstances, calling the system procedures sa_locks, sa_describe_shapefile,
st_geometry_dump, sa_list_cursors, or sa_mirror_server_status, could have
caused the server to crash, or could have caused unpredictable behaviour.
The problem was more likely to have occurred when small cache sizes were
used. This problem has been fixed.
================(Build #3295 - Engineering Case #660194)================
Execution of a query on a Directory Access proxy table with a WHERE clause
that contained a predicate of the form "file_name = variable",
may have sometimes run very slowly while running very quickly most other
times. This problem has now been fixed such that the query performance is
now consistently fast from one run to the next.
================(Build #3295 - Engineering Case #660057)================
If a foreign key was created with both MATCH and CHECK ON COMMIT clauses,
and the database subsequently required recovery, recovery would have failed
when replaying the statement from the transaction log. This has been fixed.
================(Build #3295 - Engineering Case #652949)================
The trigger operation condition 'UPDATE( {column-name} )' did not return
TRUE if the column value had been changed by a previously running BEFORE
UPDATE row-level trigger only. This has been fixed.
================(Build #3295 - Engineering Case #652244)================
An internal unload/reload (i.e. dbunload -ii) that encountered a SQL error
could have hung or caused a subsequent unload/reload on the same server to
hang. This problem has been fixed.
================(Build #3294 - Engineering Case #659804)================
If a proxy table or proxy procedure was defined with variables in the AT
clause, then the AT clause would have been incorrectly truncated if the length
of the AT clause after variable expansion was greater than the length of
the original AT clause. This problem has now been fixed.
================(Build #3294 - Engineering Case #659639)================
When making a Java external environment call, if the stored procedure had
an argument of type char (note that this is a single char value rather than
a java.lang.String), and a NULL value was passed in for the char argument,
then the server would have failed the request with a Java NullPointerException.
It should be noted that the Java VM would have continued to run in this situation
and the connection was still able to make subsequent Java external environment
calls. This problem has now been fixed such that passing a NULL char value
to a Java external environment call will result in a char with zero value
being passed down to the Java method. Again, it should be noted that this
problem does not affect passing NULL string values to java stored procedures.
================(Build #3294 - Engineering Case #659631)================
If an application enlisted a connection within a DTC transaction and then
subsequently attempted to perform a DTC commit on the transaction after explicitly
unenlisting it first, then the application would have hung until the server
was shut down. This problem has now been fixed and the commit request will
now immediately fail as expected.
================(Build #3294 - Engineering Case #659370)================
Inlining of simple functions could have generated unexpected errors or incorrect
results. For incorrect results to have occurred, the caller of the function
had to have variables defined with the same names as the inlined function.
This has been fixed.
================(Build #3294 - Engineering Case #613299)================
Queries involving indexes could return incorrect results, and using tools
such as the Validate Database Wizard in Sybase Central, or the Validation
utility, could have reported index corruption when there was in fact none.
For this to have occurred, the index must not have been unique and there
must be many consecutive rows with the same indexed value. This has been
fixed.
================(Build #3292 - Engineering Case #658985)================
Unexpected deadlocks could have occurred when using the UPDLOCK hint at isolation
level 3. For example, if two transactions issued the statements
SELECT t.c FROM t WITH (UPDLOCK) WHERE t.pk = 1
UPDATE t SET c = 2 WHERE t.pk = 1
concurrently at isolation level 3, a deadlock would have occurred if both
connections managed to issue the SELECT before either issued the UPDATE.
This has been fixed.
================(Build #3292 - Engineering Case #658849)================
If an application on a Unix system attempted to make a TCP/IP connection
to a server that was not running, the connection attempt may have failed
with error code -832 "Found server but communication error occurred".
This has been fixed, the correct error code should be
-100 "Database server not found".
================(Build #3291 - Engineering Case #657823)================
The fix for Engineering case 620136 did not handle the situation where there
was no declared Primary Key in the primary table but there were table, or
column, (not nullable) Unique Constraints that permit the addition of foreign
keys. This problem has been corrected.
================(Build #3290 - Engineering Case #658114)================
The server would have crashed if a SELECT statement useed the FOR XML EXPLICIT
clause, and a null value was used for the CDATA directive. This has been
fixed
================(Build #3290 - Engineering Case #656998)================
Remote queries with many aliases in grouped derived tables may have taken
a long time to execute. This has been fixed.
================(Build #3289 - Engineering Case #657621)================
If a server (S2) acting as mirror saw a dropped connection to the primary
server (S1) after a temporary network outage, it could have attempted to
become primary while S1 was still running. S2 would then have failed during
startup because S1 still owned the alternate server name for the database.
This error would also have caused S2 to shut down. If S1 needed to restart,
it would have been unable to take ownership of the database because S2 was
unavailable and the arbiter's state had been updated to indicate that S2
was the owner.
Also, when a server acting as primary (S1) accepted an inbound connection
from the mirror (S2), S1 attempted to make an asynchronous outbound connection
to S2 if one did not already exist. If this connection attempt failed, S2
would have failed to receive updates from S1.
These problems have now been fixed.
================(Build #3288 - Engineering Case #658302)================
If many contiguous index entries were removed from an index with no intervening
inserts, concurrent snapshot transactions could have seen incorrect results,
and in rare circumstances, foreign rows could have been added without matching
primary rows. This has been fixed.
================(Build #3287 - Engineering Case #658189)================
If a copy node (S3) was starting just as its intermediate node parent (S2)
was receiving pages from the root (S1), S3 could have failed to receive some
of the pages and would have reported a corrupt transaction log file. This
has been fixed.
================(Build #3287 - Engineering Case #658130)================
SQL Anywhere web client procedures were not able to proxy https requests.
This has been fixed.
The following example routes an https request destined for 'securehost'
(default port 443) through a proxy host named 'squid' listening on port 8080:
create or replace procedure test()
URL 'https://securehost/service'
TYPE 'HTTP:GET'
PROXY 'http://squid:8080';
================(Build #3287 - Engineering Case #658121)================
On some Windows machines, attempting to make a TCP connection to a Personal
Server on the same machine may have failed. This has been fixed.
================(Build #3287 - Engineering Case #657987)================
The server could have crashed, or failed assertion 200114, when processing
a LIKE predicate. This has been fixed.
================(Build #3287 - Engineering Case #657812)================
A number of read-only scale-out issues have been fixed.
1) The server could have crashed or otherwise failed in rare cases when
one or more read-only scale-out children were added to a node. This could
have occurred if one node was stopped or restarted.
2) If a parent node was restarted and had a lower log offset than it's child,
the child could have shutdown with the message "Database server shutdown
due to incompatible files for database mirroring." Restarting the child
node after the parent caught up to primary would succeed. Now the child node
no longer stops and the child node will start applying log changes once its
parent gets to a higher log offset.
3) If a parent copy node was started with child nodes already running, a
child node and possibly other nodes could have hung.
4) If a copy node was connected to it's alternate parent, and then it's
alternate parent stopped, the copy node may have stopped applying updates.
The copy should have connected to the primary server to receive updates but
was actually not receiving updates. Note that sa_mirror_server_status may
show that the node which is not receiving updates is connected, when in fact
it was not. Now the copy node will connect to the primary server if neither
the parent nor alternate parent servers are available.
5) An ALTER MIRROR SERVER statement that only changed the alternate parent
was ignored until the server being altered was restarted. For example, if
ServerC had parent ServerB:
ALTER MIRROR SERVER 'ServerC' AS COPY FROM SERVER 'ServerB' OR SERVER
'ServerA'
was ignored by ServerC until it was restarted. Now the alternate parent
is effective on the server being altered once it has applied the log offset
with the ALTER MIRROR SERVER statement.
6) Attempting to SET MIRROR OPTION auto_add_server to the alternate server
name for the primary server incorrectly resulted in an error.
7) If read-only scale-out copy nodes had a primary server as their root
node, and the primary server failed over to the mirror server, then all client
connections to all copy nodes were incorrectly dropped.
================(Build #3285 - Engineering Case #657520)================
In very rare cases, the server asserts with assertion error 102300 "File
associated with given page id is invalid or not open" if request level
debugging is turned on and includes plan logging and there are schema changes
around. This has been fixed. To work around the problem plan caching can
be turned off (option Max_plans_cached = 0) or plan logging can be turned
off (switch -zr without "plan" and "all").
================(Build #3285 - Engineering Case #654801)================
The SQL Anywhere Optimizer may have incorrectly pruned, without costing,
optimal plans during query optimization. This has been fixed. This incorrect
pruning would most probably have affected the final execution plans for
complex, but inexpensive (i.e., the optimal plan has a small runtime) queries.
================(Build #3284 - Engineering Case #657586)================
If a call was made to the Java external environment, and the stored procedure
had an argument of type tinyint and a NULL value was passed in for the tinyint
argument, then the server would have failed the request with a NullPointerException.
It should be noted that the Java VM would continue to run in this situation
and the connection was still able to make subsequent Java external environment
calls. This problem has now been fixed such that passing a NULL tinyint value
to a Java external environment call will result in a byte with zero value
being passed down to the Java method.
================(Build #3284 - Engineering Case #656691)================
If a query was rewritten by the optimizer to use a materialized view, the
query would incorrectly have returned zero rows if a spatial predicate was
applied to the rows originating from the view. This has been fixed.
================(Build #3283 - Engineering Case #656828)================
Adding the CHECK IMMEDIATE REFRESH clause to a CREATE MATERIALIZE VIEW statement
would have caused the server to crash. This has been fixed.
================(Build #3283 - Engineering Case #656264)================
When connected to a database that had the same character set as the OS, and
a query like the following was executed:
SELECT ... FROM dirtab WHERE file_name = '...'
where dirtab was a directory access table and the file_name string literal
contained non-ASCII characters, there was a chance the server would have
crashed. This problem has now been fixed.
================(Build #3282 - Engineering Case #656847)================
If a derived table was joined with the rest of the query using a Join Nested
Loops operator, the performance of the query may have suffered when the derived
table had to be computed many times due to many rows generated by the left
hand side of the Join Nested Loops. The optimizer was choosing such a plan
if the estimated number of rows of the left hand side was very small. If
this estimation was wrong (e.g., the optimizer estimates one row for the
left hand side but in reality the left hand side produces 1,000 rows), the
derived table was computed many, many times during execution. This has been
fixed so that the optimizer considers only Join Hash or Join Sort Merge operators
for the derived tables if it is correct to do so.
================(Build #3282 - Engineering Case #656839)================
If an INSERT or UPDATE statement affecting the value of a spatial column
was canceled, or a run-time error was encountered during execution, there
was a possibility that the server would have failed assertion 112701: "Failed
to convert geometry to EWKB for the redo log -- transaction rolled back [-301]
['40W01']". This has been fixed.
================(Build #3281 - Engineering Case #656650)================
The system procedure sa_db_list() did not validate its database id parameter
if the value was a positive integer. This would have resulted in a single
row result set containing the value provided. Now, if the value is not a
valid database id, the procedure will return an empty result set.
================(Build #3281 - Engineering Case #655981)================
Values for the ApproximateCPUTime property is never expected to decrease
between calls, as it represents an estimate of accumulated CPU time for a
connection. However, for connections that had accumulated approximately
1000 seconds of CPU time, the counter could have periodically receded by
approximately 400 seconds.
================(Build #3279 - Engineering Case #656272)================
The INSERT ON EXISTING SKIP statement did not report the correct number of
inserted and
updated rows using @@rowcount and sqlcount. This has now been corrected.
================(Build #3279 - Engineering Case #655749)================
Execution of an INSERT ... ON EXISTING SKIP statement did not report the
correct number of inserted and updated rows using @@rowcount and sqlcount.
This has been fixed
================(Build #3279 - Engineering Case #654294)================
When canceling a query involving spatial operations, there was a small probability
the server could have crashed, or failed to release resources. This has been
fixed.
================(Build #3278 - Engineering Case #655972)================
The fix for Engineering case 636018 missed a case, which has now been corrected.
Description of case 636018:
Queries involving indexes containing long values could have returned incorrect
results. Index corruption was possible, but not likely..
================(Build #3278 - Engineering Case #654938)================
In rare cases, a corrupt TCP packet could have caused the server to crash.
The server now validates the packet header before do anything with the packet.
If it is corrupt, the packet is dropped.
================(Build #3277 - Engineering Case #655533)================
Under rare circumstances, inserting the result from the Round Earth linestring()
function, or using the linestring() function in a query, could have crashed
the server, if the line string crossed the equator. This has been fixed.
================(Build #3275 - Engineering Case #654790)================
In very rare cases, the server may have crashed with a floating point exception
when slightly loaded. This has been fixed.
================(Build #3273 - Engineering Case #654284)================
The server could have crashed if the STOP SERVER or STOP ENGINE statement
was called from an event or HTTP connection. This has been fixed.
Note that the 'STOP SERVER' syntax is new to version 12 (older servers support
'STOP ENGINE').
================(Build #3273 - Engineering Case #654259)================
The changes for Engineering case 650489 may have caused execution remote
procedure calls to an ASE remote server to fail with a strange "unchained
transaction mode" error. This problem has now been fixed.
================(Build #3272 - Engineering Case #653591)================
Attempting to attach tracing to an older version database file could have
caused the server to crash. This has been fixed so that attempting to attach
tracing to an older version file now returns the error "ATTACH TRACING
could not connect to the tracing database" (-1097).
================(Build #3272 - Engineering Case #556778)================
The return values of the built-in functions user_id() and suser_id() may
have incorrectly been described as not nullable even if the function argument
was not nullable. This may have lead to the assertion error 106901 "Expression
value unexpectedly NULL in write". This has been fixed so that the functions'
results are always described as nullable.
================(Build #3270 - Engineering Case #653245)================
The value for the column "columns" for the system view SYS.SYSFOREIGNKEYS
is generated using a LIST() function, but the function did not include an
ORDER BY and so the result returned could have varied. This has been fixed
by adding an ORDER BY clause.
Note, the system view must be recreated by upgrading or rebuilding the database
for the new view definition to be used.
================(Build #3270 - Engineering Case #652911)================
If an INSTALL JAVA UPDATE statement was executed to update an existing java
class, the server would have incorrectly added a new system object id rather
than reuse the already assigned object id. This problem has now been fixed.
================(Build #3269 - Engineering Case #653590)================
Diagnostic tracing, or application profiling to LOCAL DATABASE could not
be used when the server was started with the command line option -sb 0 (disable
broadcast listener). This has been corrected. A workaround is to manually
supply a connection string (ATTACH TRACING TO <connstr>) with the DoBroadcast=NO
option, rather than using the LOCAL DATABASE clause.
================(Build #3269 - Engineering Case #653588)================
If tracing was suddenly detached (because, for example, the server receiving
the tracing data was shut down) at the same time as a deadlock occurred,
a deadlock victim may have failed to write a ROLLBACK to the transaction
log. This may have lead to an incorrect partial commit of a deadlocked transaction.
This has been fixed. This problem is expected to be very rare.
================(Build #3269 - Engineering Case #635956)================
A query with a CUBE, ROLLUP, or GROUPING SETS clause and HAVING predicates
may have returned an incorrect result set. The query must not have had any
aggregate functions, and the grouping sets must have contained the grand
total which should have been filtered by the HAVING predicates, but instead
it was returned as a valid row.
For example:
select n_comment from nation group by cube (n_comment) HAVING n_comment
like 'alw%';
The result set would have contained all the rows with n_comment for which
the predicate "n_comment LIKE 'alw%' is TRUE, but also the row "(NULL)".
This has now been fixed.
================(Build #3268 - Engineering Case #652592)================
Attempting to connect to a read-only scale-out database with a non-ASCII
database name using the NODETYPE connection parameter could have incorrectly
failed with a "Specified database not found" error. The database
name was being sent back in either OS-charset or DB-charset, but the client
needed it to be in client-charset. This has now been fixed.
================(Build #3267 - Engineering Case #652791)================
If a statement for a directory access table failed with the error SQLSTATE_OMNI_REMOTE_ERROR,
and this statement was the last statement of the transaction then all subsequent
remote server statements of this connection would have failed with the same
error. This has been fixed.
================(Build #3267 - Engineering Case #652759)================
If a table was included in a MobiLink publication and one or more options
were defined for that publication, but there were no synchronization subscriptions
defined, the table could not be ALTERed to, for example, add a new column.
This has been fixed.
================(Build #3267 - Engineering Case #652756)================
When validating a table that contained spatial data on 32-bit x86 systems
where the processor did not support the SSE2 instruction set (the minimum
required for SA spatial features), the database server would have reported
a non-fatal assertion error
113300 or 113302 "failed to build cursor to validate". This problem
has been fixed and the underlying error is now reported: SQL error (-1515)
-- Support for spatial is not available for this CPU.
================(Build #3267 - Engineering Case #651294)================
When starting a 32-bit server with a large initial number of request tasks
(-gn option), the server could have failed to start by reporting an error,
crashing or quietly exiting. This problem has been fixed by reducing the
maximum cache size to accommodate the address space needed for the stacks
of the request tasks.
================(Build #3266 - Engineering Case #652587)================
When running a database without a transaction log, performance could have
been significantly slower than in previous versions. This problem has been
corrected. See Engineering case 608904 for a similar issue..
================(Build #3266 - Engineering Case #652543)================
The server may have crashed during inserts into a view, if the view column
was not a base table column. This has been fixed. Now the correct error SQLSTATE_NON_UPDATEABLE_VIEW
is returned.
================(Build #3265 - Engineering Case #651694)================
If the connections between servers in a mirroring system used encryption,
the primary server could have hung when performing an operation which required
exclusive access to the database (e.g. a checkpoint) if other update activity
was also occurring. This has been fixed.
================(Build #3264 - Engineering Case #652107)================
If a foreign key had both ON UPDATE and ON DELETE actions, renaming a column
referenced by the foreign key could have caused one of the system triggers
to be deleted and the other to be left unchanged. A trigger for an ON UPDATE
action could have been converted to an ON DELETE action. This has been fixed.
================(Build #3264 - Engineering Case #651846)================
On Windows systems, the performance monitor might not have displayed counter
values provided by the server. Typically this would have happened when a
shared memory client that was attached to the server terminated abnormally.
Counter values should not display for subsequent servers until all processes
holding handles to the dead server (e.g. shared memory clients) are terminated.
This has been fixed.
================(Build #3263 - Engineering Case #651658)================
On Windows systems, SQL Anywhere provides a version 1 (registry) performance
provider. Windows should generate WMI classes automatically after the counter
dll is registered, but these classes were generated only after instances
of these objects (i.e. server, database and connection) existed in a process
running in session 0 (i.e. as a service in Vista and up). This has been
fixed.
================(Build #3262 - Engineering Case #651323)================
When the distance between two ST_Points exceeded the spatial reference system's
tolerance by at least a factor of 1, but less than a factor of sqrt(2), the
spatial relations ST_Equals and ST_Intersects could have incorrectly returned
TRUE. This has been fixed.
================(Build #3262 - Engineering Case #651169)================
If a database containing a table with a uniqueidentifier column was unloaded
using the Unload utility (dbunload) with one of the external unload options
(-xi or -xx), and the resulting reload.sql script was executed using the
Interactive SQL utility, a conversion error would have been reported. This
has been fixed. A workaround is to avoid using -xx or -xi when rebuilding
the database.
================(Build #3262 - Engineering Case #650337)================
Queries with an outer join having the same base table as the preserved and
null-supplying sides could have returned incorrect result sets. Conditions
where this could happen:
1. the outer join is of the form : T as T1 LEFT OUTER JOIN T as T2 ON(p)
2. the ON predicate p has only equijoins, and at least two equijoins
3. p is of the form : T1.c1 = T2.c1 and T1.c3 = T2.c2
4. there exists an unique index on T < c1,c2>
This has been fixed.
================(Build #3261 - Engineering Case #650740)================
Execution of a DROP DATABASE statement would have failed if the automatically
generated database alias name was an invalid identifier. This has been fixed.
================(Build #3261 - Engineering Case #650690)================
The server would have returned assertion failed 100905 "Articles on
the table use do not match those on the table definition", if a table
had publications and a simple INSERT with multiple row value constructors
was executed. For example: insert into tab1 values (1,'a'),(2,'b'). This
has been fixed.
================(Build #3153 - Engineering Case #647077)================
When run on Mac OS X systems, the server would have exited with the error
"Failed to
become daemon" if both the -um and -ud command line options were specified.
This was due
to a limitation in the OS X GUI infrastructure. This has been fixed. The
-um flag is now ignored if -ud is specified.
A workaround is to use dbspawn instead of -ud.
================(Build #3750 - Engineering Case #711705)================
After creating a directory access server that used the new for 12.0.1 "{varname}"
syntax in the USING clause, Sybase Central could have crashed when attempting
to open the Directory Access Servers folder. This has been fixed.
================(Build #3747 - Engineering Case #711499)================
If Sybase Central encountered an internal error, and the user elected to
send a report to Sybase, they would get a message saying that the report
could not be sent, even if it was. This problem also occurred with the Interactive
SQL utility, the Console utility, or the MobiLink Monitor, and has been fixed.
================(Build #3739 - Engineering Case #709633)================
W@hen clicking the column heading of the Current, Average or Maximum columns
on the Performance Monitor tab, the corresponding values would have been
sorted as strings, not as numeric values. Now the values are sorted numerically.
In addition, the values are now right-aligned.
================(Build #3733 - Engineering Case #708422)================
If a user owned one or more tables, views, procedures or sequence generators,
and permissions on these objects were assigned to another user, then deleting
the first user could have caused Sybase Central to crash. This has been fixed.
================(Build #3731 - Engineering Case #707971)================
The Compare Databases window would have reported ALTER LOGIN POLICY as an
unrecognized statement. This has been corrected.
================(Build #3718 - Engineering Case #699351)================
When connecting to an SQL Anywhere database from Sybase Central or the Interactive
SQL utility, a standard connection dialog is displayed to gather connection
options. On the Identification page of that dialog there is a drop-down named
"Authentication". When "Windows Integrated Login" was
chosen in the drop-down the choice was ignored and the value "Database"
was used instead. This has been fixed.
================(Build #3712 - Engineering Case #703102)================
When comparing two databases, running the generated script in Interactive
SQL would have caused syntax errors to be reported if the script contained
Transact-SQL statements. This has been fixed.
================(Build #3557 - Engineering Case #696640)================
Attempting to create a maintenance plan with a single quote in its name would
have failed. The plan's name is used in a generated SQL statement. If the
name contained a single quote, then the generated statement would not have
executed. Any single quotes in the name are now doubled-up before including
it in the generated statement.
================(Build #3557 - Engineering Case #696631)================
Attempting to create a maintenance plan, or test the email settings for a
maintenance plan, would have failed when running on a French machine. This
has been fixed.
================(Build #3533 - Engineering Case #694466)================
The Compare Databases window could have reported syntactically-distinct,
yet semantically-equivalent, differences between the two databases. The differences
were limited to the ordering of the following:
1. Authorities for a user or group
2. Option name-value pairs for a login policy
3. Tables for a publication
4. Columns for an article
5. Option name-value pairs for a mirror server
In all of the above cases, the ordering was irrelevant; however, the tool
could have reported differences because the comparison could have generated
random orderings.
For example:
GRANT CONNECT,DBA,RESOURCE TO "DBA" IDENTIFIED BY ...
vs:
GRANT CONNECT,RESOURCE,DBA TO "DBA" IDENTIFIED BY ...
These have been fixed. The comparison now provides a consistent ordering
as follows:
1. User and group authorities are ordered by authority name.
2. Login policy options are ordered by option name.
3. Publication tables are ordered first by user name, then by table name.
4. Article columns are ordered by column id.
5. Mirror server options are ordered by option name.
================(Build #3527 - Engineering Case #694480)================
Selecting a tenant database's Login Mappings folder in the tree would have
caused an error. This has been fixed.
================(Build #3527 - Engineering Case #694468)================
Attempting to compare a tenant database with another database would have
caused Sybase Central to crash. This has been fixed.
================(Build #3514 - Engineering Case #691736)================
When connected to a version 11 or earlier database, clicking the database's
Overview panel would have displayed a "Table 'sysmirrorserver' not found"
error. This has been fixed. A check of database version has now been added
before querying the SYS.SYSMIRRORSERVER table.
================(Build #3507 - Engineering Case #681082)================
If deployment of a synchronization model to a consolidated database stopped
progressing because another database connection was blocking it, clicking
Cancel would have caused Sybase Central to become unresponsive, even after
the blocking from the other connection ended. This has been fixed.
================(Build #3492 - Engineering Case #689233)================
Opening a procedure in a new window, deleting the procedure from the main
Sybase Central window, and then attempting to save the procedure from the
new window, would have caused Sybase Central to crash. The same problem occurred
for views, functions, triggers and events. These issues have been fixed.
================(Build #3461 - Engineering Case #685299)================
The "Overview" panel for a database shows the HTTP and HTTPS ports
which its server is using. If both HTTP and HTTPS were used, and the server's
-xs command line option was sufficiently complex, the reported port numbers
would have been incorrect. Typically, they were more than 6 digits long.
Now, the correct port numbers are displayed.
================(Build #3423 - Engineering Case #681931)================
When looking at the commands in a deployed task, the "On failure"
setting for each command was displayed as "Abort task", even for
those commands with different "On failure" settings. This has
been fixed. The correct "On failure" setting is now shown for each
command.
================(Build #3423 - Engineering Case #681928)================
A command can be added to a remote task by selecting the task, then clicking
the "Add Command" toolbar button or menu item. If a command is
then selected in the "Commands" tab, the new command appears on
the row following the selected row. This command was not actually added to
the task at that position, instead, it was always added to the end of the
command list. This has been fixed so that the new command actually follows
the selected command.
This problem could have made it appear as if the order of commands changed
when a remote task was deployed, if the remote task was deployed shortly
after adding a command. In fact, the ordering of the commands was incorrect
immediately after the command was added. If Sybase Central was started and
the task was viewed without deploying it, the added command would have been
at the end of the command list.
================(Build #3415 - Engineering Case #680760)================
When viewing extended options for a synchronization profile, publication,
MobiLink user, or synchronization subscription, the values for the MobiLinkPwd
and NewMobiLinkPwd extended options could have been seen in plain text from
their tooltips. Now, no tooltips are shown for these values.
================(Build #3415 - Engineering Case #680755)================
Sybase Central could have crashed when selecting a global temporary table
in the tree, then selecting the Data tab in the right-pane and attempting
to insert a row into the table. The crash would only have occurred if the
table's commit action was DELETE ROWS. This has been fixed so that the Data
tab is no longer shown for a GLOBAL TEMPORARY table unless its data is SHARE
BY ALL.
================(Build #3415 - Engineering Case #676363)================
When attempting to use Sybase Central to create a proxy table for an Access
database, and the remote server used the 'MSACCESSODBC' server class, the
following error would have been displayed:
[Sybase][ODBC Driver][Adaptive Server Anywhere]Server '<server-name>':
[Microsoft][ODBC Driver Manager] Driver does not support this function (-660)
A call was being made to SQLPrimaryKeys() to determine which columns in
the table belong to the primary key. Access does not support this function,
so this error is now ignored for the 'MSACCESSODBC' server class.
================(Build #3387 - Engineering Case #675894)================
In Sybase Central, you can generate HTML documentation for a database to
which you are connected. That documentation includes cross-reference information
for stored procedures -- a list of procedures a given procedure calls, and
a list of the procedures which call the given procedure. This cross-reference
information was not being generated for those stored procedures which used
the Transact SQL dialect. Cross-reference information for procedures which
used the SQL Anywhere dialect were generated fine. This has been fixed so
that cross-reference information is generated for stored procedures that
are written using either dialect.
================(Build #3376 - Engineering Case #674243)================
The text completer in the Interactive SQL utility and Sybase Central usually
suggests SQL statements (e.g. DELETE,INSERT,SELECT) when starting to typing
a statement. There was a problem that prevented statements from being suggested
when typing a new statement if there was already a statement on a later line,
and there was no command delimiter (i.e. a semicolon) between the new statement
and the existing one. In this case, only matching SQL keywords and database
object names would be suggested. This has been fixed.
================(Build #3339 - Engineering Case #667675)================
After the Database Documentation Wizard completed, a prompt asked whether
to view the generated documentation. If "Yes" was clicked, a browser
window was supposed to open to show the documentation, but the browser failed
to open if the path to the generated files contained a space. This has now
been fixed.
================(Build #3327 - Engineering Case #666024)================
Using Sybase Central's searching capabilities to search in a Version 11.0
or earlier database would have caused Sybase Central to crash. This has been
fixed.
================(Build #3327 - Engineering Case #666013)================
Using Sybase Central's searching capabilities to search for a single backslash
would have caused Sybase Central to crash. This has been fixed.
================(Build #3297 - Engineering Case #660656)================
After updating an external environment object via File->Update..., the
object's Contents tab would not always have reflected the changes made to
the object. This has been fixed.
================(Build #3292 - Engineering Case #659177)================
If a non-initialized materialized view or text index was selected in the
tree and the Data tab was selected in the right-pane, then attempting to
switch from one mode (Design, Debug or Application Profiling) to another
would have caused a refresh of the materialized view or text index to be
prompted for twice. This has been corrected so that there is now only one
prompt.
================(Build #3279 - Engineering Case #656454)================
When connected to a database that contained one or more publications, and
the property sheet for a Publication was opened and an Article was selected
in the "Subscribe by restriction" tab, the Editor pane at the bottom
of the tab would have been disabled except when the 'expression' radio button
was checked. When the Editor pane was disabled it was still possible to right
click on it to reveal a pop-up menu that allowed for search and replace in
the box. The menu is now disabled when the Edit pane is disabled.
================(Build #3278 - Engineering Case #655945)================
On the database Fragmentation tab, the shortcuts for Zoom In (Ctrl++) and
Zoom Out (Ctrl+-) did not work with the numeric keypad. This has been fixed.
================(Build #3278 - Engineering Case #644464)================
If a database had two or more 'post_login_procedure' option settings, then
attempting to connect to the database would have failed with a "Subquery
cannot return more than one row" error. This has been fixed.
================(Build #3273 - Engineering Case #654249)================
The External Environments folder was erroneously including an entry for dbmlsync.
This has been fixed.
================(Build #3266 - Engineering Case #652547)================
Altering the schedule for an event to remove a days-of-month specification
did not set SYSSCHEDULE.days_of_month to null. This has been fixed.
================(Build #3264 - Engineering Case #651520)================
Displaying the results of an Index Consultant run of a large workload could
have required an excessive amount of memory, causing Sybase Central to crash
if there was not enough physical memory available. This has been fixed.
================(Build #3262 - Engineering Case #651723)================
Opening a column's Property sheet would have caused the error: "Support
for spatial is not available for this CPU", when the server was run
on a system with on a Pentium III processor. The same error would also have
occurred in the Function and Domain wizards, and the Spatial Reference Systems
folder if it was selected in the tree. These issues have been fixed.
================(Build #3769 - Engineering Case #715480)================
When using the Unload utility to rebuild a pre-version 10 database, if the
connection string contained the server name or the source database name,
then the warning 'Rebuild of database with older file format ignoring connection
parameter "???"' was printed with question marks for the parameter.
This has been fixed so that the parameter name is now displayed in the message.
================(Build #3753 - Engineering Case #712618)================
Setting the isql_allow_read_client_file or isql_allow_write_client_file options
in the Interactive SQL utility to 'on' or 'off' had no effect. Interactive
SQL would always behave as if the option was 'prompt'. This has been fixed.
================(Build #3751 - Engineering Case #711977)================
The help screen for several SQL Anywhere utilities (viewcert, createcert,
dbcloudadd, dbcloudextract, and dbcloudcmd) tried to format the output for
terminal display by splitting at 80 characters. When multi-byte characters
were used, the splitting could have happened in the middle of a character,
causing that character to display incorrectly. This also affected general
output from the dbcloudcmd. This has now been corrected.
================(Build #3748 - Engineering Case #711146)================
The Interactive SQL utility has an option to control which result sets from
a query to display; just the first one, or all of them. If "Show all
result sets" was selected, the widths of columns in the table on the
"Results" panels were not automatically sized to show the data.
If "Show only the first result set" was selected (which is the
default), the columns were automatically sized correctly. This has been corrected.
================(Build #3746 - Engineering Case #711377)================
The text completer for the UltraLite function ML_GET_SERVER_NOTIFICATION
would have completed the text as ML_GET_SERVIER_NOTIFICATION (note the extra
"I" in "SERVER"). This has been fixed.
================(Build #3744 - Engineering Case #711034)================
The START DATABASE statement includes the following optional clause:
CHECKSUM { ON | OFF }
Attempting to execute a START DATABASE statement in the Interactive SQL
utility with this clause would have resulted in an inappropriate error message
which complained of an unexpected keyword. This has been fixed.
Engineering Description:
The CHECKSUM clause was added in 12.0.0. I'm not sure how this got missed.
I noticed the omission when I started to look at adding support for the new
MIRROR ON clause of START DATABASE.
Behaviour Changes:
n/a
Admin Tools, Installers and Other Affected Software:
n/a
Documentation Changes:
n/a
Testing Requirements:
A test was added to the ISQL grammar test suite.
================(Build #3744 - Engineering Case #711000)================
If an invalid value was given for a network protocol option on the Interactive
SQL command line, the program could have reported an internal error. This
would have happened only for those options which take a set of specific values.
For example, running the following command would have crashed as "bogus"
is not an allowable value for the "DoBroadcast" option.
dbisql -c "links=tcpip(DoBroadcast=bogus)"
This problem has been fixed.
================(Build #3744 - Engineering Case #707010)================
In the table of query results, cell values, entire rows, and entire columns,
can be copied to the clipboard. When copying a column or multiple cells,
the values were always separated by a comma rather than the ISQL field separator
string. This has been corrected so that the field separator is now used.
Note that the field separator was already being used when copying entire
rows of values.
================(Build #3744 - Engineering Case #689907)================
The Interactive SQL utility would not have reported an error if an unknown
encoding name was used in the READ statement's ENCODING clause. This has
been corrected so that now it does.
================(Build #3738 - Engineering Case #709639)================
On Solaris 11 systems, the default quitting time suggested by the Console
utility is one hour later than the current time if daylight savings time
is in effect. The solution to this problem is to update the Java Runtime
Environment to version 1.6.0_31 or later. Instructions for doing this are
contained in a white paper called "Updating the SQL Anywhere Java Runtime
Environment", available from the Sybase web site:
http://www.sybase.com/detail?id=1058536
There are no code changes for this issue. Note, that this problem does not
occur with Solaris 10.
================(Build #3736 - Engineering Case #709208)================
If an INI file was used with the Windows launchers for the Interactive SQL
utility, Sybase Central, MobiLink Monitor, the Console utility, or SQL Anywhere
Monitor, and the VM arguments exceeded 260 chars, the launcher would have
fail. This has been fixed.
================(Build #3709 - Engineering Case #702774)================
When connected to a database which was mirrored, the server name displayed
in the Interactive SQL title bar and the server name printed by the DESCRIBE
CONNECTION statement, was inadvertently the alternate server name, rather
than the main server name. The alternate server names tend to be long and
end in a long sequence of letters and numbers. This has been corrected so
that the main server name is now always used.
================(Build #3548 - Engineering Case #667179)================
The Start Server in Background utility (dbspawn), when used with -p option
to specify the OS process id, was reporting a process id for the started
server of 0 on Windows Vista, Windows 7 and Windows 2008. Windows XP, Windows
2003 and Unix were not affected. This has been fixed so that the process
id of the started server is reported correctly.
================(Build #3535 - Engineering Case #694489)================
If a connect to a cloud tenant database was made in the Interactive SQL utility,
or Sybase Central, by selecting an action of "Connect to a running database
in a cloud" in the "Connect" dialog, and then the connection
was disconnected, opening the "Connect" dialog again would not
have had the "Action" box initially set to "Connect to a running
database in a cloud". This has been corrected so that now it is.
================(Build #3533 - Engineering Case #693999)================
When using the Unload utility (dbunload), if an APPINFO connection parameter
was specified for the source database (-c option), the APPINFO value was
ignored and a warning message printed stating such. This bahaviour has now
been changed, the APPINFO value is now passed to the source database and
a warning message is printed stating that the rebuild may fail if the source
database has an older file format (version 9.0 or older). Connections to
the target database (-ac option) are unaffected by this change. Both the
previous and new behaviour is to pass the APPINFO value to the target database.
================(Build #3525 - Engineering Case #692376)================
After the changes for Engineering case 666434 ("dbisqlc could report
errors when using output redirection for nested READ statements"), dbisqlc
did not always correctly close all files opened for READ statements. If enough
files were opened for READ statements during a session, dbisqlc could have
reported "too many open files". This problem has been fixed.
================(Build #3513 - Engineering Case #691215)================
Different system catalog views, DESCRIBE, and the dbunload schema information,
showed different base type names for the domain Signed Integer. The base
type names shown were "int" or "integer". This has been
fixed. Now the base type name "integer" is consistently returned.
================(Build #3512 - Engineering Case #692249)================
On Mac OS X 10.7 Lion, the Java administration tools (Sybase Central, Interactive
SQL, etc) would have silently failed if Java was not installed. Previous
versions of Mac OS X included a Java runtime, but on Lion it is a separately
installed component.
Use the following method to initiate the Java runtime installation or confirm
it is currently installed:
1.Go to Applications > Utilities > Java Preferences.
2.Open the Java Preferences.
3.If Java is not installed, you receive the following message:
“To open “Java Preferences," you need a Java runtime. Would you like
to install one now?”
4.Click Install and follow the prompts. The Java runtime is downloaded and
installed.
================(Build #3512 - Engineering Case #691657)================
When using the Deployment Wizard, a temporary list of files is generated
to pass over to makecab.exe based on the temporary directory path (%TMP%);
e.g. makecab.exe /F C:\DOCUME~1\user\Local Settings\Temp\1\sql6.tmp. If the
%TMP% variable contained a space, this would not work correctly, although
the MSI file would still have been generated, but it would not have contained
the necessary files. This has been fixed.
================(Build #3491 - Engineering Case #689167)================
After using the "Find" button to find a network server, the message
"You cannot use the Host connection parameter and advanced network
parameters at the same time." could have been returned, even though
nothing was specified on the "Network" tab. For this problem to
have occurred, the "Action" field had to have been set initially
to "Connect to a running database on nother computer". The problem
would not have occurred if the "Action" value had been changed
prior to clicking the "Connect" button. This has been fixed.
In a related issue, the above error message should have been displayed,
but was not, in a number of other cases. This has also been fixed.
================(Build #3477 - Engineering Case #685205)================
When unloading a database, comments for unique constraints were not included
in the reload.sql file. This has been fixed.
================(Build #3466 - Engineering Case #685857)================
When inserting a value into a FLOAT column, an error would have been given
if the absolute value of the number was too big, or too close to zero. This
has been fixed. Now, an error will only be given if the absolute value of
the number is too big. If the number is too close to zero, it will be set
to zero and inserted without an error.
================(Build #3465 - Engineering Case #685873)================
When using the Service utility (dbsvc) for Windows to delete a service that
was currently running, the following messages were displayed:
The specified service is running. The service will be deleted when it is
stopped.
Service "<svc name>" was deleted successfully.
This has been fixed. If the service is running, only the first message is
displayed, otherwise only the second is displayed.
================(Build #3449 - Engineering Case #680770)================
When unloading a database, GRANT INTEGRATED/KERBEROS statements containing
square brackets were written in the reload.sql file. These statements would
have would have generated an 'unexpected statement' error when executed.
This has been fixed by always putting double quotes rather than square brackets
around the user identifier.
================(Build #3448 - Engineering Case #683704)================
Whenever the Server Licensing utility (dblic) was used with the -k option
(to specify a new registration key), the registration key was being written
to the license file. This should not have been done for add-on keys such
as the High Availability option, and has now been corrected.
================(Build #3433 - Engineering Case #683177)================
The Interactive SQL utility would have crashed if the "Show progress
messages" option was modified in the "Options" window while
not connected to a database. This has been fixed.
================(Build #3418 - Engineering Case #680917)================
Interactive SQL contains a number of menu items for selecting the current,
previous, and next statements. These menu items could hale selected more
than just the statement text, or could have selected nothing at all if the
statement being selected included the text "IF NOT EXISTS".
For example:
CREATE TABLE IF NOT EXISTS t ( c INT PRIMARY KEY )
This has been fixed. Now, statements are selected properly.
This same problem also affected the behavior of the "Single Step"
menu item which also relies on being able to select the next statement.
================(Build #3413 - Engineering Case #680348)================
When the Text Completer completes a table, view, or procedure name, the owner
name is now added if the name would be ambiguous without it. Previously,
the owner name could have been added when it wasn't necessary. This has
been fixed.
================(Build #3409 - Engineering Case #679415)================
Reloading a database that contained a table that referenced a sequence could
have failed. This has been fixed.
As a work around, the "Create sequences" section could be manually
moved to before the "Create tables" section in the reload.sql file.
================(Build #3409 - Engineering Case #676224)================
If a database had a publication defined using the "download only"
or "scripted upload" clauses, but had not defined any synchronization
users or synchronization subscriptions, then when a dbunload was run on the
database, the "download only" or "scripted upload" clauses
of the publication would not have been maintained. This problem has been
fixed.
A workaround to this issue would be to add any synchronization user or synchronization
subscriptions to the database. For example, if a publication "p1"
was defined for download only, execute "CREATE SYNCHRONIZATION SUBSCRIPTION
TO p1 TYPE 'tcpip'". This would define TCP/IP as the default communication
type when synchronizing the publication, which is the default that would
be chosen anyway.
================(Build #3405 - Engineering Case #676727)================
When editing a TIMESTAMP column value in the "Results" panel, the
editor did not distinguish between AM and PM, always assuming AM. This has
been corrected so that the editor now distinguishes between the two.
================(Build #3400 - Engineering Case #676844)================
Attempting to perform an unload with reload of a database, using the Unload
utility or the dbtools DBUnload function, may have failed with a "Cannot
find index named ...' error if the index had a comment. This problem has
now been fixed.
================(Build #3391 - Engineering Case #674748)================
Attempting to unload and reload a SQL Anywhere database from version 10.0.0
and later could have failed if the database contained a large number of integrated
logins, and several of the integrated logins had comments associated with
them. This problem has now been fixed.
================(Build #3388 - Engineering Case #676033)================
When a statement cannot be executed by the Interactive SQL utility, the error
is displayed in an error window. That window contains a "Help"
button which, which clicked, can display a menu of relevant help topics (for
the error message and for the type of statement being executed). Opening
this error window could have taken a non-trivial amount of time if the online
documentation for SQL Anywhere was not installed. In those cases, the software
had to check with the DocComment Exchange (DCX) server to see if help was
available for the statement in question. While the Interactive SQL utility
is doing this check, it could be unresponsive. The problem was most acute
on machines that were not connected to the internet at all. This has been
fixed so that the error dialog opens without delay, and Interactive SQL remains
responsive at all times.
================(Build #3385 - Engineering Case #675496)================
Explicitly opening the Text Completer when the "SQL Statements"
field contained only matching parentheses would have caused the Interactive
SQL utility to crash. This has been fixed.
================(Build #3383 - Engineering Case #675147)================
The Interactive SQl utility's Import wizard usually remembers the names of
recently-imported files and presents them in the combo-boxes where a file
can be selected to import. A bug was preventing the list of file names from
being remembered. This has been fixed.
================(Build #3382 - Engineering Case #674931)================
The 32-bit versions of Sybase Central, the Interactive SQL utility, the Console
utility, and the MobiLink Monitor, could have failed to start on 32-bit Windows
systems under "low" memory conditions. The point at which memory
becomes low is difficult to quantify, and depends heavily on the number of
other programs running on the machine, and their locations in memory. This
has been fixed.
As part of this change, the message that is displayed when the Java Virtual
Machine can't start has been improved to include the actual JVM error.
================(Build #3375 - Engineering Case #674024)================
The toolbar buttons in the Interactive SQL utility were not enabled if a
stored procedure was executed from Sybase Central and the procedure completed
with errors. This has been corrected so that the toolbar buttons are now
enabled correctly.
================(Build #3374 - Engineering Case #674063)================
When typing a single-line SQL comment, the Text Completer could have opened
while typing. This has been corrected so that the Text Completer remains
hidden unless it is explicitly opened.
================(Build #3374 - Engineering Case #673852)================
With both 32 bit and 64 bit versions of SQL Anywhere installed on a 64 bit
Windows system, using the Deployment wizard to create a 32 bit install would
have displayed the 64-bit UltraLite feature. Attempting to install the MSI
that was created in this way on a 32-bit Windows system would have caused
the following error:
Module C:\Program Files\SQL Anywhere 12\BIN64\ulodbc12.dll failed to register.
HRESULT -2147024703. Contact your support personnel.
This has been fixed.
================(Build #3368 - Engineering Case #669572)================
If the Service utility (dbsvc) was used to shut down a service, and the service
took a long time to shut down, dbsvc may have reported that an error occurred.
For example, if checkpointing one of the databases took longer than 3 seconds.
The server would still have shut down eventually. This has been fixed.
================(Build #3364 - Engineering Case #669412)================
When run on Linux systems, the Service utility (dbsvc) requires the LSB init-functions.
Some Linux distributions do not installed by default so the must be installed
manually in order to use dbsvc
For example, on Fedora, run the following command:
yum install redhat-lsb redhat-lsb.i686
================(Build #3363 - Engineering Case #672088)================
The Extraction utility could have incorrectly extracted an event from a consolidated
database for a user that would be not be created in the remote database.
This has now been corrected.
================(Build #3354 - Engineering Case #670521)================
Attempting to modify NCHAR, NVARCHAR or LONG NVARCHAR values, using the scrolling
table in the "Results" panel, would have silently failed if the
value was loaded from a file. This has been fixed.
================(Build #3353 - Engineering Case #669783)================
The Update Checker could have informed that there were updates, even when
it had been asked not to. Specifically, if there had been a new documentation
release (in a new language, say), and the Uupdate Checker had been configured
to not show informational messages, you would still have been notified.
This has been fixed.
================(Build #3351 - Engineering Case #670020)================
The Support utility (dbsupport) may have silently failed to submit diagnostic
information if it was a first-time submission. This has been fixed.
================(Build #3350 - Engineering Case #669411)================
When run on some Linux distributions, the Interactive SQL utility (or any
of the graphical administration tools) may not have displayed Chinese characters
correctly. This has been fixed.
Workaround:
1. Shut down any graphical administration tools (Sybase Central, Interactive
SQL (dbisql), the MobiLink Monitor, SQL Anywhere Monitor, or SQL Anywhere
Console utility (dbconsole) that are running.
2. Run the following commands:
mkdir $SQLANY12/sun/jre160_x86/lib/fonts/fallback
ln -s /usr/share/fonts/truetype/arphic/*.ttc $SQLANY12/sun/jre160_x86/lib/fonts/fallback
ln -s /usr/share/fonts/truetype/wqy/*.ttc $SQLANY12/sun/jre160_x86/lib/fonts/fallback
================(Build #3347 - Engineering Case #669218)================
Using an encrypted command file did not work on big endian computers (typically
running Solaris or AIX). The symptom was an error message "Could not
decrypt command file." This has been fixed.
================(Build #3344 - Engineering Case #666960)================
When connected to an ASE database, the "Help" menu could have contained
redundant separators. This has been fixed.
================(Build #3343 - Engineering Case #668397)================
The SQL Passthrough feature was removed in version 12 and three associated
tables (sync_passthrough_progress, sync_passthrough_script, and sync_passthrough_status)
were dropped. The Unload utility did not properly handle the case where a
pre-version 12 database contained these tables and they were not empty. This
has been fixed.
================(Build #3340 - Engineering Case #667932)================
For a table with no foreign keys, SQLForeignKeys would have returned a single
row with NULLs in most columns. This problem could have resulted in a java.lang.NullPointerException
in the Interactive SQL utility's Query Editor. This has been fixed so that
when the table has no foreign keys, no rows will be returned.
================(Build #3329 - Engineering Case #666434)================
When using output redirection for a READ statement that referenced a file
containing another READ statement, the dbisqlc utility would have reported
an error such as "invalid file number". This problem has been corrected.
Example: "READ file1.sql >& output.txt"
file1.sql:
read file2.sql
go
SELECT ...
file2.sql:
SELECT ...
================(Build #3329 - Engineering Case #665710)================
When executing a SELECT statement such as "(select 1)" that begins
with open parenthesis, the dbisqlc utility would have reported a syntax error.
This problem has been fixed.
================(Build #3327 - Engineering Case #665673)================
If the Interactive SQL utility was launched from a program using the Apache
Portable Runtime, and standard output and/or standard error file handles
were redirected, an internal error could have been reported. This has been
fixed.
================(Build #3326 - Engineering Case #663937)================
In the Interactive SQL utility, setting the "on_error" option to
"continue" was not preventing warnings from being displayed in
a popup window. This has been corrected so that when the option is set to
"continue", warnings are now displayed in the "Messages"
pane.
================(Build #3325 - Engineering Case #665670)================
The execution tree in the Plan Viewer window could have partially obscured
the bottom part of the tree drawing if a display option for the plan was
changed to make it larger (by turning on "Show percent cost", for
example). This has been fixed.
================(Build #3324 - Engineering Case #637476)================
Importing data from a database that was not a SQL Anywhere or UltraLite database
into an UltraLite database, using the Interactive SQL INPUT statement or
the Import Wizard, could have failed. This would have occurred if a new table
was to be created for the imported data and the data contained one or more
INTEGER columns. This has been fixed.
================(Build #3321 - Engineering Case #662766)================
When using the Deployment wizard to build an MSI install containing both
64-bit and 32-bit software, the jvm.dll in the sun\jre160_x64\bin\server
directory was being replaced by the 32-bit version. This could have occurred
whenever two different files were included with the same name, in a directory
with the same name, and with the same parent directory. This has been corrected.
================(Build #3314 - Engineering Case #637446)================
Exporting TIME values to a DB2 database with an OUTPUT USING statement in
the Interactive SQL utility would have failed. This has been fixed.
================(Build #3311 - Engineering Case #663786)================
The Server Enumeration utility (dblocate) may have failed to list some running
database servers if many (over around 50) servers were running in the TCP/IP
subnet. This problem was more likely if the -d option ("brief list
of databases running on each server"). This has been fixed by increasing
the UDP receive buffer size used by dblocate. For some Unix/Linux operating
systems, in order for this change to take effect, the system maximum UDP
receive buffer size may need to be increased. On Linux, this can be done
by increasing the sysctl net.core.rmem_max setting.
================(Build #3308 - Engineering Case #663279)================
Clicking the "Stop" toolbar button in the Interactive SQL utility
often did not stop execution if many short-running statements were being
executed. It did work correctly if executing a single long-running statement.
This has been fixed.
The workaround for this problem is to use the SQL->Stop menu item, which
always works.
================(Build #3305 - Engineering Case #663123)================
Creating an ODBC data source for IQ from the Connect dialog did create a
DSN, but it was not created correctly. The following issues have been fixed:
1. The driver name for the data source was always "SQL Anywhere 12"
rather than "Sybase IQ". This prevented the data source from being
listed in the "Data Source Names" window unless you checked "Show
all data sources". Also, to connect using the data source, the SQL
Anywhere ODBC driver had to be installed.
2. Creating a system data source would fail on machines that did not have
"dbdsn" installed. This would be a problem on computers running
Vista or Windows 7 which have IQ installed, but not SQL Anywhere.
================(Build #3304 - Engineering Case #662944)================
On Mac OS X, the tool tips for the "zoom in", "zoom out",
"reset view", and "save image" buttons in the "Value
of Column" dialog indicated that the Control key should be held down
to activate the button. This was incorrect, it should have shown the Command
key. This has now been fixed.
================(Build #3303 - Engineering Case #656680)================
The Interactive SQL utility could have become unresponsive when executing
a statement which returned a result set if the entire result set cannot be
returned due to a row lock. This has been fixed.
================(Build #3301 - Engineering Case #662233)================
The connection properties on the Advanced page of the Connect dialog were
not filled when attempting to reconnect following a disconnect. For this
problem to have occurred, the IQ plug-in for the Interactive SQL utility
would needed to have been loaded. That plug-in is loaded by default starting
in version 12.0.1.
A similar problem affected the TLS packet encryption parameters on the Network
page.
Both of these problems have now been fixed.
================(Build #3295 - Engineering Case #660005)================
If a file was opened in the Interactive SQL utility and then the window was
closed, the file would still have been locked by the dbisql process if the
"Enable fast launcher" option was on. This has been fixed.
================(Build #3292 - Engineering Case #659337)================
SQL changes in the Plan Viewer and Spatial Viewer windows were ignored if
the Editor component had been selected, "Options" was clicked and
then dismissed by clicking "OK". This has been fixed.
This issue had at least one other symptom: If a file was opened, "Options"
for the editor was selected, either by right-clicking as described above
or by opening the Options window, then clicked "OK", subsequent
changes in the Editor would not have caused the Interactive SQL utility's
window title text to include an asterisk. The asterisk indicates that there
are unsaved changes in the editor.
================(Build #3292 - Engineering Case #659140)================
The text completer may not have suggested any matches if there was an empty
single quoted string earlier in the statement, or in a previous statement.
This has been fixed.
================(Build #3289 - Engineering Case #658334)================
If a database option value contained a single quote, the reload script generated
by the Unload utility would have resulted in a syntax error when the database
was reloaded. This has been fixed.
================(Build #3286 - Engineering Case #653316)================
When deleting rows from an UltraLite database, the Interactive SQL utility
would have incorrectly reported the number of rows affected by a DELETE.
The message "1 row(s) deleted" would have been shown in the Message
pane, regardless of how many rows were deleted. This has been fixed.
================(Build #3285 - Engineering Case #657324)================
Installations created by the Deployment wizard were to be missing the following
files from the assembly\v2\ directory:
iAnywhere.Mobilink.Client.dll
iAnywhere.QAnywhere.Client.dll
iAnywhere.QAnywhere.Resources.dll
iAnywhere.QAnywhere.ws.dll
These files were being installed in the Global Assembly Cache (GAC), but
an additional copy was not also put in the assembly\v2 directory. This has
been corrected so that these files are now installed in both locations.
================(Build #3281 - Engineering Case #658169)================
When using the Service utility (dbsvc) for Linux to create an automatic service
(when the machine boots) on Linux SUSE 11 for the SQL Anywhere server, the
server may have started before the network service had been started. As a
result, some applications running inside the SQL Anywhere server may have
failed to work properly. This issue would have affected SQL Anywhere Server
Monitor deployments. This has been fixed.
================(Build #3281 - Engineering Case #656897)================
Attempting to execute a SQL statement that was made up only of full-width
space characters (U+3000, the "Ideographic Space") would have caused
the Interactive SQL utility to crash. This has been fixed.
================(Build #3278 - Engineering Case #637456)================
Attempting to import NCHAR types from ASE using the INPUT statement or the
Import Wizard, would have failed with the message "Cannot convert ''
to a varbit". This has been fixed.
================(Build #3278 - Engineering Case #631019)================
Two issues relating to using the INPUT and OUTPUT statements (and their corresponding
wizards) to move data between SQL Anywhere and ASE have been fixed.
Importing a table from ASE which had TIMESTAMP columns into a new table
would have failed. The ASE TIMESTAMP type was being misinterpreted as being
equivalent to the SQL Anywhere TIMESTAMP type, which is false.
Exporting data from SQL Anywhere into ASE would have reported various conversion
issues for SQL Anywhere DECIMAL values.
================(Build #3277 - Engineering Case #655607)================
The text in the Favorites sidebar could have disappeared if the mouse was
moved over it. This has been fixed.
================(Build #3275 - Engineering Case #654981)================
The Console utility could have stopped refreshing connection properties after
changing the set of properties which were displayed, even after restarting
DBConsole. This has been fixed.
================(Build #3274 - Engineering Case #654636)================
Opening a .saplan file in the "Plan Viewer" window and clicking
the "Print" button did not do anything. This has been corrected
so that it prints the plan. There was no problem printing plans which were
generated by clicking the "Get Plan" button.
================(Build #3274 - Engineering Case #654635)================
If HTMLHelp documentation for SQL Anywhere was installed, it was possible
for the Index Consultant to open DCX help under some circumstances. This
has been fixed.
================(Build #3274 - Engineering Case #654425)================
In the Options window, the components for editing the quitting time were
enabled even if the "Quitting time" checkbox was not checked. Now,
the components are disabled when the checkbox is not checked.
================(Build #3274 - Engineering Case #654253)================
In versions of the Interactive SQL utility 10.0.0 and later, using an ISQL
parameter for the value of an option in a SET OPTION statement did not work
because the parameter was not substituted correctly. This has been fixed.
================(Build #3270 - Engineering Case #653743)================
The Import wizard would have reported an internal error when importing a
shapefile if no spatial reference system was selected. This has been fixed.
================(Build #3762 - Engineering Case #714654)================
If a cloud database became unavailable, and it was being monitored by the
SQL Anywhere Monitor, the alert details would have claimed the server name
to be 'null'. This has been fixed.
================(Build #3746 - Engineering Case #711380)================
In the SQL Anywhere Monitor, the sparkline for a metric was usually drawn
empty. This has now been fixed.
================(Build #3605 - Engineering Case #701635)================
Creation of a SAMonitor resource to monitor Relay Server farms via HTTPS
may have failed, while HTTP worked. This would have happened when the Relay
Server address specified in the Relay Server configuration file was missing
the domain suffix. Even when the load balancer address given to the SAMonitor
was a FQDN, the resource creation may have failed. This has now been fixed
by making the monitor attempt its best effort to apply the domain suffix
of the load balancer to the Relay Server address when it is missing while
HTTPS is in use. If any of the Relay Server addresses, or the load balancer
address, are specified in IPv6 or IPv4 numeric notation, then this fix will
not kicks in and authentication will continue to fail. Use of FQDNs is required
by the SAMonitor when HTTPS is used.
================(Build #3531 - Engineering Case #693900)================
The SQL Anywhere Monitor database gathers monitoring data over time, and
this data is reduced according to the maintenance settings. If data reduction
settings allowed more data to be gathered than the default settings, when
the maintenance plan did run it may not have been able to successfully prune
the gathered data. This has been fixed.
================(Build #3478 - Engineering Case #687567)================
The SQL Anywhere Monitor may have missed counting some uncommon Relay Server
errors. These errors were:
FARM_CHANNEL_CONNECT_WITH_INVALID_SERVER_IDX 2006
SERVER_DISCONNECT_EARLY 3014
FARM_FAIL_ACCESS 12000
SERVER_FAIL_NEWING_CLIENT_STATISTIC 13011
This has been fixed.
================(Build #3472 - Engineering Case #686586)================
A lengthy Relay Server alert may have been corrupted by having extra non-break
space tokens ( ) broken up by exclamation marks. This has been fixed.
================(Build #3353 - Engineering Case #669738)================
The memory used by the Java process spawned by the SQL Anywhere Monitor could
have grown without bound if there were MobiLink collectors. It would have
grown faster when the MobiLink servers were consistently unreachable. This
has been fixed.
================(Build #3342 - Engineering Case #668136)================
An SQL Anywhere resource may have generated an alert for "No Recent
Backup Recorded", even though a client-side backup had recently been
done. This has been corrected so that the alert now clearly indicates that
it pertains to server-side backups only.
================(Build #3328 - Engineering Case #666566)================
After performing an unload of a resource database, the SQL Anywhere Monitor
server console would have shown 'Permission denied' errors for serveral system
procedures. Graphing the metrics for "free disk space" would have
displayed incorrect values (a horizontal line as if nothing changed). This
is caused by the server policy to preserve permissions granted or revoked
on objects owned by dbo user that are created in a newly initialized database.
The following describe the steps required to correct this whenever an unload
of a database is performed:
1. log in to SQL Anywhere Monitor Web UI as the user 'administrator'.
2. click Administrator on the left pane to open an Administrator dialog
3. under Resource tab, select the resource that had been dbunloaded
4. click Stop button to stop monitoring the resource
5. click Repair... and enter DBA uid/pwd to repair the resource database
6. after done, click Start to start monitoring the DB
After the above steps, the resource should function correctly.
================(Build #3315 - Engineering Case #664506)================
Steady Relay Server metrics, like peak values, values associated with idle
farms, and idle error counts, may not have shown correctly in graphs inside
the SQL Anywhere Monitor. The work around is to view them as current values
instead of graphing. This issue has been fixed.
================(Build #3310 - Engineering Case #663573)================
The SQL Anywhere Monitor's server console, would have shown the following
incorrect error message:
[Sybase][JDBC Driver][SQL Anywhere]Could not load dynamic library 'dbsrvmon11'
(SQLCODE: -620, SQLSTATE: HY000)
An incorrect version number being assigned when a monitor object was removed.
This has been fixed.
================(Build #3304 - Engineering Case #662942)================
Charting metric data may have omitted some ending data points. This has been
fixed.
================(Build #3288 - Engineering Case #658458)================
When editing options for configuration, but not editing Data Reduction, a
warning message for Data Reduction was displayed. This has been fixed.
================(Build #3284 - Engineering Case #657448)================
The aggregated time increment used to calculate the following metrics were
not divided by the request count increment before plotting to the graphs:
"Average Request time"
"Average Backend server processing time"
"Average Response time"
"Average Request Completion time"
The problem has been fixed.
================(Build #3281 - Engineering Case #656660)================
During a Relay Server outage, the SQL Anywhere Monitor did not display the
the "Unavailable since" time, but cleared the "Up since"
time only. A farm outage alert was also not raised. Only a sustained outage
alert was raised after the threshold time elapsed. When the Relay Server
came back up again, data collection did not resume and the "Up since"
time was not updated. These problems have now been fixed.
================(Build #3281 - Engineering Case #656645)================
Dates shown in the Graph widget were localized but not in the correct order
(they showed "MM DD" instead of "DD MM"). This has been
fixed.
================(Build #3277 - Engineering Case #655599)================
It was not possible to drag and drop the second operators in the Add Resource
page. This has been fixed.
================(Build #3277 - Engineering Case #655570)================
The tab order on the Edit Configuration:Maintenance tab was not correct..
This has been fixed.
================(Build #3277 - Engineering Case #655544)================
The 'Next' button and the 'Create' button were disabled in the Add Resource
page when an invalid time was entered. This has been fixed.
================(Build #3764 - Engineering Case #714642)================
If SQL Remote had failed to find a publisher for the database it was connected
to, it would have continued to run and could have generated a large number
of duplicate messages for a single remote user. This has been corrected so
that SQL Remote will now shut down when it determines there is no publisher.
================(Build #3433 - Engineering Case #683159)================
When SQL Remote was running in continuous mode, if the max_retries message
system parameter had been set, and a message was generated because the maximum
size of the message had been reached before the next send phase, then SQL
Remote would have incorrectly believed that an error had occurred when sending
the message. SQL Remote would then have paused for the number of seconds
specified by the pause_after_failure message system parameter. This problem
has now been fixed.
================(Build #3365 - Engineering Case #672208)================
The changes for Engineering case 655157 introduced a problem such that when
multiple consecutive pinging messages appeared in the incoming message box,
SQL
Remote would have generated the warning message:
Deleting duplicate message from ...
and then deleted the duplicate pinging messages.
This problem is fixed so that all the duplicate pinging messages are now
processed without complaint.
================(Build #3527 - Engineering Case #693255)================
If the publisher's address for a database contained a UNC path, or if the
address for a remote user contained a UNC path, the Unload and Extraction
utilities would have failed to escape the string properly, resulting in an
address in the new database with missing backslash characters. This has
now been fixed.
================(Build #3411 - Engineering Case #679803)================
SQL Remote would have generated the following error message:
"The address given is invalid. The address must be a directory name
with no path separators."
and then aborted the message receiving thread when it was able to retrieve
all the names of the message files in the given directory from a FTP server,
but for some reasons (such as network problems) was not able to retrieve
the contents of a file from the server. This problem is fixed so that the
error message is now:
"Unable to retrieve message file 'xxxx' from the FTP server."
================(Build #3405 - Engineering Case #678597)================
When running in a continuous mode, SQL Remote would have leaked about 10
kilobytes of memory in every attempt of sending messages to its subscribers.
This problem has now been fixed.
================(Build #3367 - Engineering Case #667109)================
If SQL remote (dbremote) was running in continuous mode, it was possible
for it to have have reported "Execution Complete", but no errors
or warnings would have been printed to the dbremote log indicating why the
process had stopped. This has been fixed.
================(Build #3297 - Engineering Case #660813)================
If the database was blank padded and the database option Compression was
set to be -1, .SQL Remote would have logged the following warning message
in its output file:
Option DBA.Compression contains invalid value -1
The value -1 is a valid value, it was the blank padding that was causing
the option to be treated as invalid. This problem has been fixed.
================(Build #3278 - Engineering Case #656093)================
The Log Translation utility (dbtran) and SQL Remote could left temporary
files undeleted after execution. This has been fixed.
================(Build #3277 - Engineering Case #655351)================
Temporary files created by SQL Remote and Log Translation utility may not
have been deleted. This problem has been fixed.
================(Build #3407 - Engineering Case #677800)================
When editing the SQL for a web service in the service's Property sheet, if
the Text Completer was open when the Property sheet was closed, Sybase Central
would have reported an internal error. This has been fixed.
================(Build #3404 - Engineering Case #678229)================
If the remote database schema in a synchronization was updated from an existing
remote database that had the same schema, except for the case of identifiers
(such as table names or owner names), errors could have resulted. The table
mappings would have become invalid, clicking on such a table mapping would
have caused an unexpected error dialog, and script generation errors could
have occurred. This has been corrected.
================(Build #3340 - Engineering Case #667934)================
The attempt to add a second primary key was not diagnosed in an ALTER TABLE
statement. This has been corrected.
================(Build #3718 - Engineering Case #704611)================
An index on a binary column could have become corrupt if it contained binary
values shorter than the hash size for the table. This has been fixed.
================(Build #3715 - Engineering Case #703801)================
HTTPS synchronizations using iOS 5 to a Windows (or Linux) Mobilink server,
could have failed with secure handshake errors. The synchronization would
have worked to a Mac OS X Mobilink server. This is now fixed.
================(Build #3709 - Engineering Case #702761)================
Synchronizations would have failed if the length of the parameter string
for a sync profile was larger than 64K. The error reported could have varied,
but SQLE_SYNC_INFO_INVALID would have been most likely. This error could
have occurred with the .NET API if the application set sync authentication
parameters whose total length approached or exceeded 64K. This problem has
now been corrected.
================(Build #3589 - Engineering Case #699971)================
The index hash for Timestamp with Time Zone columns was not properly incorporating
the offset component. This could have lead to an incorrect ordering of timestamp
values that had
varying timezone offsets. This has been fixed.
================(Build #3588 - Engineering Case #699839)================
A hashing algorithm used to speed the access to rows with indexes involving
timestamp with time zone columns, in rare conditions, could have performed
slightly worse than optimal. This has been fixed.
================(Build #3584 - Engineering Case #699687)================
The UltraLite runtime now supports RSA TLS and HTTPS on Pocket PC 2003 devices.
There is no support for ECC or FIPS.
================(Build #3572 - Engineering Case #698048)================
When using Xcode 4.2 and running armv6 code (i.e., after enabling armv6 and
running on 'iPhone 3G' or earlier), UltraLite may have corrupted double (floating
point) values stored in the database. This has been fixed. As this seemed
to be a compiler issue, it may be better to use an older version of Xcode
when targeting these older armv6 devices. Note that switching between Clang
and LLVM-GCC will not resolve this issue.
A workaround has been implemented to avoid the problem with double values,
but the above note still applies.
================(Build #3567 - Engineering Case #697464)================
A synchronization using end-to-end encryption could have crashed on the iPhone.
This has been fixed.
================(Build #3558 - Engineering Case #696667)================
Upgrading an UltraLite database schema by executing "ALTER DATABASE
SCHEMA FROM FILE", could have resulted in corrupt indexes. This has
been fixed.
================(Build #3493 - Engineering Case #688896)================
If an application crashed during synchronization it was possible that subsequent
sync attempts would have failed with server errors. The MobiLink server would
have reported a progress mismatch and the log could have shown multiple instances
of the same publications. This has been fixed.
================(Build #3490 - Engineering Case #689047)================
An HTTP or HTTPS synchronization through the Relay Server could have failed
with stream error STREAM_ERROR_HTTP_HEADER_PARSE_ERROR. This has been fixed.
================(Build #3488 - Engineering Case #676102)================
Inserting Unicode strings into a database using an MBCS/ANSI encoding (that
is, not UTF-8) could have resulted in corruption of the strings and possibly
unbounded store growth. Unicode strings are inserted using the wchar methods
in the C++ API, or using .NET. The Unicode conversion routines to and from
wchar were not correct and have been fixed.
================(Build #3486 - Engineering Case #688468)================
The UltraLite runtime library for iPhone would have failed to build with
recent Xcode/SDKs (Xcode 4.2 with iOS 5.0 SDK, for example), as gcc-4.2 was
no longer being shipped (the command wais not found while trying to run build.sh).
This has been fixed by having the UltraLite runtime makefile now simply use
'gcc'.
This problem can be worked-around by creating a symlink for gcc-4.2 ->
gcc in the /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin and similar
Simulator directories, or by modifying the makefile or build.sh used by UltraLite.
================(Build #3461 - Engineering Case #685284)================
If a synchronization failed during the upload, subsequent changes to the
database would not have been uploaded in the next synchronization, but in
the synchronization after that. This has been fixed.
================(Build #3437 - Engineering Case #683555)================
The UltraLite Database Unload utility (ulunload) would not have preserved
the download-only table attribute when unloading a database. This has been
corrected.
================(Build #3437 - Engineering Case #683552)================
If an UltraLite application was suddenly terminated (application crash, device
reset, etc.) while a transaction was in progress, and the partial transaction
was flushed to the database file by another commit or checkpoint, rows were
not properly rolled back on subsequent restart. This has now been corrected.
================(Build #3422 - Engineering Case #681956)================
Calling the ULConnection methods SetSyncInfo() or ULSetSynchInfo() with a
ul_sync_info, where both the auth_parms and additional_parms were non-null,
would have created a sync profile where one of the additional_parms had been
made into an auth_parm. This has been fixed.
================(Build #3419 - Engineering Case #681424)================
On Windows Mobile devices, calling GetStringLength(), on a ULValue returned
from any of the schema methods in ulcpp11.cpp, could have returned 0 even
if it was a valid non-zero length string. This has been fixed.
================(Build #3374 - Engineering Case #673856)================
Sometimes the TLS internal communication error (220) was reported without
a useful system error code (e.g. Certicom error code) for further analysis.
This has been corrected.
================(Build #3363 - Engineering Case #672094)================
Renaming a table that was marked as no-sync or all-sync would have changed
it to a normal synchronizing table if the new name didn't have the "_nosync"
or "_allsync" suffix. This has been fixed. The table will now
retain its old sync type unless the previous name did have one of the special
suffixes ("_nosync", "_allsync", and "_download_only")
and the new name does not since a change to the sync type is implied by the
removal of the special suffix.
================(Build #3348 - Engineering Case #668396)================
Join queries with predicates in the WHERE or ON clauses that involved columns
not in indexes have now been improved.
================(Build #3315 - Engineering Case #664633)================
A synchronization using FIPS end-to-end-encryption could have corrupted a
FIPS encrypted UltraLite database. This has been corrected.
================(Build #3302 - Engineering Case #662477)================
When resuming a download, the sent and received statistics are restored from
the previous sync and continue as expected from that point, except the byte
counts, which were reset to zero. This has now been fixed. The byte counts
(like the row statistics) are cumulative for resumed downloads. These statistics
are available to the synchronization observer callback and are contained
in the sync-results object.
================(Build #3300 - Engineering Case #662074)================
The following UltraLite resumable-download problems are now fixed:
In rare cases, UltraLite incorrectly computed where to resume the download.
When this occurred, the subsequently resumed download was effectively corrupted,
likely causing a synchronization error. (To recover, the download must have
been rolled back.)
When resuming a download, the server continued to use the original 'timeout'
specification, but UltraLite used the default. If a non-default timeout value
was specified, the resumed download may have timed out even though the network
connection was fine (though it still maked progress).
Sometimes the sync-info (or sync-result) 'partial_download_retained' flag
was false after trying to resume a download when there was still a partial
download present. (Workaround is to only make use of this flag when first
set - attempting to subsequently resume when there is no partial download
is safe and returns an error.)
As well, the following problem is fixed:
The COMMITTING_DOWNLOAD sync observer state was signaled later than it should
have been. The observer saw UltraLite was still receiving the download, when
in fact it had begun committing the download.
================(Build #3295 - Engineering Case #660263)================
Incorrect results were possible for a deeply nested (at least a depth of
three) aggregate subquery. This has been corrected.
================(Build #3295 - Engineering Case #659922)================
A syntax error could have been incorrectly generated for an outer reference
occurring in a subquery containing another nested subquery, where the outer
reference was to the right of the nested subquery. This has been corrected.
================(Build #3290 - Engineering Case #658549)================
Result set rows could have been presented in an incorrect order when all
of the following conditions were present for a SQL query:
- An index existed in which the first column (say col1) was specified to
be in descending order
- The query contained a search condition of the form "col1 LIKE expression"
where the expression started with non-wildcard characters.
- The query contained an ORDER BY starting with col1
This has been corrected.
================(Build #3275 - Engineering Case #654684)================
References to derived table columns may have been incorrect when temporary
tables were present and the derived table was used to load the temporary
table. This has been corrected.
================(Build #3275 - Engineering Case #654648)================
The substr() function was permitting LONG VARCHAR values to be used as the
first argument to the function. This has been corrected
================(Build #3272 - Engineering Case #653884)================
The Mobilink Server would have logged the error "Light weight poll request
failed" after every poll attempt from an Ultralite client (through the
use of the ML_GET_SERVER_NOTIFICATION function), even if the polls were actually
successful. This has been fixed
================(Build #3530 - Engineering Case #693690)================
When the 'CustDB' sample was loaded into Xcode 4.2, several warnings would
have been reported. Even after this change, there will still be a prompt
to remove the obsolete 'PREBINDING' build setting. It is recommended that
this build setting be removed. The other warnings have been addressed. The
most significant change is that the project format has been upgraded to Xcode
3.2-compatible format. Some other minor enhancements have also been made
to the sample, such as specifying the UltraLite temp_dir. See the DataAccess
class' openConnection method for more details.
================(Build #3529 - Engineering Case #693569)================
When the 'Names' sample was loaded into Xcode 4.2, several warnings would
have been reported. Even after this change, there will still be a prompt
to remove the obsolete 'PREBINDING' build setting. It is recommended that
this build setting be removed. The other warnings have been addressed. The
most significant change is that the project format has been upgraded to Xcode
3.2-compatible format. Some other minor enhancements have also been made
to the sample, such as specifying the UltraLite temp_dir. See the DataAccess
class' openConnection method for more details.
================(Build #3328 - Engineering Case #666232)================
The "Go To Table" and "Go To Foreign Key" menu items
for the ER Diagram tab did not always work. The "Go To Table" menu
item did nothing if the database tree node was collapsed. The "Go To
Foreign Key" menu item did not work at all. These have now been fixed.
================(Build #3298 - Engineering Case #661008)================
Right-clicking on an UltraLite database in the UltraLite Sybase Central plug-in,
will show a list of database properties, one of which is the database file
name. If the file name contained multi-byte characters, they could have been
displayed as mangled characters. This has now been fixed.
================(Build #3294 - Engineering Case #659866)================
If an invalid value was specified for the "(other)" parameter on
the Synchronization Profile property sheet, then it was not possible to clear
this invalid value unless the property sheet was closed and F5 was pressed.
This has now been fixed.
================(Build #3279 - Engineering Case #656087)================
When connecting from Sybase Central to an UltraLite database with multi-byte
characters in its file name, the database name would have appeared with mangled
characters. This has been fixed.
================(Build #3265 - Engineering Case #652188)================
When a table was selected in the tree and the Indexes tab was shown in the
right pane, there was no File -> New -> Index... menu item. As such,
it was only possible to start the Index wizard from the toolbar button. This
has been fixed.
================(Build #3518 - Engineering Case #689910)================
Extra rows were returned when executing a query using UNION where the subqueries
contained joins with ON conditions. This has now been fixed.
================(Build #3492 - Engineering Case #688720)================
UltraLite could have returned fewer rows than expected for queries utilizing
an index scan with conditions on multiple columns in the index. This has
now been fixed.
================(Build #3496 - Engineering Case #685163)================
For version 12.0, the methods ResultSet.getString() and ULTable.getString()
would have returned an empty string for columns that were null. Earlier versions
would have correctly returned a 'null'. These methods have been corrected
so that they now return results consistent with the prior versions.
================(Build #3491 - Engineering Case #686519)================
Calling PreparedStatement.setBytesParameter would have truncated a byte array
with more than 32k elements. This has been fixed.
Note, it is recommended that large binary parameters be set using PreparedStatement.appendBytesParameter().
================(Build #3453 - Engineering Case #683813)================
The methods Connection.getNewUUID() and ULPodUUID.toString() were removed
in version 12.0 as a result of the introduction of equivalent SQL functions.
These methods have been reintroduced. As a workaround the system functions
newid() and uuidtostr() can be used.
Documentation:
Connection::getNewUUID method
Returns a new UUID value.
Syntax
UUID getNewUUID()
example:
uuid = conn.getNewUUID();
SQLType.toString method
Returns the string name of the specified SQL column type constant or BAD_SQL_TYPE
if not a recognized type.
Syntax
String toString(UInt16 code)
Parameters
code The SQL column type constant.
example:
uuid_str = conn.getNewUUID().toString();
================(Build #3370 - Engineering Case #672372)================
Execution of an ALTER DATABASE SCHEMA FROM FILE statement may have failed
with a SQLE_SCRIPT_MISSING_DELIMITER error when using a SQL file generated
from ulunload or ulinit. This has been fixed.
================(Build #3281 - Engineering Case #656844)================
ULPod may have caused AvantGo clients to crash when calling the method TableAGDBSet
getTableAGDBSet. This has been fixed.
================(Build #3484 - Engineering Case #684277)================
Accessing result set or table columns, via streaming methods like ULResultSet::GetStringChunk
in C++, could have returned unexpected values when the actual value was null,
so checking explicitly to see if the value is null (ULResultSet::IsNull)
was essential. This issue has been addressed by ensuring empty strings are
now returned in this case. Proper handling of null values still requires
an explicit check to differentiate between null and empty strings though.
================(Build #3447 - Engineering Case #675048)================
An application attempting to update a blob column on a result set by calling
ULResultSet::AppendByteChunk (ULResultSet.AppendBytes in .NET) would have
crashed. The crash wouldn't have occurred when updating a blob column using
an UPDATE statement or a ULTable object. In .NET, this problem would have
appearred as a System.AccessViolationException. This has been fixed.
Also, when attempting to update a blob column that was NULL using a ULTable
object, the column value would have remained NULL. This has also been fixed.
================(Build #3412 - Engineering Case #680218)================
Calling ULConnection.SetSyncListener would have internally launched a thread
that would never terminate. This could have prevented Windows Mobile applications
from completely shutting down. This has been fixed.
================(Build #3409 - Engineering Case #679436)================
After returning false from the SyncProgressed method, or calling CancelSynchronize
to cancel a synchronization, it was possible that the Synchronize or EndSynchronize
call would have hung. This has been fixed.
Also, the ULSyncProgressData.FLAG_IS_BLOCKING flag could have been set erroneously
when the state was ULSyncProgressData.STATE_CANCELLED. This too has been
fixed.
================(Build #3326 - Engineering Case #664507)================
ULDataAdapter class may have reported the error SQLE_TOO_MANY_TEMP_TABLES
even if the Dispose() method was invoked. This has been fixed.
================(Build #3275 - Engineering Case #653158)================
The methods ULConnection.CountUploadRows, ULConnection.GetLastDownloadTime,
and ULConnection.ResetLastDownloadTime would have failed on Windows desktop
when provided named publications instead of ULConnection.SYNC_ALL_DB. This
has been fixed.
================(Build #3301 - Engineering Case #661930)================
In some cases, the UltraLite Database Unload utility (ulunload) would have
generated foreign keys in its XML output file that were not really in the
database being unloaded. This has been fixed.
================(Build #3274 - Engineering Case #653467)================
If an UltraLite database had a table with a LONG VARCHAR column, and that
column contained XML data, attempting to view that data in the Interactive
SQL utility's cell editor (in the XML Outline tab) could have failed with
the error: "An invalid XML character (Unicode: 0x0) was found in the
element content of the document". This is now fixed.
================(Build #3764 - Engineering Case #713899)================
A query with a reverse index scan on the left hand side of a join may have
resulted in a null pointer exception.
For example:
CREATE TABLE t1( a1 INT PRIMARY KEY )
CREATE TABLE t2( a2 INT PRIMARY KEY )
SELECT t1.a1, t2.a2 FROM t1, t2 ORDER BY t1.a1 DESC
Also, a query with a reverse index scan on the right hand side of a cross
join may not have returned any rows.
For example:
SELECT t1.a1, dt.a FROM t1, (SELECT a2 FROM t2 ORDER BY a2 DESC) AS dt(
a ) ORDER BY t1.a1 ASC
Both these issues have now been fixed.
================(Build #3759 - Engineering Case #713695)================
The fault tolerant HTTP processing in UltraLiteJ for Java 2 Platform Standard
Edition (J2SE) did not work correctly. This has been fixed.
================(Build #3741 - Engineering Case #708660)================
If a URL suffix had a leading '/', the URL formed would have been [http|https]://host-name:port-number//url-suffix.
This could result in an synchronization error. This differs from UltraLite
which ensures that the '/' is not added when there is an leading '.' in
the URL suffix. This has been fixed, the leading character of the url_suffix
is checked and a '/' is appended only if needed
================(Build #3729 - Engineering Case #707362)================
On BlackBerry devices, and the simulator, when using HTTPS UltraLiteJ would
have done an extra HTTPS POST request at the beginning of a synchronization
to verify the contents of a certificate. This extra POST was not needed
when the StreamHTTPSParms used in the synchronization had null CertificateCompany,
CertificateName and CertificateUnit (all three null). This has been fixed.
UltraLiteJ now will only do the extra POST if one or more of CertificateCompany,
CertificateName and/or CertificateUnit are not null.
================(Build #3723 - Engineering Case #705854)================
With UltraLiteJ for Android, calling the PreparedStatement.set() method when
the PreparedStatement had already been closed would have crashed the application.
This has been fixed. Now, a ULjException with code SQLE_ULTRALITE_OBJ_CLOSED
is thrown.
================(Build #3721 - Engineering Case #705696)================
With UltraLiteJ for Android, a binary column value with a length greater
than or equal to 64 KB would have been truncated when using PreparedStatement.set(int,
byte[]) to set the value for an INSERT or UPDATE statement. This has been
fixed.
A workaround is to use PreparedStatement.getBlobOutputStream(int) to get
an OutputStream object, and use that to write the parameter value.
================(Build #3719 - Engineering Case #704967)================
With UltraLiteJ for Android, calling Connection.prepareStatement with a null
statement parameter would have crashed the application. This has been fixed
so that a ULjException with code SQLE_INVALID_PARAMETER is now thrown.
================(Build #3718 - Engineering Case #704600)================
In some circumstances, an index may have become corrupted after a DELETE.
An index must have had Index Hashing turned on to be affected. This has been
fixed.
================(Build #3714 - Engineering Case #703819)================
Rows with null values in BINARY(x) or UNIQUEIDENTIFIER columns, or small
binary values in BINARY(x) columns (for example a 2 byte binary value stored
in a column declared BINARY(512)), would have used more memory than necessary.
This has been fixed.
================(Build #3714 - Engineering Case #703780)================
If a download for a particular table contained two rows with the same primary
key value, UltraLiteJ would have thrown an exception with the warning SQLE_DUPLICATE_ROW_FOUND_IN_DOWNLOAD.
This may have confused users into believing the download continued, when
in fact the download had been rolled back. This has been fixed. UltraLiteJ
now throws SQLE_PRIMARY_KEY_NOT_UNIQUE.
================(Build #3713 - Engineering Case #703785)================
With UltraLiteJ for Android, DatabaseManager.release() had undesirable effects
- it may have caused erratic behaviour when the application was relaunched
after it was used when the application closes after initial launch. This
has been fixed.
================(Build #3713 - Engineering Case #703450)================
Columns containing TIME values were not properly hashed in indexes. Although
values were correctly ordered, they were not as efficient. This has been
fixed.
================(Build #3582 - Engineering Case #699393)================
With UltraLiteJ for Android, closing a PreparedStatement after its Connection
object had been released caused the application to crash. The same was true
for a ResultSet object. This has been fixed so that a ULjException with
error code -908 "Invalid operation on a closed object" is now thrown.
================(Build #3569 - Engineering Case #697638)================
With UltraLiteJ for Android, it was not possible to retrieve the SQLCODE
of the last executed SQL statement if it was a warning (ie. SQLCODE was greater
than 0). This has been fixed. The method Connection.getLastWarning() has
been added for Android only. This method returns a SQLInfo object, from
which can be obtained the SQL code and a localized message. If the last
SQL statement resulted in a SQL error code, a ULjException is thrown, as
before.
================(Build #3553 - Engineering Case #696272)================
With UltraLiteJ for Android, calling SyncParms.setLivenessTimeout(n) had
no effect. This has been fixed. Now the liveness timeout value for the synchronization
connection is set to n seconds.
Note, the default liveness timeout for synchronization and file transfer
connections is 100 seconds for BlackBerry, J2SE and J2ME platforms, and 240
seconds (the default for UltraLite/MobiLink) for Android platforms.
================(Build #3540 - Engineering Case #695214)================
With UltraLiteJ for Android, a ULjException with code -735 (Invalid parameter)
was thrown when using PreparedStatement.set() to set a String parameter with
UTF-8 encoded length greater than or equal to 32 KB. This has been fixed.
A workaround is to use PreparedStatement.getClobWriter() to get a Writer
object, and use that to write the parameter value.
================(Build #3512 - Engineering Case #691589)================
1. ALTER TABLE would have allowed the addition of a UNIQUE constraint with
nullable columns. This would have resulted in corruption of row store for
the table, and would have lead to ArrayIndexOutOfBounds exceptions or corrupt
data being read.
2. ALTER TABLE ADD constraint would not have added existing table rows to
the new index. SELECT with ORDER BY using the new constraint would have
returned less rows, and it was possible to INSERT rows that violated the
constraint.
3. ALTER TABLE ALTER column would not have properly modified the column
definition.
4. ALTER TABLE ADD column, DROP column or ALTER column, would have corrupted
the in-memory state when lazy loading, resulting in SQLE_ERROR in subsequent
operations on a given table.
All the above issues have been corrected.
================(Build #3508 - Engineering Case #691207)================
An ArrayIndexOutOfBoundsException could have occurred when reconnecting to
an UltraLiteJ database if a previous connection had used a large amount of
storage for temporary tables. This has been fixed.
================(Build #3505 - Engineering Case #690291)================
An UltraLiteJ database that was created from a file using the method DatabaseManager.importDatabaseFile()
could have been invalid in rare circumstances. The circumstances in which
this was more likely were when the page size of the database was small (1
KB or less). This has been fixed.
================(Build #3505 - Engineering Case #676668)================
Values in long binary and long varchar columns may have become corrupted
when used in temporary tables. This may have manifested itself as incorrect
values read, or ArrayIndexOutOfBounds exceptions, when values were read or
when rows containing these values are deleted or updated. This has been fixed.
================(Build #3501 - Engineering Case #690393)================
The changes for Engineering cases 673184 and 673184 may have caused non-lazy
loading databases to encounter SQLE_ERROR and ArrayIndexOutOfBounds. This
has been fixed.
================(Build #3496 - Engineering Case #689943)================
With UltraLiteJ, committing a SQL statement that updated a table containing
a large BLOB or CLOB could have caused an ArrayIndexOutOfBoundsException.
This has been fixed.
================(Build #3487 - Engineering Case #674467)================
Queries that contained a predicate where an expression was 'greater than
or equal to' or less than or equal to' the minimum value for a column, would
have returned a result set that included rows where that column was null
(if rows with null exist in the table). Moreover, the HASH SIZE for the
indexed column must have been large enough to fully hash the indexed value.
For example, if x is of type signed integer and there are rows in T where
x is NULL, and there is an index on x with max hash size 4, then the following
statement would have returned a result set that included rows where X is
NULL:
SELECT * FROM T WHERE x >= -2147483648
This has now been fixed.
================(Build #3486 - Engineering Case #688459)================
Queries that use temporary tables could have produced incorrect results when
UltraLiteJ was configured with row limitations (i.e. using ConfigPersistent.setRowScoreMaximum
or ConfigPersistent.setRowScoreFlushSize). This has been fixed.
================(Build #3484 - Engineering Case #688272)================
If an INSERT or an UPDATE failed, due to a unique constraint violation for
example, a row may have been left behind in the store. This would have resulted
it unrecoverable database growth. This has been fixed.
================(Build #3484 - Engineering Case #686869)================
When a database page was reused, the unused portion of the page was not always
set to zeros, possibly resulting in exposure of decrypted data when that
page was written out. This has now been corrected.
================(Build #3484 - Engineering Case #681837)================
Doing a large number of download deletes when under extreme row limiting
conditions may have resulted in an ArrayIndexOutOfBounds exception. This
has been fixed.
================(Build #3484 - Engineering Case #680036)================
In a heavy indexing environment (many rows * many cursors with small row
limiting values and small cache size relative to number of index pages in
the database), a synchronization of many download deletes may have become
stuck while committing the download. Sometimes, on the BlackBerry OS it
would have caused a system wide ForcedStackTrace exception. These have been
fixed.
================(Build #3484 - Engineering Case #678600)================
When downloading rows with multiple LONG BINARY or LONG VARCHAR columns,
they may have been corrupted when earlier clob/blob columns were null. This
could have then resulted in a variety of errors including reading random
values.
For example, if a table was defined as:
CREATE TABLE t(
c1 INT PRIMARY KEY,
c2 LONG VARCHAR,
c3 LONG VARCHAR )
and the row[ 1, null, 'b' ] was downloaded, reading c3 would have failed.
Rows [2, 'a', 'b'], [3, 'a', null ] and [4, null, null ] would have been
okay.
This has been fixed.
================(Build #3483 - Engineering Case #676092)================
During download deletes, index pages were not being flushed. This has been
fixed.
Other changes have been made as well to reuse Java objects and reduce the
creation of temporary objects during the download.
These changes were made to improve memory useage during synchronization.
================(Build #3483 - Engineering Case #674032)================
A database's in-memory state may have become corrupt if it had many indexes
on large tables and small row limits. This would have resulted in an ArrayIndexOutOfBounds
exception. The database itself was not actually corrupted and could have
been used after disconnecting and reconnecting. This has been fixed.
================(Build #3479 - Engineering Case #687769)================
In some circumstances, the Long.MIN_VALUE (-2^63) was incorrectly stored
internally as a NUMERIC value. This resulted in incorrect values during expession
evaluation. This has been fixed.
================(Build #3466 - Engineering Case #686039)================
After sending the upload and applying the download, UltraLiteJ sends a message
to the server telling it the synch is complete. If there was a network error
while sending this message, it would have been reported to the application,
implying the sync had failed even though the download was applied correctly.
This has been fixed and now the application no longer gets an error if the
sync otherwise succeeded.
================(Build #3465 - Engineering Case #686040)================
UltraLiteJ could have caused the MobiLink server to report spurious protocol
errors in the MobiLink server log. This has been fixed.
================(Build #3464 - Engineering Case #685746)================
With UltraLiteJ for Android, the method DatabaseInfo.getNumberRowsToUpload()
always returned 0. This has been fixed so that it now works as documented.
================(Build #3464 - Engineering Case #679296)================
With UltraLiteJ for Android, synchronization with HTTP and E2EE was not possible
because the methods setE2eePublicKey() and getE2eePublicKey() were members
of the class StreamHTTPSParms. This has been fixed by moving the methods
to the base class, StreamHTTPParms.
================(Build #3459 - Engineering Case #683700)================
With UltraLiteJ, committing a SQL statement that had updated a table containing
a large BLOB or CLOB could have caused a StackOverflowError exception. This
has been fixed.
================(Build #3449 - Engineering Case #683774)================
With UltraLiteJ, an UPDATE statement for table T with a subquery in the WHERE
clause that referenced T, could have failed with a -144 error ("Column
... found in more than one table or it is used more than once in the SELECT
list -- it needs a correlation name") at statement preparation time.
This has been fixed.
================(Build #3435 - Engineering Case #683394)================
When UltraLIteJ was run on Android devices, the method DatabaseInfo.getPageSize()
could have returned an incorrect value. This has been fixed.
Also, the method Connection.getDatabaseProperty() was exposed for UltraLiteJ
Android; and the method DatabaseInfo.getRelease() was modified to return
the full software release, including the build number.
================(Build #3415 - Engineering Case #680578)================
If a table had many rows with the same index value (all columns for a given
index were the same), updates and deletes could have been slow. The performance
decreased as the number of non-unique indexes with poor value distribution
on a given table increased. This has been fixed.
================(Build #3409 - Engineering Case #679403)================
Calling ResultSet.getString(i) when column i was of type INT, SMALLINT, UNSIGNED
SMALLINT, BIGINT, NUMERIC, REAL or DOUBLE, would have thrown a ULjException
with code SQLE_VALUE_IS_NULL when the column value was NULL. This has been
fixed so that ResultSet.getString() now returns null in this case.
================(Build #3406 - Engineering Case #671994)================
Doing an FETCH ABSOLUTE instead of a FETCH RELATIVE could have caused the
cursor to move to an incorrect row if the query contained a subquery. This
could have resulted in a -197 error code when trying to get column values.
The GetRowCount() method does an absolute fetch internally, so the problem
could have occurred when invoking this method. This has now been fixed.
================(Build #3403 - Engineering Case #672633)================
When the MobiLink server was running on an OS with a multi-byte character
set, and a synchronization request from an Android UltraLiteJ application
caused a synchronization error at the server, the UltraLiteJ runtime could
have caused an application crash. This has been fixed.
================(Build #3401 - Engineering Case #677867)================
Null values retrieved with ResultSet.getString( col_no ) were returned as
an empty string. This has been fixed. Now, null values are retrieved as
null with this method.
================(Build #3395 - Engineering Case #675363)================
A null pointer exception was possible when a host variable occurred in the
HAVING clause This was corrected.
================(Build #3387 - Engineering Case #675642)================
Database corruption was possible when the UltraLiteJ Runtime was under row
limitation stress (when the maximum and minimum row limitation values are
close together). This has now been corrected.
================(Build #3387 - Engineering Case #674898)================
Multi-threading access to an UltraLiteJ database may have resulted in a null
pointer or other exception. This problem would have occured if another thread
was accessing many rows in a single operation (i.e. updating a table with
a large number of rows and indexes with small row limiting values). This
has been fixed.
================(Build #3376 - Engineering Case #674206)================
The DatabaseManager.release() method is designed to be used only once to
release all resources associated with the UltraLiteJ runtime. However, some
DatabaseManager methods (eg. connect) did not return an error, but silently
failed when called after the call to release(). This has been fixed. Now,
a ULjException is thrown with the error code SQLE_NOT_CONNECTED if a connect()
or createDatabase() is called after the call to release().
================(Build #3372 - Engineering Case #673483)================
When the method Connection.emergencyShutdown() was called, existing connections
on the database did not have their states changed to NOT_CONNECTED. This
has been fixed.
Also, the method DatabaseManager.connect() now returns SQLE_INVALID_PARAMETER
if passed a NULL configuration.
================(Build #3369 - Engineering Case #673051)================
It was not possible to use ZLib data compression with HTTP synchronization
as the methods to enable compression appeared in StreamHTTPSParms, rather
than StreamHTTPParms. This has been fixed by moving the methods from StreamHTTPSParms
to StreamHTTPParms. Existing applications will continue to run because StreamHTTPSParms
is a subclass of StreamHTTPParms.
================(Build #3354 - Engineering Case #669242)================
An ArrayIndexOutOfBoundsException could have been thrown during a COMMIT.
This has been fixed.
================(Build #3345 - Engineering Case #668820)================
Calling the method DatabaseManager.release() would have caused the error:
"No implementation found for native Lcom/ianywhere/ultralitejni12/implementation/JniDbMgr;.release
()V". This has been corrected by implementing the method DatabaseManager.release().
Note that prior to this fix, UltraLiteJ for Android would have done the
equivalent of DatabaseManager.release() when the UltraLiteJ application terminated.
Now it is possible for the application to execute DatabaseManager.release()
at a specific point in time.
================(Build #3339 - Engineering Case #667720)================
The following methods have been implemented in ResultSetMetadata for UltraLiteJ
for Android:
String getAliasName( int column_no )
String getDomainName( int column_no )
String getCorrelationName( int column_no )
String getQualifiedName( int column_no )
String getTableColumnName( int column_no )
String getTableName( int column_no )
String getWrittenName( int column_no )
Previously, they returned the value "N.Y.I.". They now return
values that closely approximate those returned by the UltraLiteJ runtime
for Blackberry.
================(Build #3336 - Engineering Case #667519)================
The following get-by-name APIs were missing from ResultSet for UltraLiteJ
for Android and have now been added:
java.io.InputStream getBlobInputStream( String name )
boolean getBoolean( String name )
byte[] getBytes( String name )
java.io.Reader getClobReader( String name )
java.util.Date getDate( String name )
DecimalNumber getDecimalNumber( String name )
double getDouble( String name )
float getFloat( String name )
long getLong( String name )
int getSize( String name )
String getString( String name )
UUIDValue getUUIDValue( String name )
boolean isNull( String name )
================(Build #3301 - Engineering Case #662232)================
The performance of database changes on first update (commit) after starting
up has been improved.
================(Build #3297 - Engineering Case #660797)================
During a large (at least 15 MB) data synchronization, the UltraLiteJ native
library for Android could have caused a Dalvik VM memory overflow condition
similar to the following:
WARN/dalvikvm(641): ReferenceTable overflow (max=512)
...
ERROR/dalvikvm(641): Failed adding to JNI local ref table (has 512 entries)
...
ERROR/dalvikvm(641): VM aborting
The memory overflow condition would have occurred during a Connection.synchronize(
SyncParms parms ) call, where a SyncObserver was defined in the SyncParms.
This has been fixed.
================(Build #3297 - Engineering Case #660501)================
Incorrect results were possible when executing a query with an IN list consisting
of a single host variable. This has been corrected.
The work-around is to rewrite
expression in ( ? )
as
expression = ?.
================(Build #3295 - Engineering Case #660387)================
Incorrect results were possible for a deeply nested (at least a depth of
three) aggregate subquery. This has been corrected.
================(Build #3290 - Engineering Case #658845)================
Result set rows could have been presented in an incorrect order when all
of the following conditions were present for a SQL query:
- An index existed in which the first column (say col1) was specified to
be in descending order
- The query contained a search condition of the form "col1 LIKE expression"
where the expression started with non-wildcard characters.
- The query contained an ORDER BY starting with col1
This has been corrected.
================(Build #3278 - Engineering Case #655880)================
Second and subsequent '%' characters were not being handled properly in LIKE
clauses. This was corrected.
================(Build #3388 - Engineering Case #676069)================
The UltraLiteJ Database Unload utility (uljunload) did not allow specifying
the page size on a new databases. A new flag -z has been added to uljunload
to specify the page size in bytes.
================(Build #3369 - Engineering Case #673024)================
The message "Number of tables that are never synchronized:" would
have returned the number of tables that were synchronized instead of the
number that were never synchronized. This has been fixed.
Also, the message "Number of tables that will always be uploaded:"
was incorrect and misleading and the number displayed was invalid. This
message has been changed to "Number of tables that are in publications:"
and the output has been corrected.