SQL Anywhere Bug Fix Readme for Version 12.0.1, build 4484
Choose a range of build numbers for which to display descriptions. For example if you want to see what was fixed since the last build you applied then change 3152 to the build number of that last Support Package. 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 security/encryption components
while only updating the SQL Anywhere components to the level of the previously
released build for a given platform.
These are generated so that security/encryption changes can be provided quickly.
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 #4412 - Engineering Case #798416)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1t.
================(Build #4393 - Engineering Case #796406)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1s.
================(Build #4378 - Engineering Case #795323)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1r.
================(Build #4356 - Engineering Case #793255)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1q.
================(Build #4295 - Engineering Case #786881)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1p.
================(Build #4187 - Engineering Case #773812)================
The version of OpenSSL used by all SQL Anywhere products is now 1.0.1j.
================(Build #4104 - Engineering Case #764130)================
Some additional fixes were required for Engineering case 761751.
================(Build #4086 - Engineering Case #761751)================
The OpenSSL vulnerability known as Heartbleed impacted some components of
SQL Anywhere software as follows:
- SQL Anywhere Server when using TLS (Transport Layer Security) communications
and/or HTTPS web services, though only to the networks that can access the
server. Calling external web services over HTTPS from the database server
were also affected.
- MobiLink Server when using TLS and/or HTTPS communications, though only
to the networks that can access the MobiLink server.
- Relay Server Outbound Enabler
Affected Versions (note that all platforms were impacted by the vulnerability):
- SQL Anywhere 12.0.1 builds 3994-4098
- SQL Anywhere 16.0 builds 1690-1880
This vulnerability has been resolved by replacing the OpenSSL libraries
with corrected versions. Once this SP has been applied, regenerate any certificates
that were being used, and then change any passwords/keys associated with
SQLA web service calls or TLS authentication.
================(Build #3783 - Engineering Case #739688)================
If the SQL Anywhere OnDemand Edition cloud infrastructure is below version
1.0.0.3881, then use the “Upgrade cloud infrastructure” button to upgrade
the cloud to version 1.0.0.3881. Once the cloud infrastructure has been upgraded
to 1.0.0.3881, then the cloud servers can be upgraded to 12.0.1.3783.
To upgrade the cloud servers to 12.0.1.3783, follow the steps outlined below
instead of following the original documented procedure:
1) Using the “Cloud Software->Change server version” wizard, change the
server version of all servers that are not running the latest server version
to 12.0.1.3873. Make sure to select “Do not restart any servers.” Note that
if there are both Windows and Linux hosts in your cloud, then this step will
need to performed twice, once for each platform.
2) Stop the cloud.
3) Restart the 1.0.0.3881 cloud agent on each of the cloud HA hosts. This
will also start the cloud HA servers.
4) Start all of the other servers in the cloud.
5) Verify that all of the servers in the cloud are now running 12.0.1.3783.
================(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 #4200 - Engineering Case #778134)================
The mobile web services feature of QAnywhere is no longer supported. This
is because the component “Apache Jakarta Commons HttpClient” version 3.0
has been removed from the SQL Anywhere install. See http://hc.apache.org/httpclient-legacy/index.html
Customers that wish to use the mobile web services feature of QAnywhere,
at their own risk, can obtain the Jar commons-httpclient-3.0.jar and place
it in %SQLANY12%\java.
================(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 #4005 - Engineering Case #750511)================
The connection between Relay Server Outbound Enabler and the backend server
specified through the –cs option no longer supports tls_type=ecc.
================(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 #4321 - Engineering Case #789513)================
SetupVSPackage.exe did not register the SQL Anywhere .NET DDEX Provider with
Visual Studio 2015. This problem has now been corrected.
================(Build #4142 - Engineering Case #768717)================
The ADO.NET provider now supports Entity Framework 6. A new dll (iAnywhere.Data.SQLAnywhere.EF6.dll)
has been added to %SQLANY%\Assembly\V4.5 directory. SetupVSPackage still
registers the v4.5 dll. To use the new Entity Framework 6 provider, register
it in app.config or web.config.
For example:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection,
EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"
/>
</startup>
<connectionStrings>
<add name="Entities" connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=iAnywhere.Data.SQLAnywhere;provider
connection string='datasourcename="SQL Anywhere 12 Demo"'"
providerName="System.Data.EntityClient" />
</connectionStrings>
<system.data>
<DbProviderFactories>
<clear />
<add name="SQL Anywhere 12 Data Provider" invariant="iAnywhere.Data.SQLAnywhere"
description=".Net Framework Data Provider for SQL Anywhere 12"
type="iAnywhere.Data.SQLAnywhere.SAFactory, iAnywhere.Data.SQLAnywhere.EF6,
Version=12.0.1.41474, Culture=neutral, PublicKeyToken=f222fc4333e0d400"
/>
</DbProviderFactories>
</system.data>
<entityFramework>
<providers>
<provider invariantName="iAnywhere.Data.SQLAnywhere"
type="iAnywhere.Data.SQLAnywhere.SAProviderServices, iAnywhere.Data.SQLAnywhere.EF6,
Version=12.0.1.41474, Culture=neutral, PublicKeyToken=f222fc4333e0d400"
/>
</providers>
</entityFramework>
</configuration>
================(Build #4037 - Engineering Case #752772)================
Conversion of NUMERIC/DECIMAL columns to the .NET DECIMAL type has been improved.
================(Build #3817 - Engineering Case #724639)================
A new library (iAnywhere.Data.SQLAnywhere.v4.5.dll) has been added for supporting
.NET 4.5 and Entity Framework 5. Now 4 versions of SA ADO.NET provider are
shipped:
1 - iAnywhere.Data.SQLAnywhere.dll / policy.1x.0. iAnywhere.Data.SQLAnywhere.dll
– for .NET 2
2 - iAnywhere.Data.SQLAnywhere.v3.5.dll / policy.1x.0. iAnywhere.Data.SQLAnywhere.v3.5.dll
– for .NET 3.x and 2
3 - iAnywhere.Data.SQLAnywhere.v4.0.dll / policy.1x.0. iAnywhere.Data.SQLAnywhere.v4.0.dll
– for .NET 4
4 - iAnywhere.Data.SQLAnywhere.v4.5.dll / policy.1x.0. iAnywhere.Data.SQLAnywhere.v4.5.dll
– for .NET 4.5
SetupVSPackage.exe has also been updated. A new option ‘version’ has been
added.
1 - If the version is ‘4’, SetupVSPackage.exe registers the v4 dll in machine.config
file.
2 - If the version is ‘4.5’, SetupVSPackage.exe registers the v4.5 dll in
machine.config file.
3 - When the version is not specified, SetupVSPackage.exe registers the
v4.5 dll in machine.config file if .NET 4.5 is installed; otherwise, it registers
the v4.0 dll in machine.config file.
Examples:
1 - SetupVSPackage.exe /i /v 4.5 – register the v4.5 dll
2 - SetupVSPackage.exe /i /v 4 – register the v4.0 dll
3 - SetupVSPackage.exe /i – register the v4.5 dll if .NET 4.5 is installed;
otherwise, register the v4.0 dll.
SetupVSPackage.exe should be run to register the v4.0 provider for .NET
4 applications and register the v4.5 provider for .NET 4.5 / Entity Framework
5 applications.
================(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 #3782 - Engineering Case #717690)================
Certain applications often make decisions based on the set of data types
returned when making a SQLGetTypeInfo() ODBC call or a DatabaseMetaData.getTypeInfo()
JDBC call. An example of such an application is the "Export to ODBC
Database" functionality in MS Access where the application will use
the data type information returned by the SQLGetTypeInfo() call to decide
what column types should be included in the subsequent CREATE TABLE statement.
In some rare cases, the choices the application makes due to the existence
of certain data types may not be the most appropriate and it is sometimes
useful to hide the fact that the ODBC or JDBC driver supports certain data
types. The new SuppressInfoForDataTypes connection option can be used for
both the SQL Anywhere ODBC Driver and the SQL Anywhere JDBC Driver to instruct
to the driver to not return data type information for certain data types.
The set of data types to suppress should be specified as a comma separated
list. For example, the application could have the following on the ODBC or
JDBC connection string:
SuppressInfoForDataTypes=nvarchar,long nvarchar;varbit
The above would then instruct the driver that data type information for
the nvarchar, long nvarchar and varbit data types should not be returned
for this specific connection when the application makes a SQLGetTypeInfo()
or DatabaseMetaData.getTypeInfo() call. It should be noted that the suppression
only applies to returning data type information from the driver. The application
is still free to use the data type in column declarations and when retrieving
result sets.
================(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 #3994 - Engineering Case #749465)================
Previously, an Oracle JRE was shipped with the software for use by clients.
Now, the SAP JRE is shipped instead.
Upgrading overwrites the JRE directory (%SQLANY16%\binXX\jre170) and its
subdirectories. If you are using certificates, then your certificate store
(%SQLANY16%\binXX\jre170\lib\security\cacerts) is overwritten, including
your certificates. Similarly, fonts you added to the %SQLANY16%\binXX\jre170\lib\fonts\fallback
directory to help display characters in the administration tools may be lost.
To minimize upgrading steps with regards to the JRE change, create a backup
copy of the JRE directory and all of its subdirectories before you upgrade
so that you can refer to or restore files (such as cacerts) from the backup,
as needed. To restore settings, use the java_vm_options option (SQL Anywhere),
and/or the -sl java option (MobiLink) to optimize your Java VM startup settings.
================(Build #3977 - Engineering Case #749256)================
Strong encryption now achieved using OpenSSL
--------------------------------------------
Prior to this change, SQL Anywhere included a Certicom encryption module
that provided strong encryption used throughout the software. Now, SQL Anywhere
includes an OpenSSL encryption module for the strong encryption. The Certicom
encryption module has been removed.
Read the following descriptions to determine how you may be impacted by
this change.
FIPS encryption now requires the private key of an identity file to be encrypted
using AES
- OpenSSL FIPS supports AES encryption for the private key of an identity
file. New servers using the OpenSSL FIPS encryption module will not start
when using an identity file that has its private key encrypted with 3DES.
You must re-encrypt the identity file using AES. To do this, run a command
similar to the following using an upgraded viewcert utility:
viewcert -p -o new-file-name -op new-password -ip old-password old-file-name
The new and old passwords can be the same.
- The sample server identity file (rsaserver.id) and client identity file
(rsaclient.id) have been modified so that the private keys are encrypted
using AES rather than 3DES.
- Versions of the server that use the Certicom encryption module will not
start when using an identity file that has its private key encrypted using
AES. Trusted root certificate files specified using trusted_certificates
do not need to be modified.
Self-signed certificates must now have the Certificate Signing attribute
set
Self-signed certificates must now have the Certificate Signing attribute
set when using the identity encryption option (for example, the -x mlsrvXX
and -xs dbsrvXX options). To determine if a certificate has the Certificate
Signing attribute set, use the viewcert utility and look for the Certificate
Signing attribute in the Key Usage portion of the output. If your self-signed
certificates do not have the Certificate Signing attribute set, then you
must regenerate the certificates.
Create Certificate utility (createcert) now uses AES encryption instead
of 3DES
The Create Certificate utility (createcert) now uses AES rather than 3DES
encryption for encrypting the private key in the server identity file.
A new option, -3des, has been added to the Create Certificate utility. Use
this option when you want to create a 3DES-encrypted server identity file
that can be used by both new and old servers. Note that new servers running
in FIPS mode cannot start using 3DES-encrypted certificates; however, if
you are not running in FIPS mode, then you can use 3DES-encrypted certificates.
View Certificate utility (viewcert) now uses AES encryption instead of 3DES
The View Certificate utility (viewcert) now uses AES rather than 3DES encryption
when you specify the -p option to PEM-encode the output and when you specify
the -ip and -op options to set the password.
A new option, -3des, has been added to the View Certificate utility to allow
you encrypt output and passwords using 3DES instead of AES.
Database server now loads the FIPS driver file, dbfipsXX.dll, at startup
Previously, the 32-bit Windows database server loaded the FIPS driver file,
dbfipsXX.dll, only when needed. Now, the 32-bit Windows database server always
attempts to load dbfipsXX.dll at startup, and keeps it loaded for the life
of the server. If loading dbfipsXX.dll fails, then an error is returned only
when an attempt is made to use FIPS encryption.
Deploying FIPS
If you are deploying FIPS encryption, then there are new shared libraries
to deploy; these files are included in your software. The former files, sbgse2.dll
and libsbgse2.so, are no longer installed by the software. The new files
to deploy are:
- Windows 64-bit: libeay32.dll, ssleay32.dll, and msvcr100.dll
- Windows 32-bit: libeay32.dll, ssleay32.dll, and msvcr90.dll
- Linux: libcrypto.so and libssl.so
Note: On Windows, although 32-bit and 64-bit FIPS-certified OpenSSL libraries
for encryption are provided, you must use the 64-bit libraries on a 64-bit
system.
MobiLink-related changes and information
Connecting to a MobiLink server using client-side certificates now requires
the Digital Signature certificate attribute to be set
TLS/SSL connections to a MobiLink server using client-side certificates
now require the client-side certificate to have the Digital Signature attribute
set. If the attribute is not set, then the connection will fail.
To determine if a certificate has the Digital Signature attribute set, use
the View Certificate utility (viewcert) and look for the Digital Signature
attribute in the Key Usage portion of the output. If your client-side certificates
do not have the Digital Signature attribute set, then you must regenerate
the certificates.
FIPS-based end-to-end encryption now requires the private key to be encrypted
using AES
If the private key file provided to a MobiLink server by the e2ee_private_key
file option of the –x command-line option is encoded using 3DES and you are
running in FIPS mode, then the private key file needs to be regenerated with
the private key encrypted using AES.
How to update a MobiLink deployment that uses non-FIPS TLS/SSL (includes
HTTPS) and client-side certificates
1. If your client-side identity certificates do not have the Digital Signature
attribute set and the client connects directly to the MobiLink server, then
you must regenerate and deploy client-side certificates with the Digital
Signature attribute set.
2. Update the server-side binaries.
3. Update the client-side binaries.
How to update a MobiLink deployment that uses FIPS, TLS/SSL (includes HTTPS)
and client-side certificates
These steps update the client identity certificates twice if the Digital
Signature attribute is missing from client-side identity certificates. This
procedure can make the update less disruptive because synchronizations can
continue without having to coordinate the client-side and server-side updates
to occur at the same time.
1. If your current client-side identity certificates do not have the Digital
Signature attribute set and the client connects directly to the MobiLink
server, then you must regenerate and deploy client-side certificates with
the Digital Signature attribute set.
2. Update the server-side binaries (remembering to include the new FIPS
driver files) and deploy server identity certificates with AES-encrypted
private keys.
3. Update the client-side binaries (remembering to include the new FIPS
driver files) and deploy client identity certificates with AES-encrypted
private keys.
How to update a MobiLink deployment that uses FIPS and end-to-end encryption
1. Regenerate the primary key file referenced by the e2ee_private_key encryption
option.
2. Shut down the MobiLink server.
3. Update the MobiLink server binaries, remembering to include the new required
FIPS driver files.
4. Change the e2ee_private_key option to point to the new private key file
(or replace the old file), updating the e2ee_private_key_password, if required.
5. Restart the MobiLink server.
Note, connecting to and creating a MobiLink server resource in the 32-bit
Windows SA Monitor that will use FIPS encryption to connect to the MobiLink
server, may fail with the error, “Failed to load library mlcrsafips12.dll”.
To work around this, you can either not use FIPS encryption, or use 64-bit
SA Monitor. Similarly, connecting to a database server from 32-bit DBISQL,
DBConsole, or Sybase Central using FIPS encryption, may also fail with the
error, “Failed to load library mlcrsafips12.dll”. To work around this problems,
you can either not use FIPS encryption, or use 64-bit client software.
================(Build #3782 - Engineering Case #657970)================
As of 12.0.1, a version 12.0.1 EBF can be applied to a version 12.0.0 installation,
as long as certain conditions are met. In this case, any 12.0.0 components
are upgraded to version 12.0.1. This was happening without warning the user
that they will be upgrading to a newer version, rather than just a newer
build number. This has been fixed. The installer now warns that the software
will be upgraded and asks if the user would like to continue.
================(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 #4368 - Engineering Case #794347)================
The server could have failed an assertion or fail to create some valid round-earth
geometries. This has been fixed.
================(Build #4367 - Engineering Case #794129)================
The server performs performance rewrites on ISNULL and COALESCE function
argument lists based on the nullablility of the arguments. More rewrites
can now also be done if the argument contains a referencing old or new column
of a trigger.
================(Build #4176 - Engineering Case #772559)================
SQL Anywhere, MobiLink, and UltraLite, servers and clients, no longer support
the SSLv3 protocol. All TLS connections must now be TLSv1 or higher.
================(Build #3980 - Engineering Case #747805)================
For Syntax 2 of the DELETE statement and Syntax 2 of the UPDATE statement
the error detection behaviour of the server has been improved. These two
syntax forms allow an additional FROM clause that may contain the table-name
of the updated or deleted table, for example:
DELETE
FROM [owner.]table_1 [ [ AS ] correlation-name ]
FROM [owner.]table_1 [ [ AS ] correlation-name ] ...
WHERE ...
and
UPDATE [owner.]table_1 [ [ AS ] correlation-name ]
SET columns_1 = ...
FROM [owner.]table_1 [ [ AS ] correlation-name ] ...
WHERE ...
If the DELETE or UPDATE clause and the additional FROM clause have a table
reference that contains the same table name, in the above example "table_1",
then the server can only decide whether both are identical table references
if one of the following conditions is true:
- both table references are not qualified by specifying a user ID
- both table references are qualified by specifying a user ID
- both table references are specified with a correlation name
In cases where the server cannot decide whether the above table references
are identical or not it will now return an SQL error to prevent the user
from unintended semantics like deleting and updating to many rows.
================(Build #3978 - Engineering Case #747794)================
The server now recognizes when it is running on Windows 8.1 and Windows Server
2012 R2 operating systems.
================(Build #3942 - Engineering Case #744027)================
The SQL Anywhere PHP External Environment supports several versions of the
PHP interpreter. The SQL Anywhere install bundle includes a separate PHP
external environment dll or shared object for each supported version of PHP.
In addition, whenever support for a new version of the PHP interpreter is
added, the SQL Anywhere install bundle is updated to include the new PHP
external environment dll or shared object for the new version of the PHP
interpreter. Going forward, the SQL Anywhere install bundle will no longer
be updated with additional PHP external environment dlls or shared objects
when support for new versions of the PHP interpreter are added. Instead,
the new PHP external environment dlls and shared objects will now only be
available on the download site.
================(Build #3899 - Engineering Case #737497)================
Previously, the CREATE INDEX statement for local temporary tables on read-only
nodes had been disallowed. This has been changed, and now local temporary
tables are the only tables where index creation is allowed on the read-only
databases.
================(Build #3869 - Engineering Case #734038)================
The database property TimeWithoutClientConnection has been added.
The description for this database property is:
Returns the elapsed time in seconds since a CmdSeq or TDS client connection
to the database existed. If there has not been a CmdSeq or TDS connection
since the database started then the time since the database started is returned.
If one or more CmdSeq or TDS connections are currently connected, 0 is returned.
================(Build #3823 - Engineering Case #725019)================
The syntactical construct "numeric( precision, scale )" would have
returned the error "Syntax error near ')'" if the scale value was
greater than the precision value. This has been fixed so that the syntax
error message now contains the scale value.
================(Build #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 property
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 #3373 - Engineering Case #674702)================
Assertion failure messages now include a database name where available.
================(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 #4201 - Engineering Case #761569)================
Version 12 UltraLite now supports 64-bit architectures for iOS (arm64 and
x86_64).
================(Build #4006 - Engineering Case #753086)================
UltraLite now supports Xcode 5 and iOS 7. Version 16 includes 64-bit libraries
for the new A7 (arm64) chip along with the 64-bit simulator.
================(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 #3849 - Engineering Case #727144)================
When executing SQL statements and queries with many parameters, they could
have taken a long time to complete in an UltraLite.Net application. This
has been fixed.
================(Build #4262 - Engineering Case #783219)================
In MobiLink projects with an ASE consolidated database, the "Tables
(by Owner)" container in Sybase Central could have contained the same
owner (e.g. "dbo") multiple times. This has been corrected so
that a given owner is now listed only once.
================(Build #3899 - Engineering Case #739173)================
In the MobiLink Server Log File Viewer, on the "Synchronizations"
panel, a single synchronization could have appeared a number of times in
the "Synchronizations" table. This happened when the messages from
the sync were interspersed with messages from "<Main>".
This has been fixed.
================(Build #3819 - Engineering Case #723981)================
In a synchronization model, if the Events editor was used to create a script
using the .NET language and deployed the synchronization model, the MobiLink
server could have given an error like the following:
Cannot load DLL or shared object: 'ml.net12.dll' for Script Language: '.net'
For Java scripts, a similar error could have been displayed on operating
systems with case-sensitive file names, or errors fetching Java scripts on
Windows.
These problems have been fixed.
================(Build #3816 - Engineering Case #720303)================
In a client-only installation, the Services wizard would not have allowed
the creation of a Windows service. This was incorrect, as it prohibited creating
a MobiLink service, and has been fixed.
================(Build #3814 - Engineering Case #723368)================
When deploying a synchronization model with a SQL Anywhere remote database,
an error could have occurred if the "Save message log to the following
file (using -ot option)" option was unchecked on the "Verbosity
For SQL Anywhere Remote Synchronization Client" page of the "Deploy
Synchronization Model Wizard". The error message would state:
The synchronization model could not be deployed.
Error for: Rendering macro APPEND_VAR
This has been fixed. A workaround is to enable that option and redeploy.
================(Build #3813 - Engineering Case #723212)================
If a MobiLink project in Sybase Central contained a SQL Anywhere consolidated
database, and that database was being monitored by the SQL Anywhere Monitor,
tables which were owned by the Monitor were being displayed in the user interface.
They have now been removed, because they should never take part in a synchronization.
================(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 #4068 - Engineering Case #753092)================
The MobiLink Agent for central administration of remote databases could have
crashed when shut down. For the crash to have occurred, the agent must have
executed a task that was conditional on the current network name on the device.
This has been fixed.
================(Build #3865 - Engineering Case #733583)================
The MobiLink Agent for central administration of remote databases could have
executed a given task ID concurrently if the task was running on a schedule
and also was server-initiated. This has been fixed. Although tasks may
run concurrently in general, only one instance of a given task ID should
be executing at any given time.
================(Build #4383 - Engineering Case #795657)================
On Linux systems, opening help did not work if the machine used a network
proxy. This has been fixed.
================(Build #4201 - Engineering Case #776240)================
With some versions of Linux and Unix, the Port field of the Connect to MobiLink
Server window was not displayed correctly: it was too narrow for the port
number to be visible. 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 #4320 - Engineering Case #789934)================
When a Relay Server was configured to serve thousands of backend servers,
the Relay Server State Manager (rshost) service on Windows may have sporadically
failed to startup. This has been fixed.
================(Build #4316 - Engineering Case #789326)================
The Relay Server for Apache did not relay all duplicate HTTP response headers
received from the backend server that had the same header name, regardless
of value. Only the last duplicate header that was read was sent back to the
client. This has been fixed.
================(Build #4193 - Engineering Case #775149)================
Apache setup script could have generated duplicate lines in the <apache-install>/bin/envvars
file when the script was run multiple times. The duplicate lines were generated
for setting the LD_LIBRARY_PATH environment variable. This has now been fixed.
================(Build #4192 - Engineering Case #774899)================
The Relay Server State Manager (rshost) could have crashed while reporting
a Relay Server configuration file error message:
"RSF11020: Missing required section ‘<section-name>’ in configuration
file ‘<config-file-name>’"
This has been fixed.
================(Build #4131 - Engineering Case #766464)================
Host name and Relay Server version information have now been removed from
the status page when accessed through the client or server extension. The
information still remains available via the optional admin or monitor extensions.
The admin and monitor extensions are expected to be accessible by administrators
only.
================(Build #4123 - Engineering Case #765512)================
When the Outbound Enabler used a secure HTTPS connection to the backend server,
if the connection to the backend server was re-used after it was recycled,
it was possible for the Outbound Enabler to have crashed. This has been
fixed.
================(Build #4122 - Engineering Case #765449)================
The Relay Server keeps records of statistics per type of client and there
is an internal limit of 1600 types per backend server in the backend farm.
When this limit was reached the Relay Server would have issued an RSF13011
error and failed the relay. This has been fixed with the following changes:
- The Relay Server no longer creates new metrics until the rs_monitor.dll
has been accessed. Most partners don’t distribute rs_monitor.dll.
- If rs_monitor.dll has been accessed and the number of client types of
a backend server has exceeded 1600, a new RSW107 warning is issued instead
of the RSF13011 fatal error.
- In the RSW107 situation, the Relay Server will continue to relay the
traffic, but no new metrics are created for the new client type.
================(Build #4105 - Engineering Case #762786)================
When the RSOE used -cs https=1 and a client had disconnected before receiving
all response bytes from the backend server, subsequent communications with
the backend server may have suffered from false OEE1048(MLC53) SSL handshake
errors. This has been fixed.
The RSOE may also have suffered false OEE1048(MLC8) SSL read errors when
-cs https=1 was used. This has also been fixed.
================(Build #4085 - Engineering Case #759461)================
It was possible for the Relay Server to have incorrectly reported fatal error
RSF13011 (Failed allocating shared memory block for client traffic statistic
collector of backend server 'XXX' in backend farm 'YYY'). After this fatal
error, the Relay Server would no longer have communicated with backend server
‘XXX’ in backend farm 'YYY' until the Relay Server Host Manager was restarted.
While there continue to be legitimate reasons for the RSF13011 error to be
reported, the problem that would have led to the incorrect reporting of the
RSF13011 error has now been fixed.
================(Build #4068 - Engineering Case #757265)================
The Outbound Enabler may have crashed on startup while creating an HTTPS
up-channel and down-channel at the same time before using them. This has
been fixed.
================(Build #4061 - Engineering Case #701061)================
Uploading small requests while the Relay Server Outbound Enabler up-channel
was under a low load situation may 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 upload data. This change introduced
a new up_pad_size property in the [option] section of the Relay Server config
file. The default value is 1460 which is suitable for Ethernet. This change
can be turned off by setting up_pad_size to 0. Online pad size adjustment
is supported but it will take effect only after the Outbound Enabler reconnects
the up-channel.
================(Build #4057 - Engineering Case #755249)================
When a URL query parameter contained double forward slashes, the IIS Relay
Server incorrectly converted them into a single forward slash. The X-Original-Url
header does correctly preserve the correct original URL and might have been
used by the backend server as a workaround. This issue has been fixed.
Note, this issue doesn’t happen on the Apache Relay Server.
================(Build #4038 - Engineering Case #750638)================
If a client application had included the “Expect: 100-continue” header in
the request and had passed this request through the Relay Server, it was
possible for the client to have received multiple “HTTP 100 Continue” responses,
which would likely have caused the client to have failed the request. This
has been fixed, and only a single “HTTP 100 Continue” response will now be
sent.
================(Build #4025 - Engineering Case #752109)================
The MobiLink server with an integrated Relay Server Outbound Enabler could
have hung or crashed on shutdown. The has now been fixed.
================(Build #4008 - Engineering Case #750493)================
On Linux systems, the Relay Server State Manager (rshost) process could have
failed to start under the following conditions:
- the -o option was not specified, AND
- if any of the environment variables $TMPDIR, $TMP, $TEMP was defined
but the directory did not exist.
Depending on how rshost was started, it could have failed silently. This
has been fixed.
================(Build #3987 - Engineering Case #748414)================
Relay Server monitoring provided via the SQL Anywhere Monitor may have suffered
stack overflow exceptions on the Java data collection client. This is now
fixed.
================(Build #3954 - Engineering Case #745191)================
The Outbound Enabler has a fixed limit of 1000 active connections with the
backend server per Relay Server. The Outbound Enabler would have crashed
when the limit was exceeded. This has been fixed by relaxing the internal
limit to 32768 active connections. An OEE1051 error is given when that limit
is now exceeded.
================(Build #3935 - Engineering Case #743046)================
When the Apache httpd shutdown raced ahead of the Outbound Enabler shutdown,
the Up channel may never have been gracefully shutdown, as Apache terminates
the worker process non-gracefully. This could in turn could have caused the
Relay Server State Manager (rshost) to leak System V semaphores on shutdown.
The “ipcs –s” command can be used to review System V semaphore being used.
This has been fixed by eliminating the latency on Up channel shutdown so
that the race condition is much less likely to happen. This change is not
a complete solution, but it reduces the possibility of this problem occurring.
================(Build #3924 - Engineering Case #743364)================
The fix for Engineering case 740747 - "The Apache Relay Server did not
respect the client's application timeout header" was incomplete for
Apache 2.2.21 and 2.2.24 on Linux systems. This has been fixed.
================(Build #3923 - Engineering Case #741408)================
Relay Server for Apache correctly sets the HTTP status code on the client's
HTTP response, however, it didn't return that same HTTP status code back
to the Apache webserver. This caused the wrong HTTP status code to be printed
in Apache's access_log.
This has now been fixed.
================(Build #3913 - Engineering Case #740747)================
The Apache Relay Server did not respect the client's application timeout
header (IAS-RS-App-Timeout-Minute). If the client's application timeout header
value eas smaller than Apache's 'Timeout' directive, the Apache Relay Server
would have taken longer to timeout the client's request, upto Apache's Timeout
directive. This has been fixed.
================(Build #3910 - Engineering Case #741205)================
The Relay Server and the Outbound Enabler were not designed for clients that
did not maintain affinity isolation. The Outbound Enabler has been incrementally
patched to fulfill such a need. The new Relay Server liberation option (socket_level_affinity=no)
is an efficient way to have the Relay Server transform the traffic so that
the relay mechanism will no longer be exposed to unintended use. In other
words, the net effect is to support the previously unintended use with the
liberation option. Liberation is not turned on by default and some customers
may be willing to upgrade their Outbound Enabler, but not the Relay Server
in the DMZ. So testing of such unintended use without liberation has been
increased, and yet another case where such unintended use may still fail
without using liberation has been found. This change is to fix the Outbound
Enabler to deal with such a case. A workaround is to use liberation by explicitly
setting socket_level_affinity=no.
================(Build #3910 - Engineering Case #740559)================
The affinity information injected by the Relay Server carries information
for addressing the socket opened from the Outbound Enabler to the backend
server. This was required for end-to-end persistent connections between Client-RS
and OE-Backend, while the shared RS-OE connection is always persistent. Such
socket level affinity calls for affinity information isolation per socket
on the client side. This proprietary isolation requirement was found to be
too restrictive. Partners have been releasing their clients or utilizing
third party client software in solutions using the Relay Server where the
isolation requirement has not been met. Not all development environments
or third party clients can support the implementation of the isolation. A
change has now been made to introduce an optional relaxation from the Relay
Server so that it will reduce the level of addressing information to backend
server level instead of socket level. Persistent connection between Client-RS
can still be maintained as the Relay Server will work with the Outbound Enabler
to transform the OE-Backend accesses into non-persistent transient access.
The net result is a liberation on developing integration between the client
and the Relay Server.
A new backend_farm property called socket_level_affinity has been added
for controlling the behavior in a per backend farm manner. The liberation
described above is DISABLED by default (i.e. socket_level_affinity=yes is
the default). Online configuration update of this property is supported.
External Requirements
Updating to this new Relay Server, with socket_level_affinity=no, doesn’t
require deploying a client to clear previous affinity cookie assigned by
the Relay Server. Also, the Outbound Enabler doesn’t need to be upgraded
in order to enjoy the liberation. This is an internal behavior change which
continues to require the backend servers to allow non-persistent HTTP traffic
and/or broken up persistent HTTP traffic. This backend server requirement
remains regardless of whether the liberation is used or not. If liberation
is enabled, the backend server doesn’t need to support or allow persistent
HTTP connection.
================(Build #3910 - Engineering Case #740486)================
Clients are not expected to use expired affinity, however not all client
development can support proprietary expiry defined by the Relay Server. For
that reason, the Outbound Enabler was relaxed to let in new requests with
expired affinity. This relaxation was found to be incomplete. Under certain
access sequence, a POST request may still suffer errors like the following:
RS16: RSE4015: Outbound enabler of backend server 'S0' in backend farm
'RSTEST02.F0' reports session error OEE_SESSION_ACCESS_FAILED(1051) with
parameters 'RS_CLI_REQUEST_CONTINUE', 'disconnected at the middle of a request',
'_unused_'
OE16: OEE1051: The Outbound Enabler was unable to access the session
with ridx=0 sidx=0 snum=0000 sfp=01aa9daa on a RS_CLI_REQUEST_CONTINUE packet
due to disconnected at the middle of a request
RS12: RSE4004: Outbound enabler of backend server 'S0' in backend farm
'MLVM-SARSX64.F0' reports session error OEE25100 with parameters '_unused_',
'_unused_', '_unused_'
OE12: Session was disconnected at the middle of a packet sequence. Aborting
sidx=0
The problematic sequence has been identified and a fix has been made so
that the OE can handle the POST that falls into that sequence. If the traffic
is RESTful, a user workaround is to turn off all affinity injection from
the Relay Server using the active_cookie=no and active_header=no property
in the backend_farm configuration section of the affected backend farm and
clear HTTP cookies from the client after the Relay Server configuration has
been updated.
================(Build #3909 - Engineering Case #740440)================
The Relay Server would have responsed with "HTTP 200 OK" to requests
that didn’t carry User-Agent headers, without actually performing the relay.
The Relay Server uses the User-Agent header (or alternatively the IAS-RS-User-Agent
header) to group metrics for aggregated statistics. A fix has been made
so that requests that don’t carry User-Agent or IAS-RS-User-Agent headers
are now processed, and their metrics are collected under the group with User-Agent
“_unknown_”. This problem was reported when using the Relay Server with Windows
8 Store app which accesses NetWeaver Gateway OData services via the Relay
Server and SUP 2.2.
================(Build #3908 - Engineering Case #740328)================
The Relay Server would have incorrectly stopped relaying and reported the
error RSE4008 with “Malformed HTTP chunk” when it encountered chunked server
responses with valid extensions or trailers (see RFC2616 section 3.6.1).
This has been fixed. Logging of the extensions and trailers were added for
log level 4 and higher.
================(Build #3907 - Engineering Case #738201)================
When attempting a download resumption through the Relay Server to a MobiLink
server farm, the client could have connected to the wrong MobiLink server,
resulting in the download resumption attempt failing. The client weren’t
persisting the HTTP cookies that the Relay Server requires to match it back
up with the correct MobiLink server. The cookies are now stored with the
rest of the restart state.
================(Build #3903 - Engineering Case #739810)================
During quick setup, users are prompted by the following question:
Expect Afaria clients (y/N)?
If the answer is yes, the expectation is that the quick setup script will
configure IIS to turn off request buffering, due to the incompatibility between
IIS and Afaria client regarding how the size of the entity body of the HTTP
request was specified. The IIS7 version of the quick setup script was failing
to turn off the buffering. This problem has been fixed.
================(Build #3896 - Engineering Case #738782)================
The integrated Relay Server Outbound Enabler (RSOE) library could have crashed
the Mobilink server in the following cases:
1- In an error case, such as a failure to send data to the backend
2- In a timing sensitive situation, while the RSOE was sending data to the
backend and receiving a notification from the RelayServer to disconnect a
socket (due to client dropping the connection or aborting for any reason
before completing a clean send/receive HTTP cycle).
This has been fixed.
================(Build #3895 - Engineering Case #736239)================
When the MobiLink client held on to old affinity information across Outbound
Enabler restarts, and used it on new requests, the Outbound Enabler would
have failed the relay (reported as OEE1051 error on version 16). The Outbound
Enabler has been fixed to allow the traffic to go through instead.
================(Build #3882 - Engineering Case #736717)================
The Relay Server may have reported that the shared memory manager was in
an unhealthy state when under heavy load. This has been fixed.
================(Build #3882 - Engineering Case #736716)================
By design, the Relay Server Outbound Enabler treats client disconnect as
an immediate cancel of the request if it is happening at the middle of the
HTTP request/response cycle. Therefore, uploads could have been truncated
by the immediate cancelling, if the client disconnect arrived while the upload
was queued up. This has now been changed so to make sure all request bytes
that came before the disconnect are not cancelled by the client disconnect.
Also, the RSOE no longer views this situation as an abnormal behavior of
an HTTP client.
================(Build #3877 - Engineering Case #736024)================
The renew_overlapped_cookie property was introduced for the Relay Server
to work with clients without cookie isolation support. The default value
of renew_overlapped_cookie in version 16.0.0 was set to 'yes' for maximum
compatibility. The same feature was added to version 12.0.1, however the
default value was 'no'. The 12.0.1 decision has been revised and this feature
is now on by default in 12.0.1 as well.
================(Build #3877 - Engineering Case #735998)================
The Relay Server Outbound Enabler may have restarted unnecessarily in rare
situation, resulting in repeated RSE3003 error for a duration as long as
the OE-RS liveness timeout period. One example situation would have been
when a Relay Server was removed from the farm and then being added back after.
This has been fixed.
================(Build #3871 - Engineering Case #734841)================
The Relay Server component may have silently missed error messages with old
versions of the language resource. This has been fixed by adding a generic
error message indicating the resource library is too old.
================(Build #3865 - Engineering Case #733471)================
The Outbound Enabler was performing unnecessary operations when an internal
restart was caused by an up-channel failure. This change eliminates the unnecessary
operations, so recovery time, and clarity in logged operations, are improved.
================(Build #3864 - Engineering Case #733171)================
The Relay Server provided no option to inject the X-Original-URL header.
This has been fixed by injecting the header whenever the original request
didn’t contain such a header. The injected header value is URL-encoded.
================(Build #3862 - Engineering Case #732975)================
The Apache Quick Setup script contained some bash specific syntax that caused
errors when run on Linux systems running Ubuntu. Ubuntu uses dash, not bash,
as the default shell interpreter. This has been fixed.
================(Build #3861 - Engineering Case #732959)================
A pinpointed status page may have mistakenly report that the server was not
found when IAS-RS-SERVER was not the last parameter in the URL query. This
has been corrected.
================(Build #3861 - Engineering Case #732957)================
One of the Relay Server Outbound Enabler's debug messages (-v 4) "Successfully
retrieved relay servers peer list.." was logged before the RSOE tried
to read the list. Thus it was misleading and could have lead to an incorrect
diagnosis. This fix is simply to re-word the message to "Successfully
posted peer list request..".
================(Build #3846 - Engineering Case #729873)================
The Relay Server automatically sends down instruction to the client to expire
the affinity cookie when the backend server response code falls into the
error range, except for 401 and 407 authentication challenges. Debug information
of this expiring activity was not available in the Relay Server log at any
verbosity level. This fix is to add a message at verbosity 4 and above for
this activity.
================(Build #3846 - Engineering Case #729871)================
The Relay Server was considering server responses that contained headers
with empty values as malformed, and was converting the responses to a '400
Bad Request' response. This fix is to relax this case and relay the response
without changing it or raising an error.
================(Build #3846 - Engineering Case #729869)================
The Relay Server converted server responses containing malformed headers
into a '400 Bad Request' response without logging an error. This fix added
a new RSE_CLIENT_RESPONSE_HEADER_ERR(4016) error when this now happens.
================(Build #3843 - Engineering Case #724960)================
If the Relay Server had been acting as an intermediary for a backend server
that required authentication (such as an IIS Server), it was possible that
the authentication handshake between the client and backend server could
have failed, despite the client having provided the proper username and password
for authentication. This has now been fixed.
================(Build #3822 - Engineering Case #725212)================
The Relay Server IIS7 quick setup script was using %USERDNSDOMAIN% as the
domain of the machine and that didn't always work. The script has now been
changed to test if the FQDN can be resolved, and if not it will offer two
options:
a. Setup without a domain
b. Let user enter the domain manually and test again.
Also, the setup step has been clarified so that using the domain user account
for Relay Server State Manager service is a valid option if local online
maintenance feature is not needed.
================(Build #3821 - Engineering Case #725104)================
When the MobiLink Server was using an embedded Outbound Enabler, and connectivity
issues occurred between the Relay Server and the MobiLink Server while the
embedded OE was busy uploading requests, the service may not have recovered.
A restart of the MobiLink Server was needed in this case. This problem has
been fixed.
================(Build #3817 - Engineering Case #723889)================
When using a secured connection between the Relay Server Outbound Enabler
and the local backend server, it was possible fior the Outbound Enabler to
have crashed when disconnecting. This has been fixed.
================(Build #3807 - Engineering Case #721874)================
Applications that associate themselves to edit .js or .vbs files, like UltraEdit,
could have caused the quick setup script to fail. This has been fixed.
================(Build #3796 - Engineering Case #716037)================
If the Down Channel between the Relay Server and the Outbound Enabler was
healthy, the Outbound Enabler would not have checked for liveness on the
Up Channel. In very rare circumstances, the Down Channel could be healthy,
but an intermediary between the Relay Server and Outbound Enabler has closed
the socket for the Up Channel at the Relay Server, while leaving the corresponding
socket on the Outbound Enabler open. In this scenario, the Outbound Enabler
would never have attempted to re-connect the Up Channel, and no communication
with the backend server was possible. When the Down Channel is healthy,
the Outbound Enabler now increases the time for the liveness by a factor
of four instead of disabling the liveness.
================(Build #3795 - Engineering Case #719834)================
The Relay Server Outbound Enabler was logging response bytes at verbosity
9, but should have been logging them at verbosity 5 or higher. This has been
fixed.
================(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 #710112)================
The Relay Server may have crashed when it received a session error with parameters
from the Outbound Enabler. This has been fixed.
================(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 #3993 - Engineering Case #748548)================
If a database contained subscriptions for more than one MobiLink user, and
at least one of those users had a name containing non-alphanumeric characters,
then it was possible for synchronizations to fail and generate incorrect
error messages. The messages generated may have included, “There is no synchronization
subscription for user ? to publication ?” or “Communication protocol mismatch.
Unable to negotiate an appropriate communication protocol with the MobiLink
server.” Other error messages were likely also possible. This has been fixed.
Having non-alphanumeric characters in MobiLink user names should now be handled
correctly.
================(Build #3939 - Engineering Case #743027)================
HTTP Basic authentication in persistent HTTP synchronizations could have
reported the error: -1305: MobiLink communication error -- code: 216. This
has been fixed.
Note, this fix also applies to UltraLite and UltraLiteJ for Android.
================(Build #3924 - Engineering Case #740879)================
If a SQL Anywhere MobiLink client database had been rebuilt using the Unload
utility (dbunload), and it previously had been upgraded using the Ugrade
utility (dbupgrad) or using the ALTER DATABASE UPGRADE command, then subsequent
synchronizations could have resulted in dbmlsync sending up the wrong schema
definition to the MobiLink Server, or it could have resulted in a crash of
the dbmlsync process. This can be worked around by dropping and re-creating
all the SYNCHRONIZATION SUBSCRIPTIONS in the remote database after the rebuild
or upgrade. This issue has now been resolved.
================(Build #3911 - Engineering Case #740636)================
The MobiLink user password and new password could have been shown in MobiLink
server log files in plain text. This would have occured if the password and
new password, as named-parameters, were referenced in any user authentication
scripts, and the MobiLink server was running with the –vc command line option.
This as been corrected. Now the MobiLink server will replace the password
and new password with asterisks "*", and then log them.
================(Build #3840 - Engineering Case #728446)================
When the error message “SQL statement failed: (-782) Cannot register 'sybase.asa.dbmlsync'
since another exclusive instance is running” was generated and the database
character set of the remote database was different from the OS character
set, the message would be displayed in the wrong character set and may have
been unreadable. This problem affected only this error message, and has now
been fixed.
================(Build #3830 - Engineering Case #726952)================
The MobiLink Client would not have reported error messages generated by the
MobiLink server for a synchronization where progress offsets were checked
against the server values at the beginning of the synchronization and found
to be different from the server side values. This has been fixed.
================(Build #3820 - Engineering Case #724701)================
When MobiLink clients starts up, it deletes temporary files left by any previous
instance of the software that might have exited abnormally. This cleanup
was not occurring when the SATMP environment variable was set. This has
been fixed.
================(Build #3806 - Engineering Case #720564)================
If the MobiLink client (dbmlsync) was running on a schedule, the MobiLink
Server could not be located, and dbmlsync did not know the status of the
last synchronization, it was possible for dbmlsync to have shut down. The
problem is now fixed, and dbmlsync will remain running on a schedule, even
if the MobiLink Server cannot be located.
================(Build #3791 - Engineering Case #719080)================
If the MibiLink client executable (dbmlsync) had been located in a directory
that was specified in the PATH environment variable that contained two consecutive
backslashes (for example, c:\\sa12\bin64), the Dbmlsync .NET API could have
failed to start the dbmlsync process. This problem has now been fixed.
A workaround to this problem is to set the "server path" property
using the SetProperty method to specify the location of the dbmlsync executable.
================(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 #4436 - Engineering Case #800928)================
There was a potential security vulnerability with MobiLink clients and the
Relay Server Outbound Enabler when synchronizing through HTTP proxies. This
has been fixed.
================(Build #4307 - Engineering Case #788219)================
It was possible that when a synchronization with HTTP or HTTPS failed, a
duplicate HTTP request could have been sent to the server. This would most
likely have lead to a sync failure, but there was a small chance that this
could cause data corruption. This has now been fixed.
================(Build #4083 - Engineering Case #759243)================
In some situations, it was possible for an HTTPS synchronization to fail,
though no actual stream error code would have been reported. This has been
fixed.
================(Build #3871 - Engineering Case #734839)================
In rare circumstances, a MobiLink client using HTTP would have ignored bytes
sent down by the MobiLink server during a download and requested that the
MobiLink server resend them. This has been fixed.
================(Build #3842 - Engineering Case #728863)================
A MobiLink client using HTTP could have hung, or an error could have been
reported, when it automatically attempted to reestablish a lost connection.
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 #4380 - Engineering Case #795422)================
Clients could have crashed the MobiLink server after successfully authenticating.
This has been fixed.
================(Build #4150 - Engineering Case #768379)================
The MobiLink server with integrated Outbound Enabler could have crashed.
This has been fixed.
================(Build #4028 - Engineering Case #752347)================
If there were multiple rows in the ml_scripts_modified MobiLink system table,
the MobiLink Server would have failed to start and reported a primary key
violation on the ml_scripts_modified table. This has now been fixed.
A workaround is to manually remove all but one row from ml_scripts_modified
table before starting the MobiLink Server.
================(Build #4010 - Engineering Case #750713)================
When trying to start an evaluation edition of the MobiLink server, it would
fail with the following error:
[-10382] The MobiLink Server has failed to start
This problem has now been fixed.
================(Build #3998 - Engineering Case #749407)================
If the connection between the MobiLink Notifier and the consolidated database
had been disconnected, it was possible for the MobiLink Notifier to have
failed to re-connect to the consolidated database. This has now been fixed.
A work around to the issue is to restart the MobiLink Server.
================(Build #3984 - Engineering Case #748531)================
Synchronizations could have spuriously failed if the MobiLink server was
configured to use end-to-end encryption, but the client was not. This has
been fixed.
================(Build #3974 - Engineering Case #747227)================
The MobiLink Server leaked memory when using secure streams on Mac OS X systems.
This has now been fixed.
================(Build #3968 - Engineering Case #745198)================
The ODBC driver could have exhibited inconsistent behavior when calling a
stored procedure with blob parameters. The problem only occurred with data-at-execution-time
blob parameters. Blobs of type Varchar worked correctly, but blobs of type
binary did not. The problem has now been fixed.
================(Build #3967 - Engineering Case #746108)================
The MobiLink server could have crashed when it was trying to upload updates
to tables that contained BLOB columns, if the upload_update script took BLOB
columns in its Where clause and the parameters in the script are specified
by question marks. To prevent the crash, a workaround is to change the question
marks to use named parameters instead. This problem has now been fixed.
================(Build #3887 - Engineering Case #737614)================
If a native thread in the Java VM launched by the MobiLink Server printed
to stdout, it was redirected to the MobiLink log file. If the MobiLink Server
was ready to accept synchronizations when the Java VM attempted to print
to stdout, it was possible that the Java VM could have crashed after printing
the string, which would also have crashed the MobiLink Server. A work around
for this issue is to start the Java VM with the -XtraceFile option, which
will redirect the Java VM stdout to a file instead of the MobiLink log file.
The issue has now been fixed, and the way the Java VM stdout strings are
written to the MobiLink Log has changed. Instead of being posted as errors
to the log with error number -10133, the output is now informational and
has "(JVM): " at the start of the string to identify the source
of the string.
================(Build #3879 - Engineering Case #736044)================
The MobiLink server may have crashed when the MobiLink client connects via
HTTPS via a proxy. Although the likelihood of the crash was extremely low,
it has been corrected.
================(Build #3869 - Engineering Case #734077)================
Synchronizations with large downloads could have been slowed by up to the
liveness timeout when using HTTP, if a network interruption occurred. This
has been fixed.
================(Build #3852 - Engineering Case #731014)================
If the MobiLink server had been started with a command line in which the
maximum number of concurrent database worker threads (-wm option) was a value
less than the initial number of concurrent database worker threads (-w option,
default value 5), then the MobiLink Server would have failed to start. The
MobiLink Server will now print a warning to the MobiLink Server log indicating
that it has reduced the initial number of concurrent database worker threads
to the maximum number of concurrent database worker threads that was specified
on the command line.
================(Build #3848 - Engineering Case #730271)================
Syncs could have failed when using HTTP and using an HTTP intermediary that
was setting a “Connection: Keep-alive” header, but was actually creating
a new connection for each HTTP request. This has now been corrected.
================(Build #3848 - Engineering Case #729427)================
The MobiLink server could have crashed when using HTTP and a misconfigured
HTTP proxy. The server now reports an error and kills the synchronization
when this occurs.
================(Build #3832 - Engineering Case #727360)================
The MobiLink server may have crashed if the upload stream contained updates
for tables with BLOB or spatial columns. Other requirements were that the
updates caused conflict updates, and the script version contained conflict
detection/resolution scripts. This problem is now fixed.
================(Build #3832 - Engineering Case #727357)================
If a version 16 or later MobiLink client connected to a version 12 or earlier
MobiLink server, the server would have printed a confusing error. It will
now print an 'unrecognized version' error.
================(Build #3809 - Engineering Case #723017)================
On Mac OS X 8 systems, the MobiLink Server may have failed to start, with
startup error “Unable to bind socket”. This has been fixed.
================(Build #3761 - 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 #706168)================
The MobiLink Server could have crashed when the http network protocol option
"collect_network_data" was set to 1 (i.e. -x http(collect_network_data=1)
). This has been fixed.
Note, this option was added by Engineering case 696647.
================(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 #4328 - Engineering Case #790656)================
An MLReplay memory overwrite has been fixed.
================(Build #4065 - Engineering Case #756745)================
Simulating the time in between synchronizations when replaying a persistent
connection could have caused the synchronization to timeout. This has been
fixed.
================(Build #3839 - Engineering Case #728261)================
The MobiLink Replay utility (mlreplay) was not sending liveness commands
to the MobiLink server correctly when using HTTP. This has been fixed.
================(Build #3806 - Engineering Case #721582)================
The usage description of the -sv switch for the MobiLink Listener utility
for Windows devices (dblsn), was missing the placeholder of the script version.
This has now been corrected.
================(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 #3793 - Engineering Case #719402)================
Messages generated by the iAS ODBC driver for Oracle could have contained
unreadable characters at the end, if the message length was equal to or greater
than 256 characters.
This problem is now fixed.
================(Build #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 #4443 - Engineering Case #801280)================
A .NET application could have received a NullReferenceException when calling
ClearAllPools or ClearPool in a multithreaded application.
Also, a .NET application could have gneo into an infinite loop if the database
server was shut down while the .NET application was executing SQL statements.
These problems have been fixed.
================(Build #4433 - Engineering Case #800698)================
Some of the SQL Anywhere .NET Data Provider Database (class) and DbProviderServices
(class) methods may have failed if the underlying Table property was null.
The methods that may have failed include Database.Exists, Database.Delete,
Database.Create, Database.CreateIfNotExists, DbDatabaseExists, DbDeleteDatabase,
DbCreateDatabase, and
DbCreateDatabaseScript. These Database methods are used in Entity Framework
applications. This problem has been fixed.
The following example code fragment illustrates the use of some of these
methods:
using (var db = new BloggingContext())
{
Console.WriteLine("Delete the old database");
db.Database.Delete();
}
using (var db = new BloggingContext())
{
Console.WriteLine("Create a new database");
db.Database.Create();
if (db.Database.Exists())
{
Console.WriteLine("The database does exist");
}
else
{
Console.WriteLine("The database does not exist");
}
}
================(Build #4431 - Engineering Case #800621)================
If a .NET connection had been pooled and was currently closed, and the database
server was terminated while the pooled connection was closed, then an attempt
to open the pooled connection would have resulted in an infinite loop. This
has now been fixed.
Note, the problem was introduced by the changes for Engineering case 793308
- "Slow performance of ADO.NET connection pooling"
================(Build #4402 - Engineering Case #797203)================
When using the SQL Anywhere .NET provider, it was possible to get an exception
when closing a pooled connection. The exception error text was “Invalid user
ID or password”.
This exception could have occurred for any condition where a connection
was not returned to a pool, for example, when a password had changed. The
complete list of conditions for which a connection is not pooled are described
at http://dcx.sap.com/index.html#sqla170/en/html/814d6d5c6ce2101482c9b5abd7938330.html.
This problem has been fixed. The .NET application will no longer see the
exception, and the connection is closed but not pooled.
================(Build #4401 - Engineering Case #797124)================
When using the SQL Anywhere .NET provider, it was possible to get a NullReferenceException
when calling ClearAllPools. This exception could have occurred in multithreaded
.NET applications that open or close pooled connections while another thread
calls ClearAllPools. This problem has been fixed. The .NET application will
no longer see the exception.
================(Build #4359 - Engineering Case #793308)================
The performance of the ADO.NET connection pool was slow compared to the .NET
ODBC bridge. Several changes have now been made to improve the performance.
================(Build #4355 - Engineering Case #793189)================
When attempting to call a stored procedure with many parameters with long
names, an error could have been returned indicating that parameters were
mismatched.
For example, when attempting to call a stored procedure with 99 very long
parameter names:
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_2",
10);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_1",
5);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_55",
550);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_54",
"string");
.
.
.
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_98",
980);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_97",
970);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_99",
990);
SADataReader myDataReader = myCommand.ExecuteReader();
the SQL Anywhere .NET provider should have matched parameter names with
actual parameter names so order should not have mattered. The provider was
not setting aside enough memory for the parameter name lookup, resulting
in matching by order rather than name.
This problem has been fixed.
================(Build #4321 - Engineering Case #785764)================
When using the .NET GetSchemaTable() method for a query on a table whose
name was not unique, an exception could have occurred in the provider. This
problem has been fixed.
For example, suppose the following query was executed against the table
“employees” owned by DBA, and there also exists a table “Employees” owned
by the user GROUPO.
SACommand cmd = new SACommand("SELECT * FROM DBA.employees", conn);
SADataReader reader = cmd.ExecuteReader();
DataTable schema = reader.GetSchemaTable();
An exception was raised in the GetSchemaTable call. When the tables have
the same letter case, then an exception would not have occurred but the wrong
schema information could have been returned.
================(Build #4315 - Engineering Case #787963)================
The .NET Data Provider would have generated an exception when attempting
to connect to a database server that had more than two digits in the minor
version. For example, the provider would have generated System.ArgumentOutOfRangeException
parsing the following version string:
SAP IQ/16.0.101.1215/20034/P/sp10.01/…
This problem has been fixed.
The normalized version string that is returned by the ServerVersion property
now has the following format:
##.##.###.####
^ ^ ^ ^
| | | |
| | | Build Number
| | Minor Version
| Major Version
Release Version
This new format is also used in the DataSourceInformation collection (DataSourceProductVersion
and DataSourceProductVersionNormalized).
================(Build #4299 - Engineering Case #787422)================
The changes for Engineering case 766113 caused the .NET Data Provider to
attempt to set the CHAINED option to ON when connecting to the utility database.
This resulted in the error “Permission denied: you do not have permission
to execute a statement of this type” when connecting to the utility database,
due to this option being disallowed for the utility database. This problem
has now been fixed.
================(Build #4224 - Engineering Case #776249)================
A .NET application could have crashed when calling the SACommand.Cancel method.
This has been corrected.
================(Build #4209 - Engineering Case #776895)================
In the Entity Framework Data Model Wizard “Choose Your Database Objects and
Settings” dialog, the SQL Anywhere .NET Data Provider did not return stored
procedure and function names in the “Stored Procedures and Functions” list
view for a case-sensitive database. This problem has been corrected.
================(Build #4188 - Engineering Case #773894)================
When an ADO.NET application enlisted with a transaction coordinator, a constant
GUID was supplied by the SQL Anywhere ADO.NET Data Provider. This prevented
additional .NET applications, running on the same system, from doing the
same. The following error message may have been seen.
"A resource manager with the same identifier is already registered
with the specified transaction coordinator. (Exception from HRESULT: 0x8004D102)"
This problem has now been fixed so that instead of a constant GUID, a new
one is generated each time enlistment occurs.
================(Build #4169 - Engineering Case #771708)================
When using the SQL Anywhere .NET Data Provider, if the BulkCopyTimeout property
was set to 0, an exception would have occurred during a call to WriteToServer.
This has been fixed. The value 0 means that there is no timeout.
================(Build #4162 - Engineering Case #770760)================
Visual Studio 2012/2013 would have failed to generate a Entity Framework
6 data model using a SQL Anywhere database. This has been corrected.
The steps for generating Entity Framework 6 data models (Entity Framework
6 Tools for Visual Studio 2012 & 2013 should be installed):
- Run SetupVSPackage.exe with “/v 6” option to register the Entity Framework
6 Provider.
- Install Entity Framework NuGet Package for the Visual Studio project.
- Modify app.config file to add the Entity Framework 6 provider. Here’s
an example:
<providers>
<provider invariantName="iAnywhere.Data.SQLAnywhere"
type="iAnywhere.Data.SQLAnywhere.SAProviderServices, iAnywhere.Data.SQLAnywhere.EF6,
Version=16.0.0.20144, Culture=neutral, PublicKeyToken=f222fc4333e0d400"
/>
- Build the Visual Studio project.
- Run Entity Data Model Wizard.
================(Build #4143 - Engineering Case #768174)================
When using the SQL Anywhere .NET Data Provider, decimal values would have
been displayed with trailing zeroes removed. For example, instead of 5.1000,
it would have been displayed as 5.1. This was an unintentional change in
behavior which has now been corrected.
================(Build #4132 - Engineering Case #766113)================
The ADO.NET provider would not have been able to roll back a transaction
if CHAINED option was OFF. This has ben fixed by setting CHAINED option to
ON after opening a database connection.
================(Build #4131 - Engineering Case #766511)================
In Visual Studio, incorrect major version information for the SQL Anywhere
plugin may have been shown in the "Choose Data Source" and "Add
Connection" dialogs on non-English systems. This has been corrected.
================(Build #4128 - Engineering Case #766115)================
Visual Studio 2013 integration was not supported. SetupVSPackage has now
been modified to create registry keys for Visual Studio 2013.
================(Build #4124 - Engineering Case #765334)================
In a .NET application, a buffer overrun could have resulted when using an
SADataReader to get the value of a very long column value.
Example:
SELECT SPACE(1147483643) FROM dummy
The possible buffer overrun has been corrected.
================(Build #4122 - Engineering Case #765332)================
If the alias name in a SQL statement was longer than 128 characters, a SQL
Anywhere .NET data provider client application could have crashed.
Example:
SELECT 'string' AS "alias...name" FROM dummy
Similarily, if a SQL column expression contained more than 128 characters,
a .NET client application could have crashed.
Example:
SELECT 1+2+3+...+1000 FROM dummy
These problems have been fixed. Alias and expression names are now restricted
to at most 128 characters by the SQL Anywhere .NET data provider.
As a work-around for the first case, restrict the length of alias names
to at most 128 characters.
Example:
SELECT 'string' AS expr FROM dummy
As a work-around for the second case, use an alias name and restrict the
length of its name to at most 128 characters.
Example:
SELECT 1+2+3+...+1000 AS expr FROM dummy
================(Build #4093 - Engineering Case #760873)================
Named parameter lookup performed poorly. The GetInputParameterValues method
has now been rewritten to improve the speed of named parameter lookup.
================(Build #4089 - Engineering Case #759830)================
An application using the ADO.Net Manager Provider could have failed with
the error “Unable to load DLL ‘dbdata16.dll’” when calling SAConnectionStringBuilder.ToString.
Ths has now been corrected.
================(Build #4072 - Engineering Case #758073)================
The Visual Studio 2010 compiler could have crashed when generating Entity
Data Models. This has now been fixed.
================(Build #4033 - Engineering Case #746767)================
In a .NET application, it was possible to store a decimal number into a NUMERIC/DECIMAL
table column when the precision of the decimal number exceeded the precision
of the NUMERIC/DECIMAL column by 1.
Also, when the stated precision of a decimal value parameter was much less
than the actual precision of a decimal value, it is possible to corrupt the
heap.
parm.Precision = 5;
parm.Value = (decimal) 123456789;
These problems have now been fixed.
================(Build #4030 - Engineering Case #751207)================
Using SACommandBuilder.DeriveParameters with a stored procedure or function
that contained long data values as input or output parameters would have
reported the size as 32767 bytes. This has been fixed and will now report
a size of 0 bytes (to use the maximum size of the long data value during
binding) instead.
================(Build #4016 - Engineering Case #750915)================
The SABulkCopy method would have thrown an exception when using SQL Server
as the data source. This has now been corrected.
================(Build #4002 - Engineering Case #750008)================
In a multithreaded ADO.NET application, there was a possibility for process
execution to hang, or for an exception to occur. Three problems were identified
and corrected.
================(Build #3996 - Engineering Case #749295)================
The Dispose function of SATransaction did not automatically do a rollback.
This nhas now been corrected.
================(Build #3979 - Engineering Case #747334)================
A client application could have hung when opening a pooled connection following
a failed connection. This has now been fixed.
================(Build #3978 - Engineering Case #747308)================
The Entity Framework method Import would have failed to find procedures if
the procedures had comments in front of ‘ALTER PROCEDURE’. This has now been
corrected.
================(Build #3971 - Engineering Case #746575)================
When a .NET application disconnected and then reconnected to the server,
the timestamp_with_time_zone_format option was not re-established to the
required .NET default ('YYYY-MM-DD HH:NN:SS.SSSSSS+HH:NN'). When the connection
is pooled, the server resets server options to their defaults. When a connection
was retrieved from the connection pool, the SQL Anywhere .NET provider must
re-issue a SET TEMPORARY OPTION statement. This lead to a DateTimeOffset
(timestamp with time zone) conversion error at run-time.
A work-around is to execute a ...
SET OPTION PUBLIC.timestamp_with_time_zone_format = 'YYYY-MM-DD HH:NN:SS.SSSSSS+HH:NN'
statement which sets the default required for all .NET connections.
This problem has been fixed.
================(Build #3969 - Engineering Case #746082)================
When an application using ADO.NET had disconnected all of its connections
so that they were pooled, an autostarted database, and/or server, could have
autostopped, causing the server to need to be autostarted again if the same
application connected again. This has been fixed so that in most cases, the
presence of a pooled ADO.NET connection will prevent the server from autostopping.
Note that in cases where pooled connections cannot be reused (for example,
connections using integrated login, or the user's password was changed),
the database and/or server may still autostop even with this fix.
================(Build #3941 - Engineering Case #743743)================
When an ADO.NET connection was closed and returned to the connection pool
by the SQL Anywhere .NET Data Provider, the connection name was cleared.
However, when the pooled connection was reclaimed from the pool, the ConnectionName
was not restored. This problem has now been corrected.
================(Build #3939 - Engineering Case #739247)================
When a new SAConnectionStringBuilder object was created and used by each
SAConnection object in a loop, performance was slow. Performance has now
been improved.
================(Build #3938 - Engineering Case #743048)================
Opening of pooled connections was taking longer than necessary. Open performance
of pooled connections has now been improved by caching and reusing some internal
values.
================(Build #3937 - Engineering Case #742857)================
When reading Long Varchar or Long Binary columns using SADataReader, the
results could have been truncated to 65535 chars. This has now been fixed.
================(Build #3932 - Engineering Case #742543)================
When iterating through the parameters of a SACommand using “foreach (SAParameter
param in command.Parameters)”, the first iteration would have worked, but
subsequent iterations would not have had the parameters. This has now been
corrected.
================(Build #3924 - Engineering Case #741707)================
An access violation exception in the ADO.NET provider could have caused the
database server to crash. This has been fixed.
================(Build #3923 - Engineering Case #741704)================
The changes for Engineering case 735654 were incomplete. Using a 11.0.1 database
with a 12.0.1 or 16.0.0 .net provider and server, could still have resulted
in the exception " Invalid option 'timestamp_with_time_zone_format'
-- no PUBLIC setting exists". This has now been corrected.
================(Build #3922 - Engineering Case #741721)================
Calling the SAConnection.ConnectionString property could have caused the
provider to crash with a NullReferenceException. This has now been fixed.
================(Build #3914 - Engineering Case #740695)================
The ADO.NET provider could have thrown an exception when closing a pooled
connection which used an integrated login. This has now been fixed.
================(Build #3910 - Engineering Case #740808)================
Multithreading .NET application could have failed with an access violation
exception. Fixed by modifying thread synchronization code for some interface
functions, and code for managed connection pooling.
================(Build #3901 - Engineering Case #738415)================
Use of connection pooling could have caused web applications to hang. This
has been corrected.
================(Build #3895 - Engineering Case #738381)================
Changes have been made to improve performance for connection pooling.
================(Build #3895 - Engineering Case #733902)================
The ADO.NET provider for .NET 4.0 was requiring assemblies from .NET 4.5
and would not run properly. This has now been fixed.
================(Build #3893 - Engineering Case #738144)================
In rare circumstances, calling SAConnection could have throw a NullReferenceException
when the ConnectionString property was accessed. This has now been fixed.
================(Build #3892 - Engineering Case #738143)================
In rare circumstances, the ADO.NET Provider could have thrown an AccessViolationException
when reading a DataSet. This has now been fixed.
================(Build #3884 - Engineering Case #737191)================
The MSSqlToSA.xml mapping file is used by the SQL Server Import and Export
Data wizard (DTSWizard). This mapping file has now been improved in the following
ways:
- other SQL Server clients (SQLOLEDB;SQLNCLI;SQLNCLI10) are now included
in the list of possible data sources, in addition to the existing SQL Server
.NET provider.
- "datetimeoffset" is now mapped to "timestamp with time
zone" instead of "datetimeoffset", because the Microsoft DTSWizard
would append "(0)" to "datetimeoffset" and that would
cause a syntax error when the CREATE TABLE statement was executed against
a SQL Anywhere / Sybase IQ server. For example, "CREATE TABLE Temp (dtocol
datetimeoffset(0) )" is invalid syntax.
- “float” is now mapped to “double”, instead of float. This causes the
Microsoft DTSWizard to use "real" for small precision float types,
and "double" for large precision float types. When “float” was
used, Microsoft did not add the precision specification (for example, float_col
float(53)).
These improvements apply to the use of the SQL Anywhere .NET or the SQL
Anywhere OLE DB providers, in combination with a number SQL Server providers,
in the migration of tables from SQL Server to SQL Anywhere/Sybase IQ.
================(Build #3876 - Engineering Case #735923)================
Calling SAConnection.Open would have thrown an exception when attempting
to open the 'utility_db'.
================(Build #3876 - Engineering Case #735815)================
Calling the SAConnection.Close method would have thrown an exception when
closing pooled version 10.0 and version 11.0 database connections.
================(Build #3876 - Engineering Case #735807)================
Closing a pooled connection could have been blocked when the request was
from a multi-threaded application. This has been fixed.
================(Build #3876 - Engineering Case #735654)================
The SAConnection.Open method would have thrown an exception when opening
a version 10.0 or 11.0 database connection using the version 12.0 or 16.0
provider. This has now been corrected.
================(Build #3873 - Engineering Case #735130)================
Using the Entity Framework in an ASP.NET MVC application could have caused
a NullRferenceException. The provider was not checking if the Type.FullName
was null before calling the method Type.FullName.StartsWith. This has been
corrected.
================(Build #3873 - Engineering Case #735124)================
Calling the Entity Framework function CurrentDateTimeOffset would have resulted
in a 'procedure not found' server error. This has now been corrected.
================(Build #3856 - Engineering Case #731461)================
ADO.NET provider did not convert ‘timestamp with timezone’ values correctly
when the regional date settings of the client did not match the date settings
of the database. The provider will now return .NET DateTimeOffset values
to the client. The client can then convert the .NET DateTimeOffset values
to a desired format.
================(Build #3851 - Engineering Case #730642)================
If multiple threads attempted to access a connection pool concurrently (by
modifying it to add/remove a connection), an InvalidOperationException would
have been thrown. This has been corrected.
================(Build #3842 - Engineering Case #728589)================
Calling Entity Framework SaveChanges could have caused a NullReferenceException
if the entity model had properties with “fixed” concurrency mode. This has
now been fixed.
================(Build #3840 - Engineering Case #728335)================
When setting SAParameter.DbType to DbType.DateTime2, an IndexOutOfRangeException
could have been thrown. The data type conversion was missing for DbType.DateTime2.
This has now been corrected.
================(Build #3840 - Engineering Case #727729)================
Executing a specific statement involving DateTimeOffset and an empty HashSet
in LINQ against the Entity Framework would have resulted in an "Unknown
EdmType: DateTimeOffset" error. This has now been corrected.
================(Build #3826 - Engineering Case #725854)================
The .NET values of SAParameter have been converted to native types to improve
performance. The native values are now cached and reused if they are not
changed since the last execution of the command. Also, several other changes
have been made to reduce the time for accessing the properties and methods
of SAParameter and SAParameterCollection.
================(Build #3826 - Engineering Case #725849)================
When converting .NET values of SAParameter to native types, the provider
always allocated new unmanaged memory, which may have been slow. To improve
performance, unmanaged memory is now cached and reused.
================(Build #3824 - Engineering Case #725700)================
The performance of the SAParameterCollection.AddParameters method has been
improved.
================(Build #3821 - Engineering Case #724900)================
Temporary tables, functions and variables were not dropped after a pooled
connection was closed (returned to the connection pool). This has now been
corrected.
================(Build #3819 - Engineering Case #723698)================
A client application could recieved the exception OptimisticsConcurrencyException
when updating tables with computed columns. This has now been fixed.
================(Build #3817 - Engineering Case #725821)================
The Entity Framework reference in the ADO.NET v4 provider for the 12.0.1.3797
EBF incorrectly refered to the Entity Framework 5.x assemblies. This has
been fixed.
Also, version support for the ADO.NET v4 provider to the Entity Framework
is now limited to Entity Framework versions 4.4.x and up.
================(Build #3813 - Engineering Case #721637)================
An ADO .Net application could have failed to fetch from a proxy table with
blob columns. The error returned would have been: “Cursor is restricted to
FETCH NEXT operations”. This problem has now been fixed.
================(Build #3809 - Engineering Case #721757)================
The Password field in the connection string (file App.config) could have
been inadvertently removed during execution when running the Entity Framework
application. This problem has been fixed.
================(Build #3805 - Engineering Case #719758)================
The .Net Provider could have incorrectly thrown an "Unknown PrimitiveTypeKind
DateTimeOffset" exception. This has been fixed.
================(Build #3792 - Engineering Case #719112)================
Data conversion errors could have occurred when passing DateTimeOffset parameters
to a stored procedure using the Entity Framework function import. This problem
has been fixed.
================(Build #3790 - Engineering Case #718762)================
The “Function Import” construct within the Entity Framework would have failed
with a NullReferenceException for return types of "None". This
problem has been fixed.
================(Build #3790 - Engineering Case #718761)================
SABulkCopy would have failed with an OutOfMemoryException when copying large
tables using a DataReader. This problem has been fixed.
================(Build #3789 - Engineering Case #717363)================
The ADO.NET provider was generating inefficient queries, using CHARINDEX,
for some Entity Framework functions, such as StartsWith, EndsWith, and Contains.
This problem has been fixed.
================(Build #3787 - Engineering Case #718046)================
When creating an ADO.NET Entity Data Model using an existing stored procedure,
some of the SQL Anywhere data types were not mapped correctly. This would
have been seen when clicking the "Get Column Information" button
in the "Add Function Import..." dialog. This has been corrected.
================(Build #3776 - Engineering Case #716390)================
N ADO .Net client application could have received a NullReferenceException
when updating entities using Fixed concurrency mode. This problem has been
fixed.
================(Build #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 #4441 - Engineering Case #801193)================
32-bit client applications running on SPARC systems would have crashed when
connecting to the server. This has been fixed.
================(Build #4376 - Engineering Case #795135)================
If a connection string contained a START= parameter which included an -ec
or -xs option containing a path and filename with spaces, a parsing error
could have been given even if the value was enclosed in quotes.
For example: UID=…;PWD=…;DBF=mydatabase.db;START=dbeng17 -xs “https(identity=my
spacey file.id;identity_password=test)”
This has been fixed.
================(Build #4269 - Engineering Case #783936)================
If the CHARSET connection option was set to a character set other than the
client computer’s OS character set, pieces of the connection_property(‘AppInfo’)
value could have been garbled. This would only have been visible if the hostname,
username, or SQL Anywhere installation directory contained non-ASCII characters.
This has been fixed.
================(Build #4102 - Engineering Case #762254)================
If an application made a standard connection to the server, and a second
connection through the dbtools interface (for example, by calling the DBUnload
function), and both connections used TLS with FIPS, the application could
have crashed. This has been fixed.
================(Build #3934 - Engineering Case #742862)================
On Windows systems, if the database server address cache file (sasrv.ini)
was not writable by the current user, repeated connection attempts to a non-cached
server may have been slow. This has been fixed.
================(Build #3842 - Engineering Case #728789)================
If the SQLCONNECT environment variable was used to specify default connection
values, and the length of the SQLCONNECT value was greater than or equal
to 255 bytes, the SQLCONNECT value was ignored. This has been fixed so that
SQLCONNECT values up to a length of 1023 bytes are accepted.
================(Build #3833 - Engineering Case #725206)================
A FETCH RELATIVE {offset}, where the offset was greater than 1, could have
failed with a "Connection was terminated" error if the fetch was
not the first fetch on the cursor, and prefetch was enabled for the fetch.
For this to have ocurred, the rows between the last fetch and the requested
rows row had to have values that were greater than 250 bytes. This has been
fixed.
As a workaround, prefetch can be disabled.
================(Build #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 #4471 - Engineering Case #802981)================
When a JDBC application had called getColumns or getProcedureColumns of the
DatabaseMetaData class, some returned metadata information were incorrect:
DatabaseMetaData meta = conn.getMetaData();
ResultSet columns = meta.getColumns(null, null, "AllTypes", null);
- COLUMN_SIZE for numeric types is the precision, or number of digits, that
can be represented. It does not include the sign. The COLUMN_SIZE reported
for BIGINT, UNSIGNED BIGINT, UNSIGNED INT, and UNSIGNED SMALLINT were incorrect.
This have been corrected from byte length to numeric precision. COLUMN_SIZE
for INTEGER, TINYINT, and SMALLINT is unchanged.
- DECIMAL_DIGITS for all exact numeric types other than SQL_DECIMAL and
SQL_NUMERIC is 0. The DECIMAL_DIGITS reported for BIGINT, UNSIGNED BIGINT,
UNSIGNED INT, and UNSIGNED SMALLINT were NULL. This has been corrected to
0.
- DECIMAL_DIGITS for SQL_TYPE_TIME and SQL_TYPE_TIMESTAMP is the number
digits in the fractional seconds component. The DECIMAL_DIGITS reported for
TIME and TIMESTAMP WITH TIME ZONE were NULL. This has been corrected to 6.
- CHAR_OCTET_LENGTH is the maximum length in bytes of a character or binary
data type column. The CHAR_OCTET_LENGTH for TIMESTAMP WITH TIME ZONE were
NULL. This has been corrected to 33.
================(Build #4270 - Engineering Case #784055)================
A JDBC application could have found that fetching result sets with long varchar,
long nvarchar or long binary columns took much longer with a scrollable cursor
(i.e. an insensitive or sensitive statement) when compared to a non-scrollable
cursor (i.e. a forward only statement). This difference in performance was
most noticeable if most of the long values were smaller than 256K. The performance
issue has now been fixed and scrollable cursors now perform as well as non-scrollable
cursors.
================(Build #4172 - Engineering Case #772022)================
If an application fetched a result set that contained long varchar, long
binary or long nvarchar columns, then the SQL Anywhere JDBC driver would
have fetched the result set one row at a time in order to ensure the full
column value of the long columns could be retrieved. For result sets that
do not contain long columns, the SQL Anywhere JDBC Driver fetched multiple
rows at a time instead. Applications can use the Statement.setMaxFieldSize()
method to attempt to limit the amount of data the JDBC Driver retrieves,
however calling this method did not make the JDBC driver fetch multiple rows
at a time. The SQL Anywhere JDBC driver will now fetch multiple rows at a
time for result sets that contain long columns if Statement.setMaxFieldSize()
is called and the value passed in to setMaxFieldSize() is less than or equal
to 32K. The behaviour for result sets that do not contain long columns remains
the same and the JDBC driver will continue to fetch multiple rows at a time
for these result sets.
================(Build #4148 - Engineering Case #768718)================
When using the JDBC driver in a multithreaded Java application on Windows,
a crash may have occurred in the heap management run-time code (HeapFree).
This problem also appeared when using the MobiLink Profiler, since it uses
the JDBC driver. This problem has been fixed.
================(Build #3981 - Engineering Case #747898)================
When using the SQL Anywhere JDBC driver, if two or more addBatch calls are
followed by an executeBatch and then the application used executeUpdate in
non-batched mode, the application would have crashed. This problem has been
fixed.
A work-around is to use addBatch/executeBatch for all executions of the
prepared statement once addBatch/executeBatch has been used.
================(Build #3866 - Engineering Case #733726)================
If an application using the SQL Anywhere JDBC Driver failed to explicitly
close all open connections before attempting to exit, then there was a chance
the Java VM would have crashed. This was most noticeable on Unix platforms.
This problem has now been fixed.
================(Build #3861 - Engineering Case #732853)================
Attempting to create a Mobilink project using Sybase Central on a 64-bit
platform could in some cases have caused Sybase Central to crash. This problem
was most noticeable on Solaris and Mac platforms. The problem has now been
fixed.
================(Build #3851 - Engineering Case #722245)================
Calling PreparedStatement.setNull() and passing in a SQL type of java.sql.Types.NULL,
would have incorrectly returned a “bad datatype” error. This problem has
now been fixed and java.sql.Types.NULL is now allowed in setNull() calls.
================(Build #3847 - Engineering Case #730024)================
The SQL Anywhere JDBC Driver would have incorrectly throw a “Not Implemented”
exception when PreparedStatement.setNull() was called with either java.sql.Types.BLOB
or java.sql.Types.CLOB. This problem has now been fixed.
================(Build #3847 - Engineering Case #730023)================
The SQL Anywhere JDBC Driver would have thrown a SQLException with a “Not
Implemented” message when calling an optional JDBC method that was not supported
by the JDBC Driver. This has been corrected so that the JDBC 4.0 SQL Anywhere
JDBC Driver now throws the new SQLFeatureNotSupportedException. Since SQLFeatureNotSupportedException
is a JDBC 4.0 feature, the JDBC 3.0 Driver will continue to throw a SQLException
instead.
================(Build #3845 - Engineering Case #729396)================
Attempting to fetch the “PRECISION” column of the DatabaseMetaData.getTypeInfo()
result set, using one of the ResultSet.getXXX( String ) methods, would have
resulted in the incorrct error: “column number 0 is invalid”. Using one of
the ResultSet.getXXX( int ) methods would have worked fine. This problem
has been fixed.
================(Build #3821 - Engineering Case #725201)================
If an application loaded the SQL Anywhere JDBC Driver into a private ClassLoader,
there was a small chance that the application would have crashed when the
private ClassLoader was garbage collected. This problem has now been fixed.
================(Build #3795 - Engineering Case #719089)================
A JDBC application that connected using the SQL Anywhere JDBC driver, and
then subsequently exited with a large number of connections still open, could
in rare cases crash or hang. This problem has now been fixed.
================(Build #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 #4473 - Engineering Case #803007)================
When an ODBC application had called SQLColAttribute, SQLColumns, SQLProcedureColumns,
or SQLGetTypeInfo, some returned metadata information were incorrect:
- FLOAT, REAL, and DOUBLE are approximate numeric data types so the SQL_DESC_NUM_PREC_RADIX
is 2 and the SQL_DESC_PRECISION field must contain the number of bits. For
FLOAT, REAL, and DOUBLE columns, SQLGetTypeInfo returns a NUM_PREC_RADIX
of 2. The reported COLUMN_SIZE were 15, 7, and 15 respectively which represents
base 10 precision. The COLUMN_SIZE has been corrected to 53, 24, and 53 respectively
which represents base 2 precision.
- For TIME columns, SQLGetTypeInfo must return a COLUMN_SIZE equal to 9
+ s (the number of characters in the hh:mm:ss[.fff...] format, where s is
the seconds precision). For SQL Anywhere, s is 6. For TIME columns, SQLGetTypeInfo
reported the COLUMN_SIZE as 8. The COLUMN_SIZE has been corrected to 15.
Corresponding corrections have been made to SQLColumns, and SQLProcedureColumns:
- SQLColAttribute(SQL_DESC_PRECISION) must return the precision in bits
when SQL_DESC_NUM_PREC_RADIX is 2. For REAL columns, 7 were reported. This
has been corrected to 24. For FLOAT and DOUBLE columns, 15 were reported.
This has been corrected to 53.
- SQLColAttribute(SQL_DESC_LENGTH) must return the PRECISION descriptor
field for all numeric types. For TIME, it must return 15 (9+6 fractional
seconds). For REAL columns, 7 were reported. This has been corrected to 24.
For FLOAT and DOUBLE columns, 15 were reported. This has been corrected to
53. For TIME columns, 8 were reported. This has been corrected to 15.
- SQLColAttribute(SQL_DESC_DISPLAY_SIZE) must return the maximum number
of characters required to display data from the column. For REAL, it is 14.
For FLOAT and DOUBLE, it is 24. For TIME, it is 9 + s (a time in the format
hh:mm:ss[.fff...], where s is the fractional seconds precision). For SQL
Anywhere s=6. For REAL columns, 13 were reported. This has been corrected
to 14 (for example, -3.40282347e+38). For FLOAT and DOUBLE columns, 22 were
reported. This has been corrected to 24 (for example, -1.7976931348623150e+308).
For TIME columns, 8 were reported. This has been corrected to 15 (for example,
23:59:59.999999).
These corrections also appear for corresponding metadata methods in the
SQL Anywhere JDBC driver.
================(Build #4471 - Engineering Case #802980)================
When an ODBC application had called SQLColumns or SQLProcedureColumns, some
returned metadata information were incorrect:
- COLUMN_SIZE for numeric types is the precision, or number of digits, that
can be represented. The COLUMN_SIZE reported for BIGINT, UNSIGNED BIGINT,
UNSIGNED INT, and UNSIGNED SMALLINT were incorrect. This have been corrected
from byte length to numeric precision. COLUMN_SIZE for INTEGER, TINYINT,
and SMALLINT is unchanged.
- DECIMAL_DIGITS for all exact numeric types other than SQL_DECIMAL and
SQL_NUMERIC is 0. The DECIMAL_DIGITS for BIGINT, UNSIGNED BIGINT, UNSIGNED
INT, and UNSIGNED SMALLINT were NULL. This has been corrected to 0.
- DECIMAL_DIGITS for SQL_TYPE_TIME and SQL_TYPE_TIMESTAMP is the number
digits in the fractional seconds component. The DECIMAL_DIGITS for TIME and
TIMESTAMP WITH TIME ZONE were NULL. This has been corrected to 6.
- CHAR_OCTET_LENGTH is the maximum length in bytes of a character or binary
data type column. The CHAR_OCTET_LENGTH for TIMESTAMP WITH TIME ZONE were
NULL. This has been corrected to 33.
================(Build #4455 - Engineering Case #802217)================
When an ODBC application calls SQLGetInfo with the SQL_IDENTIFIER_QUOTE_CHAR
option, the SQL Anywhere ODBC driver returns the single character SPACE as
a string (" ") when the database option quoted_identifier has been
set OFF.
If the database contains identifiers with spaces (for example, a table named
“My Appointments”), then the name must be quoted using double quotation marks
("), back ticks (`), or brackets ([]). However, when quoted_identifier
has been set OFF, then one of the latter two quoting mechanisms must be used
for “spacey” identifiers since "abc" is equivalent to 'abc' in
this mode. The following example shows an acceptable way to quote a spacey
table name, when quoted_identifier has been set OFF:
SELECT * FROM [My Appointments];
If you use an ODBC-based application that generates SQL (for example, Crystal
Reports), and quoted_identifier has been set OFF (perhaps inadvertently),
the generator might create an invalid SQL statement such as the following
since the “quote” character was reported to be a space character.
SELECT * FROM My Appointments;
This problem has been fixed. The ODBC driver will now return the back tick
character as a string ("`") for version 12 or later databases when
quoted_identifier has been set OFF. This means that the SQL generator might
build the following query, provided it uses SQLGetInfo( SQL_IDENTIFIER_QUOTE_CHAR
) to obtain the quoting character.
SELECT * FROM `My Appointments`;
Also, when SQL_ATTR_METADATA_ID has been set TRUE, catalog functions now
accept the quoting of identifiers as parameters using back ticks. Catalog
functions include SQLTables(), SQLColumns(), SQLTablePrivileges(), and so
on. Previously, only double quotes and brackets were supported.
================(Build #4423 - Engineering Case #799787)================
The 17.0 SQL Anywhere database server now supports server-side autocommit.
In general, the use of server-side autocommit improves the performance of
applications. However, there are some 3rd-party frameworks, like Hibernate,
that wrap SQL statement execution in (using JDBC as an example) setAutoCommit
calls. This is equivalent to the following sample JDBC code sequence.
while( iterations-- > 0 )
{
conn.setAutoCommit( true );
stmt.execute( sql_statement );
conn.setAutoCommit( false );
}
When connected to a 17.0 database server, such a construct results in suboptimal
performance because each call to the JDBC setAutoCommit method sends a “SET
TEMPORARY OPTION auto_commit=’ON’ (or ‘OFF’) to the database server for execution.
This problem has been fixed. A new connection parameter, ClientAutocommit=yes,
can be used to cause the client JDBC- or ODBC-based application to revert
to client-side autocommit behavior. Setting ClientAutocommit=no corresponds
to the default behavior. Note that the ClientAutocommit connection parameter
can be used with version 17.0, 16.0, or 12.0.1 ODBC drivers but it has no
effect if the database server does not support server-side commits (e.g.,
16.0 or 12.0.1 servers).
Of course, a work-around for better performance would be to move the setAutoCommit
calls outside the loop. But in some 3rd-part frameworks, this might not be
possible.
conn.setAutoCommit( true );
while( iterations-- > 0 )
{
stmt.execute( sql_statement );
}
conn.setAutoCommit( false );
On Windows, the Advanced tab of the ODBC Configuration for SQL Anywhere
dialog (using the ODBC Data Source Administrator) has been updated to include
this new connection parameter.
================(Build #4423 - Engineering Case #799779)================
The default AUTOCOMMIT behavior for the SQL Anywhere ODBC driver is SQL_AUTOCOMMIT_ON.
Changing the AUTOCOMMIT setting to SQL_AUTOCOMMIT_OFF before connecting to
the data source would have caused the driver to override this setting when
connecting to a database server that supports server-side autocommit (as
version 17 servers do).
The following is a sample ODBC code sequence where this problem occurs.
rc = SQLSetConnectAttr( hdbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_OFF,
0 );
rc = SQLDriverConnect( hdbc, (SQLHWND)NULL, ds, SQL_NTS, scso, sizeof(scso)-1,
&cbso, SQL_DRIVER_NOPROMPT );
This problem has now been fixed. A work-around is to interchange the order
of the SQLSetConnectAttr and the SQLDriverConnect calls.
================(Build #4397 - Engineering Case #796700)================
If a column that is longer than the SQL_ATTR_MAX_LENGTH value (default 256K)
was bound as SQL_C_BINARY and a multi-row fetch was performed, then the ODBC
driver would have crashed.
For example, if the column in the following query was bound as SQL_C_BINARY
and the row array size was 4, then the ODBC driver would have crashed when
attempting to fetch the rowset, provided that the SQL_ATTR_MAX_LENGTH value
was less than 300,000.
select cast(repeat( '0123456789', 30000 ) as long varchar) from sa_rowgenerator(1,4)
This problem has been fixed.
Note, this problem also affects the Interactive SQL utilty (dbisql) when
fetching BINARY columns.
================(Build #4389 - Engineering Case #796090)================
Using the SQL Anywhere ODBC driver, calling SQLGetTypeInfo() would have returned
the following information in the result set when connected to an SAP IQ database
server:
TYPE_NAME=table DATA_TYPE=SQL_VARCHAR COLUMN_SIZE=32767 LP= LS= CREATE_PARAMS=
NULLABLE=1 TYPE_ORDINAL=1
The "table" type is not a suitable SQL_VARCHAR data type declarative
and is not equivalent to the "char" data type. This row should
not appear in the result set.
Using the SQL Anywhere JDBC driver, the DatabaseMetaData.getTypeInfo() call
will also include "table" in the result set when connected to an
SAP IQ database server.
These problems have been fixed.
================(Build #4384 - Engineering Case #795701)================
If the high-order byte in the val field of a SQL_NUMERIC_STRUCT was non-zero,
then the SQL Anywhere ODBC driver may not have converted the numeric value
correctly before sending it to the database server. The column value must
be bound as a SQL_NUMERIC type and be sufficiently large enough in order
for this to have occurred. For example, the representation of 31415926535897932384626433832795028.8419
in a SQL_NUMERIC_STRUCT is such that the high-order byte of the val field
is 0xec. An incorrect value would would have been stored in the table column.
This problem has now been fixed.
================(Build #4335 - Engineering Case #791481)================
When using the SQL Anywhere ODBC driver, the character size, display size,
and octet length information returned by the ODBC functions SQLDescribeCol
and SQLColAttribute were wrong for CHAR(x CHAR) or VARCHAR(x CHAR) columns
when connected to a multi-byte character set (MBCS) database using the “wide”
interface API (UNICODE mode).
Given a table with the following columns.
c_nchar nchar(42),
c_charchar char(42 char),
c_char char(126)
The c_charchar column will hold at most 42 national characters. For example,
a 932JPN database column holds 42 Japanese double-byte characters which requires
at most 84 bytes of memory to store. A UTF-8 database column holds 42 Japanese
double-byte characters which requires at most 168 bytes of memory to store
(4*42=168 is the worst-case scenario for UTF-8 surrogate code points).
For the c_charchar column, character size and display size should be 42.
Character size is the number of characters, not the number of bytes.
For the c_charchar column, the octet length is the maximum number of bytes
required to store these characters in memory on the client (e.g., number
of characters * 2 for double-byte, number of characters * 4 for UTF-8).
For a DBCS database like 932JPN, the ODBC driver reported 84 for the character
size, 84 for the display size, and 84 for the octet length. The character
size and display size were incorrect. There was no problem when the ODBC
application was compiled for and run in ANSI mode (for example, when using
SQLDriverConnectA rather than SQLDriverConnectW).
This problem has now been fixed. For each of the columns noted above, the
following is now reported.
Column 1:
SQLDescribeCol: column name = c_nchar
SQLDescribeCol: data type = SQL_WCHAR
SQLDescribeCol: character size = 42
SQLColAttribute(SQL_DESC_DISPLAY_SIZE): character size = 42
SQLColAttribute(SQL_DESC_LENGTH): character size = 42
SQLColAttribute(SQL_DESC_OCTET_LENGTH): byte size = 168
Column 2:
SQLDescribeCol: column name = c_charchar
SQLDescribeCol: data type = SQL_CHAR
SQLDescribeCol: character size = 42
SQLColAttribute(SQL_DESC_DISPLAY_SIZE): character size = 42
SQLColAttribute(SQL_DESC_LENGTH): character size = 42
SQLColAttribute(SQL_DESC_OCTET_LENGTH): byte size = 84
Column 3:
SQLDescribeCol: column name = c_char
SQLDescribeCol: data type = SQL_CHAR
SQLDescribeCol: character size = 126
SQLColAttribute(SQL_DESC_DISPLAY_SIZE): character size = 126
SQLColAttribute(SQL_DESC_LENGTH): character size = 126
SQLColAttribute(SQL_DESC_OCTET_LENGTH): byte size = 126
================(Build #4328 - Engineering Case #790673)================
When using the version 12 ODBC driver, the SQLTables function incorrectly
identified some system tables and views as TABLE or VIEW instead of SYSTEM
TABLE or SYSTEM VIEW when the connected user did not have DBA authority.
For example, the dbo.syscolumns system view was identified as a VIEW instead
of a SYSTEM VIEW.
This problem has been fixed.
================(Build #4328 - Engineering Case #790651)================
When using the version 12 or 16 ODBC driver, any query that began with the
prefix “insert" was incorrectly categorized as an INSERT statement.
Beginning version 17, any query that began with the prefix “insert",
“update", “delete", or “merge" was incorrectly categorized
as an INSERT, UPDATE, DELETE, or MERGE statement. This problem has been fixed.
Note that the comparison was case-insensitive (insert, Insert, INSERT, etc.
all match).
For example, if the query “updateInventory( 100 )”s executed, the ODBC driver
would have assumed this was an UPDATE statement.
================(Build #4308 - Engineering Case #787903)================
If the StartLine (START) connection parameter contained the string “-n” anywhere
in the text, it is interpreted as if the -n option was specified. This could
have affected the final server name that was chosen.
For example:
dbisql -c "UID=DBA;PWD=sql;START=dbeng16.exe -z -o c:\y-n\output.log;Server=SRV1;
DBN=DBN1;DBF=demo.db"
This problem has been corrected.
================(Build #4305 - Engineering Case #788053)================
If a User Data Source Name (DSN) was created with the same name as a System
Data Source Name, the original System Data Source could not have been examined
or modified using the ODBC Configuration for SQL Anywhere window of the Windows
ODBC Data Source Administrator.
Furthermore, an attempt to modify the System DSN would have always resulted
in a modified version of the User DSN being written over the System DSN.
This problem has been fixed.
As a work-around, the dbdsn/iqdsn tool can be used to create/modify user
and system data sources.
================(Build #4264 - Engineering Case #783369)================
On Unix systems, if an ODBC connection string contained a parameter with
an empty value followed by a DSN parameter (for example “dbn=;dsn=mydsn”),
the DSN would not be read and the connection would have failed. This has
been fixed.
================(Build #4231 - Engineering Case #779772)================
When a user-defined table had the same name as a system table (for example,
SYSINDEX, SYSPROCPARM etc), one or more of the following ODBC functions may
have failed:
SQLForeignKeys
SQLProcedures
SQLSpecialColumns
SQLStatistics
SQLTablePrivileges
SQLTables
This problem has been fixed.
================(Build #4213 - Engineering Case #777061)================
Fetch performance on cursors for which prefetch was enabled may have been
a bit poorer that it should have been when the cursor was using near the
prefetch memory limit (default of 512K per connection). This slowdown was
more likely to have occured when using wide fetch (also called array fetches).
This has been fixed so that the performance in this case is now improved.
================(Build #4157 - Engineering Case #769156)================
Given a simple stored procedure such as the following:
create procedure sp_test( in @a integer, in @b integer )
begin
select @a + @b as c;
end
Binding two host variables and executing “SELECT * FROM sp_test(?, ?)"
just after starting the database server, then the error "Not enough
values for host variables" might have resulted. Subsequent execution
attempts would have succeeded. A similar problem would have occurred when
"SELECT * FROM sp_test(?, ?)" was executed immediately after (dropping
and then) creating the stored procedure. This has now been fixed.
================(Build #4115 - Engineering Case #763867)================
The SQLErrorW, SQLDataSourcesW, and SQLGetDescRecW functions were incorrectly
returning a byte count, rather than a character count. For example, the column
name "ABC" has a character count of 3, but the wide character (Unicode)
string "ABC" occupies 6 bytes. The byte count (6 in this example)
was returned. This has been corrected.
This problem could have also impacted the values returned by SQLError, SQLDataSources,
and SQLGetDescRec if the driver manager called their "wide" equivalents.
This problem is also corrected.
In addition, SQLGetDescRec could return a random field name for a descriptor
when there was no field name (for example, a bookmark column has no field
name). There was also the extremely rare possibility of a segment violation
fault. These problems have been corrected.
================(Build #4115 - Engineering Case #763866)================
The odbc.h header file that was used to compile ODBC applications could have
provided an inconsistent definition of HWND and SQLHWND for 64-bit Windows
and other 64-bit platforms. For 64-bit compilers, the type might resolve
to a 32-bit integer which is incorrect. Window handles, like other handles,
should always be 64-bit pointer-type objects for a 64-bit executable. This
problem has been fixed.
================(Build #4090 - Engineering Case #760362)================
If the SQL Anywhere ODBC driver, or the Sybase IQ ODBC driver version 15.x
or later, was used to connect to a database with the database option 'quoted_identifier'
set to 'off', or to a database on a 9.0.2 or earlier server, the ODBC driver
would have failed to establish some properties of the DBMS.
When quoted_identifier was 'off':
1. For a Sybase IQ DBMS, the driver would have reported [SQL Anywhere] in
messages rather than [Sybase IQ].
2. For a Sybase IQ DBMS, the driver would have reported "SQL Anywhere"
instead of "Sybase IQ" for SQLGetInfo(SQL_DBMS_NAME).
3. For a Sybase IQ DBMS, the driver would not have used the "SYS.SYSIQVINDEX"
table for SQLStatistics, but would have used "SYS.SYSINDEX" instead.
4. For a Sybase IQ DBMS, the ODBC driver will report the wrong server version
number (e.g., 12.0.1 rather than 15.4) for SQLGetInfo(SQL_DBMS_VER).
In addition, when quoted_identifier was 'off' or the server was version
9.0.2 or earlier:
5. The ODBC driver would not have known the correct CHARSET setting.
6. The ODBC driver may have had the wrong setting for the case sensitivity
of the database and may have affected SQLGetTypeInfo and other schema query
functions.
7. The ODBC driver may have had the wrong setting for the odbc_distinguish_char_and_varchar
option.
8. The ODBC driver may have had the wrong setting for the odbc_describe_binary_as_varbinary
option.
Other than these issues, there are no other known side-effects.
This problem has been fixed.
================(Build #4069 - Engineering Case #757516)================
Calling the ODBC function SQLBulkOperations() with SQL_ADD could have failed
to insert rows without returning an error if the number of rows multiplied
by the number of columns was more than 65535. This has been fixed.
================(Build #4051 - Engineering Case #754304)================
In rare, timing dependent cases, a multi-threaded client application could
have incorrectly received the error "Parse Error: DSN '<name>'
does not exist", or possibly other connection errors. In order for
this to have occurred, the process needed to be making concurrent connections
and needed to use both a User DSN and a System DSN. This has been fixed.
================(Build #3915 - Engineering Case #740842)================
When using the ODBC Data Source Administrator to configure a SQL Anywhere
11 ODBC data source, the Database File “Browse” button would have returned
a truncated string. Only the first 7, or 3 characters, of the file path are
returned (depending on bitness). This problem has now been fixed.
================(Build #3867 - Engineering Case #733923)================
The Additional Connection Parameters on the Advanced page of the ODBC configuration
dialog is used to specify rarely used connection parameters that do not appear
on other pages of the wizard. The problem was that once a parameter was
added in this page, it could not have been removed again. The value of the
parameter could have been modified, but could only be deleted by editing
it directly in the registry or by recreating the datasource. This problem
has been fixed.
================(Build #3855 - Engineering Case #731823)================
Calling the ODBC function SQLGetInfo to retrieve the version of the ODBC
driver (i.e. SQLGetInfo( dbc, SQL_DRIVER_VER, … ) would have returned a string
that did not include the build number of the driver. This has been corrected
so that the string now contains the build number. For version 12.0.1, the
string returned was “12.00.0001”. As of this change, the value returned
is “12.01.xxxx” where xxxx is the build number.
================(Build #3812 - Engineering Case #721534)================
If an application made a remote procedure call to an Oracle server, then
the server would have incorrectly forced a commit operation to occur on the
Oracle server. This problem has now been fixed.
================(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 #4388 - Engineering Case #795979)================
When using the SQL Anywhere OLE DB provider, attempting to move forward more
than one record using the Recordset.Move function would have failed if the
cursor type was a forward-only no-scroll cursor. This problem has been fixed.
================(Build #4360 - Engineering Case #793846)================
When using a SQL Anywhere OLE DB Linked Server object from Microsoft SQL
Server, a COMMIT or ROLLBACK of a distributed transaction would have failed.
For example, when attempting to update a row in the Contacts table of the
SQL Anywhere demonstration database using Microsoft SQL Server:
begin tran t2;
update SQLATest.demo.groupo.contacts set surname = surname + t.val
from (select 2 i, '???' val) t where id = t.i;
commit tran t2;
select surname from SQLATest.demo.groupo.contacts where id <= 4;
error messages, including one indicating that the OLE DB provider “reported
an error committing the current transaction”, were displayed. This problem
has now been fixed.
Also fixed are nested transactions using ADO and native SQL Anywhere OLE
DB. Microsoft SQL Server does not support nested distributed transactions.
Note, transactions using Linked Servers are always distributed transactions.
================(Build #3968 - Engineering Case #746688)================
The following improvements and bug fixes have been made to the SQL Anywhere
OLE DB provider:
1. When a column cannot be fetched in its entirety, set status to DBSTATUS_S_TRUNCATED
instead of DBSTATUS_S_OK and length to actual length, not amount fetched.
2. IRowsetUpdate methods InsertRow/Update should insert rows in manual commit
mode (i.e., commit in batches) rather than autocommit each row.
3. Improved support for DBTYPE_DBTIMESTAMPOFFSET data types.
4. In order to identify columns that are DEFAULT AUTOINCREMENT, IColumnsInfo::GetColumnInfo
now sets the DBCOLUMNFLAGS_ISROWVER bit for those columns. Microsoft defines
a column with this attribute as a non-writable versioning column (such as
the SQL Server TIMESTAMP) which suits SQL Server. Note, however, that SQL
Anywhere supports versioning columns that are writable.
5. Corrected failure to describe money/smallmoney as DBTYPE_CY (currency
type). Also corrected OLE DB schema queries DBSCHEMA_COLUMNS, DBSCHEMA_PROCEDURE_COLUMNS,
and DBSCHEMA_PROCEDURE_PARAMETERS results for DBTYPE_CY.
6. Corrections to schema rowset information (DBSCHEMA_COLUMNS, DBSCHEMA_PROCEDURE_COLUMNS,
and DBSCHEMA_PROCEDURE_PARAMETERS) for datetime/time precision and scale.
7. Corrections to “run-time” information for datetime/time precision and
scale.
8. Add "DATETIME" to list of DBPARAMBINDINFO.pwszDataSourceType
types for SetParameterInfo (SQL Server uses this undocumented type name).
Type names are usually of the form “DBTYPE_xxx” (for example, “DBTYPE_I4”,
“DBTYPE_STR”, “DBTYPE_DBTIMESTAMP”).
9. Adjust GetConversionSize values for TIME, DATETIME, DATETIMEOFFSET data
types (only 6 fractional digits are supported by SQL Anywhere).
10. Fixed memory leak caused by failure to free rows whose refcount is 0
in Update().
11. Fixed possible memory corruption in calls to IRowsetChange::SetData,
IRowsetChange::InsertRow, ISequentialStream::Write, and IRowChange::SetColumns.
12. Fixed performance problem when DataConvert is used when no conversion
is required.
13. The LoadCommand, DeleteCommand, and SaveCommand methods of the ICommandPersist
interface did not qualify system tables references with an owner name. This
has been corrected.
14. The OLE DB provider accepts two cbBookmark values, 1 which is the “short”
DBBMK_FIRST/LAST value, and 4 or 8 depending on the bitness of the provider.
The 64-bit provider flags “4” was an illegal value for cbBookmark. The 32-bit
provider flags “8” was an illegal value for cbBookmark. The OLE DB provider
should accept both 4 and 8 as the length of a bookmark value and fetch the
appropriate 32-bit/64-bit bookmark value from memory. This problem has been
corrected. The fix affects IRowsetLocate::GetRowsAt, IRowsetLocate::Compare,
RowsetLocate::GetRowsByBookmark, IRowsetLocate::Hash, and IRowsetScroll::GetApproximatePosition,
and IRowsetExactScroll::GetExactPosition. Both 32-bit and 64-bit providers
now support 4-byte and 8-byte bookmark values, in addition to 1-byte values.
================(Build #3907 - Engineering Case #740334)================
The ICommandPersist interface methodes, LoadCommand, DeleteCommand, and SaveCommand,
did not qualify system tables references with an owner name. This has been
corrected.
================(Build #3860 - Engineering Case #732743)================
Original description for Engineering case 706876:
A Microsoft Data Link Error could have occurred with newer versions of Microsoft
software when using the SQL Anywhere OLE DB provider. When the Test Connection
button was clicked, the following message would have been displayed when
the error occurred:
Test connection failed because not all properties can be set.
Window Handle (BAD VALUE)
Continue with test connection?
[Yes] [No]
The message was informational only and Yes can be clicked. If the credentials
and other connection information were correct, the connection succeeded.
This problem has been fixed. Instead of returning a NULL window handle to
the Microsoft software, the OLE DB Window Handle property is now marked as
unsupported, which removes the warning message.
===
The solution to this problem was incorrect. Some applications require support
for the Window Handle property and terminate if not supported (e.g., ROWSETVIEWER
application).
The problem has been corrected. The Window Handle property value was improperly
described as 32-bit in a 64-bit application.
================(Build #3800 - Engineering Case #720592)================
If the values 'SYSTEM TABLE', ‘SYSTEM VIEW’ or 'GLOBAL TEMPORARY' were specified
as the TABLE_TYPE restriction for either of the SQL Anywhere OLE DB DBSCHEMA_TABLES
or DBSCHEMA_TABLES_INFO rowsets, an empty rowset was returned. If ‘TABLE’,
‘VIEW’, or ‘TEXT’ was specified as the TABLE_TYPE restriction, there was
no problem. This problem has been corrected. To correct the problem in an
existing database, the Upgrade utility must be used once the problem resolution
fix (EBF) has been installed.
================(Build #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 #4456 - Engineering Case #802406)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.2i.
================(Build #4423 - Engineering Case #799885)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.2h. In addition, the version of the OpenSSL FIPS library has been
upgraded to 2.0.12.
================(Build #4423 - Engineering Case #799884)================
The version of OpenLDAP used by the SQL Anywhere server and client libraries
has been upgraded to 2.4.44.
================(Build #4359 - Engineering Case #793527)================
SQL Anywhere software on UNIX platforms required LD_LIBRARY_PATH (or the
equivalent for the platform) to be set in order for the loader to find dependent
libraries. This made the use of the software inconvenient, especially when
interfacing with third-party applications. Additionally, SQL Anywhere software
may have failed to find dependent libraries on Mac OS X 10.11 systems, even
if DYLD_LIBRARY_PATH was set properly. The new security policy in this version
of Mac OS X caused DYLD_LIBRARY_PATH to be unset in certain cases, causing
the loader to fail to find libraries.
This has been fixed to some degree on all UNIX platforms except AIX. However,
some use cases will still need this or some other environment variable to
be set. In some cases, user applications will need some adjustment.
Specifically:
- When using a client API that requires libdbcapi, either LD_LIBRARY_PATH
or SQLANY_API_DLL must be set correctly.
- When using Java with native libraries, such as JDBC (including when using
Java external environment; except on Mac), either LD_LIBRARY_PATH must be
set or the -Djava.library.path=/path/to/sqlanywhere/lib64 command line switch
must be used.
- When using external functions, either LD_LIBRARY_PATH must be set or
the full path to the shared library must be provided.
- If you use a custom install layout, you may find that LD_LIBRARY_PATH
is still needed. On Mac OS X, it is possible to use install_name_tool to
provide additional search paths instead of using DYLD_LIBRARY_PATH.
================(Build #4318 - Engineering Case #789607)================
In rare circumstances, the SQL Anywhere installer on Unix could have crashed
during an upgrade. This has been fixed.
A work around is to uninstall the old SQL Anywhere software and perform
a new installation of the new software.
================(Build #4269 - Engineering Case #783864)================
The SQL Anywhere Monitor Migrator would have failed when running on machines
with a Turkish locale, regardless of the server machine’s locale. This has
been fixed.
================(Build #4267 - Engineering Case #783682)================
If an application called the db_locate_servers or db_locate_servers_ex functions
more than once, the second and subsequent calls would have failed. This has
been fixed.
================(Build #4247 - Engineering Case #781487)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1m.
================(Build #4219 - Engineering Case #778063)================
The Start Menu shortcut “Download Documentation” has been changed to link
to the SCN website.
================(Build #4216 - Engineering Case #777972)================
The Start Menu shortcut “Download Documentation” has been changed to link
to the SCN website. For this change to take effect, the system must be rebooted
after applying this change.
================(Build #4214 - Engineering Case #777135)================
The version of OpenSSL used by all SQL Anywhere components has been upgraded
to 1.0.1k. The FIPS libraries have been upgraded from OpenSSL FIPS 2.0.5
to 2.0.9.
================(Build #4199 - Engineering Case #775928)================
The Interactive SQL utility could have incorrectly parsed a CREATE LOCAL
TEMPORARY TABLE statement if it appeared within some other block structure
(e.g. a BEGIN ... END block). This caused a problem if a subsequent DBISQL
statement (e.g. INPUT, OUTPUT, EXIT) was encountered. The symptom was typically
an error message from the database server which reported a syntax error near
the first keyword of the DBSIQL statement. This has been fixed.
================(Build #4148 - Engineering Case #767530)================
The SQL Anywhere ODBC sample inside the C example directory (odbc.c) used
ODBC 2.0 calls and could not link against the SQL Anywhere Driver Manager
for Unix on Unix platforms. This has been corrected so that the sample now
utilizes ODBC 3.0 calls and can link against the driver manager successfully.
================(Build #4108 - Engineering Case #763021)================
A dbtools sample was expected to perform a backup of the Demo database as
a way to demonstrate how to load and use the dbtools dynamic library. On
Mac OS X, the dbtools sample would have failed to load the dbtools dynamic
library, so it would return to the shell without performing the backup or
producing any output. This has been fixed.
================(Build #4103 - Engineering Case #762606)================
In the DBMirror sample that is included with the SQL Anywhere software, the
mirror setup SQL script contained a typographical error so no mirror partner
was established. The "mirror" partner merely acted as a copy node.
Attempts to connect to the mirror partner would have failed. This problem
has been corrected.
================(Build #4050 - Engineering Case #754211)================
The SQL Anywhere sample program build procedures have been updated to simplify
Microsoft Visual Studio x64 platform builds. When the Visual Studio C++ tools
are set to use the x64 compiler, the SQL Anywhere sample build.bat scripts
will build an x64 version of the sample programs.
================(Build #3988 - Engineering Case #748538)================
Specifying the command line option -nogui after the option -silent when running
the UNIX setup script would have caused the -silent flag to be ignored. This
has been fixed. The -nogui option now has no effect if -silent is specified
at any point.
A workaround is to avoid specifying -nogui when doing a silent install.
================(Build #3988 - Engineering Case #748535)================
The Linux GTK and Mac OS X UI installer improperly reported insufficient
disk space if there was more than 2 TB of available disk space. This has
been fixed.
A workaround is to use setup -nogui to avoid the use of the graphical installer.
Alternatively, install to a smaller disk drive.
================(Build #3908 - Engineering Case #740414)================
The SQL Anywhere Extension Agent library (dbsnmp*.dll) was not being installed
on a 64-bit systems. The 64-bit install needs to put down the 32-bit dbsnmp*.dll
to support Microsoft SNMP, which is a 32-bit only service. This has been
fixed.
================(Build #3908 - Engineering Case #740412)================
The 32-bit version of the Version 9 or earlier physical store library (dboftsp.dll)
was not installed on a 64-bit OS when the 32-bit Client feature was selected.
Furthermore, dboftsp.dll was not installed when the MobiLink or SQL Remote
features were selected. This has been fixed.
================(Build #3891 - Engineering Case #725184)================
SQL Anywhere permits the use of identical foreign key CONSTRAINT names on
different tables. Some third-party software tools cannot handle duplicate
constraint names. As a result, the sample database demo.db that is shipped
with SQL Anywhere has been modified so that it now has unique foreign key
constraint names. The constraint name FK_CustomerID_ID in the GROUPO.Contacts
table has been renamed to FK_CustomerID_ID2. The constraint name FK_ProductID_ID2
in the GROUPO.MarketingInformation table has been renamed to FK_ProductID_ID2.
================(Build #3867 - Engineering Case #733922)================
When run on Unix systems, the uninstaller always returned an error code of
1. This has been fixed.
================(Build #3867 - Engineering Case #733915)================
When installing sub-components in silent mode, for example with:
setup -silent … -install sqlany64,sqlanyclnt32
the installer may have given an error like:
The following option names are invalid or are not exposed by the registration
key provided:
sqlanyclnt32
sqlany64
Another symptom of the same problem could be seen using the -list_packages
switch, for example:
setup … -list_packages
would have output garbled messages. This has been fixed.
================(Build #3865 - Engineering Case #733443)================
Building the PHP external environment using phpize, or by integrating into
the PHP source code, would have failed. On version 16, it will fail to find
libdblib at the configure stage. On both versions, it will fail to produce
a useable PHP module. This has been fixed.
================(Build #3851 - Engineering Case #730761)================
If the Unix setup script was run from a path containing spaces (including
the default behaviour for the Mac DMG file), it would not have run correctly.
One example of bad behaviour was improper display of the version numbers.
The graphical installers would also have failed to display the license text
properly. This has been fixed.
================(Build #3818 - Engineering Case #724069)================
The SQL Anywhere Unix installer may not have installed the Start Server (dbspawn)
and Stop Server (dbstop) utilities when “SQL Anywhere Monitor”(developer
edition) was selected as a component to install. Running a command like samonitor.sh
{start|stop} would have failed due to the missing dbspawn and dbstop executables.
This has now been corrected.
================(Build #3817 - Engineering Case #723969)================
The Unix installer may have returned an error like “samples/sample_env32.sh:
No such file or directory", when the selected components did not require
the sample directory.
This has been fixed.
================(Build #3798 - Engineering Case #720288)================
The SQL Preprocesor (sqlpp) would have incorrectly reported a warning or
possibly an error if the file it was preprocessing had static SQL containing
"TIMESTAMP WITH TIME ZONE". The most likely sqlpp warning was
"Warning! W2661 near 'with': Unrecognized SQL syntax". This has
now been fixed.
================(Build #3794 - Engineering Case #719719)================
When using the SQL Anywhere C API, the information returned by sql_column_info
would always have indicated that nulls were not allowed. This has been fixed.
================(Build #3788 - Engineering Case #718489)================
Calling a stored procedure from any driver that uses the SQL Anywhere C API
runtime library (eg. python, perl, ruby) would have returned incorrect values
for the second and subsequent string (binary, varchar, long binary, or long
varchar) OUT parameters. All string prameters would have been given the value
of the first string parameter. This has been fixed.
================(Build #3787 - Engineering Case #716908)================
Attempting to upgrade a database initialized with software prior to version
10, to version 10 or higher, on a computer running Linux that uses a 3.x
kernel may have failed. This was most likely on systems with more than 4
GB of RAM, or with 32-bit software. This has now been fixed.
================(Build #3782 - Engineering Case #566705)================
In the PHP external environment, calling phpinfo() would have showed no useful
information for the sqlanywhere_extenv module. This has been fixed. Now,
server version information, as well as the names of the server, database,
and user are displayed.
================(Build #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 #4475 - Engineering Case #803177)================
The server may have returned a procedure result set that does not have the
correct schema. The problem happened if the procedure definition has no RESULTS
clause and has been loaded during parsing another batch, function, or procedure.
To work around the problem the connection option "DescribeCursor=Always"
can be used. The problem could also be solved by recompiling the procedure
using the statement ALTER PROCEDURE <proc-name> RECOMPILE. This has
been fixed.
================(Build #4474 - Engineering Case #803114)================
Under rare circumstances, the server could have crashed when executing a
query with a window function. This has been fixed.
================(Build #4468 - Engineering Case #802806)================
The server would have incorrectly returned the error SQLE_OMNI_REMOTE_ERROR
if the REGEXP search condition was used for proxy tables. This has been
fixed.
================(Build #4464 - Engineering Case #802688)================
Server may crash when calling sa_split_list procedure. This has been fixed.
================(Build #4462 - Engineering Case #802672)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.2j.
================(Build #4459 - Engineering Case #802533)================
When calling a web service using the SoapUI tool, the message "400 Bad
Request" error is returned.
This is caused by the presence of a CDATA section in a parameter value
(<![CDATA[ xml-string ]]>). CDATA can be used to imbed an XML string
into an XML structure so that it is not parsed as part of the overall XML
structure.
For example, suppose the following SOAP request was sent to the database
server.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:fix="http://url.sample.com">
<soapenv:Header/>
<soapenv:Body>
<fix:authenticate>
<fix:ac_XML><![CDATA[<auth><uid>DBA</uid><pwd>sql</pwd></auth>]]></fix:ac_XML>
</fix:authenticate>
</soapenv:Body>
</soapenv:Envelope>
When the database server SOAP parser encounters the CDATA section, it returns
an error.
This problem has been fixed. The server now treats the CDATA string as plain
text.
================(Build #4458 - Engineering Case #802464)================
When trying to call a remote function in a SQL Anywhere database that returns
a VACHAR result, the error " Count field incorrect" is returned.
For example, suppose the remote SQL Anywhere database server defines the
following function.
CREATE OR REPLACE FUNCTION DBA.TestFunction( IN arg1 CHAR(255) )
RETURNS VARCHAR(32767)
BEGIN
RETURN 'Good day';
END;
The local database defines a remote server and a cover function to call
the remote function, and then calls the remote function as follows:
CREATE SERVER rmt
CLASS 'SAODBC'
USING 'DRIVER=SQL Anywhere 17;DSN=Test17;Server=demo17;UID=DBA;PWD=sql';
CREATE OR REPLACE FUNCTION TestFunction( IN arg1 CHAR(255) )
RETURNS VARCHAR(32767)
AT 'rmt..DBA.TestFunction';
SELECT TestFunction( 'Hello' );
An error was returned when the SELECT statement was executed.
This problem has been fixed. In the example above, the SELECT statement
now returns the expected VARCHAR result.
================(Build #4450 - Engineering Case #798705)================
Under exceptional rare circumstances, the server may have returned an incorrect
result set if all the following conditions were true:
- the statement contained user defined functions or stored procedure
- the statement was part of a function, procedure, event, or batch
- parallel query execution was performed
- the parallel subtree of the query plan referenced local variables or
function/procedure arguments
This has been fixed.
A workaround of the problem is to set the option Max_query_task =1.
================(Build #4446 - Engineering Case #801492)================
Under very rare circumstances, the server may have returned an incorrect
result set if local SQL variables were used with parallel query execution.
This has been fixed.
To work around the problem set the option Max_query_tasks = 1.
================(Build #4444 - Engineering Case #801308)================
Under very rare circumstances, the server may have crashed if miscellaneous
SQL functions were used in a parallel query execution. This has been fixed.
To work around the problem set the option Max_query_task = 1.
================(Build #4429 - Engineering Case #800426)================
Under some circumstances, the LIST function may have caused the server's
temp file to grow to a large size. This has been fixed.
================(Build #4423 - Engineering Case #799118)================
The server may have incorrectly returned the error SQLSTATE_BAD_RECURSIVE_COLUMN_CONVERSION
if a recursive select statement used numeric expressions that did not have
the current default precision and scale. This has been fixed.
================(Build #4423 - Engineering Case #799117)================
Under very rare circumstances, the server may have crashed when executing
an recursive query. This has been fixed
================(Build #4416 - Engineering Case #798668)================
In some cases, creating a circular string could have resulted in the server
entering an endless loop. This has been corrected.
================(Build #4406 - Engineering Case #797752)================
Inserting a round-Earth geometry could have failed with "Error parsing
geometry internal serialization” (SQLCODE –1415). This has been fixed.
================(Build #4404 - Engineering Case #782470)================
Under very rare circumstances, it may have taken a long time to cancel a
complex query during optimization. This has been fixed
================(Build #4403 - Engineering Case #797401)================
Under rare circumstances, the database server could have crashed while updating
the column statistics at the end of a DML statement. This has been fixed.
================(Build #4401 - Engineering Case #797145)================
Under very rare circumstances, the server would have crashed if the GROUP
BY clause of a query contained outer references. This has been fixed
================(Build #4399 - Engineering Case #796705)================
An authenticated server may have given authentication errors to connections,
even though the authentication string was a valid string provided by SAP.
This has been fixed.
================(Build #4397 - Engineering Case #796738)================
The server may have returned an incorrect result set if a query had an inner
query block with a GROUP BY CUBE or ROLLUP and an outer query block had predicates
in the WHERE clause. This has been fixed.
================(Build #4391 - Engineering Case #796262)================
On Unix systems, if a server was started with the –ud option, and that server
attempted to start a database file that was already running on another server
(with a different name), the new server may have crashed on shutdown. The
reported error message also did not correctly indicate that the database
file was in use. This has been fixed.
================(Build #4390 - Engineering Case #796139)================
Under very rare circumstances, the SQL Anywhere server could have crashed
when executing a complex query with large number of threads executing in
parallel. This problem has now been fixed.
================(Build #4389 - Engineering Case #796081)================
On systems running Microsoft Windows, the server may have crashed on startup
when attempting to obtain disk drive parameters if the disk driver did not
properly implement the IOCTL_STORAGE_QUERY_PROPERTY correctly. When successful,
the information returned by this system call can be seen using the following
SQL query.
SELECT DB_EXTENDED_PROPERTY( 'DriveModel' );
This problem has been fixed. If the disk drive parameters cannot be determined,
the drive model will now be “Unknown”.
================(Build #4387 - Engineering Case #795917)================
Certain assertion numbers could have been raised in more than one situation.
This has been fixed so that assertion numbers are now unique.
================(Build #4385 - Engineering Case #795599)================
Under very rare circumstances, the server may have crashed during a database
cleaner run if there had been tables dropped and views created shortly before.
This has been fixed.
================(Build #4384 - Engineering Case #795609)================
The SQL functions NUMBER(*) and RAND() may have returned duplicate values
if they were executed below an Exchange query plan node of a parallel query
execution. This has been fixed.
================(Build #4382 - Engineering Case #795546)================
If a server was using the -zoc switch to log web procedure calls, and a web
procedure that used chunked encoding was called, the server could have crashed.
This has been fixed.
================(Build #4382 - Engineering Case #794511)================
Under very rare circumstances, the server may have crashed while receiving
host variables from a TDS based connection if the receiving TDS token stream
violated the TDS protocol definition. This has been fixed. The server will
now return a SQLSTATE_COMMUNICATIONS_ERROR error in this situation.
================(Build #4370 - Engineering Case #794531)================
When creating a foreign key with an ON DELETE SET DEFAULT or ON UPDATE SET
DEFAULT action on a column with no default value, the error message returned
by the server would have failed to reference the table name: “Constraint
'<column>' violated: Invalid value for column '<table>’ in table
'???'”. This has been fixed so that the table name is now referenced.
================(Build #4368 - Engineering Case #794343)================
The server could have crashed executing a spatial query in a low memory situation.
This has been fixed.
================(Build #4360 - Engineering Case #793824)================
Under very rare circumstances, the server may have crash when using a RANK
aggregate function. This has been fixed.
================(Build #4357 - Engineering Case #793370)================
The version of OpenLDAP used by the SQL Anywhere server and client libraries
has been upgraded to 2.4.43.
================(Build #4357 - Engineering Case #792816)================
The server may have failed the non-fatal assertion 102604 - "Error building
sub-select" if a query contained a distinct that could have been eliminated,
the query cursor was not declared with read-only, and there was a publication
with an subselect in the Subscribe-by
clause. This has been fixed.
================(Build #4354 - Engineering Case #792313)================
The server can perform a fast TRUNCATE TABLE if the table is referenced by
foreign key tables and all the foreign key tables are empty. Under some circumstances
a fast truncate was not being executed. This has been fixed.
================(Build #4349 - Engineering Case #792266)================
The UPDATE statement [SQL Remote] is executed by the Message Agent of SQL
Remote to determine existing and new recipients of the rows in a table:
UPDATE table-name
PUBLICATION publication-name
{ SUBSCRIBE BY subscription-expression |
OLD SUBSCRIBE BY old-subscription-expression
NEW SUBSCRIBE BY new-subscription-expression }
WHERE search-condition
expression : value | subquery
The statement does not modify any of the rows in the database, but puts
records in the transaction log to indicate movement of rows from or to a
recipient.
Since this type of UPDATE statement does not modify any rows, it should
not execute any BEFORE or AFTER triggers. Before this change it improperly
called BEFORE UPDATE triggers on the target table, leading to wasted work
in some cases. This has been fixed, BEFORE UPDATE triggers are no long called
for this type of statement.
================(Build #4346 - Engineering Case #792263)================
In some situations, creating an index on a very large table could have caused
the server to appear to be hung. This condition did go away once the index
was created. The is now been fixed.
================(Build #4346 - Engineering Case #792227)================
Some valid round-earth geometries could have failed to input properly, either
giving an error, failing an assertion, or causing a server crash. This has
been fixed.
================(Build #4345 - Engineering Case #792221)================
If the server encounters a fatal database error it then writes a minidump
file. During this process the server may have overwritten this minidump file,
or created another minidump file due to a crash when freeing static data.
This has been fixed.
================(Build #4343 - Engineering Case #791615)================
Temporary file names for the server and various utilites were generated using
a standard library function that may have produced somewhat predictable file
names. These predictable temporary file names could have been exploited in
various ways. Collisions between processes or threads were also possible
and could have resulted in undesirable behaviour. This has been fixed.
A workaround that mitigates most of the issues is to set SATMP to a location
that is only writable by the engine and other trusted users.
================(Build #4341 - Engineering Case #792037)================
In very rare cases, the server could have crashed dereferencing a bad pointer
or connections could have failed to unblock. This has been fixed.
================(Build #4340 - Engineering Case #791896)================
In very rare cases the server may have failed assertion 201501: “Page X:Y
for requested record not a table page”. This has been fixed.
================(Build #4337 - Engineering Case #791667)================
The function ST_PointOnSurfac()e requires an ST_Polygon or ST_MultiSurface
as input. Similarly, the function ST_IsRing() requires an ST_LineString as
input. Using these functions on valid geometry types may have resulted in
an error indicating that the geometry type was incorrect. This has been fixed.
================(Build #4337 - Engineering Case #791665)================
When creating a LineString with a round-earth SRS, points that were 180 degrees
longitude apart were rejected as being nearly antipodal, even if they were
physically close together. For example, the following geometry would have
failed to load, even though it is a relatively short line: LineString (-180
-84, 0 -90). This has been fixed.
================(Build #4337 - Engineering Case #791283)================
Under rare circumstance, the server could have crashed when executing a statement
involving a stored procedure or user defined function defined with SQL SECURITY
INVOKER. This has been fixed.
================(Build #4337 - Engineering Case #790722)================
Under very rare circumstances, the server may have crashed or failed an assertion
"Assertion failed: 109512 Freeing already-freed memory". This has
been fixed.
To work around the problem, plan caching can be turned off (option Max_plans_cached
= 0).
================(Build #4336 - Engineering Case #791554)================
Zero-length LineStrings were not handled properly by the set operations,
ST_IsSimple, and ST_Buffer. Passing such a LineString to ST_Buffer may have
caused the server to fail an assertion. This has been fixed.
ST_IsSimple now returns TRUE if there are only two points in the LineString.
LineStrings containing more than two points that are also zero-length are
not considered to be ST_IsSimple.
Set operations now treat the zero-length LineString as a single point.
Zero-length segments within a given LineString whose overall length is non-zero
are ignored.
================(Build #4335 - Engineering Case #791165)================
In some situations, when a table had hundreds of Foreign Key constraints
defined an insert in that table may have caused a server crash. Behavior
has now been changed to throw an error instead.
================(Build #4332 - Engineering Case #788462)================
The server may have incorrectly returned the error "Function or column
reference to 'rowid' must also appear in a GROUP BY", when a select
with aggregation had a correlated subquery in its select list and the subquery
contains an outer join that returned constants from the null-supplying side.
For example:
select ( select sum(T2.b2)
from T2 left outer join ( select 1 as x from T3 )
V3 on 1=1
where T1.a1 = T2.a2
) as Z,
count(*)
from T1
group by T1.a1
This query below has a main query block with GROUP BY T1.a1, a subquery
with alias Z, and an outer reference to the subquery using T1.a1. The null-supplying
side of the outer join V3 returns a constant "1 as x".
This has been fixed.
================(Build #4331 - Engineering Case #780893)================
Under rare circumstances, the server may have returned the error "Invalid
use of an aggregate function" when a query contained a proxy table and
an aliased flattenable subquery with grouping in the select list of a query
block. For example: The below query has a subquery with an alias name "s1"
and would have returned the above error:
select *
from ( select ( select sum(V1.a1) x from T1 V1 ) as s1
from T1 V2
) V0,
T2_proxy
This has now been fixed.
================(Build #4328 - Engineering Case #790670)================
Accessing a proxy table mapped to a remote Oracle table which had special
characters in its name (such as ‘/’, ‘$’, ...) was reporting syntax errors
such as ORA-0903 and ORA-0933. The problem was due to the table identifiers
not being delimited properly, which has now been fixed.
================(Build #4327 - Engineering Case #790600)================
In some cases, UPDATE statements that included SET <variable> = <expression>
could have failed to evaluate the expression for the variable, setting it
to NULL instead. This has been fixed.
A workaround is to issue a separate query before issuing the update. For
example,
UPDATE T SET @var = T.x, T.y = 4 WHERE T.z=1
becomes
SELECT T.x INTO @var WHERE T.z=1;
UPDATE T SET T.y = 4 WHERE T.z = 1;
================(Build #4327 - Engineering Case #790589)================
In very rare situations, a server could have crashed if an application that
made a connection-scoped external environment call closed the connection
while the server machine was under heavy load. This problem has now been
fixed.
================(Build #4326 - Engineering Case #790543)================
Under rare circumstances, cursors with a cached query plan could have caused
a memory leak if diagnostic tracing was used. This has been fixed.
================(Build #4320 - Engineering Case #789852)================
If a server was running on a Unix system with multiple network adapters and
the MyIP parameter was used with a link-local IPv6 address (i.e. one that
begins with “fe80::”), clients may not have been able to find the server
using TCP/IP. This has been fixed.
================(Build #4319 - Engineering Case #789740)================
The server may have returned a sequence value for CURRVAL even if NEXTVAL
was never called in the current connection for this sequence. This has been
fixed.
================(Build #4319 - Engineering Case #786626)================
The server did not allow the use of sequence.currval as a default column
value. This has now been implemented.
================(Build #4316 - Engineering Case #789267)================
The changes for Engineering case 786183 did not completely resolve a problem
where domain users explicitly present in the local group were no longer being
located. This has been corrected so that local users or domain users that
are members of a local group, as well as domain users who are indirectly
members of a local group (by virtue of being a member of a global group placed
within a local group) are now found and the group name is checked for an
integrated login mapping.
================(Build #4310 - Engineering Case #788402)================
When calling a secure web procedure, the database server would have leaked
memory. This has now been fixed.
================(Build #4308 - Engineering Case #786492)================
If a multi-threaded application instantiated separate DbmlsyncClient objects
on separate threads, it was possible for the application to have crashed
if the Init function was called concurrently on multiple threads. The SYNCHORNIZE
command in the SQL Anywhere database engine uses the Dbmlsync API, so concurrent
calls to the SYNCHRONIZE command on different connections could also result
in a crash of the database server. These issues have now been fixed.
================(Build #4307 - Engineering Case #788197)================
When connecting to an authenticated server using SQL Anywhere tools such
as Interactive SQL or SQL Central, executing statements that would modify
the database would have failed with the error: "-98 Authentication violation".
This problem was introduced by changes made for Engineering case 785757 and
has now been fixed.
================(Build #4306 - Engineering Case #788051)================
If a server was running on a Unix machine (other than Mac OS X) with multiple
network adapters and the MyIP parameter was used with a link-local IPv6 address
(i.e. one that begins with “fe80::”), clients may not have been able to find
the server using TCP/IP. This has been fixed.
================(Build #4305 - Engineering Case #788026)================
Under rare circumstances, the server may have crashed, or failed an assertion:
“Assertion failed: 109512 Freeing already-freed memory”. This has now been
fixed.
================(Build #4303 - Engineering Case #761650)================
The server may have issued an error, for example "Column <name>
not found", if an INSERT, UPDATE or DELETE statement on a local table
referenced a proxy table, and the changing table had a publication that referenced
in its publication WHERE clause additional tables.
This has been fixed.
================(Build #4301 - Engineering Case #787592)================
Certain sub and dynamic classes built using a 1.8 JDK could not been installed
in the database. This problem has now been fixed.
================(Build #4299 - Engineering Case #738277)================
The server may have crashed, or returned unexpected errors, if a SELECT from
DML referenced proxy or IQ tables. This has been fixed.
================(Build #4298 - Engineering Case #787340)================
The server would not have started if a server name with spaces was entered
in the server startup dialog window. This has been fixed.
================(Build #4297 - Engineering Case #787105)================
Repeatedly executing INSERT statements with a VALUES clause containing two
or more rows could have caused a crash in memory constrained environments.
This has been fixed.
================(Build #4296 - Engineering Case #787014)================
Under very rare circumstances, the server could have returned an error, an
incorrect result, or entered an infinite loop, if a query contained Transact
SQL outer joins in subqueries that were part of a disjunctive clause. This
has been fixed.
================(Build #4294 - Engineering Case #786804)================
If an application fetched a result set containing an nvarchar(1024) column
from a remote server, then that column value would have been invalid if the
original value was exactly 1024 nchar characters in length. This problem
has now been fixed.
================(Build #4290 - Engineering Case #790977)================
Under very rare timing dependent condition, an index that had long hash values
could have some assertions (for example: 200114 - Can't find values for
row ... in index ...). This has been fixed.
================(Build #4288 - Engineering Case #786183)================
Engineering case 776698 resolved a problem where a domain group was included
in a local group, but users in the domain group were not being located in
the local group (via indirection). It introduced a problem where domain users
explicitly present in the local group were no longer being located. This
problem has been corrected. Indirect lookups are now performed separately
from direct lookups.
================(Build #4288 - Engineering Case #786120)================
In very rare cases, the transaction log can become corrupted. The symptoms
of the corruption can appear as checksum failures on page 0 of the transaction
log. This has been fixed.
================(Build #4288 - Engineering Case #786112)================
When setting the QuittingTime server property using the system procedure
sa_server_option(), parsing of the provided date string did not respect the
date_order or nearest_century options. The date_order was always assumed
to be YMD and the nearest_century was always assumed to be set to 50 , despite
any connection, user, or public settings. This has now been fixed.
================(Build #4286 - Engineering Case #785858)================
In some cases, dynamic cache resizing on Linux systems might not have behaved
correctly. This has been fixed.
================(Build #4286 - Engineering Case #785851)================
SQL Anywhere installations no longer include PHP drivers. They are now posted
to a web page, but the versions posted only include the .0 release of each
major/minor version.
The PHP external environment attempts to load the external environment DLL
that matches the current phpversion(), which includes the release number.
Unless the release number is 0, or an appropriate driver was previously installed,
the correct driver will not be found and the PHP external environment will
fail to start.
This has been fixed. If a DLL with the full version number is available,
it will be used. Otherwise the DLL with the .0 release number will be used.
e.g. PHP 5.6.5 would use the 5.6.0 DLL.
SQLA 12.0.1 and 16.0.0 should continue to work as before, but the fix was
included to allow for possible future changes.
Workarounds include (one of):
- rename the SQLA PHP modules to a name that will be found
- set up a php.ini file containing the “extension” setting that will load
the SQLA PHP modules
- compile the PHP drivers in the SDK directory to match your PHP installation
================(Build #4284 - Engineering Case #785640)================
If the Content-Type header begins with "multipart/" but is not
"multipart/form-data" (e.g. multipart/mixed), the HTTP server would
have returned a 400 error, even though the request itself is valid.
This has been fixed. The body of the request is not parsed for these Content-Types,
nor is it accessible through HTTP_VARIABLE( ‘body’ ). The body may be accessed
through the HTTP_BODY() function.
================(Build #4283 - Engineering Case #785450)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1o.
================(Build #4282 - Engineering Case #785330)================
Under some circumstances, running the Index Consultant against workloads
that included queries against remote tables may have caused the server to
crash. This has been fixed.
================(Build #4281 - Engineering Case #784735)================
Under rare circumstances, a query that generated a large intermediate result
set containing strings of medium length (usually in the range of 128-256
bytes long) could have crashed the server. This has been fixed.
================(Build #4280 - Engineering Case #785134)================
Under rare circumstances, a long running, memory intensive query could have
caused the server to crash. This has been fixed.
================(Build #4276 - Engineering Case #784731)================
Under rare circumstances, cancelling a parallel query could have caused a
memory leak. This has been fixed.
================(Build #4275 - Engineering Case #780004)================
Under rare circumstances, a query executed using a parallel bloom filter
operator could have caused a server crash or an assertion failure - “memory
allocation too large”. This has been fixed.
================(Build #4272 - Engineering Case #783734)================
Under rare circumstances, an AUTO/MANUAL text index operation could have
failed to return an error when an error was encountered. This has been fixed.
================(Build #4272 - Engineering Case #782601)================
If the query for which the graphical_plan was being calculated included a
reference to a stored procedure that was expected to return a result set,
but did not do so, the SELECT graphical_plan( … ) statement would have returned
a warning at OPEN time. This has been fixed.
Note, the issue could also have affected some queries referencing such a
stored procedure.
================(Build #4270 - Engineering Case #784051)================
If an application made a remote procedure call or executed sp_forward_to_remote_server(),
and the call on the remote server generated an error, then the server could
in some cases have given the generic “remote server not capable” error rather
than returning the actual error from the remote server. This problem has
now been fixed and the original error is now returned.
================(Build #4269 - Engineering Case #773426)================
Under exceptionally rare circumstances, the server would have taken a long
time to build the final query plan. This may have occurred for very complex
and large queries. During this time DDL statements were blocked, which caused
subsequent requests to block as well. This has been fixed.
================(Build #4267 - Engineering Case #783702)================
The server may have crashed when querying for recommended indexes from a
tracing database using sa_recommend_indexes(). This has been fixed.
================(Build #4264 - Engineering Case #783424)================
The predicate normalization phase of query processing was incorrectly done
two times for a SELECT under an INSERT statement. This did not cause incorrect
results, but in some cases it could cause statements to execute slowly. This
has been fixed so that the predicate normalization phase is now applied only
once to the SELECT under an INSERT statement.
Predicate normalization is performed during the semantic transformation
phase.
http://dcx.sap.com/index.html#sa160/en/dbusage/queryopt-b-3197621.html*d5e16832
One particular predicate normalization is the handling of equality predicates
when the ANSINULL option is set to Off. Note that by default this option
is set to Off for Sybase Open Client and jConnect connections by calling
the sp_tsql_environment system procedure.
When ANSINULL=Off, predicates are transformed during the normalization phase
to reflect the Transact-SQL semantics, for example:
T.x = @v -> (T.x = @v) OR (T.x is null and @v is null)
Additional predicate normalization steps during the Semantic transformation
phase simplify conditions in the WHERE clause and identify useful search
conditions. These normalizations do not use the current value of columns
or variables.
During the Pre-optimization phase, further predicate analysis is used to
find relevant indexes or materialized views that may be used in the query
access plan. At this point, values of variables can be used to simplify the
search conditions.
drop table if exists R;
drop table if exists T;
create table R(x int null);
create table T(x int null);
create or replace variable @V int = 1;
set temporary option ANSINULL=OFF;
/*Q1*/ select rewrite('select T.x from T as T where T.x=@V
-> select T_1.x from T as T_1 where(T_1.x = @V or T_1.x is null and @V
is null)
When processing an INSERT statement, the Predicate normalization phase was
incorrectly applied twice to the SELECT statement that generates rows for
the INSERT. While repeating normalization does not give incorrect answers,
it can contribute to slower query plans than needed.
In particular, the transformation for ANSINULL=Off was repeated, generating
a more complex condition than needed:
T.x = @v
-> (T.x = @V) or (T.x is null and @v is null)
-> (T.x = @V) or (T.x is null and @v is null) or (T.x is null and @v
is null)
Because of the effect of repeating the ANSINULL=Off transformation, this
more complex search condition was simplified by later Predicate normalization
steps:
-> (T.x = @v or T.x is null) and (T.x = @v or @v is null)
This more complex condition could, in some cases lead to slower statement
execution than needed. In versions of the server before 16.0.3051, the Pre-optimization
phase would simplify this more complex condition as follows:
(T.x = @v) and (T.x = @v or T.x is null)
This simplified condition qualified for index access, but could lead to
selectivity estimation problems due to the redundant predicate on T.x, causing
the rows returned from T to be underestimated and potentially affecting plan
quality.
While this type of predicate is generated with ANSINULL=Off, in particular
with the issue related to Predicate normalization being repeated under INSERT,
the same effect could occur with certain structures of search conditions,
such as the following:
set temporary option ANSINULL=ON;
/*Q2*/ select rewrite('select T.x from T as T where T.x=@V OR T.x is null
and @V is null OR T.x is null and @V is null');
-> select T_1.x from T as T_1 where(T_1.x = @V or T_1.x is null) and(T_1.x
= @V or @V is null)
A related change, Engineering case 775142 (Predicate optimizations improved),
providses new pre-optimization capabilities during predicate analysis which
simplifies these more complex search conditions, avoiding the selectivity
errors.
================(Build #4264 - Engineering Case #783410)================
Queries containing the built-in functions HEXTOINT, ROUND, STRTOUUID, and
YMD may have incorrectly described an expression as NOT NULLABLE when the
option conversion_error=Off and the input to the function was a non-nullable
column or expression. If the input value would have caused a conversion
error (SQLCODE -157 or -158) when option conversion_error=On, the built-in
functions could have returned NULL; as well, the query could have returned
an incorrect result if the result of the builtin was used in a predicate
or as input to another built-in such as ISNULL or COALESCE. This has been
fixed.
================(Build #4263 - Engineering Case #783357)================
On a Linux systems that had been up for a long time, the 32-bit server would
have returned LastRequestTime connection properties that were in the future.
This has been fixed.
================(Build #4263 - Engineering Case #783348)================
The changes for Engineering case 779078 may have caused the server to incorrectly
report the error "Function or column reference to 'col' must also appear
in a GROUP BY" for complex queries that contained alias names in the
GROUP BY list. This has now been fixed.
================(Build #4262 - Engineering Case #783215)================
In a rare scenario where a cached plan encountered an error, a memory leak
could have occurred. This has been fixed.
================(Build #4261 - Engineering Case #783120)================
Some round-earth polygons that should have been rejected due to having 0-area
ring, may have been accepted. An example of this is ‘Polygon (0 0, 10 10,
20 20.00001, 10 10, 0 0)’ This has been fixed.
================(Build #4261 - Engineering Case #783067)================
If a DELETE statement with an ORDER BY clause was executed over a table on
a remote server, the ORDER BY clause was omitted when the statement was forwarded
to the remote server. If an UPDATE statement with an ORDER BY clause was
executed over a table on a remote server that did not have the capability
“Order by allowed in update”, the ORDER BY clause was omitted when the statement
was forwarded to the remote server.
These have been fixed. Both statements now return SQLCODE -706 if they
contain an ORDER BY clause and the server does not have capability “Order
by allowed in update”.
================(Build #4261 - Engineering Case #782421)================
The server did not return an error if an INSERT ON EXISTING UPDATE statement
violated unique indexes on the insert table and silently deleted violating
rows. This has been fixed.
================(Build #4260 - Engineering Case #783019)================
If a DELETE statement in a stored procedure contained an ORDER BY clause,
this clause was ignored when the procedure was executed and would be omitted
from the procedure definition if queried from the system tables. This has
been fixed.
================(Build #4260 - Engineering Case #782872)================
Under rare circumstances, the server could have crashed or returned incorrect
results when executing a parallel query with join hash operators with large
intermediate results. This has been fixed.
================(Build #4260 - Engineering Case #782604)================
Under exceptionally rare circumstances, the server may have hung indefinitely
when executing a regexp_substr SQL function. This has been fixed.
================(Build #4258 - Engineering Case #781783)================
Under exceptionally rare circumstances, the server may have returned the
error "The optimizer was unable to construct a valid access plan"
if a very complex query contained proxy tables and some table references
had the same table name and same correlation name or no correlation name.
This has been fixed.
================(Build #4257 - Engineering Case #782698)================
When the server was running on Windows 10, the value of property(‘Platform’)
was ‘Windows8’. This has been fixed.
================(Build #4249 - Engineering Case #782677)================
Engineering Case 769059 introduced a small performance regression for wide
insert statements. This has now been fixed.
================(Build #4247 - Engineering Case #781332)================
In very rare cases, the server would have crashed with assertion 200509,
indicating that a checksum failure of critical sectors of page 0 had failed.
This was specific to page 0 of the transaction log, and has now been fixed.
================(Build #4247 - Engineering Case #776698)================
On Windows, if a global group was placed in a server’s local group, a user
was a member of that global group, and a mapping existed between the local
group and a login user ID, then an Integrated Login would have failed.
For example, given that global groups EngineeringA and EngineeringB are
members of the local group Engineering and the local group Engineering has
an integrated login mapping as follows:
GRANT INTEGRATED LOGIN TO Engineering AS USER ENGINEER;
Then if the user attempting an integrated login belonged to the global group
EngineeringA or EngineeringB, the login attempt should have succeeded, but
did not.
This problem has now been fixed.
================(Build #4247 - Engineering Case #776458)================
If a Transact SQL CREATE PROCEDURE statement contained a DECLARE CURSOR for
CALL procedure then the server would have returned a syntax error near 'execute'.
This has been fixed.
================(Build #4246 - Engineering Case #781752)================
Under rare circumstances, the server could have crashed when canceling a
parallel query. This has been fixed.
================(Build #4246 - Engineering Case #781524)================
If an application executed an INSERT statement that inserted values into
a temporary table, and if some of those values came as the result of an external
environment function call, then the server could on occasion have failed
the insert with a 'table not found' error. This problem has now been fixed.
================(Build #4245 - Engineering Case #781486)================
SQL Anywhere clients and servers now use a new library for LDAP support instead
of libsybaseldap[64].dll/so. If deploying the clients or servers with LDAP
support, the new library must be included. In addition, a new library will
be used by the server when the -fips switch is used. The new library names
are (NN is the major version number):
Windows: dbldapNN.dll, dbldapfipsNN.dll
Unix server and threaded clients: libdbldapNN_r.so
Linux server and threaded clients: libdbldapfipsNN_r.so
Unix non-threaded clients: libdbldapNN.so
================(Build #4245 - Engineering Case #781387)================
The server would have taken a very long time to parse large parameter lists
of function or procedure calls. This has been fixed.
================(Build #4244 - Engineering Case #780884)================
In very rare timing dependent cases, concurrently connecting to the server
could have resulted in the server crashing. This could have only occurred
if the number of connections (both established and in the process of connecting)
was greater than it had ever been since the server had started. This has
been fixed.
================(Build #4243 - Engineering Case #781245)================
The LastReqTime connection property was showing the time in the previous
time zone even after the time zone was adjusted because of daylight saving
time. This has been corrected.
================(Build #4240 - Engineering Case #780116)================
If the server was shut down just as a backup was starting, the server could
have hung and never completed the shutdown. This has been fixed.
================(Build #4239 - Engineering Case #779711)================
When running an archive backup of a large database (greater than 5 GB), the
server would appear to be hung. Other connections would also hang and new
connections would not be allowed. The server would eventually continue and
the backup would complete but the server could be unavailable for several
minutes. This has been fixed.
================(Build #4238 - Engineering Case #780376)================
The SET OPTION statement allowed the user to set min_password_length to a
number greater than 255. When this happened, the user was not able to change
the DBA password until min_password_length was set to a number within the
valid range. This has been fixed so that if the user attempts to set set
min_password_length to a number greater than 255, the server will return
the error: -201 : Invalid setting for option 'min_password_length'
================(Build #4237 - Engineering Case #754970)================
In rare, timing dependent cases, the server could have hung indefinitely
if it was renaming the transaction log at the same time as a DDL operation.
This has been fixed.
================(Build #4237 - Engineering Case #677178)================
Under rare circumstances, the server may have crashed if there was a cycle
in computed column dependencies and a COMPUTE expression contained a subselect.
This has been fixed.
================(Build #4236 - Engineering Case #780137)================
If a statement contained a distinct aggregate (e.g., COUNT( DISTINCT T.x))
and an error was detected while evaluating aggregates, than an improper result
might have been returned. The problem has been fixed.
================(Build #4236 - Engineering Case #780131)================
When using unary minus twice in a row (e.g., "- -5"), an error
in unparsing could have lead to incorrect behaviour for procedures, views,
or statements logged to the transaction log.
For example, the following function should return 5:
create function F() returns int
begin
return - - 5;
end;
It incorrectly returned NULL because the 'return - - 5' is unparsed as 'return--5;'
and the '--' is a comment start. Other types of statements could have lead
to syntax errors.
When unparsing CHECK constraints, the server previously removed one set
of extra parentheses:
CHECK ( (x < 5) ) „» CHECK( x < 5 )
However, additional pairs were not removed:
CHECK ( ((x < 5)) ) „» CHECK( (x < 5) )
This has been changed so that all outer parentheses are removed.
================(Build #4236 - Engineering Case #780124)================
TSQL join conditions such as *= and =* can be used to express outer joins
when they are used in the FROM clause. In some queries, they are used improperly
in the SELECT list or GROUP BY list (for example, when they are used in IF
or CASE expressions). These uses are invalid but were not recognized as such,
leading in some cases to answers that did not match the query appeared to
intend or in other cases to an error message that did not clearly identify
the problem.
This has been fixed; the following error is now returned for these types
of queries.
INVALID_TSQL_JOIN_TYPE 52W24 -681L
"Invalid join type used with Transact-SQL outer join"
================(Build #4236 - Engineering Case #767808)================
If the Information utility (dbinfo), or the Validation utility (dbvalid),
or the VALIDATE DATABASE statement, was run against a database and a backup
of that database was done shortly thereafter, there may have been problems
recovering the backup. This has been fixed.
================(Build #4234 - Engineering Case #779828)================
When using a quantified subquery, invalid comparison relations for geometries,
such as "<", were permitted even though these are not semantically
meaningful. These were evaluated using an internal sorting order for geometries.
This has been fixed. Now a comparison such as the following results in an
error:
select * from T where pt < any ( select pt from t_sp ) or x < 10
The comparison '<' cannot be used with geometries.
SQLCODE=-1440, ODBC 3 State="HY000"
Further, quantified subqueries now apply the same automatic casting rules
as scalar comparisons, allowing a string (WKT, WKB or XML) to be compared
to a geometry value. The string is implicitly cast to a geometry before the
comparison.
================(Build #4233 - Engineering Case #778920)================
In some rare situations a redo log could have become corrupted after creating
an index on the table that had DML activity. This has been fixed
================(Build #4232 - Engineering Case #779827)================
If a database server was configured to listen on multiple TCP ports and to
register itself with LDAP, the addresses listed in the LDAP entry only contained
one of the port numbers. This has been fixed.
================(Build #4232 - Engineering Case #779487)================
An application that attempted to execute a remote function call that returned
a numeric or decimal value would have caused a server crash. This problem
has now been fixed.
================(Build #4231 - Engineering Case #779673)================
Under rare circumstances, an aggregate query running on a server with low
memory conditions could have failed assertion 106107 - "Unexpected field
type ... when trying to create read set". This has been fixed.
================(Build #4231 - Engineering Case #766532)================
If invalid HTTP parameters were provided to the database server running on
Unix systems, the server may have detected, but tyhen hung. This has been
fixed.
================(Build #4229 - Engineering Case #779448)================
The server may have returned the error "Column '???' not found",
or "Invalid expression near 'Col1'" for an INSERT, UPDATE, or DELETE
statement that was part of a stored procedure if a table column was dropped
or renamed and the procedure was in execution at time. This has been fixed.
================(Build #4228 - Engineering Case #779152)================
Incorrect information about an INPUT/OUTPUT parameter of a Transact-SQL stored
procedure could have appeared in the SYSPROCPARM system table. This has been
fixed.
Note, the issue did not affect execution of the stored procedure. Recompiling
an affected procedure using ALTER PROCEDURE … RECOMPILE would have fixed
the catalog information.
================(Build #4228 - Engineering Case #779078)================
In very rare cases, the server may have crashed if the null supplying side
of an outer join contained a grouping query block based on constant expressions.
This has been fixed.
================(Build #4228 - Engineering Case #771704)================
Invoking a system stored procedure with an invalid named parameter could
have succeeded without an error. This has been fixed.
For example, this query now returns an error:
Select *
From sa_locks( garbage=1);
================(Build #4223 - Engineering Case #778371)================
In memory-constrained environments, queries containing a subquery which contained
a ROLLUP, CUBE, or GROUPING SETS operation could have failed the non-fatal
assertion 102501 (Work table: NULL value inserted into not-NULL column).
This has been fixed. A workaround is to rewrite the subquery as a join.
================(Build #4223 - Engineering Case #778369)================
If a server was started on a Windows system with the -qw command line option,
but no -n server_name option (i.e. the server name was derived from the database
name), the server would have incorrectly shown a tool tray text of "???
- SQL Anywhere Personal Server" (or "… Network Server").
The tool tray text is shown when the mouse hovers over the tool tray icon.
This has been fixed to display the server name instead of ???.
================(Build #4223 - Engineering Case #736575)================
In some cases, a statement that contained a dotted reference was misinterpreted
with the dotted reference interpreted as a row access.
For example:
select (dt.ci).nosuchcolumn
from (
select cast(row(25 as val1,27) as row(val1 int, ci int)) ci
) dt
would have incorrectly returned DT.ci.ci instead of an error. This has now
been fixed.
================(Build #4223 - Engineering Case #736573)================
When executing statements that included invalid uses of the NUMBER function,
the statement could have failed with a non-fatal assertion failure.
For example:
select COUNT( DISTINCT NUMBER(*) )
from sys.dummy
would have failed with the following error:
*** ERROR *** Assertion failed: 106103 (16.0.0.1320)[asatest] NUMBER(*)
is not associated
This has been fixed so that an appropriate error is now returned.
================(Build #4223 - Engineering Case #736571)================
Certain SQL constructs containing selectivity estimates could have caused
the server to crash. This has been fixed.
================(Build #4223 - Engineering Case #736570)================
Statements that included invalid Transact-SQL outer join predicates, did
not give appropriate errors.
For example, the following gave an “invalid expression” error:
select count(*) c
having c *= 0
This has been fixed.
================(Build #4223 - Engineering Case #736546)================
The LIKE predicate allows an optional ESCAPE argument which must be a single
character. In some cases where the string and pattern could be optimized,
an error was not returned for ESCAPE arguments that did not consist of a
single character.
For example:
select if 'abc' like 'abc' escape '99' then 1 else 0 endif
should have failed with an error, but did not. This has been fixed.
================(Build #4223 - Engineering Case #736544)================
When creating or altering a table, CHECK constraints were allowed that were
not valid. These failed when evaluating the CHECK at execution time.
- in TABLE checks, unknown column/variable names were permitted if they
started with '@'
- aggregate and window functions were permitted
- ROWID() and NUMBER() were permitted
- host variable references were permitted
This has been fixed. These now give appropriate errors when the CHECK is
created.
================(Build #4222 - Engineering Case #778303)================
In rare, timing dependent conditions, the server could have crashed when
executing CONNECTION_PROPERTY( 'UtilCmdsPermitted', n ), CONNECTION_PROPERTY
( 'Progress', n ) or CONNECTION_PROPERTY( 'CurrentProcedure', n ) where n
was a connection number other than the current connection. Note that these
properties are executed as part of calls to the sa_conn_properties system
procedure. This has been fixed.
================(Build #4219 - Engineering Case #777870)================
In specific circumstances, a very complex query could have failed with an
assertion failure: 106104 "Field unexpected during compilation".
This has been fixed.
================(Build #4219 - Engineering Case #777436)================
If an application made an external environment call, and if that external
environment call returned with an open procedure cursor, then the server
would have crashed if the application subsequently disconnected without getting
the external environment to close the procedure cursor. This problem has
now been fixed.
================(Build #4219 - Engineering Case #774595)================
If an application had a trigger that referenced a materialized view, and
if that trigger was subsequently fired while making an external environment
call, then there was a chance the server could have crashed. This problem
has now been fixed.
================(Build #4217 - Engineering Case #777370)================
The server could have crashed if there were unusual operations between a
statement prepare and cursor open, as well as other connections performing
DDL during the lifetime of the cursor. This has been fixed.
================(Build #4216 - Engineering Case #777478)================
The server may have crashed if user estimates in a query were placed in clauses
other than the WHERE or ON clauses. This has been fixed.
================(Build #4214 - Engineering Case #777385)================
When constructing certain round-earth geometries, the 32-bit server could
have crashed. This was more likely for servers with the fix for Engineering
case 765031. This has been fixed. There is no known workarounds.
================(Build #4214 - Engineering Case #776816)================
Under some conditions, the server may have crashed when trying to access
the property TcpIpAddresses from an event. This has been fixed.
================(Build #4213 - Engineering Case #776911)================
The server may crash if an UPDATE on a table that had a publication used
a cached plan. This has been fixed.
================(Build #4212 - Engineering Case #777200)================
Under rare circumstances, the server could have crashed when executing a
positioned update. This has been fixed.
================(Build #4202 - Engineering Case #776241)================
Under rare circumstances, query plans involving parallel hash joins running
in memory-constrained environments may have crashed the server. These query
plans may also have been used by internal operators, such as those that do
table validation and foreign key building, causing these statements to fail
as well. The crash can occur only on servers that contained the fix for Engineering
case 769501, as the issues fixed by that change would have masked the issue.
This has been fixed.
Note, the problem can avoided by disabling parallel query execution (i.e.
set option PUBLIC.max_query_tasks=1), and can be made less likely by increasing
the amount of memory available to the server.
================(Build #4201 - Engineering Case #776157)================
Invalid use of the ARRAY clause in an embedded SQL EXECUTE statement could
have crashed the server. This has been fixed.
================(Build #4199 - Engineering Case #775640)================
When executing an ALTER TRIGGER … SET HIDDEN on an INSTEAD OF trigger for
a view, an “invalid trigger type for view” error was returned. This has been
fixed.
Note, this issue also affects creating INSTEAD OF triggers with encrypted
definitions on views as well.
================(Build #4197 - Engineering Case #775809)================
In rare, timing dependent cases, the server could have crashed when making
a native external function call if a thread deadlock error occurred. This
has been fixed.
================(Build #4197 - Engineering Case #775403)================
Under certain circumstances, calling the xp_scanf system procedure could
have caused the server to crash. Also, format specifiers other than %s could
have given unpredictable results. These have both been fixed.
================(Build #4197 - Engineering Case #774060)================
The server may have crashed or failed assertion 106104 - "Field unexpected
during compilation" when using IN list predicates that do not just contain
literal constants. This has been fixed.
================(Build #4196 - Engineering Case #775550)================
When the procedure st_geometry_dump recursively expanded a geometry of dimension
>= 1 defined in a round-earth spatial reference system, the rows returned
for internal points were incorrect.
For example, the query:
select geom from st_geometry_dump( new ST_LineString(new ST_Point(1,1,4326),
new ST_Point(2,2,4326)))
incorrectly returned the rows:
LineString (1 1, 2 2)
Point (180 -.000000000000006)
Point (180 -33.690067525979835)
This has been fixed.
================(Build #4196 - Engineering Case #773123)================
When computing a set operation (ST_Union, ST_Intersection, ST_Difference,
ST_SymDifference), the value NULL was incorrectly returned if one of the
inputs was an empty curve (e.g., 'LineString EMPTY'). This has been fixed.
================(Build #4196 - Engineering Case #767053)================
Applications that attempted to make server side calls in a CLR External Environment
would only have worked with .NET 2.0 or 3.5. Applications could use the CLR
External Environment with assemblies targeted at .NET 4.0 or 4.5, provided
those assemblies did not make server side calls back to the SQL Anywhere
server. This problem has now been fixed, and new CLR External Environment
executables have now been included for use with .NET 4.0 or 4.5.
It should be noted that only one CLR External Environment can be launched
per database. Hence applications need to decide prior to starting the CLR
External Environment which version of .NET should be used. By default, the
server will launch the CLR External Environment that will allow server side
calls using either the .NET 2.0 or 3.5 Provider. If an application needs
to make server side calls using .NET 4.0; then the following ALTER EXTERNAL
ENVIRONMENT statement must be executed prior to starting the CLR External
Environment:
ALTER EXTERNAL ENVIRONMENT CLR LOCATION 'dbextclr[VER_MAJOR]_v4.0 '
Similarly, if an application needs to make server side calls using .NET
4.5; then the following ALTER EXTERNAL ENVIRONMENT statement must be executed:
ALTER EXTERNAL ENVIRONMENT CLR LOCATION 'dbextclr[VER_MAJOR]_v4.5 '
If the application needs to go back to .NET 2.0 or 3.5; then the following
ALTER EXTERNAL ENVIRONMENT statement must be executed:
ALTER EXTERNAL ENVIRONMENT CLR LOCATION 'dbextclr[VER_MAJOR] '
Note that in each of the above [VER_MAJOR] should NOT be replaced with one
of 12 or 16. It is best to keep [VER_MAJOR] as is in order to ensure a smooth
transition to a newer version of SQL Anywhere if needed.
================(Build #4194 - Engineering Case #774773)================
In very rare, timing dependent cases, if a procedure was being accessed (normally
due to being called) at the same time it was being dropped or altered, the
caller could have executed the previous definition of the procedure. It was
also possible in extremely rare cases to drop a procedure that was already
dropped, which could have caused the server to assert it was applying this
second incorrect drop operation. This has been fixed so that a caller cannot
access the old definition of a procedure, and so that a procedure that is
already dropped cannot be dropped again.
================(Build #4193 - Engineering Case #775247)================
The value of the CurrentLineNumber connection property could have been reported
incorrectly for a procedural statement (for example, SET or MESSAGE). This
has been fixed.
================(Build #4193 - Engineering Case #774798)================
In rare, timing dependent cases, the server could have crashed when getting
one of the CharSet, NCharCharset, ClientLibrary or Language connection properties
for another connection (using connection_property( prop_name, conn_number
). This has been fixed.
================(Build #4193 - Engineering Case #773629)================
When the path for the server command line option -a ("apply named transaction
log file") was wrong (the path is relative to the database path, not
the server path) the server still seemed to go through recovery even though
it did not. This has been fixed. Now server will return an error in such
situations.
================(Build #4193 - Engineering Case #764386)================
If an application executed a query against a Microsoft SQL Server proxy table
that contained SELECT FIRST or a subquery in an IF EXISTS( … ), then there
was a chance the Remote Data Access layer would incorrectly send the SELECT
FIRST to the remote server. Note that a similar problem existed with remote
Oracle servers as well. These problems have now been fixed and the Remote
Data Access layer will now send a TOP 1 instead.
================(Build #4191 - Engineering Case #774462)================
Under rare circumstances, the server could have crashed when describing a
result set returned from a stored procedure. This has been fixed.
================(Build #4191 - Engineering Case #774305)================
Execution of the statement DROP <object-type> IF EXISTS <owner>.<object-name>
would have returned the error "User ID '%1' does not exist" if
<object-type> was a FUNCTION, PROCEDURE, or PUBLICATION, and there
was no user named <owner>. This has been fixed.
================(Build #4190 - Engineering Case #774328)================
In rare cases, dropping a temporary procedure could have caused the server
to crash. This has been fixed.
================(Build #4189 - Engineering Case #774333)================
Certain values returned by the SNMP agent may have been incorrect. This would
only have happened if the values were greater than approximately 2 billion.
This has been fixed.
================(Build #4188 - Engineering Case #771780)================
If an application made an external environment call and then subsequently
used STOP EXTERNAL ENVIRONMENT or STOP JAVA to shut down the external environment
then there was a very small chance the server could have hung or crashed
if the external environment crashed at the same time as the stop request.
A similarly rare problem could have occurred if the connection was dropped
at the same time the external environment crashed. This problem has now been
fixed.
================(Build #4185 - Engineering Case #773703)================
Under exceptionally rare circumstances, the server may have leaked an internal
connection with the connection name "INT:FlushStats", and therefore
could not complete the database and server shutdown when requested. This
has now been fixed.
================(Build #4185 - Engineering Case #773683)================
The server may have crashed if a DELETE statement that deleted rows from
a local table also referenced proxy tables. This has been fixed.
================(Build #4184 - Engineering Case #773422)================
Under some conditions, when importing from a file containing long string
values into a table with fixed length fields the server could have failed
assertion 100914. This has been fixed
================(Build #4184 - Engineering Case #773420)================
If more than 254 databases were specified on the command line when starting
the database server, the server would have quit without giving an error.
This has been fixed. A "Too many databases specified: <dbname>"
error will now be generated.
================(Build #4179 - Engineering Case #771731)================
If an ALTER failed between START and STOP SYNCHRONIZATION SCHEMA CHANGES
there was a possibility that the server would have failed assertion 107101
("Table lock inconsistency"). This has been fixed.
================(Build #4179 - Engineering Case #771622)================
The COUNT_BIG() aggregate function is intended to be used in cases where
the number of rows is larger than can be represented in an INTEGER. When
initially implemented for SQL-level compatibility, COUNT_BIG() was an alias
for COUNT(), returning an INTEGER and restricted to the same supported input
cardinalities. COUNT_BIG() has been corrected to now return a BIGINT.
When executing a parallel query plan with a COUNT_BIG() over a table larger
than representable in an INTEGER (approximately 2 billion rows), an error
such as “Value SUM() out of range for destination” was returned. This is
now corrected.
The SUM(x) aggregate function now returns BIGINT if x is of type BIGINT.
When using COUNT_BIG() in sliding window queries, the window was re-scanned
for each row of the window instead of decrementing the count when rows were
removed. This has been corrected.
The graphical plan for window operators now displays the PARTITION BY, ORDER
BY, and window functions computed by the operator. It also shows whether
rows are removed from the functions by inverting the aggregate (e.g., SUM,
COUNT, COUNT_BIG) or by rescanning the window (e.g., MIN,MAX). Rescanning
the buffer is slower and proportional to the square of the maximum buffer
size.
The COUNT_BIG aggregate is now supported for incremental maintenance materialized
views.
When printing COUNT_BIG with no argument, it is now printed as COUNT_BIG(*).
If COUNT_BIG() was used in a subquery that was flattened by semantic transformations,
it was possible for the function to improperly return NULL instead of 0 (the
classic count bug). This has now been corrected.
================(Build #4176 - Engineering Case #772523)================
Under exceptionally rare circumstances, the server may have crashed when
executing complex statements with proxy tables. This has been fixed.
================(Build #4174 - Engineering Case #771281)================
The server may have appeared to hang while creating a histogram on a NUMERIC
column that had an index. This has been fixed.
================(Build #4171 - Engineering Case #771878)================
If a client-side backup was terminated, or failed due a communication error
or other unexpected error, database and transaction log file growth could
have had poor performance. This has been fixed.
Also, if the server was shut down while a backup was in progress, the backup
could have reported a protocol error. This has been fixed so that a "Database
server not found" error is now returned.
================(Build #4170 - Engineering Case #771105)================
The global variable @@error could have been set incorrectly for the first
error encountered in a stored procedure or batch. This has been fixed.
================(Build #4169 - Engineering Case #771690)================
In very rare cases, the server may have crashed while executing the system
procedure xp_cmdshell() if the client connection calling the procedure was
cancelled. This has been fixed.
================(Build #4169 - Engineering Case #771431)================
In specific circumstances, if there were concurrent connections executing
the same procedure it was possible for the server to crash. The conditions
were rare and timing dependent, and have now been fixed.
================(Build #4168 - Engineering Case #771542)================
Executing CREATE SUBSCRIPTION or DROP SUBSCRIPTION statements could have
failed if they used a subscription-value. This has been fixed.
================(Build #4166 - Engineering Case #771444)================
JSON services would have returned an empty document if an SQL error occurred.
This has been fixed so that an object containing one row with two keys, status:
“error”, and message: “<text of the SQL error message>”, is now returned.
================(Build #4166 - Engineering Case #771441)================
Creating a JSON service that called a procedure which set the CharsetConversion
option would have caused the server to crash. This has been fixed.
================(Build #4166 - Engineering Case #770430)================
A server thread can go into an infinite loop attempting to update an index,
eventually resulting in a server hang. The index in question is not corrupt,
the server was just misinterpreting an index key. The is fixed so that the
key is now interpreted correctly.
================(Build #4165 - Engineering Case #771044)================
The server may have incorrectly returned the error: 'Function or column reference
to '<user-name>' in the ORDER BY clause is invalid', if a select statement
used a user-defined function with an owner name in the ORDER BY clause; e.g.
ORDER BY <user-name>.<function-name(...). This has been fixed.
================(Build #4165 - Engineering Case #770510)================
Under rare circumstances, the server could have crashed executing query plans
involving group-by operators above parallel scans when operating in memory-constrained
environments. This has been fixed. The problem can be avoided by disabling
parallel query execution (set option PUBLIC.max_query_tasks=1), or made less
likely by increasing the amount of memory available to the server.
================(Build #4165 - Engineering Case #769501)================
Query plans involving parallel hash joins running in memory-constrained environments
may have failed to return all of the rows from the join. These query plans
may also be used by internal operators, such as those that do table validation
and foreign key building, causing these statements to also fail. This has
now been fixed. The problem can avoided by disabling parallel query execution
(set option PUBLIC.max_query_tasks=1), and can be made less likely by increasing
the amount of memory available to the server.
================(Build #4165 - Engineering Case #769347)================
The UPDATE and DELETE statements do not support ordinal column numbers in
the ORDER BY clause. DELETE statements that bypass the optimizer did not
return an error if ordinal column numbers were used in the ORDER BY. This
has been fixed.
For UPDATE and DELETE statements the SQL reference correctly documents:
"You cannot use ordinal column numbers in the ORDER BY clause."
But for DELETE statements the syntax must be changed from
[ ORDER BY { expression | integer } [ ASC | DESC ], ... ]
to
[ ORDER BY expression [ ASC | DESC ] , ...]
================(Build #4163 - Engineering Case #770956)================
A query with WITH RECURSIVE and FOR XML/JSON clauses could have returned
an error when used in a stored procedure definition. This has been fixed.
Note, affected procedures will need to be recreated with the fixed version
of the server.
================(Build #4163 - Engineering Case #770597)================
The server may have crashed while updating a histogram. This has been fixed.
================(Build #4163 - Engineering Case #770496)================
Under exceptionally rare circumstances, the Unload utility (dbunload) would
have returned the error "Primary key for table 'sa_unload_stage2' is
not unique". For this to have occurred, the unloaded database must have
contained foreign keys with very high ids, and the constraint name of the
foreign key must have been renamed. This has been fixed.
================(Build #4163 - Engineering Case #769356)================
Under exceptionally rare circumstances, the server may have crashed during
concurrent execution of a stored procedure that contained a LOAD TABLE statement.
This has been fixed.
================(Build #4163 - Engineering Case #768186)================
The server may have returned poor selectivity estimates for equi-sarg searches
on a floating-point type column. Some changes have been made to improve the
accuracy of these estimations.
================(Build #4162 - Engineering Case #768791)================
The server could have hung attempting to schedule a recurring event. This
has been fixed.
================(Build #4162 - Engineering Case #768034)================
In rare timing dependent cases, a synchronized mirror server could have failed
to take over as primary when the old primary went down. In order for this
problem to have occurred the mirror database must have restarted while the
primary server was still running. This has been corrected.
================(Build #4162 - Engineering Case #751752)================
A secure web procedure call through a proxy server could have failed with
error code -988, “Invalid response from the HTTP server” if the web server
or proxy attempted to redirect the call with a “301 Moved Permanently” status
code. This has been fixed.
================(Build #4159 - Engineering Case #748349)================
In extremely rare timing dependent cases, it was possible for the transaction
log on a copy node to have become corrupted. In order for the potential
corruption to have occurred, the copy node needed to have a parent other
than the primary/root server, and the parent must have been writing a page
to the transaction log at the same time the child copy node was requesting
the last page of the parent's transaction. Note that once the copy node
has caught up the log operation of the parent, the parent sends pages to
the copy node during commit operations. This problem could have only occurred
when the copy node is requesting pages from the parent, and not when the
parent is sending pages to the copy node. This has been fixed.
================(Build #4159 - Engineering Case #727093)================
In extremely rare, timing dependent cases a database could have been corrupted
if a server crashed or was terminated during a checkpoint, and then was terminated
again during recovery. This has been fixed.
================(Build #4157 - Engineering Case #767963)================
Calling the system procedure xp_cmdshell() could have caused the server to
shut down on UNIX in rare, timing-dependent events. This has been fixed.
There is no known workaround.
================(Build #4156 - Engineering Case #769515)================
If the system procedure sa_validate() was called with a table or materialized
view name only, then only one of the possibly several owner.name objects
was validated. For example, given two tables named "Products" as
follows:
CREATE TABLE FarmEquipment.Products(...);
CREATE TABLE HighwayEquipment.Products(...);
the following statement would only have validated one of them at random:
SELECT * FROM sa_validate( 'Products' );
Even if the user execting the SELECT was the owner of a table called "Products",
it may not have been the table that is validated. In other words, the statement
above was not equivalent to:
VALIDATE TABLE Products;
The documentation states that all tables/materialized views matching the
specified object name are validated. This problem has been fixed. The work-around
is to specify the table/materialized view owner (the second argument).
================(Build #4156 - Engineering Case #768882)================
Under rare circumstances, executing a procedure defined with SQL SECURITY
INVOKER could have cashed a server crash. This has been fixed.
================(Build #4156 - Engineering Case #768311)================
Under exceptionally rare circumstances, the server may have crashed when
running the system function CONNECTION_PROPERTY() for a connection other
than the one making the request, if the queried property was a connection
option but not a connection statistic. This has been fixed.
================(Build #4155 - Engineering Case #769159)================
When attempting to connect to a secure SMTP server using the system procedure
xp_startsmtp(), the connection would not have timed out. This has been fixed.
================(Build #4155 - Engineering Case #769059)================
Wide INSERT statements (i.e., prepared insert statements which insert more
than one row at a time) require that each host variable/parameter appear
exactly once within VALUES clause and not be nested within an expression.
In some cases, a repeat host variable name would not have been detected and
the resulting inserted row could have contained an incorrect value within
one of the columns. This has now been fixed. Incorrect wide inserts will
now return SQL code -155 (Invalid host variable).
================(Build #4150 - Engineering Case #770143)================
The version of OpenSSL now used by the server (as well as all SQL Anywhere
products) is 1.0.1i.
================(Build #4148 - Engineering Case #768684)================
The server may have returned the error 'Invalid expression' or crashed, if
common table expressions were used in statements with proxy tables. This
has now been fixed.
================(Build #4148 - Engineering Case #737917)================
Some queries that contained an invalid GROUP BY or HAVING clause could have
failed to give an error. Specific constructs that were not correctly validated
include the following:
- x IS OF TYPE(…)
- x IS [NOT] DISTINCT FROM y
- TSEQUAL( x, y )
- array_expression[[ index_expression ]]
- (row_type_expression).field_name
- Subqueries predicates or subselects that contained joins with outer references
in the ON condition
In certain cases, these invalid queries failed with a non-fatal assertion
failure. In specific circumstances, it was also possible for the server to
crash. This problem has now been fixed.
================(Build #4146 - Engineering Case #768466)================
In rare cases, the server would have appeared to not have processed requests
for a duration of 30 seconds. For this to have occurred. the auto multiprogramming
level adjustment had to have been active and there had to have been many
client side connections that were blocked. This has now been fixed.
================(Build #4145 - Engineering Case #764064)================
If a CLR stored procedure attempted to create an SAConnection using the connection
string from the SAServerSideConnection object; the server and CLR External
Environment would both have crashed. For example, if calling a CLR stored
procedure resulted in code similar to the following being executed on the
CLR External Environment side:
SAConnection local_conn = new SAConnection( SAServerSideConnection.Connection.ConnectionString
);
Local_conn.Open()
then both the SQL Anywhere Server and the corresponding CLR External Environment
would crash. This problem has now been fixed.
================(Build #4143 - Engineering Case #767793)================
In rare, timing dependent cases, when the primary went down and the mirror
failed over to become the new primary, it was possible the transaction log
on the new primary to contain operations that were never applied to the database.
This could have resulted in the database file on the primary being different
from the database file on the mirror and any copy nodes. The mirror or copy
nodes could have failed with errors or assertions related to applying the
transaction log. This issue was possible, but extremely unlikely and never
observed, if the synchronization_mode was synchronous. It had been observed
if the synchronization mode was asynchronous or asyncfullpage. This has been
fixed.
================(Build #4142 - Engineering Case #767780)================
The server could have taken a long time to shutdown if the built-in HTTP
server was used during previous executions of any server on the same computer.
Other side effects of this problem may also have been seen:
- If the sadiags.xml file was large then the merge-to-disk operation that
automatically happens at midnight each day may have taken a long time and
any other operation that caused a feature to be ‘counted’ would have blocked
until the merge was complete. I.e. some operations at midnight may have been
seen to ‘hang’ or take longer than usual to complete.
- Mobilink servers could also suffer the slow shutdown (or midnight sync)
problem if a database server was running on the same computer and that database
server had generated a large sadiags.xml file.
This has been fixed. A work-around is to delete the sadiags.xml file prior
to shutting down the server. This should only be expected to improve the
shutdown time if the size of the file is large (e.g. over 100K bytes).
================(Build #4141 - Engineering Case #767873)================
The server could have crashed when performing a recursive union query. This
would only have occurred when running the query against a server with a very
small buffer pool or many active memory-intensive queries. This has now been
fixed.
================(Build #4140 - Engineering Case #767805)================
The server could have crashed when performing a query containing a CUBE or
ROLLUP, or that specified grouping sets. This was only possible when the
server was operating in a memory-constrained environment. This has been fixed.
================(Build #4140 - Engineering Case #767799)================
When attempting to create a database with the reserved name ‘utility_db’(a
very rare use case), the server would have leaked memory. This has been fixed.
================(Build #4139 - Engineering Case #721300)================
Copy nodes which used a partner server name as a parent (as opposed to the
primary or mirror), could have failed to connect to this parent. In this
case, the initial connection to the parent could have succeeded, but if the
parent database or server was restarted, the copy node was unable to connect.
This has been fixed.
================(Build #4139 - Engineering Case #681743)================
In rare, timing dependent cases a server which was a copy node and its parent
could both have hung for several minutes and then the parent report the following
message in the console "Mirroring request timed out: dropping mirroring
connection" and both server continue normally. If this did occur, after
the message was logged, the copy node would have reconnected and both servers
continue normally. In order for this situation to occur, there needed to
be requests from the copy node server to the parent server (such as mirroring
requests for another database or remote data access requests).
This has been fixed so that servers that have less than about 20 committed
transactions per second will no longer hang. There may also be slightly
improved performance when using copy nodes.
================(Build #4138 - Engineering Case #773198)================
Under rare circumstances, the server may have crashed while executing a query
with OPENXML functions. This has now been fixed.
================(Build #4136 - Engineering Case #767121)================
If an application attempted to execute an ALTER EXTERNAL ENVIRONMENT statement
on a case sensitive database, then the server would return an external environment
not found error if the environment name was specified in mixed or upper case.
This problem has now been fixed.
================(Build #4136 - Engineering Case #767050)================
Under rare circumstances, the server could have failed a fatal assertion
with a “Dynamic memory exhausted” error. This has been fixed.
================(Build #4136 - Engineering Case #758580)================
When a reusable plan for a statement in a stored procedure was executed from
the plan cache, in certain cases the reused plan failed to obtain schema
locks on all of the tables occurring in the statement. As a result, another
connection was not blocked from performing concurrent DDL on a table in use
by the cached plan. This scenario could have caused data corruption that
could lead to a non-recoverable database. This has been fixed.
================(Build #4130 - Engineering Case #764810)================
On Linux and Mac OSX platforms, the server was not accepting denormal double
values in INSERT statements. This has been fixed.
================(Build #4130 - Engineering Case #666123)================
The server did not respond to a cancel during execution of a REGEXP or LIKE
predicate if the first operand was a very long constant expression. This
has been fixed.
================(Build #4129 - Engineering Case #737027)================
If in a query block, two equal correlation names referred to exactly the
same view or base table, then the server could have merged them and performed
a query rewrite. The server incorrectly rewrote a query if one of the two
table expressions aliased with the same correlation name was a derived table,
a procedure name, an openstring expression, a contains expression, or a DML
derived table. As a result, the server may have returned an incorrect result
set. This has been fixed.
================(Build #4128 - Engineering Case #765993)================
The server allows one extra connection beyond the connection limit as long
as that connection has the DROP CONNECTION privilege (or DBA authority prior
to version 16). This is to allow that connection to drop other connections
if all connections to a server become blocked. However, once this extra connection
was made, the server would not have allowed new connections until, (a) that
extra connection went away, or (b) two other database connections went away.
This has been fixed – (b) above has been changed to “one other database connection
goes away”.
================(Build #4127 - Engineering Case #765979)================
Calls to connection_property( 'TempFilePages' ) could have incorrectly returned
values greater than 2 billion when 0 should have been returned. This has
been fixed.
================(Build #4126 - Engineering Case #764973)================
In rare, timing dependent cases, the server could have failed assertion 101201
- "Deferred growth not suspended for checkpoint" after a cancelled
backup which did a log rename or truncate. This has been fixed.
================(Build #4124 - Engineering Case #765443)================
Reading beyond the end of a file (e.g., for a LOAD TABLE statement from a
0-length file) on Linux when the file is on a remote NFS drive may cause
the server to crash. This will only happen if O_DIRECT is enabled over NFS
in Linux kernel versions 3.5, 3.6, and 3.7.
Details of the kernel bug can be found here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/nfs/direct.c?id=67fad106a219e083c91c79695bd1807dde1bf7b9
This has been fixed. Direct I/O will no longer be used for remote file
systems on these Linux versions. Upgrading the Linux kernel to at least
3.8 is the only workaround.
================(Build #4124 - Engineering Case #765031)================
A polygon in a Round Earth SRS could have failed to be represented correctly
if it contained an edge on the equator going east to west and crossing latitude
0. This has been fixed.
================(Build #4124 - Engineering Case #725602)================
If a grouped query contained a ROWID function in the SELECT list or the HAVING
clause, where the primary key of the table of the ROWID was in the GROUP
BY list but the ROWID function was not in the GROUP BY list, then an inappropriate
error (“Expression error”) was returned.
For example:
select ROWID(T)
from sys.dummy T
group by dummy_col
This has been fixed. The following error is now returned:
Function or column reference to 'ROWID' must also appear in a GROUP BY
SQLCODE=-149, ODBC 3 State="42000"
To avoid the error, include the ROWID function in the GROUP BY list.
================(Build #4124 - Engineering Case #725601)================
An error could have been incorrectly returned when creating a procedure,
trigger, view, or event if there was a constant literal for a number. For
the problem to occur, the number must have been larger than can fit in a
NUMERIC type, but in range for a DOUBLE value (alternatively, it could have
been a number smaller than can fit in a NUMERIC type but non-zero when interpreted
as a DOUBLE). When the problem occurred, an error such as the following might
have been returned:
SQLCODE=-836 "Procedure 'P1' is no longer valid"
Further, the database where the statement was executed could have failed
to recover after a failure.
For example:
create or replace procedure dba.P1()
begin
select if 1=1 then 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
end if;
end
create or replace procedure dba.P2()
begin
select if 1=1 then 0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
end if;
end
================(Build #4124 - Engineering Case #725600)================
Some queries with invalid ORDER BY clause specifications could have failed
to give an error, given an inappropriate error, or caused a server crash.
This has been fixed.
================(Build #4124 - Engineering Case #725599)================
In some cases, invalid DEFAULT values were allowed when executing a CREATE
TABLE statement. In specific instances, these invalid default values could
have caused a server crash. This has now been corrected.
================(Build #4123 - Engineering Case #765566)================
Certain syntactically-invalid queries using SELECT FROM DML constructs could
have caused the server to crash. This has been fixed.
================(Build #4122 - Engineering Case #765821)================
Server could have hang while executing a stored procedure that invoked other
stored procedures. This has been fixed.
================(Build #4121 - Engineering Case #761197)================
The database server may have crashed if any one dbspace file reached the
maximum size of 0x10000000 pages. If a single dbspace needs more space and
cannot be split into multiple dbspaces, a larger page size is required.
For example, the dbspace size limit for a 2K page size is 512GB while a 4K
page size may create dbspaces up to 1TB in size.
When a single file gets too big, the server will now detect this situation,
version 11 and 12 servers will display a failed assertion message and shut
down. Version 16 and later servers will display a failed assertion message
and shut down only the affected database.
================(Build #4119 - Engineering Case #764849)================
If a very long string was unloaded from a database and was loaded into a
second database with a different character set, the LOAD TABLE statement
may have returned the SQL error: -1313, “Maximum string length exceeded.”
This was only likely to happen if the length of the string was within a page
size of the string limit of 2GB-1. This has been fixed.
================(Build #4119 - Engineering Case #764411)================
If the first line of the HTTP response from an outbound client HTTP request
was split across two or more packets then the server would have failed to
accept the response from the remote server. This has been fixed.
================(Build #4115 - Engineering Case #763803)================
Loading the following polygon:
POLYGON((-1 -1, -1 1, 0 0, 1 1, 1 -1, -1 -1))
would have resulted in an invalid polygon error. This has been fixed. There
is no known workaround.
================(Build #4115 - Engineering Case #666731)================
Under rare circumstances, the server could have hung when values for WHERE
or SUBSCRIBE
BY clauses were being changed in a table with an article. This has been
fixed. This fix covers additional cases that were not covered by Engineering
case 654952.
================(Build #4110 - Engineering Case #763545)================
SET MIRROR OPTION auto_failover = 'On' was incorrectly being treated as 'Off'.
As a workaround, SET MIRROR OPTION auto_failover = 'Yes' can be used. This
has been fixed so that both 'On' and 'Yes' are now supported.
================(Build #4110 - Engineering Case #762317)================
If a computer supported IPv6, but had IPv4 disabled, the database server
would have failed to start if TCP/IP or HTTP were being used. In addition,
a SQL Anywhere client application running on such a machine could have failed
to find servers using TCP/IP. These problems have now been fixed.
================(Build #4108 - Engineering Case #763241)================
In rare cases, the database server may have crashed while request level logging
was turned on. This has been fixed.
================(Build #4107 - Engineering Case #763031)================
In very rare, timing dependent cases, starting a server with a mirrored database
could have failed with the server failing assertion 101426. This has been
fixed.
================(Build #4106 - Engineering Case #671957)================
The server may have returned an incorrect result set when a query had a grouped
subquery in the null-supplying side of an outer join, and all the following
conditions were true:
- all group by expressions in the subquery were constants
- the subquery had a COUNT aggregate
- the subquery did not affect any table rows
- the outer join condition referenced a constant grouping column of the
subquery
For example: If table T1 has no row with a1 < 44 then the query does
not return rows in any circumstances.
select *
from T2 left outer join
( select 111 c1, count(*) c2 from T1 where a1 <
44 ) V on T2.a2 = V.c1
This has been fixed.
================(Build #4105 - Engineering Case #762616)================
Under very rare circumstances, executing a query with a cached parallel plan
could have crashed the server. This has been fixed.
================(Build #4101 - Engineering Case #761748)================
If the transaction log was renamed while the MobiLink client (dbmlsync) was
performing a sync operation, and no transactions were in progress, the SQL
Anywhere server would have generated the new log in a way that would have
caused dbmlsync to send downloaded rows for upload. This problem has been
fixed
================(Build #4101 - Engineering Case #758543)================
The server could have become deadlocked when attempting to drop a user with
a table in-use. This has been fixed.
================(Build #4100 - Engineering Case #761039)================
Under exceptionally rare circumstances, the server may have crashed when
executing UPDATE or DELETE statements that bypass the optimizer if the number
of columns of the table was evenly divisible by 32, and all the column values
were needed in the statement and an index had been chosen. This has been
fixed.
================(Build #4099 - Engineering Case #761652)================
In rare cases the server may have returned SQLCODE -150 or failed assertion
106104 when optimizing an aggregation query that qualified for optimizer
bypass. This could have occurred when the aggregate function was within the
left-hand side of a dot-notation function expression (primarily occurring
within spatial queries), such as ST_Geometry::ST_EnvelopeAggr(column).ST_AsWKB().
This has been fixed.
================(Build #4098 - Engineering Case #761500)================
The system procedure sa_recompile_views may have returned an unexpected error
if it was executed outside the reload.sql script with non-standard settings
for the database options quoted_identifiers and ansi_close_cursors_on_rollback.
This has been fixed.
================(Build #4097 - Engineering Case #761107)================
The server may have returned an incorrect result set if an OrderedGroupBy
strategy used an index and the GroupBy query block contained an outer reference
after the query rewrite. This has been fixed.
================(Build #4097 - Engineering Case #741082)================
On Windows, event log entries for version 12.0.1 MobiLink and SQL Anywhere
database server services would have shown the service name only on the General
tab of the Event Viewer/Windows Logs/Application window. There was no accompanying
message.
For example, the following text could have been displayed:
SQLANYe_test12
As a workaround, the Details tab can be used to see the missing message
for this event. This problem has now been fixed so that the Details tab will
include the message, as in the following:
SQLANYe_test12: Starting service SQLANYe_test12
================(Build #4095 - Engineering Case #727737)================
Some clauses of the CREATE SPATIAL REFERENCE SYSTEM statement were incorrectly
recorded in the transaction log. This has been fixed
================(Build #4095 - Engineering Case #641490)================
Under exceptionally rare circumstances, the server may have crashed while
executing a parallel plan with outer joins in the parallel plan parts. This
has been fixed.
================(Build #4093 - Engineering Case #760874)================
If the system procedure sa_server_option() was used to change the 'IdleTimeout'
or 'LivenessTimeout' option values to less than 0 or more than 32767, connections
may have been incorrectly dropped. This has been corrected so that an error
is now given if a value less than 0 or more than 32767 is specified for these
options. In both cases, a value of 0 means there is no timeout.
================(Build #4093 - Engineering Case #759431)================
The search condition "<expression> IS [ NOT ] ( type-name, ...
)" may have incorrectly evaluated to FALSE, or have caused a server
crash. This has been fixed.
================(Build #4092 - Engineering Case #760526)================
Under rare circumstances, the server could have crashed when checking whether
a stored procedure could be in-lined. This has been fixed.
================(Build #4092 - Engineering Case #759209)================
The server may have loaded too large a value, and NaN/INF values, into DOUBLE,
FLOAT and REAL columns by LOAD TABLE and OPENSTRING. This has been fixed.
The server will now generate an error for these values.
================(Build #4090 - Engineering Case #747637)================
If an ODBC application performed a wide or array INSERT, where the number
of rows times the number of columns was more than 32767, the INSERT may not
have been as efficient as it should have been. This has been fixed so that
the wide or array INSERT is more efficient in this case.
================(Build #4089 - Engineering Case #760144)================
When performing an absolute or relative fetch, the SELECT list expressions
for rows that are not returned were evaluated. These were not strictly needed
and if they contained expensive operations such as UDFs this could have been
slower than necessary. If the Row_counts option was TRUE and the query optimizer
could not accurately estimate the number of rows to be returned, the server
simulates an ABSOLUTE fetch to position 1000000000 in order to count the
rows. Before this change, all select list expressions were evaluated for
these rows.
These unneeded evaluations are now skipped. A change in behaviour is that
side effects and errors are no longer observed in some cases. There may still
be more executions than client fetches due to factors such as prefetching.
================(Build #4089 - Engineering Case #760022)================
If auditing was on and the database contained events that were executed,
the output from dbtran -g could have contained lines like the following:
--CONNECT-1025-0000952657-failure-2014-03-18 09:36
indicating a possible connection failure. This has been fixed. These lines
do not indicate a connection failure. They can be safely ignored and will
not show up in transaction logs created with fixed servers.
================(Build #4089 - Engineering Case #758422)================
When starting the database server with a minimum multiprogramming level (command
line option "-gnl <value>") that was higher than the default
maximum, the database server would not have adjusted the maximum setting.
The number of threads would never have gone higher than the maximum. This
has been fixed. If the minimum (-gnl) value exceeds the maximum value, then
the maximum and initial MultiProgrammingLevel settings will be readjusted
to this minimum.
================(Build #4087 - Engineering Case #759618)================
A failed ALTER TABLE statement could have corrupted the database. For corruption
to occur, the table being altered must have contained no data, but must have
contained some at some point. The error most likely involved was “column
not found”. Assertion failures possible included 201135 (page freed twice),
201503 (Record X not present on page Y), 200106 (attempting to add row twice),
200131 (Invalid page found in index), 106200 (Unable to undo index changes
during rollback), 100700 (Unable to find table definition X for record referenced
in rollback log), or 101422 (Attempt to write an invalid page).
This has been fixed.
================(Build #4085 - Engineering Case #757959)================
Under exceptionally rare circumstances, the server may have returned too
many rows from a parallel hash semi-join if the build site is the preserved
table. This has been fixed.
================(Build #4084 - Engineering Case #756777)================
In rare cases, the server may have crashed when executing an invalid plan
that contained an equi-join to a correlated subquery. This has been fixed.
================(Build #4083 - Engineering Case #759129)================
If a Java stored procedure was defined such that the number of OUT parameters
in the stored procedure definition was not equal to the number of OUT parameters
in the Java signature, then the server would have returned an ArrayOutOfBounds
exception when the procedure was called. This problem was introduced by the
fixes for Engineering case 691193, and has now been fixed.
================(Build #4083 - Engineering Case #759114)================
Attempting to fetch the date 0000-01-00 as either a java.sql.Timestamp or
java.sql.Date using the SQL Anywhere JDBC Driver would have resulted in the
wrong value being returned and all subsequent timestamp values being incorrect.
This date is not representable within Java, hence the value now returned
will be 0001-01-01 and all subsequent timestamp values will now be correct.
Note that this change is most significant when querying the mv_known_stale_at
column from SYS.SYSVIEW since 0000-01-00 represents a materialized view that
is either fresh or in an unknown state. The value will now be returned as
0001-01-01 instead.
================(Build #4083 - Engineering Case #758811)================
In rare, timing dependent cases, if a connection was running a procedure
and a DDL operation occurred, the server could have crashed. In order for
the crash to have occurred, the procedure needed to have a statement that
referenced a view or multiple tables. This has been fixed.
In rare, timing dependent cases, if multiple connections were running the
same procedure concurrently and a DDL operation occurred, the server could
have hung. In order for the hang to have occurred, the procedure needed
to have had multiple statements that referenced the same view. This has also
been fixed.
================(Build #4083 - Engineering Case #748710)================
Under some circumstances, the server could have crashed when executing a
procedure with NO RESULT SET clause. This has been fixed.
================(Build #4081 - Engineering Case #758899)================
Spatial operations may, in rare cases, have crashed the server. This has
been fixed.
================(Build #4081 - Engineering Case #758564)================
LineStrings in Round Earth SRSs could have been represented incorrectly.
This could have happened for LineStrings with segments crossing equator
from South to North. Additionally, under very rare circumstances, such LineStrings
could have caused a stack overflow exception. This has been fixed.
In the existing databases, LineStrings that cross equator from South to
North and are stored in a Round Earth SRS (for example, 4326) should be reloaded
in order to be stored in the correct representation.
================(Build #4081 - Engineering Case #758063)================
When the system procedure sa_server_messages() was called from services,
in such a way that it returned an empty result set, it could have put the
server in a state where further concurrent calls to sa_server_messages()
could have caused a server crash. This has been fixed.
================(Build #4081 - Engineering Case #751771)================
A user defined function with a SELECT statement containing a common table
expression could have been incorrectly inlined. This has been fixed.
================(Build #4081 - Engineering Case #750691)================
In rare cases, appending or prepending data to the value in a compressed
column could have resulted in a server hang. This has been fixed.
================(Build #4078 - Engineering Case #756394)================
Under exceptional rare circumstances, the server may have crashed when trying
to reuse a cached query plan if tables used in the query were dropped and
recreated. This has been fixed.
================(Build #4071 - Engineering Case #756681)================
In rare cases, the server could have returned an error like:
"Table '_^_^_22072007_^_^_759_^_^_22072007_^_^_' not found"
for an internal temporary table if an INSERT, UPDATE, or DELETE statement
triggered the change of an immediate materialized view. The problem only
happened when the very first INSERT, UPDATE, or DELETE of the table in a
connection was executed in a nested block, for example a trigger or procedure.
In this case subsequent DML operations on the
table may then have returned the above error. This has been fixed.
================(Build #4070 - Engineering Case #757009)================
When the server executed an ALTER TABLE statement, or loaded the table definition
of a table with a unique index (primary key, table/column unique constraint
or unique index) it did not derive the unique property to non-unique declared
indexes that were defined on a superset of the columns of a unique index.
For example: If a table has a primary key on columns (col1, col2) and there
is another index on columns (col2, col3, col1) then this other index is unique
as well.
The optimizer relies very much on this unique property of an index for cardinality
estimation. So the server may have used an non-optimal plan if above conditions
were true. This has now been fixed.
================(Build #4070 - Engineering Case #754724)================
Under exceptional rare circumstances, the server may have crashed when receiving
a host variable value on a TDS communication based connection failed. This
has been fixed.
================(Build #4069 - Engineering Case #757492)================
When a multibyte character string with a truncated last character was unloaded,
the last two bytes of a character may be added to the end of the string as
ASCII characters. This has been fixed.
================(Build #4069 - Engineering Case #757146)================
Under rare circumstances, the server could have crash when executing an ALTER
MATERIALIZED VIEW … IMMEDIATE REFRESH statement. This has been fixed.
================(Build #4068 - Engineering Case #757264)================
In timing dependent cases, a mirror or copy node could have crashed while
shutting down due to an error detected while applying the transaction log
- such as a transaction log mismatch. This crash could have only occurred
after the databases were shut down and communications completed. This has
been fixed.
================(Build #4068 - Engineering Case #756886)================
Mirroring servers now log more detailed information to the console log in
the following cases:
- when failover occurs and the mirror server takes over as the primary
"Now running as primary server" is now logged. Previously, "Database
<name> (<file>) started at <date/time>" was logged,
which was incorrect because the database was already started and was not
restarted.
- if the mirror server was behind applying operations and caused the primary
to block for more than 10 seconds, "primary blocked for <number>
seconds waiting for the mirror to catch up" is logged.
- transaction log start and current offsets are now displayed when starting
up a database and at other transitions (such as when the transaction log
is restarted).
- if there was an unexpected error that caused applying the transaction
log to fail, a message is displayed and the database is not automatically
restarted
================(Build #4067 - Engineering Case #750513)================
The server could have crashed if a TDS based connection sent a cancel request
and a cursor close request at the same time for the same connection. Note
that the cancel request could have either been sent explicitly by the application
or implicitly by the underlying driver due to a query timeout. This problem
has now been fixed.
================(Build #4065 - Engineering Case #756801)================
The builtin SQL functions HTTP_BODY, HTTP_HEADER and HTTP_RESPONSE_HEADER
were returning an empty string when the required value did not exist, instead
of NULL as documented. This has been corrected so that they now return NULL
when the required value does not exist. As well, the builtin function HTTP_RESPONSE_HEADER
has been corrected to recognize the special header name ‘@HttpStatus’ and
return the status code if given ‘@HttpStatus’.
================(Build #4065 - Engineering Case #756028)================
Under rare circumstances, a server that was performing request level logging
could have crashed when executing stored procedure code. This has been fixed.
================(Build #4065 - Engineering Case #748976)================
If a database had one or more of the following public options set differently:
- ansinull=On
- conversion_error=On
- divide_by_zero_error=On
- sort_collation=Internal
- string_rtruncation=On
, and the specified value was then set as a temporary option for the connection
creating a materialized view, recovery of the CREATE MATERIALIZED VIEW statement
would have failed. This has been fixed.
Note that the fix applies only to the CREATE statement executed with the
fixed version of the server.
================(Build #4064 - Engineering Case #756118)================
The server may have incorrectly returned the non-fatal assertion error 106104
"Field unexpected during compilation" for an IN list predicate,
if the IN list contained expressions with column references for which the
value was unknown at open time. This has been fixed.
================(Build #4064 - Engineering Case #692981)================
Within stored procedure code, ARGN and some other builtins, IF expressions,
conjunction or disjunction of predicates, could have eagerly evaluated all
of the subselects in subexpressions. For example, expression
ARGN( 1, (select 1/max(v) from t1), (select 1/min(k) from t2), (select 1/0
from dummy) )
would have evaluated all of the subselects (and returned an error) before
noting that only the first of the subselects needed to be evaluated, and
no error returned. This has been fixed.
NOTE: The evaluation of subselects in procedural expressions now matches
the evaluation in queries. For disjunctions and conjunctions, the order of
evaluation of predicates is not guaranteed.
================(Build #4062 - Engineering Case #662248)================
In rare, timing and data-dependent cases, the server could have hung or crashed
during execution of parallel query plans. This has now been fixed.
================(Build #4061 - Engineering Case #770500)================
Under exceptionally rare circumstances, the server may have crashed when
executing the function CONNECTION_PROPERTY() for a connection other than
the own executors connection, if the queried property was an connection option,
but not a connection statistic. This has been fixed.
================(Build #4061 - Engineering Case #756032)================
If two subscribed publication articles contain two of the same tables and
both contained the same list of columns, when adding a synchronization subscription
to the second publication the database server would have erroneously reported
the error:
SQLCODE -1325: Column subset for table '%1' in publication '%2' does
not match that specified in publication '%3'
This has been fixed.
================(Build #4061 - Engineering Case #755767)================
Iif the OUTPUT statement was attempting to write a string which contained
characters whose Unicode representation was greater than U+FFFF (known as
"supplementary characters"), the statement would have failed with
the message "Could not save result set. Input length = 1" This
has been fixed.
================(Build #4060 - Engineering Case #755524)================
Under rare circumstances, queries using hash filters could have caused the
server to crash. This was more likely in environments with a heavy load,
and/or cursors held open for long periods of time. This has been fixed.
================(Build #4059 - Engineering Case #755676)================
In very rare, timing dependent cases, establishing a connection with a non-default
maximum packet size connection parameter could have caused a loaded server
to crash. The default maximum packet size for a server can be specified
using the -p server option. A client application can request a different
packet size using the CBSize connection parameter. Mirroring servers containing
Engineering case 750502 change would also have used a non-default maximum
packet size. This has now been fixed.
================(Build #4058 - Engineering Case #754832)================
In rare, timing dependent cases, the server could have crashed when a mirrored
database was stopped or restarted. The crash was more likely (but still
rare) if asyncfullpage mode was used. Note that mirrored databases can automatically
restart for a number of reasons - for example after loss of quorum. This
has now been fixed.
================(Build #4058 - Engineering Case #753193)================
If a database server was running multiple databases with mirroring enabled,
and one of the databases incorrectly used a primary or mirror alternate server
name that was already in use by another database, connections to the other
database that used the alternate server name could have failed. This has
been fixed so that if one database starts using a particular alternate server
name, that alternate server name will not be removed if a second database
attempts to use it.
================(Build #4057 - Engineering Case #753721)================
The row-level update triggers and referential update actions may have incorrectly
fired for unchanged columns if the UPDATE statement was executed by SQL Remote
and caused an update conflict. This has been fixed.
================(Build #4050 - Engineering Case #753615)================
In very rare, timing dependent cases, the server could have crashed when
starting or stopping a database, failing on a "MESSAGE ... TO CLIENT
FOR ALL" statement. This has been fixed.
================(Build #4040 - Engineering Case #753719)================
Zero-length linestrings were being treated as invalid. For example, selecting
ST_Geometry::ST_GeomFromText( 'LineString( 1 1, 1 1 )' ) would have resulted
in an error indicating that linestrings must have at least two points. The
OGC standard does not forbid zero-length linestrings, so this geometry should
be accepted. This has been fixed.
================(Build #4040 - Engineering Case #752967)================
The server may have returned an incorrect result set for a complex query
with multiple nested derived tables or views, if there was an equality predicate
that could have been pushed inside the nested derived tables and the outside
derived table could have been flatted. If the problem happened, the equality
predicate was not executed and the result
set contains additional incorrect result rows.
For example, in the below query the predicate "v2.c = 0" can be
pushed inside the derived table "v2" and derived table "v2"
can be flatted. Predicate is not executed in this case.
select *
from ( select distinct *
from ( select a, sum(b) c from T1 group by a )
v1
) v2
where v2.c = 0
This has been fixed.
================(Build #4038 - Engineering Case #753279)================
Execution of a DROP statement with an IF EXISTS clause for a table, view
or materialized view, incorrectly returned an error if the object of the
requested object type did not exist but there was an object with the same
name but different object type. For example: there exists a table "Products"
then a "DROP VIEW IF EXISTS Products" returns the error "Table
'Products' not found". This has been fixed.
================(Build #4034 - Engineering Case #751684)================
If a domain was dropped and re-created within a batch, and the batch also
included a subsequent reference to the domain in a CREATE TABLE or ALTER
TABLE statement, the old (before drop & create) domain was used for the
column definitions. This has now been corrected.
================(Build #4033 - Engineering Case #752869)================
In very rare timing dependent cases, if the arbiter for a running High Availability
system was changed to a different arbiter server, and then changed back to
the original arbiter server later, the arbiter may have contained incorrect
state information. If this occurred, there was a small chance that the incorrect
partner could have become the primary. This has been fixed.
================(Build #4031 - Engineering Case #693422)================
The default value specified in a CREATE [ OR REPLACE ] VARIABLE statement
within a procedure, function, or trigger would have been ignored.
Example:
create or replace procedure foo ()
begin
create or replace variable @v int = 123;
end;
call foo();
select @v; -- should return 123 but would have returned NULL
This has been fixed. As a workaround set the default or initial value for
the variable in a separate statement after the variable has been created.
================(Build #4030 - Engineering Case #752641)================
If a server was started with one database on the command line with mirroring
enabled, and then other databases were started on the server, the server
could have stopped incorrectly if the mirrored database failed to start when
the database was restarted. Note that mirrored databases are automatically
restarted by the server if they lose quorum, as well as other cases. This
has been fixed so that if the mirrored database fails to start in this case,
only the mirrored database will be stopped, and the server will remain running
if there are other databases running.
Also, if a server to server mirror connection failed due to a liveness timeout,
no message was logged even if -z was enabled. In addition, other server
to server connections contained little diagnostic information even if -z
diagnostic logged was enabled. This has been fixed so that liveness timeout
messages for mirror server connection are logged with or without -z. In
addition, the messages "mirror server connection closed by other side"
and "connection terminated abnormally; error code <number>"
will be logged if -z is used and a mirror server connection is closed by
the remote server or fails due to a network error.
================(Build #4030 - Engineering Case #752201)================
If a procedure was defined with the special values SQLCODE or SQLSTATE as
parameters, and the procedure was used in the FROM clause of SELECT statement,
it was possible that the server could have crashed. This has been fixed.
================(Build #4028 - Engineering Case #752428)================
In rare timing dependent cases, if a connection between a copy node and its
parent was lost, it was possible for the new connection to have repetitively
connected and disconnected. Normally this condition would have resolved
itself within a minute or so, but in some cases it could have continued indefinitely.
This has been fixed.
If an ALTER MIRROR SERVER statement was used to add an alternate parent
to a running and connected copy node, the alternate parent would have been
used until the copy node restarted. This has been fixed so the alternate
parent can be used the next time the copy node loses its connection to its
parent.
================(Build #4027 - Engineering Case #752612)================
When fetching a Date, Time, or Timestamp from the database as a string in
a client, the fetch was much slower than if the data was bound to be fetched
as a timestamp type or structure. This performance has been improved.
Also, when fetching a Date, Time, or Timestamp, or other types that are
not native strings or numerics, from the database when the clients character
set is different from the database character set, the data would have been
returned in the database character set. This has been fixed so the data will
returned to the client in the client's character set.
================(Build #4027 - Engineering Case #752328)================
In very rare cases the server may have hung at shutdown. This would only
have happened while disconnecting TCP/IP connections. This has been fixed.
================(Build #4024 - Engineering Case #751937)================
In rare cases, a copy node could have started but never have written or applied
any changes that the primary or root had made until the copy node was restarted
or the connection to its parent was lost. All of the following conditions
must have been met for this problem to have been possible:
- the database was backed up from the primary or root using dbbackup or
the BACKUP statement
- while dbbackup was running, there must have been other connections to
the primary or root that had modified the database
- between the backup and when the copy node was started on the backed up
database, there was no commit done on the primary or root
If this problem was occurring, the sa_mirror_server_status row for the copy
node would show the copy node was connected with a recent last_updated value,
but the log_written and log_applied values would not change. If the copy
node was restarted, it would start applying and writing changes. This has
been fixed.
================(Build #4023 - Engineering Case #751948)================
In rare timing dependent cases, a Linux or Unix server using TLS mirroring
or diagnostic connections could hang. This has been fixed.
================(Build #4022 - Engineering Case #751847)================
If an HTTP connection was manually dropped (using DROP CONNECTION), and another
HTTP connection was accepted at the same time, it was possible for the server
to have crashed. This has been fixed.
================(Build #4020 - Engineering Case #751585)================
If a database server attempted to send more than 16k of data over an HTTPS
connection at one time, the client side of the connection could have hung.
With version 16.x, this could also have happened if a TLS connection used
a packet size bigger than 16000 bytes. This has been fixed.
================(Build #4017 - Engineering Case #751374)================
Under rare circumstances, a very long line segment defined in a Round Earth
SRS (for example, SRS 4326) could have crashed the server. This has been
fixed.
================(Build #4016 - Engineering Case #751285)================
Some complex statements took a long time to open a cursor. For some classes,
opening the cursor could not have been interrupted by cancelling the statement,
nor could the server have been stopped until the open completed. One such
instance has been corrected and the open will now respond properly to a cancel.
================(Build #4015 - Engineering Case #750502)================
Mirror server connections were ignoring the CommBufferSize (CBSIZE) connection
parameter. This has been fixed so that CBSIZE can now be used to specify
the maximum size of communication packets between mirror servers.
In addition, transferring many log pages between mirror servers may have
been slower than necessary. The default maximum packet size used for connections
between mirror servers has been increased, which can improve performance
in some cases. 16.0.0 mirror server connections now default to a maximum
packet size of 64240 bytes, and 12.0.1 mirror server connections now default
to a maximum packet size of 16000 bytes.
================(Build #4015 - Engineering Case #750363)================
If using FIPS, the SQL Anywhere FIPS DLL (dbfips16.dll) does not have to
be in the path but the actual FIPS module DLLs (libeay32.dll, ssleay32.dll
on Windows, libcrypto.so, libssl.so on Unix) do. On unix, they need to be
in the LD_LIBRARY_PATH. If they were not found, the error message that results
would have daid that the dbfips DLL could not be found. This has been fixed.
The correct filename for the missing file will now be given, and the error
message will indicate whether the file could not be found at all or if it
could not be found in the path.
================(Build #4014 - Engineering Case #750992)================
The server may have crashed when attempting to execute a certain class of
incorrect queries if the select list contained alias names and aggregate
functions. This has been fixed.
================(Build #4010 - Engineering Case #740548)================
Information returned by the system procedure sa_mirror_server_status() was
not updated for the hour after a daylight savings time change that changed
the local time to be an hour earlier. The sa_mirror_server_status row corresponding
to the server that was running the sa_mirror_server_status query was note
affected. This has been fixed.
================(Build #4007 - Engineering Case #654952)================
Under rare circumstances, the server could have hung when SUBSCRIBE BY values
were being changed for an article while large numbers of connections were
updating tables in the database. This has now been fixed. A workaround is
to avoid changing SUBSCRIBE BY values simultaneously with connections performing
INSERT, UPDATE or DELETE operations.
================(Build #4006 - Engineering Case #750298)================
In very rare, timing dependent cases, a copy node with children could have
hung when it was reconnecting to its parent. This has been fixed.
================(Build #4006 - Engineering Case #750288)================
If a network server was started with the LocalOnly TCP option set, and the
server was running on a portable device (eg. a laptop), changes to the IP
addresses on the machine would have been reflected in the server. For example,
if a new IP address was added, a new listener would have been started on
that IP address which could then accept connections from remote machines.
This has been fixed. The LocalOnly option now disables IP address monitoring.
================(Build #4005 - Engineering Case #749170)================
When invoked with a very large integer value, the hours() function could
have returned an incorrect result. For example, hours function invoked with
a ’12:00’ time and a very large integer argument would return a value like
’22:44’. This has been fixed.
================(Build #4004 - Engineering Case #749484)================
In rare cases, after a log rename on the primary, a mirror or copy node could
have stopped writing and applying changes. In order for this to have occurred,
all of the following conditions must have applied:
- the mirror or copy node must have been fairly recently started and requesting
log pages (in the case of the mirror, not yet synchronized)
- the mirror or copy node must have been writing pages from the primary's
current log file
- the primary log file was renamed
- something (such as a virus scanner) must have accessed the renamed log
on the primary (or parent), preventing the primary from opening the file
when the mirror or copy node requested pages from it
This has been fixed so that the primary or parent will attempt to open the
renamed log several times before failing. If the file open still fails after
multiple attempts, the primary will display the message "Database "<database-name>"
mirroring: failure when opening log file <file-name> for remote server
<server-name>" and the mirror or copy node will display the message
"Database "<database-name>" mirroring: database is
not compatible with primary; files must be replaced" and shut down the
database.
================(Build #4004 - Engineering Case #708252)================
The LOAD TABLE statement may insert invalid data values into columns of type
NUMERIC. For type NUMERIC the server may insert values that exceeded the
precision and scale
of the column type definition. This has been fixed. Now values for NUMERIC
columns will be cast to the column data type if needed.
================(Build #4002 - Engineering Case #749824)================
If a secure web procedure contained any of the certificate_unit, certificate_name,
or certificate_company options, and one or more did not match the certificate
used by the server, the connection could have hung or timed out. This has
been fixed.
================(Build #4000 - Engineering Case #749622)================
If an archive backup was corrupt in a specific way, it was possible for the
database server to crash when attempting to restore it. This has been fixed.
================(Build #3997 - Engineering Case #749387)================
Under certain rare circumstances the server could have become deadlocked.
For this to have occurred there must be a table continually undergoing many
insertions and deletions. This has been addressed.
================(Build #3996 - Engineering Case #746236)================
Under very rare circumstances, the server may have crashed during server
shutdown if a SQL Anywhere debugger was still connected. This has been fixed.
================(Build #3995 - Engineering Case #749169)================
In some rare cases, attempting to modify a database file after the server
using that file had been shut down using the Stop Server utility (dbstop)
would have failed with 'permission denied'. For this to have occurred, the
server must have been using the external environment (e.g. php). This is
a very timing sensitive bug and rarely reproduces. This has been fixed.
================(Build #3989 - Engineering Case #748096)================
If a stored procedure containing a single SELECT statement that uses a key
join was inlined, and the connected user was not the procedure owner and
has no select permissions on the table(s) in the query, a permission error
could have been returned. This has been fixed.
================(Build #3988 - Engineering Case #748351)================
Mirror and copy node servers were not applying transaction log changes as
efficiently as they could have been. This has been fixed to be more efficient.
================(Build #3987 - Engineering Case #748450)================
In some rare cases, the server may have crashed while processing HTTP/HTTPS
requests. This has been fixed.
================(Build #3984 - Engineering Case #748170)================
In rare timing dependent cases, a copy node that had just processed a Log
rRename could have failed assertion 200505, if its child was requesting log
pages. This has been fixed.
================(Build #3980 - Engineering Case #747810)================
When a mirror or copy node was shutdown while a connection was blocked on
a lock held by an internal connection which was applying log operations,
the shutdown could have hung. Note that mirror or copy node databases shutdown
and restart automatically for a number of internal reasons, for example,
the mirror database can shutdown and restart if the connection between the
partner servers becomes disconnect but the primary partner is still running.
This has been fixed.
================(Build #3978 - Engineering Case #747649)================
In rare timing dependent cases, a copy node could have failed with a log
mismatch message or an assertion failure when a log rename was performed.
In order for this problem to have occurred, in addition to processing the
log rename, the copy node needed to be transitioning from requesting to receiving
log pages from its parent, or a connection to its parent would have had to
be dropped and reconnected. This has been fixed.
================(Build #3977 - Engineering Case #696469)================
Executing an UNLOAD ... TO FILE or UNLOAD ... INTO CLIENT FILE statement
with the APPEND ON BYTE ORDER MARK option, would have written a byte order
mark even if the unload file already existed with a size greater than zero
bytes. This has now been fixed.
================(Build #3974 - Engineering Case #747141)================
In very rare timing dependent cases, a copy node's transaction log could
have been corrupted if the primary failed over to the mirror. In order for
this to have occurred, the old primary would have needed to still be running
and not in the process of stopping during the failover (for example, running
extremely slowly due to lack of machine resources). If this problem did
occur, the most likely failures would be assertion 100902, 100903 or 100904,
but other failures were also possible. This has been fixed.
================(Build #3973 - Engineering Case #747053)================
If the primary server failed and the mirror took over as the new primary,
the old primary could have failed to start and reported "database is
not compatible with primary; files must be replaced" in the console
log, even though it should have been able to start. In order for this failure
to have been reported when it should not have been, there had to be over
64 transaction log pages since the last checkpoint.
This has been fixed. Note that this failure (database is not compatible)
can still validly occur in certain cases.
================(Build #3973 - Engineering Case #746924)================
In very rare, timing dependent cases, mirroring servers (likely more than
one) could have hung indefinitely.
If, while processing ALTER DATABASE SET PARTNER FAILOVER, connections between
the primary and mirror servers timed out, or were dropped, before the failover
operation completed, the primary server could have stopped accepting connections.
The sa_mirror_server_status log_written offset could have been incorrect
about the time a log rename occurred.
================(Build #3971 - Engineering Case #746586)================
In rare cases, the server may have crashed or returned an incorrect SQL error
if the UPDATE clause of a bypass update statement had an invalid subselect
as table-expression. This has been fixed.
================(Build #3968 - Engineering Case #746290)================
On Windows systems, CPUs numbered 32 and above were not detected correctly
and treated as offline. This has been fixed
================(Build #3965 - Engineering Case #696753)================
Under rare circumstances, executing a CREATE TEMPORARY PROCEDURE statement
could have crashed the server. This has now been fixed.
================(Build #3959 - Engineering Case #745648)================
In rare timing dependent cases, near when a transaction log rename was being
performed, the sa_mirror_server_status log_written or log_applied columns
could have been inaccurate. This has been fixed.
================(Build #3958 - Engineering Case #745468)================
If a Directory Access server accessed a file with a size over 4GB, the file
length would have been reported as a size smaller than 4GB. This has been
fixed.
================(Build #3958 - Engineering Case #743578)================
In extremely rare, timing dependent cases, the server could have crashed
when a database was starting. This has been fixed.
================(Build #3953 - Engineering Case #740799)================
Performance of the server when run on Linux systems was much slower than
when run on Windows. The performance of the server has now been improved
so the speed on Linux should now be comparable to speeds on Windows.
================(Build #3953 - Engineering Case #643286)================
A mirror server could have crashed if multiple errors occurred on startup.
A mirror server uses -xp, and the crash could have occurred if the database
failed to start and the TCP/IP protocol failed to start. This has been fixed.
================(Build #3952 - Engineering Case #740708)================
In SYSUSER, SYSEXTERNLOGIN and SYSLDAPSERVER system views, columns containing
password hashes were visible to users without SELECT ANY TABLE privilege.
This has been fixed.
Note that in order to apply this fix, existing version 16.0 database will
need to be upgraded once the server containing the fix is deployed. New databases
created with the fixed version of the server do not need to be upgraded.
================(Build #3951 - Engineering Case #731483)================
Several issues with database mirroring and read-only scale-out have now been
fixed.
1) If the mirror or copy node was requesting pages from the primary or parent
(it had recently started and had not caught up to the current log operation)
and renamed log files required by the mirror or copy node had been deleted
on the primary or parent since the mirror or copy node started requesting
pages, then the mirror or copy node could have stopped applying log operations
or failed with the assertion 100904. This has been fixed so that that primary
or parent now correctly detects this case (a required renamed log file has
been deleted) and logs the message "Database <DBName> mirroring:
failure when requesting pages on remote server <ServerName>: missing
transaction log with start offset <Offset>" (where <DBName>,
<ServerName> and <Offset> are replaced with appropriate values).
If this occurs, the mirror or copy node will log the message " Database
"asatest" mirroring: database is not compatible with primary;
files must be replaced” and the database and possibly the server will stop.
2) The message "Database server shutdown due to incompatible files
for database mirroring” could have been displayed if an incompatible log
file was detected even though the server was not stopped. If there is more
than one database running on the server, the affected database is stopped,
but the server is not stopped. This has been fixed so that this message
is only logged if the server is actually being stopped.
3) In rare timing depending cases, after one or more ALTER DATABASE SET
PARTNER FAILOVER statements, neither partner could have taken the role of
primary. This has been fixed. As a workaround, the ALTER DATABASE ... FORCE
START statement can be used to force a partner to take over as partner if
this problem occurred.
4) If a copy node or async mirror got significantly behind writing log pages,
it could have caused requests to the primary database to block for more than
a minute. This has been fixed so that the primary will not be blocked for
more than about 10 seconds.
================(Build #3950 - Engineering Case #743662)================
On a heavily loaded server, client connections could have been incorrectly
dropped in timing dependent cases. If this occurred, the client would likely
get "Communication error" error and the server would report "
Disconnecting Client - 120 seconds since last contact" (or a different
number of seconds) in the console log.
This has been fixed so the dropped connections are less likely. Note that
these errors can still correctly occur if there is a network issue or if
either the client or server computers completely bog down (most likely due
to limited resources).
================(Build #3945 - Engineering Case #702506)================
The LOCATE function may have returned an incorrect result if the search string
contained multi-byte characters. This has now been fixed.
================(Build #3942 - Engineering Case #743871)================
If the query of a cursor used the OrderedGroupBy algorithm in its execution
plan, and was used to perform fetches that reversed direction of the scan,
incorrect results could have been returned. This could have been observed
for a cursor that fetched the first row, then second, then returned to the
first row of an aggregate query. This has been fixed.
================(Build #3940 - Engineering Case #743692)================
Servers with the fix for Engineering case 742355 could have returned garbage
characters for connection_property( 'Name' ), if there were non-ASCII characters
in the CON connection parameter. This has been fixed.
================(Build #3938 - Engineering Case #743341)================
In rare cases, if an application made an external environment call that in
turn performed a server-side request, then the server could have crashed
or lost an update if the server-side request resulted in a deadlock error.
This problem has now been fixed.
================(Build #3934 - Engineering Case #742872)================
The server could have become unresponsive or extremely slow if it was involved
in multiple high-availability configurations (for example, if it was running
a number of read-only copy nodes), and there were networking problems causing
loss of connectivity. This would have been more noticeable on single-processor
machines. This has been fixed.
================(Build #3933 - Engineering Case #732114)================
The first insert of a blob into a table after the database was started may
have taken longer under the following conditions:
- the blob to insert was longer than its column INLINE value
- the table contained a large number of blobs that were longer than about
8 database pages (blobs with blob index)
- the columns containing these blobs were created with a blob index (default)
- large parts of the table were not in cache
This has been fixed.
To work around the problem the blob indexes can be dropped by running the
following statement for all long varchar or binary columns with blobs longer
than 8 pages:
alter table <table-name> alter <columns-name> no
index
To fix the problem in existing databases rebuild the database or drop and
recreate the blob index by running ALTER TABLE. This must be done with a
fixed version of the server and only on table columns with above conditions.
================(Build #3933 - Engineering Case #689451)================
If the server was forcibly shut down while an encrypted database was in the
process of starting or stopping, the server could have crashed. This has
been fixed.
================(Build #3931 - Engineering Case #742365)================
A number of incorrect behaviors could have occurred when using database mirroring,
including:
- in rare, timing dependent cases, a mirror or copy node could have crashed,
hung or failed assertion 102010
- when a mirror or copy node reconnected to the primary or parent, it was
possible for it to not request, write or apply log pages.
- when a mirror was yielding to a preferred server, or the "ALTER DATABASE
SET PARTNER FAILOVER" statement was executed on the primary, it was
possible for the previous mirror to not take over as the primary (both partner
servers could have had the mirror role)
These problems have been fixed.
================(Build #3931 - Engineering Case #736004)================
Some window functions, including MIN and MAX, could have given incorrect
results if called over a column with data type TIMESTAMP WITH TIME ZONE.
This has been fixed.
================(Build #3931 - Engineering Case #735216)================
In rare situations, queries containing a Merge Join appearing below another
Merge Join may have failed assertion 106104: "Field unexpected during
compilation". This has been fixed.
================(Build #3928 - Engineering Case #665195)================
If a column or variable name was misspelled in a function that was inlined,
and the scope into which inlining was performed contained an object with
a matching name, incorrect results, or an incorrect error, could have been
returned. This has been fixed.
Example:
CREATE FUNCTION func1( @a integer)
RETURNS INTEGER
BEGIN
DECLARE @ret INTEGER;
SET @ret = ( a + 10 ) / 100;
RETURN @ret;
END;
SELECT a, func1( b + c ) as ret
FROM tab;
Expected error is ‘Column “a” not found’.
================(Build #3925 - Engineering Case #742013)================
Starting a database could have taken 10 seconds or more longer than it should
have taken if the -ar, -ad or -xp database options were used with servers
running on Windows. This could have occurred if files other than the database
and current transaction log files for the server that was attempting to start
the database were in the same directory as the database's log file, and these
files were locked by the current server or another process. For example,
if a single directory contained database files in use by a different server
process, or a console log file in use by the server starting the database,
a server starting the database with -ar, -ad or -xp would have started slowly.
This has now been fixed.
As a workaround, the database files could be put in a directory containing
only the database files for a single database.
================(Build #3925 - Engineering Case #742010)================
A mirror server or copy node could have crashed if snapshot isolation was
enabled and read-only connections were committed or rolled back. This has
been fixed.
================(Build #3924 - Engineering Case #742355)================
SQL Anywhere ADO.NET drivers without the fix for Engineering case 741707,
could have sent invalid connection pooling requests to the server which could
have resulted in a server crash. This has been fixed so that the server will
not crash even if the client makes invalid connection pooling requests.
SQL Anywhere ADO.NET drivers without the 714707 fix may have requests fail
with the error "Run time SQL error -- *** ERROR *** Assertion failed:
104909". The ADO.NET driver needs to be updated if this occurs.
================(Build #3924 - Engineering Case #741724)================
If a DSN contained a connection string with double quotes (eg. “server=MyServer;start=’dbeng16
-o \”file with spaces.txt\” ’ ”), the output from dbdsn -cm (intended to
be a dbdsn command that would re-create the DSN) would have incorrectly escaped
the double quotes. This has been fixed.
================(Build #3923 - Engineering Case #741870)================
If the database server was started with the –fips option, but the FIPS library
was not available, the server would have given an error and then hung. The
server process would have to have been killed. This has been fixed.
================(Build #3915 - Engineering Case #741078)================
A server could, in rare cases, have failed assertion 104301 ("Attempt
to free a user descriptor with non-zero reference count") on database
shutdown if there were active external environment calls at the time of shutdown
request. This problem has now been fixed.
================(Build #3915 - Engineering Case #740649)================
Under very rare conditions, the server may have entered an infinite loop
while performing massive amounts of concurrent inserts. This has now been
corrected.
================(Build #3914 - Engineering Case #740895)================
If a NULL byte was used in the string provided to the DELIMITED BY, ROW DELIMITED
BY, COMMENTS INTRODUCED BY, QUOTE, or ESCAPE CHARACTER clauses of a LOAD
TABLE statement or OPENSTRING expression, then the server would have used
all characters prior to the first null byte as the argument to the option.
For example, if the user specified DELIMITED BY '#\x00@' then the server
would use '#' as the column delimiter. This problem has been fixed.
================(Build #3913 - Engineering Case #740787)================
The connection property ApproximateCPUTime was reporting twice the amount
of CPU time consumed by a connection. This has been corrected.
================(Build #3913 - Engineering Case #740784)================
When OPENSTRING() is used in the FROM clause, the ROWID() function can be
used to get the row number of each row read from the string. In execution
plans where the same OPENSTRING() was executed more than one time, the ROWID()
values for second and subsequent executions would not have given the correct
line number: they would have continued to increase. In addition, error messages
for rows loaded from the string value could have reported incorrect line
numbers. This has been fixed.
================(Build #3912 - Engineering Case #740651)================
If the Unload utility (dbunload) was run on a database that had a user with
an expired password, or if a new user had been created that was forced to
change their password on first login, the resulting reload script would have
contained an ALTER USER statement that would have failed with a syntax error.
This problem has been fixed. The correct "ALTER USER <user-id>
FORCE PASSWORD CHANGE ON" syntax is now correctly generated in the reload
script.
================(Build #3908 - Engineering Case #740400)================
In rare cases, a copy node or mirror server could have used more memory than
expected. If this occurred, the extra memory would typically have been less
than 1MB. This has been fixed.
================(Build #3907 - Engineering Case #701648)================
Procedure profiling results would have shown an invalid execution time if
the total execution time of the request exceeded 4,294,967,295 microseconds.
This has been fixed.
================(Build #3906 - Engineering Case #740130)================
Under very rare circumstances, DML operations on a table with an immediate
text index that used an external prefilter or termbreaker library, could
have caused assertion failures or other issues with the database server.
This problem has now been fixed.
================(Build #3903 - Engineering Case #681579)================
For certain queries containing the built-in function ARGN(), the ARGN() expression
may either have returned an incorrect value due to incorrectly matching an
earlier case in the expression, or caused the server to crash. The probability
of either failure was very small, and depended on both the database page
size and the query text; however, the failure was deterministic for a given
database and query text. This has been fixed.
================(Build #3902 - Engineering Case #739349)================
If an application executed a SQL SECURITY INVOKER JAVA stored procedure with
an effective user id that required quoting or that was owned by a user id
that required quoting, then the server would have failed the Java procedure
execution with a syntax error. This problem has now been fixed.
Note, a user id that requires quoting would be one that was either a keyword,
or contained a dot (.) or some other unusual character. No other external
environment is affected by this problem.
================(Build #3902 - Engineering Case #739269)================
A procedural statement of the form "IF [NOT] EXISTS( simple-subselect
) ..." may have failed with a warning or an error. The warning "The
result returned is non-deterministic" was returned if the subselect
did not contain an ORDER BY clause. The error "Cursor has not been declared"
was returned if the THEN clause, but not the ELSE clause, contained a SELECT
statement that returned a result set, and the IF condition evaluated to 'false'.
This has been fixed.
================(Build #3902 - Engineering Case #739187)================
If an application executed the STOP JAVA or STOP EXTERNAL ENVIRONMENT statement
for a database scoped external environment (i.e java or clr), then the server
and external environment resources associated with the connection would be
correctly cleaned up, but the external environment executable would not have
been shut down. This problem has been corrected and the executable will now
shut down when the STOP JAVA or STOP EXTERNAL ENVIRONMENT CLR statement is
explicitly executed and there are no other connections using the database
scoped external environment.
================(Build #3902 - Engineering Case #733306)================
The server would have returned the error "Correlation name ... not found"
for a query when the following conditions were true:
- the query contained a proxy table and a nested query block with an outer
reference
- the nested query block used a view with a non-flattable select statement
- the outer reference in the nested query block could have been pushed into
the select statement of the view
For example, in the following query T1 is a proxy and would have returned
the error "Correlation name 'V0' not found".
create view V1 as select 2 as col1 union select 1;
select ( select col1 from V1 where col1 = V0.c21 ) as D from T2 V0,
T1;
This has been fixed.
================(Build #3899 - Engineering Case #739154)================
In rare timing dependent cases, the primary could have restarted unnecessarily
if the connection between the primary and mirror server was dropped about
the same time that the mirror became synchronized. When the primary restarted,
the database was stopped and restarted, causing all connections to have been
dropped. This has been fixed so that the primary does not restart in this
case.
================(Build #3899 - Engineering Case #738994)================
If the mirror tried to take over as primary and failed, in rare cases it
was possible for the database on the mirror to have become corrupted. The
most likely case of this occurring involved the connection between the two
partners being dropped for some reason, and then the mirror server or database
being shut down while the mirror was in the middle of attempting to take
over as primary. This has been fixed.
================(Build #3899 - Engineering Case #738756)================
If an operation on the database had executed trigger actions that included
UPDATE PUBLICATION commands, and that operation was also implicitly rolled
back because of an error in the trigger (such as a referential integrity
violation), then it was possible for SQL Remote (dbremote) to have sent operations
that would have been rolled back in the database. The Log Translation utility
(dbtran) may have also shown operations as committed in the translated transaction
log that were rolled back. This issue has now been fixed
================(Build #3898 - Engineering Case #738955)================
In rare timing dependent cases, when the primary server was shutdown, the
mirror could have failed to take over as primary. In versions 11 and 12,
both the primary and mirror could have both appeared to have hung for two
minutes while the primary was shutting down. This has been fixed.
================(Build #3898 - Engineering Case #738912)================
In extremely rare cases, a copy node could have been partially connected
to its parent indefinitely, and not write or apply log operations. In order
for this to have occurred, a connection to its parent would need have been
dropped shortly after it was established. The sa_mirror_server_status()
system procedure would have reported the copy node as connected. This has
been fixed.
As workaround, restarting the copynode in this state would cause it to get
and apply log operations from its parent.
================(Build #3897 - Engineering Case #738617)================
In exceptional rare circumstances, the server may have crashed while trying
to use the string value of a column DEFAULT or COMPUTE definition. This may
have occurred after resetting the column's DEFAULT or COMPUTE definition
using ALTER TABLE. Restarting
the database after executing the ALTER TABLE prevents the problem. This
has been fixed.
================(Build #3896 - Engineering Case #736687)================
Queries with predicates of the form '( T.X = <constant expression>
OR T.X = <constant expression> OR ...)' may have had unoptimal plans
if the <constant expression> was a variable, host variable, or aliased
constant. This has been fixed.
================(Build #3895 - Engineering Case #736255)================
A SQLE_COLUMN_NOT_STREAMABLE error would be erroneously reported when importing
in the Interactive SQL utlity. This has been fixed.
================(Build #3895 - Engineering Case #681578)================
In rare timing dependent cases, a copy node or async mirror could have failed
assertion 100927 ("Transaction log page number ... from parent or partner
is not expected page number ... "). This problem could have occurred
soon after the copy node started, or soon after the copy node reconnected
to a parent. This has been fixed.
================(Build #3893 - Engineering Case #738517)================
On Unix platforms, using any of the email functions, while running a version
12.0 database on a version 16.0 server, would have failed with an error:
“Dynamic library ‘libdbextf.so’ could not be loaded.” This has now been fixed.
There are two workarounds:
- ensure that libdbtasks12_r.so.1 is in the library load path (e.g. copy
it into the SA 16.0 installation next to libdbextf.so.1)
- upgrade the database to version 16.0
================(Build #3893 - Engineering Case #738276)================
For specific types of views and procedures using a WINDOW specification,
it was possible for the server to crash when processing a query referencing
the view or procedure. This has now been fixed.
================(Build #3892 - Engineering Case #738260)================
A read-only scale-out system, or an asynchronous mirror, could have done
more disk writes and more communication with children than necessary, which
could have resulted in somewhat slower performance. The unnecessary writes
and communication were most likely when many small transactions per second
were being committed on the primary or root server. This has been fixed so
that the unnecessary writes and communication have been eliminated.
================(Build #3892 - Engineering Case #737036)================
Executing a REORGANIZE TABLE statement could have worked sub-optimally and
may have left some pages with single rows on them. This has been fixed
================(Build #3891 - Engineering Case #738031)================
Using dbstop -c "...;NODETYPE=..." could have failed. Note that
it is not recommended that NODETYPE is used with dbstop since it may not
be clear which server will be stopped. This has been fixed.
================(Build #3889 - Engineering Case #693319)================
The sql functions set_bit() and get_bit() incorrectly accepted the value
0 for the bit-position parameter. This has been fixed. Now these functions
return an error.
================(Build #3885 - Engineering Case #737186)================
In rare, timing dependent cases, executing the "ALTER DATABASE SET PARTNER
FAILOVER" statement could have hung. If this occurred, the server itself
was not hung, but the server on which the statement was executed would not
accept connections to the database being failed over. This has been fixed.
As a workaround, the server that was running as the primary could be stopped,
or the database that was running as the primary could be stopped by connecting
to the utility database and executing the STOP DATABASE statement.
================(Build #3884 - Engineering Case #737159)================
If two separate connections had set the PRIORITY connection option, and the
database shut down unexpectedly so as to required automatic recovery, it
was possible for the database to fail the automatic recovery with assertion
100904:
Failed to redo a database operation (id=#, page_no=0x#, offset=0x###)
Error: Permission denied: you do not have permission to set the option 'PRIORITY'
This has been fixed. An upgraded database server will now be able to recover
the database successfully.
================(Build #3884 - Engineering Case #736806)================
Under rare circumstances, evaluation of very complex expressions could have
caused the server to crash. This has been fixed.
================(Build #3884 - Engineering Case #736680)================
It was possible for a mirror server to have hung for a few seconds or indefinitely,
have had connection timeouts, failed, or have had poor performance. It was
more likely to see these problems when running multiple mirrored databases
on a single server that had automatic multiprogramming level enabled (the
default) and there were nearly as many mirrored databases as cores.
This has been fixed by ensuring some long running background tasks do not
affect the number of tasks controlled by the multiprogramming level. A workaround
is to ensure that the minimum multiprogramming level is at least three times
the number of mirrored databases.
Two new server properties were added by this change:
1) property( 'CurrentMirrorBackgroundWorkers' ): The number of workers currently
being used for database mirroring background tasks. These workers are separate
from those controlled by the multiprogramming level.
2) property( 'MaxMirrorBackgroundWorkers' ): The highest number of workers
used for database mirroring background tasks since the server started. These
workers are separate from those controlled by the multiprogramming level.
================(Build #3882 - Engineering Case #736547)================
Under rare circumstances, evaluation of a query with complex expressions
could have caused a server crash. This has been fixed.
================(Build #3882 - Engineering Case #725690)================
Under rare circumstances, if recovery operations performed on a database
included changes affecting immediate text indexes, there was a potential
for triggering assertions failures or server crashes. There is also a potential
for generating incorrect score values or incorrect results for subsequent
queries using the text index. These problems have now been corrected.
================(Build #3881 - Engineering Case #736823)================
If a database was created with the -a or -af dbinit command line options
set, or with the "ACCENT RESPECT" or "ACCENT FRENCH"
clause on a CREATE DATABASE STATEMENT, and if the database CHAR charset was
not a UCA collation, then catalog lookups for tables, procedures, etc, could
have been slow because the server would not have taken advantage of the available
indexes on the catalog tables. This problem has been fixed.
As a side effect of the fix, dbunload now generates dbinit command lines
or CREATE DATABASE statements that use fully explicit collation specifications
such as "1252LATIN1(CaseSensitivity=Respect)" and it no longer
puts -a, -af, ACCENT RESPECT, and ACCENT FRENCH on dbinit command lines or
CREATE DATABASE statements. By using fully explicit collation specifications,
dbunload also no longer puts "-c" or "CASE RESPECT/IGNORE"
on dbinit command lines or CREATE DATABASE statements.
================(Build #3873 - Engineering Case #735358)================
In rare situations in a high availability setup with TLS connections, it
was possible for the primary server to hang while doing a commit. This is
the same fix that was done for Engineering case 674782, but now available
on Unix platforms.
================(Build #3873 - Engineering Case #735344)================
After performing a calibration using the ALTER DATABASE CALIBRATE statement,
it was possible for queries to execute slowly on the database due to an error
in the recorded calibration data. This problem was most likely to happen
with faster computers. This problem has been fixed. A workaround is to use
“ALTER DATABASE RESTORE DEFAULT CALIBRATION” to remove the incorrect calibration
data.
================(Build #3873 - Engineering Case #735267)================
When using Snapshot isolation, a statement-level or transaction-level snapshot
may remain active while other transactions completed. Previously, the time
to close the snapshot was proportional to O(N^2) for N transactions that
completed with the snapshot open. With one hundred thousand transactions,
this could have taken over a minute to close a single snapshot. With one
million transactions, this could have taken over 100 days to close a single
snapshot. During this time, other transactions were not allowed to start
or stop. The server would have appeared to be fully busy on a single core.
This performance has been improved; for one hundred thousand transactions,
the new algorithm completes in 13 milliseconds (compared to 80205 milliseconds
previously).
Further, it was possible for the server to crash with specific access plans
relating to viewing snapshot meta-data. This has also been fixed.
A best practice is to ensure that the number of transactions tracked by
the server is minimized; for example, by keeping the length of transaction
snapshots short (commit as soon as possible). For statement-level snapshots,
the snapshot is closed when the statement is closed. For cursors opened WITH
HOLD (for example, using ODBC), the snapshot will not be closed when a COMMIT
or ROLLBACK is performed; it is delayed until the statement is closed. Best
practice recommends closing these cursors promptly. The sa_snapshots() procedure
can be used to monitor active snapshots and sa_transactions() monitors transactions
being tracked due to snapshots.
================(Build #3873 - Engineering Case #735226)================
In rare situations in a high availability mirroring setup, it was possible
for the primary mirror server to hang while doing a commit if the connection
to the partner server was lost. This has been fixed.
================(Build #3873 - Engineering Case #674545)================
If a function that can be inlined was invoked with an argument that was an
expression with restrictions on where in the query it can appear (for example,
an aggregate function), a syntax error could have beeen returned. This has
been fixed.
================(Build #3871 - Engineering Case #734960)================
Updating a column, or a set of columns, that contained exactly the same value
and had an index defined, could have caused the server to crash. This has
been fixed.
================(Build #3871 - Engineering Case #731211)================
A query of the form “select * from T, R where T.X IN (R.X, T.Y )” may have
had a suboptimal execution plan if an index existed on the column T.X. This
has been fixed.
================(Build #3870 - Engineering Case #734589)================
In a mirroring configuration, it was possible for the primary mirror server
to restart sooner than expected when its partner was converted to a copy
node. This has been fixed.
================(Build #3870 - Engineering Case #732453)================
If an application made a Java External Environment call to a Java method
that made server side requests, then the Java External Environment may have
hung when the Java method created or prepared a large number of server-side
statements but did not explicitly close statements that were no longer needed.
This problem has now been fixed.
================(Build #3869 - Engineering Case #734486)================
If the computer on which a server is running was improperly configured, it
was possible for property(‘TcpipAddresses’), property(‘HttpAddresses’), or
property(‘HttpsAddresses’) to return a string with multiple consecutive or
trailing semicolon characters, eg. “1.2.3.4;1.2.3.5;;1.2.3.6;;;1.2.3.7”.
This has been fixed.
================(Build #3869 - Engineering Case #734158)================
Executing a batch or stored procedure that contained the ALTER DATABASE UPGRADE
statement would very likely have crashed the server. This problem has now
been fixed. Note that executing ALTER DATABASE UPGRADE within a batch or
stored procedure is not recommended when using SQL Anywhere 16 and up, since
the database will automatically be shut down once the upgrade completes.
================(Build #3869 - Engineering Case #711260)================
In a mirrored database configuration on Windows, when the SQL Anywhere service
encountered a fatal error, it may have failed to stop and the only way to
stop it was to kill the dbsrv1x.exe process. This has been fixed.
================(Build #3868 - Engineering Case #726959)================
In a high availability mirroring setup, if the connection between the mirroring
partners dropped, but the connections to the arbiter were stable, it was
possible for the primary to have restarted. This has been fixed.
================(Build #3867 - Engineering Case #734042)================
Query plans containing a HashGroupBy operator could have under-performed
in some cases. This was only possible when there were a large number of
groups (~10,000 or more) and where the data types of the aggregate functions
included strings, bit vectors, numerics, or other BLOBs. This has now been
fixed.
================(Build #3867 - Engineering Case #732745)================
If a SELECT statement with an INTO clause contained a variable in the select
list, then the temporary table was created with a not-nullable or nullable
column definition depending on the value of the variable. This has been fixed.
The column definition will now always be nullable in this context.
================(Build #3866 - Engineering Case #734049)================
If the trigger definition resulting from ALTER TRIGGER statement execution
conflicted with an existing trigger, the original trigger could have been
deleted, and a wrong error returned. This has been fixed.
This change also introduces a change in the algorithm used to decide the
order of firing triggers when an ORDER clause is not specified, or multiple
triggers with the same order and combination of events were created. For
example, this may change the order in which triggers created with “UPDATE
ORDER 2”, “UPDATE, DELETE ORDER 2” and “UPDATE OF <col> ORDER 2” are
fired. Note that documentation explicitly recommends specifying different
ORDER values for triggers with the same event. If your database contains
such sets of triggers, and the order of firing is important, please alter
the triggers to reorder them accordingly.
In general, both UPDATE ORDER 1 and UPDATE OF <col> ORDER 1 triggers
will fire before any UPDATE … ORDER 2 triggers are fired. A unique ordering
between UPDATE and UPDATE OF <col> triggers is still recommended.
================(Build #3864 - Engineering Case #733313)================
The mirror partner server in a mirroring setup may have failed to take over
immediately as primary, and instead restarted, when the primary mirrored
database became unavailable but the server was still running. This could
have happened when the primary mirror server was shutting down, or if the
“STOP DATABASE” statement has been used on the primary server. This has been
fixed.
================(Build #3864 - Engineering Case #733181)================
When executing a statement with a parallel execution strategy, it was possible
for the statement to fail to complete with an error such as the following:
All threads are blocked [-307] ['40W06']
This problem was more likely to occur with a UNION query where multiple
branches could use parallel execution. This problem has now been fixed.
================(Build #3858 - Engineering Case #732247)================
In rare timing dependent cases, if the primary server was stopped, the mirror
server could have failed to take over as the new primary server. This has
been fixed.
================(Build #3857 - Engineering Case #732156)================
Validating a database on a server with concurrent activity could have resulted
in failed assertions, or a server crash. This has now been fixed.
================(Build #3857 - Engineering Case #730149)================
On rare occasions the server would have crashed on shutdown when running
on Linux systems. The crash would have occurred when stopping shared memory
connections. This problem has now been fixed.
================(Build #3855 - Engineering Case #731731)================
When running on Solaris systems, if the server had accepted a new connection,
but the client side closed its socket right away, the TCP listener would
have been stopped and the message "TCP Listener shutting down (130)"
was be displayed on the server console. This has been fixed.
================(Build #3852 - Engineering Case #726536)================
When using the START EXTERNAL ENVIRONMENT statement to start a connection-scoped
external environment, and then disconnecting later on without actually making
any external environment calls to the connection-scoped external environment,
then there was a small chance the server would have crashed. This problem
has now been fixed.
================(Build #3851 - Engineering Case #730785)================
The Deployment wizard may not have worked corrctly on UNIX platforms. The
version number may not have been displayed correctly and/or the list of components
may have been empty. This has now been fixed.
================(Build #3851 - Engineering Case #730776)================
In very rare, timing dependent cases, it was possible for one or more copy
nodes to have failed an assertion after the primary was shutdown and the
mirror took over as the primary. The assertion would have indicated a problem
applying operations from the transaction log (for example assertion 100903).
This problem has now been corrected.
================(Build #3851 - Engineering Case #725391)================
If an Open Client or jConnect application attempted to perform a positioned
update on a table that had an NCHAR based column in the primary key, then
there was a chance the application would have hung. This problem has now
been fixed. Note that this problem did not affect non-TDS based clients.
================(Build #3851 - Engineering Case #693964)================
A user that did not have DBA authority was able to alter a SQL procedure
that they owned into an external or external environment stored procedure.
This problem has now been fixed.
================(Build #3849 - Engineering Case #730111)================
Attempting to creating a primary key on a table with an existing primary
key could have return an “Index name not unique” error, rather than an error
reporting the existence of a primary key. This has been fixed.
================(Build #3849 - Engineering Case #724507)================
In rare circumstances, a server that was running diagnostic tracing to a
remote server may have crashed if the diagnostic tracing server or database
stopped, or if the diagnostic tracing server or database stopped and tracing
was detached at the same time. This has been fixed.
================(Build #3847 - Engineering Case #729867)================
After calling the system procedure sa_server_option( ‘RequestTiming’, ...
), connections may have gathered or returned request timing values inconsistently.
In particular, request timing may have been enabled when the connection was
established but disabled immediately after changing the option, or request
timing may have been disabled when the connect was established but ignored
when the option was enabled. Also, if a pooled connection was reused, the
values tracked by request timing where not reset as they would be if a new
connection was established. This has been fixed so that request timing is
enabled or disabled at connect time (including when reusing a pooled connection).
Once the connection has been established, request timing will remain enabled
or disabled for the connection until it is disconnected, regardless of sa_server_option(
‘RequestTiming’, ... ) calls during the life of the connection. In addition,
if a pooled connection is reused when request timing is enabled, the values
tracked by request timing are reset.
Note that the database and server properties that correspond to those enabled
by the –zt server option are only updated for connections that have request
timing enabled or disabled at their individual connection time.
================(Build #3846 - Engineering Case #726235)================
Under rare, timing and execution plan dependent circumstances, execution
of a parallel query plan could have caused the server to hang. This has been
fixed.
A workaround is to disable intra-query parallelism for affected queries.
================(Build #3845 - Engineering Case #729394)================
In very rare cases, a database could have failed to start with the error
"Fatal error: undo log corrupted after log rename". In order for
this to have occurred, all of the following needed to be true:
1) a connection to the database had an outstanding transaction
2) while there was this outstanding transaction, the transaction log was
renamed or truncated
3) the database had no free pages and needed to grow during the checkpoint
that was part of renaming or truncating the transaction log
4) the connection from 1) still had an outstanding transaction during the
last checkpoint before the database stopped or was backed up
5) the database was not shut down cleanly, or it was backed up
6) attempting to start the database from 5) required recovery and could
have in rare cases failed with the error "Fatal error: undo log corrupted
after log rename".
Other failures may have been possible if all of the above conditions applied.
This has been fixed to avoid corrupting the undo log.
================(Build #3845 - Engineering Case #726396)================
If a SQL batch contained multiple DECLARE statements for local variables
with assignments of the default value or an initial value, then the assignments
were only executed for the last DECLARE variable-name statement of the batch.
This has been fixed.
================(Build #3845 - Engineering Case #724355)================
In very rare circumstances, the server may have crashed while performing
a query sort operation if the sort key was very long and the query was low
on cache space. This has been fixed.
================(Build #3843 - Engineering Case #729006)================
Creating a procedure with a right curly-bracket "}" in procedure_name(e.g
CREATE PROCEDURE “P1{}”()…) would have failed. This has been fixed.
================(Build #3843 - Engineering Case #727669)================
Under rare circumstances, a simple statement using variables or builtin functions
could have returned incorrect results. This could only happen if the simple
statement was processed by bypassing the query optimizer. This has been fixed.
================(Build #3842 - Engineering Case #728597)================
Crashes and data corruption were possible due to silent I/O failures on Red
Hat Linux 6, as well as other Linux distributions with kernel versions greater
than 2.6.38. The most likely manifestation of this bug was assertion 200505
("checksum failure on page x").
This problem is related to a possible bug in the transparent huge pages
(THP) feature introduced in these operating system versions. Red Hat bug
891857 has been created to track this issue.
The problem can be triggered by calling an external environment, xp_cmdshell,
or other procedure that causes a fork while other I/O is occurring. A known
limitation with the Linux kernel limits the use of fork while doing O_DIRECT
I/O operations. Essentially what can happen is that the data can come from
or go to the wrong process’ memory after the fork. SQL Anywhere performs
O_DIRECT I/O operations according to the documented safe usage. However,
THP appears to cause further problems and the O_DIRECT I/O data comprising
database page reads/writes appears to get lost.
This has been fixed by disabling THP on the SQL Anywhere cache memory where
possible. We are working with Red Hat to identify a solution within the
operating system.
There are two possible workarounds:
1. disable THP on a system-wide basis with one of the following methods:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
boot with transparent_hugepage=never
2. disable O_DIRECT I/O for database file reads/writes with one of the following
methods:
use the -u flag on the server command line
set SA_DISABLE_DIRECTIO=1 in the environment before starting the server
Transparent huge pages cannot be disabled just for the SQL Anywhere cache
memory on Red Hat Enterprise Linux 6. SQL Anywhere now disables direct I/O
if transparent huge pages are enabled and cannot be disabled on a per-allocation
basis. A warning will be printed as the database file is being opened to
indicate that direct I/O is disabled due to this bug. This is similar to
how SQL Anywhere handles file systems that do not support direct I/O.
Customers using RHEL 6 who wish to continue using direct I/O should use
the previously-stated command to disable THP at the system level.
================(Build #3840 - Engineering Case #728734)================
Crashes and data corruption are possible due to silent I/O failures on Red
Hat Linux 6, as well as other Linux distributions with kernel versions greater
than 2.6.38. The most likely manifestation of this bug is assertion 200505
(checksum failure on page X).
This problem is related to a possible bug in the transparent huge pages
(THP) feature introduced in these operating system versions. Red Hat bug
891857 has been created to track this issue.
The problem can be triggered by calling an external environment, xp_cmdshell,
or other procedure that causes a fork while other I/O is occurring. A known
limitation with the Linux kernel limits the use of fork while doing O_DIRECT
I/O operations. Essentially what can happen is that the data can come from
or go to the wrong process’ memory after the fork. SQL Anywhere performs
O_DIRECT I/O operations according to the documented safe usage. However,
THP appears to cause further problems and the O_DIRECT I/O data comprising
database page reads/writes appears to get lost.
Until this is fixed, there are two possible workarounds:
1. disable THP on a system-wide basis with one of the following methods:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
boot with transparent_hugepage=never
2. disable O_DIRECT I/O for database file reads/writes with one of the following
methods:
use the -u flag on the server command line
set SA_DISABLE_DIRECTIO=1 in the environment before starting the server
================(Build #3840 - Engineering Case #728458)================
The server may have behaved badly, including crashes or corruptions, when
using a recent version of Linux with glibc 2.11 or higher. This has been
fixed.
================(Build #3840 - Engineering Case #728449)================
When using communication compression on HP-UX, or on Linux with a recent
glibc version, a communication error could have occurred on the compressed
connection. This has been fixed
================(Build #3839 - Engineering Case #728223)================
If an HTTP request was incorrectly formatted in a particular way, the server
could have crashed. This has been fixed.
================(Build #3833 - Engineering Case #727601)================
If a statement contained an IN predicate on a column and one or more other
sargable predicates on the column, then the statement might not have executed
as efficiently as it could have. When optimizing predicates, the range of
values within the IN list was not considered when finding tautologies, contradictions,
or a narrower interval of validity. This has been fixed.
For example, the following predicates are now optimized as follows (where,
UDF is a user-defined function):
x=3 and x in (1,2,3) --> x=3
x>=3 and x in (1,2,3) --> x=3
x>3 and x in (1,2,3) --> FALSE
x=2 and x in (1,2,UDF(3)) --> x=2
x=3 and x in (1,2,UDF(3)) --> x=3 and x in (1,2,UDF(3))
================(Build #3833 - Engineering Case #727198)================
Specific forms of the LIKE predicate could have caused the server to crash.
As well, the wrong answer could have been returned for a LIKE predicate that
compared non-string values. These problems have now been fixed.
================(Build #3832 - Engineering Case #727315)================
Under rare circumstances, the server may have crashed if RememberLastStatement
was turned on and a statement being executed was too complex. This has been
fixed.
================(Build #3832 - Engineering Case #722646)================
When an application that was connected using Open Client or jConnect executed
a query that involved parameters, and the query generated a syntax error,
the server could have crashed. For the crash to occur at least one of these
parameters had to have been a string or binary parameter that was greater
than 250 bytes in length, and an additional tinyint, smallint, int or bigint
parameters followed the string or binary parameter. This problem has now
been fixed.
================(Build #3831 - Engineering Case #727087)================
If a stored procedure statement contained an OPENXML statement with a variable
used in an XPATH value, or a CONTAINS condition with a variable used in the
query parameter, then the statement could have failed incorrectly with an
error:
-134 "Feature 'OPENXML with non-constant query' not implemented"
-1159 "Non-constant or unknown text query string."
In order for the error to be returned, the variable must have been used
in a larger expression such as a cast or string concatenation. The failure
would have occurresd intermittently, for example on the 11th execution of
the statement. This has been fixed.
================(Build #3831 - Engineering Case #726951)================
In rare timing dependent cases, if the primary server was stopped, the mirror
server would have failed to take over as the new primary server. This has
been fixed.
================(Build #3831 - Engineering Case #723010)================
Under rare circumstances, the server may have returned the error SQLSTATE_INVALID_RECURSION
for a recursive select statement. This has been fixed.
================(Build #3830 - Engineering Case #726945)================
Attempting to start external environments would have failed if an Version
10.0 database, with a large number of objects, was upgraded. This problem
has now been fixed.
================(Build #3830 - Engineering Case #726720)================
In very rare timing dependent cases, it was possible for a mirror server
connection between two servers to have only been partially established.
If this was the case, the mirror or copy node with the partially established
connection would not have written or applied changes. In particular, a mirror
would have stayed in the 'synchronizing' state when it should have become
'synchronized'. This has been fixed.
A work around is to restart the server that is not writing or applying changes.
================(Build #3829 - Engineering Case #726715)================
The server could in some cases, have crashed while performing a BCP IN request
if an error was generated while servicing the BCP request. This problem has
now been fixed.
================(Build #3829 - Engineering Case #726546)================
The LastReqTime connection property could have had an incorrect time stamp
compared to current time. This would have only occurred if the server had
been running for more than 24 hours. This has been fixed.
================(Build #3828 - Engineering Case #726508)================
If a query used the user_name() or suser_name() builtin function, then the
described length of the column was LONG VARCHAR, even though the value would
be at most 128 bytes. This has been corrected so that the described type
is now VARCHAR(128). Any materialized views that use these builtins in the
select list should be rebuilt after this change.
================(Build #3828 - Engineering Case #726388)================
Some XML documents could have caused the server to allocate excessive memory
while processing OPENXML. This has been fixed. These types of documents now
return the error:
-890 "Statement size or complexity exceeds server limits"
In some cases, a statement processing an XML document could not have been
stopped by cancelling or dropping the connection. This has been fixed
================(Build #3828 - Engineering Case #723960)================
Under specific circumstances, the server could have crashed when applying
updates via SQL Remote. This has been fixed.
================(Build #3828 - Engineering Case #720804)================
If a backwards index scan blocked on a locked row, it would have continued
onto the next row after it resumed, rather than retrying the current row.
This has been fixed.
================(Build #3826 - Engineering Case #725718)================
When running the server on Linux systems with a recent glibc version, the
server could have crashed. This was more likely when a system with many
CPUs was being used. This has now been fixed.
The only reliable workaround is to use an older version of glibc.
================(Build #3824 - Engineering Case #725553)================
A client request which required a server to server request could have hang
if the server to server connection was dropped while the client request was
using it. For example, if a client request (such as a commit) resulted in
writing to the transaction log on a primary high availability server, and
the connection to the mirror (the server to server connection) dropped while
the client request was attempting to send log pages to the mirror, the client
request could have hung. Similarly, this could have occurred during a client
request if a connection to a diagnostic server dropped during the client
request. Note that only the single client request was hung and the server
was still operating normally otherwise. This has been fixed so that the client
request will not hang.
As a workaround, the client connection that is hung can be dropped using
DROP CONNECTION. This will cause the client connection to immediately report
an error.
================(Build #3824 - Engineering Case #725110)================
Under rare circumstances, the server may have crashed when the system procedure
sa_locks() was trying to collect row locking information for global temporary
tables. This has been fixed.
================(Build #3824 - Engineering Case #721950)================
Under rare circumstances, execution of a query using a MergeJoin operator
could have crashed the server. This has been fixed.
================(Build #3823 - Engineering Case #725451)================
The execution of SELECT INTO statements in stored procedures may have been
inefficient to compute. This has been fixed.
================(Build #3823 - Engineering Case #725392)================
When setting options using the system procedure sa_server_option(), the documentation
states that 'YES/NO' as well as 'ON/OFF' can be used for any settings that
accept Boolean values. There were two options that would accept 'ON/OFF',
but not 'YES/NO', ProcedureProfiling and DeadlockLogging. This has been fixed.
================(Build #3823 - Engineering Case #725302)================
When running on Windows systems, the database server could have hung for
up to three minutes when running as a system service when the system was
first booting up. This has been fixed.
================(Build #3823 - Engineering Case #723719)================
A permissions error could be given when calling a procedure or functions
that had been inlined. This has been fixed.
================(Build #3821 - Engineering Case #725583)================
Execution of "[not] exists(subquery)" expressions in stored procedures
may have been inefficient to compute. This has been fixed.
================(Build #3821 - Engineering Case #725197)================
Using the PHP external environment in an HTTP request, could have returned
an HTTP status code of 500 even when it was successful. This was most likely
to happen on Windows systems, and has now been fixed.
================(Build #3821 - Engineering Case #725179)================
Diagnostic tracing also collected information from Cleaner task connections.
This has been removed.
================(Build #3821 - Engineering Case #724847)================
In certain circumstances, running the Information utility to get table usage
and sizes ("dbinfo -u"), calling the system procedure sa_table_page_usage(),
or executing "VALIDATE DATABASE", could have caused assertion failure
109510 "Memory allocation size is too large". This problem has
been fixed.
================(Build #3821 - Engineering Case #724550)================
The CacheFree server statistic could have underflowed and presented extremely
large values. This has been fixed.
================(Build #3819 - Engineering Case #724543)================
In very rare cases, the server could have crashed while parsing a request-level
log file using the system procedure sa_get_request_times(). This problem
was introduced by the changes for Enginnering case 722122, and has now been
fixed.
================(Build #3819 - Engineering Case #724258)================
A web procedure created using the PROXY clause may have returned the error:
'-981: “Unable to connect to the remote host specified by “<URL>””
', depending on the type and configuration of the proxy server being used.
This would only have occurred for HTTP requests, HTTPS requests would have
worked. This has been fixed.
================(Build #3817 - Engineering Case #725820)================
If a high availability partner was stopped while it was attempting to determine
its role, the database may have been corrupted. If this corruption occurred,
attempting to start the database would likely fail with the 100904 assertion
"Failed to redo a database operation." This has now been fixed.
As a workaround, when stopping a mirror partner that is currently determining
the role with an affected build, it is recommended that the server is terminated
instead of stopped normally.
If this database corruption occurs, the database is corrupted but the transaction
log is not. The database can be fully recovered by applying the current
transaction log file(s) to a backup.
================(Build #3817 - Engineering Case #723835)================
Under certain circumstances, the NOT NULL clause for a foreign key specification
would have been ignored. When determining the nullability of an indexed column
the fact that a foreign key could be specified as NOT NULL was not being
taken into account. This has been fixed.
================(Build #3816 - Engineering Case #723710)================
On Mac OS X systems, use of the server option -um allows the server to run
with a GUI (through DBLauncher). It was not displayed though in the server's
usage message. This has now been corrected.
================(Build #3816 - Engineering Case #723706)================
In very rare cases, it was possible for the server to have crashed when an
HTTP connection is accepted. This has been fixed.
================(Build #3816 - Engineering Case #711401)================
Under rare circumstances, snapshot transactions could have caused the server
to fail assertions 200505, 200610, 201501, or 201503. This was more likely
to have occurred when other connections had rollbacks of large transactions
underway. This has been fixed.
================(Build #3815 - Engineering Case #721068)================
Under rare circumstances, a “Statement interrupted by user” error could have
been returned from parallel query executionm, instead of the correct runtime
error. Other possible behaviours under the same circumstances were returning
an “Unexpected error” error, or a server crash. This has been fixed.
================(Build #3813 - Engineering Case #722466)================
In rare circumstances, preforming bulk inserts and deletes of large amounts
of data may have caused the server to fail assertion 200130. This has been
fixed.
================(Build #3812 - Engineering Case #723096)================
If the SQL Anywhere server was registered with an ActiveDirectory LDAP server
and an LDAP error occurred at just the right time, the LDAP entry could have
been corrupted. When the server then shutdown, no new server with the same
server name would have been able to start. This has been fixed.
================(Build #3811 - Engineering Case #722972)================
Server may have run out of memory and crashed when executing the system procedure
sa_get_request_times(), especially when running with databases that had large
page sizes. This has been fixed.
================(Build #3811 - Engineering Case #722739)================
If a string of between half a page size and one page size in length was inserted
into a compressed column, the string could have caused a full page to be
allocated to hold the compressed data, which usually took up a very small
percentage of the page. No other strings would be able to use the same page.
This has been fixed.
Note that it is not possible to gain back the “wasted” space until the compressed
string is completely rewritten, and “ALTER TABLE t SET comp_col=comp_col”
will not do it either. The easiest way is to “ALTER TABLE t ALTER comp_col
NOT COMPRESSED”, followed by “ALTER TABLE t ALTER comp_col COMPRESSED”. This
only needs to be done once. Depending on how much data is in the column,
doing this may be slow and will likely increase the database file size. But
once it’s done, all the strings will be properly, and efficiently, compressed,
and any “wasted” pages will now exist in the database file as free pages
that can be re-used.
================(Build #3811 - Engineering Case #722440)================
In rare timing dependent cases, two partners attempting to determine roles
could have restarted their databases unnecessarily a number of times until
their role was finally determined.
Also, in rare timing dependent cases, a running copy node that was able
to reconnect to its parent server could unnecessarily have restarted its
database. In order for this to have occurred, the parent server would needed
to have been unavailable for long enough for the copy node to connect to
the root or alternate parent.
These issues have been fixed.
================(Build #3811 - Engineering Case #721977)================
Under very rare circumstances, the server may have crashed when encountering
a thread deadlock during a login packet receive. This has been fixed
================(Build #3811 - Engineering Case #719484)================
A query having a theta (subquery) predicate may have crashed the server during
query optimization. One of the conditions for this issue to have occurred
was that the subquery’s select items and groupby expressions were base table
columns of the same index, and the subquery was a grouped query block.
For example:
Select *
from T where T.X = (select R.X where …. Group by R.Y)
and there existed an index on R on columns <X,Y>.
This has now been fixed.
================(Build #3811 - Engineering Case #719334)================
The cardinality estimation for an index with descending (DESC) columns may
have been incorrect. This has been fixed.
The conditions for this issue to happen, for a query Q, were:
1 - The index on the table T was of the form <X1, …, Xk, …> with
k > 1
2 - The first k-1 columns in the prefix of the index had predicates of the
form T.Xi = constant in the query Q
3 - The column k had the predicate of the form T.Xk \theta constantk (\theta
n {<, <=, >, >=}), or T.Xk between constantk and constank+1
in the query Q
4 - The column T.Xk was declared DESC in the index.
================(Build #3810 - Engineering Case #722429)================
Calling the system procedure sa_iometrics() with invalid arguments may have
caused the server to crash. This has been fixed.
================(Build #3809 - Engineering Case #721778)================
When a connection was pooled and reused by SQL Anywhere's connection pooling,
in some cases there were some behavior differences compared to getting a
new (unpooled) connection. Note that the type of connection pooling affected
is controlled by the ConnectionPool connection parameter and enabled by default,
but this connection pooling is not used by the ADO.Net driver. The specific
behaviors that differed between reusing a pooled connection and getting a
new unpooled connection were:
1) a "SET rowcount <value>" statement done on a connection
that was then cached and reused could have incorrectly continued using this
setting.
2) a "SET TEMPORARY OPTION secure_feature_key = <value>"
statement done on a connection that was then cached and reused could have
incorrectly persisted using this option.
3) the @@identity value could have incorrectly returned an identify value
from before the connection was cached and reused.
These problems have been fixed so that the cached and reused connections
will have the same behavior as completely new connections.
================(Build #3809 - Engineering Case #721394)================
The server may have failed assertions 111706, 111707, or 201200, if a procedure
call was used in a SELECT statement, one of the specified arguments exceeded
its declared parameter size, and the procedure used the argument in a DML
statement. This has been fixed.
================(Build #3805 - Engineering Case #716538)================
An addition fix was required for Engineering case 714656, where the server
could have crashed when auto-starting a database.
================(Build #3804 - Engineering Case #721318)================
The changes for Engineering case 674232 broke JAX-WS support for multiple
databases on a server. The generated WSDL document omitted the database name
in the targetNamespace. For example, targetNamespace="http://localhost:8082/WS"
instead of targetNamespace="http://localhost:8082/demo/WS".
As a result, all the URL references to web services could have gone to the
wrong database. It would have gone to the database that was started first.
This problem can not be worked around using the DBN option, as follows:
dbsrv12 -xs http(port=8082;dbn=test) "%SQLANYSAMP12%\demo.db"
test.db
as the targetNamespace is correct but the wsdlLocation is wrong. The correct
workaround is to edit the source files generated by wsimport and make the
corrections. This problem has been fixed.
================(Build #3804 - Engineering Case #721288)================
In rare cases, if a copy node was renaming the transaction log while a child
copy node was requesting log pages, the parent copy node could have failed
with "Fatal Error: Internal database error". Note that a child
copy node only requests pages until the child has all the log pages that
the parent has (after that the parent sends the updated log pages as they
are written).
Also, in very rare cases, if a copy node or mirror was renaming the transaction
log while the connection to the parent or partner dropped, the could node
or mirror could have crashed.
These issues have now been fixed.
================(Build #3803 - Engineering Case #721070)================
The REGEXP search condition and the REGEXP_SUBSTR function could have incorrectly
matched or failed to match regular expressions with ^ or $ followed immediately
by a character that had special meaning in a regular expression if it was
escaped. For example, REGEXP_SUBSTR( 'A', '^A' ) was incorrectly returning
NULL. This has been fixed.
================(Build #3803 - Engineering Case #721039)================
Dropping a connection that had previously made an external environment call
to a connection scoped external environment, could, in very rare cases, have
caused the server to crash. This problem has now been fixed.
================(Build #3803 - Engineering Case #716317)================
Under some circumstances, especially if a cached plan was used, a select
from a DML statement (INSERT, DELETE, UPDATE, or MERGE) may have returned
an incorrect result set. This has been fixed.
================(Build #3802 - Engineering Case #720462)================
Under very rare circumstances, the server may have crashed when running the
system procedures sa_char_terms or sa_nchar_terms, or some internal text
index related procedures, with invalid arguments. This has been fixed.
================(Build #3801 - Engineering Case #720811)================
A high availability mirror or a copy node server running on Windows could
have failed assertion 112002 during a transaction log rename. This has been
fixed.
If the high availability mirror was busy applying log pages, failing over
due to the other partner being preferred, or due to the ALTER DATABASE SET
PARTNER FAILOVER statement, could have been delayed for a minute or more.
This has also been fixed.
================(Build #3801 - Engineering Case #720489)================
In very rare timing dependent cases, when a high availability mirror was
taking over as primary, it could have hung or failed assertions 100924 or
100925. In order for this to have occurred, the mirror must have had active
read-only connections using temporary tables and performing commits or rollbacks,
as well as certain other conditions. This has been fixed.
================(Build #3800 - Engineering Case #720607)================
When the SQL Preprocessor was run with the "-e u" command line
option (Flag syntax that is not supported by UltraLite) it would have incorrectly
reported the TIMESTAMP WITH TIME ZONE syntax as a language extension. This
has been fixed so that it is no longer reported as a language extension.
================(Build #3799 - Engineering Case #720384)================
Under very rare circumstances, the server may have crashed when running the
procedure sp_forward_to_remote_server, or any of the Remote Data Access procedures
(i.e sp_remote_columns, sp_remote_tables, etc). This has been fixed.
================(Build #3799 - Engineering Case #720298)================
Under rare circumstances, calling the system procedure sa_index_statistics()
could have caused the server to crash. This has been fixed.
================(Build #3798 - Engineering Case #720219)================
Executing a SET MIRROR OPTION option-name = NULL statement would not have
correctly changed the behavior of currently running databases for the auto_failover
and synchronization_mode options. Once the database was restarted on a partner
server, the option value would then have been correctly interpreted as the
default value for the option. This has been fixed so that the default value
for the option is effective immediately after the SET MIRROR OPTION option-name
= NULL statement is executed or applied.
================(Build #3798 - Engineering Case #720066)================
If a connection could not be made to the root or primary server from a copy
node that did not already have a mirror definition, the copy node could have
crashed after about max_retry_connect_time from when the copy node was started.
This has been fixed.
================(Build #3798 - Engineering Case #719710)================
Executing an ALTER TABLE statement on an empty table could have caused a
server crash on a subsequent table scan of the table. This has been fixed.
================(Build #3798 - Engineering Case #712459)================
In very rare timing dependent cases, a copy node that was both a parent and
a child could have crashed, or failed with an assertion, while the transaction
log was being renamed. This has been fixed.
================(Build #3797 - Engineering Case #719397)================
Under rare conditions, the server or client library could have crashed when
attempting an LDAP operation (eg. registering the server, searching LDAP
for servers when connecting). This has been fixed.
================(Build #3796 - Engineering Case #719932)================
In a mirroring setup during a forced failover, it was possible for the new
mirror to get stuck in a situation where the database would print the following
error to the console log: “primary not available or mirror log longer than
primary”, and proceed to restart. This could often be fixed by executing
a transaction on the new primary after the failover was complete. This bug
has been fixed, and the mirror server should now start up without difficulty.
================(Build #3794 - Engineering Case #719220)================
In rare timing dependent cases, the changes for Engineering case 713113 mau
have caused a mirror or copy node to fail assertion 100927 when starting
the database. The assertion text was "Transaction log page number 0x<first-hex-number>
from parent or partner is not expected page number 0x<second-hex-number>",
where the first-hex-number was one lower then second-hex-number. If this
assertion failure occurred, restarting the mirror or copy node should succeed.
This has been fixed.
================(Build #3793 - Engineering Case #719503)================
The server would have failed assertion 107400 - Internal parse tree error,
if a query used proxy tables and contained a common table expression in a
derived table, and the derived table was flatted. This has been fixed
================(Build #3791 - Engineering Case #719111)================
User-defined counters are implemented as UNSIGNED INTEGER, but their values
could not be set or adjusted using values that were greater than 2147483647.
This has been corrected so that values can now range up to 4294967295.
================(Build #3791 - Engineering Case #719105)================
In some circumstances, the primary server in a mirroring setup may not have
allowed the mirror to take over as primary when an ALTER DATABASE SET PARTNER
FAILOVER occurred. The server would have waited until all active transactions
were committed. This has been fixed. Now, the failover will occur as soon
as the servers are synchronized, and the mirror has all the committed transactions
from the primary. Any transactions that have not been committed will be lost
when the failover occurs.
================(Build #3791 - Engineering Case #718875)================
In a mirroring setup, if a copynode or the mirror was still connected to
its parent or partner, and was busy receiving a lot of pages from its parent,
and needed to restart for some reason, the server could have waited until
it wasn’t as busy before restarting. A mirrored database may need to restart
in many situations. For example, a restart is required when a copynode’s
parent has changed, or when a mirror is converted to a copy node. This has
been fixed, so the server will restart much sooner after deciding it needs
to restart, and will not wait until there is a break in receiving information
from its parent or partner.
================(Build #3791 - Engineering Case #717944)================
In rare cases, calling the system procedure sa_transactions(), may have lead
to a server crash. This has been fixed.
================(Build #3788 - Engineering Case #718525)================
In very rare situations, the server could crash when using the OPENSTRING
clause, string concatenation, substring operation, or attempting to execute
a LOAD TABLE statement. The problem was most likely to have occurred when
cache pressure was very high. This problem has been fixed.
================(Build #3788 - Engineering Case #718497)================
Creating a REMOTE SERVER definition with a USING clause that contained both
"DRIVER=SQL Anywhere Native" and "DSN=..." would have
resulted in the connection string used to connect to the remote SA server
not containing the items in the DSN entry. This problem has now been fixed.
================(Build #3788 - Engineering Case #674549)================
The server may have failed assertions 111706, 111707, 106808, or 201200,
if the recursive subquery of a recursive common table expression returned
a larger select-list item value than its corresponding select-list item in
the initial subquery. The problem only happened if the recursive subquery
performed a join operation to rows added during previous iterations. This
has been fixed so that the server now returns the error
"Recursive column %1: conversion from '%2' to '%3' loses precision
".
================(Build #3787 - Engineering Case #718375)================
In rare cases, a copy node whose parent was not the primary or root could
have failed assertion 100927 immediately after a log rename.
In very rare cases, a mirror or copy node that was automatically restarted
immediately after a log rename could have incorrectly restarted as a non-mirrored
read-write
database. The automatic restart could have occurred for a number of reasons,
including rare cases of a lost connection to the parent server.
Both of these problems have now been fixed.
================(Build #3787 - Engineering Case #718369)================
Attempting to insert a string literal containing multi-byte characters into
an nchar based proxy column may have actually inserted mangled data into
the remote column, if the local database character set was not UTF8. This
problem has now been fixed.
Note that inserting multi-byte character data using an nchar based variable
or column as the source works fine. As a result, using an nchar based variable
instead of a string literal is a possible work around for this problem.
================(Build #3787 - Engineering Case #717966)================
The time to process an HTTP or HTTPS request that contained a large number
of input variables may have been longer than expected. This has been fixed.
================(Build #3787 - Engineering Case #717024)================
Attempting the execute a CREATE EXISTING TABLE that referenced a remote server
using IBM's NotesSQL ODBC driver version 8.5.1 would have resulted in mangled
column names. The statement would likely have failed with a Syntax error
(SQLCODE=-131, ODBC 3 State=42000). This problem has now been fixed.
================(Build #3785 - Engineering Case #718122)================
If a connection updated a table and subsequently left a cursor open past
a COMMIT or ROLLBACK, other connections would not have been able to lock
the entire table in share mode (i.e. LOCK TABLE t IN SHARE MODE) until the
updating connection closed the cursors and did a COMMIT or ROLLBACK. This
has been fixed.
================(Build #3784 - Engineering Case #717316)================
In some circumstances, the server could have crashed, failed assertions,
or rarely, could have returned incorrect data, when working with tables that
contained more than eight thousand columns. This has been fixed.
Note, a database with more than eight thousand columns that is run with
a server that contains this fix cannot be run on an older server. Doing
so will result in startup error -1007 "Unable to start specified database:
'%1' is an invalid transaction log" on the older, unfixed server.
================(Build #3783 - Engineering Case #717784)================
On Windows 8 and Windows 2012 systems, the platform-related properties would
have indicated an "unrecognized Windows version". Support for these
two platforms has now been added.
================(Build #3782 - Engineering Case #717694)================
Execution times of prefetches increased when compared with previous releases.
This has been fixed.
================(Build #3782 - Engineering Case #717689)================
If an 11.x or 12.x database was upgraded using either the Upgrade utility,
or ALTER DATABASE UPGRADE, then external environments would no longer have
started. This problem has now been fixed.
Note that in order to apply this fix, the database will need to be upgraded
again once this fix has been properly deployed.
================(Build #3781 - Engineering Case #717313)================
Archive backups would have suspended checkpoints until the next COMMIT or
ROLLBACK. This would have prevent checkpoints, and commands that implicitly
issued checkpoints, from running until that point. This has been fixed.
================(Build #3781 - Engineering Case #715843)================
In rare cases, attempting to use nested procedures with nested transactions
and internally generated temporary tables would have failed assertion 201501,
101412, 200505 or others. This problem has now been fixed.
================(Build #3780 - Engineering Case #716544)================
Explicitly passing in NULL as the 3rd parameter (algorithm) to the encrypt
or decrypt function would have resulted in the error: "The string is
too long (Parameter 3)" SQLCODE -973, rather than having the encryption/decryption
default to AES128. This has been fixed. Not specifying the third parameter
at all would have worked properly.
================(Build #3780 - Engineering Case #716537)================
In a multi-level read-only scale-out configuration, executing the "ALTER
MIRROR SERVER ... ALTER PARENT FROM ..." statement could have resulted
in read-only scale-out servers not being able to connect to their parent,
even if their parent was running. This has been fixed.
Note, a work around is to stop and restart copy node servers that cannot
connect to their running parent.
================(Build #3777 - Engineering Case #715799)================
Two foreign key or unique constraints on the same table could have been created
with names that represent the same identifier, but differ only in case. For
example 'myFK' and 'myfk'.
This has been fixed.
================(Build #3776 - Engineering Case #716036)================
The changes for Engineering case 702214 may have made an external environment
call take significantly longer when connected to a case sensitive database.
This problem has now been fixed.
================(Build #3775 - Engineering Case #716625)================
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.
================(Build #3772 - Engineering Case #715615)================
Under rare circumstances, database recovery could have held locks on a new
text index. This has been fixed.
Also, text index validation could have returned an error later than necessary.
This has been fixed in version 12.0.1 and later.
================(Build #3772 - Engineering Case #715583)================
It was possible to create duplicate indexes for a table in a case-sensitive
database if the only difference between the index names was case or accent.
For example, both foo and Foo could have been created with same or different
definitions. This has now been fixed.
================(Build #3771 - Engineering Case #715909)================
The output from the system procedure sa_locks() could have been incorrect,
in that it may have missed reporting some row locks. This has now been corrected.
This was a reporting problem only, and did not affect actual locking behaviour.
================(Build #3771 - Engineering Case #715687)================
When the server collects information about database pages to be used for
cache warming in the next database start, it also incorrectly collected information
about pages that the database cleaner task reads. This has been fixed so
that page recording no longer includes pages read by the cleaner since these
pages are different each time.
================(Build #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 #3727 - 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 #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 #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 #4401 - Engineering Case #797158)================
The "Compare Database" window in Sybase Central contains drop-down
lists for selecting the databases at the top of the window. Clicking the
arrow in the component to open the list would have worked intermittently,
preventing the choosing of one of the recently-used databases. Now, the
list drops down reliably.
================(Build #4372 - Engineering Case #794675)================
If a users only connection to a server was a connection to the utility database,
then attempting to open the server property sheet would have failed with
a permission denied error. Now the property sheet opens but only the General
page is shown.
================(Build #4372 - Engineering Case #794671)================
If attempting to connect to a database via a Connection Profile failed, then
SQL Central could have crashed. This has been fixed.
================(Build #4292 - Engineering Case #786565)================
It was not possible to set the server’s quitting time on the property sheet’s
Options page if the timestamp_format option was set to a non-default value
(the default is YYYY-MM-DD HH:NN:SS.SSS). This has been fixed. The property
sheet now uses a free-form text field rather than a masked text field. Also,
the current time is now shown in the same format as is required for setting
the quitting time.
================(Build #4275 - Engineering Case #784579)================
If a breakpoint was deleted from the Breakpoints window when the breakpoint's
stored procedure was not selected, the breakpoint was still shown when the
procedure was subsequently selected. This has been fixed.
================(Build #4275 - Engineering Case #784559)================
In the Create Database wizard, when starting a new local server to create
the database, the server name would have defaulted to the database file name.
This could result in an invalid server name or a server name that wasn’t
recommended. For example, if the database file name contained characters
other than 7-bit ASCII. This has been fixed. Now if the database file name
isn’t a valid or recommended server name, then the wizard generates a random
server name.
================(Build #4270 - Engineering Case #783998)================
The Database Overview tab listed port numbers incorrectly for IPV6 addresses.
This has been fixed.
================(Build #4269 - Engineering Case #783875)================
In the ‘Fragmentation’ tab of a database, selecting the ‘Tables’ folder in
the tree, clicking the Back button in the toolbar to go back to the ‘Fragmentation’
tab, and then the clicking ‘Checkpoint & Refresh", would have selected
the ‘Folders’ tab instead of staying on the ‘Fragmentation’ tab. This has
been fixed.
================(Build #4263 - Engineering Case #783248)================
In the Table Editor, attempting to include a column with an approximate numeric
data type (a float or double) as part of the table's primary key would show
a dialog discouraging this practice; however, regardless of whether OK or
Cancel was clicked in the dialog, the change would have been reverted and
the primary key check box would remain unchecked. This has been fixed. Now
the check box is checked if you click OK in the dialog.
However, including a column with an approximate numeric data type as part
of a table's primary key is still discouraged. This is because SQL Anywhere
cannot enforce a referential integrity constraint for values that cannot
be represented exactly by an approximate numeric data type.
================(Build #4260 - Engineering Case #783071)================
In Sybase Central, trying to save a zero-length VARBINARY value from a table's
"Data" tab, would have caused Sybase Central to crash. This has
been fixed.
Note, the same problem could also have manifest itself in the Interactive
SQL utility.
================(Build #4258 - Engineering Case #782826)================
Editing a SQL Anywhere connection profile that contained only a userid and
password could have inadvertently set the "action" to "Connect
with an ODBC data source" rather than "Connect to a running database
on this computer". This has been fixed.
================(Build #4247 - Engineering Case #782250)================
Rows can be deleted from a table in Sybase Central even if the table does
not include a primary key. If deleting a row actually causes more than one
row to be deleted, Sybase Central displays a message which prompts the user
to refresh the display to get an accurate display of the rows. If the display
was not refreshed, but instead the last row in the table was selected and
the Delete key was pressed, Sybase Central would have crashed while attempting
to delete the row. This has been fixed; pressing the Delete key in this
case now does nothing.
================(Build #4247 - Engineering Case #781759)================
The "Compare Database Schemas" window has an "Open in Interactive
SQL" button which is supposed to open Interactive SQL and put the SQL
script into its "SQL Statements" pane. On Mac OS X computers,
Interactive SQL would also have immediately executed the statements. Now,
it does not execute the statements unless the user tells Interactive SQL
to run the statements.
================(Build #4238 - Engineering Case #780457)================
When comparing databases on Mac OS X systems, an unknown error would have
occurred if either of the databases contained a Java class, JAR file, or
external environment object. This has been fixed.
================(Build #4228 - Engineering Case #779251)================
After running the Validate Database wizard, Sybase Central’s connection would
have held a schema lock on each of the tables and materialized views in the
database. This has been fixed.
================(Build #4223 - Engineering Case #778458)================
Creating a remote server from within the Migrate Database wizard could have
crashed if the database server had previously been selected in the tree and
selected View -> Refresh. This has been fixed.
================(Build #4222 - Engineering Case #778293)================
Selecting a database’s Overview tab would have caused an error if the database
used the 1254TRK collation. This has been fixed.
================(Build #4220 - Engineering Case #777960)================
Sybase Central could have crashed if table data was edited and the table
did not have a primary key, and if the row being modified had the same values
as some other row in the table. This has been fixed.
================(Build #4166 - Engineering Case #771379)================
The web server port was not displayed in the Overview tab. This has been
fixed
================(Build #4166 - Engineering Case #771364)================
When searching in SQL Central if the server was shut down, or the connection
to the database was dropped from another application, then SQL Central would
have shown multiple error dialogs, each of which needed to be closed before
SQL Central could be used again. This has been fixed.
================(Build #4163 - Engineering Case #770952)================
The following issues related to the Database Documentation wizard have been
fixed:
On Windows systems: Sybase Central could have become unresponsive for about
a minute when viewing the generated documentation, and the directory was
specified from the root of the drive but did not include the drive letter.
On non-Windows systems: Generating the documentation to a directory with
a space in its name, and then attempting to open the documentation would
have failed.
================(Build #4163 - Engineering Case #770843)================
when comparing databases, SQL Central would have appeared to hang if the
database contained a large procedure definition. This has been fixed.
================(Build #4148 - Engineering Case #768875)================
Attempting to create a maintenance plan could have failed if the Allow_nulls_by_default
database option was set to ‘Off’ the first time the Maintenance Plans folder
was selected for that database in Sybase Central. This has been fixed.
================(Build #4105 - Engineering Case #762532)================
The Overview page did not show the arbiter and mirror server names. This
has been corrected.
================(Build #4103 - Engineering Case #762605)================
The "Find/Replace" window for the syntax highlighting editor could
have hung when searching up for a whole word if the search text appeared
in the editor, but not as a separate word, and if the caret position was
initially after the search text. This has been fixed.
This prolem also affects the Interactive SQL utility. It has been present
since version 9.0.2, possibly earlier.
================(Build #4100 - Engineering Case #762046)================
The SQL Anywhere Plug-in tooltip for the Connect window had its text truncated.
This has been fixed.
================(Build #4100 - Engineering Case #762038)================
When reviewing recommendations from a tracing session, and the database had
been shut down, a java.lang.IndexOutOfBoundsException could have occurred.
This has been fixed.
================(Build #4083 - Engineering Case #759373)================
In the Views folder, clicking the “Last Refresh Time” or “Known Stale Time”
column headings to sort the views by one of these columns would have produced
incorrect results. This has been fixed.
================(Build #4081 - Engineering Case #758812)================
The property sheet for a table column would not have allowed changing the
column’s “Compress values” or “Maintain BLOB indexes for large values” settings
if the column’s type was a domain, even if the domain’s base type supported
these settings. This has been fixed.
================(Build #4071 - Engineering Case #757937)================
Attempting to save the SQL for an event that contained whitespace before
the BEGIN keyword would have resulted in a syntax error. This has been fixed.
================(Build #4066 - Engineering Case #756707)================
Sybase Central could have crashed if it was running and something was done
to change the Windows desktop theme. This same problem could have been encountered
when using a Remote Desktop Connection with a low-bandwidth connection; in
that configuration, Remote Desktop may automatically change the desktop theme
to satisfy the bandwidth limitations.
This issue was partially fixed by the changes for Engineering case 752610,
but this change goes beyond it by fixing the following problems as well:
- On the Search panel, the "Search" button enabling logic and
the button's clicking logic would stop working after the look-and-feel changed.
- Sybase Central could have crashed if any of the following panels/windows
were open when the look and feel were closed:
1. "Results" on the "Search" pane
2. The list of plug-in in the "Sybase Central Plug-ins" window.
3. The connection profiles window
4. The About window
5. The Disconnect window
- The background color of items in details panels would have been painted
gray (rather than white) after switching look-and-feel.
- Drop-down toolbar buttons (e.g. "Tools") did not draw their
arrow, and did not open when clicked.
================(Build #4019 - Engineering Case #751566)================
The antialiasing algorithm used for SQL editors (including the SQL Anywhere
auditing viewer, and the MobiLink server log file viewer) did not render
certain fonts optimally. Chinese fonts on RedFlag Linux and small fonts
generally were poorly drawn (or were not drawn at all). This has been fixed.
================(Build #3950 - Engineering Case #743367)================
Sybase Central would have reported an internal error on startup if it was
configured to run with recent updates of the Java Virtual Machine (JVM),
for example, 1.6.0 update 45, and if the Fast Launcher was turned on. This
has been fixed.
================(Build #3946 - Engineering Case #744044)================
When testing a connection to a MySQL remote server, Sybase Central could
sometimes have reported that the connection failed, when in fact it had succeeded.
This has been fixed.
================(Build #3942 - Engineering Case #744039)================
It was not possible to connect to a tracing database when profiling using
a client-only install. This has been fixed. Now, only opening an analysis
file is prevented in a client-only install.
================(Build #3939 - Engineering Case #743587)================
When duplicating a user via copy-and-paste or drag-and-drop, the password
for the new user was copied from the original user. Now, Sybase Central prompts
for the new user’s password.
================(Build #3910 - Engineering Case #740488)================
Attempting to create a table column or domain with an empty string as the
default value would have caused the object to be created with no default
value. This has been fixed.
================(Build #3896 - Engineering Case #738707)================
When a mirror or copy node was transitioning between pulling log pages and
having the primary or parent pushing log pages, it was possible for the mirror
or copy node to have failed assertions 112011 or 100927. This has been fixed.
================(Build #3879 - Engineering Case #736356)================
Sybase Central could have crashed after changing the definition of a view
or materialized view. This has been fixed.
================(Build #3875 - Engineering Case #735599)================
When duplicating a materialized view, any change to which dbspace it was
located would have been ignored. Now the choice of dbspace is no longer given,
and the copied materialized view is created in the same dbspace as the original.
================(Build #3873 - Engineering Case #735368)================
Selecting and deleting multiple table privileges could have crashed Sybase
Central if there were corresponding column privileges. This has been fixed.
================(Build #3873 - Engineering Case #735367)================
If an application used variables in the USING clause of a remote server,
or the AT clause of a proxy table or procedure, then the server would have
leaked memory. This problem has now been fixed.
================(Build #3870 - Engineering Case #734591)================
When using the Foreign Key Wizard to create a foreign key, and choosing to
add one or more columns to the foreign table for a foreign key that allowed
nulls, the foreign key would actually have prohibited nulls if the foreign
table was empty. This has been fixed.
In addition, the Foreign Key wizard did not display the SQL to create the
columns on the last page of the wizard. This has also been fixed.
================(Build #3856 - Engineering Case #729777)================
The "Overview" panel for a database shows the mirrored state of
a database. If the deprecated command line option "-xp{partner=...;arbiter=...}"
were specified, the mirroring configuration was not shown on the "Overview"
panel. This has been corrected so that now it is.
================(Build #3852 - Engineering Case #727676)================
The MobiLink Log File Viewer in Sybase Central was unable to read log files
that contained lines which were longer than 8192 bytes. Now, lines up to
65536 bytes are supported.
Note, line length in log files can become very long when the MobiLink server
"-vr" option (display column values) is used.
================(Build #3851 - Engineering Case #730907)================
When selecting the Data tab for a table or view, clicking Cancel in the “Loading
Data” dialog then attempting to fetch the Data didn't always cancel the loading.
This has now been corrected.
================(Build #3851 - Engineering Case #730896)================
On the Fragmentation tab for a database, selecting a table or index in the
list and then attempting to change the selection while the previous selection’s
bitmap was being loaded, may have caused Sybase Central to hang until the
loading completed. This has been fixed. Now the loading of the previous selection’s
bitmap is canceled and the loading of the new selection’s bitmap is started.
================(Build #3851 - Engineering Case #730893)================
On the Create Database wizard’s “Connect to the Database” page, the server
name shown would have been incorrect if a new local server was started, then
the database creation was cancelled and the database file name was changed.
This has been fixed.
================(Build #3851 - Engineering Case #730762)================
In the Breakpoints window, selecting an existing breakpoint to edit may not
have selected the right server name. This has been fixed.
================(Build #3849 - Engineering Case #730475)================
When viewing a NULL binary value in the Long Value window, the Save button
was incorrectly enabled. If the Save button was clicked, Interactive SQL
would have crashed. This has been fixed;. Now, the button is not enabled
if the value is NULL.
================(Build #3848 - Engineering Case #730250)================
Attempting to delete one or more objects by selecting the objects, pressing
the Delete key, and then quickly pressing the Y key to confirm the deletion
before the confirm dialog was displayed, could have caused Sybase Central
to crash. This has been fixed.
================(Build #3848 - Engineering Case #730248)================
When using the table editor to change a column’s data type, Sybase Central
could have crashed if a domain had previously been created in the same Sybase
Central session. This has been fixed.
================(Build #3834 - Engineering Case #727777)================
When comparing databases, applying the generated script to convert database
1 to database 2 would have failed if one database contained a table and the
other database contained a view, such that the table and view shared the
same owner and name. The same problem would also have occurred for procedures
and functions. These problems have been fixed so that the generated script
now contains the required statement to drop the object from database 1 before
creating the object from database 2.
================(Build #3834 - Engineering Case #727769)================
When comparing databases, a CREATE TRIGGER statement would have been marked
as an unrecognized statement if it included a trigger owner; for example,
CREATE TRIGGER trigger-owner.trigger-name BEFORE INSERT ON table-owner.table-name...
. This has been fixed.
Note that while the trigger owner is syntactically valid, it is ignored
by the server.
================(Build #3831 - Engineering Case #727192)================
Comparing databases could have failed if extended characters were used in
one or more of the connection parameters for either of the databases. For
example, if a database name was specified that contained characters other
than 7-bit ASCII. This has been fixed.
================(Build #3831 - Engineering Case #727045)================
If the case of the procedure owner and/or name differed between the procedure’s
definition statement and its source statement in the reload script generated
by dbunload, then attempting to compare the databases would have thrown an
assertion.
For example:
create procedure usr.FullName( ...;
COMMENT TO PRESERVE FORMAT ON PROCEDURE "USR"."FullName"
IS ...;
The same problem would have occurred for functions, triggers, views, and
events. These issues have been fixed.
================(Build #3827 - Engineering Case #726268)================
Under rare circumstances, using Sybase Central’s search functionality may
not have have been able to locate a search hit when it was double-clicked.
This has been fixed.
================(Build #3819 - Engineering Case #724359)================
If a database contained a Remote Server definition with a variable reference
in its srvinfo column, then clicking the Overview panel would have caused
a “variable not found” error to be reported. This has been fixed.
================(Build #3786 - Engineering Case #718270)================
In the Create User wizard, attempting to create a user without a password
and setting the login policy to something other than "root" would
have caused the login policy setting to be ignored. This has been fixed.
================(Build #3770 - Engineering Case #715672)================
Attempting to connect Sybase Central to a database running on a version 11.0.0
or earlier server would have caused Sybase Central to crash. This has been
fixed.
================(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 #4452 - Engineering Case #801963)================
On Windows systems, a custom SQL Anywhere install using the MSI file created
by the Deployment Wizard would have failed to create some registry entries.
In particular, the following entries were not set for the indicated versions
and bitness.
Version 16.0 64-bit HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SQL Anywhere\16.0
Version 17.0 64-bit HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SQL Anywhere\17.0
When one of the above registry entries was missing, it may have lead to
problems locating the correct version of software components. The procedure
for creating these entries manually is described here: http://dcx.sap.com/index.html#sqla170/en/html/815fecef6ce21014b8cbe79cfc3ef3a3.html
32-bit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\SQLANY
<version>.0
32-bit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\SQLANY
<version>.0 Admin
64-bit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\SQLANY64
<version>.0
64-bit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\SQLANY64
<version>.0 Admin
where <version> is 12, 16, or 17.
When the above registry entries are missing, it is not possible to see the
message text when using the Windows Event Viewer to examine event log entries
created by the database server and other SQL Anywhere components. The procedure
for creating these entries manually is documented here: http://dcx.sap.com/index.html#sqla170/en/html/816136106ce21014b9a68de8836cc659.html
These problems have now been fixed.
================(Build #4373 - Engineering Case #794961)================
The text completer could have mistaken the keyword "ON" following
a table name as a table alias. If the completer was used to fill in the name
of a column in that table, the column name wouldn have been prefixed by "on.",
which was incorrect. This has been fixed.
================(Build #4373 - Engineering Case #794889)================
The Connect window allows connecting to a SQL Anywhere database using a connection
string, and contains a list of recently used connection strings. Passwords
in the list of connection strings were not removed when they were saved.
This has been corrected so that now they are.
================(Build #4300 - Engineering Case #787530)================
An XML value can be viewd from a result set in its own window. That window
contains a tab called "XML" which contains a "Format"
button. Clicking the button formats the XML to make it more readable. f
the column value included a self-closing element which contained whitespace
within the tag, it was not recognized as a self-closing element, and all
subsequent indenting was wrong.
For example, "<e><e /></e><f>Test</f>"
should be formatted
<e>
<e />
</e>
<f>Test</f>
but was incorrectly formatted
<e>
<e /></e>
<f>Test</f>
This has been fixed.
================(Build #4288 - Engineering Case #786259)================
XML values can be displayed in their own window by double-clicking them.
That window contains a number of tabs, one of which is "XML Outline",
which renders the XML value as a tree. On non-Windows computers, clicking
on an expandable node in the tree could have expanded the wrong node, or
could have done nothing. This has been fixed.
================(Build #4278 - Engineering Case #784929)================
If the Broadcast Repeater utility used the -x option was used to stop an
existing dbns, it would work (the first dbns would shut down), but the second
dbns would remain running. This has been fixed.
================(Build #4276 - Engineering Case #784723)================
The Interactive SQL utility could have reported an internal error if the
Query Editor was opened after losing the connection to a SQL Anywhere database.
This has been fixed.
================(Build #4257 - Engineering Case #782602)================
The dbisqlc utility returned an incorrect result row with null values if
a query contained an outer join and the null-supplying side was a procedure
call that returned no rows. This has been fixed.
================(Build #4247 - Engineering Case #782242)================
On non-Windows computers with multiple monitors, popup menus (typically opened
by right-clicking on a component) could have appeared on the wrong monitor
if the Interactive SQL utility or SQL Central window was not on the primary
monitor. This has been fixed.
================(Build #4247 - Engineering Case #781693)================
The version number on x509 certificates generated by createcert was 1, but
the certificate contained extensions that were only available in version
3. One notable side-effect of this was that importing certificates into a
Java keystore for the odata server or other Java application failed. This
was a result of the conversion from Certicom to OpenSSL, and has been fixed.
================(Build #4247 - Engineering Case #778313)================
On Unix systems, after sourcing the file bin64/sa_config.sh, the Interactive
SQL utility would have reported “Warning … disabled stack guard.” This has
been fixed.
================(Build #4247 - Engineering Case #777179)================
When using the SQL Anywhere, MobiLink, or UltraLite, utilities with multi-byte
characters in connection strings or on the command-line, there may have be
an unexpected “Parse Error”. This has been fixed.
================(Build #4241 - Engineering Case #780898)================
The OUTPUT statement could have written results to the wrong file if all
of the following were true:
- DBISQL was configured to show results from all statements. That was an
option (but not the default) in version 16 and earlier.
- The last two (or more) result-set-generating SQL statements were the
same.
- DBISQL was run as a windowed application.
For example:
create table t ( c int );
insert into t values( 1 );
select * from t;
output to 'x.txt';
insert into t values( 2 );
select * from t; // Same as the previous SELECT statement
output to 'x.txt' append;
Before the fix, the first OUTPUT statement wrote 'x.txt', while the second
OUTPUT statement wrote 'x-1.txt' and 'x-2.txt'. The string 'x-1.txt' was
a copy of 'x.txt'. Now, the second OUTPUT correctly appends to 'x.txt'.
================(Build #4240 - Engineering Case #780701)================
The Import Wizard reported an error when attempting to import a shape file
into a database that used the Turkish collation 1254TRK. This has been fixed.
================(Build #4225 - Engineering Case #778719)================
When connected to a database with a Turkish collation (1254TRK), the Index
Consultant would have always failed with the message "Table 'sysphysidx'
not found". This has been corrected.
================(Build #4225 - Engineering Case #778718)================
When connecting to a database with a Turkish collation (1254TRK), the post
login procedure was not being called, given that one was defined. This has
been corrected.
================(Build #4222 - Engineering Case #778231)================
The Extraction utility (dbxtract) was incorrectly extracting the consolidated
database's mirror server definitions (if they existed). This has been fixed
so that mirror server definitions are no longer extracted.
================(Build #4211 - Engineering Case #777043)================
If the Backup utility (dbbackup) was used to back up a database that had
no transaction log, and the -n and -r switches were used, dbbackup would
crash. This has been fixed.
================(Build #4210 - Engineering Case #776897)================
The Interactive SQL utiliy (dbisql) could have reported an internal error
(OutOfMemoryException) when copying large result sets when the results were
displayed as text. Now, a more user-friendly error message is displayed.
If dbisql runs out of memory when copying results, there are a couple of
things that can be done:
1. When running the 32-bit version of dbisql, run the 64-bit version instead.
It allows for a larger heap, and is less likely to run out of memory.
2. Export the data using an OUTPUT statement, or the "Export Wizard",
rather than copying results to the clipboard.
================(Build #4201 - Engineering Case #665980)================
The Index Consultant could have failed if the tables involved had text indexes.
This has been fixed.
================(Build #4198 - Engineering Case #775805)================
If a Data Source was modified in the registry to contain the 'Server' connection
parameter rather than 'ServerName', that parameter would have been ignored.
This has been fixed.
================(Build #4193 - Engineering Case #775231)================
If the Service utility (dbsvc) was used to create a service with a space
in the service name (eg. dbsvc -w “My service name”), the service would have
been created but it would not be able to start. This has been fixed.
================(Build #4191 - Engineering Case #773279)================
Turning off The Interactive SQL utility's COMMIT_ON_EXIT option had no effect
for the session in which it was turned off. This has now been fixed.
================(Build #4176 - Engineering Case #784649)================
When exporting data to an ASE database, the "Owner" combobox on
the Export Wizard page where a table name is specified could have contained
a given owner name many times. This has been corrected so that now the name
appears only once.
================(Build #4171 - Engineering Case #771873)================
If the Interactive SQL utility (dbisql) was run as a command-line program,
it was possible for dbisql to report that it could not connect to the database,
and then proceed to execute a statement anyway. In this scenario, dbisql
would set its return code to 9 (could not connect) which was inconsistent
with the fact that it actually executed the statement. For this to have
occurred, all of the following would have had to be true:
- A valid connection string and a statement must have been specified on
the command line,
- The database server had to be unreachable when dbisql started
- The database server must then have become available as dbisql completeed
its startup sequence
This has been fixed. If the database server is unavailable when dbisql
initially attempts to connect, it will now simply shut down, rather than
attempting to execute the given statement.
================(Build #4166 - Engineering Case #771429)================
The Interactive SQL utility would have crashed when using the Import Wizard
to import a shape file, and that shape file had an associated .DBF file which
contained a DATE, TIME, or TIMESTAMP column. This has been fixed.
================(Build #4163 - Engineering Case #770967)================
The following issues have been fixed:
If a post login procedure did not return a result set, the Interactive SQL
utility would have crashed.
Also, a race condition could have caused the window containing the post
login messages to appear on-screen at the same time as the "Connecting
to database" status window. When this occurred, neither window could
have been closed.
================(Build #4162 - Engineering Case #770747)================
The Interactive SQL utility (dbisql) could have consumed more disk space
than was required under certain circumstances. This has now been corrected.
================(Build #4161 - Engineering Case #770576)================
On Red Hat Enterprise Linux 7, the Interactive SQL utility could not check
for updates, nor could they open online help if the computer it was running
on required a network proxy to reach the internet. This has been fixed so
that on non-Windows platform, the software will use the proxy information
in the http_proxy environment variable, if set.
Note, this problem also affected Sybase Central and the Console utility,
which are fixed as well.
================(Build #4160 - Engineering Case #770200)================
The unused Batik JAR file JS.JAR has been removed from the list of JAR files
that the Interactive SQL utility searches for on startup.
================(Build #4146 - Engineering Case #768514)================
On some RedHat distributions, if the SQL Anywhere Monitor was configured
as a service that started automatically when the computer was rebooted, it
may have sporadically failed to start. This has been fixed.
================(Build #4142 - Engineering Case #767881)================
When SQL Remote was generating messages, if a change had been made to a column
with a numeric or decimal data type, SQL Remote would have failed to add
information to the message that would have allowed the receiving side to
have performed conflict resolution. This issue has now been fixed.
================(Build #4130 - Engineering Case #766369)================
When running sqlpp on Linux systems with a recent version of glibc, a syntax
error could have been reported for perfectly good code. Moreover, the "near"
text may have appeared mangled. For example, running the following statements
through sqlpp:
EXEC SQL BEGIN DECLARE SECTION;
EXEC SQL END DECLARE SECTION;
would have resulted in the following error:
test.sqc(35): Error! E2636 near 'AREARE': Incorrect Embedded SQL syntax
This has been fixed. There is no known workaround for this.
================(Build #4108 - Engineering Case #763149)================
If the Interactive SQL utility (dbisql) had been launched from Sybase Central
to debug a stored procedure, and then closed while at a breakpoint, dbisql
would have crashed. This has been fixed.
================(Build #4106 - Engineering Case #762942)================
The Interactive SQL utility (dbisql) could have crashed if the text completer
was opened in poorly formed SQL. In order to crash, the caret would have
to follow an unmatched quotation mark. This has been fixed.
================(Build #4105 - Engineering Case #762797)================
The text completer could have crashed when opened in an incomplete or poorly-formed
SELECT...FROM clause. This has been fixed.
================(Build #4090 - Engineering Case #732565)================
MSI installs generated using the Deployment wizard would have always contained
the same upgradecode property. This was causing the behavior that installing
a newer version of SQL Anywhere would cause the older version to be uninstalled.
This has been fixed by changing the upgradecode property to a distinct code
for each major revision of SQL Anywhere.
================(Build #4066 - Engineering Case #756786)================
In the Console utility (dbconsole), if the Connections panel was configured
to show the last reported statement, and the statement was longer than 255
characters, a "Right truncation of string data" error would have
been reported. This has been fixed.
================(Build #4058 - Engineering Case #755529)================
Creating a certificate with an expiry date beyond 2050 would have resulted
in a certificate that expired 100 years before the expected expiry date.
This has been fixed.
================(Build #4058 - Engineering Case #755372)================
If the Certificate Creation utility (createcert) was used without the -3des
option, a compatibility warning was displayed warning that the resulting
certificate would not be compatible with older versions of the software.
The build numbers shown in this message were incorrect. This has been corrected.
================(Build #4055 - Engineering Case #754733)================
Interactive SQL could have appended a spurious character to the command line
if it was passed a command file which was hidden using the File Hiding utility
(dbfhide) . This has been fixed.
================(Build #4055 - Engineering Case #754638)================
The Service utility for Windows (dbsvc) was treating leading @ in passwords
as an intend to expand the argument via a file or environment variable. This
is a consistent behavior across many SQL Anywhere command line tools. However,
there is no general escape syntax for leading @ in command line arguments.
Users can work around the issue by avoiding user defined elements with leading
@, but is not acceptable for user accounts with established or generated
passwords. A fix was made to the Service utility specifically so that it
will fall back to take the entire password argument following –p literally
if the expansion failed. This change does not apply to other tools.
================(Build #4047 - Engineering Case #757529)================
A security issue with the Unload utility (dbunload) has been corrected.
================(Build #4028 - Engineering Case #733912)================
The File Hiding utility (dbfhide) would have crashed if an input file was
larger than 65528 (64k-8) bytes. This has been fixed so that an error is
now displayed if the file is too large.
================(Build #4012 - Engineering Case #750919)================
Opening online help (DCX) from the graphical administration tools may have
failed with the error message "Web page is not accessible". This
would have happened under the following conditions:
- Interactive SQL 12 was being run and the "Help" button was clicked
on the "Connect" window the first time it was opened, and the network
used a proxy to connect to the internet.
- Sybase Central 12 or later, or Interactive SQL 12 or later, was being
run and the fast launcher was turned on, and the network used a proxy to
connect to the internet.
These problems have been fixed.
================(Build #3988 - Engineering Case #748557)================
Opening the text completer when connected to an ASE database could have caused
the Interactive SQL utility to crash. This has been fixed.
================(Build #3951 - Engineering Case #744845)================
The context menu for the SQL Statements panel includes a "Help on"
menu item if there might be online help for the statement under the mouse.
Clicking the "Help on" menu item opens help in a browser if local
help is not installed. The process of opening the help has been sped up,
especially if no help files were installed. How much faster depends on the
network connection.
Also, the software is now more tolerant of whitespace between keywords.
For example, suppose the SQL Statements panel contained the following valid
statement, spread across four lines:
CREATE
VARIABLE
retcode
INT
Clicking "Help on" in the context menu would have failed to open
help because of the newlines that separate the tokens. Now, help for the
CREATE VARIABLE statement will be opened.
================(Build #3935 - Engineering Case #742293)================
A case sensitive database with the DBA user name spelled in a way other than
‘DBA’ (for example, ‘dBA’ or ‘dba’) and password other than ‘sql’ could have
failed to be unloaded. This has been fixed.
================(Build #3931 - Engineering Case #742549)================
The Validation utility (dbvalid) would have returned EXIT_BAD_DATA(=2) if
an invalid object name was included in the object-name-list. If these obests
are not found, ideally the error EXIT_FAIL(=1) should be returned instead.
This has been fixed.
================(Build #3899 - Engineering Case #728742)================
If a database contained a materialized view that used key joins, then unloading
and subsequently reloading the database would have failed. This problem has
now been fixed.
================(Build #3889 - Engineering Case #737801)================
If a single user on a computer ran a number of copies of the Interactive
SQL utility (dbisql), it was possible for its options to have been reset
to their defaults. For this to have occurred, one dbisql process would have
to have be starting, when another dbisql process was shutting down. This
has now been fixed.
================(Build #3868 - Engineering Case #733155)================
During silent installs of a SQL Anywhere Monitor SP, the Migration tool’s
progress window was being displayed. This has been fixed so that the progress
window is no longer displayed during a silent install.
================(Build #3867 - Engineering Case #733905)================
Attempting to export a result set which contained character data to a Microsoft
Access database would have failed with a message saying that 'there is no
data type in the destination database that corresponds to "char".'
This has been fixed.
================(Build #3860 - Engineering Case #732584)================
When editing a binary table value in either the Interactive SQL utility,
or Sybase Central, an assertion error would have been reported if the existing
value was not null. This has been fixed.
================(Build #3858 - Engineering Case #731939)================
Binary values could have been unexpectedly truncated when being displayed
to a console window, or in Interactive SQL if the program was configured
to display result sets as text. This has been fixed.
================(Build #3851 - Engineering Case #730928)================
The Interactive SQL utility could have crashed when viewing binary values
if the long value window was closed before the server returned the complete
cell value. This has been fixed.
================(Build #3851 - Engineering Case #730919)================
Clicking the Cancel button in the Spatial Viewer window could have failed
to cancel the execution. At that point, the Spatial Viewer could not then
be closed. This problem has been fixed, and execution can now be cancelled.
================(Build #3851 - Engineering Case #730800)================
Some uniqueidentifier column values could have been displayed as "(IMAGE)"
in the result set table. This has been fixed.
================(Build #3851 - Engineering Case #730797)================
The fix for Engineering case 728776 introduced a bug which caused the CREATE
TABLE ON clause of the INPUT statement to fail with a message saying that
the destination table did not exist. This has been fixed.
================(Build #3851 - Engineering Case #730789)================
The INPUT statement and the Import wizard could have failed while importing
spatial data if the source column did not have a SRID constraint, the data
contained an embedded non-zero SRID, and Interactive SQL was creating a new
table to hold the imported data. This has now been fixed.
================(Build #3849 - Engineering Case #730485)================
The Interactive SQL utility shows result sets using a scrollable table, which
can be searched. With "Match case" selected in the "Find in
Results" window, dbisql would still have performed a case-insensitive
search. This has been fixed.
Also, It was possible for the table cell which contained the matched text
to be hidden under the "Find in Results" window. Now, the window
is automatically moved out of the way.
================(Build #3849 - Engineering Case #730384)================
Pressing the F1 key while an error window was open after executing a SQL
statement with the Interactive SQL utility, would have cased dbisql to crash.
This has been fixed.
================(Build #3846 - Engineering Case #729852)================
The Text Completer has an option to open automatically when typing to suggest
object names. Opening the Query Editor window had an inadvertent side-effect
of always turning off this option. This has been fixed so the Query Editor
no longer permanently turns off the option.
================(Build #3846 - Engineering Case #728886)================
When the "Show all result sets" option is on, the Interactive SQL
utility will display all the result sets returned by a query. If a statement
produced more than one result set, and the Export Wizard was used to export
those result sets, clicking the "Next" button on the first page
would have returned an error saying that only one result set can be exported
to an ODBC data source. This message would have been returned even when not
exporting to a database. This has been fixed. The Export Wizard now supports
exporting multiple result sets to text files, HTML files, and XML files.
================(Build #3844 - Engineering Case #729292)================
The unload support utility for pre-10.0 database (dbunlspt) may have behaved
badly, including crashing, failing assertions, or database file corruption,
when using a recent version of Linux with glibc 2.11 or higher. This has
been fixed.
================(Build #3842 - Engineering Case #728776)================
Attempting to import data into a table for which the user did not have permission
to select rows, they would have failed with the incorrect error message "The
table you selected ... does not exist."
Similarly, the same bad error message would have been presented when exporting
into a database table for which the user did not have permission to select
rows.
These problems have been fixed. The error message now clearly indicates
that you don't have permission to select from the table.
Users could encounter this problem when executing the INPUT or OUTPUT USING
statements, or when using the Import or Export wizards.
================(Build #3842 - Engineering Case #728720)================
A long delay may have been observed when right-clicking in the SQL Statements
panel, especially if the internet connection was slow, or if there was no
internet connected at all. This has been fixed. Note, the problem does not
occur if the documentation has been installed locally.
================(Build #3834 - Engineering Case #727765)================
If the SQLANY12 environment variable had a trailing slash, the path to the
Driver= line in the DSN would have been constructed incorrectly by the Data
Source utility (dbdsn). This has been fixed.
================(Build #3831 - Engineering Case #727096)================
Clicking the "Single Step" menu item executes the SQL statement
containing the editing caret, then selects the next statement in the "SQL
Statements" panel. If the SQL statements were separated by the word
"GO", the single stepping could have failed depending on the specific
statement being executed, resulting in a syntax error that referred to a
trailing letter "G" in the statement. This has been fixed.
================(Build #3827 - Engineering Case #725779)================
When installing an EBF, the installer could have erroneously terminated and
rolled back the install. This has been fixed.
================(Build #3817 - Engineering Case #712095)================
The Log Translation utility (dbtran) could have crashed if the transaction
log ended in an incomplete checkpoint. This problem has been fixed
================(Build #3814 - Engineering Case #723135)================
If a directory in quotes with a trailing backslash inside the quotes (i.e.
“my directory name\”) was supplied to a utility requiring a directory name,
the name of the directory used would have been incorrect (in this case my
directory name” with a trailing quote). The affected tools were: dbbackup,
dbunload, dbtran (-m switch), dbremote (-ml switch) and the server (-dt,
-ad, and -ds switches). This has been fixed. The trailing quote will now
be stripped from the directory name.
================(Build #3810 - Engineering Case #722071)================
When attempting to execute a statement which contained an incomplete multi-line
comment, the error message mentioned that there was an error at the end of
the SQL statement, but did not indicate that the problem was an unterminated
comment. Now, the error message makes that explicit.
================(Build #3804 - Engineering Case #721437)================
The "Check for Updates" menu item in the Interactive SQL utility,
Sybase Central, and DBConsole would have always reported that the update
server was unavailable if a network proxy was used to access the internet.
This has been corrected so that now if an HTTP proxy is configured for the
computer, the proxy will be used and the check for updates will succeed.
Note that if the computer is set to automatically configure its proxy, the
HTTP proxy must also be set explicitly for the update checker work function
properly.
================(Build #3799 - Engineering Case #718127)================
When importing or exporting to an UltraLite database using the Interactive
SQL utility, LONG BINARY and LONG VARCHAR datatypes could have been truncated
or an error reported. This has now been fixed.
================(Build #3792 - Engineering Case #719292)================
Attempting to connect to a database by specifying an IPv6 address would most
likely have failed. This has been fixed.
Note, in the Connect window, a new IPv6 address can be entered in the Host
field. If the address ends in a colon and a port number, the host portion
of the address must be enclosed in square brackets. This is as documented.
An IPv6 address can also be entered without a port number and without square
brackets in the Host field. When entering a port number in the Port field,
the square brackets will be added automatically.
================(Build #3782 - Engineering Case #717545)================
On Solaris systems, the setup script run by the install would have failed
with the message "Bad string" when run on systems with a multi-byte
charset locale. This has been fixed.
================(Build #3781 - Engineering Case #717390)================
The Support utility (dbsupport) could have crashed if Error Reporting server
was down. This has been fixed.
================(Build #3779 - Engineering Case #717187)================
The Interactive SQL utility's OUTPUT statement can write data to a text file.
Special characters in the data can be escaped, or not, as specified by the
ESCAPES clause. If ESCAPES OFF was specified, special characters were not
escaped, but the quote character (an apostophe, by default) was not being
doubled up as it should have been. As a result, the generated text file could
not be subsequently processed by the INPUT statement because the quotes were
not matched. This has been fixed.
================(Build #3779 - Engineering Case #717100)================
Unchecking the "Escape text data" box in the Export Wizard did
not turn off escaping of text data. This has been corrected so that now it
does.
================(Build #3779 - Engineering Case #717096)================
The Export Wizard in the Interactive SQL utility had the "Include column
names" check box incorrectly disabled when the user elected not to escape
text data. These two options are, in fact, independent. Now, the "Include
column names" check box is always enabled.
================(Build #3771 - Engineering Case #715906)================
The Support utility (dbsupport) may have crashed while attempting to receive
a response from the error reporting site, if the error reporting site was
not available. This has not been corrected.
================(Build #3770 - Engineering Case #715469)================
The interactive response of the Lookup Table Name and Lookup Procedure Name
windows in the Interactive SQL utility has been improved.
================(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 #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 #4224 - Engineering Case #777476)================
The Extraction utility (dbxtract) would have failed to extract indexes defined
on materialized views. This would have resulted in a failure during rebuild
if an IMMEDIATE REFRESH materialized view was extracted, as a unique index
on the view is mandatory. The issue could have been worked around by adding
the –xv switch to dbxtract to not extract views. This problem has now been
fixed, and indexes defined on materialized views are now extracted.
================(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 #3850 - Engineering Case #730270)================
SQL Remote always assumes that all databases involved in replication share
the same character set. By default, SQL Remote will always apply source CHAR
data to a target database using the default character set for the operating
system it is running on, ignoring the source data character set.
When using a database character set that is different than the default character
set for the operating system, dbremote must be instructed to perform explicit
data conversion to that character set on its connection string:
e.g. dbremote -c “CHARSET=utf8;…”
or instruct dbremote to always use the CHAR character set
of the target database to apply the remote CHAR data:
e.g. dbremote -c “CHARSET=none;…”
================(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 #4240 - Engineering Case #772485)================
In passthrough mode for SQL Remote the server also placed calls to internal
procedures into the transaction log. If these call statements were replicated
to the remote side, errors would have ocurred. This has been fixed.
================(Build #3770 - Engineering Case #715218)================
In rare cases, SQL Remote would have started applying a multi-part message
before receiving the last piece the message, and then would have ignored
all the operations in the last piece of the message when it was received.
This has been fixed, SQL Remote will make sure it has received all the pieces
of a multi-part message before applying them.
================(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 #4158 - Engineering Case #769881)================
On Chinese RedHat 7 Linux, the syntax highlighting editor chose an inappropriate
(proportional) font. This choice caused a number of problems:
- the caret was displayed in the wrong location
- it was impossible to move the caret predictably
- the Text Completer made inappropriate suggestions
- the line and column information on the status bar were incorrect
These have now been fixed.
================(Build #4014 - Engineering Case #751106)================
If the Fast Launcher was enabled, but was unable to initialize, the Interactive
SQL utility or Sybase Central would have crashed if the Fast Launcher was
subsequently disabled. This has been fixed.
================(Build #3855 - Engineering Case #731620)================
The Deadlocks tab for a database could have reported that deadlock collection
was not enabled, when it was in fact enabled. This 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 #4427 - Engineering Case #800244)================
Customers were previously recommened when developing Windows 10 applications
to reference the UltraLite Windows 8.1 libraries. However it was found that
applications referencing these 8.1 libraries may fail the Windows App Certification
Kit (WACK) tests, preventing them from being published to the Microsoft app
store. UltraLite libraries built specifically for Windows 10 that will pass
the WACK are now provided.
================(Build #4367 - Engineering Case #794181)================
The runtime would have crashed if a temporary table exceeded the maximum
row size. This has been fixed. The runtime will now correctly report the
error SQLE_MAX_ROW_SIZE_EXCEEDED.
================(Build #4173 - Engineering Case #772133)================
Calling the system function ML_GET_SERVER_NOTIFICATION() would have failed
on iOS using a client identity stored in the database. This has been fixed.
================(Build #4157 - Engineering Case #769394)================
Using UltraLite on iOS 8 beta software resulted in synchronization errors
with HTTPS.
This has been fixed
================(Build #4157 - Engineering Case #765434)================
Creating a publication with an article greater than 256 bytes in length would
have resulted in crash of the UltraLite runtime. This has been corrected
so that articles of up to 2048 bytes in length are now supported. SQLE_STRING_PARM_TOO_LONG
is now reported when a publication predicate is >=2048 bytes.
The database must be created or rebuilt to access the larger publication
article size. Older databases will continue to work with a max publication
article size of 256 bytes. Databases created or rebuild with this change
will run on older runtimes provided publication articles are <= 256 bytes.
================(Build #4015 - Engineering Case #750611)================
When a row was inserted into a table with a UNIQUE INDEX, with a NULL value
in the index key and matching an existing index key with NULLs considered
equal, the error SQLE_INDEX_NOT_UNIQUE was signaled. This has been fixed.
Note that UltraLite does not support the clause “WITH NULLS NOT DISTINCT”
for the CREATE INDEX statement. Therefore, an index key should be considered
unique if it contains NULL in at least one column.
================(Build #4005 - Engineering Case #743862)================
UltraLite on iOS previously required that certificates named in synchronization
parameters be packaged as resources in the root of the application bundle.
Now, if the named certificate resolves to a filename (directly), that file
is used instead of searching the bundle. This means any certificate file
in the application sandbox is now accessible given the proper path.
================(Build #3977 - Engineering Case #747538)================
The UltraLite runtime may have generated UUID values which were not globally
unique on iOS 7. This has been fixed.
================(Build #3906 - Engineering Case #740226)================
Using '*' when specifying the publication list would have caused the UltraLite
runtime to crash during a synchronization. This has been fixed.
================(Build #3887 - Engineering Case #737612)================
If an application closed the connection to the database used to synchronize
before the synchronization completed, the database could have become corrupt.
One possible symptom of this corruption was the runtime sending two different
progress values for the same publication during synchronization. This has
been fixed. Now the runtime will report SQLE_SYNCHRONIZATION_IN_PROGRESS
in the close connection call and immediate abort the application. When the
database is restarted, recovery will be done to rollback any uncommitted
operations that occurred during synchronization.
================(Build #3881 - Engineering Case #736683)================
An UltraLite database could have unnecessarily grown by a small amount during
each synchronization, or as a result of executing publication DDL. This has
now been corrected.
================(Build #3870 - Engineering Case #734471)================
For queries with LIKE expressions of the form “c LIKE <pattern>”, where
column c is a numeric data type, the UltraLite runtime would have given a
SQLE_CONVERSION_ERROR during query execution if column c contained data whose
string length when converted to a string was longer than the domain size
of the numeric type. For example, if c is of type INTEGER and a row in table
t contained the integer 12345, then the query SELECT c FROM t WHERE c LIKE
‘1%’ would have caused a SQLE_CONVERSION_ERROR because the length of the
string ‘12345’ is greater than 4, the domain size of the INTEGER data type.
This has been fixed.
================(Build #3864 - Engineering Case #733309)================
If an UltraLite application placed a cursor on a row and then moved to before
the first row and then back to that row again, the row may have been skipped
the second time if the row was updated while the cursor was positioned before
the first row. This has been fixed.
================(Build #3851 - Engineering Case #730783)================
In rare circumstances, synchronizations could have failed if another thread
was performing operations on the database at the same time. This has been
fixed.
================(Build #3834 - Engineering Case #714809)================
A result set could have been returned with both the pre-image and the post-image
of a row that was updated while the cursor was sitting on it. This has been
fixed. Result sets will now return only one copy of the row, the pre-image
or the post-image, but not both, depending on the isolation level and when
the update is committed.
================(Build #3820 - Engineering Case #723102)================
UltraLite could have returned incorrect results when a subquery made reference
to its own expressions.
For example, in the following, c2 is not evaluated properly:
select * from (select id + id as c1, c1 as c2 from T) as DT(c1,c2)
This has been fixed.
================(Build #3815 - Engineering Case #723443)================
String concatenation expressions in UltraLite could have given incorrect
results, in such a way that a substring was missing from the correct result.
For example, the SQL query "SELECT ISNULL('a','') + ISNULL(NULL, '')
+ 'b'" would have given the result ‘b’ when the correct result was ‘ab’.
This has been fixed.
================(Build #3811 - Engineering Case #723024)================
An index with multiple columns, and any nullable column except the last one
in the index, may have been incorrectly ordered.
For example:
CREATE TABLE Foo ( num INT PRIMARY KEY DEFAULT AUTOINCREMENT, b1 BINARY(1),
b2 BINARY(1), b3 BINARY(1) )
CREATE INDEX I ON Foo( b1, b2, b3 ) WITH MAX HASH SIZE 3
INSERT INTO Foo( b1, b2, b3 ) VALUES( 0, 0, 7 )
INSERT INTO Foo( b1, b2, b3 ) VALUES( 0, null, 8 )
INSERT INTO Foo( b1, b2, b3 ) VALUES( null, 0, 9 )
INSERT INTO Foo( b1, b2, b3 ) VALUES( null, null, 10 )
SELECT * FROM Foo ORDER BY b1, b2, b3 could result in an ordering like:
row: 0, 0, 7
row: 0, null, 8
row: null, 0, 9
row: null, null, 10
DROP INDEX Foo.I
CREATE INDEX I ON Foo( b1, b2, b3 ) WITH MAX HASH SIZE 3
SELECT * FROM Foo ORDER BY b1, b2, b3
row: null, null, 10
row: null, 0, 9
row: 0, null, 8
row: 0, 0, 7
This has been fixed.
================(Build #3811 - Engineering Case #723007)================
UltraLite queries that used an index with a DESC column that contains NULLs,
may have returned wrong results. The query must not have had a lower bound
condition for the DESC column for this problem to have occurred. Depending
on any ORDER BY clauses, the query may have returned no rows, or may have
returned rows containing nulls, when the query had a predicate on that column.
For example:
CREATE TABLE "T" ( "pk" bigint NOT NULL PRIMARY KEY,
"x" integer NULL )
CREATE INDEX "idx1" on "T" ( "x" DESC ) WITH
MAX HASH SIZE 0
And the following data:
insert into T(pk,x) values(1, -20)
insert into T(pk,x) values(2, null)
insert into T(pk,x) values(3, 10)
And the following queries:
SELECT pk FROM T WHERE x >= 5 ORDER BY x DESC
-> UL will return the wrong results (no rows, when it should return
the row with pk=3).
SELECT pk FROM T WHERE x <= 10 ORDER BY x ASC
-> UL will return no rows when it should return the rows with pk=1 and
3
SELECT pk FROM T WHERE x <= 10 ORDER BY x DESC
-> UL will return all rows (including the row pk=2,x=null when it should
return the rows with pk=1 and 3
This has been fixed.
================(Build #3809 - Engineering Case #721986)================
Attempting to drop a table that was still referenced by a foreign key would
not have returned an error, but would have lefte the database in an incorrect
state. This has been fixed. DROP TABLE will now signal SQLE_TABLE_IN_USE
in this case..
================(Build #3807 - Engineering Case #721933)================
Unique keys could have been created incorrectly in the following situations:
1) If a CREATE TABLE defined a column as nullable then placed that column
in an unique constraint, the column would have remained nullable. For example:
CREATE MyTable(
pkey INT PRIMARY KEY,
num INT NULL,
CONSTRAINT un_num UNIQUE( num )
)
2) A GEOMETRY column could have been placed in a unique constraint.
3) An ALTER TABLE which added a UNIQUE constraint could have included a
nullable column.
This has been fixed. When a table is now created, columns in unique constraints
are forced to be not null and GEOMETRY columns are not allowed in unique
constraints (as previously documented). When adding a unique constraint
on a nullable column, an error will now occur. The correct procedure is to
first alter the column to be not null, then alter the table to add a unique
constraint.
================(Build #3803 - Engineering Case #717377)================
A query involving CASE or IF, with references to a sub-query, could have
crashed UltraLite when the query was executed. This has been fixed.
================(Build #3800 - Engineering Case #720419)================
LONG VARCHAR columns could have contained incorrect results for the second
and subsequent queries using that datatype.
================(Build #3787 - Engineering Case #718317)================
A query using sub-queries with a UNION may have returned incorrect results.
For example:
select (select 1) union select 2"
the sub-query (select 1) was not evaluated properly. This has now been fixed.
================(Build #3782 - Engineering Case #717582)================
When running on Mac OS X and iOS systems, it is possible that writes to an
UltraLite database file could have been reordered by the underlying hardware/storage
device under certain circumstances, possibly resulting in a corrupt database
file. This has been corrected by having UltraLite make extra calls to request
the hardware complete writes in order when required.
================(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 #4368 - Engineering Case #788865)================
An Embedded SQL application using TCHAR datatypes may have encountered a
compile error. This has been fixed.
================(Build #3845 - Engineering Case #729556)================
The UltraLite runtime could have caused an application to crash during the
optimization of a query with many JOINs (typically more than 12). 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 #3843 - Engineering Case #729137)================
When running a non-English synchronization profile, attempts to synchronize
an UltraLite database from the Sybase Central UltraLite plug-in, via the
Synchronization wizard, could have failed with a message reporting that the
synchronization profile can’t be found (and the name of the profile will
be mangled). This has been fixed.
================(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 #4249 - Engineering Case #767368)================
UltraLite could have returned less rows than expected for queries utilizing
an index scan with conditions on multiple columns in the index. This has
been corrected.
================(Build #4178 - Engineering Case #770488)================
UltraLite would have failed to sync using HTTPS on iOS 8. This has now been
fixed.
================(Build #3971 - Engineering Case #743857)================
UltraLite may have blocked concurrent database access while synchronizing,
during the UL_SYNC_STATE_FINISHING_UPLOAD synchronization state. This has
been fixed.
================(Build #3941 - Engineering Case #741572)================
UltraLite could have returned incorrect results for queries using LIKE 'C%',
where C contained 'large'/multi-byte characters. This affected only UTF-8
encoded databases (created with utf8_encoding=yes, which is the default).
This has now been corrected.
================(Build #3931 - Engineering Case #741954)================
Performance of schema API calls could have been poor for large schemas. Querying
any table would have been slow with Sybase Central and Interactive SQL when
the schema was large. This has been fixed.
================(Build #3856 - Engineering Case #727245)================
UltraLite could have signaled -305 or -309 errors, and the crashed or possibly
failed to upload all rows, after the following sequence:
- synchronization including downloaded deletes
- concurrent commit operation during the synchronization download cleanup
phase
- shutdown (or application termination) soon after the synchronization completes
This has now been corrected.
================(Build #3813 - Engineering Case #722938)================
PROBLEM: With UltraLiteJ for Android, when synchronizing a large number of
tables with a SyncObserver the following JNI exception was likely to occur:
"E/dalvikvm(26683): JNI ERROR (app bug): local reference table overflow
(max=512)". The native code to call the SyncObserver was not freeing
local references to Java String objects containing the table name.
SOLUTION: 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 #4095 - Engineering Case #724518)================
When using the MobiLink autodial feature, it was possible for the connection
attempt to fail initially. Later connection attempts would generally have
worked. This has now been corrected.
================(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 #4194 - Engineering Case #772116)================
Execution of sSubqueries whose predicates were sized datatypes, such as char,
varchar, and binary, could have crashed due to a data alignment exception.
This has been fixed.
================(Build #4169 - Engineering Case #771709)================
When using the UltraLite .NET Data Provider, if the BulkCopyTimeout property
was set to 0, an exception would hace occurred during a call to WriteToServer.
This has now been fixed. The value 0 means that there is no timeout.
================(Build #4156 - Engineering Case #724850)================
DataTable.Load() , ULTable.GetSchemaTable(), or use of ULIndexSchema object
could have thrown the exceptions: "Too many temporary tables in connection"
or "Attempted to read or write protected memory. This is often an indication
that other memory is corrupt” if used repeatedly. The method ULIndexSchema.Close()
has been added, and should be called when an application has finished with
an ULIndexSchema instance. This method is also now called internally by
UL.Net objects that use ULIndexSchema.
================(Build #3921 - Engineering Case #741303)================
A DATE datatype would have included time components if the value supplied
contained a time component. As a result, queries could have returned incorrect
results when providing a DATE only predicate value. UltraLite now stores
DATE datatypes correctly when setting or changing the value.
================(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 #4143 - Engineering Case #766935)================
UltraLite Initialize Database utility would have reported ‘?missing string?’
as the description for some collations (ulinit -Z). 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.
A security patch contains an already-released version of the software but includes
updated security components. This process allows the software to be tested more quickly
so that important security fixes are released to customers quickly. Two build numbers
are recorded for security patches: one build number identifies the build of the software
that was previously tested and released; the other is the build of the new security
components that have been updated in the release
The following security patches have been released.
PLATFORM
SOFTWARE BUILD
SECURITY COMPONENTS BUILD
DESCRIPTION
AIX
4224
4422
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1t.
AIX
4224
4358
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1q.
The version of OpenLDAP used by the SQL Anywhere server and client libraries has been upgraded to 2.4.43.
AIX
4224
4295
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1p.
HP-IA64
4224
4422
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1t.
HP-IA64
4224
4358
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1q.
The version of OpenLDAP used by the SQL Anywhere server and client libraries has been upgraded to 2.4.43.
HP-IA64
4224
4295
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1p.
Linux
4378
4422
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1t.
Linux
4294
4358
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1q.
The version of OpenLDAP used by the SQL Anywhere server and client libraries has been upgraded to 2.4.43.
Mac OSX x64
4201
4422
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1t.
Mac OSX x64
4318
4358
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1q.
The version of OpenLDAP used by the SQL Anywhere server and client libraries has been upgraded to 2.4.43.
Mac OSX x64
4201
4295
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1p.
Sun Solaris SPARC
4224
4422
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1t.
Sun Solaris SPARC
4224
4358
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1q.
The version of OpenLDAP used by the SQL Anywhere server and client libraries has been upgraded to 2.4.43.
Sun Solaris SPARC
4224
4295
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1p.
Sun Solaris x64
4224
4422
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1t.
Sun Solaris x64
4224
4358
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1q.
The version of OpenLDAP used by the SQL Anywhere server and client libraries has been upgraded to 2.4.43.
Sun Solaris x64
4224
4295
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1p.
Windows
4403
4414
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1t.
Windows
4344
4358
The version of OpenSSL used by all SQL Anywhere products has been upgraded to 1.0.1q.
The version of OpenLDAP used by the SQL Anywhere server and client libraries has been upgraded to 2.4.43.