SQL Anywhere Bug Fix Readme for Version 11.0.1, build
2627
Choose a range of build numbers for which to display
descriptions. For example if you want to see what was fixed since the last
EBF you applied then change 2044 to the build number of that last EBF. Click
Update Readme to make those changes take effect. to Update
Readme
A subset of the software with one or more bug fixes. The bug fixes are
listed below. A Bug Fix update may only be applied to installed software
with the same version number.
While some testing has been performed on the software, you should not distribute
these files with your application unless you have thoroughly tested your
application with the software.
A complete set of software that upgrades installed software from an older
version with the same major version number (version number format is
major.minor.patch). Bug fixes and other changes are listed in the "readme"
file for the upgrade.
For answers to commonly asked questions please use the following URL:
Frequently Asked Questions
If any of these bug fixes apply to your installation, iAnywhere strongly recommends
that you install this fix. Specific testing of behavior changes is recommended.
================(Build #2524 - Engineering Case #648497)================
When a consolidated was running on an Oracle server, the MobiLink server
would not have advanced the next_last_download timestamp value (it is used
for generating the download in the next synchronization) after it had run
for certain time, even if a synchronization did contain a download request.
After this occurred, the MobiLink server would have downloaded the same rows
over and over again. This has now been fixed.
The work around is to restart the MobiLink server.
================(Build #2156 - Engineering Case #563839)================
The SQL Passthrough feature was originally written as a plugin to the MobiLink
server in Java. A number of issues were found, including using extra database
connections, which needed to be addressed. The feature has now been re-written
as a core part of the MobiLink server, so it no longer requires a Java VM
on startup.
When SQL Passthrough was being used, ie. when there was at least one row
in the the ml_passthrough_script table, the MobiLink server could have used
twice the number of consolidated database connections than necessary, (ie.
up to twice the -w value). When creating these extra connections, the MobiLink
server would, during a synchronization, make another consolidated database
connection, perform some work, disconnect that connection, then resume the
synchronization. In other words, penalizing each synchronization with the
time/cost of connecting and disconnecting to the consolidated database. Besides
the performance and database connection penalties, these connects/disconnects
could also have made the MobiLink server reach OS socket limits faster, potentially
causing failures.
Most MobiLink clients (ie. dbmlsync, dbtools sync interface, dbmlsync ActiveX
integration component, and all UltraLite runtimes -- except UltraLiteJ, which
doesn't support SQL Passthrough) have been updated as part of this fix.
This change will cause newer clients to fail if run against an the 11.0.1
GA server. Thus MobiLink clients of version 11.0.1 2156 or later will require
a MobiLink server of version 11.0.1 2156 or later.
================(Build #2145 - Engineering Case #558108)================
Calling the function SQLGetTypeInfo() would have returned an incorrect AUTO_UNIQUE_VALUE
column value in the result set for non-numeric types. The value return would
have been 0, but according to the ODBC specification a NULL should have been
returned.
ODBC specificatrion for AUTO_UNIQUE_VALUE :
Whether the data type is autoincrementing:
SQL_TRUE if the data type is autoincrementing.
SQL_FALSE if the data type is not autoincrementing.
NULL is returned if the attribute is not applicable to the data type or
the data type is not numeric.
The behaviour has been corrected to follow the ODBC specification.
================(Build #2584 - Engineering Case #663991)================
Under some circumstances, queries with cached plans and queries containing
complex correlated subqueries may have returned incomplete results if they
were executed as parallel plans. This has been fixed.
Note, a workaround is to disable intra-query parallelism (set MAX_QUERY_TASKS=1).
================(Build #2509 - Engineering Case #642313)================
Execution of the statement "BACKUP DATABASE DIRECTORY '' TRANSACTION
LOG RENAME TRANSACTION LOG ONLY" would have left a gap in the offsets
between the renamed transaction log and the live transaction log. This would
have affected replication, synchronization and the ability to recover from
backups. This has been fixed.
================(Build #2272 - Engineering Case #580735)================
In rare circumstances, transaction log corruption could have occurred, or
the server could have haved assertion 100918 ('Invalid redo log page header'),
shortly after restarting a database. The probability of this happening on
any given database restart was approximately 1/pagesize (ie. for 4K pages,
the probability is approximately 0.0002). The corruption was likely to go
undetected, and the assertion was unlikely to fire in most cases. However,
sites using Mobilink or SQL Remote would have been alerted to the presence
of such corruption by errors occurring during synchronization. This has now
been fixed.
================(Build #2189 - Engineering Case #566207)================
The QAnywhere plug-in for Sybase Central now supports the connection retry
command line options for the Agent (see Engineering case 561067).
================(Build #2604 - Engineering Case #668833)================
The dbmlsyc command line option -qi prevents the tray icon or window from
being displayed. This behaviour is identical to the -qi option of the database
server. The option has existed since 11.0.1, but was not referenced in the
usage text or the documentation. The usage text has been corrected
================(Build #2184 - Engineering Case #561122)================
The .NET QAManagerBase class now supports ExceptionListener delegates, which
allows for applications to be notified of QAExceptions that occur while receiving
messages on the background thread.
The following are the relevant APIs:
/// <summary>
/// ExceptionListener delegate definition.
/// </summary>
/// <param name="ex">The exception that occurred.</param>
/// <param name="msg">The message that was received, or
null if the message
/// could not be constructed.</param>
public delegate void ExceptionListener( QAException ex, QAMessage msg );
/// <summary>
/// Sets an <see cref="ExceptionListener"/> delegate to
receive QAExceptions
/// when processing QAnywhere messages asynchronously.
/// </summary>
/// <param name="address">The address of messages.</param>
/// <param name="listener">The exception listener to register.</param>
public void SetExceptionListener( string address, ExceptionListener listener
);
In 10.0.x and later, the .NET and Java QAManagerBase class now supports
exception listeners.
The .NET and Java QAManagerBase class now supports a property, RECEIVER_INTERVAL,
that represents the maximum wait interval (in milliseconds) in the background
receiver thread for receiving messages. The default is 60000 milliseconds.
As with other QAManager properties, this property must be set before calling
an Open() method.
The .NET and Java QAManagerBase class now supports a ReOpen() method that
can be called in an ExceptionListener or MessageListener to re-establish
connections to the message store database. Following is the API description.
/// <summary>
/// Reopens the QAManagerBase. This re-establishes connections to the message
/// store, without releasing any resources. This method may called in a
/// message or exception listener, and in that case it is not necessary
to
/// call Start() again. This method simply executes Close() then Open()
if
/// not called in a listener, and in that case Start() must be called to
/// restart receiving of messages.
/// </summary>
/// <exception cref="iAnywhere.QAnywhere.Client.QAException">
/// if there is a problem reopening the manager.
/// </exception>
public void ReOpen();
================(Build #2167 - Engineering Case #561067)================
The QAnywhere Agent (qaagent) now attempts to reconnect to the message store
database when the connection is dropped.
Notes:
- The initial database connection will be retried a given number of times
if the first connection fails
- Command line options for connection retries and retry delay:
-cr <n> (n is the number of retries to connect after a failure)
-cd <n> (n is delay, in seconds, between retries)
- The defaults are 3 retries with a 10 second delay between retries
- If all retries fail, the QAnywhere Agent displays an error and waits
to be shut down
- If a database connection fails during operation, the QAnywhere Agent
will go through termination steps, including finalizing connections, terminating
threads and external processes, and then re-starts.
================(Build #2613 - Engineering Case #671955)================
The new property "ianywhere.qa.server.disableDeleteRules" has been
added to the QAnywhere server properties that can be specified in the configuration
file that can appear after the -m option of the MobiLink command. When set
to True (default is False), this property disables the message delete rules
and archiving processes that automatically run while the server is running.
This property would normally not be used, but it is useful, along with the
property "ianywhere.qa.server.disableNotifications", in the scenario
where more than one MobiLink server is running on a given consolidated database,
and the servers are not in a server farm configuration. In this case, the
MobiLink servers must be configured such that only one of the servers is
running message delete rules and the QAnywhere notifier.
================(Build #2410 - Engineering Case #559636)================
MobiLink clients, except UltraLiteJ, now support a new network protocol option
on Windows Mobile and desktop, 'network_adapter_name', which allows clients
to explicitly specify the name of the network adapter to be used to connect
to a MobiLink server. Example: "network_adapter_name=Serial on USB".
================(Build #2352 - Engineering Case #573222)================
Support for FIPS 140-2 certified encryption has now been added to 64-bit
Windows for UltraLite (except UltraLiteJ) and MobiLink clients .
If the "FIPS-approved Strong Encryption" feature is not already
installed, proceed as follows after applying the EBF:
- From Add & Remove Programs, select SQL Anywhere 11 and click the Change
button.
- Select the Add option and enter the Add-on Registration Key and click
Next.
- In the dialog, ensure that the "FIPS-approved Strong Encryption"
feature is selected and proceed.
If the "FIPS-approved Strong Encryption" feature is already installed,
proceed as follows after applying the EBF:
- From Add & Remove Programs, select SQL Anywhere 11 and click the Change
button.
- Select the Modify option and de-select the "FIPS-approved Strong
Encryption" feature, to temporarily remove it, and proceed.
- Again from Add & Remove Programs, select SQL Anywhere 11 and click
the Change button.
- Select the Modify option and select the "FIPS-approved Strong Encryption"
feature and proceed.
================(Build #2249 - Engineering Case #571810)================
MobiLink clients (except for UltraLiteJ) now cache the host socket address
to avoid extra calls to socket methods, such as getaddrinfo, inet_addr, and
gethostbyname, for non-persistent HTTP and HTTPS synchronizations.
================(Build #2241 - Engineering Case #571233)================
When the -pi option 'ping MobiLink server' was used on the MobiLink client
(dbmlsync) command line, dbmlsync would have returne an exit code of 0 (indicating
success), even if it was unable to contact the Mobilink server. This has
been fixed, and a non-zero exit code will now be returned in this case.
================(Build #2586 - Engineering Case #665140)================
For MobiLink clients that support ECC TLS, support has now been added for
RFC 4492 and 256-bit AES ECC cipher suites as well, in addition to the Draft
3 128-bit AES ECC cipher suite they previously supported.
================(Build #2450 - Engineering Case #632359)================
For 11.0.1, ECC curve support for MobiLink end-to-end encryption has been
reduced to the same 7 ECC curves supported by the createcert and createkey
utilities and by SA's TLS support.
For 12.0.0, ECC curve support for end-to-end encryption, the createcert
and createkey utilities, and for the TLS protocol for both MobiLink and SA,
has been extended to support the 15 curves recommended by NIST:
sect163k1 sect283k1 sect571k1 secp256r1
sect163r2 sect283r1 sect571r1 secp384r1
sect233k1 sect409k1 secp192r1 secp521r1
sect233r1 sect409r1 secp224r1
================(Build #2426 - Engineering Case #626480)================
An extension to the TLS protocol for session renegotiation has been made
to fix a recently discovered vulnerability (RFC 5746). Although SQL Anywhere
software is not directly vulnerable, third-party servers that it communicates
through may be vulnerable. SA clients now support this TLS extension which
will allow vulnerable third-party servers to be secured.
================(Build #2412 - Engineering Case #623106)================
New http, https and oe stream options have been added to the MobiLink server
that will cause it to print additional errors, analogous to the errors printed
by the -vf option.
Usage:
-x http(...;log_bad_request={yes|no})
-x https(...;log_bad_request={yes|no})
-x oe(...;log_bad_request={yes|no})
The default value for these noew options is "no".
If log_bad_request is enabled and a request disconnects before the server
receives a complete set of HTTP headers, the server will print these errors:
[-10117] Stream Error: Failed reading an incomplete HTTP request
[-10117] Stream Error: This connection will be abandoned because of previous
errors
If log_bad_request is enabled and a request contains an unknown User-Agent
or unknown request type, the server will print these errors:
[-10117] Stream Error: Unknown HTTP User-Agent or request type
[-10117] Stream Error: This connection will be abandoned because of previous
errors
This option is most useful when debugging network issues. For example,
you can connect to the ML server using a web browser on the remote device
and if the device can reach the server, then these errors will be printed.
================(Build #2375 - Engineering Case #607881)================
The MobiLink server would have reported error -10152 if a Java class loaded
for scripting contained overloaded methods, and would have failed with an
AmbiguousMatchException if a .NET class contained overloaded methods. This
restriction has been lifted. This is most useful for the authenticate_parameters
script, as now remotes can send different numbers of authentication parameters
and the MobiLink server will choose the method that most closely matches
those parameters.
For example, suppose a class Test exists:
public class Test {
public static String auth( InOutInteger status,
String user_name,
String p1,
String p2 )
{
return "insert into j_authparm_T2 (pk, c1, c2, c3) values (?,?,?,?)";
}
public static String auth( InOutInteger status,
String user_name,
String p1,
String p2,
String p3 )
{
return "insert into j_authparm_T2 (pk, c1, c2, c3, c4) values (?,?,?,?,?)";
}
}
Then the auth method can be registered as the script for the authenticate_parameters
event:
call ml_add_java_connection_script( 'the version', 'authenticate_parameters',
'Test.auth' )
and invoking dbmlsync with different -ap switches will give different behaviour:
"-ap parm1,parm2" will call the first 'auth' overload
"-ap parm1,parm2,parm3" will call the second 'auth' overload
"-ap parm1" will print the error, "[-10362] No overload matching
'auth(ianywhere.ml.script.MLInOutInteger, java.lang.String, java.lang.String)'
was found in class 'Test'", because there are not enough parameters
to call any of the overloads
"-ap parm1,parm2,parm3,parm4" will invoke the second 'auth' overload,
but the returned SQL will cause error "[-10094] Expecting 3 authentication
parameter(s) from client, but received 4 for script insert into j_authparm_T2
(pk, c1, c2, c3, c4) values (?,?,?,?,?)" because the MobiLink server
will accept a Java or .NET authentication_parameters script if it has the
same number of parameters or fewer, but SQL authentication_parameters scripts
must match the exact number of parameters. Some future version of the server
may place that restriction on Java and .NET authentication_parameters scripts
as well.
================(Build #2352 - Engineering Case #609449)================
FIPS 140-2 certified encryption is now supported by the MobiLink server on
64-bit (x64) Windows.
If the "FIPS-approved Strong Encryption" feature is not already
installed, proceed as follows after applying the EBF:
- From Add & Remove Programs, select SQL Anywhere 11 and click the Change
button.
- Select the Add option and enter the Add-on Registration Key and click
Next.
- In the dialog, ensure that the "FIPS-approved Strong Encryption"
feature is selected and proceed.
If the "FIPS-approved Strong Encryption" feature is already installed,
proceed as follows after applying the EBF:
- From Add & Remove Programs, select SQL Anywhere 11 and click the Change
button.
- Select the Modify option and de-select the "FIPS-approved Strong
Encryption" feature, to temporarily remove it, and proceed.
- Again from Add & Remove Programs, select SQL Anywhere 11 and click
the Change button.
- Select the Modify option and select the "FIPS-approved Strong Encryption"
feature and proceed.
================(Build #2144 - Engineering Case #558085)================
The MobiLink server now supports two new command options,
-vR show the remote ID in each logging message
-vU show the ML user name in each logging message
When both -vR and -vU are specified, the MobiLink server will add the remote
ID and the MobiLink user to each message logged:
yyyy-mm-dd hh:mm:ss. <sync_id> ({remote_id},{user_name})
When started with -vR and without -vU, the prefix will be just the remote_id:
yyyy-mm-dd hh:mm:ss. <sync_id> (remote_id,)
and the MobiLink user name will be empty. When started with -vU and without
-vR, the
prefix will be just the user name:
yyyy-mm-dd hh:mm:ss. <sync_id> (,user_name)
and the remote ID will be empty.
The new feature may be useful for MobiLink users who are running the MobiLink
server with the command options -on or -os, as the logging messages for a
synchronization can span multiple MobiLink server logging files, which makes
it is hard to find out the remote ID and MobiLink user name for a given sync
ID from such logs. This extra logging information will only apply to the
synchronization threads. For the main thread of the MobiLink
server, the logging messages will still contain the following prefix,
yyyy-mm-dd hh:mm:ss. <Main>
because there is no remote ID or MobiLink user name for the main thread.
These two command line options will not be affected by the -v+ option, that
is, the MobiLink server will not add the remote ID or the ML user name into
its logging messages, even if the -v+ option is used. Therefore, the description
for the -v+ option
has been changed to - "show all verbose logging specified with lower
case letters".
================(Build #2604 - Engineering Case #668832)================
The dblsn command line option -qi prevents the tray icon or window from being
displayed. This behaviour is identical to the -qi option of the database
server. The option has existed since 11.0.1, but was not referenced in the
usage text or the documentation. The usage text has been corrected
================(Build #2586 - Engineering Case #666801)================
The Redirector for Apache on Windows now supports Apache 2.2.15. This newer
webserver offers enhanced security.
================(Build #2267 - Engineering Case #580574)================
The Apache Redirector is now available for Apache 2.2 on Linux. The new file
is named mod_iaredirect.so, and is located in <install-dir>/mobilink/redirector/apache/v22.
================(Build #2138 - Engineering Case #584322)================
The following new features have been added to the iAnywhere Solutions ODBC
driver for Oracle:
1) In order to determine if a stored procedure returns a result set, or
if a procedure uses Oracle VARRAYs, the iAnywhere Solutions Oracle ODBC driver
needs to describe the stored procedure through Oracle OCI functions. The
driver now provides an extra connection parameter, ProcOwner (long form)
or POwner (short form), which is used to by tyen driver to describe all the
stored procedures invoked by the application. This parameter can be given
as followis:
-c "uid=...;pwd=...;procowner=my_procedure_owner;..."
2) The iAnywhere Solutions ODBC driver for Oracle now supports VARRAYs used
by packaged procedures.
================(Build #2598 - Engineering Case #667520)================
A new command line option 'uninstallall' (or 'ua') has been added to SetupVSPackage.exe.
When specified, the 'uninstallall' option will cause SetupVSPackage to remove
all versions of SQL Anywhere assemblies from the Global Assembly Cache.
For example:
SetupVSPackage.exe /ua
================(Build #2476 - Engineering Case #637146)================
Two xml mapping files have been added to support SQL Server 2008 Integration
Services:
- MSSqlToSA.xml --- mapping SQL Server 2008 data types to SA data types.
- SAToMSSql10.xml --- mapping SA data types to SQL Server 2008 data types.
These files will be installed to "%SA%\Assembly\V2" folders. The
utility SetupVSPackage.exe will copy them to, or remove them from, the "%SQL
Server 2008 Dir%\DTS\Binn" folder.
================(Build #2456 - Engineering Case #633600)================
Some Visual Studio integration related problems were not handled by SetupVSPackage.exe,
but were problems caused by SA installer when installing the SA ADO.NET provider
and the SA Visual Studio Integration Package. Some of these problems were
1. Incorrect machine.config file.
2. SA ADO.NET provider assemblies were not added to GAC.
3. SA ADO.NET provider assemblies did not show up in Visual Studio Add Reference
dialogbox.
4. Visual Studio failed to create DataSets or Entity Framework Models using
SA data sources.
Re-installation of SQL Anywhere was usually required to fix these problems.
Now all Visual Studio integration related code has been implemented in SetupVSPackage.exe,
and any Visual Studio integration problem should be fixed by running SetupVSPackage.
It will perform the following tasks:
1. Add / Remove assemblies of SA ADO.NET provider and integration package
to / from GAC.
2. Register or unregister SA ADO.NET provider in machine.config.
3. Create registry keys for SA integration package
4. Create registry keys for Visual Studio Add Reference dialogbox.
5. Copy / Remove SSDLToSA12.tt to / from Visual Studio 2010 folder (%VS_DIR%\Common7\IDE\Extensions\Microsoft\Entity
Framework Tools\DBGen).
6. Register or unregister SA ADO.NET provider in %SQL Server 2008 DIR%\100\DTS\ProviderDescriptors\ProviderDescriptors.xml
which is used by SQL Server Integration Service.
7. Setup Visual Studio IDE for SA integration package.
SetupVSPackage.exe is executed by the SQL Anywhere installer when installing
or uninstalling SQL Anywhere, but SetupVSPackage.exe can be run separately.
Two versions of SetupVSPackage.exe will be installed:
1. %SQLANY%\Assembly\V4\SetupVSPackage.exe - This version is built using
.NET Framework 4, this version should be used if .NET Framework 4 is installed.
2. %SQLANY%\Assembly\V2\SetupVSPackage.exe - This version is built using
.NET Framework 2, this version should be used if .NET Framework 4 is not
installed.
A performance issue when running SetupVSPackage.exe for Visual Studio 2008
and 2010 has also been fixed.
================(Build #2438 - Engineering Case #629284)================
The Visual Studio "Add Connection" wizard will display SQL Anywhere
and Adaptive Server Anywhere ODBC Data Source names in the pick list when
the SQL Anywhere .NET provider is used for the connection. SQL Anywhere integration
with Visual Studio has been improved to also show Sybase IQ ODBC Data Source
names in the pick list.
================(Build #2420 - Engineering Case #624809)================
Support for .NET Framework 4 and Visual Studio 2010 has now been added to
the SQL Anywhere ADO.Net provider. Three versions of the provider are installed.
One for .NET 2.0 / 3.0, one for .NET 3.5, and one for .NET 4.0. Each version
contains both assembly and policy files.
Here is a list of the files:
(1) .NET 2.0 / 3.0
...\Assembly\V2\iAnywhere.Data.SQLAnywhere.config
...\Assembly\V2\iAnywhere.Data.SQLAnywhere.dll
...\Assembly\V2\iAnywhere.Data.SQLAnywhere.xml
...\Assembly\V2\policy.11.0.iAnywhere.Data.SQLAnywhere.dll
(2) .NET 3.5
...\Assembly\V3.5\iAnywhere.Data.SQLAnywhere.v3.5.config
...\Assembly\V3.5\iAnywhere.Data.SQLAnywhere.v3.5.dll
...\Assembly\V3.5\iAnywhere.Data.SQLAnywhere.v3.5.xml
...\Assembly\V3.5\policy.11.0.iAnywhere.Data.SQLAnywhere.v3.5.dll
(3) .NET 4.0
...\Assembly\V4\iAnywhere.Data.SQLAnywhere.v4.0.config
...\Assembly\V4\iAnywhere.Data.SQLAnywhere.v4.0.dll
...\Assembly\V4\iAnywhere.Data.SQLAnywhere.v4.0.xml
...\Assembly\V4\policy.11.0.iAnywhere.Data.SQLAnywhere.v4.0.dll
...\Assembly\V4\SSDLToSA11.tt
The iAnywhere.Data.SQLAnywhere assembly reference can be added in Visual
Studio with the Add Reference dialog. Use the one depending on the .NET project
as follows:
iAnywhere.Data.SQLAnywhere for .NET 2 should be used for .NET 2.0 /
3.0 projects
iAnywhere.Data.SQLAnywhere for .NET 3.5 should be used for .NET 3.5
projects
iAnywhere.Data.SQLAnywhere for .NET 4 should be used for .NET 4 projects
SSDLToSA11.tt is used for generating database schema DDL for Entity Data
Models. The SQL Anywhere installer copies this file to the Visual Studio
2010 directory. The DDL Generation property should be set to this file when
generating database schema DDL for Entity Data Models.
================(Build #2564 - Engineering Case #659363)================
The Timeout, SendBufferSize, and ReceiveBufferSize TCP options now have upper
limits. Values specified above these limits will result in connection failure
(-832). The limits are:
Timeout: 3600 seconds
SendBufferSize: 1048576 bytes (1 MB)
ReceiveBufferSize: 1048576 bytes (1 MB)
================(Build #2424 - Engineering Case #625011)================
The iAnywhere and SQL Anywhere JDBC drivers only supported the PreparedStatement
methods addBatch() and executeBatch(). Support has now been added for the
Statement methods addBatch(), clearBatch() and executeBatch(). Due to the
fact that the JDBC specification is unclear on the behaviour of Statement.executeBatch(),
the following notes should be considered when using this method with these
JDBC drivers:
1) Processing of the batch stops immediately upon encountering a SQL exception
or result set. If processing of the batch stops, then a BatchUpdateException
will be thrown by Statement.executeBatch(). Calling getUpdateCounts() on
the BatchUpdateException will return an integer array of row counts where
the set of counts prior to the batch failure will contain a valid non-negative
update count; while all counts at the point of the batch failure and beyond
will contain a -1. Casting the BatchUpdateCount to a SQLException will provide
additional details as to why batch processing was stopped.
2) The batch is only cleared when Statement.clearBatch() is explicitly called.
As a result, calling Statement.executeBatch() repeatedly will re-execute
the batch over and over again. In addition, calling Statement.execute( sql
) or Statement.executeQuery( sql ) will correctly execute the statement with
the "sql" argument, but will not clear the underlying batch. Hence,
calling Statement.executeBatch() followed by Statement.execute( sql ) followed
by Statement.executeBatch() will execute the set of batched statements, then
execute "sql" and then execute the set of batched statements again.
================(Build #2128 - Engineering Case #553310)================
An application that uses the iAnywhere JDBC driver must now have the jodbc.jar
built with the same build number as the dbjodbc and mljodbc shared objects.
If the jar and shared objects are out of sync, a SQLException will be thrown
at connect time and the connection will be refused.
================(Build #2112 - Engineering Case #549932)================
The iAnywhere JDBC driver has supported the PreparedStatement.addBatch()
and PreparedStatement.executeBatch() methods for quite some time now, but,
these methods were only supported for INSERT statements. These methods will
now also be supported for UDATE and DELETE statements, provided the underlying
connection is to an SA server. If the underlying connection is to a non-SA
server, then these methods will still only be supported for INSERT.
================(Build #2490 - Engineering Case #638755)================
When an ODBC application made a SQLTables() call, the TABLE_TYPE column in
the result set identified materialized views as MATERIALIZED VIEW. While
doing so was not against the ODBC specification, there was nevertheless a
problem with applications like Microsoft Access and Crystal Reports, which
filter out anything that is not marked as TABLE, VIEW, SYSTEM TABLE, ALIAS,
SYNONYM, GLOBAL TEMPORARY or LOCAL TEMPORARY. Therefore, the TABLE_TYPE value
returned for materialized views has been changed to be VIEW.
In addition, a new connection parameter has been added to ODBC which allows
a specific string to be defined that is returned in the SQLTables() result
set for materialized views. This new connection parameter is called MATVIEW,
and is a string that will be returned in the TABLE_TYPE column for materialized
views.
For example, to have the SQLTables() function return materialized views
as type TABLE, connect as follows:
uid=dba;pwd=sql;eng=...;matview=table
This new option can be used to override this default and return to the previous
behaviour. The same string is also used when SQLTables() is called with an
explicit TableType filter.
================(Build #2328 - Engineering Case #594888)================
The performance of ODBC metadata functions, such as SQLPrimaryKeys, SQLTables,
and SQLColumns, has been improved for case-sensitive databases. This performance
improvement will not occur for case-sensitive databases if SQLSetStmtAttr
is called to set the SQL_ATTR_METADATA_ID attribute to SQL_TRUE. However,
by default, this attribute is set to SQL_FALSE. When set to SQL_FALSE, case-sensitive
databases will now enjoy the same performance as case-insensitive databases.
Please note that when the SQL_ATTR_METADATA_ID attribute is set to SQL_TRUE,
the string arguments to metadata functions are treated as identifiers, not
strings (or patterns like "co%"). Identifiers can be delimited,
in which case leading and trailing spaces are removed. Identifiers need not
be delimited, in which case trailing spaces are removed.
================(Build #2266 - Engineering Case #578617)================
On Unix systems, an ANSI-only (no wide call support) ODBC driver is now available.
The name of the driver is libdbodbcansi11_r. Only a threaded variant is provided.
On Mac OS X, in addition to the dylib, the driver is also available in bundle
form (dbodbcansi11_r.bundle). Certain frameworks, such as Real Basic, do
not work with the dylib and require the bundle. The regular SQL Anywhere
ODBC driver treats SQLWCHAR strings as UTF-16 strings. Starting in SQL Anywhere
10, when Unicode support in the Unix ODBC drivers was first introduced, the
driver could not have been used with some ODBC driver managers, such as iODBC,
which treated SQLWCHAR strings as UTF-32 strings. When dealing with Unicode-enabled
drivers, these driver managers would translate narrow calls from the application
to wide calls into the driver. An ANSI-only driver gets around this
behaviour, allowing the driver to be used with such driver managers, as
long as the application does not make any wide calls. Wide calls through
iODBC, or any other driver manager with similar semantics, remain unsupported.
================(Build #2514 - Engineering Case #645959)================
Microsoft SQL Server has introduced two data types DBTYPE_DBTIME2 and DBTYPE_DBTIMESTAMPOFFSET
that are not part of the OLE DB specification. Support for conversions between
these two types and DBTYPE_STR, DBTYPE_WSTR, DBTYPE_DBDATE, DBTYPE_DBTIME,
and DBTYPE_DBTIMESTAMP has now been added to the SQL Anywhere OLE DB provider.
DBTYPE_DBTIME2 differs from DBTYPE_DBTIME in that fractional seconds are
included. The type corresponds to the Microsoft SQL Server TIME data type.
DBTYPE_TIMESTAMPOFFSET adds support for a timezone offset (hours/minutes).
The type corresponds to the Microsoft SQL Server DATETIMEOFFSET data type.
================(Build #2382 - Engineering Case #674702)================
Assertion failure messages now include a database name where available.
================(Build #2558 - Engineering Case #657471)================
The PHP external environment and the PHP driver now support PHP versions
5.3.3, 5.3.4, and 5.3.5.
================(Build #2272 - Engineering Case #580788)================
The EBF installers for Linux are now capable of installing FIPS components.
To initially install the components, the setup script must be invoked with
the -regkey (alias -k) command line option, and be passed a registration
key that entitles the installation of the FIPS componenents.
e.g., ./setup -k <FIPS registration key>
or ./setup -regkey <FIPS registration key>
It is not possible to specify the registration key through the EBF Installer
UI itself. Subsequent invocations of the EBF install will then update previously
installed FIPS components without needing to specify a registration key.
================(Build #2166 - Engineering Case #563352)================
Prebuilt binary libraries for PHP 5.2.8 have now been added.
================(Build #2561 - Engineering Case #657712)================
Additional information is now saved for graphical and long plans. This additional
information includes:
- Known values for expressions are now dumped in the plans. For example,
a stored procedure parameter known at the optimization time is dumped as
'parm1[100]' if its name is 'parm1' and its known value is '100'.
- For long plans generated by the application profiling, extra information
related to the optimization process is now dumped. For example, 'Plan [ Total
Cost Estimate: 3.5657, Costed Best Plans: 1, Costed Plans: 13, Optimization
Time: 0.074541, Estimated Cache Pages: 590 ]' This type of information is
already present for long plans generated by calling the explanation() function.
- Information related to the cached plan of a statement is now dumped in
its long plan.
- Predicates used to generate fence posts for a partial index scan are now
dumped in the long plans generated by the application profiling. This type
of information is already present for long plans generated by calling the
explanation() function.
Also, graphical plans with statistics saved during tracing did not actually
contain any statistics. This has been fixed.
================(Build #2526 - Engineering Case #649437)================
Version 9.0.x has an optimization for a very large number of WHERE predicates
that are in Disjunctive Normal Form (DNF), which was not implemented starting
with version 10.0.0.
For example:
WHERE
(T.A1 = c11 and T.A2 = c12 and ... and T.Ak =c1k) OR
.....
(T.A1 = cN1 and T.A2 = cN2 and .... and T.Ak =cNk)
AND
(other predicates)
The values for c11, c12, ..., cNk are constants, and N is large. The following
sargable IN predicates were generated from the original predicates:
T.A1 IN {c11,c21, ..., cN1} AND
...
T.Ak IN { c1k, ..., cNk}
If there existed an index on table T with a prefix on any combination of
the columns T.A1, ..., T.Ak, then a partial index scan using the sargable
IN predicates could have been chosen in the best access plan. For example,
if an index 'idx1' existed on T < A2, Ak > then the partial index scan
[ {c12, ..., cN2} JNL {c1k, ..., cNk} JNL T <idx1>] may have been used
in the best access plan. The original predicate would still have been applied
after the index scan as a postfilter.
This optimization was not implemented starting with SA 10.0.0, as multiindex
scans introduced in SA 11.0.0 and enhanced in SA 11.0.1 provided more general
access methods using any combination of UNION and INTERSECTION of indexes.
Multiindex scans performed better than the above optimization for small to
medium size DNF predicates. However, multiindex scans can be inefficient
when the number of predicates is large, for example, DNF predicates having
1,000 or more terms. This new feature addresses, in a very general way,
these extreme cases and other cases when multiindex index scans use the same
index. A multicolumn inmemory table is built with the exact combinations
used in a DNF term, and this table is joined with the index scan. In the
example above, if an index 'idx2' on T<A1, A2,..., Ak> exists, the
access method
[{(c11,c12,...,c1k), (c21,c22,...,c2k),..., (cN1, cN2, ..., cNk)} JNL T<idx2>]
will be built.
Prior to this change the following multiindex scan was considered:
T<idx2: (c11,c12,...,c1k)> UNION T<idx2: (c21,c22,...,c2k)>
UNION ... UNION T<idx2: (cN1,cN2,...,cNk)>
This multiindex scan could have been inefficient if N was greater than 1,000.
================(Build #2482 - Engineering Case #625314)================
It is now possible to use the Script Execution utility (dbrunsql) to reload
a database without displaying the GUI, but still log output messages (results)
to a file. Previously, if the -q option was not used the dbrunsql gui was
shown regardless of the -g setting. Now, the -q and -g switches work together.
If -g- is specified, the GUI will not be shown except for error messages.
The -q option now only controls if data and warning messages shall be output
to the GUI, the console, and/or an output file.
================(Build #2459 - Engineering Case #629411)================
The database option UUID_HAS_HYPHENS has been re-added. It can have the values
On (default) and Off. If a uniqueidentifer value is converted to a string,
then the string contains hyphens if the option value is On.
================(Build #2414 - Engineering Case #623610)================
Processor topology detection for x86/x64 processors has been improved to
detect new SMT processors correctly (ie processors with multiple threads
per core that are not the older "hyperthread" implementation).
Previously, a quad-core i7 (for example) with two threads per core would
be detected as 8 cores rather than 4 cores with 2 threads per core. The algorithm
for distributing database server threads among logical processors when using
less than the maximum concurrency permitted (via the database server -gtc
switch) now correctly takes the 3-level chip/core/thread topology into consideration.
Generally, this change does not affect licensing since association of a logical
processor with the actual chip containing each logical processor was still
correct in the old code with the possible exception of some newer Intel 6-core
processors.
On Mac OS X where the operating system does not provide interfaces to control
processor affinity, exact processor topology cannot be determined, so SQL
Anywhere treats each logical processor as a separate package or "socket".
On multicore and SMT processors, OSX users should purchase the correct license
for the hardware they are using, but install a license that will allow the
correct amount of concurrency. For example on a quad-core i7 with two threads
per core, purchase a license for 1 CPU "socket" but install a license
for 8 cpu "sockets" since each processor thread will be treated
as a separate CPU socket.
Feature tracking code has also been changed so that the 3-level topology,
CPU brand string and CPU info registers (which do not form a unique machine
identifier) are reported when crash reports are sent to Sybase.
================(Build #2413 - Engineering Case #622024)================
If an application attempted to perform an integrated login from one Windows
machine to a SQL Anywhere database server running on a different Windows
machine; and the machine that the database server was running on was not
the domain controller; and the Windows userid that the application was using
was not explicitly mapped in the database; and the application was expecting
that the server would instead map the application's Windows userid to a Windows
user group on the Domain Controller, then there was a chance the integrated
login would fail to map the Windows group.
For example:
1) suppose the domain controller was Windows machine DC, and
2) suppose the application was running on Windows machine App with Windows
userid AppUser, and
3) suppose the database server was running on Windows machine SAServ with
Windows userid ServUser, and
4) suppose the domain controller had a Windows user group GRP of which AppUser
was a member, and
5) suppose the database did not grant explicit integrated login privileges
to AppUser but instead had granted integrated login privileges to GRP instead,
then there was a chance that the application would fail to establish an
integrated login to the db userid that GRP was mapped to. This problem has
now been fixed.
================(Build #2412 - Engineering Case #560044)================
In some cases, an error was generated for expressions that contained only
values that were known at open time.
For example, the following generated a "division by zero" error:
select if 1=0 then 1/0 else 42 endif val
This problem occurred because the expression '1/0' was evaluated as part
of building the access plan for the query. Constant expression trees were
evaluated at open time in a bottom-up fashion so that the value can be used
at execution time (avoiding multiple evaluations and supporting optimizations).
In some cases, the expression was not actually needed, as in the above example
with an IF expression. In these cases, the constant folding process could
have generated an error that would not have been returned if the constant
literals were replaced with field references.
This has been changed. Errors generated during constant folding are no longer
returned at open time. Instead, the constant expression tree is left in its
original structure and evaluated at execution time if the value is needed.
This execution-time evaluation will generate the related error if the value
is actually needed.
================(Build #2399 - Engineering Case #619595)================
The SQL Anywhere Optimizer now has a new source type for the selectivity
estimations of atomic predicates of the form "T.X = R.X", namely
JOIN. A selectivity estimation has the "JOIN" source type if it
is computed using (1) Primary Key - Foreign Key referential integrity constraints;
(2) unique constraints; (3) join histograms. The SQL Anywhere Optimizer uses
selectivity estimation sources when redundant predicates are present in a
query. Different sources have different qualities, hence predicates with
better sources are used when competing predicates are present.
================(Build #2344 - Engineering Case #605668)================
If an application that was connected via jConnect or Open Client attempted
to insert or retrieve a datetime or time value, then the date portion of
the value was limited to January 1, 1753 or later, and the time portion was
restricted a precision of 1/300th of a second. Now, if an application uses
newer versions of jConnect and Open Client, then the date portion of datetime
values will span the full range from 0001-01-01 to 9999-12-31, and the time
portion will now be handled in microsecond precision.
================(Build #2256 - Engineering Case #575760)================
When there is only one connection, the maximum number of prefetch rows has
been increased to 10000. If there is more than one connection, the maximum
number of prefetch rows remains unchanged at 1000.
Performance may improve when all of the following conditions are met:
- an application has only one connection
- fetching a result set with many thousands of rows
- each row in the result set has small number of columns
- the data size of the fetched columns is small
- prefetch is enabled
- the connection is over TCP/IP (shared memory connections are not likely
to see a significant performance improvement)
================(Build #2250 - Engineering Case #570650)================
Using the TRANSACTION LOG TRUNCATE clause on the BACKUP DATABASE statement
could have lead to the error "Assertion failed: 100910 Error renaming
transaction log file before deleting it." This would have occurred
when the user under which the server was running did not have delete permissions
on the directory where the transaction log was located. Now, the server no
longer deletes and re-creates the transaction log file, instead it truncates
the file to one page. This should also prevent any interaction with virus
scanners and disk defragmenters, which was often the case when files were
being created.
================(Build #2236 - Engineering Case #571620)================
OEMs now have the ability to prevent users from saving connection passwords
with favorites. To do this, add the (new) "allowPasswordsInFavorites"
directive to the "dbisql" section of the OEM.INI file:
[dbisql]
allowPasswordsInFavorites=false
Allowable values for this directive are "true" and "false".
The default is "true". If this directive is added to OEM.INI, and
its value is "false", the visible change is in the "Add to
Favorites" window: the checkbox called "Save the connection password"
will not be visible, and will be assumed to be unselected.
================(Build #2195 - Engineering Case #566651)================
A SERVICE may invoke a procedure that explicitly sets the 'Connection' and
'Content-Length' HTTP response headers using the SA_SET_HTTP_HEADER system
procedure. The setting of the 'Content-Length' was ignored, and the setting
of 'Connection:close' implicitly disabled chunked-mode transfer encoding.
Changes have been made to provide greater control over SQLAnywhere HTTP server
responses. The following is a summary of the new behaviour:
Client is HTTP/1.0:
The server does not support Keep-Alive and Chunk-mode operation for this
HTTP version.
By default the server never sets the 'Transfer-Encoding' header and always
sets 'Connection: close' header, shutting down the connection once the response
has been sent. A SERVICE procedure may set the 'Content-Length' header but
setting the 'Connection' header is ignored.
Client is HTTP/1.1:
By default the server responses use chunked-mode transfer encoding and automatically
set the 'Transfer-Encoding: chunked' header. If the SERVICE procedure explicitly
sets a 'Content-Length' header to some value, then the 'Content-Length' header
is sent in place of the 'Transfer-Encoding' header and the response body
is not chunk-mode encoded. Note: It is an error for a SERVICE procedure
to set both a 'Content-Length' and 'Transfer-Encoding' header.
The server will assume 'Connection: keep-alive' if the client does not send
a 'Connection' request header. If a client explicitly sends a 'Connection:
close' request header and/or the SERVER procedure explicitly sets 'Connection:
close' the server will shutdown the connection once the response has been
sent.
Setting Content-Length
In most cases data will need to be buffered in order to calculate the Content-Length.
Therefore, it is recommended to use chunk-mode transfer encoding whenever
possible. If 'Content-Length' must be set, then care must be taken to ensure
that the result-set is not character set translated when the response is
composed. It is recommended that the 'CharsetConversion' http option is
set to off when returning textual data. Also, setting 'Content-Length' should
only be done within a TYPE 'RAW' SERVICE since some services (i.e. 'HTML',
'JSON') add content to the response.
A check has been added to ensure that the actual length of the response
matches the value of 'Content-Length' header. If the values do not match
then the server will shutdown the connection, once the response has been
sent, regardless of whether or not a 'Connection: keep-alive' response header
has been sent.
================(Build #2167 - Engineering Case #563394)================
Execution of LOAD TABLE statement will now use asynchronous IO in order to
improve performance. Actual performance gains will vary depending on hardware
and database configuration but tests have shown an approximate doubling of
performance. Asynchronous IO is only used when accessing a local data file
(not a client file, etc).
================(Build #2148 - Engineering Case #559813)================
The server would have reported the number of processors detected and some
imposed limits. The messages have been changed so that they will now report:
- number of processors detected (changed format)
- processor limits imposed by Edition, licenses purchased, and -gt option
- max number of processors that will be used
Also, the Edition limit that is imposed during licensing is now also imposed
by the server itself.
For some Unix systems, the number of processors used can not be limited.
If the number to be used exceeds the per-processor license limitation, an
additional message is reported, and is unchanged from previous versions.
================(Build #2144 - Engineering Case #558084)================
A new tailoring of the Japanese UCA collation has been added which defines
primary-level differences between all Hiragana letters, as well as primary-level
differences between all Katakana letters. This new tailoring will permit
correct equality comparisons of Hiragana and Katakana letters in case-insensitive
collations. The new collation is used by specifying a collation of UCA(locale=ja;sorttype=direct;...).
================(Build #2142 - Engineering Case #557527)================
A SQL Anywhere HTTP client function was only able to return a varchar data
type. Support has now been added to the HTTP client so that it can also be
defined to return binary, varbinary or long binary data types, i.e.:
CREATE function client() RETURNS long binary URL 'http://localhost/image_service/...'
TYPE 'HTTP:GET'
Note, this change only extends the semantic meaning of the returned value,
declaring the return data type as binary does not change the behaviour at
the transport level. Textual data may still be converted to the database
character set based on Content-Type HTTP header or SOAP envelope encoding
criteria.
================(Build #2141 - Engineering Case #557363)================
By default (or with SET 'HTTP(CH=auto)') an SA HTTP client procedure would
have sent its HTTP request using chunk mode transfer encoding when posting
data that was greater than 2048 bytes. If the server rejected the request
with a 501 "Not Implemented" or 505 "HTTP Version Not Supported"
status, the procedure would have automatically re-issued the request without
using chunk transfer encoding. When in default mode, an SA client would
not have used chunk transfer encoding when posting data that was less than
2048 bytes in length. This has now been changed so that the data byte limit
is now 8196 bytes, from 2048 bytes, and the status 411 "Length Required"
has been added to its criteria for re-issuing the request without using chunk
mode transfer encoding.
================(Build #2139 - Engineering Case #555976)================
With the release of SA 10.0.0, identifiers were restricted such that they
could no longer include double quotes or backslashes. Unfortunately, if an
application wants to create an externlogin to a remote SQL server using secure
logins, then the remote login needs to be specified in the form user\domain.
As a result, the remote login specification of a create externlogin statement
has now been extended to accept both identifiers and strings. Note that no
catalog changes have been made; hence, the remote login specification is
still restricted to 128 bytes.
================(Build #2124 - Engineering Case #552503)================
SQL statements which don't contain Transact-SQL OUTER JOINs, OUTER JOINs,
KEY JOINs, or NATURAL JOINs will now skip some of the optimizations implemented
in the server, which will improve the DESCRIBE time.
================(Build #2121 - Engineering Case #551700)================
Column widths in the debugger Details panel were not persistent. This has
been fixed so that column widths are saved in user preferences.
================(Build #2572 - Engineering Case #662054)================
When deploying, the directory used by the Interactive SQL utility, Sybase
Central, the Console utility, and the MobiLink Monitor, can now be specified.
To do this, an OEM.ini file must be deployed along with these utilities.
The file must contain the following lines:
[preferences]
directory={preferences files directory|
where "preferences_files_directory" is a fully-qualified directory
name, e.g. "c:\work\prefs". The directory name should not end
in a separator (backslash on Windows; forward slash on Unix and Mac OS X).
Preferences files include:
.isqlPreferences12_32
.isqlPreferences12_64
.isqlHistory12
.jlogon12
.textCompleter12
.SybaseCentralEditor610
.scUserPreferences610_32
.scUserPreferences610_64
among others.
================(Build #2520 - Engineering Case #641296)================
When choosing to localize with the Deployment wizard, the Installation Wizard
would have appeared localized, but Language was not set in the registry on
the target machine. This has been corrected so that the SQL Anywhere Language
registry entry is now set to match the deployment language.
================(Build #2314 - Engineering Case #539772)================
Installs created by the SQL Anywhere Deployment wizard would only have appeared
in the Add or Remove Programs list in Control Panel, for the users that installed
the MSI. This behaviour has been changed. The install will now appear in
the Add or Remove Programs list for all users.
================(Build #2269 - Engineering Case #581403)================
It is now possible to specify the ESCAPE connection parameter in the "Connect"
dialog when connecting to SQL Anywhere servers.
Note, this new feature is actually available for use with all the graphical
administration tools.
================(Build #2158 - Engineering Case #561127)================
By default, the reload.sql script generated by the Unload utility (dbunload_)
includes calls to a temporary procedure (sa_unload_display_table_status)
to display progress messages when loading tables and creating indexes. The
-qr command line option will now suppress generation of these calls.
================(Build #2547 - Engineering Case #655157)================
If there were any missing messages, SQL Remote would have asked for a resend
after it had reached its receive polls given by the -rp option. This resend
logic could have caused the publisher to re-scan the transaction log(s) and
slow down replicating new transactions, especially on heavy load databases.
This has been changed so that when a message in a multi-part message series
(SQL Remote will generate multiple messages for a single transaction to form
a multi-part message when the transaction is too big to fit in a single message)
is missing, SQL Remote will not immediately ask for a resend, if the received
messages are not followed by any messages that contain a commit or any messages
that belong to another multi-part message series. This new logic will help
users who
need to shut down or kill SQL Remote when it is sending multi-part messages
to its subscribers.
================(Build #2512 - Engineering Case #645529)================
When run on Windows desktop, UltraLite now supports long paths when creating,
opening, or deleting databases.
================(Build #2315 - Engineering Case #590030)================
A new "OR REPLACE" clause can now be optionally specified in the
CREATE SYNCHRONIZATION PROFILE statement. If this clause is present, and
the profile named in the statement already exists, then it will be replaced.
Otherwise, it will be created.
================(Build #2139 - Engineering Case #556527)================
A new network protocol option 'http_buffer_responses' has been added. When
set to 'On', HTTP packets from MobiLink will be completely streamed into
an intermediary buffer before being processed, instead of processing the
bytes as they are read off the wire.
Syntax: http_buffer_responses = { off | on }
Protocols: HTTP, HTTPS
Default: off
Because of the extra memory overhead required, this feature should only
be used to work-around HTTP sync stability issues. In particular, the ActiveSync
proxy server for Windows Mobile devices will throw away any data that is
not read within 15 seconds after the server has closed its side of the connection.
Because MobiLink clients process the download as they receive it from MobiLink,
there is a chance they will fail to finish reading an HTTP packet within
the allotted 15 seconds causing synchronization to fail with stream error
code STREAM_ERROR_READ, when synchronizing using non-persistent HTTP. By
specifiying 'http_buffer_responses=On', the client will read each HTTP packet
in its entirety into a buffer before processing any of it, thereby beating
the 15 second timeout.
================(Build #2226 - Engineering Case #568866)================
The UltraLite Initialize Database utility (ulinit) is used to create an UltraLite
database, based on information in the SQL Anywhere database that it is connected
to. If the schema being extracted from the SQL Anywhere database contained
elements that UltraLite did not support (like column datatypes or default
values), the utility would have failed. Ulinit has been changed so that by
default, it will attempt to create an UltraLite database that comes as close
as possible to the SQL Anywhere database. For example, if a column in the
SQL Anywhere database included the DEFAULT TIMESTAMP clause (a default that
UltraLite does not support), a warning is generated and a default of CURRENT
TIMESTAMP is generated instead. In particular, if a default in the SQL Anywhere
database is not supported in the UltraLite database, the default value is
ignored and creation continues. This enhancement was made because, in some
cases, it’s possible the SQL Anywhere tables cannot be modified, and yet
a reasonable UltraLite alternative is available. The ulinit utility also
now has a –f switch that can be used to make the utility fail if the exact
schema does not match (in other words, the old behavior is given and the
utility will fail).
This fix also addressed a problem where warnings were emitted into the SQL
file if the ulinit utility was run with –l.
================(Build #2309 - Engineering Case #584478)================
BlackBerry devices with OS 4.2 or later, may now read and write UltraLiteJ
databases to either the internal flash or the SD (media) Card, in addition
to the previously supported persistent store. While the persistent object
store of BlackBerry devices is faster, it has limited capacity and is shared
with RAM and program storage. Newer devices such as the Bold, Storm and Tour
have internal flash (Bold and Storm have almost 1GB) and many devices support
SD Cards. Persistent store is 3-4 times faster than internal flash, and internal
flash is faster than SD cards. Databases stored on internal flash (URIs
begining with "file:///store/") or media cards ("file:///SDCard/")
can keep more rows in memory, and/or use a bigger cache to improve performance.
Databases names must follow the format for a fully qualified, absolute path
file name as described in the file URL format as part of IETF RFCs 1738 and
2396. That RFC dictates that a file URL takes the form:
file://<host>/<path>
In the form above, <host> is the fully qualified domain name of the
system on which the <path> is accessible, and <path> is a hierarchical
directory path of the form:
<root>/<directory>/<directory>/.../<name>.
For BlackBerry devices, the internal flash is accessed using URIs starting
with file:///store/ (case sensitive) while the SD media card is accessed
using URIs starting with file:///SDCard/ (case sensitive). File paths are
case insensitive except for the host portion which is case sensitive. Percent
(%) characters have special meaning and relative paths (directories "."
and "..") are not allowed. For more information on file name restrictions,
please consult the BlackBerry JDE (4.2 or later) API Reference for the javax.microedition.io.file
package.
The following example creates a configuration for using the media card.
The database is store in the directory "ulj" and is called "test.ulj".
// BlackBerry media card Sample - use file:///store/ulj/test.ulj
// for internal flash
Connection conn;
ConfigFileME config = DatabaseManager.createConfigurationFileME(
"file:///SDCard/ulj/test.ulj"
);
try {
conn = DatabaseManager.connect(config);
} catch(ULjException ex) {
conn = DatabaseManager.createDatabase(config);
// Create the schema here.
}
To maintain support for BlackBerry 4.1 devices, a new distribution directory
UltraLite\UltraLiteJ\BlackBerry4.2 has been added which contains files for
4.2 or later devices. BlackBerry 4.1 devices and simulators should continue
to use the UltraLite\UltraLiteJ\J2meRIM11files. BlackBerry 4.2 and later
devices can use either distribution if they do not require SD card or internal
flash storage.
The UltraLiteJ Database Transfer tool has not been updated.
================(Build #2266 - Engineering Case #578636)================
Support has now been added for the SQL statements CREATE PUBLICATION, ALTER
PUBLICATION and DROP PUBLICATION. This change also includes support for publication
predicates.
================(Build #2563 - Engineering Case #658860)================
Sybase Central would have crashed when using the QAnywhere plugin to define
a property for a connector and the property was given both a blank name and
value. Now, the creation of properties with blank names is prevented, as
these are meaningless in any case. A message box indicating that the property
name must not be empty is displayed.
================(Build #2558 - Engineering Case #657284)================
The MobiLink Server log file viewer in Sybase Central might not have listed
all synchronizations in a given log file separately if the log file contained
messages from more than one run of the MobiLink Server. This has been fixed.
================(Build #2558 - Engineering Case #657068)================
In the MobiLink Server Log File Viewer, selecting a synchronization could
have resulted in the window becoming unresponsive if the synchronization
contained hundreds of thousands of messages. This has been fixed.
Also, it was noticed that synchronizations were not initially listed in
chronological order if the log file contained output for more than one run
of the MobiLink Server. This has also been fixed.
================(Build #2541 - Engineering Case #653058)================
When creating a rule with a "Custom" schedule type, the schedule
that was saved could have been incorrect if "Run rule every" was
turned off in the "Schedule Editor" window. The rule was saved
such that it was run every 10 minutes. This has been fixed.
================(Build #2539 - Engineering Case #652577)================
Sybase Central could have crashed while the property sheet for a client message
store was open, if adding a new property was started, but then the action
was cancelled. This has been fixed.
================(Build #2512 - Engineering Case #637326)================
An error could have occurred when deploying a Synchronization Model for an
ASE consolidated database when a synchronized table had a MONEY or SMALLMONEY
column and conflict resolution was enabled for the table mapping. ASE would
have reported the error "Can't specify a length or scale on type 'money'"
when deployment tried to create a temporary table for conflict resolution,
and incorrectly specified the length and scale for MONEY columns. This would
also have occurred for a Microsoft SQL Server consolidated database with
a synchronized table having a MONEY or SMALLMONEY column, and for an IBM
DB2 consolidated database with a synchronized table having a LONG VARCHAR
column. These problems have been fixed. Now the generated SQL does not specify
length or scale for MONEY or SMALLMONEY columns with ASE and Microsoft SQL
Server, or for LONG VARCHAR with IBM DB2.
================(Build #2486 - Engineering Case #639298)================
Creating a server message store would have fail when attempting to create
a new, encrypted SQL Anywhere database for the store. This has been fixed.
================(Build #2486 - Engineering Case #637481)================
UltraLite client message stores created from Sybase Central did not have
their store IDs set, even if a store ID was given in the Client Message Store
wizard. Lack of the store ID would have caused a warning message to be displayed
when attempting to disconnect from the database and stop the agent from Sybase
Central. This has been fixed.
================(Build #2468 - Engineering Case #635336)================
The MobiLink Server Log File Viewer would have shown empty user names and
remote IDs in its "Synchronizations" and "Details" panels
when running on a non-English Solaris, Mac OS X, or French Linux system,
and Sybase Central was set up to run in that non-English language. This
has been fixed.
================(Build #2465 - Engineering Case #634933)================
Deploying a Synchronization Model with the "Run this wizard initialized
with last deployment settings" option would have given an empty field
for the location of the UltraLite database file, instead of using the location
from the last deployment. A workaround is to use the Browse button to pick
the previously deployed UDB file. This has been fixed.
================(Build #2451 - Engineering Case #632446)================
The MobiLink server stream options set in the Deploy Synchronization Model
wizard would not have been set in the batch file created to run the MobiLink
server. This has been fixed. A workaround is to edit the generated batch
file to add the stream options.
================(Build #2441 - Engineering Case #630082)================
The "Apply" button in the client properties window (for a given
server store) was not enabled correctly, and when it was enabled, it did
not consistently apply the changes. This has been fixed.
================(Build #2441 - Engineering Case #630073)================
The contents of the combobox in the "Schedule Editor" window could
have been truncated on some systems, depending on which font was being used
by Sybase Central. This has been fixed.
================(Build #2426 - Engineering Case #626459)================
A UDP Gateway's property sheet would have shown the default destination port
as -1. This has been corrected so that the correct value of 5001 is now shown.
================(Build #2423 - Engineering Case #625625)================
Sybase Central would have generated an error when attempting to create a
notifier, gateway or carrier with any of the following characters in its
name: '[', ']', '^', '%', '_'. A similar error would have occurred when attempting
to rename a notifier, gateway or carrier and any of these characters were
used in the new name. This has been fixed.
================(Build #2422 - Engineering Case #624555)================
When adding a new table to the remote database schema in a synchronization
model, if the remote schema was based on a consolidated database other than
SQL Anywhere, and the table was referenced by foreign keys in other tables
already copied from the consolidated schema to the remote schema, then an
internal error would have occurred. This has been fixed.
Note, a workaround is to add the table to the remote schema by using the
Update Schema menu item to update the remote schema.
================(Build #2418 - Engineering Case #624574)================
Attempting to connect to a newly created message store at the end of the
Client Store wizard could have failed there already was network server running
the computer and its "-gd ALL" option was not used. This has been
fixed.
================(Build #2417 - Engineering Case #624405)================
Adding a member to an empty destination alias would have caused a crash.
This has been fixed.
================(Build #2411 - Engineering Case #622889)================
When entering a file location in the Deploy Synchronization Model wizard,
typing in a file name that did not include the folder would have resulted
in an error when clicking Next. This has been fixed. A workaround is to specify
the folder.
================(Build #2403 - Engineering Case #620496)================
When deploying a synchronization model to a new remote database, if the remote
database schema had multiple foreign keys to multiple non-primary key columns
in a table, a deployment error could have occurred with the following description:
"Error for: Method makeUniqueConstraints threw exception for reference
$HELPER in template script-defs\remote.vm"
This has been fixed.
================(Build #2357 - Engineering Case #606888)================
When redeploying a synchronization model to a SQL Anywhere remote database
using the wizard initialized with the last settings, the extended options
for the SQL Anywhere client could have been corrupted. This has been fixed.
================(Build #2345 - Engineering Case #605823)================
For an IBM DB2 synchronization model, any events with comments would have
had the comments lost when deploying the model directly to a DB2 consolidated
database. Thus the special "--{ml_ignore}" comment to ignore a
script, would have been lost. This has been fixed. A workaround is to deploy
to file and run the deployed file.
================(Build #2344 - Engineering Case #605675)================
For a MySQL synchronization model, any events with comments would have had
the comments lost when deploying the model directly to a MySQL consolidated
database. Thus the special "--{ml_ignore}" comment to ignore a
script, would have been lost. This has been fixed.
A workaround is to deploy to a file, and then run the deployed file.
================(Build #2340 - Engineering Case #596235)================
When deploying a Synchronization Model to a new UltraLite database, if the
remote schema had LONG NVARCHAR columns, an error would have occurred because
UltraLite does not support LONG NVARCHAR columns. This has been fixed so
that a warning is now given, and a LONG VARCHAR column is used instead in
the new UltraLite database.
================(Build #2338 - Engineering Case #595997)================
When using a Synchronization Model with a Microsoft SQL Server consolidated
database that had a table with a UNIQUEIDENTIFIER or TIMESTAMP primary key
column, and using snapshot download and downloading of deletes, the following
error would have occurred for the generated download_delete_cursor script:
[-10002] Consolidated database server or ODBC error: ODBC: [Microsoft][ODBC
SQL Server Driver]Restricted data type attribute violation
This has been fixed.
================(Build #2316 - Engineering Case #590243)================
Sorting a list of messages on the "Messages" and "Archived
Messages" tabs by the "Status Time" column, would not have
sorted the messages correctly. The comparator for the date column had been
based on the string representation of the date, rather than the date itself.
This has been fixed.
================(Build #2306 - Engineering Case #587246)================
If a synchronization model was created that contained mappings with errors,
and then the mappings were deleted or disableds, the sync model could still
not have been deployed. The workarounds to this were to either recreate or
enable the mapping, or manually edit the sync model file and remove the scripts
with errors. This has been fixed.
================(Build #2275 - Engineering Case #581613)================
When deploying a Synchronization Model that added a timestamp column to a
MySQL consolidated table for timestamp-based downloads, existing rows would
never have been downloaded because of MySQL bug #17392. This bug caused the
new timestamp column to have values of 0, instead of the column default.
A would around for this problem has been implemented. An UPDATE statement
is now generated to follow the generated ALTER TABLE statement that adds
the timestamp row.
A manual workaround is to update the timestamp column for each row where
it is zero, after the column is added.
================(Build #2260 - Engineering Case #576501)================
If a Synchronization Model had a table mapping that was upload-only or download-only,
then attempting to synchronize would have caused a warning that some scripts
were missing. This has ben fixed by generating ignored scripts for the unneeded
upload or download scripts, which suppressed the warnings. A workaround is
to disable the warning, or create dummy scripts.
================(Build #2258 - Engineering Case #576500)================
When a Synchronization Model was being generated for a MySQL database, columns
that had been defined as nchar and nvarchar in the MySQL database, would
have been mapped as char and varchar in the Synchronization Model. This has
been fixed.
================(Build #2255 - Engineering Case #575517)================
When using the Table Mapping editor, changed the sorting order of table mappings
in the GUI may have displayed a prompt to save the model, even though no
changes were made. This has been fixed.
================(Build #2255 - Engineering Case #575516)================
When editing a Synchronization Model, deleting the "timestamp column
name" (or another text box's contents) and then trying to switch to
another Synchroniation Model without saving changes, would have caused an
error to occur. This has been fixed.
================(Build #2252 - Engineering Case #574352)================
If a Synchronization Model was deployed to a location that contained a space
in the name, or the deployed model contained a space in the name, then the
remote and consolidated script files would not have functioned correctly.
This has now been corrected. A workaround is to manually edit the files and
quote any file paths that contained spaces.
================(Build #2252 - Engineering Case #574348)================
When deploying a Synchronization Model, and using a secure stream, the Deploy
Wizard's Secure Stream Server Certificate page incorrectly referred to an
"Identity certificate file" and the File dialog opened by the Browse
button only showed certificate files (with .crt and .cer extensions). The
wizard should have listed identity files (with a private key as well as a
certificate, and .id file extension by iAnywhere convention). This has been
fixed. Now the page is called "Secure Stream Server Identity",
which refers to an "identity file", and the File dialog by default
shows only identity files with .id extension, although listing .crt and .cer
files is still an option (in case the .id extension is not used). A workaround
is to change the filter to show all file types and choose an identity file.
================(Build #2250 - Engineering Case #573839)================
In the Synchronization Model wizard, when creating a model using a consolidated
database and an existing remote database, the mapping editor's column headings
could have been incorrect. In particular, the "Consolidated Table"
column would have incorrectly been labelled "Mapping Direction".
This has been fixed.
================(Build #2243 - Engineering Case #572123)================
When deploying a Synchronization Model on Unix systems, generated .sh files
were not created with executable permissions set. A workaround was to run
"chmod a+x" on all of the .sh files. This has been fixed. Now executable
permission is set for everyone when .sh files are generated.
================(Build #2242 - Engineering Case #572124)================
Opening a previously deployed and saved Synchronization Model file with a
new remote database, and then trying to deploy it using the last settings,
would have failed with a file error while recreating the remote database.
This has now been fixed.
A workaround is to manually delete the remote database and transaction log
before redeploying.
================(Build #2242 - Engineering Case #572122)================
When a Synchronization Model was created and deployed on Unix systems, the
created .sh files had statements like "if [[ value == value ]] ".
The "[[", " ]]" and "==" were syntactically
incorrect, causing error messages. This has been fixed.
Also when running an mlsrv.sh file with an argument that contained spaces,
such as "dsn=SQL Anywhere 11 Demo", would have failed. The connection
string is now quoted within the file to correct this.
================(Build #2237 - Engineering Case #571671)================
When editing a synchronization model's mappings with the table or column
mapping editors, typing a Ctrl or Alt key combination could have initiated
editing of the focused cell and either selected or opened a menu. This has
been corrected so that typing a Ctrl or Alt key combination only performs
the latter operation, and does not initiate editing.
================(Build #2235 - Engineering Case #571282)================
When creating a synchronization model, if a custom download subset was choosen,
without specifying one or more tables to join, then the download_cursor events
would not have been generated. Instead errors like the following would have
appeared as comments in the Events editor:
/*
* ERROR: Unexpected error encountered while generating event.
* Error for: RHS of #set statement is null. Context will not be modified.
table-scripts\download_cursor.vm
* [line 59, column 8]
*/
This problem only happened in the New Synchronization Model wizard, not
when custom download subset was enabled in the Mappings editor. The problem
has been fixed for new synchronization models.
To work around the problem, in the Mappings editor change the Download Subset
(Dnld. Sub.) to None and then back to Custom, then switch back to the Events
editor.
================(Build #2233 - Engineering Case #570923)================
If a database error occurred when trying to install or update the MobiLink
System Setup, the error message would have included the SQL statement that
was being executed, which could have lead to the message box being too large
for the screen. This has been fixed. Now the SQL statement is only shown
when the Details are shown.
================(Build #2217 - Engineering Case #569122)================
When deploying a synchronization model to an UltraLite remote database, the
batch file generated to run ulsync had an example CONNECTION string that
incorrectly used my_db.db, rather than my_db.udb. A correct CONNECTION string
in the batch file is now generated.
================(Build #2165 - Engineering Case #562962)================
The QAnywhere message transmission status code which formerly displayed as
"Local", is now displayed as "Do_not_transmit". This
change was made to match the documentation.
================(Build #2157 - Engineering Case #559653)================
When connected to an authenicated SQL Anywhere database from the MobiLink
plug-in in Sybase Central using the "Generic ODBC DSN" option,
the connection would have been read-only. This has been fixed.
================(Build #2149 - Engineering Case #558915)================
When deploying a Synchronization Model to file, any characters in .SQL files
that are not supported by the OS console code page would be changed to a
substitution character, even though the character would have been displayed
correctly in the MobiLink plug-in. This has been fixed so that .SQL files
now use UTF-8 character encoding. The generated .bat or .sh file is still
written using the console code page, since it must run in a console, but
the UTF-8 character encoding is now specified when the Interactive SQL utility
is invoked in the .bat or .sh file.
================(Build #2147 - Engineering Case #558739)================
After deploying a synchronization model with logical deletes to a DB2 consolidated
database, and then synchronizing, either of the following synchronization
errors would have occurred for the MobiLink server (depending on the database
setup):
[IBM][CLI Driver][DB2/NT] SQL1216N Graphic data and graphic functions are
not supported for this database. SQLSTATE=56031
[IBM][CLI Driver][DB2/NT] SQL0104N An unexpected token "N''"
was found following ", ?, ?, ?, ?, ''". Expected tokens may
include: "<space>". SQLSTATE=42601
This has been fixed. A workaround is to deploy to a file and edit the consolidated
SQL file to change instances of four single quotes to two single quotes.
================(Build #2137 - Engineering Case #555809)================
The Server Message Store would have been unable to connect to the store after
creating it, if an encryption password was specified. This has been fixed.
================(Build #2136 - Engineering Case #555453)================
If an encryption key was specified, it was not possible to create a server
message store when running on Linux systems. This has been fixed.
================(Build #2135 - Engineering Case #555054)================
Sybase Central was allowing the modification or deletion of the QAnyNotifier_client
notifier. Doing so could have caused problems with QAnywhere. To prevent
any problems, it is now only possible to modify the notifier's description,
polling interval and event SQL.
================(Build #2135 - Engineering Case #555007)================
Sybase Central could have crashed when attempting to change the visible columns
(via View -> Choose Columns...), or column widths, while the MobiLink
11 node was selected in the tree. In addition, when in Model mode, the list
of columns under the View -> Sort menu would sometimes not have contained
all the displayed columns when the MobiLink 11 node was selected in the tree.
Both of these issues have now been fixed.
================(Build #2132 - Engineering Case #554265)================
If more than one message store connection was open, and the connections were
broken from outside of Sybase Central, attempting to then disconnect from
within Sybase Central could have caused Sybase Central to crash. This has
been fixed.
================(Build #2571 - Engineering Case #661035)================
When deploying a Synchronization Model for an existing remote database and
only deploying to file, the generated Windows batch file would have failed
when execute. For example, a "You are not connected to a database"
error could have occurred when the batch file tried to apply the generated
SQL file to the remote database. This has been fixed.
To workaround the problem, change this line in the generated batch file:
set CONNECTION=%1
to this:
set CONNECTION=%~1
================(Build #2562 - Engineering Case #658482)================
When a MobiLink Monitor instance that already had a horizontal scroll bar,
was connected to a MobiLink server, the Utilization Graph time scale (if
Utilization Graph was enabled) would have been different than the Chart time
scale. After being connected long enough for the horizontal scroll bar to
be redisplayed, the scroll bar position would have been incorrect and the
Overview Marquee Tool would have fluctuated between the inconsistent time
scales. This has been fixed.
A workaround is to use the Marquee Tool, or change the zoom to fix the display,
or disable the Utilization Graph to prevent the problem.
================(Build #2560 - Engineering Case #657979)================
The MobiLink Monitor's Zoom To Selection menu or toolbar button might not
have panned to the selected synchronization until it was used a second time.
This has been fixed.
================(Build #2541 - Engineering Case #653055)================
Any parameters entered on the MobiLink Monitor's command line with a Multibyte
Character Set would have been mangled. This has been fixed.
================(Build #2439 - Engineering Case #629597)================
The initial position of the main window for the MobiLink Monitor could have
placed the window underneath the Windows task bar. This has been fixed.
Note, this problem also affected the Interactive SQL utility, Sybase Central,
and the SQL Anywhere Console utility.
================(Build #2439 - Engineering Case #606840)================
When running on Windows Vista or Windows 7 systems, menu items that toggle
a property on or off would not always have shown the check mark next to the
menu item's text. Similarly, menu items that choose a value from a mutually
exclusive set of values would not always have shown a sphere next to the
currently selected value. Both of these problems have been fixed.
================(Build #2165 - Engineering Case #562833)================
When the MobiLink Server had a large number of synchronizations running concurrently
(in the range of 10000), a MobiLink Monitor connected to it could have become
unresponsive, and not displayed new information in a timely manner. This
has been fixed.
================(Build #2144 - Engineering Case #554383)================
In the MobiLink Monitor Details Table, if the optional column "connection_retries",
or optional columns starting with "download_" or "sync_",
were enabled, the column labels for these columns would have been misaligned
by one or two columns. A similar problem would have occurred when exporting
to a database, where that data was exported to incorrect columns in the database
tables. Both of these problems have been fixed.
================(Build #2605 - Engineering Case #669235)================
When starting the QAnywhere Agent (qaagent) with the command line option
"-qi", the MobiLink Listener and the MobiLink Client processes
were not also launched with "-qi" options, resulting in system
tray icons on Windows Mobile devices. This has been corrected.
================(Build #2575 - Engineering Case #662456)================
On a Windows Mobile device, the QAnywhere Agent (qaagent) would have sometimes
given the following error messages at start up:
E. 2011-03-14 08:33:50. Error registering with DBLSN code: -1
The error message was displayed in a message box, even when qaagent was
executed in quiet mode. This has been fixed. Now, qaagent is more tolerant
to dblsn slowness at startup. Also, a message box is not displayed when
qaagent is executed in quiet mode (-q or -qi), and the message is logged
in the qaagent console and log file.
================(Build #2513 - Engineering Case #645659)================
Under some conditions, the QAManager Close() method could have taken up to
a minute to return. This has been fixed. The Close() method will now always
complete in a reasonable amount of time.
================(Build #2512 - Engineering Case #645665)================
When a message was received by the QAManager.GetMessage method when the QAManager
was opened in AcknowledgementMode.IMPLICT_ACKNOWLEDGEMENT and the QAnywhere
Agent was running with automatic policy, it was possible that the acknowledgement
would not have been transmitted to the receiver until the next time the message
store was synchronized with the MobiLink server. This has been fixed. Now
the received message is immediately acknowledged.
================(Build #2490 - Engineering Case #640241)================
In rare circumstances, the QAnywhere C++ client could have deleted a received
and acknowledged message before the acknowledged status was transmitted back
to the sender. This has been fixed.
================(Build #2438 - Engineering Case #629277)================
The QAnywhere Standalone Clients would not synchronize when expected to in
two cases.
The first case occurred if a sync request was made while another synchronization
was already taking place. It was expected that another sync will begin once
the current one has finished, but this did not always happen.
The second case occurred if a sync request was made while using a Transactional
Manager. It was expected that only sync requests resulting from changes
to the database will be delayed until the transaction is committed. However,
this delay was occurring for other types of sync requests as well.
These two cases have now been fixed.
================(Build #2414 - Engineering Case #624352)================
When run on a Windows CE device, the QAnywhere Agent for UltraLite would
have failed to connect with a MobiLink server running on the desktop through
ActiveSync, if no -x option was specified. The QAnywhere Agent was using
"host=localhost" for its stream parameters when no -x option was
specified. Now, the agent does not specify stream parameters in this case,
letting the UltraLite sync stream choose the default host IP address.
================(Build #2410 - Engineering Case #622720)================
Application using the Ultralite runtime would have sometimes looped endlessly
following a synchronization stream error. This has been fixed.
================(Build #2379 - Engineering Case #616015)================
The QAnywhere Agent could have failed with the error: "Internal error:
Too many MESSAGE ... FOR CONNECTION messages". This has been fixed.
================(Build #2316 - Engineering Case #590374)================
Calling the QAManager.close() method, immediately after receiving a message
asynchronously, could have caused the manager to hang indefinitely. This
has been fixed
================(Build #2297 - Engineering Case #584873)================
If the QAnywhere Agent for Ultralite was running using the automatic policy,
and a message was sent during a loss of communication with the QAnywhere
server, then the message would not have been sent upon re-establishing communication.
This has now been fixed so that and unsent messages will be sent shortly
after that connection is re-established.
A workaround for this problem is to perform an action that will trigger
a
synchronization (eg. send another message, call triggerSendReceive, etc.)
================(Build #2282 - Engineering Case #583194)================
The QAnywhere Standalone Clients were not adhering to the synchronization
policies as they are defined in the documentation. In several scenarios,
the clients would trigger synchronizations even though the policy requirements
were not satisfied, although it was never the case that a synchronizations
didn't occur when one should have. This has been fixed so that the clients
now synchronize only at the appropriate times as defined by the policies.
================(Build #2253 - Engineering Case #574698)================
The QAnywhere Java clients could have gone into an endless loop, with 100%
CPU usage, if it attempted to uncompress a message whose content has become
somehow corrupted. This has been fixed so that the clients now return a suitable
error message to indicate that it failed to retrieve the message.
================(Build #2253 - Engineering Case #574693)================
The QAnywhere Agent for UltraLite would have given a misleading error message
if an invalid username or password was specified in the connection string.
The error message that was being generated looked like:
Internal error: SQLCODE: -108, SQLSTATE: []
Source statement: SET OPTION isolation_level=read_committed
QAnywhere Agent failed to initialize message store
This has been fixed so that the agent now returns error code -103 as expected
================(Build #2246 - Engineering Case #572968)================
A small amount of memory was being leaked on every synchronization by the
QAnywhere Agent for Ultralite. This has been fixed.
================(Build #2218 - Engineering Case #616017)================
The QAnywhere Agent would have failed to upgrade 9.0.2 message stores that
were created with SQL Anywhere 9.0.2 builds 3654 and later. This has been
fixed.
================(Build #2211 - Engineering Case #569012)================
The "UserAgent" HTTP header for QAnywhere/MobiLink communications
previously only specified "QAnywhere/11.0.1", and "QAnywhereUL/11.0.1",
for SQL Anywhere and UltraLite clients respectively. It did not differentiate
between data synchronization and listener components. This has been fixed.
Now, the header specifies "QAnywhereSync/11.0.1" for a SQL Anywhere
data sync client, "QAnywhereULSync/11.0.1" for a UltraLite data
sync client, and "QAnywhereLsn/11.0.1" for a MobiLink listener
client.
================(Build #2184 - Engineering Case #565667)================
The methods QAManagerBase.SetMessageListener and QAManagerBase.SetExceptionListener
would have throw a QAException with error code COMMON_NOT_OPEN_ERROR, when
called before an Open() call. This has been fixed. Now, SetMessageListener
and SetExceptionListener can be called any time after the creation of a QAManagerBase
object, as in earlier versions of QAnywhere.
================(Build #2537 - Engineering Case #651880)================
The reply-to address for messages originating from a Weblogic 10.3 JMS server
were formatted in such a way that they could not have been resolved by the
JMS connector. This has been fixed.
================(Build #2372 - Engineering Case #614034)================
When a 9.0.2 QAnywhere client synchronized, the MobiLink server would have
displayed the following errors:
Expecting 1 parameters in script, but only found 4: update ml_qa_global_props
set modifiers = ?, value = ? where client = ? and name = ?
Unable to open upload_update .
This has been fixed by a change to the upload_update script for the table
ml_qa_global_props, version ml_qa_2.
================(Build #2365 - Engineering Case #611361)================
Using Sybase Central to cancel a system message that resided in a QAnywhere
Client database would have resulted in an unhandled Null Pointer Exception.
This has been fixed
================(Build #2327 - Engineering Case #593120)================
The QAnywhere server could have stopped sending and receiving messages with
an Enterprise Messaging Server, through its JMS connector, when connectivity
to the EMS was interrupted and subsequently restored. This has been fixed.
================(Build #2307 - Engineering Case #585035)================
The QAnywhere server could have stopped sending/receiving messages with an
Enterprise Messaging Server, through its JMS connector, when a SQLException
was thrown by the JDBC driver. This has been fixed.
Where possible, the QAnywhere server should recover gracefully from exceptions
thrown by the JDBC driver and continue processing messages.
================(Build #2222 - Engineering Case #564639)================
When MobiLink servers with QAnywhere messaging were set up in a server farm,
push notifications could have stopped working in some circumstances. In particular,
if the MobiLink server(s) handling synchronization requests from QAnywhere
clients were different from the server that initiated the push notification
(as would have been the case if the notifications were the result of outbound
JMS messages in a server running a JMS connector), only the first push notification
would have been sent, and no further notifications would have been sent.
This has now been fixed.
It should be noted that, in a MobiLink server farm deployment, there could
be a latency of at most the automatic rules evaluation period to send a push
notification to a client as a result of an outbound message to that client.
This is due to scalabilty factors in a situation where there is a high volume
of outbound messages being processed by the MobiLink server.
================(Build #2214 - Engineering Case #568986)================
Performing a PutMessage operation from the Java QAnywhere Client using UltraLite,
or from the Standalone Java QAnywhere Client, would have resulted in a memory
leak equal to the size of the content of the message. This has been fixed.
================(Build #2188 - Engineering Case #558510)================
A table in the QAnywhere for Ultralite schema could have been created improperly,
resulting in a failure to initialize the message store with the error (-131)
"param 1: timestamp". This has been fixed
================(Build #2166 - Engineering Case #563143)================
When a QAnywhere consolidated database contained a large number of messages
that satisfied a delete rule, and the MobiLink server was shut down, the
server would not have actually terminated until all messages had been deleted,
which could have been a very long period of time. When delete rules are executed,
old messages are deleted in batches of 100 at a time until there are no more
messages satisfying the delete condition. However, there was no mechanism
to stop the execution of delete rules on MobiLink server shutdown. Such a
mechanism has now been added for delete and archive rules.
================(Build #2144 - Engineering Case #557938)================
It was possible for a deadlock to have occurred in the database server if
the QAnywhere server was performing delete rules and archiving messages at
the same time. Furthermore, the exception thrown by this deadlock exposed
another problem in the QAnywhere server error handling where it was possible
for a transaction to be left open, causing other connections to block due
to unreleased table locks. Both of these issues have been fixed.
================(Build #2141 - Engineering Case #556974)================
Using a QAnywhere JMS connector to communicate with a Websphere MQ JMS provider
could have resulted in the following two issues:
- The MobiLink server could have reported the error "The property
name 'JMSTimestamp' is reserved and cannot be set." when Sending a message
from a QAnywhere application to the JMS connector.
- The ReplyToAddress of a QAnywhere message originating from a Websphere
JMS provider could have contained a malformed queue name.
Both of these issues have been corrected.
================(Build #2120 - Engineering Case #551751)================
Attempting to use the QAnywhere Server to cancel a message in an Ultralite
Client Message Store would have failed with a NullPointerException. This
problem was more likely to occur when using the Sybase Central plugin to
connect to an Ultralite client database and then attempting to cancel a message.
This has been fixed.
================(Build #2114 - Engineering Case #550080)================
In the Sybase Central QAnywhere Plugin, if when connected to a server message
store a client was created, and then the view refreshed, the newly created
client would not have been displayed. This has been fixed.
================(Build #2624 - Engineering Case #674187)================
A web server worker thread may have crashed when it failed to load the localized
language resource (e.g dblge12.dll). The reasons for the failure may have
included the file not being found due to path and registry info, or the account
associated with the worker did not have permission to read the resource.
The symptom was a truncated log line with a missing end-of-line. This has
been fixed so that the crash will no longer occur and an unlocalized error
message is displayed regarding the loading error.
================(Build #2624 - Engineering Case #674120)================
A web server worker may have crashed when logging lengthy debug messages
that had not been localized. This has been fixed.
================(Build #2603 - Engineering Case #668791)================
When the Relay Server Outbound Enabler failed a backend connection test,
it may have crashed, or have been unable to recover even after the backend
became available again. This has been fixed.
================(Build #2593 - Engineering Case #666845)================
The Relay Server admin and monitor extensions may have slowly leaked memory.
Eventually, admin or monitoring requests would have failed without any trace
in the HTTP error log, IIS access log, or in the Relay Server log. This problem
has been fixed so that recycling is no longer necessary. To workaround this
problem, users may setup application pool recycling for the admin and monitoring
extension.
================(Build #2583 - Engineering Case #664283)================
Relay Server enable/disable events were not broadcast to connected Outbound
Enablers. For example, disabling the last Relay Server from a Relay Server
farm was not going to suffer the issue described in Engineering case 664284,
but when adding a Relay Server to the Relay Server farm, it would also not
have woken up the Outbound Enablers to start utilizing the new Relay Server.
The user workaround is to restart the Outbound Enabler. This problem has
been fixed.
================(Build #2583 - Engineering Case #664139)================
When a Relay Server starts up, its description was logged and the startup
verbosity was applied properly, but those values were not stored correctly
for later consumption. Such as for the admin tool to export the configuration
or for the next configuration update to properly determine if an updated
was required. This problem has been fixed.
================(Build #2583 - Engineering Case #661112)================
It was possible for synchronizations to fail if any of the 'certificate_name',
'certificate_company', or 'certificate_unit' parameters were supplied, even
though the value of these parameters matched the corresponding field values
in the server's certificate, if they were encoded as Unicode in the server's
certificate. This has been corrected.
================(Build #2581 - Engineering Case #663835)================
When the Outbound Enabler shut down, on going client requests may have taken
3 times the application timeout value to abort. This has been fixed.
================(Build #2577 - Engineering Case #663061)================
Proxy support for the Relay Server Outbound Enabler may only have worked
with HTTPS against some HTTP 1.1 proxy servers. The down channel using HTTP
instead of HTTPS would have connected successfully at first but then would
have been dropped by the proxy after a period of being idle. This problem
is proxy specific and it does not affect all HTTP proxy environments. This
problem has been fixed in the Relay Server so that an update to the Outbound
Enabler is not required (see Engineering case 662749). The workaround is
to use HTTPS, or apply the Outbound Enabler fix from case 662749.
================(Build #2572 - Engineering Case #661849)================
When using the Service utility (dbsvc) to start a Relay Server service with
a large configuration on a slow machine, it may have reported startup errors
while the service was still in the pending start state. A fix was made to
the Relay Server to correct this problem.
================(Build #2570 - Engineering Case #661225)================
A network environment that was sensitive to HOST header inspection on http
traffic, may have caused the Outbound Enabler to fail to connect to the Relay
Server, or it may have connected to the wrong server. This has been fixed.
================(Build #2570 - Engineering Case #660995)================
When connected to a Relay Server, and no Outbound Enabler providing the backend
service had connected yet, the connection was expected to timeout within
the application timeout time specified by the client. However on IIS7, some
J2SE http clients may have become stuck writing to a server that was no longer
reading and eventually failed the write and then perform a delayed internal
retry without processing the response sent by the web server. This change
modifies the Relay Server to provide the expected fail fast experience according
to the timeout against such J2SE clients.
================(Build #2557 - Engineering Case #656716)================
The Relay Server could have leaked heap memory under the following conditions:
- On the response to the first HTTP request in the session, or specifically,
anytime a cookie was set, if the response was long and came in small packets.
- A small number of bytes were leaked on Upchannel and Dnchannel creation.
This has been fixed.
================(Build #2555 - Engineering Case #657026)================
The MobiLInk server would immediately refuse to startup, if it could not
make any connections to the consolidated database, even when it was running
as a Windows service.
This behaviour has changed so that the MobiLink server will retry to make
connections, when it is running as a Windows services. The retries are once
a minutes for ten minutes. If it still cannot make a connection after that,
it will refuse to startup.
================(Build #2540 - Engineering Case #652735)================
When a Relay Server shuts down, it notifies connected Relay Server Outbound
Enablers (RSOE) to perform an internal shutdown before the RSOE enters recovery
mode. The RSOE also notifies the Relay Server via the down channel when the
the RSOE shutdown is completed. The HTTP subsystem used on IIS7.5 prevented
a Relay Server from receiving the shutdown notification reliably and in turn
caused an unnecessary hard shutdown of the Relay Server after a 100 sec delay.
This has been fixed so that the Relay Server now handles this case properly
as a graceful soft shutdown without a delay.
================(Build #2540 - Engineering Case #652382)================
The Relay Server did not work with a Relay Server Outbound Enabler (RSOE)
that was behind an HTTP 1.0 proxy. The Relay Server has now been fixed to
adapt to HTTP version downgrades done by an HTTP 1.0 proxy, and is needed
when working with a 12.0.1 RSOE in conjunction with a HTTP 1.0 proxy.
================(Build #2538 - Engineering Case #652243)================
MobiLink clients using persistent HTTP 1.0 connections may fail occasionally
when using the Relay Server. The failure was isolated to synchronizations
that ran into a rare timing problem. This has been corrected.
================(Build #2526 - Engineering Case #649044)================
When a backend server drops a connection without providing any HTTP response,
IIS ver7 may inject "200 OK" as a response to the client. This
may have caused MobiLink clients to be fooled to spin into an infinite loop
by repeatedly getting 200OK at high frequency. This change will allow the
Relay Server to detect this case and explicit send a "400 Bad request
with on backend server response" response.
================(Build #2513 - Engineering Case #645223)================
The Relay Server for IIS7 could have unexpectedly disconnected persistent
http connections after finishing relaying a server response. This has been
fixed.
================(Build #2507 - Engineering Case #644112)================
When the backend machine was under heavy load, a standalone Relay Server
Outbound Enabler may have reported the following internal error
HandleNotification: Error receiving for sidx=<session_index> system
error ({error code})
With this change, the error is now less likely to occur.
================(Build #2505 - Engineering Case #643812)================
When a backend server was using an id longer than 44 characters, the client
may not have been able to access the backend server. This has been fixed.
================(Build #2501 - Engineering Case #643019)================
In rare situations, data corruption may have occurred during up channel renewal
when the backend server was under high load. By default, channel renewal
occurs whenever 2G of data has been uploaded to the Outbound Enabler. Since
the up channel renewal mechanism has been replaced by chunk encoding in the
version 11.0 Apache Relay Server, and all IIS Relay Servers, this issue only
applies to version 12.0 Apache or IIS Relay Servers working against older
Outbound Enablers (earlier than 11.0.1.2446) which don't support chunking.
Up to 64k of upload data could have been lost when this problem occurred.
This problem has now been fixed.
================(Build #2499 - Engineering Case #642827)================
The Relay Server for IIS7 would have failed to stream Afaria downloads, and
was causing the Afaria client to timeout. This has been fixed.
================(Build #2482 - Engineering Case #638473)================
If a Relay Server Outbound Enabler (rsoe) was successfully connected to a
Relay Server, and the Relay Server was restarted while the rsoe was still
running, then the server extension of the Relay Server could have crashed
upon receiving the rsoe's new up channel connect request. This crash would
have occurred if the rsoe tried to connect with configurations that invalidated
the (already running) rsoe authentication, such as changing the farm or server
id, that the rsoe was using. This has been fixed.
================(Build #2481 - Engineering Case #638268)================
When connecting a device that supports the OMA Device Management protocol
directly to an Apache based Relay Server, the device would have displayed
an error stating “Invalid Host Address”. The Afaria Server still provisions
the device, but the Afaria OMA-DM Server logs state: "... authentication:
no credentials in message “. When sending the response back to the client,
the Relay Server (when run on systems other than Linux) was incorrectly setting
the content-type header as text/plain instead of application/vnd.syncml.dm+wbxml.
This has now been fixed.
================(Build #2480 - Engineering Case #638153)================
If none of the $SATMP, $TMP, $TMPDIR or $TEMP environment variables were
set and the Relay Server State Manager (rshost) was started without the -o
command line option specified, rshast would have failed to start. Under these
conditions, rshost uses '/' as the root directory and fails due to write
premissions. This has been fixed.
================(Build #2465 - Engineering Case #635062)================
The Relay Server Outbound Enabler (RSOE) could have failed to connect to
an Apache Relay Server, with the error message "HTTP chunk length too
long". The same RSOE would not have reproduced this error with a Microsoft
IIS webserver. This has been fixed.
================(Build #2458 - Engineering Case #633685)================
Under rare situation, the Relay Server Outbound Enabler (RSOE) may have crashed
during channel renewal. This has been fixed.
================(Build #2451 - Engineering Case #632434)================
Version 11.x of the Relay Server is not compatible with version 7 of Microsoft's
Internet Information Server (IIS7). The Relay Server has now been updated
to support IIS7. New IIS7 set up instructions will be available in %sqlany11%\MobiLink\RelayServer\IIS\iis7_setup.txt.
================(Build #2427 - Engineering Case #627403)================
If the Relay Server Outbound Enabler (RSOE) lost connectivity to the Relay
Server, and was attempting to restart the worker threads at the same time
that it was about to time out a thread working an active request, it was
possible for the RSOE to have crashed. This has now been fixed.
================(Build #2414 - Engineering Case #623805)================
The Relay Server State Manager (rshost) could have crashed if initialization
failed before a log file was successfully created. Failure to create the
log file, empty config file or missing required sections, were some of the
conditions that could have lead to the crash. This has been fixed.
================(Build #2384 - Engineering Case #616997)================
Relay Server Ooutbound Enabler could have been slow in connecting to a backend
server when it used a host name, instead of a dotted IP address, in the -cs
option. This connect performance issue has been fixed. Using a host name
in the -cs switch should no longer causes performance issues. The workaround
is to use dotted ip address.
================(Build #2380 - Engineering Case #616239)================
Under sustained high load from a Relay Server, the Outbound Enabler may not
have performed well enough, resulting in client timeouts. A performance improvement
has been made to the Outbound Enabler to correct this problem.
================(Build #2379 - Engineering Case #616040)================
When the Relay Server Outbound Enabler console was opened with high verbosity
logging set, the Outbound Enabler performance could have been significantly
degraded. This has been fixed by removing log information at verbosity level
1 and above from the console display, but leave them in the log file only.
To restored the old behavior of displaying all information to the console,
use the new -dl command line option.
================(Build #2379 - Engineering Case #615861)================
The Relay Server Outbound Enabler was over using memory for buffering upward
data. This has been fixed.
================(Build #2378 - Engineering Case #615813)================
The Relay Server does not support running more than one Outbound Enabler
per backend server if they are started with the same backend server id. If
this limitation for a unique backend server id was violated, some traffic
to that backend server may either have failed, or suffered slowness. This
problem has been fixed. The Relay service to other backend servers is no
longer affected by this issue. The second and subsequent instances are not
functional.
================(Build #2373 - Engineering Case #615828)================
The Relay Server Outbound Enabler (RSOE) could have sporadically crashed
on startup. This has been fixed.
================(Build #2373 - Engineering Case #614976)================
The Relay Server Outbound Enabler (RSOE) may not have relayed backend server
responses when under a sustained high load of requests. The problem was more
likely to occur when the network between the client and Relay Server (RS),
as well as the network between the RS and the RSOE, were both very fast while
the backend server machine was relatively slow in processing. Turning on
high RSOE verbosity in such situation would have caused this problem to be
more likely to occur. A fix has now been made in the RSOE to solve this problem.
================(Build #2373 - Engineering Case #614245)================
When more than one Relay Server Outbound Enabler (RSOE) in the same backend
server farm used the same server id to connect to the Relay Server, the Relay
Server would have reported that there was a conflict, and let the newer RSOE
instance win over the existing RSOE connection. There was a small chance
that the old RSOE connection may have reported the error "Internal error!
Freeing already freed memory!" during the disconnect process. Although
the memory manager in versions 11.0.1 2335 or higher of the Relay Server
is immune from such memory problems, and will keep working normally, a fix
has been made to further stop the cause of this memory problem in order to
stop the internal error from occuring at all.
================(Build #2362 - Engineering Case #609944)================
When running the Relay Server Outbound Enabler (ROSE) and the backend server
on slow machines, the RSOE may have failed to notify the Relay Server (RS)
that the backend connection for a non-persistent http request had been closed,
which would have caused the RS to hold on to resources for an extended period
of time, making the RS less scalable. This problem has been fixed.
================(Build #2361 - Engineering Case #610141)================
When the Relay Server State Manager was run on Linux with the -os command
line option, it would have generated many small archive output log files
once the archiving process had started. The logger's size counter wasn't
being reset after successfully generating the first output archive file.
This has now been fixed.
================(Build #2357 - Engineering Case #608747)================
The Relay Server Outbound Enabler may have reported session mismatch errors
when an Afaria client disconnect their POST channel. This has been fixed.
================(Build #2353 - Engineering Case #605873)================
Two minor problems have been corrected:
1) The logging of unilitialized session indexes has been fixed
2) Reword logging of backend socket closing activities to "DoneReceive
EOF" instead of "disconnecting" or "socket close"
================(Build #2350 - Engineering Case #606826)================
An incomplete startup of the Relay Server on Linux due to resource limitations,
may have left many persistent System V semaphores behind. This would have
caused a permanent semaphore resource drain to the system until they were
either manually deleted, or the system was rebooted. This issue has now been
fixed.
================(Build #2350 - Engineering Case #606658)================
When shuting down the Relay Server for Apache on Linux, one persistent System
V semaphore for IPC was being leaked between Relay Server components. This
has been fixed.
================(Build #2347 - Engineering Case #606660)================
When working with clients that don't support communication liveness, such
as MobiLink 9.x clients, the Relay Server will timeout a client after being
idle for 8 minutes, if the web server has not timed out the client earlier.
Increasing the web server liveness timeout will not resolve the situation.
The solution is to use the IAS-RS-App-Timeout-Minute header in the http request.
For example, to set a 20 minute timeout for a big download with a MobiLink
version 9.x client, simply add custom_header=IAS-RS-App-Timeout-Minute:20
to the HTTinkP synchronization communication option. This timeout header
is an existing but undocumented feature in all released version of the Relay
Server. There is no software change involved.
================(Build #2346 - Engineering Case #605874)================
When the Relay Server Outbound Enabler (RSOE) timed out an up channel connection,
the RSOE would have recovered the connection, but it may have resulted in
an invalid opcode being received in error from the Relay Server, and then
cause the RSOE to disconnect both the up and down channels and restart. This
is now fixed so that the RSOE will handle the reconnect properly without
causing a more substaintial restart before restoring the service.
================(Build #2345 - Engineering Case #605818)================
The Relay Server Outbound Enabler (RSOE) may not have issued timely liveness
packet on the down channel when the backend server was loaded. This may have
caused a down channel read timeout on the Relay Server. Also, the Relay Server
may not have issued timely liveness packets on the up channel when the it
was loaded, This may have caused an up channel read timeout on the RSOE.
Both of these problems are now fixed.
================(Build #2344 - Engineering Case #605843)================
When non-persistent http was used, and there was a significant latency for
the backend server to close the socket after writing all response bytes and
before the next request of the same session come into the Relay Server Outbound
Enabler (RSOE), the RSOE may have mistakenly failed the new request when
the Relay Server timed out waiting for the close of the previous request.
This has been fixed.
================(Build #2343 - Engineering Case #605412)================
If client_security (or server_security) was set to 'on' in the Relay Server
for Apache running on Linux, the Relay Server may have unnecessarily failed
the client's (or Outbound Enabler's) HTTPS requests. This has been fixed.
================(Build #2343 - Engineering Case #605071)================
The Relay Server, in general, is not forward compatible with future versions
of the Relay Server Ooutbound Enabler (RSOE). Changes have now been made
which will allow future version of RSOE to fallback to a protocol version
that is compatible with the Relay Server in use at the time. New Relay Servers
will no longer reject connections from newer RSOEs, but will request a protocol
version adjustment. This fix also contains an independent change that allows
the RSOE to work with legacy 11.0.x Relay Servers without patching the Relay
Server with the capability to request a protocol version adjustment. Heterogeneous
Relay Server farms, with a mix of new and old Relay Servers, has also been
enabled by this change. This can be useful in progressive Relay Server farm
upgrades. Here is the compatibility matrix following this change:
RS RS
11.0.0.ga-1529 11.0.0.1530 and up
11.0.1.ga and up
12.0 beta and up
RSOE
11.0.0.ga-1529 YES YES
RSOE
11.0.0.1530 and up NO YES
11.0.1.ga and up
12.0 beta and up
================(Build #2342 - Engineering Case #605032)================
Under rare situation, the Relay Server may have notified the Relay Server
Ooutbound Enabler (RSOE) to disconnect a stale backend connection when the
HTTP response had been completed, but the RSOE didn't indicate that the backend
server connection had been completed within a tolerable latency. When this
happened on a request that was not the first one of a HTTP session, the Relay
Server didn't fill in available OE and session indexes to optimize the lookup
of the backend session, and caused the RSOE to perform extra work to lookup
the session. The RSOE was also logging misleading invalid indices because
of this. This problem has now been corrected.
================(Build #2342 - Engineering Case #605029)================
When the Relay Server Outbound Enabler (RSOE) loses a connection to the Relay
Server, it will attempt to recovery the connection at a rate controlled by
the -d switch. The reattempt may have unnecessarily failed, causing more
reattempts before the service was restored. This has been fixed. The fix
also improves error reporting on the RSOE so that it will report the HTTP
response code and message in an error in cases when the web server rejects
the request before it reaches the Relay Server extension.
================(Build #2336 - Engineering Case #595745)================
After a session was interrupted due to client disconnecting from the Relay
Server, the Relay Server Outbound Enabler (RSOE) may have logged cancelled
operations on the session using incorrect backend connection context information.
This has been fixed. Along with this fix, a typo was corrected where sfp
was being logged as spf.
================(Build #2336 - Engineering Case #595744)================
After an HTTP request failure, the Relay Server Outbound Enabler (ROSE) would
have unnecessarily failed an HTTP client retrying an HTTP request on the
session using the acquired session cookie. This has been fixed by adding
support in RSOE for this kind of resume.
================(Build #2336 - Engineering Case #595502)================
The Relay Server may have incorrectly reported that shared memory was exhausted
and then failed to relay further traffic after a rare memory abuse. This
fix improves the memory manager by detecting and reporting incidents when
a block of shared memory is freed by more than one process, and will allow
the Relay Server to continue following the abuse. The detection was added
without introducing extra computational overhead. The error report has the
following format in the relay server log:
E. 2009-10-22 14:39:32. <1036.440.ShmDebug> Internal Error! Freeing
already freed memory!: 00011390
The error message is useful in reporting issue to tech support so that we
can identify defects in the higher level logic and eliminate the source of
the rare abuse.
================(Build #2333 - Engineering Case #595104)================
The Relay Server may be set up to autostart by the first RSOE connection.
Concurrent autostarts were unnecessarily failing some of the RSOE connections
that attempted to spawn the state manager (rshost.exe), but lost the race.
This left those losing RSOE connections in an idle failed startup state,
requiring users to restart them. The following error message would have been
shown on the RSOE console and log file:
400 Auto started rshost.exe but it exited with return code <?>.
This has been fixed by suppressing the startup error for the failed connections,
as long as the connections can attach to the stage manager started by others.
================(Build #2333 - Engineering Case #594914)================
The Relay Server had been relying on standard http cookie reflection or header
reflection from the client to maintain affinity of the http session. However,
some mobile devices suffer from thin http support, where both cookie and
header reflection are not supported. So, the Relay Server Outbound Enabler
(RSOE) now injects an IAS-RS-AFQ header at the first HTTP request of all
session. The value of the header is the affinity token for the rest of the
request belonging to the session. The backend server is responsible for transporting
the affinity token to their client in their application protocol. The client
is responsible for inserting the following query parameter to the query string
of the subsequent responding URL.
IAS-RS-AFQ=<affinity_token>
The relay server will respect this affinity control when affinity information
was not found in standard cookie nor in proprietary header.
================(Build #2332 - Engineering Case #594922)================
The Relay Server at log level 3+ will produce packet header logging in the
RS-OE protocol. The Relay Server at log level 5+ will also produce packet
header logging plus the hex dump of the payload. This has been changed to
now suspress level 3 packet header logging when verbosity level is 5 or above.
================(Build #2332 - Engineering Case #594917)================
Backend farm Outbound Enabler security requirements and client security can
be specified by client_security and/or backend_security properties of the
backend farm in the Relay Server configuration file. These setting were not
enforced though until the first Relay Server configuration update. This problem
has now been fixed so that these setting are enforced immediately after Relay
Server startup.
================(Build #2331 - Engineering Case #595624)================
The Relay Server Outbound Eeabler (RSOE) will verify routing of the relayed
packets, and issue session mismatch errors when a routing issue occurs. One
of the verifications was checking against a session finger print (sfp). The
error message contained useful elements like session index, observed sfp
and expected sfp, but the message being logged in the RSOE log was mangled
so that it was not possible to use the detail information in the message
to diagnose routine issues effectively. This has now been corrected.
================(Build #2270 - Engineering Case #580636)================
The Relay Server can be started automatically by the first Relay Server Outbound
Enabler (RSOE) connection, but the connection may have failed within 1.5
seconds if the Selay Server's configuration file was too big. Thhe Relay
Server will eventually have finished starting, but the RSOE would not have
attempted to reconnect to the Relay Server. This has been fixed by allowing
15 seconds for the Relay Server to startup before giving up the the RSOE
connection. RSOE reconnect attempts will be fixed in a separate issue.
================(Build #2262 - Engineering Case #576448)================
When run on Unix systems, if the redirector was configured to route to more
than one backend, and one of the backend servers went down, the redirector
could have failed to route requests to the live backend. In this case, the
redirector would have added the error message "No machine is available
to handle request" to the error log. This has been fixed.
================(Build #2255 - Engineering Case #575539)================
If the Relay Server Outbound Enabler (RSOE) was connected to an Apache RelayServer,
and then RSHOST was shutdown through a command line (rshost -s), then this
would have caused the RSOE's up channel to enter a loop and issue an "Invalid
opcode!" error message. This has been fixed.
================(Build #2226 - Engineering Case #570144)================
The Relay server's configuration file has a 64k size limit that, if exceeded,
can caused the Relay Server to fail on start up. This limit has been removed.
This limit was not affecting dynamic growth of configuration.
================(Build #2221 - Engineering Case #575538)================
When the Relay Server Outbound Enabler's attempts to re-establish its channels
to a Relay Server failed (for example, RelayServer still down), it could
have occasionally quit further attempts. This has been fixed.
================(Build #2218 - Engineering Case #569516)================
The Relay Server Outbound Enabler (RSOE) may have produced bad http requests.
While relaying a packet of a http request, the RSOE would have reconnected
to the backend server when the connection was lost, even if it was at the
request boundary, producing a bad http request. This has been fixed by introducing
a reconnect retry at request boundaries to improve robustness, and replace
reconnect with an error for non-boundary packets.
================(Build #2214 - Engineering Case #569513)================
When an error or a timeout was detected between request phases of an http
request-response cycle, the Relay Server outbound Enabler was not disconnecting
the backend in a timely manner. This has been corrected.
================(Build #2211 - Engineering Case #569520)================
Dynamically added backend server farms, or servers, may have been incorrectly
disabled. This is fixed.
================(Build #2176 - Engineering Case #577984)================
When the Relay Server Outbound Enabler (rsoe) was shutdown, the message "<UpChannel-xxxx>
networkRead: interrupted error errCode: 218, sysCode: 0" was written
to the log file. This is a lower level error indicating the blocking read
operation had been interrupted. This error message is redundant and confusing,
and has been removed. An informational message will still be printed at a
higher level.
================(Build #2166 - Engineering Case #563132)================
An adddition fix was needed to avoid a boundary mis-routing problem introduced
by the original fix for Engineering case 561378.
================(Build #2164 - Engineering Case #563118)================
If a communication error occurred at an early stage of the Relay Server Outbound
Enabler (rsoe) attempting to establish the up channel with the Relay Server,
the RSOE would have continued to fail to reconnect forever. This has been
fixed. The workaround is to restart the RSOE.
================(Build #2164 - Engineering Case #563117)================
When the Relay Server Outbound Enabler (rsoe) was started with http instead
of https (i.e. -cr https=1;... ), it would not have been able to communicate
with a newly added relay server. The workaround is to restart rsoe. This
has been fixed.
================(Build #2157 - Engineering Case #561816)================
The Relay Server State Manage (rshost) would have crashed if its configuration
file was missing or invalid, or if a non-switched command line argument was
used (i.e. one that was not preceded with '-' in Unix, or '-' or '/' in Windows).
This has been fixed.
================(Build #2156 - Engineering Case #561378)================
The Relay Server Outbound Enabler could have logged one of the following
error messages in the log file:
"Failed to retrieve session[x]"
or
"Session mismatch: session[x].snum=y instead of z"
or
"Session mismatch: session[x].sfp=y instead of z".
when a client unexpectedly disconnected from a Relay Server in the middle
of sending a request, or receiving a response. These errors would have happened
in a Relay Server farm environment with more than one Relay Servers in the
farm and in particular, in the general case when using an Afaria client or
a QAnywhere client running a listener. This has now been fixed.
================(Build #2119 - Engineering Case #552638)================
The Relay server may have run out of shared memory when under high load.
This was more likely to have occurred when the Relay Server was hosting a
large number of backend servers. This has been fixed by leaving spare room
in shared memory according to the startup configuration. The user specified
amount of shared memory is left for relaying traffic.
================(Build #2608 - Engineering Case #670360)================
The SQL Anywhere synchronization/replication components, including the MobiLink
client (dbmlsync) and SQL Remote (dbremote), could have given the error 'No
off-line transaction log file found and on-line transaction log starts at
offset XXXXX'. This would have occurred:
1) if no transaction-logs-directory was given on its command line; and
2) if the length of the transaction log name including its absolute path
was greater than 128 bytes.
This problem is now fixed and the length of the transaction log name plus
its absolute path has been extended to 1024 bytes.
================(Build #2575 - Engineering Case #662639)================
When a SQL Anywhere database is used as a remote database, the MobiLink client
(dbmlsync) generates a remote ID which is a GUID for the database during
the first synchronization. This remote ID is used by the Mobilink server
to identify the remote. MobiLink keeps a list of synchronizing remotes in
the ml_database table. When a blank padded SA database was used as a remote,
a remote ID would have been generated during the first synchronization,
sent to the MobiLink server and stored in the ml_database table. On all
subsequent synchronizations, a blank padded version of the remote id would
then have been sent. The results of this were:
1) The server would not have been recognized on the second sync that the
same remote was synchronizing and would treat the second sync as a first
sync. That is to say the server would not have used state information it
had from the first sync when processing the second. Third and subsequent
sync's were not affected. This would have had no impact unless the first
synchronization had failed.
2) Two entries would have been made in the ml_database table for each remote.
One would contain the blank padded remote id and the other would contain
the unpadded id.
This behaviour has now been fixed. Now, on first synchronization the remote_id
assigned to the remote database will be blank padded.
================(Build #2551 - Engineering Case #655953)================
Several memory leaks have been fixed in the MobiLink client. These leaks
would primarily affect applications using the dbmlsync API.
================(Build #2543 - Engineering Case #653930)================
The Console utility could have stopped refreshing database and/or server
properties after changing the set of properties which were displayed, even
after it was restarted. The problem was sensitive to the speed with which
properties were selected or unselected. This has been fixed.
================(Build #2535 - Engineering Case #650856)================
Synchronizations using HTTP-based communication protocols (including HTTP,
HTTPS and other encrypted HTTP protocols) could have failed intermittently.
When synchronizations failed, they would do so after the download had been
applied and committed, and would have reported an error message like: "Data
read failed. Requested 2 bytes but got 0 bytes." When this occurred
the MobiLink server would have reported the error: "Connection was dropped
due to lack of network activity". These failures were only likely to
occur when applying the download to the remote database took longer than
the stream timeout interval, which is 4 minutes by default. This problem
has now been resolved
================(Build #2529 - Engineering Case #647851)================
During HTTPS synchronizations, MobiLink clients could have crashed in MobiLink's
RSA encryption library. This has been fixed.
================(Build #2492 - Engineering Case #638770)================
When using the Dbmlsync API (either the C++ or .Net version), events are
retrieved using the GetEvent method. One of the events that might be returned
is DBSC_EVENTTYPE_PROGRESS_INDEX, which includes an integer that is supposed
to be between 0 and 1000 and indicates how close the current phase of synchronization
is to completion. This value is intended to be used to update a progress
indicator. Occasionally, the DBSC_EVENTYPE_PROGRESS_INDEX events would have
been generated with values greater than 1000. This happened during the log
scan phase of synchronization, when the -x command line option or the LogRenameSize
sychronization profile option was used. It could also happen if operations
were occurring to the remote database during synchronization. This has been
fixed. The index should now always be between 0 and 1000.
================(Build #2481 - Engineering Case #638242)================
In rare situations, when multiple instances of the MobiLink client (dbmlsync)
were run concurrently on the same machine, one or more of the instances may
have crashed. It was possible that this problem might also have manifest
itself as corrupt data sent to the MobiLink server, but that would have been
extremely unlikely. This behaviour has been fixed.
================(Build #2477 - Engineering Case #637333)================
When using the ADO.NET Provider with a .NET Framework 4.0 Client Profile,
Visual Studio 2010 generated some compile errors. This problem has been fixed.
================(Build #2474 - Engineering Case #636557)================
Attempting to delete properties and transmission rules from the clients defined
within a Server Message Store, could have failed either with or without an
error message. This has been fixed.
================(Build #2466 - Engineering Case #635072)================
Specifying a single, empty authentication parameter on the dbmlsync commandline,
or using a synchronization profile, would have caused dbmlsync to report
"out of memory". For example specifying the following on the commandline
would have caused the error:
-ap ""
This problem has been fixed.
Note, a workaround is to specify the parameter using a single comma. For
example -ap , This passes a single empty authentication parameter but does
not cause the "out of memory" error.
================(Build #2376 - Engineering Case #615855)================
The MobiLink client (dbmlsync) could have crashed on shutdown when run on
linux systems.
This problem also affected applications using dbmlsync through the dbtools
interface. They could have crashed when DBToolsFini was called. This has
now been fixed.
================(Build #2375 - Engineering Case #614625)================
The MobiLink client would have ignored the command line option -a. This
has been fixed.
================(Build #2358 - Engineering Case #609062)================
The MobiLink client (dbmlsync) was leaving a small fixed amount of memory
unfreed on shutdown. This should not have been visible to users, and has
now been fixed.
================(Build #2335 - Engineering Case #594317)================
If a synchronization had failed during the download, but before MobiLink
had been able to generate any data for the download, then the MobiLink server
would have placed the synchronization in the restartable state. When the
same remote database synchronized again, there was a chance that the MobiLink
server would not have been able to find the previous synchronization to cancel
it, preventing the remote database from synchronizing. This problem has now
been fixed.
A workaround to this problem would be to stop and start the MobiLink server.
================(Build #2317 - Engineering Case #590633)================
Symbols from the Dbmlsync C++ API could pollute the user's default namespace.
These symbols are now segregated into their own namespace named "DbmlsyncClient11".
Existing Dbmlsync C++ API applications will still be able to compile without
modification, since the dbmlsynccli.hpp header file now also includes "using
namespace DbmlsyncClient11". Those wishing to exclude the USING command,
and be forced to reference the symbols using the namespace, can define a
macro called MULTIPLE_DBMLSYNC_API_VERSIONS in their source code.
================(Build #2272 - Engineering Case #580190)================
If an error had occurred while the MobiLink client (dbmlsync) was applying
a download, and there had also been referential integrity errors that dbmlsync
could not resolve, then dbmlsync would have reported that the download had
been committed, even though it had been rolled back. This has been corrected
so that dbmlsync now correctly reports that the download was rolled back.
================(Build #2268 - Engineering Case #579404)================
If MobiLick Client (dbmlsync) had been running as a server, and a client
application had executed the ShutdownServer() method, the exit code from
the dbmlsync executable would have been EXIT_FAIL, which indicated a general
failure. This would also have resulted in the progress message text changing
to "Synchronization Failed" on shutdown, although it was difficult
to see on a desktop system. The dbmlsync executable now returns EXIT_OKAY
in this situation, which also results in the progress message text changing
to "Synchronization Succeeded" on shutdown.
================(Build #2244 - Engineering Case #572196)================
It was possible for the MobiLink client (dbmlsync) to have sent an incorrect
last download timestamp up to the MobiLink server, if dbmlsync had been running
on a schedule, and ALL of the following had occurred during the last synchronization
:
1) All of the data in the download stream had been applied, but had not
yet been committed to the remote database.
2) An SQL Error had been generated by dbmlsync before the download had been
committed. Examples of errors that could have occurred include an error occurring
in the sp_hook_dbmlsync_download_ri_violation or the sp_hook_dbmlsync_download_end
hooks, or an error occurring as dbmlsync had attempted to resolve referential
integrity issues.
3) Another hook had been defined in the remote database that would have
executed on another connection. For example, the sp_hook_dbmlsync_download_log_ri_violation
or the sp_hook_dbmlsync_all_error hooks would have executed on a separate
connection.
This problem has now been fixed, and the proper last download timestamp
is now sent up to the MobiLink server in the synchronization when this situation
occurs.
================(Build #2228 - Engineering Case #570503)================
When using secure streams and an invalid TLS handshake occured, the MobiLink
server could have waited for a full network timeout period before disconnecting.
This has been fixed. The MobiLink server will now immediately terminate the
network connection with a "handshake error" error message.
================(Build #2217 - Engineering Case #569013)================
MobiLink clients and the certificate utilities would have failed to read
PEM-encoded trusted certificates files which contained blank lines before
the first PEM header. The PEM parsing code has now been modified to skip
leading white space characters.
================(Build #2205 - Engineering Case #567932)================
Client-side certificates can now be used to authenticate MobiLink clients
to third party server and proxies. The following two synchronization parameters
have been added to provide support for this feature:
identity - Indicates the file that contains the client's identity. An identity
consists of the client certificate, the corresponding private key, and, optionally,
the certificates of the intermediary certificate authorities. This parameter
is equivalent to MobiLink server's 'identity' parameter.
identity_password - An optional parameter that specifies the password used
to encrypt the private key found in the identity file. It is only required
if the private key in the identity file is encrypted. This parameter is
equivalent to MobiLink server's 'identity_password' parameter.
Note that MobiLink clients cannot authenticate directly to the MobiLink
server using client-side certificates. They can only be used to authenticate
to third-party servers and proxies which have been configured to accept client-side
certificate authentication and are sitting between the client and MobiLink
server.
Also note, this feature is not supported in UltraLiteJ, and because of ECC
compatibility issues between different versions of Certicom's Security Builder
libraries, it is also not supported when using ECC TLS. It is only supported
for RSA TLS.
================(Build #2182 - Engineering Case #563844)================
The MobiLink client (dbmlsync) would have occationally reported the error:
Failed writing remote id file to '<filename>'
Despite the error, synchronizations would have continued successfully, and
the remote id file would have appeared on the disk in good order. This problem
has been fixed.
================(Build #2181 - Engineering Case #565441)================
Changes have been made to the MobiLink client to accomodate the changes made
to the MobiLink server for Engineering case 563839. Therefore, running the
11.0.1 GA MobiLink server with SQL passthrough enabled (i.e. rows have been
added to the ml_passthrough_script table), with 11.0.1 MobiLink clients (dbmlsync)
from an EBF will cause synchronizations to fail with the message:
This client is newer than your MobiLink server. You must upgrade your MobiLink
server before you can synchronize.
In order to resolve this problem, the MobiLink server must be upgraded as
well. As a temporary work around, SQL Passthrough can be disabled by deleting
all the rows in the ml_passthrough_script table and restarting the Mobilink
server.
================(Build #2166 - Engineering Case #563171)================
The MobiLink server would have failed synchronizations from version 10.0.1
and later clients, when they connected via HTTP. The error would have been
'HTTP error 404' (not found), and most clients would have reported this as
the error. This has been fixed.
================(Build #2158 - Engineering Case #562027)================
When running on Sun SPARC systems, the MobiLink client (dbmlsync) would have
complained about "missing transaction log files", if there were
any offline transaction log files bigger than 2GB. This problem now been
fixed.
================(Build #2156 - Engineering Case #560943)================
The dbmlsync ActiveX component was not able to launch the dbmlsync application
properly on Windows if some or all of the dbmlsync options are given by a
file, and the dbmlsync command line contained the option @filename. This
problem has now been fixed.
================(Build #2136 - Engineering Case #555444)================
When synchronizing using HTTPS through an HTTP proxy, MobiLink clients would
have incorrectly appended the url_suffix to the HTTP CONNECT request, which
could have caused some proxies and servers to fail. This has been fixed.
================(Build #2122 - Engineering Case #551953)================
It was possible for the MobiLink client .NET API to have thrown an unhandled
socket exception when attempting to disconnect from a socket that had been
forcibly closed by the operating system. This exception is now caught and
handled within the dbmlsync .NET API.
================(Build #2119 - Engineering Case #551433)================
Calling to the StartServer or WaitForServerShutdown methods when using the
Dbmlsync .NET API, would have caused problems for some values of the timeout
parameter. If the timeout value was greater than 2147483647, the WaitForServerShutdown
method would always have returned DBSC_ERR_TIMED_OUT, and the StartServer
method would also have returned DBSC_ERR_TIMED_OUT, unless the call was able
to connect to an existing dbmlsync server on the port specified. The calls
will now treat values greater than 2147483647 as equivalent to DBSC_INFINITY.
================(Build #2588 - Engineering Case #665837)================
The changes for Engineering case 661112 introduced a bug where the MobiLink
client could have crashed, or the check of the certificate_name, certificate_company,
or certificate_unit could have failed, if any of the certificate fields were
encoded as Unicode in the server's certificate. This has been fixed.
================(Build #2546 - Engineering Case #650719)================
After a failed download, an attempt to restart the download may have failed
and reported a "Protocol Error" or a read failure. This has been
fixed.
================(Build #2541 - Engineering Case #653470)================
MobiLink clients (except UltraLiteJ) could have failed to authenticate to
third party servers or proxies when using digest HTTP authentication. In
particular, if the third party server's or proxy's response contained nextnonce
attribute in the Authentication-Info header. This has been fixed.
================(Build #2521 - Engineering Case #649135)================
MobiLink clients (except UltraLiteJ) could have failed to authenticate to
third party servers when using digest HTTP authentication. In particular,
it would have failed when the algorithm was "MD5-Sess" instead
of "MD5". This has been fixed.
================(Build #2482 - Engineering Case #638492)================
For MobiLink clients, except UltraLiteJ, it was possible to receive an "Out
of memory" or STREAM_ERROR_MEMORY_ALLOCATION error during TLS or HTTPS
synchronizations. Incorrectly attempting a very large memory allocation has
bee fixed.
================(Build #2344 - Engineering Case #488676)================
The HTTP option 'buffer_size' was limited to 64000 (64KB). On slow networks
and/or large uploads or downloads, the overhead due to HTTP could have been
significant. The 'buffer_size' option is now limited to 1000000000 (1GB).
When using slow networks to perform HTTP or HTTPS synchronizations, tests
could be done with larger values for 'buffer_size' to see if synchronization
times improve.
For versions 11.0.1 and up, this change only applies to the -xo option of
the MobiLink server. The -x option already allows larger values.
================(Build #2236 - Engineering Case #571465)================
If a network error occurred in the MobiLink Monitor, the SQL Anywhere Monitor,
QAnywhere, or the Notifier, there could have been garbage characters trailing
the error string.
For example:
"The server monitor was unable to contact the MobiLink server. The
host 'mlstress02' is still available. Error: Timed out trying to read 128
bytes. rWms"
This has been fixed.
================(Build #2203 - Engineering Case #567754)================
When providing a list of DER-encoded trusted root certificates to a MobiLink
client for TLS synchronization, the client only accepted the first item in
the list and ignored the rest. There was no problem if the list of certificates
was PEM-encoded. This has been fixed.
Note that this problem affected all MobiLink clients except UltraLiteJ.
================(Build #2159 - Engineering Case #562083)================
The MobiLink server could have silently ignored bad HTTP requests. In particular,
subsequent requests received by MobiLink server B, for a session started
in MobiLink server A, would have been silently ignored. The error was particularly
likely to appear if an HTTP intermediary was misbehaving and sending different
HTTP requests for the same session to different MobiLink servers. This has
been fixed, and this case will now issue an error.
================(Build #2609 - Engineering Case #669465)================
The MobiLink server could have crashed when handling restartable downloads
and the restartable download cache was too small to hold all possible restartable
downloads at one time. This has been fixed.
================(Build #2582 - Engineering Case #632219)================
The MobiLink server running in a server farm against the cluster edition
of a consolidated database, would have shutdown too quickly when the node
the MobiLink server was connecting to was killed or shut down. This problem
has been fixed. When the MobiLink server detects the database connection
unusable, it will now attempt to re-establish a connection and pause for
1 second before each retry. By default, the number of retries is 3. Therefore,
it would allow the ODBC driver to switch the MobiLInk server database connections
to another node within 3 seconds. If the failover of the consolidated database
takes more than 3 seconds, the MobiLink server command line option -cr <num>
can be used to change the number of retries.
================(Build #2568 - Engineering Case #660428)================
The MobiLink server could have crashed during shutdown if user spawned Java
threads printed to System.out or System.err after the ShutdownListeners were
notified of shutdown. This has been made much less likely to happen. A work
around is to ensure all user threads are stopped before the ShutdownListeners
return.
================(Build #2562 - Engineering Case #658453)================
When using MobiLink synchronization and timestamp-based downloads with an
Oracle Real Application Cluster (RAC) system, there is a chance of missing
rows to be downloaded if the clocks of the Oracle cluster nodes differ by
more than the time elapsed between the MobiLink server fetching the next
last download timestamp and fetching the rows to be downloaded. This problem
is unlikely on a RAC system with synchronized node clocks, but the likelihood
increases with larger node clock differences. A workaround is to create either
a modify_next_last_download_timestamp or modify_last_download_timestamp script
to subtract the maximum node clock difference.
Note that at least since version 10i, Oracle has recommended using Network
Time Protocol (NTP) to synchronize the clocks on all nodes in a cluster,
and NTP typically runs by default on Unix and Linux. With cluster nodes properly
configured to use NTP, their clocks should all be within 200 microseconds
to 10 milliseconds (depending on the proximity of the NTP server). Since
Windows Server 2003, the Windows Time Service implements the NTP version
3 protocol and it runs by default. Also, as of version 11gR2, Oracle Clusterware
includes the Oracle Cluster Time Synchronization Service (CTSS) to either
monitor clock synchronization or, if neither NTP or Windows Time Service
is running, it will actively maintain clock synchronization. However CTSS
and Windows Time Service are less accurate than NTP,
To avoid missing rows when Oracle RAC node clocks differ by up to one second
more than the time between fetching the next_last_download_timestamp and
the rows to be downloaded, now the MobiLink server will subtract one second
from the next_last_download_timestamp fetched from the consolidated database,
if
1) the Oracle account used by the MobiLink server has execute permission
for SYS.DBMS_UTILITY,
2) the consolidated database is an Oracle RAC system,
and (only for MobiLink version 12.0.0 and up)
3) there is no generate_next_last_download_timestamp script.
For Oracle RAC node clocks that may differ by greater amounts, you can avoid
the problem by defining a generate_next_last_download_timestamp, modify_next_last_download_timestamp
or modify_last_download_timestamp script to compensate for the maximum node
clock difference.
================(Build #2539 - Engineering Case #652609)================
When using Oracle as a back-end database, synchronizations may have failed
with the error ORA-08207. This has been fixed.
================(Build #2538 - Engineering Case #652263)================
The usage text for the Relay Server Outbound Enabler didn't describe what
were the valid options for the -cr option. This has been corrected so that
the values are now listed for the tcp options, server certificate options,
and client certificate options.
In addition, http authentication options, proxy options, and proxy authentication
options, have been added in version 12.0.1.
================(Build #2528 - Engineering Case #647345)================
The data for an upload stream may not have been fully uploaded into the consolidated
database if the consolidated database was running on Microsoft SQL Server
and errors occurred in the upload. For this to have occurred, the connection
property, XACT_ABORT must have been set 'ON' in the consolidated database,
and the handle_error script must have returned 1000 (skip the row and continue
processing). This problem has now been fixed.
================(Build #2518 - Engineering Case #646269)================
The MobiLink Server could have crashed under heavy load if the client load
was a mix of old (prior to version 10) and new (version 10 or later) clients.
THis has now been fixed.
A work around is to specify the -cn switch with a value of the twice the
value of -w plus 1. Eg. if using the default value of -w (5), specify -cn
11. Version 12 is not affected as it no longer supports old clients.
================(Build #2510 - Engineering Case #642568)================
If a synchronization failed with a protocol error, some later synchronization
could have failed with a translator or right truncation error. It was also
possible that instead of failing, the later sync could have made use of the
failed syncs to, for example, insert it into the consolidated. These issues
have been fixed.
================(Build #2493 - Engineering Case #639825)================
The 32-bit authentication value sent to MobiLink clients was being truncated
to 16-bits. This has been fixed. In order to use this fix, both clients
and server must be updated. If the use of this fix is not required, it is
not necessary to upgrade both the clients and server.
================(Build #2490 - Engineering Case #639012)================
The script events publication_nonblocking_download_ack, nonblocking_download_ack
and generate_next_last_download_timestamp may have incorrectly been passed
the client Remote ID. This would have occurred for non-SQL scripts as well
as SQL scripts that used the question mark notation. This has been fixed
so that the Remote ID is no longer passed to these scripts.
Note that the documentation is correct.
================(Build #2489 - Engineering Case #637309)================
The MobiLink server could have crashed at the end of a version 9 or earlier
synchronization request, or while processing the upload stream from a version
10 or later synchronization request.
Also, the MobiLink server was not able to distinguish between empty strings
in varchar(8) or smaller columns, binary(16) or smaller values made of only
0s, the integer 0, and null values when filtering the download. This could
have caused rows to be incorrectly filtered from the download. For example,
if an empty string was uploaded in a row, and the only difference between
a downloaded row and that uploaded row was that the empty string became null,
the row would have been ommitted from the download and the remote would not
have received that update.
These issues have been fixed.
================(Build #2477 - Engineering Case #636715)================
The iAS ODBC driver for Oracle would have returned a wrong value for a parameter
indicator through the ODBC API, SQLBindparameter( ..., c_type, ..., param_type,
..., &indicator ), if it was called with the following parameters:
1) the C data type of the parameter was SQL_C_WCHAR or SQL_C_CHAR
2) the type of parameter was SQL_PARAM_INPUT_OUTPUT, but the corresponding
parameter used in the SQL statement was input-only
Due to this problem, the data for the user-defined named parameters in the
MobiLink server may have been truncated after each use when the named parameter
was defined as {ml u.varname} and the parameter used in the SQL statement
was input-only. This has now been fixed.
================(Build #2476 - Engineering Case #637169)================
Starting with Visual Studio 2010, class libraries built with with the default
project settings will no longer work with a MobiLink server running with
its default CLR version. There are two workarounds for this:
1) Change the target Framework of the VS project.
When creating a new project, there is a drop down above the list of project
types that contains ".NET Framework 4"; change this to ".NET
Framework 2.0", ".NET Framework 3.0", or ".NET Framework
3.5". If a version 4 project has already been created, change the target
framework by right-clicking on the project in the Solution Explorer, and
selecting "Properties" in the context menu. The target framework
can be set on the "Application" tab. When changing the target framework,
there is no longer access to .NET 4.0 features; to use newer features, use
the next workaround.
2) Tell the MobiLink server to load the version 4 framework.
To do this, add -clrVersion=v4.0.30319 to the -sl dnet options. The
"30319" is the specific build number of the framework installed
and may be different on your machine. To find the correct version, look
in the .NET install location, which is typically "c:\WINDOWS\Microsoft.NET\Framework\".
The clrVersion to specify is the v4.0 sub-directory there.
================(Build #2459 - Engineering Case #622866)================
If the MobiLink Server had been started with the "-xo http" or
"-xo https" command line options to accept http[s] synchronizations
from version 9 or lower MobiLink clients, and the port that was listening
for synchronizations received an HTTP request from an HTTP client other than
an UltraLite or SQL Anywhere MobiLink client (for example, a web browser),
the MobiLink Server would have reported an HTTP error to the HTTP client,
posted an error to the ML Server log, but would not have freed the worker
thread in the ML Server. Multiple requests from other HTTP clients would
have eventually resulted in no threads available to handle additional synchronizations.
This has now been fixed, and the worker thread is returned to the pool of
available worker threads after the error is reported.
================(Build #2454 - Engineering Case #632869)================
Using the -ppv command line option ("print periodic performance values")
could have degraded the MobiLink server's performance if there were many
unsubmitted error reports. This was most noticable when using -ppv 1, and
there were more than one thousand unsubmitted reports. This has been fixed
by removing the NUM_UNSUBMITTED_ERROR_RPTS value from the -ppv output. The
number of unsubmitted error reports can still be found by using the SQLAnywhere
Monitor for MobiLink, or by counting the lines output by "dbsupport
-lc".
================(Build #2451 - Engineering Case #632519)================
Changes made to INOUT script parameters in .NET scripts were ignored unless
the script accepted all the possible parameters for the event. This has
been fixed.
================(Build #2448 - Engineering Case #632040)================
On 64-bit systems, it was possible for the JDBC driver to crash if some statement
attributes were queried. This has now been fixed.
================(Build #2447 - Engineering Case #631119)================
If the empty string was passed into an SQLNativeSQL or SQLPrepare function,
it was possible for the iAS Oracle ODBC Driver to have crashed. This has
been fixed. The SQLPrepare function will now return the error "Invalid
string or buffer length", and the SQLNativeSQL function will now simply
set the out parameters to the empty string as well.
================(Build #2443 - Engineering Case #631280)================
The MobiLink Server could have hung or crashed on MacOSX 10.6 systems when
the server was run as a daemon (using the -ud command line option). This
has been fixed.
================(Build #2436 - Engineering Case #629058)================
A Java VM running inside the MobiLink server could have run out of memory
if the server had many requests with different script versions and some sync
scripts made calls to DBConnectionContext.getConnection(). This has been
fixed.
================(Build #2401 - Engineering Case #623115)================
Sometimes, when printing the error -10193, "Unable to load Assembly
... into domain ...", the MobiLink server would have failed to print
why it failed to load the assembly. Also, the MobiLink server would have
spuriously printed this error whenever it failed to find a class in the loaded
assemblies. These issues have now been fixed.
================(Build #2401 - Engineering Case #620985)================
The MobiLink server would have reported the error, ".NET CLR Host encountered
unexpected error." (SQLCODE -10167), instead of error, "Assembly
'%1!s!' does not contain '%2!s!'" (SQLCODE -10172), when a .NET method
could not be found. This has been fixed.
================(Build #2380 - Engineering Case #616196)================
Older MobiLink clients (prior to Version 10) would have caused the server
to log a Protocol Error, when attempting to restart a download. This has
been fixed. Restartable downloads for older clients is not supported, so
the server will now log the restart failure and send a status code to the
client.
================(Build #2376 - Engineering Case #614417)================
The MobiLink server could have crashed when processing a synchronization
request from a client, if the client was older than version 10 and was syncing
UUID columns. This has been fixed.
================(Build #2376 - Engineering Case #611373)================
The MobiLink server could have occasionally given the following error:
A downloaded value for table 'table_name' (column #column_number) was either
too big or invalid for the remote schema type
and then aborted the synchronization, when a client was trying to download
data from a table that contained NCHAR, NVARCHAR or LONG NVARCHAR columns,
even when NCHAR, NVARCHAR or LONG NVARCHAR data was uploaded in a previous
synchronization. This problem has now been fixed.
================(Build #2365 - Engineering Case #611414)================
When using the iAS Oracle ODBC driver, attempting to execute an INSERT, UPDATE,
or DELETE statement with SQLExecDirect immediately after executing a SELECT
statement with the same statement handle, would have failed with the following
error message:
ORA-24333: zero iteration count
This problem is fixed now.
================(Build #2363 - Engineering Case #609707)================
When running the MobiLink server in a server farm, it was possible for the
MobiLink server to have printed errors to the MobiLink log that dealt with
problems on operations to the ml_active_remote_id table. These errors are
now suppressed, and more meaningful warnings or errors are printed to the
MobiLink log.
================(Build #2344 - Engineering Case #605651)================
The MobiLink server would have thrown the exception IllegalCastException
when assigning the null reference to the Value property of an IDataParameter
when using the MobiLink Direct Row API to download data. This has been fixed.
A work around is to assign DBNull.Value instead.
================(Build #2321 - Engineering Case #591002)================
The changes for Engineering case 582782 could have caused the MobiLink server
to be much slower for small sync than servers without the fix. This problem
would have occurred when a consolidated database was running on an Oracle
RAC. The slowness is in the Oracle server: fetching the minimum starting
time of the open transactions from gv$transaction can take as much as a couple
of seconds and it is much slower than from v$transaction. This has now been
corrected.
================(Build #2320 - Engineering Case #589236)================
The MobiLink server could have crashed following a failed synchronization.
This has now been fixed.
================(Build #2315 - Engineering Case #590061)================
If a MobiLink server had a connection from a MobiLink Monitor, or a SQL Anywhere
Monitor, it could have hung while printing warning 10082, "MobiLink
server has swapped data pages to disk ... ". This was due to a deadlock
between the thread printing the warning and a thread sending a monitor event.
This has been fixed.
================(Build #2297 - Engineering Case #585456)================
The queue lengths in the Utilization Graph of the MobiLink Monitor could
have been incorrect and the RAW_TCP_STAGE_LEN, STREAM_STAGE_LEN, HEARTBEAT_STAGE_LEN,
CMD_PROCESSOR_STAGE_LEN metrics printed by the -ppv option could also have
been incorrect. These issues have now been corrected.
================(Build #2296 - Engineering Case #585258)================
The MobiLink server would not have shown any script contents, if the scripts
were written in Java or .NET, even when the verbose option (-vc) was specified
in its command line. This problem is fixed now.
================(Build #2288 - Engineering Case #584310)================
Download performance of the MobiLink server has been improved for tables
that contain no BLOB columns, when the consolidated database is running on
Microsoft SQL Server.
================(Build #2280 - Engineering Case #581426)================
When the number of concurrent synchronizations was greater than the maximum
number of concurrent active synchronizations specified by the -sm command
line option, the MobiLink server would have quietly rejected any synchronization
requests without showing any error or warning messages. This has been fixed.
The MobiLink server will now issue the following warning message:
[10101] Synchronization request from client '?' was rejected
where ? is the rejected remote ID. A more complete description of this warning
code can be found in the documentation.
================(Build #2279 - Engineering Case #582782)================
When a consolidated database was running on an Oracle RAC, the MobiLink server
could have skipped rows being downloaded to remote databases in a time-based
download. In the following situations, rows modified in the Oracle database
could be missed from the download stream:
1) the MobiLink server connected to one node on an Oracle RAC;
2) another application, A connected to another node on the same Oracle RAC;
3) application A modifies rows in a synchronization table without commit;
4) a MobiLink client, R1 issues a synchronization request that contains
a time-based download from this table;
5) the MobiLink server completes the synchronization request successfully;
6) A commits its transaction;
Then the rows modified by application A would not be down loaded to remote
R1. This problem has now been fixed.
Note, as a result of this change, the Oracle account used by the MobiLink
server must now have permission for the GV_$TRANSACTION Oracle system view
instead of V_$TRANSACTION. Only SYS can grant this access. The Oracle syntax
for granting this access is:
grant select on SYS.GV_$TRANSACTION to <user-name>
================(Build #2278 - Engineering Case #582589)================
If 10 MobiLink Monitors or SQL Anywhere Monitors connected to the same MobiLink
server, and the last to connect then disconnected, then the MobiLink server
could have crashed. This has been fixed.
================(Build #2275 - Engineering Case #581755)================
An undocumented feature could have prevented a MobiLink server from starting
when multiple MobiLink servers were trying to start at the same time, against
the same consolidated database. The error displayed would have been:
<main> [-10002] Consolidated database server or ODBC error: ODBC:
[Sybase][ODBC Driver][SQL Anywhere]Primary key for table 'ml_property'
is not unique:
Primary key value("'ML','server_info','release_version''")
(ODBC State = 23000, Native error code = -193)
when the consolidated database was running on a SQL Anywhere server. This
problem has now been fixed.
================(Build #2272 - Engineering Case #580222)================
If the MobiLink Server had been started with "-s 1" command line
option, to indicate that the server should always apply changes to the consolidated
database one row at a time, then the MobiLink Server would still have executed
SAVEPOINT commands. SAVEPOINT commands are not needed when running in single
row mode, so they are no longer executed when the MobiLink Server had been
started with "-s 1".
================(Build #2260 - Engineering Case #577142)================
The MobiLink server would not have skipped a script that was defined to be
ignored, if the script contained white space (spaces, tabs, and/or line-breaks)
before the special prefix, '--{ml_ignore}'. This problem is fixed now.
================(Build #2248 - Engineering Case #573456)================
On Windows x64 systems, attempting to start the MobiLink server with the
-xo command line option (specify network protocal and options for version
8 and 9 clients), would have failed with a missing dll error if HTTPS was
requested. The dll mlhttps11.dll was missing from the install. This has been
corrected.
================(Build #2236 - Engineering Case #567906)================
The MobiLink server could have crashed when multiple -x options were specified
on the command line, with at least one being HTTP and another being HTTPS.
This could have happened, for example, when a VPN connection was created
or dropped in the middle of a non-persistent HTTP/HTTPS synchronization,
and the network intermediaries were set up such that one path resulted in
HTTP and the other resulted in HTTPS. This has been fixed.
================(Build #2235 - Engineering Case #570690)================
The "Longest Active Synchronization Time" and the "Longest
Active Wait for a Database Worker Thread" metrics were incorrect in
the SQL Anywhere Monitor, and the monitoring values printed by the -ppv options
LONGEST_SYNC and LONGEST_DB_WAIT, would have been incorrect. These metrics
in the Monitor had the incorrect sign, but the absolute values were correct;
essentially the graph was drawn upside down. A side effect of this is that
the alert on these metrics would never be raised. These issues have been
fixed.
================(Build #2229 - Engineering Case #570656)================
If a MobiLink synchronization script included the two characters "ui"
inside an {ml ...} structure for named parameters, and the "ui"
characters were not part of a named parameter, then MobiLink would have incorrectly
replaced the "ui" with a question mark when it sent the command
to the consolidated database. For example, the following script would have
had no problem, since the "ui" in this case was part of the named
parameter "build":
INSERT INTO t1(pk,build) VALUES ( {ml r.pk}, {ml r.build})
However, the following script would have failed, because the "ui"
in the column list for the insert would have been replaced:
{ml INSERT INTO t1(pk,build) VALUES ( r.pk, r.build )}
This has now been fixed.
================(Build #2222 - Engineering Case #565844)================
When using MobiLink servers in a server farm (by specifying the -ss command
line option), servers could have crashed and/or unexpectedly caused failed
synchronizations. The problem was more noticeable in environments with poor
network quality or where retries after synchronization failures occurred
very quickly after the original synchronization. This has been fixed.
================(Build #2222 - Engineering Case #563535)================
Worker threads are created to process the stream data from clients, and perform
the database activities for each synchronization. Two sets of workers were
being created, one set for pre version 10 clients, and another set for current
clients (version 10 and later). Now, when the -xo switch is not specified,
the MobiLink server no longer creates the threads to process the old client
requests.
================(Build #2211 - Engineering Case #574337)================
If MobiLink servers were running in a server farm against a very busy consolidated
database, some of the MobiLink servers may have shutdown automatically, due
to the fact that they were no longer able to maintain their liveness to the
consolidated database. To fix this problem, a new MobiLink server command
line option to supply server farm database connection parameters has been
added:
-ca "keyword=value;..."
This new option can be used to let the MobiLink servers connect to another
database that is running on a less busy database server, and then the MobiLink
servers will use this
second database to maintain their state information for the server farm.
This second database can be running on an SA, ASE, Microsoft SQL Server,
Oracle, DB2, or MySQL database server. However, it must contain the MobiLink
server system objects.
Note, the -ca command line option must be the same for all the MobiLink
servers across the same server farm, otherwise, redundant synchronizations
may not be detected and data inconsistency can happen.
================(Build #2190 - Engineering Case #565651)================
If an application executed a query like "select ... for t where c =
v', where c was a char or varchar column, v was as variable of type nchar
or nvarchar, and t was a proxy table to a remote table in Microsoft SQL Server,
then the query would have failed with SQL Server reporting the error "The
data types varchar and ntext are incompatible in the equal to operator."
This problem has now been corrected.
================(Build #2182 - Engineering Case #564829)================
When the MobiLink server was listening for HTTP and/or HTTPS requests, and
a load balancer or any other utility (eg. the RSOE) performed a simple TCP/IP
connect, then an immediate close without sending any bytes, the MobiLink
server would have taken four minutes to time out the socket. If too many
such connections happened in a short time, the MobiLink server could have
run out of sockets earlier than necessary. This has been fixed.
================(Build #2170 - Engineering Case #563592)================
When run on Windows systems, both the MobiLink server and the Relay Server
Outbound Enabler (RSOE) could have held onto sockets for longer than necessary.
This would have caused both to use up sockets faster than necessary, possibly
exhausting system socket limits. With the RSOE, needless timeouts could also
have occurred. This behaviour was particularly evident with non-persistent
HTTP/HTTPS connections, and appeared to be very much OS and machine dependent.
This has been fixed.
================(Build #2168 - Engineering Case #563405)================
The MobiLink server could have crashed if a IDataReader returned by MLUploadData
was not closed. If the server didn't crash it would have leaked memory. The
crash would have occurred at a random time after the synchronization completed.
This has been fixed.
Note that enclosing the use of the IDataReader in a 'using' block will automatically
close it.
================(Build #2167 - Engineering Case #563404)================
Synchronizations could have failed with protocol errors when some, but not
all, of the parameters for a delete command in the .NET irect row API were
set to DBNull.Value or null. This has been fixed so that an exception will
be thrown when attempting to execute the command.
================(Build #2158 - Engineering Case #562039)================
The start times for synchronizations reported by the MobiLink Monitor and
the MobiLink Server, when used with the -vm option, could have been incorrect
if the MobiLink Server had been running for several days. Also, the output
for the -vm option could have been incorrect if a request used non-blocking
download acks, and phase durations reported by -vm option could have been
slightly different than phase times reported by the MobiLink Monitor. These
issues have now been fixed.
================(Build #2157 - Engineering Case #561813)================
The MobiLink server could have crashed when using the -xo option ("specify
network protocol and options for version 8 and 9 clients"). Monitoring
pre-10.0.0 synchronizations would also have had erratic behaviour. These
issues have been fixed.
================(Build #2145 - Engineering Case #558232)================
The MobiLink Monitor has a default filter which highlights failed synchronizations
in red. Failed synchronizations logged by the MobiLink Server were not being
shown in the Monitor in red as the server was telling the Monitor that every
sync was successful. This has been fixed.
================(Build #2143 - Engineering Case #557686)================
The MobiLink server could not start in a server farm if the consolidated
databases were running on DB2 or DB2 mainframe database servers, and the
MobiLink server in the farm was requested to start with a liveness setting
from the ml_property table (the ml_property table in the consolidated database
contained a liveness value for the server farm). This problem has now been
fixed.
================(Build #2136 - Engineering Case #555616)================
he MobiLink server was allocating more memory than necessary and thus wasting
memory. The amount wasted was approximately equal to 13% of the -cm option
value. This has now been fixed.
================(Build #2135 - Engineering Case #555034)================
Push notifications over a SYNC gateway may have stopped working after the
listener reconnected. The was timing dependent and was more likely to have
occurred when there was a proxy, a redirector, or a relay server being used
between the listener and the SYNC gateway of the MobiLink server. The listener
may have reconnected to the SYNC gateway when the IP address of the remote
device had been changed, when the QAAgent registered with the listener on
startup, or a communication error had occurred. This problem has now been
fixed.
================(Build #2129 - Engineering Case #553748)================
When using the iAS ODBC driver for Oracle, calling SQLColAttribute with an
attribute code of SQL_DESC_TYPE_NAME would not have returned the type names
of columns. This has now been fixed.
================(Build #2124 - Engineering Case #552321)================
If an error or warning occurred when commiting, the MobiLink server would
not have reported any error or warning messages. If it was an error, the
MobiLink server would have just failed the synchronization request without
giving any reasons. This problem is fixed.
================(Build #2586 - Engineering Case #665200)================
The redirector for Apache could have crashed during a synchronization. This
has been fixed.
================(Build #2583 - Engineering Case #664140)================
Sometime the MobiLink Listener (dblsn) could have taken a few minutes to
shutdown if the shutdown was initiated by the QAnywhere Agent (qaagent).
This problem has been fixed.
================(Build #2538 - Engineering Case #652249)================
The title line of the usage screen for the QAnywhere Stop utility (qastop)
may have contained an untranslated character. This has been fixed.
================(Build #2467 - Engineering Case #635175)================
When there was a design problem in the Notifier property (e.g. user defined
a request_cursor referencing an unknown column), the Notifier would have
reported the SQLException on MobiLink server startup, but the error report
did not contain enough context information to pinpoint the issue efficiently.
The Notifier would also have produced repeated NullPointerException in the
MobiLink log after it failed to start. This has been fixed to add context
information in addition to the SQLException and stop the Notifier from running
if it has encountered a design problem.
The following is an example output after the fix.
<Main> [-10133] java.lang.Exception: Notifier(Simple).request_cursor:
Failed to prepare request cursor
<Main> [-10133] at ianywhere.ml.notifier.Notifier.connectDB(Notifier.java:390)
<Main> [-10133] at ianywhere.ml.notifier.Scheduler.connectDB(Scheduler.java:360)
<Main> [-10133] at ianywhere.ml.notifier.Scheduler.run(Scheduler.java:428)
<Main> [-10133] at java.lang.Thread.run(Thread.java:619)
<Main> [-10133] Caused by: java.sql.SQLException: [Sybase][ODBC
Driver][SQL Anywhere]Column 'bogus_content' not found
<Main> [-10133] at ianywhere.ml.jdbcodbc.IConnection.nativePrepareStatement(Native
Method)
<Main> [-10133] at ianywhere.ml.jdbcodbc.IConnection.prepareStatement(IConnection.java:554)
<Main> [-10133] at ianywhere.ml.notifier.Notifier.connectDB(Notifier.java:388)
<Main> [-10133] ... 3 more
<Main> <SISI><Scheduler(0:1)>: Shutdown
<Main> <SISI><Scheduler(0:1)>: Disconnected from database
================(Build #2453 - Engineering Case #631731)================
When starting the MobiLink Monitor with the -o or -c command line options,
the result of the session should have been saved when the MobiLink server
terminated, or the user manually disconnected from the MobiLink server. In
the latter case, the output was not being saved and the Monitor was not shutting
down. This has now been fixed.
================(Build #2452 - Engineering Case #631946)================
An error on startup of the MobiLink server on Mac OS X systems, would have
displayed text that was prefixed by random characters and/or yellow highlighting.
This has been corrected.
================(Build #2451 - Engineering Case #631733)================
When connecting the MobiLink Monitor to a MobiLink server, any authentication
error resulted in a poor error message from the Monitor, like:
"Got unexpected data when receiving authentication result. Check
version of MobiLink server (opcode=0)"
This has been fixed to provide more information on the problem. The most
common authentication error is now:
"Invalid userid or password (auth_status=NNNN)"
Other errors, for example due to an expired password, are similar.
================(Build #2451 - Engineering Case #631643)================
Changes made for Engineering case 585456 caused the queue lengths in the
Utilization Graph of the MobiLink Monitor, the RAW_TCP_STAGE_LEN, STREAM_STAGE_LEN,
HEARTBEAT_STAGE_LEN, CMD_PROCESSOR_STAGE_LEN metrics printed by the -ppv
option, and the queue lengths available in the SQL Anywhere Monitor, to possibly
have been reported as larger than they actually were. These issues have
been fixed.
================(Build #2415 - Engineering Case #624041)================
If the action command in the message handler did not contain any arguments,
the MobiLink Listener may have crashed. This has been fixed.
================(Build #2409 - Engineering Case #622058)================
When MobiLink listeners were connected to a MobiLink server via a persistent
sync gateway connection, shutting down the listener would have caused the
MobiLink server to report "Ping request failed" as an informational
message. This message was non-harmful, but misleading. The MobiLink server
will now report "Listener request completed" instead.
================(Build #2276 - Engineering Case #581829)================
The MobiLink Listener (dblsn)would have failed to query an optimal polling
interval from secondary MobiLink servers, as the primary notifier was not
broadcasting the polling interval to secondary servers. This affected a light
weight poller dblsn, but not application using the light weight poller API
directly. This has now been corrected.
================(Build #2275 - Engineering Case #580191)================
Spacy tokens need to be quoted with double quotes. If the quoted token further
contains spacy sub token then nested double quotes are need, and they need
to be escaped with escape sequence. This was not working correctly when used
in a MobiLink Listener (dblsn) configuration file. For example:
-l "subject=$remote_id;
content=sync cardealer;
action='run dbmlsync.exe -c \"filedsn=c:\my fdsns\CarDealer.dsn\"
-ot dbmlsync.log -k -e sa=on';"
This works correctly on the command line, because the tokenizer of the commandline
processor in the OS supports escaping double quotes using a backslash, but
using the same command in a configuration file would have failed. This problem
has been fixed by improving the common configuration file parsing routine
to support <slash><slash> and <slash><double quote>
as escape sequences for <slash> and <double quote> respectively.
The escape mechanism is effective only inside a quoted token.
================(Build #2274 - Engineering Case #581417)================
Light weight polling against a secondary MobiLink server that is in a MobiLink
server farm, may have failed. This is now fixed.
================(Build #2227 - Engineering Case #570369)================
The listener may not have substituted action variables properly in some cases.
The light weight polling handler would have substituted the variables $ml_user,
$ml_password and $ml_connect with undefined values, as they were thought
to be irrelevant in unauthenticated light weight polling. This has been fixed.
They will be substituted properly into the action string and, if they are
not specified, the values will be empty. Action variables in irrelevant contexts
would have been substituted with undefined values as well. This is too is
fixed, by not not be substituting them at all. For example, using $poll_key
in the action string of a non-light-weight-polling handler will now result
in $poll_key without substitution instead of an undefined result.
================(Build #2218 - Engineering Case #569510)================
HTTP light weight polling may have failed with communication errors. This
has been fixed.
================(Build #2218 - Engineering Case #569509)================
The MobiLink Listener would have gone into an infinite loop light weight
polling continuously, without respecting the polling interval, when communication
errors continue to occur. This has now been corrected.
================(Build #2564 - Engineering Case #657721)================
There was a memory leak in the iAS ODBC driver for Oracle. The memory leak
would have occurred when an application tried to make a connection but the
ODBC driver was not able to obtain a valid database connection. This problem
has now been fixed.
================(Build #2495 - Engineering Case #640205)================
In some cases, the iAS ODBC driver for Oracle could aborted the operation
and given the following Oracle error:
ORA-03145: I/O streaming direction error
This would have occurred when the driver was used to send NULL BLOBs to
a table in an Oracle database and then the rows were fetched back from this
table using the same database connection, and the Oracle database was running
with a multi-byte character set. This has now been fixed.
================(Build #2473 - Engineering Case #632612)================
The iAnywhere ODBC driver for Oracle could have crashed, if an application
made a request to convert an invalid SQL statement (for instance, a SQL statement
containing a '{' that was not followed by 'call') to native SQL by calling
SQLNativeSQLW. This has been fixed.
================(Build #2455 - Engineering Case #632889)================
When using the iAS Oracle ODBC Driver, a call to SQLGetStmtAttr that queried
the SQL_ATTR_CONCURRENCY, SQL_ATTR_CURSOR_TYPE, SQL_ATTR_CURSOR_SENSITIVITY
or SQL_ATTR_QUERY_TIMEOUT attributes could have returned a random value for
the attribute. The driver now throws an "Optional feature not implemented"
error (SQL State HYC00) for the SQL_ATTR_CONCURRENCY, SQL_ATTR_CURSOR_TYPE,
and SQL_ATTR_CURSOR_SENSITIVITY attributes. When the SQL_ATTR_QUERY_TIMEOUT
is queried, a zero is returned, and no error is reported.
================(Build #2451 - Engineering Case #631405)================
If a result set contained a column with ROWID values, the iAnywhere Oracle
driver would have returned invalid OUT parameters from calls to SQLColAttribute
for the SQL_COLUMN_TYPE and SQL_DESC_DISPLAY_SIZE identifiers. As a workaround,
the select statement could use ROWIDTOCHAR(ROWID) instead of ROWID. This
has been fixed so that the calls to SQLColAttribute will now describe the
column in the result set as a SQL_WCHAR of length 18.
================(Build #2436 - Engineering Case #628952)================
The MobiLink server would have shown the following error:
Invalid Date-time segment. Year value out of range
and aborted any synchronization requests, if the consolidated database was
running on an ASE server with a database that was using a multi-byte charset,
and the MobiLink server was running on a Windows system that was using a
non-English Date format. This problem has now been fixed.
================(Build #2436 - Engineering Case #627776)================
On big-endian machines, the 64-bit iAS ODBC driver could have returned random
values when an application was trying to retrieve the following statement
attributes:
SQL_ATTR_METADATA_ID
SQL_ATTR_ROW_NUMBER
SQL_ATTR_ROW_ARRAY_SIZE
SQL_ATTR_PARAMSET_SIZE
SQL_ATTR_MAX_LENGTH
SQL_ATTR_MAX_ROWS
The driver was using SQLUINTEGER for these statement attributes. It has
been corrected to now use SQLULEN.
================(Build #2428 - Engineering Case #626951)================
The iAS Oracle ODBC driver could not detect connection status correctly when
a connection was forcibly disconnected by the server. Due to this problem,
an application, such as the MobiLink server, might not re-establish a new
connection and would have reported the same errors repeatedly. This problem
is fixed now.
================(Build #2278 - Engineering Case #579837)================
The iAnywhere Solutions Oracle ODBC driver could not recognize synonyms of
stored procedures. Thus an application, such as the MobiLink server, that
uses this driver was not able to execute procedure synonyms if the DSN used
by the application was configured with the "Procedure returns results"
check box checked. This problem has now been fixed.
================(Build #2271 - Engineering Case #573625)================
If an application asked for the connection status through the following ODBC
API
SQLGetConnectAttr( hdbc, SQL_ATTR_CONNECTION_DEAD, ... )
after an error occurred, the iAnywhere Solutions ODBC driver for Oracle
could told the application that the connection was still alive, even though
the connection had actually been killed, or had timed out. If this problem
occurred for the MobiLink server main connection, in most cases, the server
would have displayed the following messages:
[10009] MobiLink table 'ml_scripts_modified' is damaged
[-10020] Unable to flush scripts
and refused any synchronization requests. This MobiLink server would then
have needed to be be restarted in order to carry on any synchronization.
This problem is fixed now.
================(Build #2265 - Engineering Case #578401)================
The iAnywhere Solutions ODBC driver for Oracle could have held the socket
descriptor and service handle, even when the database connection had been
disconnected. This could have resulted in the driver running out of service
handles with the following error: "ORA-12519: TNS:no appropriate service
handler found". The OCI function, OCIServerDetach, was missing in the
logoff function. This has now been corrected.
================(Build #2250 - Engineering Case #574354)================
The iAS ODBC driver for Oracle could have crash in a stored procedure call,
if the stored procedure contained char or varchar type INOUT parameters,
and the data length of these parameters was greater than 2000 bytes (1000
bytes for driver versions, 9.0.2 and 10.0.1). This has now been fixed.
================(Build #2203 - Engineering Case #567794)================
If the MobiLink Server was connected to an Oracle consolidated database,
and an event was defined that called a stored procedure within a package,
it was possible for a crash to have occurred in the iAnywhere Oracle ODBC
Driver, which would in turn crash the MobiLink Server. This problem has now
been fixed.
================(Build #2157 - Engineering Case #561820)================
The iAS ODBC driver for Oracle could have leaked memory when fetching binary
data (CLOB, BLOB, NCLOB, LONG VARCHAR, and LONG RAW) from an Oracle database.
This problem would only have occurred when sending the fields as part of
the MobiLink download stream to the remote. This has now been fixed.
================(Build #2139 - Engineering Case #556326)================
Applications running on Unix systems, and using the iAS ODBC driver for Oracle,
could have received an "Out of memory" error when calling SQLTables,
SQLColumns, SQLPrimaryKeys, SQLForeignKeys, SQLProcedureColumns, SQLProcedures,
or SQLStatistics. This problem has now been fixed.
================(Build #2612 - Engineering Case #671397)================
The following Entity Framework datetime functions were not mapped to SQL
Anywhere functions:
AddDays, AddHours, AddMicroseconds, AddMilliseconds, AddMinutes, AddMonths,
AddSeconds, AddYears, DiffHours, DiffMicroseconds, DiffMilliseconds, DiffMinutes,
DiffMonths, DiffSeconds, DiffYears.
For example:
Entities db = new Entities();
var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays(
x.OrderDate, DateTime.Now ) > 100 );
string trace = ( ( ObjectQuery ) query ).ToTraceString();
This problem has been corrected by adding new function handlers for mapping
Entity Framework datetime functions to the SQL Anywhere functions 'DATEADD'
and 'DATEDIFF'.
================(Build #2604 - Engineering Case #669227)================
On systems running Windows Vista or later, when using the Visual Studio Add
Connection wizard the SQL Anywhere .NET provider listed USER DSNs only in
the ODBC Data Sources drop-down list. The SYSTEM DSNs are omitted. This problem
has been corrected. The SetupVSPackage tool must be run to install this fix.
It should be noted that on 64-bit Windows, only the 64-bit SYSTEM DSNs are
listed (after this correction). Any 32-bit SYSTEM DSNs are not displayed.
In Visual Studio 2008's design environment (which is 32-bit on 64-bit platforms),
the Test Connection button will attempt to establish a connection using the
32-bit equivalent of the 64-bit DSN. If the 32-bit DSN does not exist, the
test will fail.
================(Build #2600 - Engineering Case #668141)================
Calling the method SATcpOptionsBuilder.ClientPort could have caused the exception
InvalidCastException to have been thrown.
For example:
SATcpOptionsBuilder options = new SATcpOptionsBuilder( "localonly=yes;port=6873"
);
string cport = options.ClientPort;
This problem has been fixed.
================(Build #2600 - Engineering Case #667672)================
The Entity Framework function 'DiffDays' was not mapped to the SQL Anywhere
function 'Days'.
For example:
Entities db = new Entities();
var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays(
x.OrderDate, DateTime.Now ) > 100 );
string trace = ( ( ObjectQuery ) query ).ToTraceString();
This problem has been fixed.
================(Build #2599 - Engineering Case #667762)================
SetupVSPackage.exe would have failed to add some dlls to the Global Assembly
Cache on 64 bit Windows systems. This problem has been fixed.
Also, a new command line option 'salocation' (or 'saloc') has been added
to SetupVSPackage to allow specifying the SQL Anywhere install location.
If 'saloc' is specified, SetupVSPackage will use it to locate the necessary
dlls. If 'saloc' is not specified, SetupVSPackage will use SQL Anywhere registry
keys to locate the dlls.
================(Build #2597 - Engineering Case #667441)================
Misleading error messages would have been returned to the client when opening
a connection using an invalid DSN. This problem has been fixed.
================(Build #2589 - Engineering Case #667927)================
The SQL Anywhere .NET Provider, running in 64-bit mode, might have inadvertently
attempted to load a 32-bit language resource DLL (e.g., dblgen12.dll) and
failed with an error. This problem has been corrected.
================(Build #2581 - Engineering Case #663470)================
On CE devices, if multiple applications were running simultaneously, the
library dbdata.dll could have been deployed multiple times to the temp directory.
This problem has been fixed.
Additionally, the version number has been added to the native dll name (i.e.
dbdata12.dll). This will allow running multiple versions of the provider
simultaneously on Windows CE.
================(Build #2571 - Engineering Case #661459)================
The .NET provider was incorrectly assuming that a Sybase IQ 12.7 server supported
the NCHAR datatype. This resulted in a failure to establish a connection
to a Sybase IQ 12.7 server. This problem has been fixed.
================(Build #2560 - Engineering Case #657542)================
The results of an Entity DAta Model query could have been non-deterministic.
For example, having a GridView with the properties "AllowPaging"
and "AllowSorting" set to "True", would have returned
a "Result is non-deterministic" warning (SQLCODE 122). This has
been fixed by adding an ORDER BY clause to the generated SQL.
================(Build #2553 - Engineering Case #656481)================
An application using the ADO .Net provider, and calling the method SAConnection(),
could not have successfully connected to an IQ 12.7 server. A run-time error
(iAnywhere.Data.SQLAnywhere.SAException) would have occurred when the provider
tried to parse the server version string. This problem has been resolved.
================(Build #2547 - Engineering Case #654446)================
If there were multiple applications running simultaneously, the ADO.NET provider
could have failed to load dbdata.dll. This has now been fixed.
================(Build #2535 - Engineering Case #651510)================
Execution of the utility SetupVSPackage, would have shown an error: "Object
reference not set to an instance of an object." if machine.config file
did not have the entry <DbProviderFactories>. This problem has been
fixed.
================(Build #2529 - Engineering Case #649763)================
If an application connected with autostop=yes, and subsequently made a CLR
external environment call, then the CLR external environment could have crashed
when the application disconnected. This problem has now been fixed.
================(Build #2515 - Engineering Case #646349)================
The SQL Anywhere BINARY datatype was mapped to SQL Server's BINARY datatype.
This could have resulted in incorrect values when exporting SQL Anywhere
tables to SQL Server, as the SQL Anywhere BINARY datatype is variable length,
and the SQL Server BINARY datatype is fixed length. This has been corrected
by mapping the SQL Anywhere Binary datatype to SQL Server's VARBINARY datatype.
================(Build #2505 - Engineering Case #643822)================
Schema locks were not being released when the execution of ExecuteReader()
encountered an exception. If a BeginTransaction was called, a Rollback or
Commit should be called by the application to release the locks. Now, if
BeginTransaction is not called, the transaction will be automatically rolled
when an exception is encountered.
================(Build #2501 - Engineering Case #643230)================
The datatypes sysname and uniqueidentifierstr were both being mapped to char(0)
in Micrsoft's SQL Server Integration Services. This has been corrected so
that sysname is now mapped to varchar(30), and uniqueidentifierstr is now
mapped to char(36).
================(Build #2501 - Engineering Case #642563)================
When running the install generated by the Deployment wizard, the ADO.NET
provider was not registered correctly. Running the utility setupvspackage.exe
manually after the install finished would have correctly registered the .NET
provider. This has now been fixed.
================(Build #2500 - Engineering Case #642971)================
The utility SetupVSPackage.exe would have thrown the error "Object reference
not set to an instance of an object.", if the .NET Framework 4.0 was
not installed. This problem has been fixed.
================(Build #2493 - Engineering Case #640786)================
Calls to the GetSchema method would have return an error when the restrictions
vector size was less than the total number of restrictions. For example,
if 2 restrictions were specified for a schema rowset that took up to 3 restrictions,
the GetSchema call would have resulted in an error indicating that 3 restrictions
were expected. The error was due to the fact that the array size is 2, not
3. This problem has been fixed.
================(Build #2492 - Engineering Case #640589)================
The utility SetupVSPackage.exe did not modify the file machine.config for
the 64 bit .NET Framework. The machine.config file is now updated for both
the 32 bit and 64 bit Frameworks on 64 bit Windows.
================(Build #2490 - Engineering Case #640239)================
The SetupVSPackage.exe utility did not update SQL Server Integration Services
mapping files and the ProviderDescriptors.xml file for 64 bit DTS on 64 bit
Windows. This problem has been fixed.
================(Build #2482 - Engineering Case #637909)================
Executing a stored procedure and fetching the result set would have thrown
the exception "Index was outside the bounds of the array" if the
stored procedure selects results from a local temporary table with blob columns.
The provider was determining the row buffer length prior to opening the cursor,
this has been corrected so that it is done after the cursor has been opened.
================(Build #2480 - Engineering Case #638231)================
The property SAConnection.State would have indicated that the connection
was still open even after the connection had been dropped. This has now been
corrected.
================(Build #2479 - Engineering Case #637725)================
The Available objects list would have been empty when creating SQL Server
Integration Services data source view. This problem has been fixed.
================(Build #2465 - Engineering Case #634919)================
The utility SetupVSPackage.exe did not modify the Global Assembly Cache (GAC)
or the machine.config file if Visual Studio was not installed. This problem
has been fixed.
================(Build #2463 - Engineering Case #634504)================
SQL Anywhere ODBC data sources were not listed in Visual Studio's Add Connection
dialogbox on 64 bit Windows systems. This has now been fixed.
================(Build #2456 - Engineering Case #637453)================
With the changes for Engineering case 576252, support for SQL Anywhere Explorer
and SQL Anywhere Toolbar was disabled for Visual Studio version 2010. Now,
SQL Anywhere Explorer and SQL Anywhere Toolbar have been disabled for Visual
Studio versions 2005 and 2008 as well.
================(Build #2452 - Engineering Case #632608)================
The performance for fetching BLOB columns was much slower compared with the
managed OLE DB provider. This problem has been corrected.
================(Build #2444 - Engineering Case #631249)================
The result sets returned by calls to SAConnection.GetSchema( "Columns"
) and SAConnection.GetSchema( "DataTypes" ) could have been incorrect.
This has been fixed.
================(Build #2443 - Engineering Case #631026)================
When using the ADO.NET provider to insert long binary, varchar or nvarchar
values with a SQL_BINARY, SQL_VARCHAR or SQL_NVARCHAR parameter type, the
parameter type that is passed to the server will be changed to SQL_LONGBINARY,
SQL_LONGVARCHAR or SQL_LONGNVARCHAR if the length of the value to be inserted
is greater than 32767 bytes.
================(Build #2443 - Engineering Case #630913)================
If some columns had been dropped from a table, SAConnection.GetSchema( "Columns"
) could have returned incorrect ORDINAL_POSITION values for that table. This
has been fixed.
================(Build #2443 - Engineering Case #630911)================
Some result sets returned by by the method SAConnection.GetSchema() were
not sorted. This has been corrected.
================(Build #2443 - Engineering Case #630909)================
Calls to the method SADataAdapter.Update() in batch update mode would have
hung when updating large tables. This has been fixed.
================(Build #2442 - Engineering Case #630542)================
In the SADataReader's schema table, , the SCALE property for Date, DateTime,
DateTimeOffset, SmallDateTime, Time, Timestamp, and Timestamp with time zone
columns, has been changed to 6.
================(Build #2442 - Engineering Case #630540)================
The method SAConnection.ServerVersion() has been changed to return normalized
version strings that match the strings returned by SqlConnection.ServerVersion().
================(Build #2442 - Engineering Case #630408)================
The method SAConnection.GetSchema() would have returned incorrect data. Database
objects owned by system accounts were being included in the result sets.
They are now excluded.
================(Build #2439 - Engineering Case #629758)================
The SAConnection.GetSchema method returned incorrect schema data for the
DataTypes schema set and the DataSourceInformation schema set. This problem
was found using the SQL Server Integration Service's Import and Export Wizard.
This has now been corrected.
================(Build #2438 - Engineering Case #629304)================
The values for DataSourceProductVersion and DataSourceProductVersionNormalized
returned by the SAConnection.GetSchema method didn't match the ADO.NET specification.
The normalized version string should have been like nn.nn.nn.nnnn. For example,
SQL Server 2008 would return "DataSourceProductVersion = 10.00.1600,
DataSourceProductVersionNormalized = 10.00.1600". SQL Anywhere was returning
"DataSourceProductVersion = 12.0.0.1234, DataSourceProductVersionNormalized
= 12.0.0". This has now been corrected.
================(Build #2435 - Engineering Case #628587)================
A multithreaded application could have failed to load the unmanaged dll.
This has now been corrected.
================(Build #2432 - Engineering Case #625219)================
A prepared statement was not being dropped when an exception occurred while
calling the method SACommand.ExecuteReader. This problem has been fixed.
================(Build #2431 - Engineering Case #627780)================
The Start Server in Background utility (dbspawn) would have failed to start
a database server if the full path to the server executable was given and
that path contained a space. This has now been fixed.
================(Build #2411 - Engineering Case #622789)================
Applications running on on Windows 7 64 bit systems could have crashed when
canceling the methods EndExecuteReader or EndExecuteNonQuery. This problem
has been fixed.
================(Build #2397 - Engineering Case #619719)================
ADO.Net client applications could have hung in very rare circumstances when
fetching data readers. This problem has been fixed.
================(Build #2388 - Engineering Case #617699)================
The message "Statement interrupted by user" was not being returned
after a user canceled a command. This problem has been fixed.
================(Build #2388 - Engineering Case #617178)================
The asynchronous command execution ( BeginExecuteReader and BeginExecuteNonQuery
) could have been blocked by exclusive table locks. This problem has been
fixed.
================(Build #2352 - Engineering Case #606683)================
The build number on policy.11.0.iAnywhere.Data.SQLAnywhere.dll is incorrect.
This has been corrected.
================(Build #2344 - Engineering Case #605792)================
If an internal connection was the cause of a diagnostic message, it might
have been identified with the phrase 'another user'. A more descriptive
string identifying the connection will now be used. For example, one might
now get a diagnostic message such as: User 'Cleaner' has the row in 'x' locked
(SQLCODE: -210; SQLSTATE: 42W18)
================(Build #2334 - Engineering Case #595100)================
The Connect to Database dialog had strings overlapping text boxes. The "Connection
String:" string and the "Specify Custom User" string overlapped
their text boxes. This has been corrected.
================(Build #2325 - Engineering Case #591833)================
The ADO.NET provider could have failed to unpack and load dbdata.dll. A race
condition has been fixed.
================(Build #2302 - Engineering Case #586217)================
Methods in the SADataReader clase could have returned an incorrect fraction
for datetime and time columns. This has now been corrected.
================(Build #2272 - Engineering Case #580607)================
User Impersonation on IIS caused Win32Exception "Access is denied".
This has been fixed.
================(Build #2266 - Engineering Case #577974)================
Using an ADO.NET Entity Data Model object with an ASP.NET Web Site project
did not work correctly. This has been corrected.
================(Build #2265 - Engineering Case #578172)================
Calls to the methods SADataReader and SADataAdapter would not have returned
any data for temporary tables. An AutoCommit when opening a data reader would
have dropped temporary tables. This has now been fixed.
================(Build #2257 - Engineering Case #576252)================
Support for SQL Anywhere Explorer and SQL Anywhere Toolbar has been disabled
for Visual Studio 2010. They still support Visual Studio versions 2005 and
2008.
================(Build #2182 - Engineering Case #565104)================
The php process may have crashed after completing a php external environment
call. This has been fixed.
================(Build #2602 - Engineering Case #668603)================
In rare cases, an application could have failed to connect because of a TCP/IP
communication link failure. No specific reason for the failure would have
been logged to the file specified by the LOGFILE connection parameter. This
has been fixed.
Note, this problem affected the .Net provider, the ODBC, JDBC and OLEDB
drivers as well.
================(Build #2567 - Engineering Case #660204)================
Specifying a TCP timeout value of more than 2147 seconds could have caused
connection failures. This has been fixed.
================(Build #2566 - Engineering Case #659643)================
An application could have crashed if it was attempting an Integrated Login
or Kerberos connection and the connection to the server was lost. This could
have occurred if the server was stopped or terminated during the connection.
This has been fixed.
================(Build #2509 - Engineering Case #643421)================
If an application was attempting to connect to a server and the server shut
down between the time the protocol connection was made and the time the database
connection was attempted, the application could have crashed. This has been
fixed.
================(Build #2495 - Engineering Case #641485)================
Attempting to make a connection with invalid TCPIP protocol options could
have caused a crash in the client library. This has been fixed.
================(Build #2478 - Engineering Case #635466)================
When making a TCP connection to a remote machine that was unavailable (i.e.
powered off, network cable unplugged, etc.), the time taken to time out could
have been far longer than the value of the TIMEOUT parameter. This has been
fixed.
================(Build #2443 - Engineering Case #631023)================
SA Clients on Mac OS X systems would have received the error "TLS handshake
failure" (SQLCODE -829) when attempting to connect using TLS/RSA to
a server running on a different operating system. This has been fixed.
Note: Engineering case 626480 included new versions of the Certicom and
OpenSSL libraries. This problem only affects Mac OS X clients with these
new libraries connecting to servers on a different operating system also
with these new libraries.
================(Build #2400 - Engineering Case #619937)================
An embedded SQL application that attempted to fetch into a sqlvar of type
DT_VARCHAR, DT_NVARCHAR or DT_BINARY, with a negative sqllen, could have
crashed due to a memory overrun. A negative sqllen with these types is invalid
and should never be passed to DBLib. DBLib has now been fixed to make the
memory overrun less likely.
================(Build #2377 - Engineering Case #615254)================
If a percent character "%" was used in a RAISERROR statement, then
retrieving the error using sqlany_error() would have returned garbage characters
for the percent character. This has been fixed.
================(Build #2360 - Engineering Case #609708)================
When using the SQL Anywhere C API and binding parameters for prepared statements
and calling sqlany_execute() multiple times, the second and subsequent calls
to sqlany_execute() would have failed with the error "Cursor already
open". The problem was introduced as part of the changes for Engineering
case 560351. This has now been fixed.
================(Build #2360 - Engineering Case #609704)================
When calling the SQL Anywhere C API function sqlany_clear_error() the resulting
SQLSTATE value would have been set to the empty string instead of "00000".
This has been fixed.
================(Build #2353 - Engineering Case #607330)================
The SQL Anywhere C API was fetching the TINYINT data type as a signed value.
This has been fixed.
================(Build #2316 - Engineering Case #590383)================
On UNIX systems, there were directories left in the temporary directory,
with names of the form __SQLAnyCli__X_Y, where X is a process number and
Y is an alphanumeric number. This usually happened when a SQL Anywhere client
application was terminated abnormally. An example of this was the PHP driver
running within the Apache web server. This has been fixed.
================(Build #2291 - Engineering Case #584721)================
When using the SQL Anywhere C API, no error information was returned when
a connection attempt failed. This problem was introduced as part of a previous
fix to dbcapi, and has now been corrected.
================(Build #2247 - Engineering Case #573228)================
When concurrent connection requests were made to servers running on multi
core or multi processor Unix systems, connections could, in rare cases, have
hung, received communication errors, or otherwise failed. This has been fixed.
================(Build #2203 - Engineering Case #567417)================
The DBLib client library could have crashed if there was a language resource
problem, such as a missing language dll or .res file. In order for this crash
to have occurred, db_init must have been called at least twice, and then
another dblib call must have been made (such as db_string_connect or EXEC
SQL CONNECT). This has been fixed, and db_init will now return 0 on language
resource problems.
================(Build #2183 - Engineering Case #565255)================
A multi-threaded embedded SQL application could have crashed if db_fini was
called with the last active SQLCA at the same time as db_init was called
with another SQLCA. The crash was very timing dependent. A race condition
has been corrected.
================(Build #2150 - Engineering Case #559632)================
An embedded SQL PREPARE or OPEN request could have caused the application
to crash in rare cases, if the connection was dropped before, or during,
the request. This has been fixed.
================(Build #2149 - Engineering Case #559600)================
Executing a "MESSAGE .. TO CLIENT FOR CONNECTION conn-id IMMEDIATE"
statement shortly before the target connection abnormally disconnected could
have resulted in the message callback being called after an API request returned
an error. The abnormal disconnect could have been caused by a liveness timeout,
idle timeout, DROP CONNECTION, server shut down, or other conditions. Depending
on the application's message callback routine, this could have resulted in
a crash or other incorrect behaviour. This has been fixed so that the message
callback will not be called after an API request has returned an error due
to an abnormal disconnect.
================(Build #2136 - Engineering Case #555450)================
Column names that are greater than 29 bytes in length were being truncated.
This has been fixed.
================(Build #2540 - Engineering Case #652739)================
If an application prepared a batch insert using the SQL Anywhere JDBC driver,
and the last row in the batch involved a call to setNull() and the datatype
passed to setNull() was different than the previous set of setX calls for
that column, then there was a chance the JDBC driver would have inserted
incorrect data. This problem has now been fixed.
For example, the following set of calls would have inserted incorrect data
into the table test:
PreparedStatement pstmt = con.prepareStatement( "insert into test values(?,?)"
);
pstmt.setInt(1, 1001);
pstmt.setString(2, "this is row #1" );
pstmt.addBatch();
pstmt.setInt(1, 2001);
pstmt.setString(2, "this is row #2" );
pstmt.addBatch();
pstmt.setInt(1, 3001);
pstmt.setString(2, "this is row #3" );
pstmt.addBatch();
// note the fact that we are switching datatypes below
pstmt.setNull(1, java.sql.Types.SMALLINT);
pstmt.setString(2, "this is row #4" );
pstmt.addBatch();
pstmt.executeBatch();
Again, note that this problem would not have occurred if instead of using
java.sql.Types.SMALLINT, the application instead used java.sql.Types.INTEGER.
In addition, if the call to setNull() was not in the last row of the batch,
then again this problem would not have occurred, even if the application
switched datatypes for the setNull() call.
================(Build #2497 - Engineering Case #642015)================
Due to an uninitialized variable in the iAnywhere JDBC driver, applications
using the driver (such as the MobiLink server) could have crashed when trying
to access a result set. This problem has now been fixed.
================(Build #2483 - Engineering Case #638600)================
When connected using the SQL Anywhere JDBC 4.0 driver, calling DatabaseMetaData.getProcedureColumns()
would have returned a result set with the DATA_TYPE column in the metadata
result set containing an incorrect JDBC data type for nchar, nvarchar and
longnvarchar columns. This problem has now been fixed.
================(Build #2483 - Engineering Case #638273)================
While connected using the SQL Anywhere or iAnywhere JDBC drivers, attempting
to use setNull() in a batch update may have caused the JDBC driver to throw
a datatype mismatch SQLException if the datatype specified within the setNull()
call differed from other non-null set calls to the same column within the
batch update. This problem has now been fixed and the datatype mismatch will
now only be thrown if a non-null set call of a different type is made on
the same column within a batch update.
================(Build #2444 - Engineering Case #631045)================
If an application attempted to establish a connection using the ASADataSource
class available with the SQL Anywhere JDBC driver, then the application would
have received a ClassCastException. This problem has now been fixed.
Note that in addition to supporting the ASADataSource class, the SQL Anywhere
and iAnywhere JDBC drivers now offer an SADataSource class as well.
================(Build #2444 - Engineering Case #630475)================
If an application used the SQL Anywhere JDBC driver to obtain the ResultSet
from a call to DatabaseMetaData.getPrimaryKeys(), then the driver would incorrectly
return a ResultSet that was sorted by catalog, schema, table name and key
sequence. This has now been fixed and the ResultSet is now sorted by column
name instead.
Note that this fix is only for the SQL Anywhere JDBC driver. The iAnywhere
JDBC driver will continue to return a ResultSet based on ODBC sorting standards.
================(Build #2394 - Engineering Case #619037)================
If an application opened multiple database metadata result sets, and the
application closed the metadata result sets appropriately, there was still
a chance that the iAnywhere JDBC driver would have closed one of the open
metadata result sets, even though the application had not reached the limit
of 3 metadata result sets open at any given time. This problem has now been
fixed.
================(Build #2389 - Engineering Case #618212)================
If an application connected using the iAnywhere JDBC driver, and then subsequently
called one of the read() overloads of ResultSet.getBlob().getBinaryStream(),
if the blob value was a non-NULL zero length long binary value, then the
read() method would have incorrectly returned 0, instead of -1 to signal
the end of the input stream. This problem has now been fixed.
Note, this problem was introduced by the changes for Engineering case 609739.
================(Build #2365 - Engineering Case #609739)================
When an application retrieved a Blob object by calling ResultSet.getBlob(),
and the application subsequently retrieved the Blob's InputStream by calling
Blob.getBinaryStream(), the applications performance would have been severely
impacted if the application called InputStream.read( byte[] ) or InputStream.read(
byte[], int, int ) on the Blob InputStream. This problem has now been fixed.
Note that a workaround is to use Blob.getBytes() directly, instead of using
the Blob InputStream.
================(Build #2362 - Engineering Case #610533)================
If an application retrieved a ResultSet via a DatabaseMetaData call, and
the application subsequently retrieved the underlying Statement object of
that ResultSet by calling ResultSet.getStatement(), then attempting to close
that DatabaseMetaData Statement object could have crashed the application.
The problem with closing DatabaseMetaData Statement objects has now been
fixed.
Note that in general, applications do not explicitly need to close DatabaseMetaData
Statement objects; hence the chances of an application crashing due to this
problem are rare. Closing the ResultSet of a DatabaseMetaData call is not
uncommon and not affected by this.
================(Build #2360 - Engineering Case #609736)================
If an application had a connection that was holding on to table locks, and
the same application had other connections that were blocked in the server
waiting for the table locks to be released, then there was a chance the application
would have hung if the connection holding on to the table locks subsequently
called Connection.createStatement(). This problem has now been fixed.
================(Build #2357 - Engineering Case #608751)================
If an application called IBlob.getBytes() with a position value <= 0,
or a length value < 0, then the getBytes() method would have incorrectly
returned NULL. The JDBC driver now correctly throws a SQLException for these
cases.
================(Build #2357 - Engineering Case #608750)================
If an application called ResultSet.getObject() on an unsigned smallint, int
or bigint column, then the JDBC driver may have given a conversion error.
This problem has now been fixed such that calling ResultSet.getObject() on
an unsigned column will now promote the datatype. Hence, calling ResultSet.getObject()
on an unsigned smallint column will now return an int; similarly, an unsigned
int column will now return a long, and an unsigned bigint column will now
return a BigDecimal. It should be noted that most applications prefer to
have full control on the column object so it is always better to use one
of the getShort(), getInt(), getLong() and getBigDecimal() methods explicitly
rather than using an implicit method like getObject().
================(Build #2355 - Engineering Case #608106)================
If an application called ResultSet.getObject() on a tinyint column, and the
column value ranged from 128 to 255, then the JDBC driver would have incorrectly
thrown a SQLException with a conversion error. This problem has now been
fixed.
================(Build #2332 - Engineering Case #594666)================
If an application called the ODBC function ResultSet.getCursorName(), then
the iAnywhere JDBC Driver would have returned a truncated cursor name. The
JDBC driver was incorrectly assuming that the returned length from SQLGetCursorNameW
was in bytes, when in fact the value returned is in characters. This problem
has been fixed, and the full cursor name is now properly returned.
================(Build #2331 - Engineering Case #594327)================
If an application called the method DatabaseMetaData.getDatabaseProductVersion()
on a closed Connection object, then the iAnywhere JDBC Driver would have
thrown a NullPointerException, instead of returning the appropriate SQLException.
This problem has now been fixed.
================(Build #2331 - Engineering Case #593347)================
An application connected using the iAnywhere JDBC Driver, and calling the
method PreparedStatement.setBlob() to insert a blob of length between 64M
and 256M, would have seen the insert take much longer than if the application
used the method PreparedStatement.setBinaryStream() instead. This problem
has now been fixed, and in addition, also improves the performance of using
PreparedStatement.setBinaryStream().
Note that using setBlob() requires significantly less memory than using
setBinaryStream(), and also, for blob values greater than 256M in size, setBlob()
may actually be the only option.
================(Build #2296 - Engineering Case #585013)================
If an application executed Connection.prepareStatement(), or Connection.prepareCall(),
on one connection, and the prepare request took a long time, then attempting
to execute Connection.createStatement(), Connection.prepareStatement(), or
Connection.prepareCall() on a different connection would have ended up blocking
until the original prepare returned. This problem has now been fixed.
================(Build #2273 - Engineering Case #581029)================
The fix for Engineering case 571029 would have caused the Interactive SQL
utility to give an "optional feature not implemented" error when
exporting data to Excel. This problem has now been fixed.
================(Build #2273 - Engineering Case #580599)================
The SQL Anywhere JDBC driver getTimeDateFunctions() call did not return the
correct names for the CURRENT_DATE, CURRENT_TIME, and CURRENT_TIMESTAMP functions.
It returned "current date,current time,current timestamp" instead
of "current_date,current_time,current_timestamp". The same problem
also existed in the iAnywhere JDBC driver. These problems have now been fixed.
================(Build #2271 - Engineering Case #580174)================
If an application using the iAnywhere JDBC driver, created a scrollable,
updateable Statement or PreparedStatement, created a ResultSet object off
of the Statement or PreparedStatement object, called ResultSet.updateRow()
to perform a positioned update of a row in the ResultSet, and then positioned
the ResultSet to a row before the updated row, attempting to call next()
to go beyond the updated row would have failed. A similar problem exists
if the application positions the ResultSet beyond the updated row and then
tries to call previous(). Both problems have now been fixed.
================(Build #2270 - Engineering Case #580012)================
The changes for Engineering case 576257 resulted in a substantial performance
improvement within the iAnywhere JDBC driver when fetching a large number
of Date, Time or Timestamp values. New changes, which build on these earlier
changes, make fetching Date, Time and Timestamp values even faster, when
using the iAnywhere JDBC driver.
================(Build #2267 - Engineering Case #578990)================
If an application called DatabaseMetaData.getSystemFunctions(), the string
returned would have contained the functions named dbname and username. The
correct function names are database and user. This problem has now been fixed.
================(Build #2261 - Engineering Case #577532)================
An application running under a Java VM in server mode, and fetching a large
result set, will now retrieve the result set much faster.
================(Build #2257 - Engineering Case #576257)================
Changes have been made to the iAnywhere JDBC driver in order to improve fetch
times for Date, Time and Timestamp values. Applications that are fetching
a large number of Date, Time and/or timestamp values from the same ResultSet
object, will now see a large improvement.
================(Build #2237 - Engineering Case #571625)================
If an application called DatabaseMetaData.getCatalogs(), DatabaseMetaData.getSchemas()
or DatabaseMetaData.getTableTypes(), then the JDBC driver would have leaked
a very small amount of memory. This problem has now been fixed.
================(Build #2237 - Engineering Case #571624)================
If an application executed a query that generated a warning, and that warning
was attached to a Statement, PreparedStatement, CallableStatement or ResultSet
object, and the object was subsequently closed without calling clearWarnings()
first, then the JDBC driver would have leaked memory. This problem has now
been fixed.
================(Build #2234 - Engineering Case #571029)================
If an application attempted to execute a batch with a long binary or long
varchar column, and the values within the long columns were large, and the
batch size was also reasonably large, then the iAnywhere JDBC driver may
have given an 'out of memory' dialog, even though the Java VM still had lots
of memory available. This problem has now been fixed.
================(Build #2233 - Engineering Case #570903)================
In very rare circumstances it was possible for the SQL Anywhere JDBC driver
to have caused a crash in the Java VM. The Hotspot log generated for the
crash would most likely have indicated that the crash occurred while attempting
to construct a class cast exception. This has been fixed.
================(Build #2218 - Engineering Case #569316)================
If an application connected using the iAnywhere JDBC driver and created a
very large batch, containing either long binary or long varchar parameters,
then executing the batch may have given a strange out of memory error dialog
after which the application would have crashed. The driver has now been modified
to allow such large batches to be executed; however, any such batches that
require a very large amount of contiguous memory to be allocated will be
executed one row at a time, instead of being batched. In addition, whenever
the driver decides to execute a batch one row at a time, a SQLWarning will
be returned on the executeBatch() call indicating that the "batch was
executed in single row mode due to memory limitations".
================(Build #2173 - Engineering Case #563736)================
If an ODBC DSN explicitly specified an isolation level, and that DSN was
then used within the Interactive SQL utility (dbisql), then the isolation
level specification would have been ignored. This problem has been fixed.
================(Build #2149 - Engineering Case #556757)================
If a JDBC application called ResultSetMetaData.getColumnTypeName() with an
invalid column index, then the application may have crashed. This problem
has been fixed.
================(Build #2134 - Engineering Case #554880)================
If the Server Monitor was used to monitor several servers, and one or more
of those servers were down, then it was likely that the server monitor requests
would have started to time out, and cause communication errors within the
browser. This problem has now been fixed.
================(Build #2133 - Engineering Case #554764)================
When running on heavily loaded Unix systems, applications using a large number
of connections may have crashed. This has been fixed.
================(Build #2130 - Engineering Case #554067)================
A Windows application using the iAnywhere JDBC driver, could have hung if
all of the following conditions were true:
1) the application installed a message handler connections
2) the application shared a connection amongst multiple threads
3) one of the threads executed a statement that returned an asynchronous
message
4) at the same time another thread used the same connection and called
createStatement(), prepareStatement() or prepareCall(), before the asynchronous
message was returned from the server
This problem has now been fixed.
================(Build #2127 - Engineering Case #552888)================
If an application called PreparedStatement.setBlob(), and if the underlying
java.sql.Blob implementation misbehaved, then there was a chance that the
iAnywhere JDBC driver would have failed when the PreparedStatement was executed.
Workarounds have now been implemented in the iAnywhere JDBC driver to attempt
to handle the Blob implementation misbehaviour.
================(Build #2124 - Engineering Case #552314)================
If an application called the ResultSet.getBlob() method, and if fetching
the blob should have thrown a valid SQLException, then quite often the exception
would not have been thrown and an empty blob would have instead been returned
to the client. This problem has now been fixed.
================(Build #2122 - Engineering Case #551978)================
If an application called ResultSet.getString() on a uniqueidentifier column,
the iAnywhere JDBC driver would have incorrectly returned a string of binary
bytes. This problem has now been fixed and the iAnywhere JDBC driver now
returns a properly formatted GUID string.
================(Build #2619 - Engineering Case #669581)================
If an application attempted to perform a wide or batched insert, and the
application did not bind or set enough parameters to match the number of
parameters within the prepared INSERT statement, and the wide insert or batch
insert size was greater than 1, then the application would have crashed.
This problem has now been fixed.
================(Build #2615 - Engineering Case #672184)================
If an application attempted to perform a wide insert using the SQL Anywhere
ODBC driver, or a batched insert using the SQL Anywhere JDBC driver, then
there was a very small chance the application would crash if the system was
low on memory or under stress. This problem has now been fixed.
================(Build #2560 - Engineering Case #657826)================
When using the Microsoft ODBC Data Source Administrator, a crash may have
resulted if an encrypted password had been specified and the "Test Connection"
button was used. This has been fixed.
================(Build #2528 - Engineering Case #649644)================
The ODBC driver could not properly handle the following SQL statement because
it thought it was improperly formed:
create table [ab'cd] (i int )
This has now been fixed so that the driver now supports table names with
embedded quotes enclosed in brackets.
================(Build #2514 - Engineering Case #645952)================
The ODBC functions SQLColumns and SQLProcedureColumns incorrectly returned
a NULL value for the CHAR_OCTET_LENGTH column for XML and ST_GEOMETRY data
types. ST_GEOMETRY is a new data type supported by SQL Anywhere in version
12. This has been fixed and the correct value of 2147483647 is now returned.
================(Build #2514 - Engineering Case #645948)================
The LITERAL_PREFIX and LITERAL_SUFFIX characters returned by SQLGetTypeInfo
for binary data types were apostrophes. If these characters were used in
an INSERT statement, the value stored was incorrect.
For example: Store binary 0x1234 into column.
INSERT INTO test (binary_col) VALUES ('1234');
The result is 0x31323334.
If the LITERAL_PREFIX was 0x and the LITERAL_SUFFIX was NULL, then the value
stored was correct.
INSERT INTO test (binary_col) VALUES (0x1234);
This problem has been corrected. The following types will now return 0x
in the LITERAL_PREFIX column and NULL in the LITERAL_SUFFIX column:
long binary
varbinary
binary
================(Build #2485 - Engineering Case #638900)================
If a certain statement was prepared and described that returned no result
set, and then a DDL statement caused the same statement to return a result
set, client statement caching could have caused the statement to be redescribed
incorrectly. This was a client statement caching peformance optimization,
and before this change, there was no way to disable this incorrect behavior.
For example, the following statements executed in dbisql would have returned
an error on the second call foo() statement:
create or replace function foo() returns int begin return 1; end;
call foo();
create or replace procedure foo() begin select 2; end;
call foo();
This has been fixed so that if client statement caching is disabled by setting
the max_client_statement_cached option to 0 for the connection, such a statement
is now described correctly.
================(Build #2479 - Engineering Case #637743)================
Calls to SQLGetTypeInfo() would have returned the wrong UNSIGNED_ATTRIBUTE
column value for TINYINT. The TINYINT datatype is an unsigned type so the
column should have contained a 1 rather than a 0. This problem has been fixed
so that the UNSIGNED_ATTRIBUTE column result now agrees with the result returned
by SQLColAttribute(SQL_DESC_UNSIGNED) for a TINYINT column.
================(Build #2460 - Engineering Case #634189)================
If a connection string was made up of parameters coming from the connection
string and from the data source, and the UID and PWD/ENP parameters were
not all in the connection string or all in the data source, the PWD/ENP parameters
would have been ignored. For example, if DSN "foo" contained a
UID but no PWD, then the connection string "DSN=foo;PWD=secret"
would ignore the PWD field. This has been fixed.
================(Build #2436 - Engineering Case #628843)================
If an application connected to a 64-bit Linux server subsequently used the
ASE ODBC driver to query proxy tables mapped to an ASE server, and the proxy
tables contained long varchar or long binary data, then the long data might
have been returned with extra characters or bytes. This problem has now been
fixed.
================(Build #2430 - Engineering Case #627634)================
The ODBC driver did not support setting of the SQL_ATTR_METADATA_ID attribute
for connections using SQLSetConnectAttr(). This setting governs how the string
arguments of catalog functions are treated. However, the driver does support
this attribute at the statement level using SQLSetStmtAttr(). For SQLSetConnectAttr(),
the ODBC driver returned a "driver not capable" error. This problem
has been corrected.
If the setting for SQL_ATTR_METADATA_ID is SQL_TRUE, the string argument
of catalog functions are treated as identifiers. The case is not significant.
For nondelimited strings, the driver removes any trailing spaces and the
string is folded to uppercase. For delimited strings, the driver removes
any leading or trailing spaces and takes literally whatever is between the
delimiters.
If the setting is SQL_FALSE, the string arguments of catalog functions are
not treated as identifiers. The case is significant. They can either contain
a string search pattern or not, depending on the argument. The default value
is SQL_FALSE.
The following example changes the default setting for the entire connection.
rc = SQLSetConnectAttr( hdbc, SQL_ATTR_METADATA_ID, (SQLPOINTER)SQL_TRUE,
SQL_IS_UINTEGER );
This setting is important for case-sensitive databases. For example, the
table name "customers" does not match the table name "Customers"
in a function such as SQLPrimaryKeys() unless the SQL_ATTR_METADATA_ID attribute
has been set to SQL_TRUE.
================(Build #2424 - Engineering Case #625933)================
If an application that was connected to a server running on a big endian
machine attempted to query data via the Remote Data Access feature with the
64-bit ASE ODBC driver, then there is a chance the server would have incorrectly
reported a truncation error. This problem has now been fixed.
================(Build #2403 - Engineering Case #619613)================
The ODBC functions SQLPrimaryKeys() and SQLForeignKeys() would have returned
an incorrect name for the primary key identifier (PK_NAME). It should return
the PRIMARY KEY constraint name, but was returning the table name (the "default"
primary key name). This problem has been fixed.
================(Build #2388 - Engineering Case #616385)================
When making continuous ODBC connections and disconnections, using the ANSI
entry points to SQLConnect() and SQLDisconnect(), a memory leak would have
occurred in the application. The UNICODE versions of SQLConnect() and SQLDisconnect()
(i.e., SQLConnectW() ) were not affected by this problem. The process heap
will continue to grow as the application loops. This problem has been fixed.
See also Engineering case 608095.
================(Build #2366 - Engineering Case #611168)================
ODBC drivers support standard escape sequences in bound data as a driver-independent
way to specify date and time literals, outer joins and procedure calls.
The SQL Anywhere driver was failing to recognize these escape sequences when
embedded in a bound parameter that contained a Unicode string. This has
been fixed.
================(Build #2360 - Engineering Case #608728)================
If a connection string was made up of parameters coming from different sources
(i.e. the connection string itself, DSNs or file DSNs, SQLCONNECT environment
variable), and the UID and PWD/ENP parameters were not specified in the same
source, the PWD/ENP would have been ignored. For example, if DSN "foo"
contained a UID but no PWD, then the connection string "DSN=foo;PWD=secret"
would ignore the PWD field. This has been fixed.
================(Build #2356 - Engineering Case #608095)================
When continually making ODBC connections/disconnections, using SQLConnect()/SQLDisconnect(),
a memory leak would have occurred in the application. The process heap would
continue to grow as the application looped. This has been fixed.
================(Build #2329 - Engineering Case #593676)================
When using the SQL Anywhere ODBC driver, the transaction isolation level
can be set with a call to the ODBC function SQLSetConnectAttr(). The following
is an example for setting the transaction isolation level to "readonly-statement-snapshot":
SQLSetConnectAttr( dbc,
SA_SQL_ATTR_TXN_ISOLATION,
(SQLPOINTER)SA_SQL_TXN_READONLY_STATEMENT_SNAPSHOT,
SQL_IS_INTEGER );
The following isolation level options are available.
SQL_TXN_READ_UNCOMMITTED
SQL_TXN_READ_COMMITTED
SQL_TXN_REPEATABLE_READ
SQL_TXN_SERIALIZABLE
SA_SQL_TXN_SNAPSHOT
SA_SQL_TXN_STATEMENT_SNAPSHOT
SA_SQL_TXN_READONLY_STATEMENT_SNAPSHOT
When any of the "snapshot" isolation levels were selected, the
ODBC driver would have set the transaction isolation level incorrectly upon
connecting to the server. The following is an example of a SET statement
that was executed:
SET TEMPORARY OPTION isolation_level = readonly-statement-snapshot;
This would have resulted in a syntax error and the server options would
not have been changed. This problem has been fixed. The ODBC driver will
now generate the following correct syntax with quotes around the isolation
level value.
SET TEMPORARY OPTION isolation_level = 'readonly-statement-snapshot';
================(Build #2325 - Engineering Case #592784)================
Calls to the ODBC function SQLGetTypeInfo() always returned 0 in the CASE_SENSITIVE
metadata column for the XML data type. For case-sensitive databases, string
comparisions of columns and variables of type XML is case sensitive. Therefore,
SQLGetTypeInfo() has been fixed to returned 1 in this case.
================(Build #2308 - Engineering Case #587036)================
If a LONG VARCHAR column containing multi-byte data was fetched by the OLE
DB provider, the resulting string may have contained appended null characters.
As a result, the Length attribute of the string (e.g., strTxt.Length) may
have been larger than expected. This problem has been fixed.
================(Build #2275 - Engineering Case #581793)================
If a SQL_NUMERIC or SQL_DECIMAL value had a precision sufficiently greater
than the bound precision, then an internal buffer would have been overrun.
For example, if a bound column was defined as DECIMAL(10,2), and the precision
described by the input SQL_NUMERIC_STRUCT parameter value was 40, then an
internal buffer would have been overrun. This problem has been fixed.
================(Build #2271 - Engineering Case #579219)================
Calling the function SQLGetInfo() function with the SQL_SQL92_STRING_FUNCTIONS
information type returns a bitmask indicating which SQL 92 functions are
supported by the database server.
The following bits should not be returned:
SQL_SSF_CONVERT
SQL_SSF_SUBSTRING
SQL_SSF_TRIM_BOTH
SQL_SSF_TRIM_LEADING
SQL_SSF_TRIM_TRAILING
as SQL Anywhere does not support the above SQL 92 functions (e.g., SELECT
TRIM(BOTH ' ' FROM ' abc ').
Only the following following bits should be returned.
SQL_SSF_LOWER
SQL_SSF_UPPER
This problem has been fixed.
================(Build #2266 - Engineering Case #579816)================
A new connection parameter has been added to the ODBC driver. This parameter
(ESCAPE) allows you to specify the escape character used in the LIKE clause
of SQL statements generated by the ODBC driver when returning a list of tables
or columns.
By default the ODBC driver uses the tilde character (~), but some applications
do not properly query the ODBC driver to see what escape character is used,
and assume that it is the backslash character (\). With this new connection
parameter, users can specify the escape character in the connection string
to make these applications work properly.
"DSN=My Datasource;UID=xxx;PWD=xxx;ESCAPE=\;ENG=myserver"
================(Build #2253 - Engineering Case #574746)================
If an unknown connection parameter was provided to the ODBC driver, the driver
would have given the error: "Parse Error: Invalid or missing keyword
near '<unknown parameter>'". Some applications (for example,
Crystal Reports in some cases) generate connection parameters which are unknown
to SQL Anywhere, which resulted in connection failures. This has been fixed
so that unknown connection parameters are now ignored. This returns the ODBC
driver to the Adaptive Server Anywhere 9.x and earlier behavior.
================(Build #2253 - Engineering Case #574710)================
When the SQL Anywhere Monitor was run on Linux systems, and used to monitor
a large number of resources, there is a very good possibility that the Monitor
would have performed poorly. This problem only existed after applying the
11.0.1 build 2222 EBF. This problem has now been fixed.
================(Build #2252 - Engineering Case #573990)================
When calling the SADataReader.GetBytes method into a binary or varbinary
column with a null buffer, it would have thrown the exception "no current
row of cursor". This problem has been fixed.
================(Build #2250 - Engineering Case #573824)================
The 32-bit Unix versions of the SQL Anywhere ODBC Driver Manager (libdbodm)
would have leaked a very small amount of memory for every statement handle
that was allocated and subsequently freed. The memory leak problem has now
been fixed.
Note that the memory leak does not exist with the 64-bit Unix versions of
the SQL Anywhere ODBC Driver Manager, and that the SQL Anywhere ODBC Driver
Manager does not exist on Windows platforms. It should also be noted that
several SQL Anywhere components on Unix platforms use the SQL Anywhere ODBC
Driver Manager implicitly, and are therefore impacted by this problem. In
particular, the server will use the SQL Anywhere ODBC Driver Manager for
performing Remote Data Access operations; as well, the Mobilink Server uses
the SQL Anywhere ODBC Driver Manager to talk to the consolidated database.
Also, the iAnywhere JDBC driver uses the SQL Anywhere ODBC Driver Manager
to make connections.
================(Build #2183 - Engineering Case #565110)================
When binding a column in ODBC, the column type, a buffer and a length are
specified. For static types (int, long, double, time, etc) the ODBC driver
ignores the length specified because the length is constant. The ODBC driver
should have been treating SQL_GUID columns as static as well, but was incorrectly
respecting the length specified, which sometimes resulted in truncated values.
This has been fixed.
================(Build #2182 - Engineering Case #565054)================
Calling the ODBC functiom SQLColAttribute( ..., SQL_DESC_BASE_COLUMN_NAME,
... ) could have incorrectly returned the correlation name, instead of the
base column name. This has been fixed so that the base column name is returned.
If there is no base column, the column alias is returned.
Note, this fix requires both an updated ODBC driver and server.
================(Build #2173 - Engineering Case #563848)================
If an ODBC application called SQLColAttribute() on a long varchar, long nvarchar
or long binary column, with an attribute value of SQL_DESC_DISPLAY_SIZE,
then the ODBC driver would have incorrectly returned the value 65535. This
problem has been fixed and the driver now returns the value 2147483647.
================(Build #2152 - Engineering Case #549800)================
The SQL Anywhere ODBC driver incorrectly described a column of type NCHAR
as SQL_WVARCHAR (-9), instead of SQL_WCHAR (-8), when the odbc_distinguish_char_and_varchar
database option was set 'off'. In the following SQL statement, the two columns
should be described as SQL_WCHAR and SQL_WVARCHAR respectively.
select cast('abc' as nchar),cast('abc' as nvarchar)
This problem did not affect calls to SQLColumns(), but it did affect calls
to SQLDescribeCol(). This problem has been fixed.
The odbc_distinguish_char_and_varchar option is intended for CHAR columns
only. It is provided for backwards compatibility with older versions of the
SQL Anywhere ODBC driver. For backwards compatibility, the odbc_distinguish_char_and_varchar
option is set 'off' by default. When odbc_distinguish_char_and_varchar option
is set 'on', the ODBC driver will describe CHAR columns as SQL_CHAR, rather
than SQL_VARCHAR.
================(Build #2148 - Engineering Case #559402)================
In previous versions of SQL Anywhere, a password connection parameter was
not written to a FILEDSN (.dsn file). Beginning with version 11.0.0, the
password is written to the .dsn file in the format "Password={some pwd}".
This behavior is not in keeping with the spirit of the ODBC specification
which states, "the PWD keyword is not stored in a .dsn file". This
change in behavior occurred as a result for a change to the SQL Anywhere
ODBC driver to return "Password={some pwd}", instead of "PWD={some
pwd}" in the connection string. Also, "Userid=user" was returned
instead of "UID=user". The Microsoft driver manager only recognizes
the UID and PWD forms of the connection parameters, which caused it to add
the Password parameter. This problem has been corrected. The SQL Anywhere
ODBC driver will now return "UID={user};PWD={some pwd}" in the
connection string, as it did in earlier versions. This will result is the
Driver Manager no longer including the password.
================(Build #2148 - Engineering Case #559383)================
When configuring an ODBC FileDSN on Windows, NEWPWD=* incorrectly showed
up in the Advanced tab of the configuration dialog. The NEWPWD=* parameter
was not actually added to the FileDSN though. This has been fixed.
================(Build #2147 - Engineering Case #551956)================
When the TargetType parameter to the ODBC function SQLGetData() is SQL_C_DEFAULT,
the driver selects the default C data type based on the SQL data type of
the source.
For NCHAR types, the Microsoft ODBC driver selects a SQL_C_CHAR binding.
Microsoft acknowledges in its knowledgebase article http://support.microsoft.com/default.aspx/kb/293659
that to do so is an error, but states that it does this to support older
legacy applications. The SQL Anywhere ODBC driver selected a SQL_C_WCHAR
binding. This caused problems with applications like Microsoft Access, that
expected the Microsoft ODBC behaviour. This problem in Access could have
been seen when setting up a linked table using the SQL Anywhere ODC driver
to a database table containing NCHAR, NVARCHAR, or LONG NVARCHAR column types.
The resulting table columns were displayed with "#deleted" values.
To conform to the Microsoft ODBC driver behaviour, the SQL Anywhere ODBC
driver has been changed. Now, the SQL Anywhere ODBC driver selects a SQL_C_CHAR
binding for NCHAR, NVARCHAR, and LONG NVARCHAR (including NTEXT) types when
the "MS Applications ( Keys In SQLStatistics)" checkbox is selected
in the ODBC Administrator configuration dialog for SQL Anywhere datasources.
This option can also be specified as the connection parameter "KeysInSQLStatistics=YES"
in a SQL Anywhere ODBC driver connection string. This change affects any
ODBC function, like SQLBindCol, SQLBindParameter, and SQLGetData, where SQL_C_DEFAULT
can be specified.
================(Build #2144 - Engineering Case #557955)================
Calls the function SQLGetInfo() would have incorrectly returned SQL_CB_NULL
for SQL_CONCAT_NULL_BEHAVIOR. As the result of the server concatenating a
string and NULL is the string, calls to SQLGetInfo() have now been corrected
to return SQL_CB_NON_NULL for SQL_CONCAT_NULL_BEHAVIOR.
================(Build #2144 - Engineering Case #555236)================
SQLColumns returns a result set including COLUMN_SIZE, BUFFER_LENGTH, and
CHAR_OCTET_LENGTH among other things. For a column typed NCHAR(30) or NVARCHAR(30),
the COLUMN_SIZE was returned as 30 and the BUFFER_LENGTH as 30. The BUFFER_LENGTH
should have been 60. For CHAR_OCTET_LENGTH, NULL is returned, whereas it
should have ben 60 as well.
From the ODBC standand:
"COLUMN_SIZE": For character types, this is the length in characters
of the data; The defined or maximum column size in characters of the column
or parameter (as contained in the SQL_DESC_LENGTH descriptor field). For
example, the column size of a single-byte character column defined as CHAR(10)
is 10.
"BUFFER_LENGTH": The defined or the maximum (for variable type)
length of the column in bytes. This is the same value as the descriptor field
SQL_DESC_OCTET_LENGTH.
"CHAR_OCTET_LENGTH": The maximum length in bytes of a character
or binary data type column. For all other data types, this column returns
a NULL.
These problems have been fixed.
================(Build #2143 - Engineering Case #555059)================
When using Microsoft's AppVerifier (a development/debugging tool), the tool
may have reported various errors, such as the use of an invalid handle in
client libraries (ODBC, dblib, etc) or in the database server. These problems
have been fixed and the database server and client libraries now run cleanly
under AppVerifier.
Note, without the use of AppVerifier it would have been extremely rare for
users to encounter these problems.
================(Build #2138 - Engineering Case #555963)================
If an NCHAR, NVARCHAR, or LONG NVARCHAR parameter was bound as SQL_C_DEFAULT,
the binding would have defaulted to SQL_C_CHAR, instead of SQL_C_WCHAR. This
has been corrected.
================(Build #2138 - Engineering Case #555617)================
When calling SQLForeignKeys(), the result set was not returned in the correct
sort order. According to the ODBC standard, the sort orders are:
1. If the foreign keys associated with a primary key are requested, the
result set is ordered by FKTABLE_CAT, FKTABLE_SCHEM, FKTABLE_NAME, and KEY_SEQ.
2. If the primary keys associated with a foreign key are requested, the
result set is ordered by PKTABLE_CAT, PKTABLE_SCHEM, PKTABLE_NAME, and KEY_SEQ.
This has now been corrected.
================(Build #2130 - Engineering Case #554080)================
Applications which used the EncryptedPassword connection parameter could
have crashed when attempting to connect. This has been fixed.
================(Build #2579 - Engineering Case #662896)================
When using the OLEDB provider, if a statement was prepared, executed, and
then the ADO MoveFirst() (OLE DB RestartPosition() ) method was called when
the cursor type was forward-only, the statement would have become unprepared.
Subsequent attempts to execute the prepared statement would then have failed.
This problem has been corrected.
================(Build #2563 - Engineering Case #658887)================
The OLE DB DBSCHEMA_FOREIGN_KEYS rowset returned the following indicated
integer values for the UPDATE_RULE or DELETE_RULE referential actions.
CASCADE 0
if referential action is NULL 1
SET NULL 2
SET DEFAULT and RESTRICT 3
These values, derived from the ODBC SQLForeignKeys result set, did not match
the following OLEDB constants defined for these referential actions.
DBUPDELRULE_NOACTION = 0x0
DBUPDELRULE_CASCADE = 0x1
DBUPDELRULE_SETNULL = 0x2
DBUPDELRULE_SETDEFAULT = 0x3
Furthermore, the DBSCHEMA_FOREIGN_KEYS rowset should have returned strings
rather than integers for the UPDATE_RULE or DELETE_RULE referential actions.
The OLE DB specification states:
If a rule was specified, the UPDATE_RULE or DELETE_RULE value is one of
the following:
"CASCADE" — A <referential action> of CASCADE was specified.
"SET NULL" — A <referential action> of SET NULL was specified.
"SET DEFAULT" — A <referential action> of SET DEFAULT was
specified.
"NO ACTION" — A <referential action> of NO ACTION was specified.
Providers should return NULL only if they cannot determine the UPDATE_RULE
or DELETE_RULE. In most cases, this implies a default of NO ACTION.
Also, the fix for Engineering case 620136 did not handle the situation when
there was no declared Primary Key in the primary table but there were table
or column (not nullable) Unique Constraints that permitted the addition of
foreign keys.
These problems have been fixed. The Upgrade utility should be used to update
the OLE DB schema rowset support in any database used with ADO, ADOX or OLE
DB.
================(Build #2539 - Engineering Case #651383)================
As of the changes for Engineering case 633120, a SQL query producing multiple
result sets was not handled correctly by the SQL Anywhere OLE DB provider.
This problem has now been corrected. The cursor is no longer closed after
the first result set is processed.
================(Build #2514 - Engineering Case #645953)================
The DBSCHEMA_PROVIDER_TYPES rowset schema incorrectly returned 0x in the
LITERAL_PREFIX column for varbit types. The apostrophe character (') is now
returned in the LITERAL_PREFIX and LITERAL_SUFFIX columns instead.
================(Build #2500 - Engineering Case #642865)================
The SQL Anywhere OLE DB provider was ignoring the Location and Initial Catalog
connection parameters. This problem has been fixed.
"Location" can now be used to specify the host name and port of
the database server. The form is hostname:port (e.g., username-pc:3628).
"Location" is mapped to the SQL Anywhere "Host" connection
parameter for version 12 or later and the "CommLinks" connection
parameter for version 11 or earlier.
"Initial Catalog" can now be used to specify the database to connect
to when more than one database has been started by a SQL Anywhere database
server. "Initial Catalog" is mapped to the SQL Anywhere "DatabaseName"
(DBN) connection parameter.
================(Build #2499 - Engineering Case #642980)================
A number of corrections and improvements have been made to the SQL Anywhere
OLE DB schema rowset support procedures:
- If a catalog name is specified as one of the schema restrictions, the
procedure will make sure it matches the current catalog. If it does not,
a single row will be returned with NULLs.
- Any rowset that can return a catalog name in a column will now return
the current database name in that column instead of NULL.
- The rows returned in the DBSCHEMA_PROVIDER_TYPES rowset have been slightly
reordered for better results with Microsoft tools. This was done since Microsoft
tools ignore the BEST_MATCH column and use the first row that matches the
datatype it is searching for.
- In the DBSCHEMA_PROVIDER_TYPES schema, the XML datatype will now set
the DATA_TYPE column to 141 (DBTYPE_XML), the IS_LONG column to 1 and return
2GB instead of 32767 for COLUMN_SIZE.
- In the DBSCHEMA_PROVIDER_TYPES schema, the TIMESTAMP WITH TIME ZONE datatype
will now set the DATA_TYPE column to 146 (DBTYPE_DBTIMESTAMPOFFSET). This
is supported in version 12 or later of SQL Anywhere.
- An entry for the REAL datatype was missing from the DBSCHEMA_PROVIDER_TYPES
rowset. This row has been added.
To install these updates into a database, the Upgrade utility (dbupgrad),
or the ALTER DATABASE UPGRADE statement can be used.
================(Build #2494 - Engineering Case #641092)================
The changes for Engineering case 633120, introduced a problem with returning
a character string column value when the length of the column value was not
bound by the consumer (i.e., the consumer does not provide a pointer to a
length field). In this special case, the returned string value should be
null-terminated. This has been fixed.
================(Build #2490 - Engineering Case #639712)================
The OLE DB provider's TABLES, TABLES_INFO, and VIEWS schema rowset support
procedures do not identify MATERIALIZED VIEWs and TEXT CONFIGURATION objects
correctly. Materialized views are now reported as "VIEWS", and
text configuration objects are now identified as "TEXT", in the
TABLE_TYPE column.
Also, the OLE DB provider's TABLES schema rowset included an unnecessary
and undocumented column "PREFIXSYSOWNED". This column has been
removed from the rowset to match similar behavior of the stored procedure
than produces theTABLES_INFO schema rowset.
The OLE DB provider's TABLE_CONSTRAINTS schema rowset support procedure
fails with the error "Column 'check' not found". This has been
fixed.
The Upgrade utility (dbupgrad) should be used to update the OLE DB schema
rowset support in any database used with ADO, ADOX or OLE DB.
================(Build #2484 - Engineering Case #638848)================
A few improvements have been made to ADOX/OLEDB table creation.
Long types are now mapped to SQL Anywhere long types. For example, an adLongVarChar
column is now mapped to "LONG VARCHAR" instead of "CHAR(0)".
Wide types are now mapped to SQL Anywhere nchar types instead of char types.
For example, adWChar is now mapped to "NCHAR" and adLongVarWChar
is now mapped to "LONG NVARCHAR".
An adSingle column with no specifed precision will now default to REAL rather
than FLOAT(0), which generated a syntax error.
An adDecimal column with no specified precision and scale will now default
to DECIMAL rather than DECIMAL(0,0), which generated a syntax error.
An adNumeric column with no specified precision and scale will now default
to NUMERIC rather than NUMERIC(0,0), which generated a syntax error.
An adLongVarBinary column will map to the IMAGE type rather than BINARY(0),
which generated a syntax error.
An adCurrency column is now supported and will map to a column of type MONEY.
An adDate column is now supported and will map to a column of type DATETIME.
If a table or column name is not defined, OLEDB will no longer fault with
a NULL pointer reference. Instead, the name "undefined" will be
used.
The following code fragment is a VBScript example for creating a table using
ADOX statements.
Set db = CreateObject( "ADOX.Catalog" )
Set ntable = CreateObject( "ADOX.Table" )
ntable.Name = "testTable"
ntable.Columns.Append "Col_1", adNumeric
ntable.Columns.Append "Col_2", adDate
ntable.Columns.Append "Col_3", adChar, 32
ntable.Columns.Append "Col_4", adVarChar, 32767
ntable.Columns.Append "Col_5", adLongVarChar
ntable.Columns.Append "Col_6", adLongVarWChar
db.Tables.Append ntable
================(Build #2464 - Engineering Case #634664)================
The Microsoft SQL Server Reporting Services 2008 application uses the Linked
Server mechanism to communicate via OLE DB to a SQL Anywhere server. It can
send EXEC statements of the following form to the SQL Anywhere OLE DB provider:
EXEC owner.procedure_name :parm1, :parm2, ...
where :parm1, etc. are bound parameters.
The SQL Anywhere OLE DB provider has been improved to now handle this syntax.
================(Build #2455 - Engineering Case #633120)================
Microsoft's SQL Server 2005/2008 Replication software allocates a 0x200 byte
buffer for the TYPE_NAME column of the DBSCHEMA_PROVIDER_TYPES rowset. It
then creates a DBBINDING structure identifying the length of the buffer as
0x300 bytes. When the SQL Anywhere OLE DB provider initializes the buffer
with nulls, a stack overrun occurs and Microsoft's Replication software faults.
As a work-around for Microsoft's bug, the SQL Anywhere OLE DB provider will
no longer initialize the consumer's buffer with nulls.
================(Build #2454 - Engineering Case #633125)================
Improvements to the DBSCHEMA_PROVIDER_TYPES rowset have been made to make
it more consistent with Microsoft SQL Server.
================(Build #2445 - Engineering Case #631330)================
Some inconsistencies between SQL Anywhere OLE DB column metadata information
and run-time column information caused problems with accessing tables via
the Microsoft SQL Server "Linked Server" mechanism. These problems
affected NCHAR, NVARCHAR,LONG NVARCHAR, VARBIT, LONG VARBIT, and TIMESTAMP
WITH TIME ZONE columns. The TIMESTAMP WITH TIMEZONE data type is new to version
12.0.0. These problems have been fixed. Table rows inserted using the OLE
DB OpenRowset/InsertRows methods are now done with autocommit turned off.
Once the inserts are completed, the rows are committed.
For the complete fix to this problem, use the Upgrade utility (dbupgrad)
to upgrade existing databases with fixes for the OLE DB schema rowset support
(metadata support).
================(Build #2439 - Engineering Case #629606)================
When using SQL Server Integration Services (SSIS), an attempt to migrate
tables between SQL Anywhere/Sybase IQ and SQL Server databases would have
failed. This problem has been corrected.
Note, if the Data Flow consists of more than 10 tables that are to be migrated
to SQL Server from a SQL Anywhere server, the Personal server should not
be used since each table is moved asynchronously on a separate connection
(i.e., more than 10 simultaneous connections will be made to the SQL Anywhere
server and the number of simultaneous connections is limited with the Personal
server).
================(Build #2438 - Engineering Case #627407)================
.NET applications using the SQL Anywhere OLE DB provider may have failed
with the following error for OleDbDataReader.Close():
"Reader Exception: Attempted to read or write protected memory. This
is often an indication that other memory is corrupt."
This has been fixed.
================(Build #2438 - Engineering Case #627266)================
An "Out of Memory" assertion may have been raised by the SQL Anywhere
OLE DB provider, which may have been indicative of heap corruption. This
problem may arise when binding parameters that are described as DBTYPE_IUNKNOWN
(a type used for LONG VARCHAR parameters). This problem has been fixed.
================(Build #2402 - Engineering Case #620289)================
If the length for a data column was described as SQL_NTS (-3), the SQL Anywhere
OLE DB provider would not have computed the correct length for the column
on 64-bit platforms. This problem has been fixed.
Note, this problem was seen with SQL Server Integration Services applications
on 64-bit Windows platforms, it does not appear in ADO applications.
================(Build #2402 - Engineering Case #620287)================
The SQL Anywhere OLE DB provider would have leaked memory if the InsertRow
method was called with no row handle return pointer.
For example,
HRESULT hr = rowset::InsertRow( hChapter, hAccessor, pData, NULL
);
would have resulted in a memory leak, since phRow (the 4th argument) is
NULL. This problem may have occurred when using the provider with SQL Server
Integration Services (SSIS).
This problem has been fixed.
================(Build #2401 - Engineering Case #620136)================
The SQL Anywhere OLEDB provider's result sets for PRIMARY_KEYS and FOREIGN_KEYS
did not show the correct constraint name (PK_NAME column). Instead, they
listed the table name. This problem has now been corrected.
================(Build #2387 - Engineering Case #617397)================
By default, the OLE DB provider indicates, through a property settting, that
it does not support returning multiple result sets, although the provider
is capable of doing so. An undocumented connection option "ASA Multiple
Results=TRUE" will enable the returning of multiple result sets. The
provider has been changed so that returning of multiple results sets is now
supported by default. More specifically, DBPROP_MULTIPLERESULTS is now set
to DBPROPVAL_MR_SUPPORTED by default. If desired, the connection option "ASA
Multiple Results=FALSE" can be used to change the property value to
DBPROPVAL_MR_NOTSUPPORTED. However, there is no known benefit to using this
option.
================(Build #2365 - Engineering Case #611017)================
When the OLE DB provider's GetNextRows method was called, the next row would
not have been read if the previous row had NULL column values. This problem
was introduced by the changes for Engineering case 605058, and has now been
fixed.
================(Build #2350 - Engineering Case #606642)================
If a division by zero error occurred in a result set, the SQL Anywhere OLE
DB provider would have returned DB_S_ENDOFROWSET instead of 0x800a000b (divide
by zero). For example, the following SELECT statement will result in a division
by zero error if the column value for "num" is 3:
SELECT num/(num-3) FROM divisionby0
This problem has been fixed. ADO will now set the correct error number (11)
and description (Division by zero) from the error code returned by OLE DB.
================(Build #2347 - Engineering Case #606229)================
When using the SQL Anywhere OLE DB provider, a memory leak cpuld have occurred
when fetching data LONG VARCHAR or long VARBINARY columns. This problem has
been fixed.
================(Build #2344 - Engineering Case #605803)================
When uploading data into a SQL Anywhere database from Microsoft SQL Server
using the Linked Server mechanism, SQL Server could have reported that it
had received inconsistent metadata information and failed the upload. This
was due to the SQL Anywhere OLE DB provider returning inconsistent column
lengths for VARCHAR and NVARCHAR columns when using the UTF8 character set
collation. For example, an NVARCHAR(100) column length would have been reported
as 400, which is the octet length for this column using the UTF8 collation,
but the "ulColumnSize" field of the DBCOLUMNINFO structure should
contain the maximum length in characters for DBTYPE_STR and DBTYPE_WSTR columns,
not the maximum length in bytes. This problem has been corrected.
================(Build #2344 - Engineering Case #605058)================
If a client-side cursor UPDATE was performed using the SQL Anywhere OLE DB
provider, and the column was of type VARCHAR(n), where n was greater than
or equal to 256 and the column value was originally NULL, then an error message
similar to the following would have been issued by ADO:
Row cannot be located for updating. Some values may have been changed
since it was last read.
The OLE DB provider was failing to return DBSTATUS_S_ISNULL for the column
value and returned an empty string instead. This caused ADO to generate an
UPDATE statement with a WHERE clause expression of the form "column
= ?" and a bound value of '' (a zero-length string). This problem has
been fixed. ADO will now generate an UPDATE statement with a WHERE clause
expression of the form "column IS NULL".
A workaround is to use a server-side cursor.
================(Build #2316 - Engineering Case #590210)================
The SQL Anywhere OLE DB provider implementation of IMultipleResults::GetResult()
returned an incorrect 'rows affected' count for inserts, updates, and deletes.
In this situation, the result returned by OleDbCommand.ExecuteNonQuery(),
which called the GetResult() method, was -1. This problem has now been fixed
to return the correct 'rows affected' count.
================(Build #2266 - Engineering Case #575490)================
Wide-fetching a query that referenced a proxy table could have returned the
last row multiple times, instead of returning no rows and the SQLE_NOTFOUND
warning. This has been fixed.
================(Build #2254 - Engineering Case #574697)================
If a NUMERIC INOUT parameter was bound as SQL_PARAM_INPUT_OUTPUT, the result
that was returned to the caller was always 0.
For example:
CREATE PROCEDURE _TEST_PROC
(
@IN_VAL1 NUMERIC(7, 0),
@IN_VAL2 NUMERIC(7, 0),
@OUT_VAL NUMERIC(7, 0) OUTPUT
)
AS
BEGIN
SET @OUT_VAL = @IN_VAL1 + @IN_VAL2
END
If the statement "CALL PROCEDURE _TEST_PROC( 100, 200, ? )" was
prepared, and the third parameter was bound as SQL_PARAM_INPUT_OUTPUT, the
result after execution was 0. It should have been 300. If the parameter was
bound as SQL_PARAM_OUTPUT, the result returned was correct.This problem has
been fixed.
Note that in the above Transact SQL procedure, OUT_VAL is an INOUT parameter,
since Transact SQL parameters are always INPUT and the addition of the OUTPUT
clause makes them INOUT.
================(Build #2175 - Engineering Case #564435)================
In an ADO/OLE DB application, when a UNIQUEIDENTIFIER (or GUID) was used
as a parameter in a query, an error message like "Cannot convert 0x
to a uniqueidentifier" may have resulted, or the query may simply have
failed to return any results. This problem has been fixed.
Sample schema:
create table uuidtable( pkey int, uuid uniqueidentifier, stringform uniqueidentifierstr
);
Sample query:
select * from uuidtable where uuid = ?
The following .NET/OLE DB example shows typical uniqueidentifier parameter
binding:
OleDbCommand cmd = new OleDbCommand(txtSQLStatement.Text.Trim(), _conn);
OleDbParameter param1 = new OleDbParameter();
param1.ParameterName = "@p1";
param1.DbType = System.Data.DbType.Guid;
cmd.Parameters.Add(param1);
cmd.Parameters[0].Value = new Guid("41dfe9f9-db91-11d2-8c43-006008d26a6f");
================(Build #2133 - Engineering Case #554998)================
When ADO asks for the schema information related to a query (e.g., SELECT
* FROM Products), it requests a number of attributes like "IDNAME",
"TABLENAME", etc. The SQL Anywhere OLE DB provider returns a DBID
for schema rowset columns that matches Microsoft's declared DBID. For example,
the schema column DBCOLUMN_IDNAME is defined in Microsoft's OLEDB.H header
file as follows:
extern const OLEDBDECLSPEC DBID DBCOLUMN_IDNAME = {DBCIDGUID, DBKIND_GUID_PROPID,
(LPOLESTR)2};
This is what the OLE DB provider would return as the DBID for the "IDNAME"
column. This strategy works for many ADO methods that request schema information.
However, the following example illustrates a problem with the ADO RecordSet
Save() method.
Dim strConnection = "PROVIDER=SAOLEDB;ServerName=demo;DatabaseName=demo;USERID=DBA;PASSWORD=sql"
Dim strSQLStatement = "SELECT ID, Name FROM Products"
Dim strXMLLocation = "c:\\temp\\products.xml"
Dim objADOConnection As New ADODB.Connection
Dim objADORecordSet As New ADODB.Recordset
objADOConnection.Open(strConnection)
objADORecordSet.Open(strSQLStatement, objADOConnection, ADODB.CursorTypeEnum.adOpenStatic,
ADODB.LockTypeEnum.adLockOptimistic)
If Not (objADORecordSet.EOF And objADORecordSet.BOF) Then
objADORecordSet.MoveFirst()
objADORecordSet.Save(strXMLLocation, ADODB.PersistFormatEnum.adPersistXML)
End If
For reasons unknown, the ADO RecordSet Save() method returns the error "catastrophic
failure".
The SQL Anywhere OLE DB provider has been changed to return only the "property
ID" part of the DBID. This is equivalent to returning the following
structure.
extern const OLEDBDECLSPEC DBID DBCOLUMN_IDNAME = {NULL,
DBKIND_PROPID, (LPOLESTR)2};
This permits the ADO RecordSet Save() method to complete successfully.
================(Build #2604 - Engineering Case #669435)================
On Unix systems, when using the Service utility (dbsvc) to create a service
for the MobiLink client (dbmlsync), the following error would have been reported:
svc_t_dbmlsync: No such file or directory
This was due to the file svc_t_dbmlsync not having been installed in the
bin32/dbsvc_scripts directory. This has been corrected.
================(Build #2596 - Engineering Case #667902)================
SQL Anywhere EBF installs would have failed to update the SQL Anywhere Monitor
(Developer) database (samonitor.db) if the SQL Anywhere Monitor had been
used after the EBF build date. This has now been fixed.
================(Build #2585 - Engineering Case #665004)================
When trying to connect using the Ruby DBI interface, the driver did not raise
an error if the username/password was invalid. Instead it silently failed.
This has been fixed.
================(Build #2563 - Engineering Case #659357)================
Running the Deployment wizard when SQL Anywhere had been installed to directory
with a path containing multi-byte characters would have caused the generation
of the MSI to fail with an error like: "C:\Syç¾ç½²\SQL Anywhere 12\bin32\dblib12.dll
(Not Found)". This has been fixed.
================(Build #2560 - Engineering Case #657748)================
When using the Microsoft ODBC Data Source Administrator, an attempt to create
a DSN that used a FIPS Certificate may have resulted in a crash. The has
been fixed.
================(Build #2553 - Engineering Case #656162)================
When building a CAB file to deploy SQL Anywhere for Windows Mobile, a start
menu folder "sqlany12" would have been created, the folder name
should have been "sqlany11". This has been corrected.
================(Build #2522 - Engineering Case #647854)================
When running the fetchtst tool for testing the performance of queries (in
samples-dir\SQLAnywhere\PerformanceFetch) on a SQL statement larger than
10K, fetchtst may have crashed. This has now been fixed.
================(Build #2518 - Engineering Case #647005)================
The CE Deployment Wizard Installer would have throw an exception when clicking
the 'Deploy to Mobile Device Now' button on a system which did not have ActiveSync
installed. This has been fixed so that the following error is now issued:
Error: Microsoft Activesync is not installed. CEAppMgr.exe is not detected.
.CAB file will not be deployed.
================(Build #2501 - Engineering Case #642996)================
If a database encrypted with AES_FIPS or AES256_FIPS was copied to a CE device,
the server would have been unable to start it. This has been fixed.
================(Build #2495 - Engineering Case #640776)================
When running an MSI install that was generated by the Deployment wizard,
the ulodbc11.dll was not self registered. This has now been fixed.
================(Build #2494 - Engineering Case #640110)================
When executing a remote procedure call to an ASE server, if the procedure
involved output parameters, then there was a chance the call would have failed
with the remote error "output parameters will only be returned from
this stored procedure when you use only parameter markers to pass parameter
values". This problem has now been fixed and the remote call should
now execute correctly.
================(Build #2490 - Engineering Case #640109)================
The deployment wizard was failing when attempting to register one of our
v4.0 .Net assemblies on systems where version 4.0 of the .NET framework was
not installed. This has been fixed.
================(Build #2490 - Engineering Case #633118)================
The Deployment Wizard did not deploy V3.5 and V4.0 .Net assemblies. They
have now been added to the list of files we deploy.
================(Build #2483 - Engineering Case #638738)================
Windows CE applications, including SA utilities, requiring aygshell.dll to
be present on the device or they would not have loaded. This worked fine
on Windows Mobile 5 and later devices, but not for non-Windows Mobile CE
5.0 and 6.0 devices. This has been corrected by trying to dynamically load
aygshell.dll if it is present, and skip these functions otherwise. For non-Windows
Mobile CE devices, buttons are displayed on the main window for shutdown/hide/etc,
instead of relying on creating menus accessible via softkeys since this would
require aygshell.dll.
================(Build #2451 - Engineering Case #627649)================
The PHP driver would have crashed when trying to open multiple result sets
using SASQL_USE_RESULT or sasql_real_query() and sasql_use_result(). This
has been fixed.
================(Build #2445 - Engineering Case #630338)================
If the option row_counts was set to 'On', the system procedures sa_performance_statistics
and sa_performance_diagnostics did not return a result set, and the procedure
sa_describe_query caused an assertion failed 109512 error. These problems
have been fixed.
================(Build #2431 - Engineering Case #627788)================
Selecting the database property "name" for viewing would have prevented
the list of database properties from refreshing. This has been fixed.
================(Build #2428 - Engineering Case #626617)================
A synchronization request from a client prior to version 11, that was using
a UTF8-encoded database, would have failed against 64-bit Unix servers.
This has been fixed.
Note, this problem does not occur with the 32-bit versions of the server.
================(Build #2424 - Engineering Case #625465)================
When deploying SQL Anywhere using the Deployment wizard, the PHP Extenv DLLs:
(php-<PHP version>_sqlanywhere_extenv11.dll) and PHP SQL Anywhere DLLs
(php-<PHP_version>_sqlanywhere.dll) were included, but not the file
dbcapi.dll. This has been corrected so that dbcapi.dll is now deployed as
well.
================(Build #2418 - Engineering Case #619195)================
Generating an MSI install using the Deployment Wizard, should have included
these files:
IANYWHERE.MOBILINK.CLIENT.DLL
IANYWHERE.DATA.SQLANYWHERE.DLL
but they were not included in the assembly/v2 directory.
These files were being deployed directly into the GAC, but were not being
put into the assembly/v2 directory. This has been corrected, and they are
now installed into both locations.
================(Build #2399 - Engineering Case #614818)================
When deploying support for dbunload to a windows CE device, the following
scripts were missing: unloadold.sql, optdeflt.sql and opttemp.sql. These
are now deployed to the device.
================(Build #2395 - Engineering Case #616656)================
When using the SQL Anywhere PHP module, and binding a null numeric value
to a statement with sasql_stmt_bind_param_ex, the null value would have been
converted to a 0. This resulted in a 0 being passed in the statement instead
of the desired null value. Resetting the variable to null after binding would
have given the desired behavior. This has now been fixed.
================(Build #2391 - Engineering Case #618014)================
The TableViewer ADO.Net sample application queries SYSTABLE to determine
the table list to display. That query would have incorrectly returned text
index tables, if defined, which cannot be directly manipulated. If a query
was subsequently issued using a text index table, the error SQLE_TEXT_CANNOT_USE_TEXT_INDEX
would have occurred. The query has now been rewritten to only display base
tables.
Additional changes to the application were also made to improve usability.
First, functionality that required an active database connection such as
the Execute button are disabled if there is no active connection. Second,
a simple SELECT statement is generated based on the table selected from the
table list control.
================(Build #2379 - Engineering Case #616031)================
On Unix systems other than Linux, JAR files were installed with 0700 permissions,
which meant that they were only usable by the user who ran the install. This
has been fixed so that executables, shared objects, and shell scripts are
now installed with 0555 permissions, while the permissions of all other files
will be 0444.
As a workaround, the following command may be run to fix the permissions
of the JAR files:
find $SQLANY11 -name "*.jar" -exec chmod 444 {} \;
================(Build #2373 - Engineering Case #610982)================
When installing SQL Anywhere on a Windows system that used a multibyte character
set as the ANSI code page, the SQL Anywhere performance monitor counters
may not have been registered correctly and no error message would have been
displayed. At startup, the server would have displayed the message "Unable
to initialize NT performance monitor data area; server startup continuing".
This problem has now been fixed.
================(Build #2362 - Engineering Case #607874)================
The SQL Anywhere C API version of DBD::SQLAnywhere perl driver did not fetch
floating point/double values correctly (incorrect values would have been
returned). This problem has been fixed.
================(Build #2350 - Engineering Case #596034)================
Attempting to run a silent install using an MSI file created by the Deployment
wizard, could have failed with the error:
Error 2769: Custom Action CAD_writeStrings did not close 3 MSIHANDLEs.
This has been corrected by no longer using MSIHANDLEs in custom actions,
but rather using PMSIHANDLE variables, which are automatically freed when
they go out of scope.
================(Build #2346 - Engineering Case #606014)================
When the script sqlanydb.py was run, it would not have propagated some fetch-related
errors to the application. This has been fixed.
Support has been added for Connection and Cursor .messages and .errorhandler
attributes as outlined in PEP 249. Support has been added for SPARC 64 (and
other platforms where sizeof(c_void_p) != sizeof(c_int)).
================(Build #2343 - Engineering Case #605386)================
When any of the Java based administration tools (Interactve SQL, Sybase Central,
Mobilink Monitor, DBConsole) were launched on Mac OS X systems, two copies
of
the admin tool icons were being displayed on the Dock. This has been fixed.
================(Build #2343 - Engineering Case #605385)================
When installing 11.0.1 on Mac OS X 10.6 (Snow Leopard), the registration
key panel had problems displaying the key as entered. Sometimes, nothing
would have been displayed, other times mangled characters would have been
displayed. This has been fixed.
================(Build #2309 - Engineering Case #587699)================
If the DBTools function DBSynchronizeLog() was called when no callback routines
(errorrtn, msgrtn, warningrtn, logrtn, progress_msg_rtn, progress_index_rtn,
msgqueuertn, confirmrtn) were defined, it would have crashed. This problem
has been fixed. It is no longer necessary to define all callback routines.
A workaround is to define each of the callback routines. Example:
a_sync_db sync;
.
.
.
sync.confirmrtn = (MSG_CALLBACK) ConfirmCallback;
================(Build #2293 - Engineering Case #584722)================
When installing EBFs on Unix systems, the installer would not have applied
the updates if the destination directory included spaces. This has been fixed.
================(Build #2275 - Engineering Case #577512)================
Sybase Central plugins for Ultralite & QAnywhere were not being registered
when deployed by the Deployment wizard. This has now been corrected.
================(Build #2267 - Engineering Case #580590)================
The SQL Anywhere Python Database interface now supports the ability to register
callbacks to control how database types are mapped into Python objects when
results are fetched from the database server. Callbacks are registered using
the new module-level "register_converter" method. This method should
be called with the database type as the first parameter, and the conversion
function as the second parameter. For example, to request that sqlanydb.py
create Decimal objects for data in any column described as having type DT_DECIMAL:
import sqlanydb
import decimal
def convert_to_decimal(num):
return decimal.Decimal(num)
sqlanydb.register_converter(sqlanydb.DT_DECIMAL, convert_to_decimal)
Converters may be registered for the following database types:
DT_DATE
DT_TIME
DT_TIMESTAMP
DT_VARCHAR
DT_FIXCHAR
DT_LONGVARCHAR
DT_STRING
DT_DOUBLE
DT_FLOAT
DT_DECIMAL
DT_INT
DT_SMALLINT
DT_BINARY
DT_LONGBINARY
DT_TINYINT
DT_BIGINT
DT_UNSINT
DT_UNSSMALLINT
DT_UNSBIGINT
DT_BIT
DT_LONGNVARCHAR
================(Build #2267 - Engineering Case #579233)================
When using the SQL Anywhere Python database interface (sqlanydb.py) the Cursor.rowcount
attribute value was inaccurate under when calling executemany. The rowcount
attribute was set to the number of rows affected/returned by the last execute
in the series. This has been fixed. The rowcount attribute will now contain
the sum of the row counts of the executes (or -1 if unknown).
Also, when the server returned an estimated, rather than an exact row count,
Cursor.rowcount was set to a negative number, the absolute value of which
was the estimate. Cursor.rowcount will now be set to -1 in this case.
================(Build #2266 - Engineering Case #578859)================
The GUI launchers for the 11.0.1 Administration Tools no longer worked after
Java for Mac OS X v10.5 Update 4 was installed. The following error messages
would have appeared in the logs:
[JavaAppLauncher Warning] Java application launched from PPC or bad stub.
Relaunching in 32-bit, and tagging sub-processes to prefer 32-bit with $JAVA_ARCH=i386.
[JavaAppLauncher Error] This process is [i386] and was re-exec'd from [i386],
but for some reason we are trying re-exec to [].
[JavaAppLauncher Error] unable to find a version of Java to launch
This has been fixed.
There are two workarounds:
1. Use the command line launchers instead of the GUI launchers.
2. Run the following from a terminal:
. <SQL Anywhere 11 Installation Directory>/System/bin64/sa_config.sh
for TOOL in DBConsole.app InteractiveSQL.app MobiLinkMonitor.app
SybaseCentral.app ; do chmod +w "$SQLANY11/../$TOOL/Contents/MacOS/
JavaApplicationStub" ; cp /System/Library/Frameworks/JavaVM.framework/
Versions/A/Resources/MacOS/JavaApplicationStub64 "$SQLANY11/../$TOOL/
Contents/MacOS/JavaApplicationStub" ; done
Note, the portion of the script from "for" to "done"
should be one single line.
================(Build #2265 - Engineering Case #578385)================
Following an initial install of version 11.0.1, the installer would have
left incorrect information as to the version of the documentation that was
installed, 11.0.0 instead of 11.0.1. Any method of checking for documentation
updates, via the web page, at the end of install, using dbsupport, or using
the Admin Tools, would then have used the incorrect version. This has now
been corrected.
================(Build #2261 - Engineering Case #577714)================
The ADO.Net sample program LinqSample was not working correctly. This has
now been fixed.
================(Build #2260 - Engineering Case #577334)================
When using the SQL Anwhere C API (drivers for PHP, Perl, Python, and Ruby),
applications executing RAISERROR with a user-defined error, would have seen
the correct error code returned, but the error message was returned as "Unknown
error". This has been fixed.
================(Build #2260 - Engineering Case #577092)================
Previously, the SQL Anywhere Python driver (sqlanydb.py) raised an OperationalError
for all database errors. The driver now raises an IntegrityError for the
following SQLCODEs:
SQLCODE Error
-193 Primary key for table '%1' is not unique : Primary key value
('%2')
-194 No primary key value for foreign key '%1' in table '%2'
-195 Column '%1' in table '%2' cannot be NULL
-196 Index '%1' for table '%2' would not be unique
================(Build #2244 - Engineering Case #572549)================
On Solaris systems with a non-UTF8 locale (eg. GB18030), when installing
SQL Anywhere to a path containing MBCS characters, the installer would have
failed to register the Sybase Central plugins. This has now been fixed.
================(Build #2242 - Engineering Case #586604)================
On Solaris systems, if the directory /usr/ucb precedes /bin and /usr/bin
in the PATH, the installer could have failed. Fixed by prepending /bin and
/usr/bin to our local copy of PATH.
================(Build #2240 - Engineering Case #564857)================
In very rare circumstances, SQL Anywhere .NET provider could have crashed
the work process in IIS. This problem has been fixed
================(Build #2235 - Engineering Case #571253)================
When installing only the MobiLink components on Linux systems using the 1.0.1
GA install, the dbfhide utility was not installed. This utility should be
installed, as it is used for both MobiLink and Relay Server setup. This has
been corrected.
================(Build #2226 - Engineering Case #570115)================
Character set translation wasn't being done properly by the SQL Anywhere
Python driver. Unicode encoding and decoding errors were possible, as well
as incorrect translations. This has been fixed so that conversions are based
on the connection's CharSet property.
================(Build #2214 - Engineering Case #569114)================
The SQL Anywhere Monitor, when installed by the standalone installer, was
not able to monitor MobiLink servers. The standalone installer was not installing
the library mljstrm11.dll as part of the SQL Anywhere support component.
This problem does not exist in the edition of SQL Anywhere Monitor included
with SQL Anywhere. This has been fixed.
================(Build #2211 - Engineering Case #568657)================
Signed and unsigned short values were not being translated properly by the
SQL Anywhere Python interface. Attempting to use short values would have
resulted in errors like "struct.error: bad char in struct format"
or "struct.error: unpack requires a string argument of length 1".
This has been fixed.
================(Build #2202 - Engineering Case #567590)================
The SQL Anywhere Monitor was setting redundant HTTP headers which would have
caused the browser-based interface to function incorrectly when using SSL
on Internet Explorer. This has been fixed by removing the redundant HTTP
headers.
================(Build #2195 - Engineering Case #566703)================
The PHP external environment was passing strings as LONG VARCHAR, which was
causing character set conversion between the server and the PHP process.
This would have corrupted binary data. This has been corrected so that all
strings are now passed as LONG BINARY, which means that no character set
conversion will be done.
================(Build #2194 - Engineering Case #566711)================
The PHP external environment process would have crashed if the system procedures
sa_http_php_* were called from the Interactive SQL utility, or anywhere outside
of an HTTP server request. This has been fixed
================(Build #2194 - Engineering Case #566688)================
Prebuilt binary libraries for PHP 5.2.9 have now been added.
================(Build #2194 - Engineering Case #561831)================
The PHP external environment, when used in the HTTP context, was not sending
the appropriate HTTP status code back to the client. This has been fixed.
================(Build #2187 - Engineering Case #565891)================
When run on Unix systems, the server would have crashed or hang if a client
application attempted to connect and disconnect in a tight loop. Another
symptom may have been that the client would have received the following error:
-832 Connection Error: Found server but communication error occurred.
For this to have occurred, the connection must have been via shared memory,
the application must have previously connected and disconnected successfully
so as to unload the client libraries (ODBC, DBLIB, or DBCAPI), and the time
between the last disconnect and the new connect was within 10ms. This has
been fixed.
================(Build #2182 - Engineering Case #561825)================
The PHP external environment did not expose all of the $_SERVER fields during
an HTTP request, as specified by the CGI/1.1 specification. This has been
fixed.
================(Build #2173 - Engineering Case #563832)================
The Windows makefiles for the PerformanceFetch, PerformanceInsert, and PerformanceTransaction
SQL Anywhere samples could not have been used to build the sample applications,
as they referenced directories that no longer existed in the version 11.0
installation. This has now been fixed.
================(Build #2151 - Engineering Case #560351)================
Columns of type UNIQUEIDENTIFIER were being fetched in binary format in the
SQL Anywhere C API (php, Perl, Python and Ruby), where as they should have
been returned as strings. This has been fixed.
================(Build #2150 - Engineering Case #559864)================
Connecting, disconnecting, and reconnecting using the same connection handle
would have caused error -298 "Attempted two active database requests"
in dbcapi.
For example:
conn = sqlany_new_connection();
sqlany_connect( conn, <connection_string> );
sqlany_disconnect( conn );
sqlany_connect( conn, <connection_string> );
The last sqlany_connect() call would have returned error -298. This has
been fixed. The workaround is to call sqlany_free_connect() and allocate
and new handle.
================(Build #2148 - Engineering Case #558984)================
The JDBC sample applications incorrectly contained references to the SQL
Anywhere 10 ODBC driver. This has been fixed.
Comments were also added that explain the DriverManager.registerDriver and
DriverManager.getConnection code.
================(Build #2139 - Engineering Case #556340)================
Applications fetching data from an NCHAR column that was greater than 32767
bytes, using the Perl, Python, PHP, or Ruby drivers, may have crashed. This
has been fixed.
================(Build #2135 - Engineering Case #555024)================
When the server was run on Unix systems, the PHP external environment would
have reported all errors, warnings, etc, even when PHP was explicitly configured
not to do so. This has been fixed.
================(Build #2129 - Engineering Case #553491)================
The Apache redirector module would have crashed when used with the Sun built
Apache web server that currently ships with the Solaris operating system.
This has been fixed.
================(Build #2114 - Engineering Case #550418)================
The Python module would have sent all "string" host variable data
as varchar data. This would have resulted in an unwanted character set conversion
when the desired type was binary. This has been fixed.
As well, Python scripts can now pass an instance of sqlanydb.Binary in the
variable data list. This will cause the value to be sent as binary data.
================(Build #2537 - Engineering Case #651707)================
The iAnywhere.mib file that shipped with the SNMP agent was not SMI compliant.
This has been fixed.
Note that this change did not affect the software itself.
================(Build #2468 - Engineering Case #635419)================
Attempting to retrieve the uid_has_hyphens option setting through the SNMP
interface would always have returned NULL. This has been fixed.
================(Build #2627 - Engineering Case #671906)================
When processing an UPDATE statement, the server could have constructed erroneous
values for the OLD table that would have been created for AFTER ROW or AFTER
STATEMENT triggers. This could have lead to incorrect results if the AFTER
trigger referenced these values, or could have resulted in the statement
failing with an SQL error. The problem would have occurred if and only if
the following conditions hold:
1) The UPDATE statement modifies a table that had a primary key, UNIQUE
constraint, or unique index.
2) The UPDATE statement modified a column included in the primary key, UNIQUE
constraint, or unique index, such that the new value matched a value already
existing in the index.
3) The modified table had an AFTER ROW or AFTER STATEMENT trigger
This problem has been corrected.
================(Build #2626 - Engineering Case #674782)================
If a server involved in a high availability mirroring system had active TLS
connections, the server may have hung indefinitely due to a thread deadlock.
This has been fixed.
================(Build #2626 - Engineering Case #674753)================
In rare, timing depending cases, a primary, mirror or copy node server could
have hung while shutting down. This has been fixed.
================(Build #2626 - Engineering Case #674704)================
If a directory access server was queried, and one of the files was owned
by a user that did not exist on the system where the server was running,
then the server would have crashed. This problem has now been fixed.
================(Build #2626 - Engineering Case #674537)================
Simple INSERT statements referencing a table with an article defined with
a non-empty WHERE and/or SUBSCRIBE BY clause could have occasionally failed
with a "Column not found" error for the column referenced in either
WHERE or SUBSCRIBE BY clause. Re-execution of the same INSERT would, in most
cases, have succeeded with no error. This has been fixed.
================(Build #2625 - Engineering Case #674550)================
Calling the system function WRITE_CLIENT_FILE could have incorrectly resulted
in the error "Client library reported a permissions error accessing
object ('<FILENAME>') during transfer" if there were multiple
READ_CLIENT_FILE or WRITE_CLIENT_FILE calls in a batch, procedure, or function
referring to the same client file name. This could have happened if the client
executed a batch or procedure, which in turn called other functions or procedures
which ended up doing multiple READ_CLIENT_FILE or WRITE_CLIENT_FILE calls
during the execution of the batch or procedure that was executed by the client.
This has been fixed by explicitly closing the file at the end of the function
call. The file was previously closed at the end of the request.
================(Build #2624 - Engineering Case #674582)================
The server would have crashed when inserting several values lower then MIN_DBL
(about 1e-306, which is the smallest double which can be stored in normalised
format) which still can be stored using denormalized double values. This
was fixes by forcing all of the denormal double values to be rounded down
to zero.
================(Build #2624 - Engineering Case #674320)================
After a MANUAL or AUTO REFRESH text index was renamed, it may not have been
found by subsequent statements. This has been fixed.
Note that restarting the database server eliminates the problem
================(Build #2619 - Engineering Case #673844)================
The server may have crashed while attempting to log a deadlock error between
connections. For this to have happened, the Log_deadlocks option needed to
have been set to 'on', and at least one of the connections that was participating
in the deadlock needed to be executing a query that had a parallel plan.
There are two possible workarounds:
1) Turn off intra-query parallelism by setting the Max_query_tasks option
to 1, or
2) Set the Log_deadlocks option to 'off'
This problem has been fixed.
================(Build #2619 - Engineering Case #673212)================
1) If one TCP/IP address for one partner server in the partner/mirror/primary
server connection string in the MIRROR SERVER or -xp configuration was correct,
but the TCP/IP address for the other mirror partner server was incorrect,
it was possible for the primary server to have skipped performing checkpoints
indefinitely. This could only occur with the incorrect TCP/IP address configuration
and if the mirror servers contained the fix for Engineering issue 660851.
This has been fixed so that the primary server checkpoints normally.
2) If a High Availability or read-only scale-out server failed to connect
to another server, there may not have been any indication of the failed connect.
This has been fixed by logging a message to the console for each failed connection.
3) A High Availability or read-only scale-out server may have displayed
the message "... recovery n% complete" where n was a number less
than zero or much greater than 100. This has been fixed.
================(Build #2618 - Engineering Case #675686)================
The server may have failed assertion 101412 - "Page number on pages
does not match page requested", if the database/connection option 'chained'
was set to 'off'. This has been fixed.
================(Build #2618 - Engineering Case #673173)================
The fix for Engineering case 661622 missed the situation where a subselect
that referenced two tables from the main query block, and was equated to
a constant, could also have caused the server to fail an assertion or crash
.
For example:
Select *
from T1, T2
where 10 = (select e1 from R where p(R,T1, T2) ) and ..
This has now been fixed.
================(Build #2618 - Engineering Case #672858)================
The server could have crashed if a table was being dropped at the same time
as a proxy table was being created. This has been fixed.
================(Build #2618 - Engineering Case #647802)================
The server may have failed assertion 106104 "field unexpected during
compilation" for queries containing correlated subselects in the WHERE
clause. The WHERE subselect predicate must have been of the form "T.X
= (subselect referencing R.Y)" where R.Y was an outer reference. This
has now been fixed.
================(Build #2617 - Engineering Case #667001)================
If a stored procedure or a user defined function with the hidden definition
appeared on the stack when an error occurred, subsequent call to the TRACEBACK
function could have returned the statements from the hidden definition. This
has been fixed so that the output of the TRACEBACK function now contains
the string '<hidden>' instead of the statements from the hidden procedures
or user defined functions.
================(Build #2614 - Engineering Case #672077)================
Executing a query that joined two or more External Environment result sets
could have caused the server to crash if the join resulted in a very large
result set. This problem has now been fixed.
================(Build #2614 - Engineering Case #672076)================
When inserting a string literal value into a time or timestamp column of
a proxy table, if the string literal contained more than 3 digits of precision
within the fractional seconds portion of the time/timestamp value, then the
fractional seconds would have been truncated to 3 digits of precision. This
problem has now been fixed.
Note that this fix only applies to ODBC based Remote Data Access servers.
The fractional seconds precision will still be truncated to 3 digits of precision
for JDBC based Remote Data Access servers.
================(Build #2614 - Engineering Case #671911)================
The system function OPENSTRING allows a text file to be parsed and interpreted
as a relational table. The schema for OPENSTRING can be explicitly specified
or can be provided by means of an existing database table. If a remote (IQ
or other proxy) table was used to specify the OPENSTRING schema then the
server can behave erratically, including crashing. This problem has now been
resolved.
================(Build #2613 - Engineering Case #671711)================
The changes for Engineering case 624047 could have caused a server running
high availability mirroring, or a read-only scale-out copy node, to fail
assertion 200131. The failure was timing dependent, and required accessing
an empty table with an index from a read-only connection. This has been fixed.
================(Build #2612 - Engineering Case #659138)================
In exceptionally rare cases, the server may have crashed if two procedure
debuggers had been attached to a database and one of them disconnected while
a new connect request for a user to debug was being executed. This has been
fixed.
================(Build #2612 - Engineering Case #655524)================
A MERGE statement on a table that had a column with DEFAULT AUTOINCREMENT
would have increased the autoincrement value for every matching row independently
of whether the value had already been used for an INSERT or not. This behaviour
has been improved so that the server only generates a new autoincrement value
if the matching branch is an INSERT and the value will be used.
================(Build #2610 - Engineering Case #670990)================
If the number(*) function was used in the VALUES clause of an INSERT statement,
then the server would have returned a non-fatal assertion error 106103. This
has been fixed so that the correct error is now returned.
================(Build #2610 - Engineering Case #670838)================
In rare timing dependent cases, if a High Availability mirror server was
in the process of taking over as the primary, it could have failed. The 201120
assertion failure could have been logged to the console log. This problem
could only have affected servers containing the fix for Engineering issue
663964. This has been fixed.
================(Build #2609 - Engineering Case #670486)================
In exceptionally rare cases, the server could have crashed when executing
a non-parallel query that contains a hash join. The crash would only have
occurred if all of the following conditions were true:
- the probe input of the hash join had already consumed a lot of memory
for hash tables
- a child of the hash join returned an error
- a hash based parent query node of the hash join needed to allocate memory
for the hash table and is restricted by the memory governor, so that it had
to acquire memory from other hash based query nodes.
This problem has been fixed.
================(Build #2609 - Engineering Case #670403)================
When a database was shut down (for example, as part of server shutdown) and
the database was a high availability mirror or a read-only scale-out copy
node, the server could have hung in rare timing dependent cases. If the
server was hung due to this problem, there would have been messages like
the following in the server console:
A write failed with error code: (6), The handle is invalid.
Fatal error: disk full when writing to "???"
This has been fixed.
================(Build #2609 - Engineering Case #669965)================
A database server using web services could have crashed in very rare situations
when an HTTP connection was shutdown. This has been fixed.
================(Build #2609 - Engineering Case #669448)================
When performing a backward index scan (a rare occurrence) while there were
heavy concurrent updates to the index, there was a small chance that the
server could have made a comparison to a random value with unpredictable
results. This has been fixed.
================(Build #2607 - Engineering Case #670202)================
In rare timing dependent cases, a primary, mirror or copy node server could
have crashed or hung.
Also in rare timing dependent cases, partner servers starting for the first
time could have fail to have chosen a primary after the changes for Engineering
case 663964.
These problems have been fixed.
================(Build #2607 - Engineering Case #669633)================
The SQL Anywhere Server provides a system procedure sa_refresh_materialized_views()
that can be used to refresh all currently stale materialized views. Invoking
the procedure with an argument value of 0 would have caused an error to be
reported if at least one of the materialized views failed to be refreshed.
This procedure is invoked by the reload script generated by the Unload utility
when executed with the "-g" command line switch. This problem has
now been resolved.
================(Build #2606 - Engineering Case #669431)================
When attempting to cancel a Remote Data Access request to an ODBC based remote
server, there was a very small chance that the server would have become unresponsive
if all three of the following was true:
- the local server was running on a Windows based system
- the local server had a restricted (or small) number of CPUs or cores
(either due to the limitations of the server machine or VM, or as a result
of using the -gt or -gtc command line option)
- the remote server was not defined to utilize the new "driver=SQL
Anywhere Native" feature
This problem has now been fixed.
================(Build #2604 - Engineering Case #668989)================
In rare timing dependent cases, a transaction which was successfully committed
on a primary server could have been lost. In order for there to have been
a chance of this occurring, all of the following needed to be true:
- the application was connected to a primary server that lost quorum (the
server lost the connection to both the mirror and arbiter servers)
- the application stayed connected to this server (the old primary server)
even though the network connection to other servers dropped
- the application was in the middle of committing a transaction between
the time that the old primary server lost its connection to the mirror and
arbiter server, and when the old primary server restarted as the new mirror
server because it lost quorum
- the old mirror server took over as the new primary (the mirror server
must have been able to connect to the arbiter server for this to occur)
This has been fixed so that the application may now receive the new error
for this situation, "The transaction may not be committed because the
primary server lost quorum."
================(Build #2602 - Engineering Case #663056)================
In exceptional rare situations the server could have crashed or failed assertions
106808, 100913, or 111706 if very long property values are queried. This
has been fixed by truncating property values to the max varchar length of
32000 bytes.
================(Build #2600 - Engineering Case #659608)================
When making an external environment call, if the external environment procedure
made a server side request that ended up leaving a cursor on a temporary
table open, then the server could have crashed when the connection was closed.
This problem has now been fixed.
================(Build #2599 - Engineering Case #667901)================
If an application connected via jConnect and then subsequently attempted
to use the {} JDBC escape sequence when making a stored procedure call, then
there was a chance the server would have returned an incorrect "variable
@p0 not found" error at the time the stored procedure statement or result
set was closed. This problem has now been fixed.
================(Build #2599 - Engineering Case #667900)================
If the Transact-SQL ROWCOUNT option was used to limit the number of rows
returned by a cursor, the cursor may have skipped the first row in the result
set in some cases. This incorrect behaviour only occurred for queries in
which optimization was bypassed, and the plan contained a SortTopN operator,
rather than a RowLimit operator. This incorrect behaviour was introduced
as part of the fix for Engineer case 653706, and has now been fixed.
================(Build #2599 - Engineering Case #667686)================
If an application attempted to cancel or drop a connection that was in the
process of making a connection-scoped external environment call, then there
was a very small chance the server would have crashed. This problem has now
been fixed.
================(Build #2599 - Engineering Case #660691)================
When accessing a directory or file using a Directory Access Server, if the
name of the directory or file contained a multi-byte character where one
of the bytes in the character was 0x5C, then the Directory Access Server
would have failed to find the directory or file. This problem has now been
fixed.
================(Build #2598 - Engineering Case #667314)================
If more than one connection attempted to install or remove Java external
environment objects at the same time, then there was a chance the server
would have crashed or failed assertions. This problem has now been fixed.
================(Build #2596 - Engineering Case #666731)================
Under rare circumstances, the server could have hung when values for WHERE
or SUBSCRIBE
BY clauses were being changed in a table with an article. This has been
fixed. This fix covers additional cases that were not covered by Engineering
case 654952.
================(Build #2595 - Engineering Case #667142)================
In very rare timing dependent cases, the server could have crashed when a
database was stopping. Also in rare cases, it was possible for an automatically
started database to not automatically stop when there where no longer any
connections to it. Both of these problems have now been fixed.
================(Build #2593 - Engineering Case #661440)================
In rare cases, the server may have crashed while performing DDL and DML operations
concurrently. This has been fixed.
================(Build #2592 - Engineering Case #666639)================
The detection of processor geometry (number of physical processors, cores
and threads) was incorrect for certain Intel x86/x64 processors, including
the Intel Xeon E5405. The server would have detected all cores and threads
as belonging to a single physical processor. This problem has been corrected.
================(Build #2592 - Engineering Case #660211)================
In rare circumstances, calling the system procedures sa_locks, sa_describe_shapefile,
st_geometry_dump, sa_list_cursors, or sa_mirror_server_status, could have
caused the server to crash, or could have caused unpredictable behaviour.
The problem was more likely to have occurred when small cache sizes were
used. This problem has been fixed.
================(Build #2589 - Engineering Case #665657)================
The problems described here affect Windows CE 5.x kernels only. Note that
Windows Mobile 6 platforms use the Windows CE 5.x kernel.
With version 11.x, the server was not able to create a cache larger than
32MB. Attempting to do so would have caused the error "Not enough memory".
With version 12.x, the server would have automatically and erroneously restricted
the cache size to a size smaller than 32MB.
The default maximum cache size was erroneously restricted to a value less
than 32MB.
The "percentage" notation for cache sizes (eg, "-c 50p")
erroneously based the percentage on a value that was less than 32MB, rather
than the total system memory as documented.
These problems have been corrected.
================(Build #2589 - Engineering Case #665630)================
Upgrading a database that had been created with the -dba switch (to set the
DBA username and password) could have failed. This has been fixed.
================(Build #2589 - Engineering Case #635353)================
The server could have hung when a connection disconnected, or was dropped.
This was more likely to have occurred if the server was under heavy load.
This has been fixed.
================(Build #2588 - Engineering Case #665799)================
On Windows systems, a minidump might not have been generated under certain
circumstances. This has been fixed.
================(Build #2587 - Engineering Case #665684)================
If an application attempted to establish a Remote Data Access connection
to an ASE server, and that connection request failed over to a different
ASE server, then the Remote Data Access connection request would have failed.
This problem has now been fixed.
================(Build #2587 - Engineering Case #665524)================
An exclusive table lock on a non-transactional global shared temporary table
could have caused the server to crash on subsequent INSERT, UPDATE or DELETE
statements. This has been fixed.
All conditions must have been met (non-transactional, shared global temp
table,
and LOCK TABLE WITH EXCLUSIVE) for the crash to have occurred. If any of
these three can be relaxed, the crash will be avoided.
================(Build #2587 - Engineering Case #665522)================
The attachment specified by the attachname parameter of the system procedure
xp_sendmail() may not have been received properly by the recipient's mail
client. This has been fixed.
================(Build #2587 - Engineering Case #661066)================
If a range of values was supplied for the TCP/IP option ClientPort, connection
attempts may have been slow if the server was not found, or if multiple hosts
were supplied for the Host option. This has been fixed.
================(Build #2586 - Engineering Case #665325)================
When validating a database using the VALIDATE statement or the Validation
utility (dbvalid), the operation could not have been cancelled. This has
been fixed.
================(Build #2586 - Engineering Case #665158)================
For servers that support ECC TLS, support has now been added for RFC 4492
and 256-bit AES ECC cipher suites as well, in addition to the Draft 3 128-bit
AES ECC cipher suite they previously supported.
================(Build #2586 - Engineering Case #661622)================
Execution of a query with a subselect predicate correlated on two different
tables from the main query block may have caused an assertion failure in
the server. This has now been fixed
For example:
Select *
from T1, T2
where T1.X = (select e1 from R where p(R,T1, T2) ) and ..
The predicate "T1.X = (select e1 from R where p(R,T1, T2) )" has
a subselect and references both tables T1 and T2 from the main query block.
================(Build #2584 - Engineering Case #664865)================
In rare timing dependent cases, after a primary server relinquished ownership
and had became the mirror server, it may not have received log page updates
from the new primary. A high availability primary server relinquishes ownership
when the partner is preferred, or due to a ALTER DATABASE SET PARTNER FAILOVER
statement. If this problem occurred, restarting the mirror server would have
caused it to start receiving log updates again. This has been fixed.
================(Build #2584 - Engineering Case #664695)================
In rare situations, the server could have erroneously reported the error
"Not enough memory" at startup. This problem has been corrected.
================(Build #2584 - Engineering Case #661036)================
Activity executing on the utility_db could have caused a crash, memory corruption,
or other unpredictable behaviour, if the cache were to shrink at the same
time. This problem has been fixed.
================(Build #2583 - Engineering Case #664348)================
In very rare timing dependent cases, the server could have crashed or hung
on shutdown if there were active client requests during shutdown. The databases
would have already been stopped before the failure, so there was no chance
of data loss. This has been fixed.
================(Build #2583 - Engineering Case #664292)================
In rare situations, the server could have crashed if a log truncation or
rename (dbbackup -x or -xo or -r) took place while the server was processing
a large number of transactions, especially long-running transactions. This
has been fixed.
No workaround for this problem is known, except to avoid performing log
truncation or renaming when the server is handling large numbers of inserts,
updates or deletes.
================(Build #2583 - Engineering Case #664247)================
If the system procedure sa_get_user_status() was run on a database with an
extremely high number of user definitions, the procedure would have blocked
DDL statements and could not have been cancelled until its result had been
materialized. This has been fixed.
================(Build #2579 - Engineering Case #663459)================
Attempting to autostart a database server on Windows CE when one was already
running was incorrectly giving the error:
"Unable to start specified database: server exit code -11728"
(where the number could vary).
This has been fixed to return the correct error:
"Database server already running"
Note that on Windows CE only one database server can be running at a time,
even if when attempting to start a second server with a different name.
================(Build #2576 - Engineering Case #663283)================
The server may have chosen less that optimal plans for queries with predicates
of the form 'T.X=(unknown expression)' if an index on T(X) existed. The
'(unknown expression)' could have been, for example, a variable whose value
was not used for queries inside the procedures, or could have been a complex
expression (i.e. "R.Y+1"). This has now been fixed.
================(Build #2574 - Engineering Case #662452)================
Attempting to start a connection-scoped external environment, and then canceling
the start request before the external environment completed the startup process,
could have caused the server to crash. This problem has now been fixed.
================(Build #2572 - Engineering Case #661633)================
Execution of an "UPDATE ... PUBLICATION ... WHERE .." statement
with a complex WHERE clause may have caused the server to crash. This has
been fixed.
================(Build #2572 - Engineering Case #660851)================
When a primary server lost its connections to both the mirror and arbiter
servers as a checkpoint was performed, the database on the primary may not
have been recoverable. Typically, it would fail assertion 100904. This
has been fixed.
Similarly, in cases where a primary server lost its connections to both
the mirror and arbiter servers as a checkpoint was performed, the next time
the primary and mirror servers were connected and attempt to synchronize,
the mirror server may have in rare situations reported "Database "<name>"
mirroring: database is not compatible with primary; files must be replaced"
and then stop with the message "Database server shutdown due to incompatible
files for database mirroring". This has been fixed to reduce the possibility
of this occurring. It is possible for this to still occur, so then the database
running on the current primary must be manually copied or backed up to the
mirror server so that the server can successfully synchronize again.
The primary server could have hung, again in rare situations, if only one
of the two connections between it and the mirror server was dropped, for
example due to a liveness timeout. This has been fixed.
When the mirror server was becoming the primary server there was a small
possibility it could have hung after reporting it was starting a checkpoint
and then reporting it was recovering. This has been fixed.
================(Build #2571 - Engineering Case #661453)================
If the distance parameter of the proximity search condition contained letters,
the server could have silently failed, and returned some result, instead
of reporting an error. This has been fixed.
For example, the following query would not report an error and would behave
as if the
full text query was 'apple NEAR[2] oranges':
SELECT *
FROM t CONTAINS( 'apple NEAR[ 2b ] oranges' )
Note that the following query was correctly reporting an error:
SELECT *
FROM t CONTAINS( 'apple NEAR[ b ] oranges' )
================(Build #2569 - Engineering Case #662466)================
Some potential security issues have been fixed.
================(Build #2569 - Engineering Case #660834)================
The server could have hung for thirty seconds or more when it was establishing
a mirror or diagnostics connection to another server. This has been fixed.
================(Build #2569 - Engineering Case #660629)================
When connected to an ASE 15.5 server and attempting to make a remote request
to SQL Anywhere, there was a chance the request would have failed with an
"unkown token 35" error. This problem has now been fixed.
Note that this problem only affected remote requests from ASE to SQL Anywhere.
The problem did not affect making remote requests from SQL Anywhere to ASE
via Remote Data Access.
================(Build #2569 - Engineering Case #660446)================
Performing a backup with a TRANSACTION LOG RENAME would have caused read-only
connections to the database on the mirror server to be dropped. This has
been fixed.
================(Build #2569 - Engineering Case #659115)================
The server may have crashed if a query block contained an alias definition
and the expression of the alias used columns that could be folded as a constant,
(in the example below, alias v011 can be folded as a constant if column T2.a2
was created as NOT NULL), and the alias name was used in a subselect of the
query block and in the GROUP BY clause of the query block.
For example:
select if T2.a2 is null then 99999 else 11111 endif as v011,
(select count(*) from T1 where T1.a1 = v011) as c
from T2,T3
where T2.a2 = T3.a3
group by v011
This has been fixed.
================(Build #2569 - Engineering Case #658330)================
Execution of an INSERT ON EXISTING UPDATE statement, with CASCADE as the
foreign key update option, would have resulted in a foreign key constraint
violation error when updating values which were logically the same, but had
different physical representation. For example, in case insensitive database
changing 'EMPLOYEE' to 'employee'. This has been fixed.
================(Build #2568 - Engineering Case #660248)================
If an application connected via jConnect or Open Client and made an external
environment call that returned a result set, then the server may have crashed.
This problem has now been fixed.
================(Build #2567 - Engineering Case #660235)================
On Windows Vista and later operating systems, whenever a new server executable
had to be launched in order to autostart a database, launching the executable
may have failed when a relative path to the server executable was specified.
For example, dbspawn mybin\dbsrv12.exe -n myserver my.db, or using "...;start=mybin\dbsrv12.exe..."
in a connection string, could have fail to launch the server executable.
This problem has been fixed.
================(Build #2567 - Engineering Case #660194)================
Execution of a query on a Directory Access proxy table with a WHERE clause
that contained a predicate of the form "file_name = variable",
may have sometimes run very slowly while running very quickly most other
times. This problem has now been fixed such that the query performance is
now consistently fast from one run to the next.
================(Build #2567 - Engineering Case #660057)================
If a foreign key was created with both MATCH and CHECK ON COMMIT clauses,
and the database subsequently required recovery, recovery would have failed
when replaying the statement from the transaction log. This has been fixed.
================(Build #2567 - Engineering Case #660024)================
In version 10, web service requests sent to a server acting as mirror would
have been redirected to the same port on the primary server. Starting with
version 11, this redirection no longer happens. In version 12, the documentation
was updated to reflect the change in behavior.
No change in behavior from earlier builds of version 11 should be seen with
this software change.
================(Build #2567 - Engineering Case #652949)================
The trigger operation condition 'UPDATE( {column-name} )' did not return
TRUE if the column value had been changed by a previously running BEFORE
UPDATE row-level trigger only. This has been fixed.
================(Build #2566 - Engineering Case #659639)================
When making a Java external environment call, if the stored procedure had
an argument of type char (note that this is a single char value rather than
a java.lang.String), and a NULL value was passed in for the char argument,
then the server would have failed the request with a Java NullPointerException.
It should be noted that the Java VM would have continued to run in this situation
and the connection was still able to make subsequent Java external environment
calls. This problem has now been fixed such that passing a NULL char value
to a Java external environment call will result in a char with zero value
being passed down to the Java method. Again, it should be noted that this
problem does not affect passing NULL string values to java stored procedures.
================(Build #2566 - Engineering Case #659631)================
If an application enlisted a connection within a DTC transaction and then
subsequently attempted to perform a DTC commit on the transaction after explicitly
unenlisting it first, then the application would have hung until the server
was shut down. This problem has now been fixed and the commit request will
now immediately fail as expected.
================(Build #2566 - Engineering Case #613299)================
Queries involving indexes could return incorrect results, and using tools
such as the Validate Database Wizard in Sybase Central, or the Validation
utility, could have reported index corruption when there was in fact none.
For this to have occurred, the index must not have been unique and there
must be many consecutive rows with the same indexed value. This has been
fixed.
================(Build #2564 - Engineering Case #658985)================
Unexpected deadlocks could have occurred when using the UPDLOCK hint at isolation
level 3. For example, if two transactions issued the statements
SELECT t.c FROM t WITH (UPDLOCK) WHERE t.pk = 1
UPDATE t SET c = 2 WHERE t.pk = 1
concurrently at isolation level 3, a deadlock would have occurred if both
connections managed to issue the SELECT before either issued the UPDATE.
This has been fixed.
================(Build #2564 - Engineering Case #658849)================
If an application on a Unix system attempted to make a TCP/IP connection
to a server that was not running, the connection attempt may have failed
with error code -832 "Found server but communication error occurred".
This has been fixed, the correct error code should be
-100 "Database server not found".
================(Build #2563 - Engineering Case #658114)================
The server would have crashed if a SELECT statement useed the FOR XML EXPLICIT
clause, and a null value was used for the CDATA directive. This has been
fixed
================(Build #2563 - Engineering Case #657823)================
The fix for Engineering case 620136 did not handle the situation where there
was no declared Primary Key in the primary table but there were table, or
column, (not nullable) Unique Constraints that permit the addition of foreign
keys. This problem has been corrected.
================(Build #2563 - Engineering Case #656998)================
Remote queries with many aliases in grouped derived tables may have taken
a long time to execute. This has been fixed.
================(Build #2563 - Engineering Case #647077)================
When run on Mac OS X systems, the server would have exited with the error
"Failed to
become daemon" if both the -um and -ud command line options were specified.
This was due
to a limitation in the OS X GUI infrastructure. This has been fixed. The
-um flag is now ignored if -ud is specified.
A workaround is to use dbspawn instead of -ud.
================(Build #2562 - Engineering Case #657621)================
If a server (S2) acting as mirror saw a dropped connection to the primary
server (S1) after a temporary network outage, it could have attempted to
become primary while S1 was still running. S2 would then have failed during
startup because S1 still owned the alternate server name for the database.
This error would also have caused S2 to shut down. If S1 needed to restart,
it would have been unable to take ownership of the database because S2 was
unavailable and the arbiter's state had been updated to indicate that S2
was the owner.
Also, when a server acting as primary (S1) accepted an inbound connection
from the mirror (S2), S1 attempted to make an asynchronous outbound connection
to S2 if one did not already exist. If this connection attempt failed, S2
would have failed to receive updates from S1.
These problems have now been fixed.
================(Build #2561 - Engineering Case #658302)================
If many contiguous index entries were removed from an index with no intervening
inserts, concurrent snapshot transactions could have seen incorrect results,
and in rare circumstances, foreign rows could have been added without matching
primary rows. This has been fixed.
================(Build #2561 - Engineering Case #658121)================
On some Windows machines, attempting to make a TCP connection to a Personal
Server on the same machine may have failed. This has been fixed.
================(Build #2561 - Engineering Case #657987)================
The server could have crashed, or failed assertion 200114, when processing
a LIKE predicate. This has been fixed.
================(Build #2560 - Engineering Case #634900)================
The server may have become deadlocked while acquiring shared latches. This
has now been corrected.
================(Build #2559 - Engineering Case #655956)================
If a server was handling a large number of requests, and a large number of
those requests made external environment calls that resulted in server side
calls coming back into the server and those server side calls were similar
in nature, then there was a chance that the server would have crashed when
one or more of the connections making external environment calls closed.
This problem has now been fixed.
================(Build #2558 - Engineering Case #657586)================
If a call was made to the Java external environment, and the stored procedure
had an argument of type tinyint and a NULL value was passed in for the tinyint
argument, then the server would have failed the request with a NullPointerException.
It should be noted that the Java VM would continue to run in this situation
and the connection was still able to make subsequent Java external environment
calls. This problem has now been fixed such that passing a NULL tinyint value
to a Java external environment call will result in a byte with zero value
being passed down to the Java method.
================(Build #2558 - Engineering Case #657520)================
In very rare cases, the server asserts with assertion error 102300 "File
associated with given page id is invalid or not open" if request level
debugging is turned on and includes plan logging and there are schema changes
around. This has been fixed. To work around the problem plan caching can
be turned off (option Max_plans_cached = 0) or plan logging can be turned
off (switch -zr without "plan" and "all").
================(Build #2558 - Engineering Case #654801)================
The SQL Anywhere Optimizer may have incorrectly pruned, without costing,
optimal plans during query optimization. This has been fixed. This incorrect
pruning would most probably have affected the final execution plans for
complex, but inexpensive (i.e., the optimal plan has a small runtime) queries.
================(Build #2556 - Engineering Case #656264)================
When connected to a database that had the same character set as the OS, and
a query like the following was executed:
SELECT ... FROM dirtab WHERE file_name = '...'
where dirtab was a directory access table and the file_name string literal
contained non-ASCII characters, there was a chance the server would have
crashed. This problem has now been fixed.
================(Build #2555 - Engineering Case #656847)================
If a derived table was joined with the rest of the query using a Join Nested
Loops operator, the performance of the query may have suffered when the derived
table had to be computed many times due to many rows generated by the left
hand side of the Join Nested Loops. The optimizer was choosing such a plan
if the estimated number of rows of the left hand side was very small. If
this estimation was wrong (e.g., the optimizer estimates one row for the
left hand side but in reality the left hand side produces 1,000 rows), the
derived table was computed many, many times during execution. This has been
fixed so that the optimizer considers only Join Hash or Join Sort Merge operators
for the derived tables if it is correct to do so.
================(Build #2554 - Engineering Case #656650)================
The system procedure sa_db_list() did not validate its database id parameter
if the value was a positive integer. This would have resulted in a single
row result set containing the value provided. Now, if the value is not a
valid database id, the procedure will return an empty result set.
================(Build #2554 - Engineering Case #655981)================
Values for the ApproximateCPUTime property is never expected to decrease
between calls, as it represents an estimate of accumulated CPU time for a
connection. However, for connections that had accumulated approximately
1000 seconds of CPU time, the counter could have periodically receded by
approximately 400 seconds.
================(Build #2552 - Engineering Case #656272)================
The INSERT ON EXISTING SKIP statement did not report the correct number of
inserted and
updated rows using @@rowcount and sqlcount. This has now been corrected.
================(Build #2552 - Engineering Case #655749)================
Execution of an INSERT ... ON EXISTING SKIP statement did not report the
correct number of inserted and updated rows using @@rowcount and sqlcount.
This has been fixed
================(Build #2551 - Engineering Case #655972)================
The fix for Engineering case 636018 missed a case, which has now been corrected.
Description of case 636018:
Queries involving indexes containing long values could have returned incorrect
results. Index corruption was possible, but not likely..
================(Build #2550 - Engineering Case #654938)================
In rare cases, a corrupt TCP packet could have caused the server to crash.
The server now validates the packet header before do anything with the packet.
If it is corrupt, the packet is dropped.
================(Build #2548 - Engineering Case #654952)================
Under rare circumstances, the server could have hang when subscribe-by values
were being changed for an article, while large numbers of connections were
updating tables in the database. This has now been fixed. A workaround is
to avoid changing subscribe-by values simultaneously with connections performing
INSERT, UPDATE or DELETE operations.
================(Build #2546 - Engineering Case #654790)================
In very rare cases, the server may have crashed with a floating point exception
when slightly loaded. This has been fixed.
================(Build #2544 - Engineering Case #654284)================
The server could have crashed if the STOP SERVER or STOP ENGINE statement
was called from an event or HTTP connection. This has been fixed.
Note that the 'STOP SERVER' syntax is new to version 12 (older servers support
'STOP ENGINE').
================(Build #2544 - Engineering Case #654259)================
The changes for Engineering case 650489 may have caused execution remote
procedure calls to an ASE remote server to fail with a strange "unchained
transaction mode" error. This problem has now been fixed.
================(Build #2544 - Engineering Case #620095)================
Several stability problems existed with parallel queries when using low-memory
strategies, which could have lead to server hangs or crashes. These have
been fixed. A workaround for these problems is to disable parallelism by
setting the option MAX_QUERY_TASKS=1 for all affected queries.
================(Build #2543 - Engineering Case #653591)================
Attempting to attach tracing to an older version database file could have
caused the server to crash. This has been fixed so that attempting to attach
tracing to an older version file now returns the error "ATTACH TRACING
could not connect to the tracing database" (-1097).
================(Build #2543 - Engineering Case #653590)================
Diagnostic tracing, or application profiling to LOCAL DATABASE could not
be used when the server was started with the command line option -sb 0 (disable
broadcast listener). This has been corrected. A workaround is to manually
supply a connection string (ATTACH TRACING TO <connstr>) with the DoBroadcast=NO
option, rather than using the LOCAL DATABASE clause.
================(Build #2543 - Engineering Case #556778)================
The return values of the built-in functions user_id() and suser_id() may
have incorrectly been described as not nullable even if the function argument
was not nullable. This may have lead to the assertion error 106901 "Expression
value unexpectedly NULL in write". This has been fixed so that the functions'
results are always described as nullable.
================(Build #2542 - Engineering Case #653588)================
If tracing was suddenly detached (because, for example, the server receiving
the tracing data was shut down) at the same time as a deadlock occurred,
a deadlock victim may have failed to write a ROLLBACK to the transaction
log. This may have lead to an incorrect partial commit of a deadlocked transaction.
This has been fixed. This problem is expected to be very rare.
================(Build #2542 - Engineering Case #653245)================
The value for the column "columns" for the system view SYS.SYSFOREIGNKEYS
is generated using a LIST() function, but the function did not include an
ORDER BY and so the result returned could have varied. This has been fixed
by adding an ORDER BY clause.
Note, the system view must be recreated by upgrading or rebuilding the database
for the new view definition to be used.
================(Build #2542 - Engineering Case #652911)================
If an INSTALL JAVA UPDATE statement was executed to update an existing java
class, the server would have incorrectly added a new system object id rather
than reuse the already assigned object id. This problem has now been fixed.
================(Build #2541 - Engineering Case #653706)================
The 'TOP limit START AT startat' and 'LIMIT limit OFFSET offset' constructs
now support 1 - simple arithmetic expressions for 'limit', 'offset', 'startat'
arguments;
2 - TOP supports the 'ALL' limit indicating that all rows are to be returned
after the specified 'startat';
3 - the maximum value for (limit + offset) is now 9223372036854775807
= 2^64-1
The new grammar is as follows:
TOP range_expression range_offset
TOP T_ALL range_offset
LIMIT range_expression [OFFSET range_expression]
range_expression:
integer_or_var | '(' simple_expression ')'
simple_expression:
integer_or_var | simple_expression '+' simple_expression
| simple_expression '-' simple_expression
| simple_expression '*' simple_expression
| '(' simple_expression ')'
range_offset: /* empty */
| T_START T_AT range_expression
================(Build #2541 - Engineering Case #653052)================
Using the system procedure xp_sendmail with an attachment larger than about
55 kB may have resulted in the attachment being corrupted. This has been
fixed.
================(Build #2541 - Engineering Case #648799)================
In some cases, the server could have returned an error ("Parameter error")
for a statement using OPENSTRING with a VALUE specifying a field reference
or other complex expression.
For example, the following sequence could generate this error:
declare local temporary table T_strs( str long varchar );
insert into T_strs values ('1,a1\n2,a2'), ('3,b1\n4,b2');
select *
from T_strs T cross apply openstring( value T.str ) with( a char(10) )
as O
This has been fixed. Statements such as the above are now processed correctly
without an error.
================(Build #2540 - Engineering Case #652791)================
If a statement for a directory access table failed with the error SQLSTATE_OMNI_REMOTE_ERROR,
and this statement was the last statement of the transaction then all subsequent
remote server statements of this connection would have failed with the same
error. This has been fixed.
================(Build #2539 - Engineering Case #652543)================
The server may have crashed during inserts into a view, if the view column
was not a base table column. This has been fixed. Now the correct error SQLSTATE_NON_UPDATEABLE_VIEW
is returned.
================(Build #2538 - Engineering Case #652411)================
If an error occurred accessing the tape drive when beginning a tape backup,
the BACKUP statement may have hung. This has been fixed.
================(Build #2538 - Engineering Case #652253)================
In some rare cases, when run on HP, AIX, and Solaris systems the server may
have crashed on shutdown. This has been fixed.
================(Build #2538 - Engineering Case #652221)================
In some cases, calling a web services stored procedure may have crashed the
server. This has been fixed.
================(Build #2538 - Engineering Case #651694)================
If the connections between servers in a mirroring system used encryption,
the primary server could have hung when performing an operation which required
exclusive access to the database (e.g. a checkpoint) if other update activity
was also occurring. This has been fixed.
================(Build #2537 - Engineering Case #652107)================
If a foreign key had both ON UPDATE and ON DELETE actions, renaming a column
referenced by the foreign key could have caused one of the system triggers
to be deleted and the other to be left unchanged. A trigger for an ON UPDATE
action could have been converted to an ON DELETE action. This has been fixed.
================(Build #2537 - Engineering Case #651846)================
On Windows systems, the performance monitor might not have displayed counter
values provided by the server. Typically this would have happened when a
shared memory client that was attached to the server terminated abnormally.
Counter values should not display for subsequent servers until all processes
holding handles to the dead server (e.g. shared memory clients) are terminated.
This has been fixed.
================(Build #2536 - Engineering Case #651729)================
In some rare cases, the server may have hung if diagnostic tracing had been
enabled. This has been fixed.
================(Build #2536 - Engineering Case #651658)================
On Windows systems, SQL Anywhere provides a version 1 (registry) performance
provider. Windows should generate WMI classes automatically after the counter
dll is registered, but these classes were generated only after instances
of these objects (i.e. server, database and connection) existed in a process
running in session 0 (i.e. as a service in Vista and up). This has been
fixed.
================(Build #2535 - Engineering Case #651169)================
If a database containing a table with a uniqueidentifier column was unloaded
using the Unload utility (dbunload) with one of the external unload options
(-xi or -xx), and the resulting reload.sql script was executed using the
Interactive SQL utility, a conversion error would have been reported. This
has been fixed. A workaround is to avoid using -xx or -xi when rebuilding
the database.
================(Build #2535 - Engineering Case #650740)================
Execution of a DROP DATABASE statement would have failed if the automatically
generated database alias name was an invalid identifier. This has been fixed.
================(Build #2534 - Engineering Case #651029)================
On Linux builds where the kernel was compiled to support something other
than 1024 processors, the database server could have failed to detect the
correct processor geometry and could have crashed. This problem has been
fixed. Note that recent Linux kernels have been built with support for up
to 4096 processors.
================(Build #2534 - Engineering Case #650489)================
If an application made a remote procedure call that made changes to a remote
database and then subsequently called ROLLBACK, the changes would not have
been rolled back on the remote database that the remote procedure call affected,
but would have been rolled back locally and on the other remote databases
that the local connection modified. This problem has now been fixed.
================(Build #2533 - Engineering Case #650829)================
The Validate utility, or the VALIDATE utility, could have reported spurious
orphaned blobs if there were indexes containing long values. This has been
fixed.
================(Build #2532 - Engineering Case #647154)================
The denial-of-service attack addressed by the changes for Engineering case
610115 could still have occurred if idle timeout had been turned off on the
server using the command line option -ti 0, or the system procedure sa_server_option('IdleTimeout',0).
If the idle_timeout value was not 0, the server was not susceptible. This
has now been corrected.
================(Build #2531 - Engineering Case #650352)================
Procedure profiling showed statements that executed in under 1 millisecond
as using zero time, even when those statements were executed many times.
This has been fixed.
================(Build #2531 - Engineering Case #650337)================
Queries with an outer join having the same base table as the preserved and
null-supplying sides could have returned incorrect result sets. Conditions
where this could happen:
1. the outer join is of the form : T as T1 LEFT OUTER JOIN T as T2 ON(p)
2. the ON predicate p has only equijoins, and at least two equijoins
3. p is of the form : T1.c1 = T2.c1 and T1.c3 = T2.c2
4. there exists an unique index on T < c1,c2>
This has been fixed.
================(Build #2531 - Engineering Case #649978)================
Under rare circumstances, some statements involving proxy tables could have
missed expression checking. This has been corrected.
================(Build #2530 - Engineering Case #649928)================
Sending large attachment files via SMTP using the system Procedure xp_sendmail()
may have crashed the server. This problem was introduced by the changes made
for Engineering case 643590, and have now been fixed.
================(Build #2530 - Engineering Case #649868)================
A brief network outage in a mirroring environment could have resulted in
one of the servers reporting "Alternate server name in use"; or
the former mirror server restarting, but not becoming the primary server.
This has been fixed.
================(Build #2529 - Engineering Case #649797)================
An index containing long values could have become corrupted if the table
was subsequently altered to add columns, remove columns that did not appear
in the index, or change the nullability of a column not appearing in the
index. Also, for this to have happened, entries must have been deleted from
the index. This has been fixed.
================(Build #2528 - Engineering Case #649475)================
If a JDBC application connected via jConnect called the method DatabaseMetaData.getSchemas(),
then the server would have failed the request with the error "the 'FileVersion'
property is no longer supported". This problem has now been fixed and
the proper list of userids is now returned to the application.
================(Build #2527 - Engineering Case #649795)================
Queries over indexes could have returned incorrect results if long index
entries (greater than ~240 bytes) appeared in the index, with index corruption
a possibility. This has been fixed.
================(Build #2527 - Engineering Case #648786)================
If the primary server in a mirroring system lost quorum, just as an update
caused log pages to be sent to the mirror, the primary server could have
hung. This has been fixed.
================(Build #2526 - Engineering Case #648518)================
In very rare cases, the server may have crashed if the cache was low on memory
and a SELECT statement contained a very large IN list predicate. This has
been fixed. The server will now return the error SQLSTATE_SYNTACTIC_LIMIT.
================(Build #2526 - Engineering Case #648179)================
The server could have entered a state where it would consume 100% of a single
CPU (ie. one 'core') and never leave that state. The problem was caused by
a race condition when more than one thread simultaneously attempted to reference
a foreign key index for the very first time; however, the effects of the
race condition may not be observed until the server attempts to shut down.
This problem has been fixed.
================(Build #2526 - Engineering Case #648158)================
Attempting to use an index in a non-system dbspace with a database that was
upgraded from 10.x, would have caused an assertion. This has been fixed.
================(Build #2525 - Engineering Case #648790)================
After applying the fix for Engineering case 635815, if an application executed
a statement of the form:
INSTALL JAVA [NEW | UPDATE] JAR 'jar-name' FROM expression
then there was a chance the server would have crashed. This problem has
now been fixed.
================(Build #2525 - Engineering Case #648493)================
If Perseat licensing was used, the error "Database server connection
limit exceeded" may have been reported when it should not have. In order
for this have occurred, in addition to Perseat licensing, the -gm server
option, or http connections to disabled databases, must have also been used.
When this problem occurred, the first time the error was reported was correct
behaviour, but after disconnecting connections, the error may have continued
when it should not have. This has now been fixed.
================(Build #2525 - Engineering Case #647682)================
Key constraint checking and validation errors were possible when indexing
long index values if the relative position of the corresponding index columns
(foreign and primary) within their respective tables were not identical.
This has been fixed.
================(Build #2525 - Engineering Case #646858)================
Under very rare circumstances, the server could crash during database cleaner
execution. This has been fixed.
================(Build #2524 - Engineering Case #640821)================
It was possible to get the following validation errors:
Page x of database file "<database file name>" references
a table (y) that doesn't exist
or
Orphaned page (x) found in database file "<database file name>".
The database server could have left some pages in a state where they cannot
be reused. The database would have continued to function normally in this
state but it is possible to regain the lost pages by rebuilding the database
file. This most likely would have occurred in a non-system dbspace, and has
now been fixed.
================(Build #2522 - Engineering Case #647663)================
A server running as the primary in a mirroring system could have hung when
the mirror server was started. This was more likely to occur after the fix
for Engineering case 637057 was applied. This has been fixed.
================(Build #2522 - Engineering Case #646703)================
In rare circumstances, reading a substring of a value from a compressed column
(not starting at the first byte) could have caused assertion failure 201501
- "Page ... for requested record not a table page". Note that the
Interactive SQL utility (dbisql) fetches long values in pieces, so selecting
the value using dbisql (without using substrings) may cause this problem.
This only happens on compressed columns with blob indexes. This has been
fixed.
================(Build #2521 - Engineering Case #647225)================
Attempts to edit table data in the "Results" panel would have failed
with the error "Savepoint ... could not be found.", if the Transact-SQL
transaction mode was Unchained. This has been fixed.
Note that the default transaction mode is Chained.
================(Build #2521 - Engineering Case #645801)================
In an environment with each server in a mirroring system having two network
connections, each on one of three separate networks, so that a failure in
one of the networks would still allow two of the nodes to communicate, a
network outage could have resulted in both partner servers acting as a primary
server. This has been fixed.
================(Build #2520 - Engineering Case #647495)================
On recent versions of Linux (with SELinux enabled), programs with executable
stacks were forbidden. The program would have failed to start with an error
like:
dbeng12: error while loading shared libraries: libdbserv12_r.so: cannot
enable executable stack as shared object requires: Permission denied
This would have potentially happened with any SQL Anywhere binary, and has
now been fixed.
A work around is to either disable SELinux, or run execstack -c on the problematic
binaries.
================(Build #2520 - Engineering Case #647331)================
Execution of an extremely complicated remote query that
needed to be processed in either no passthrough or partial
passthrough mode, could have resulted in a server failure.
The server now properly returns error -890.
================(Build #2520 - Engineering Case #643642)================
Revoking all table permissions from a grantee that were granted by a particular
grantor did not always remove the corresponding SYSTABLEPERM row. This has
now been fixed.
================(Build #2519 - Engineering Case #647187)================
When attempting to insert a string into a proxy table that was the result
of calling a builtin function, if the builtin function returned an empty
string, then there was a chance that the Remote Data Access layer would have
inserted a NULL value instead. For example, a statement like:
INSERT INTO my_proxy_table(my_column) SELECT RTRIM( ' ' )
may have inserted NULL instead of '' into to my_proxy_table. This problem
has now been fixed.
================(Build #2519 - Engineering Case #647076)================
When starting the server on recent versions of Linux using the -ux or -ui
command line options, or when auto-starting a server that required a GUI-based
evaluation splash screen, the server may have crashed or hang. The crash
would have occurred mostly on recent versions of Linux running a GTK theme
engine (e.g. Clearlooks). The hang could have happened with any supported
GTK version after dismissing the evaluation splash screen. This has now been
fixed.
A workaround is to run without the GUI.
================(Build #2519 - Engineering Case #647066)================
The Stored Procedure Debugger was sometimes unable to set breakpoints for
statements in procedures that should have allowed breakpoints. This has been
fixed.
================(Build #2519 - Engineering Case #645664)================
Attempting o unload and reload a database that contained a proxy table with
a unique constraint would have failed with the error: "feature 'alter
remote table' not implemented ". This problem has now been fixed. The
"alter table...add unique" statement is no longer unloaded for
proxy tables.
================(Build #2519 - Engineering Case #643763)================
Execution of a query block that output a string constant could have caused
the server crash if the optimizer chose a parallel execution plan. The likelyhood
of such a crash increased under high server load and when the query occurred
inside a stored procedure. This problem has now been fixed.
For version 12.0.0, this problem was most likely to be encountered when
using string literals in different blocks of a Union, as follows:
SELECT 'String1', col1, col2 FROM table1 WHERE predicate1
UNION
SELECT 'String2', col1, col2 FROM table2 WHERE predicate2
For versions prior to 12.0.0 this problem was much more obscure, and likely
required a constant string occurring both in a non-simple output expression
and in a WHERE clause predicate.
This has been fixed.
================(Build #2518 - Engineering Case #646830)================
In very rare cases, the server may have crashed using long identifiers in
SQL statements. This has been fixed.
================(Build #2517 - Engineering Case #646687)================
If a large number of concurrent connections simultaneously executed remote
queries that required partial or no passthrough processing, and several of
the queries made heavy usage of aliases, then the server could have crashed.
This problem has now been fixed.
================(Build #2517 - Engineering Case #641328)================
A statement such as the following could have incorrectly given an error:
select row_num, if row_num < 1 then 1+row_num/0 endif x
from rowgenerator
order by x
option(force no optimization)
The sub-expression 1+row_num/0 should never be evaluated as the condition
row_num<1 is never true. However, in a simple statement processed by bypassing
the query optimizer, if a Sort was needed to order the rows of the result,
an error could be incorrectly given. This problem has been fixed.
================(Build #2514 - Engineering Case #645926)================
If an Open Client or jConnect application attempted to prepare and execute
a statement with a large number of parameters, then the server would have
failed the request, or in rare cases, could have crashed. This problem has
now been fixed.
================(Build #2513 - Engineering Case #645635)================
HTTP requests made to SQL Anywhere services that utilize the built-in HTTP
Session mechanism (created with sa_set_http_option) may, on rare occasions,
have caused the server to crash. This has been fixed.
================(Build #2512 - Engineering Case #644526)================
If a long index entry (the equivalent of a 250 character or longer ASCII
string) was deleted from an index, there was the possibility of index corruption
and the server crashing. This has been fixed.
================(Build #2512 - Engineering Case #644508)================
A SQL Anywhere HTTP procedure may have failed when configured with a PROXY
clause to connect through an Apache forwarding proxy version 2.0.X. This
has been fixed. Changes have also been made to improve WebClientLogging (-zoc)
messages when connecting through a proxy.
================(Build #2511 - Engineering Case #645138)================
In very rare cases, a primary mirroring server could have crashed on shutdown
if the database was being updated. This has been fixed.
================(Build #2511 - Engineering Case #643936)================
Unexpected column names could have been reported for complex expressions
in the SELECT list of a statement. The problem mostly affected queries over
views, for which the name of the base table column, rather than the name
of the view column, could have been reported.
For example, consider the following table and view:
CREATE TABLE admin_group.employee(
pk INTEGER PRIMARY KEY,
fname CHAR(100) NOT NULL,
lname CHAR(100) NOT NULL,
cname CHAR(100) );
CREATE VIEW admin_group.v AS
SELECT e.fname AS first_name, e.lname AS last_name,
e.cname AS company_name
FROM admin_group.employee e;
In the query:
SELECT <expr> FROM admin_group.v;
the following expressions would have been described with the base table
column names:
CAST( first_name AS VARCHAR(100))
(first_name)
This has been fixed so that both of the expressions above will now be described
as 'first_name'.
Additionally, expressions such as ISNULL( <col1>, <col2> ) could
have been described differently depending on the nullability of the first
column. For example, ISNULL( first_name, company_name ) would have been described
as 'fname', whereas ISNULL( company_name, first_name ) would have been described
as 'isnull( employee.fname as first_name,employee.cname as company_name)'.
For consistency, both of the above expressions will now be described by unparsing
the expression.
================(Build #2511 - Engineering Case #595494)================
When running on Windows Vista or later, if the server encountered a fatal
error it was possible to see a Windows crash dialog as well as a "Send
Error Report" dialog. This has been fixed.
================(Build #2510 - Engineering Case #644733)================
If a server acting as a mirror in a mirroring system required access to transaction
log files on the primary that had been deleted, the mirror server would not
have reported an error. The mirror server would have continued to stay running,
but would not have received updates from the primary server. This has been
fixed so that the mirror server will now report the error and shut down.
================(Build #2510 - Engineering Case #644491)================
A bypass query that contained an invalid cursor range could have caused the
server to crash in certain conditions. This has been fixed.
Note: please see the section "Query processing phases" for a definition
of bypass queries.
================(Build #2509 - Engineering Case #644682)================
Using a reserved word as a label in a Transact-SQL procedure would have made
the procedure unusable. This has been fixed.
================(Build #2509 - Engineering Case #642460)================
Starting a copy node server while updates were being applied at the primary
server, could have resulted in a variety of failures, including assertion
failures 100902 or 100903, or checksum failures. This has been fixed.
================(Build #2506 - Engineering Case #643787)================
REFRESH TEXT INDEX on MANUAL or AUTO text index could have caused database
recovery to fail. For the problem to have occurred, the statement had to
have been executed under SNAPSHOT isolation, which must also have been enabled
on the database as part of the changes being recovered. This has now been
fixed.
================(Build #2506 - Engineering Case #643456)================
If ALTER TABLE was used to reduce the length of a string column to less than
the value of the INLINE or PREFIX values for that column, and then the database
was unloaded, the reload script would have contained CREATE TABLE statements
that would be rejected by the server.
This has been fixed so that the ALTER TABLE statements will now fail.
================(Build #2505 - Engineering Case #644122)================
A number a LOAD TABLE fixes have been made.
1. Arbitrary expressions were allowed in the FROM/USING clause of LOAD TABLE.
If a variable was used, its value was logged to the transaction log; however,
if the expression was anything other than a literal string or a variable
(eg. 'c:\\tmp\\'+filename_var), the original expression would have been logged
including the names of variables whose values would be unknown at recovery.
The problem was fixed by only allowing a string or a variable for the file
name (as documented).
2. If a LOAD TABLE statement was logged that used a variable in the FROM/USING
clause and the statement was affected by database options such that the option
values had to be logged with the statement, the variable name rather than
its value would have been logged. This problem has been fixed.
3. When using LOAD TABLE ... WITH CONTENT LOGGING, the data logged was in
the character set in which the server parsed the input file (either CHAR
or NCHAR charset), rather than the original input file's character set. If
the LOAD TABLE statement had an ENCODING clause, the data would have been
re-translated during recovery as if it were in the specified ENCODING and
potentially mangling the data. Fixed by logging an exact copy of the original
input data.
4. If a LOAD TABLE statement did not contain an ENCODING clause (in which
case the server assumes CHAR charset), the statement written to the log would
not have one either. If the log were translated and executed against a database
with a different collation, the file could be translated incorrectly since
the default encoding would be different. This problem has been fixed by always
logging an ENCODING clause.
5. If a LOAD TABLE statement contained an ENCODING clause that specified
a 'UTF16' encoding of unspecified endian, the logged statement would also
have contained an ENCODING clause with an unspecified endian. If recovery
were performed on a server with the opposite endian, or if the log was translated
then executed on a server with the opposite endian, the statement would not
interpret the input file correctly. This problem has been fixed by never
logging ambiguous names for encodings.
6. LOAD TABLE ... FORMAT XML ... WITH CONTENT LOGGING did not actually log
any data and was not recoverable. This problem has been fixed.
7. LOAD TABLE ... FORMAT XML ... USING COLUMN (which is the statement that
is logged for a LOAD TABLE ... FORMAT XML ... WITH CONTENT LOGGING) would
have crashed the server. This problem has been fixed.
8. LOAD TABLE USING CLIENT FILE ... WITH FILE NAME LOGGING was permitted
by the server and the server would then have logged a statement that referenced
a client file. Access to the client file requires an active connection from
the client and therefore this statement was not recoverable. This problem
has been fixed by requiring WITH CONTENT LOGGING when loading from a client
file. If the logging type is not specified when loading from a client file,
content logging is assumed.
9. When recovering a LOAD TABLE ... WITH CONTENT LOGGING or executing LOAD
TABLE ... USING COLUMN, the server would have leaked a small amount of memory
for each row of data fetched from the table containing the pieces of the
original file image. This problem has been fixed.
10. When executing LOAD TABLE ... USING COLUMN ... ENCODING..., the server
did not check for a conflict between the specified encoding and the encoding
of the column's datatype. This problem has been fixed by reporting an error
if the encodings conflict.
11. LOAD TABLE and UNLOAD TABLE did not allow the ESCAPE CHARACTER to be
more than 1 byte. It can now be an arbitrary string, but it is recommended
that it should be no longer than one (potentially multibyte) character.
12. When using UNLOAD TABLE with a QUOTE or ESCAPE CHARACTER which was
not encoded identically in both CHAR and NCHAR character sets, the quotes
may not be doubled up or escape sequences may not be issued where necessary
depending on the datatype of the column being unloaded. This problem has
been fixed.
13. When using UNLOAD TABLE with a QUOTE or ESCAPE CHARACTER which were
not encoded identically in both CHAR and NCHAR character sets and the destination
charset, the quotes or escape characters could have been translated incorrectly
when converting to the destination character set. This problem has been fixed.
14. ALTER DBSPACE RENAME allowed a variable to be used for the new file
name but the variable name rather than its value was logged, which meant
that the statement was unrecoverable. This problem has been fixed by logging
the variable's value instead.
15. The SQL generated by the Log Translation utility (dbtran) for LOAD TABLE
... WITH CONTENT LOGGING (ie inserts into a temporary table) did not work
correctly due to the temporary table's name being fully qualified with the
user's name. This problem has been fixed.
================(Build #2505 - Engineering Case #643802)================
A web procedure that references another computer by name may have failed
to connect if both machines supported IPv6, but the web server on the remote
computer was not listening on any IPv6 addresses. This has been fixed.
================(Build #2505 - Engineering Case #643590)================
When using the include_file parameter of the external system procedures xp_sendmail
and xp_sendmail, they may have failed depending on the length of the file.
This has been fixed.
================(Build #2504 - Engineering Case #643596)================
When executing a query that involved window functions, proxy tables and dotted
references, if the query was invalid due to a missing GROUP BY reference,
then there was a chance the server would have failed to return the error.
In some cases, the server would even have crashed. This problem has now been
fixed.
Note that this fix is a follow-up Engineering case 641477.
================(Build #2504 - Engineering Case #634181)================
The amount of data in CHAR, NCHAR or BINARY variables could have exceeded
the declared length of the variable when data was appended using the string
concatenation operator (||). This has been fixed.
================(Build #2502 - Engineering Case #643355)================
Setting the value of an OUT parameter in an external stored procedures would
have persisted, even without calling the set_value() function. This has been
fixed.
================(Build #2502 - Engineering Case #643342)================
If an external environment call encountered a thread deadlock error, then
there was a very small chance the application or event connection would have
hung. This problem has now been fixed.
================(Build #2502 - Engineering Case #643317)================
Canceling a call to xp_sendmail(), xp_startmail(), xp_stopmail(), xp_startsmtp(),
or xp_stopsmtp(), may have caused a server crash. The external stored procedures
that manage SMTP mail state did not protect against the case were two threads
can try to access the same SMTP state. This has been fixed.
================(Build #2502 - Engineering Case #643314)================
Canceling an external stored procedure may have caused the server to crash.
This has been fixed.
================(Build #2502 - 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 #2502 - Engineering Case #642600)================
When attempting to start the server on a TeamPad series model of a Fujitsu
CE device, the server would always have failed, report the error "Not
enough memory". This problem has been fixed
================(Build #2502 - Engineering Case #637057)================
If the network connection between a primary server and a mirror server was
temporarily broken, the primary server could have stopped sending updates
to the mirror server. This has been fixed.
================(Build #2501 - Engineering Case #642524)================
The server could have become unresponsive when processing index scans in
which a residual predicate continually rejected candidate rows for the duration
of the scan. This has been fixed.
================(Build #2499 - Engineering Case #642329)================
An attempt to use an exception name in a procedure when the exception had
not been declared did not report an error. This has been fixed.
================(Build #2499 - Engineering Case #641806)================
The date_format, timestamp_format and uuid_has_hyphens options stored in
a text configuration were not respected during an immediate text index update.
Immediate text index updates incorrectly used the current connection option
values. This has been fixed.
If an existing immediate text indexes is suspected of being effected by
this problem then the text index needs to be refreshed after applying this
fix.
================(Build #2499 - Engineering Case #641360)================
The server may have returned an incorrect result set for a query that contained
a GROUP BY clause with distinct arguments, and the GROUP BY was executed
using the low memory strategy. This has been fixed.
================(Build #2497 - Engineering Case #641434)================
If a large number of connections that had made external environment calls
all shut down at the same time, then there was a chance the server would
have hung one of the clients trying to shut down. In some cases, all the
requests to shut down the connections would have succeeded, but the server
would have subsequently hung when asked to terminate. Both of these problems
have now been fixed.
================(Build #2497 - Engineering Case #640540)================
The property QueryOpened was not being increased if a reusable cursor was
opened. This has been fixed.
================(Build #2496 - Engineering Case #641793)================
In very rare cases, the server could have hang if an external environment
call was made at the same time that the server performed some maintenance
on the database. This has now been corrected.
================(Build #2495 - Engineering Case #641487)================
If a server was started with -o <file name>, then stopped and immediately
started again with the same -o <file name>, the server could have failed
to start with the errors "Invalid database server command line"
or "Can't open Message window log file: <file name>". This
failure was rare and timing dependent, and has now been fixed so the second
server will successfully start.
================(Build #2495 - Engineering Case #641095)================
The changes for Engineering case 635618, could have caused an INSERT statement,
using the CONVERT() function to convert a string to a time, to fail assertion
111704 - 'Attempting to store invalid time value in table {table name}, column
{column name}. This problem did not occur if CAST was used in place of CONVERT,
and has now been fixed.
================(Build #2495 - Engineering Case #640901)================
Revoking table column permissions may have failed with the SQL error 'Permission
denied: you do not have permission to revoke permissions on "Column1"'
if there were column permissions granted from multiple grantors. This has
been fixed.
================(Build #2495 - Engineering Case #640543)================
The result set returned for a query with GROUP BY and ORDER BY clauses was
not correctly ordered if both clauses contained the same integer constant.
This has been fixed.
================(Build #2495 - Engineering Case #637897)================
On SUSE 10 systems, the server could have failed to start a database if the
database file was mounted on an NFS share. The error given would be something
like:
"Error: Database cannot be started -- /mnt/share/demo.db is not
a database"
This has now been fixed.
================(Build #2495 - Engineering Case #636801)================
Unloading a version 9 database with a table with named primary key constraint
could have failed if the primary key was referenced by an index hint in a
view. This has been fixed.
Also, unloading a version 10 or later database containing a table with a
primary key index that had been renamed would have failed to preserve the
new name for the index. This has been fixed.
================(Build #2494 - Engineering Case #641123)================
If a mirror or read-only copy node server was shut down while updates were
being made on the primary server, the mirror or copy node could have failed
to restart. Starting a mirror or copy node while updates were being made
on the primary server could also have prevented that server from starting.
These problems have been fixed.
================(Build #2494 - Engineering Case #640923)================
Simple queries using the aggregate GROUPING(1), but with no GROUP BY clause,
would have returned the meaningless error "Invalid expression near GROUPING(1)".
This has been fixed. The server now returns the error "Argument to GROUPING
aggregate must be a grouping column in the GROUP BY clause".
================(Build #2492 - Engineering Case #640434)================
A failed attempting to connect to a server which required the server to be
autostarted could have leave the server running. This could have occurred
if the server started had the server stop permission set to a value other
than None, and server failed to start the database for certain reasons.
For example, if asatest.db is an Adaptive Server Anywhere 9 database, the
following would start a server that was left running:
dbping -d -c "uid=dba;pwd=sql;dbf=asademo.db;start=dbsrv11 -x none"
This has now been fixed.
================(Build #2492 - Engineering Case #606848)================
Executing a REORGANIZE TABLE statement on a table having an IMMEDIATE text
index would have caused the index size to double. Additionally, under some
rare circumstances, incorrect results could have been returned for subsequent
full text queries. This has been fixed.
Note, if there exists a text index in a database affected by this problem,
it should be dropped and recreated to reclaim the space and avoid possible
wrong results for full text queries.
================(Build #2490 - Engineering Case #640621)================
Depending on timing, stopping a server with the Stop Server utility (dbstop)
and immediately restarting it with the Start Server in Background utility
(dbspawn) could have return the error:
DBSPAWN ERROR: -85
Communication error
The communication error could also have occurred if the server was started
without dbspawn. This has been fixed.
================(Build #2490 - Engineering Case #640240)================
Execution of an ATTACH TRACING statement with a LIMIT clause, either by size
or by time, would generally have failed to limit the size of the trace captured.
This has been fixed.
================(Build #2490 - Engineering Case #640232)================
Dropping a temporary procedure could have caused recovery to fail if the
procedure name was qualified with an owner. This has been fixed.
================(Build #2490 - Engineering Case #639535)================
Queries that did a sequential table scan could have failed to return all
the rows in the table. This would usually only have happened when doing
a DELETE over a non-transactional temporary table. This could also have happened
to regular base tables with concurrent deleters as well, but the chances
of this would have been very low in practice.
A workaround is to issue deletes over a non-transactional temporary table
multiple times.
================(Build #2489 - Engineering Case #639836)================
A SQL Anywhere "root" web service did not resolve a URL when the
database name was provided without a terminating slash, i.e. http://localhost/dbname.
The server would have returned a 404 "Not Found" HTTP status. The
following URL forms were also rejected with a 404 "Not Found":
http://localhost/dbname?arg
http://localhost/dbname/?arg
The problem existed for both secure and insecure services, and has now been
fixed.
================(Build #2488 - Engineering Case #639706)================
The startup error messages "Failed to become a daemon" and "'%1'
is not a valid engine name" were not localized on UNIX systems. This
has been corrected.
================(Build #2487 - Engineering Case #639656)================
In some cases the Start Server in Background utility (dbspawn) could have
returned the generic error, -80 (Cannot start server), instead of returning
the real error. In other cases, the server could have crashed on shutdown.
This has been fixed.
================(Build #2486 - Engineering Case #639238)================
In very rare cases, doing full validation on a table may have caused the
server to crash. For this to have occurred, the following conditions had
to hold:
1) Validation was being done online.
2) The table contained blobs.
3) Table blobs were being heavily modified by other concurrent requests.
4) The right timing happened between the validation process and the blob
update
process.
This has been fixed.
================(Build #2486 - Engineering Case #639159)================
In some cases, calling the system procedure sa_get_request_times() may have
caused the server to crash. This has now been fixed.
================(Build #2486 - Engineering Case #638494)================
Attempting to start an external environment when the server machine was incorrectly
configured would have caused the application to wait up to 15 seconds before
receiving an error from the server. An incorrectly configured server usually
results in the external environment process terminating immediately upon
startup; hence the server will now report an appropriate error as soon as
it detects that the external environment process terminated while starting
up.
================(Build #2485 - Engineering Case #639016)================
Attempting to execute queries that used the FOR XML clause, may have caused
the server to crash when failures were encountered while fetching data.
This has been fixed.
================(Build #2485 - Engineering Case #638207)================
A LOAD TABLE statement would have failed assertion 111706 "Attempting
to store invalid string value in table "{table name}", column "{column
name}" if the table had a column with user datatype uniqueidentifier.
The problem only happened if a user datatype was used. This has been fixed.
To fix such tables in existing databases the table needs to get recreated
or a database upgrade needs to be run.
================(Build #2485 - Engineering Case #637881)================
When executing a remote query that required partial or no passthru processing,
and the query made heavy usage of aliases, then the server could have incorrectly
returned error "-890 statement size or complexity exceeds server limits".
This problem has now been fixed and the -890 error will now only be returned
if the statement size or complexity really does exceed server limits.
================(Build #2485 - Engineering Case #633232)================
The server could have crashed under certain circumstances where malformed
data existed in the database, and an attempt was made to generate statistics
over this data either implicitly or explicitly. Customer applications that
do not insert this malformed data are not likely to be impacted. The server
now treats malformed data as NULL for the purpose of statistics collection.
================(Build #2484 - Engineering Case #638849)================
Statements which CREATE, DROP or ALTER synchronization profiles were not
being recorded in the transaction log. If a database server needed to recover
the effects of one of these statements, recovery could have failed. This
has been fixed.
================(Build #2484 - Engineering Case #637336)================
Dropping a text index used within a view could have caused the assertion
failure message: "Unable to delete row from SYSTABLE". This could
have happen when the view definition contained a CONTAINS predicated that
could have be satisfied by the text index. This has been fixed. A workaround
is to drop the view, then drop the text index.
================(Build #2483 - Engineering Case #637340)================
If a Unix server was started with a server name longer than 32 bytes, shared
memory connections to it may have been dropped. This has been fixed.
================(Build #2483 - Engineering Case #634785)================
When applying an MSI install built using the deployment wizard, and specifying
the target directory similar to the following:
msiexec /i sqlany11.msi SQLANYDIR="{path to install directory}\xxx
xxxxxxxx xx"
the install could have failed. This has been fixed.
================(Build #2482 - Engineering Case #638484)================
Larger tables with a clustered index that had a significant number of rows
inserted at the end of the clustering index, could have exhibited poor local
clustering. This could have caused the optimizer to pick sub-optimal plans.
This has been fixed.
================(Build #2482 - Engineering Case #638477)================
In extremely rare circumstances, servers answering queries with keyset cursors
may have become unstable, leading to an eventual crash. This has been fixed.
================(Build #2482 - Engineering Case #631004)================
The range for a correlation coefficient is between -1 and +1, however the
corr() system function returned only positive values. This has now been corrected.
================(Build #2482 - Engineering Case #627397)================
In very rare cases the server may have crashed when releasing a query plan
of a DML statement from the plan cache, and the statement had triggers and
publications and used string or numeric values. This has been fixed.
================(Build #2481 - Engineering Case #638260)================
If a database with multiple dbspaces failed to start (for any of a variety
of reasons such as an invalid log file), the server could have erroneously
reported:
"Assertion failed: 201117 Attempt to close a file marked as dirty".
This has now been corrected.
================(Build #2480 - Engineering Case #638001)================
Attempting to start an external environment on a server machine that was
overloaded or incorrectly configured, could have resulted in the error "External
environment could not be started, 'main thread' not found". Quite often
this problem was due to the external environment failing to establish a connection
with the server within a specific timeout, either due to the server (or server
machine) being overloaded, or due to incorrect configuration. The error message
has now been changed to give a more meaningful reason for the failed START
EXTERNAL ENVIRONMENT request.
================(Build #2480 - Engineering Case #637988)================
If an incorrect password was supplied in the saldap.ini file, the server
could have hung when attempting to register with LDAP. Also, SA client libraries
could have hung when using LDAP to find servers. This has been fixed.
================(Build #2480 - Engineering Case #637745)================
If an application executed a remote statement, and the remote statement required
the server to execute the statement in either partial or no passthrough mode,
then there was a chance the server would have crashed when the statement
was overly complex, or if the server cache was exhausted. This problem has
now been fixed by reporting an error in this situation.
================(Build #2480 - Engineering Case #637290)================
On a machine with IPv6 enabled but not configured, the function property('TcpipAddresses')
would have returned "(::):2638" as one of the addresses. This is
the IPv6 INADDR_ANY address, and it is not useful to clients for making connections.
If HTTP or HTTPS was in use, the functions property('HttpAddresess') and
property('HttpsAddresses') would have had the same problem. This has been
fixed so that now this address will no longer be listed.
================(Build #2480 - Engineering Case #636018)================
Queries involving indexes containing long values could have returned incorrect
results. Index corruption was possible, but not likely. This problem has
now been fixed.
================(Build #2480 - Engineering Case #634728)================
If a simple statement had one of the following forms and a table hint was
used in the FROM clause, it was possible for subsequent statements from the
same connection with the same form, but with different hints, to use the
hints from the earlier statement.
1) SELECT {table columns} FROM {table} WHERE {primary key col1 = val1,
primary key col2 = val2, ... }
2) UPDATE {table} SET ... WHERE {primary key col1 = val1, primary key col2
= val2, ... }
3) DELETE FROM {table} SET ... WHERE {primary key col1 = val1, primary
key col2 = val2, ... }
This has been fixed. As a work-around, the statements can be change to include
"OPTIONS( FORCE OPTIMIZATION )", or the server can be started with
the following command line switch: "-hW AllowSimpleUserCache".
================(Build #2479 - Engineering Case #637874)================
When computing the VARIANCE, VAR_SAMP, VAR_POP, STDDEV, STDDEV_SAMP, or STDDEV_POP
functions, the server could have incorrectly returned a negative value or
NULL. This could have happened if the data was in a non-exact numeric column
(that is, of type DOUBLE or FLOAT) and there was extremely little actual
variance across the values. It most likely could only have happened when
all the values were exactly the same. This has now been fixed.
A workaround is to adjust the value over which the variance function is
computed so that a tiny amount of variance is introduced. For example, instead
of:
SELECT VARIANCE(mycolumn) FROM mytable
use:
SELECT VARIANCE(mycolumn + 0.00000001*myprimarykey) FROM mytable
================(Build #2479 - Engineering Case #637769)================
As part of the fix for Engineering case 632873, a problem was introduced
where, under rare circumstances, an IMMEDIATE text index could have become
corrupt. The corruption may manifest itself by preventing some documents
from being found by matching queries. This has been fixed, but it is recommended
that IMMEDIATE text indexes that are under heavy contention be recreated
following applying this fix.
================(Build #2478 - Engineering Case #637620)================
In rare circumstances, the server could have crashed while handling multiple
TLS connections. This has been fixed.
================(Build #2478 - Engineering Case #637125)================
If an application executed a remote query that required the server to make
a remote connection to another SA database, then there was a very rare chance
that the server would have incorrectly failed the remote connection with
the error: "unable to connect, server definition is circular".
This problem has now been fixed.
================(Build #2478 - Engineering Case #634883)================
Connections which had communication compression enabled could have been dropped,
resulting in the "Connection was terminated" error. This was more
likely to occur if the connection had both communication compression and
simple encryption enabled. If the server -z log and the client LOGFILE log
was used, the message "Failed to decompress a compressed packet"
would have appearred in one or both of the logs when this problem occurred.
This has been fixed.
================(Build #2476 - 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 #2474 - Engineering Case #636770)================
If the database option Chained was set to OFF, upgrading the database would
have failed with the error: "COMMIT/ROLLBACK not allowed within atomic
operation". This has been fixed by temporarily setting the option to
ON within the upgrade script when needed.
================(Build #2474 - Engineering Case #636660)================
SQL Anywhere web server required that the last boundary of a multi-part/formdata
HTTP request be terminated with a carriage-return line-feed. This restriction
has now been relaxed, the server will now accept the last boundary as valid
even if it is not terminated with a CR/LF.
================(Build #2474 - Engineering Case #636572)================
If an application executed a remote query, and the query involved an IF or
CASE expression in the select list, then the query would always have been
processed in partial or no passthru mode, even if there was only one remote
server involved. This restriction has now been relaxed such that remote queries
containing IF or CASE expressions in the select list will now be executed
in full passthru whenever possible, but only if the remote server is another
SA server.
================(Build #2474 - Engineering Case #636508)================
Attempting to use an unnamed multi-column unique constraint as an index hint
in the FROM clause, would have caused the error "Cannot find index named".
This has been fixed.
================(Build #2474 - Engineering Case #622184)================
All CALL statements had the same hash signature when captured by diagnostic
tracing, or the Application Profiling wizard. Now, the name of the procedure
is incorporated into the signature. This means that the Summary view of
captured statements will contain one entry for every procedure, rather than
a single entry for all procedures, which makes it easier to identify procedures
that need to be looked at for performance reasons.
================(Build #2473 - Engineering Case #637037)================
When a stored procedure was invoked through the Microsoft SQL Server Linked
Server mechanism using an "EXEC" statement and specifying parameters,
the call would have failed with a syntax error. The following is an example
of a SQL Server query that is forwarded to a SQL Anywhere server:
SELECT * FROM openquery(SALINK, 'exec test_proc 1')
This problem has been fixed. When parameters are present in the SQL query,
the statement is passed unchanged to the server. When no parameters are present,
the OLE DB provider rewrites the "exec" statement using CALL and
appends parameter marker place holders (in order to support ADO's ADODB.CommandTypeEnum.adCmdStoredProc).
================(Build #2473 - Engineering Case #636307)================
A simple UPDATE statement that affected a large number of rows could have
consumed memory proportional to the number of rows if the statement used
one of the following features:
- results from a user-defined function with numeric Expression Caching
(any data type)
- a LIKE predicate
- a CAST of a string to an approximate number (REAL, DOUBLE, or FLOAT)
- the SORTKEY or COMPARE builtin function
- the REMAINDER or MOD builtin functions with arguments of type NUMERIC
or DECIMAL
- the MEDIAN aggregate function
- a spatial data type
If the memory usage exceeded what was allowed for one connection, the statement
would have failed with a dynamic memory exhausted error. This has been fixed.
================(Build #2473 - Engineering Case #635803)================
Diagnostic tracing databases, or databases created by the automatic Application
Profiling Wizard, would have failed to start if the original database had
auditing enabled. This has been fixed.
A workaround is to temporarily disable auditing on the main database, create
the tracing database, and then re-enable it.
================(Build #2473 - Engineering Case #634775)================
Execution of a CREATE TEXT INDEX <name> ON <table_name>(...)
statement on a proxy table could have failed silently without giving an error.
The creation of text indexes on proxy tables is not allowed, and the statement
now gives the appropriate error.
================(Build #2472 - Engineering Case #635618)================
When converting a string to a time using the CONVERT function and an explicit
format-style, SQL Anywhere 10.0 and above could have rejected conversions
permitted by earlier versions.
For example, the following statement is accepted by version 9.0, but rejected
by version 10.0 and above:
select convert( time, '11:45am', 14 ) tm_conv
The behavour of converting from strings to TIME changed from version 9.0
of SQL Anywhere to version 10.0 and later, with version 10.0 and later applying
the same rules that conversions from string to timestamp used. The string
'11:45am' does not precisely match the format style 14 (hh:nn:ss:sss) because
it contains an "am" indicator that is not present in the style.
Parsing of formatted time strings has been enhanced so that the time portion
of a string is accepted provided that it matches the format [hh:nn:ss.ssssssAA].
The time string must specify the hour digits, but all other time parts are
optional. The AM/PM indicator is always accepted whether or not time parts
are omitted. Note that this now permits up to six digits to represent microseconds
after the seconds. This change affects the conversion of string to TIME and
also to TIMESTAMP, so there is a consistent parsing. The following is rejected
after this change, even though it was accepted in 9.0:
select convert( time, '1991-02-03 11:45', 101 )
The string does not match the style format 101 (mm/dd/yyyy).
Further, in some cases it was possible to generate invalid timestamps with
string conversions. This has also been fixed.
================(Build #2472 - Engineering Case #633795)================
Under rare circumstances, a query with a CONTAINS clause or predicate could
have returned incorrect results when executed on a connection with snapshot
isolation. For the problem to have occurred, the query would have had to
have used an IMMEDIATE text index with a high volume of updates. This has
been fixed.
================(Build #2470 - Engineering Case #635961)================
Attempting to connect using Integrated Login to a mirror server, or copy
node, would have failed with the error "Integrated login failed".
This has been fixed.
================(Build #2470 - Engineering Case #635815)================
If Java or other external environment objects were installed in a database,
and the database failed to shut down cleanly before the next checkpoint,
then it was likely that the Java or external environment objects would have
needed to be re-installed. This problem has now been fixed.
================(Build #2470 - Engineering Case #635120)================
In exceptionally rare conditions, the server may have crashed while reading
a row of a table that had a very large number of columns. This has now been
fixed.
================(Build #2468 - Engineering Case #646169)================
When run on a machine with 25 or more logical processors, the server may
have hung. This hang would only have occurred on Windows and Linux systems.
This problem has been fixed.
A workaround is to reduce the number of logical processors the server uses
by specifying
-gtc <num>, where num is less than or equal 24.
================(Build #2468 - Engineering Case #635322)================
The cleaner may not have completely cleaned pages in some situations. This
has now been fixed.
================(Build #2468 - Engineering Case #634327)================
The server may have hung while running the Validation utility (dbvalid),
or the equivalent VALIDATE DATABASE statement. This was only possible if
multiple connections were open to the database, at least one of which is
doing DDL (such as an ALTER TABLE statement), and a checkpoint or connection
attempt was made during the validate. This has now been fixed.
Note, it is recommended that the database server not be servicing other
connections while database validation is taking place.
================(Build #2468 - Engineering Case #633773)================
The method used for an internal database server timer on Linux to support
request timing (-zt option,) and row access times in the graphical plan with
statistics, was unreliable. This has been fixed.
================(Build #2468 - Engineering Case #632873)================
Concurrent updates to an IMMEDIATE REFRESH text index may have corrupted
the index. This has been fixed.
================(Build #2467 - Engineering Case #634724)================
With the option Blocking set to 'off', any attempts to modify a row that
is locked by another user will result in an error message. Occasionally,
this error message would have contained the string 'another user', instead
of a valid user name. This has been fixed.
================(Build #2467 - Engineering Case #633465)================
Under rare circumstances, Application Profiling or diagnostic tracing could
have caused the server to crash when the application being profiled used
UPDATE statements with complex FROM clauses. This has been fixed.
A workaround is to avoid capturing the PLANS_WITH_STATISTICS level.
================(Build #2466 - Engineering Case #635066)================
When Snapshot isolation was enabled, deleted rows might not have been physically
removed in some cases. This has been corrected.
================(Build #2465 - Engineering Case #633753)================
If an application deleted a row from a table with a unique index, then subsequently
called an external environment procedure, and the external environment procedure
then re-added the row using the server-side connection, the application would
have received an assertion failure (200112) message on rollback. This problem
has now been fixed.
================(Build #2464 - Engineering Case #632353)================
If the server acting as the primary server in a mirroring system was shut
down at the same time as it lost quorum due to a dropped mirror connection,
the database on the primary could have been improperly checkpointed, resulting
in a failure to recover on the next startup. Also, if a mirror server was
starting at the same time the primary server was stopping or restarting,
the mirror server could have received log operations that were not written
on the primary. This would have resulted in an "incompatible files"
message the next time the mirror connected to the primary, and would have
forced the database and log to be manually recopied. Both of these problems
have now been fixed.
================(Build #2463 - Engineering Case #634330)================
Kerberos server principals needed to be of the form: server_name@REALM (for
example myserver@SYBASE.COM). There was no way to specify a Kerberos server
principal of the industry standard form: server_name/hostname@REALM (for
example myserver/mymachine.sybase.com@SYBASE.COM). Now the Kerberos server
principal can be specified with the server -kp option. The server principal
specified by -kp must have been extracted to the Kerberos keytab file on
the machine running the database server. Note that only one of -kp or -kr
can be specified.
-kp dbengX/dbsrvX server option:
Specifies the Kerberos server principal and enable Kerberos authenticated
connections to the database server.
Syntax:
-kp server-principal
Applies to:
all OSes except Windows Mobile
Remarks:
This option specifies the Kerberos server principal used by the database
server. Normally, the principal used by the database server for Kerberos
authentication is server-name@default-realm, where default-realm is the default
realm configured for the Kerberos client. Use this option if you want to
use a different server principal, such as the more standard format server-name/hostname@myrealm.
If OpenClient or jConnect Kerberos authenticated connections are made to
the server, the server principal must be specified by the application (see
SERVICE_PRINCIPAL_NAME for jConnect).
The -kr option cannot be specified if the -kp option is specified.
Specifying this option enables Kerberos authentication to the database server.
See also:
<same list as -kr option documents, with the addition of the -kr option>
Example:
The following command starts a database server that accepts Kerberos logins
and uses the principal myserver/mymachine.sybase.com@SYBASE.COM for authentication.
dbeng12 -kp myserver/mymachine.domain.com@MYREALM -n myserver C:\kerberos.db
================(Build #2461 - Engineering Case #633747)================
Unsetting the public option Oem_string would have caused the server to crash.
This has been fixed.
================(Build #2461 - Engineering Case #632875)================
The server would have crashed if a client application attempted to connect
while the
server was shutting down after failing to start. This has been fixed.
================(Build #2460 - Engineering Case #634191)================
If an application made an external C environment call with a NULL argument,
and the external C environment routine subsequently called get_value() to
retrieve the NULL argument, then the environment would have incorrectly returned
a status of 0 indicating failure to the external C environment routine, rather
than returning a non-zero status. This problem has now been fixed.
================(Build #2459 - Engineering Case #631890)================
If an outer join had a materializing operator on the null-supplying side
(for example a work table or a sort), then the performance could have been
slower than it could have been because expressions from the tables under
the null-supplying side were materialized when they were not needed above
the join.
Also, the server could have crashed while executing a plan with an outer
join if the null-supplying side contained an IN-list with either NUMERIC
or string values.
These problems have now been fixed.
================(Build #2457 - Engineering Case #633275)================
If a database mirroring server was shut down via the console (or via a HUP
signal on Unix), it could have hung. This has been fixed. As a workaround,
use the Stop Server utility (dbstop) to stop the server.
================(Build #2456 - Engineering Case #632342)================
Under rare circumstances, the server may have hung while diagnostic tracing
was enabled. This has been fixed.
================(Build #2456 - Engineering Case #629056)================
Attempting to connect with the connection parameter DatabaseName (DBN), but
not DatabaseFile (DBF), to a database that was not running on a network server
could have incorrectly resulted in the error "Request to start/stop
database denied". This error could have also occurred on the personal
server if the -gd option was used. This has been fixed so that this now results
in the "Specified database not found" error.
================(Build #2456 - Engineering Case #628573)================
The system procedure xp_startsmtp may have returned error code 104 depending
on the SMTP server being used. This has been fixed.
================(Build #2456 - Engineering Case #623779)================
Servers running databases with large schemas may experience periods of unresponsiveness
at idle checkpoint time. The performance of checkpoints has been improved
to reduce the length of this interval.
================(Build #2455 - Engineering Case #633021)================
When using the external system procedure xp_startsmtp, if the SMTP authentication
failed the server would not have closed the TCP connection to the SMTP server.
This has been fixed.
================(Build #2455 - Engineering Case #633015)================
If an application called a Java external environment procedure that returned
result sets, then those result sets would not have been cleaned up for a
long time after the application was done with them. The result sets now get
cleaned up in a more timely fashion.
================(Build #2454 - Engineering Case #632874)================
Under very rare circumstances, sequential scans of tables that had rows deleted
within the past minute may have returned too few rows. Subsequent scans
of the table would have returned the correct number of rows.
This has been fixed.
Note, this problem was extremely rare in builds prior to the changes made
for Engineering case 625189, it would have been slightly more likely in later
builds, due to increased frequency of cleaner invocation.
================(Build #2454 - Engineering Case #624801)================
An HTTP protocol option specifying a port with no value would have started
a listener on the next available port. Specifying a port with no value, or
providing a value of zero, is no longer accepted. All protocol options that
take a numeric value will no longer accept an empty value as a zero default.
================(Build #2452 - Engineering Case #632413)================
On Vista and later versions of Windows, the Windows Performance Monitor utility
(perfmon) could not have monitored a database server which was running as
a Windows service. This problem has been fixed.
================(Build #2451 - Engineering Case #632438)================
When running the Unload utility to create a new database with the same settings
(dbunload -ar), it may have immediately failed with the error "Too many
connections to database being replaced". This would have been rare,
and retrying the unload would likely have resulted in success. This has been
fixed.
================(Build #2451 - Engineering Case #632417)================
If a Java or CLR external environment had been started, and an application
then attempted to execute an "alter database upgrade" command,
or if the Upgrade utility (dbupgrad) was run, then the upgrade would have
failed due to the fact that the database was still in use by the external
environment(s). This problem has now been fixed and the external environments
will now be shut down provided they are idle at the time the database upgrade
is attempted.
================(Build #2450 - Engineering Case #632362)================
If a connection set the dedicated_task option to 'On', then there was a chance
a request for this connection would have hung. This was more likely for connections
where many requests are sent one after the other. This has been fixed.
================(Build #2450 - Engineering Case #632315)================
The START JAVA statement would have failed when the server was started through
the GUI (DBLauncher) on Mac OS X 10.6. This has been fixed. Servers started
via the command line interface (Terminal.app) do not have this problem.
================(Build #2449 - Engineering Case #632050)================
If a Java external environment had been started for a particular database,
and a connection on that database accidentally attempted to drop the SYS.DUMMY
table, then the connection would have hung instead of giving the expected
"permission denied" error. This problem has now been fixed.
Note that this problem does not exist for external environment other than
Java.
================(Build #2449 - Engineering Case #632048)================
If a view or derived table was used on the null-supplying side of an outer
join it was possible for the expression to return a non-NULL value for a
row of the view that should have been null-supplied. This would have occurred
if one of the view columns contained one of the following expressions:
- user-defined function
- argn
- http_header
- http_response_header
- http_variable
- isdate
- isnumeric
- next_connection
- next_database
- next_http_header
- next_http_response_header
- next_http_variable
- next_soap_header
- patindex
- soap_header
- stuff
For example, the following queries would have incorrectly returned a non-NULL
value for the column "b" of the derived table "D":
select *
from rowgenerator left join ( select dummy_col , argn( 1, 137, dummy_col
) b from sys.dummy ) D on 1=0
where row_num=1
select *
from rowgenerator left join ( select dummy_col , isnumeric( dummy_col
) b from sys.dummy ) D on 1=0
where row_num=1
This has been fixed.
================(Build #2448 - Engineering Case #631904)================
If a server or database was started with a space in the name, then attempting
to start external environments would have failed. This problem is specific
to servers running on Windows based systems, and has now been fixed..
================(Build #2448 - Engineering Case #631897)================
In extremely rare timing dependent cases, if a communication error occurred
on a connection with the dedicated_task option set in a mirroring configuration,
the server could have crashed, asserted or hung. The fix for Engineering
case 628436 missed this situation, which has now been fixed.
================(Build #2448 - Engineering Case #631797)================
If a column CHECK constraint was defined using references to other columns,
it was not being handled as a table CHECK constraint. This has been fixed.
================(Build #2448 - Engineering Case #631774)================
The server could have crashed if lock contention was high. This has been
fixed.
================(Build #2447 - Engineering Case #631640)================
In very rare cases, the server could have crashed if a database shutdown
request was received at the same time that an active connection on the same
database executed an external environment call. This problem has now been
fixed.
================(Build #2447 - Engineering Case #631525)================
If a cursor was opened over a query containing a call to the system procedures
sa_rowgenerator() or sa_reserved_words(), and the cursor was moved forward
and backwards, the server could have returned inconsistent results. The scrolling
could have happened implicitly as a result of prefetch and re-fetching columns
(for example, using GET DATA). This has been fixed.
================(Build #2447 - Engineering Case #625189)================
Repeatedly inserting and deleting rows with long strings may have lead to
unconstrained database growth. This was more likely to occur if the server
was continually under heavy load. In 11.x servers, snapshot isolation must
have been enabled for this problem to have occurred. This has now been corrected.
================(Build #2445 - Engineering Case #631484)================
Execution of an ALTER TABLE statement, could have corrupted the table after
deleting and committing some rows from it. This has now been fixed.
================(Build #2445 - Engineering Case #631475)================
Calls to some system procedures may have caused an server crash if null arguments
were used. This has been fixed.
================(Build #2445 - Engineering Case #627631)================
In rare cases, a database server used for mirroring could have crashed when
the connection to its partner was dropped. This has been fixed.
================(Build #2444 - Engineering Case #631113)================
Attempting to execute a CREATE OR REPLACE PROCEDURE statement could have
caused a server crash. This has been fixed.
================(Build #2444 - Engineering Case #630376)================
If a database being mirrored had been enabled for auditing and the mirror
servers were restarted, no auditing operations were recorded in the transaction
log. This has been fixed.
================(Build #2444 - Engineering Case #630226)================
If an ALTER TABLE statement had a DROP or ALTER column clause, and the column
did not exist,
then an incorrect column name could have been reported in the error message.
This only happened if there was another ADD, ALTER or DROP column clause
in the statement. This has been fixed.
================(Build #2443 - Engineering Case #631017)================
If an application attempted to create a proxy table to a Microsoft SQL Server
table which contained a varbinary(max) column, then the server would have
incorrectly mapped the varbinary(max) column to varbinary(1). This problem
has now been fixed and the server now correctly maps varbinary(max) columns
to long varbinary.
================(Build #2443 - Engineering Case #630890)================
In very rare situations, the server may have crashed when executing a statement
that contained a large number of UNION, EXCEPT or INTERSECT clauses. This
has been fixed. These statements will now return the sql error "Statement
size or complexity exceeds server limits".
================(Build #2443 - Engineering Case #630527)================
The ApproximateCPUTime property would have grown in value for blocked connections
if the property was queried. This problem was most noticeable for connections
that were blocked for long periods of time and for whom this property was
frequently queried. This has now been fixed.
================(Build #2442 - Engineering Case #630519)================
A query that referenced a view or derived table that contained a select list
item that was not a table column could have caused a crash when executing
using proxy tables. This has been fixed.
================(Build #2441 - Engineering Case #630359)================
The ASE label for the "GBK" character set has been changed from
"CP936" to "cp936", as character set names passed to
ASE APIs such as cs_locale() are case sensitive. The ASE version of character
set labels is generally not used directly by SQL Anywhere, but is provided
to users who need to use ASE libraries. Typically, a client would obtain
the ASE label via a call such as db_extended_property( 'charset', 'ase' ).
================(Build #2441 - Engineering Case #630210)================
If a GRANT or REVOKE statement was executed for a view which was currently
invalid (e.g. because it referenced a table that has been dropped), an error
indicating that the view was invalid might have been given. Now, the error
is suppressed, but the view is still marked as invalid.
================(Build #2441 - Engineering Case #629759)================
A query that made use of index only retrieval could have returned incorrect
results (too few rows) in some cases. This has been fixed.
================(Build #2441 - Engineering Case #620110)================
Under rare circumstances, a crashed database could have failed to recover
with the message:
"Unable to start specified database: Cannot use log file '%1' since
it is shorter than expected".
No data was actually been lost, but the log metadata would have needed to
be patched by hand to allow the database to recover. This problem, while
very rare, was more likely on systems with very large transactions running
on a small number of connections. This has been fixed.
================(Build #2439 - Engineering Case #629577)================
For Unix versions, the server's usage display included incorrect values in
the descriptions for the options -n, -p, -tl and -x. This has been fixed.
================(Build #2438 - Engineering Case #629417)================
If an application attempted to execute a Java external environment procedure,
and the target method was part of a class that had a private constructor,
then calling the Java external environment procedure would have failed with
an IllegalAccessException. This problem has now been fixed.
================(Build #2437 - Engineering Case #629153)================
If an application attempted to start an external environment session, and
other connections were being established, or were closing, at exactly the
same time, then there was a very small chance that the server could have
crashed. This problem has now been fixed.
================(Build #2436 - Engineering Case #629073)================
If a stored procedure or user-defined function contained a statement that
referenced a connection level variable (created with CREATE VARIABLE), then
it was possible for the statement to behave improperly if plan caching was
used by the server. The statement could have used the NULL SQL value for
the variable instead of giving an error if the variable were dropped, and
the statement could have used incorrect type information if the variable
was dropped and then recreated with a different data type. This has been
fixed.
================(Build #2436 - Engineering Case #628836)================
Shutting down a database could have caused an assertion failed error 104301
if a GRANT PROFILE had failed because the "diagnostics" user was
not a group. This has been fixed.
================(Build #2436 - Engineering Case #628735)================
A full text query with a non-alphanumeric character in a prefix string could
have caused a server crash. This has been fixed.
================(Build #2436 - Engineering Case #622875)================
If a procedure or function was simple enough that it was inlined during semantic
query transformations, and the procedure or function contained uses of a
parameter with a different case than the case in the declared parameter list,
then the statement could have failed with an error (column not found). In
versions 10.0.1 and 11, only simple procedures would have had this problem.
In version 12.0.0 (beta), simple user-defined functions could also have exposed
this problem. This has now been fixed.
================(Build #2435 - Engineering Case #628436)================
In extremely rare timing dependent cases, if a communication error occurred
on a mirror or diagnostic tracing server-to-server connection, the server
could have crashed, failed an assertion or hung. This has been fixed.
================(Build #2434 - Engineering Case #628304)================
If the MINIMUM TERM LENGTH setting of the text configuration used to build
a text index was changed to a value greater than 1, prefix terms in phrase
queries of full text search could have behaved differently depending on their
position in the phrase. This has been fixed.
================(Build #2431 - Engineering Case #627672)================
Running the VALIDATE INDEX statement would have committed any previously
uncommitted transactions. The VALIDATE INDEX statement no longer performs
a COMMIT on its connection.
================(Build #2430 - Engineering Case #627228)================
Under very rare circumstances the server could have crashed at startup while
updating the SYSHISTORY table. This has been fixed.
================(Build #2429 - Engineering Case #627054)================
If the system procedure sa_describe_query() was executed with null as the
query parameter then the server would have crashed. This has been fixed.
================(Build #2428 - Engineering Case #624586)================
The Validate Index statement would have placed an exclusive lock on the table,
preventing other connections from accessing the table. Alternatively, the
connection performing the validate could have blocked waiting for exclusive
access to the table. This has been changed so that Validate Index no longer
places an exclusive lock on the table.
================(Build #2427 - Engineering Case #626779)================
Some harddisk drivers on Windows and Linux are known not to execute drive
cache FLUSH commands when applications request them; however, all platforms
may be affected by similar issues. When the database server shuts down because
of a system shutdown, reboot or hibernate, the database server now delays
a short while (3 seconds) after the last I/O is performed to allow a little
bit of time for cached data in the drives to be written to the disk. On UNIX
platforms, shutting down the server via SIGTERM is assumed to be due to a
system shutdown or reboot.
================(Build #2427 - Engineering Case #626769)================
If old transaction log files on a primary server were deleted while the server
was running, subsequent BACKUP/RENAME operations would not have resulted
in the copies of these logs on the mirror server being deleted. This has
been fixed.
A workaround is to restart both servers and perform another BACKUP/RENAME.
================(Build #2427 - Engineering Case #626420)================
If the server executed a 'SET rowcount' statement with a host variable inside
a batch, then the server would have crashed. This has been fixed.
================(Build #2427 - Engineering Case #626255)================
If a statement in an event caused a deadlock or blocking error the first
time it was executed, an assertion error (107001 Duplicate table in UPDATE
statement) could have been given the next time the event was executed. Now
an "invalid statement" error is given in this case. A workaround
is to define the body of the event as a procedure and call the procedure
from the event.
================(Build #2427 - Engineering Case #625819)================
If checkpoints on a mirror server took a long time to complete, possibly
due to a large cache with many dirty pages, then applications performing
updates on the primary server could have been blocked until the checkpoint
completed. This has been fixed.
================(Build #2427 - Engineering Case #624989)================
Statements containing predicates of the form T.X = R.X where T.X and R.X
have different domains could have had poor performance due to a less than
optimal access plan generated by the optimizer. Such predicates were not
using a join histogram to estimate the selectivity of the predicate. This
has been fixed so that join histograms are now built as long as the domains
of the columns are both numeric data types. Numeric datatypes include the
following:
BIGINT
BIT
DECIMAL
DOUBLE
FLOAT
INTEGER
NUMERIC
REAL
SMALLINT
TINYINT
================(Build #2425 - Engineering Case #626295)================
If a remote query that involved GROUP BY was executed in no-passthrough mode,
and the server ran into a low memory situation, then there was a chance the
query would have failed with an "update operation attempted on non-updatable
remote query" error. This problem has now been fixed and the query will
now successfully complete without error.
Note that a workaround for this problem is to increase the amount of memory
that is available to the server.
================(Build #2425 - Engineering Case #626209)================
In very rare cases, the server may have crashed if a simple SELECT statement
that bypassed optimization used a BETWEEN predicate with a high value that
was not known until execution time. This has been fixed.
================(Build #2425 - Engineering Case #626151)================
If an application connected to an authenticated server made an external environment
call, and the call took more than 30 seconds to complete, then the application
would have hung. The check for ensuring that an external connection was properly
authenticated was incorrect, and has now been fixed.
================(Build #2424 - Engineering Case #626091)================
When SQLAnywhere reported the ASE label for the "Big5" character
set, it incorrectly reported "Big5". SQLAnywhere now reports "cp950"
as the ASE label for the Big5 character set. As far as SQL Anywhere and ICU
are concerned, these two character sets are distinct (but very similar),
but ASE makes no such distinction. The ASE version of the label is generally
not used directly by SQL Anywhere, but is provided to users who need to use
ASE libraries. Typically, a client would obtain the ASE label via a call
such as db_extended_property( 'charset', 'ase' ).
================(Build #2422 - Engineering Case #625493)================
If an application connected using a version of jConnect that did not support
bigtime, and the application subsequently prepared a statement that consisted
of a batch of insert and select statements, then there was a chance the server
would have incorrectly inserted a value of 00:00:00.0 for the time value
if one of the parameters to the insert was of type time. This problem has
now been fixed.
================(Build #2422 - Engineering Case #625353)================
Code that attempted to prevent a divide-by-zero condition may have caused
the server to crash. This has now been fixed.
================(Build #2422 - Engineering Case #624404)================
If an event made a call out to the Java external environment, then the Java
environment would have leaked memory with every iteration of the event. The
result would have been an eventual 'out of memory' exception from the Java
VM. This problem has now been fixed.
================(Build #2422 - Engineering Case #623281)================
Doing absolute fetches from a cursor would have slowed down after one or
more tables had been updated many times. Restarting the server would have
resolved the problem. This has been fixed.
================(Build #2420 - Engineering Case #625466)================
When run on a Windows 2008 Server (AMD64) machine, the Sybase Central fast
launcher could have failed to re-launch Sybase Central. This has been fixed.
================(Build #2420 - Engineering Case #624991)================
If a table was created with a primary key column declared as GLOBAL AUTOINCREMENT
when the global_database_id option was set to 0, a performance warning claiming
that the column was not indexed would have been written to the server console.
This has been fixed.
================(Build #2420 - Engineering Case #624974)================
Following the changes for Engineering case 621443, if an application made
an external environment call, and the external environment crashed during
that call, then there was a very rare chance the server would also have crashed.
This problem has now been fixed.
================(Build #2417 - Engineering Case #624183)================
As a result of the changes for Engineering case 585282, the maximum packet
size for Open Client and jConnect applications was increased from 512 bytes
to 4096 bytes. These changes have been extended to allow Open Client and
jConnect applications to now negotiate a maximum packet size of 16000 bytes.
================(Build #2417 - Engineering Case #624179)================
If an application executed an INSERT statement that contained a file name
with escaped single quotes as follows:
INSERT INTO directoryTab(file_name, contents) VALUES( 'he''l''lo.txt',
0x0 )
where directoryTab was a directory access table, then the resulting file
would incorrectly have been named "he'l'lo.txtxt", instead of the
expected name "he'l'lo.txt". This problem has now been fixed.
================(Build #2417 - Engineering Case #624047)================
Validating or unloading an empty table could have caused the server to fail
an assertion when the database had been started read-only. This would only
have happened if the table contained an index, and a truncate table had just
been done. This has been fixed.
================(Build #2417 - Engineering Case #623891)================
1) If:
- the on_tsql_error database option was set to 'conditional' or 'stop'
- the continue_after_raiserror database option was set to 'off'
- a RAISERROR statement was executed in a procedure with an exception handler
- the exception handler executed a RESIGNAL statement
then the procedure's caller would not have been able to obtain the error
code used in the RAISERROR statement by examining the SQLCODE variable. The
SQLCODE value would be -631 (SQLE_RAISERROR_STMT).
2) If:
- the on_tsql_error database option was set to 'conditional' or 'stop'
- the continue_after_raiserror database option was set to 'off'
- a RAISERROR statement was executed in a trigger with an exception handler
- the exception handler executed a RESIGNAL statement
then the error would not have been seen by the statement which caused the
trigger to fire.
This has been fixed. In case 1 above, the value of SQLCODE will now be the
error code used in the RAISERROR statement. In case 2, the error will now
not be suppressed by the trigger.
================(Build #2414 - Engineering Case #623769)================
If a TDS based application using a multi-byte character set, connected to
an SA database using a single-byte character set, subsequently fetched a
char(n) or varchar(n) value, and the char/varchar value resulted in greater
than n bytes when converted to the client's multi-byte character set, then
the client would have received an incomplete value. This problem has now
been fixed.
================(Build #2414 - Engineering Case #615617)================
If an application connected via jConnect attempted to retrieve the column
metadata of a result set that contained a varbit, long varbit, nchar, nvarchar
long nvarchar, or uniqueidentifier column, then the column metadata would
have been returned with an unknown datatype. This problem has now been fixed.
================(Build #2413 - Engineering Case #623432)================
The database server could have leaked memory in rare circumstances when strings
were being accessed concurrently. This has been fixed.
================(Build #2413 - Engineering Case #623292)================
The sa_get_request_times and sa_get_request_profile stored procedures did
not properly handle request logs created with a non-zero value for the max_client_statements_cached
database option when a connection executed the same statement more than once.
The number of uses and time used for such statements was reported incorrectly.
This has been fixed.
A workaround is to set max_client_statements_cached to 0 before creating
the request log. Note that if a request log is to be analyzed using the tracetime.pl
Perl script, it must also be generated with max_client_statements_cached
set to 0.
================(Build #2413 - Engineering Case #623270)================
The server would have crashed if a parallel archive backup was executed with
TRANSACTION LOG ONLY and TRANSACTION LOG RENAME clauses. This has been fixed.
================(Build #2413 - Engineering Case #621829)================
If an application attempted to insert data into a proxy table, and one of
the columns was an nchar based column, then there was a chance the data would
have been truncated. This problem has now been fixed.
Note, when creating proxy tables to Oracle tables that contain varchar2
columns, the Oracle ODBC driver does not provide enough information for SQL
Anywhere to correctly map the varchar2 columns to nvarchar columns. It is
therefore strongly recommended that an explicit column list be used when
creating proxy tables to Oracle tables containing varchar2 columns, and that
the explicit column list appropriately maps the varchar2 columns to nvarchar
columns.
================(Build #2413 - Engineering Case #620253)================
Permission checking for materialized views was being incorrectly done in
some cases, resulting in errors, for example: "Assertion Failed 102907
(11.0.1.xxxx) Could not generate triggers for immediately materialized view".
This has been fixed.
================(Build #2413 - Engineering Case #619911)================
Executing a query of the form:
SELECT ... FROM dirTab WHERE file_name='...'
where dirTab is a directory access table, then the server would have incorrectly
returned a result set in cases where the specified file_name extended beyond
the subdir limit of the directory access server. This problem has now been
fixed and a proper empty result set now gets returned for file names that
violate the subdir limit.
================(Build #2411 - Engineering Case #622021)================
Following the fix for Engineering case 588740, the server could have performed
slowly when deleting large numbers of rows concurrently. This has been fixed.
================(Build #2410 - Engineering Case #622552)================
A misconfigured SQL Anywhere webservice function may have caused the server
to crash when the function was executed. The problem was specific to a function
declaration (not a procedure) that was configured as TYPE 'HTTP:POST:<mimetype>'
(ie. mimetype = text/xml) that declares, but does not utilize, all substitution
parameters. This has been fixed.
The following illustrates the problem, note that the clause consuming the
substitution parameter is commented out:
create function bad_params(str long varchar, len int)
returns long varchar
url 'http://127.0.0.1/no_serv
================(Build #2410 - Engineering Case #622512)================
If an application was connected via jConnect 7 or Open Client 15.5, and the
application fetched a datetime value, then the fractional seconds portion
of the value would have been returned with six digits of precision; however,
fetching a timestamp value would still have returned 1/300th of a second
precision. This problem has been fixed and fetching either datetime or timestamp
values using jConnect 7 or Open Client 15.5 will now return the full six
digits of precision.
================(Build #2410 - Engineering Case #621822)================
A SQL Anywhere webservice client procedure may have truncated an HTTPS response
under certain circumstances. This has been fixed.
================(Build #2409 - Engineering Case #620795)================
The function count_set_bits may have returned a number that was too large,
if a bitwise NOT operation had previously been applied to the operand. This
has been fixed.
================(Build #2408 - Engineering Case #621827)================
Same machine TCPIP broadcasts did not work correctly on Mac OS 10.6. This
means that it may have been possible to start multiple database servers with
identical names on the same machine when using Mac OS 10.6. This has now
been fixed.
================(Build #2407 - Engineering Case #621665)================
If an application was connected via jConnect or Open Client, then the connection
name for that TDS based connection would have been empty. This has now been
fixed and the connection name for TDS based connections will now default
to the application name.
================(Build #2407 - Engineering Case #621652)================
If a server was asked to close a large number of connections that had at
some point in time made calls to an external Java environment, then there
was a chance the external Java VM would have leaked memory if all the connection
close requests occurred at the same time. This problem has now been fixed.
================(Build #2407 - Engineering Case #621636)================
If a call to an HTTP client procedure failed, the server could have leaked
memory. This has been fixed.
================(Build #2407 - Engineering Case #621443)================
If a server was asked to make a very large number of external environment
calls at the same time, then there was a small chance the server would become
unresponsive for 30 or more seconds. This problem has now been fixed.
================(Build #2407 - Engineering Case #621162)================
A SQL Anywhere 'RAW' web service having been defined with AUTHORIZATION ON,
would have failed to the service when it had an AS NULL statement. This
has been fixed.
Note, service types: HTML, XML, RAW, JSON may contain a NULL statement only
with AUTHORIZATION ON, DISH services always contain a NULL statement and
SOAP services must contain a (non-NULL) statement.
================(Build #2406 - Engineering Case #621121)================
If all of the following conditions were true, the result set for a procedure
would not have been defined properly after a rebuild:
- procedure P1 generates a result set using a SELECT which references
another procedure P2 in the FROM clause
- P1 did not include a RESULT clause defining the result set
- the procedure id of P1 was less than that for P2
This has been fixed.
================(Build #2406 - Engineering Case #621038)================
Executing an ALTER USER statement with LOGIN POLICY clauses, on a database
created with version 10.0.1 and not upgraded, could have caused a server
crash. This has been fixed.
================(Build #2405 - Engineering Case #627062)================
An INSERT ... ON EXISTING UPDATE DEFAULTS OFF statement did not update columns
defined with DEFAULT LAST USER. This has been fixed.
================(Build #2404 - Engineering Case #620474)================
If the primary server (S1) in a database mirroring environment was running
in a VM and the VM was paused or otherwise inactive for sufficient time that
the mirror server's connection to S1 was dropped, causing a failover to the
mirror (S2) , then when S1 was resumed it would not have realize that a failover
has occurred and would have continued to act as a primary. This has been
fixed.
================(Build #2402 - Engineering Case #620324)================
The server may have incorrectly set the transfer-encoding when processing
an HTTP request that failed with a SQL error. The problem may have occurred
when the SQL error was generated from within a sub-select. This has been
fixed.
================(Build #2402 - Engineering Case #619976)================
The server could have crashed when executing an aggregate function that operated
on string data when the Group By operator was forced into a low-memory strategy.
This has been fixed.
A workaround is to increase the amount of memory available to the server.
================(Build #2401 - Engineering Case #619950)================
The Unload utility (dbunload) was failing to add the length information for
VARBIT user domain definitions in the reload.sql file. This has been fixed.
================(Build #2401 - Engineering Case #619926)================
Stored procedures that contained simple queries over a single table (or the
implied DUMMY table), that were run many thousands of times by the same connection,
may have consumed more CPU after many thousands of executions. This problem
would only have occurred if the same connection executed the same queries
in a procedure more than 65000 times before disconnecting. This has been
fixed.
A workaround is to periodically issue an inconsequential DDL statement to
the server (for example, CREATE TABLE FOO(id int); DROP TABLE FOO). This
will flush the plan caches and allow each connection to use fully-cached
plans for these simple statements.
This issue had no impact on statements involving more than one table, or
on statements that are not subject to plan caching.
================(Build #2401 - Engineering Case #619746)================
IS NOT NULL predicates were incorrectly being generated for expressions which
cannot be null, that is for the null-supplying side of OUTER JOINs. These
extra predicates may have resulted in less than optimal access plans. This
has been fixed.
================(Build #2401 - Engineering Case #594568)================
Queries executed with a plan that involved parallel hash joins that caused
a run-time error (for example, a conversion error) could have occasionally
hung. This has been fixed.
A workaround is to disable parallel plans (i.e. set MAX_QUERY_TASKS = 1).
================(Build #2400 - Engineering Case #619190)================
A base table with publications was not allowed to be used in any parallel
access plan. This has been fixed. Now, a table with publications cannot
be used in a parallel plan of a statement if the table is updatable in that
statement, and it has publications.
================(Build #2400 - Engineering Case #619113)================
In very rare timing depended circumstances, the server may have crashed when
querying connection properties for a connection in the process of disconnecting.
This has been fixed.
================(Build #2399 - Engineering Case #619552)================
Queries that used indexed snapshot scans could have returned extra rows.
This has been fixed. See also Engineering case 612617.
================(Build #2399 - Engineering Case #619357)================
When an application attempted to make an external environment call, there
was a very small chance the server would have crashed if the external environment
for that connection shut down at exactly the same time as the application
made the external environment call. This problem has now been fixed.
================(Build #2399 - Engineering Case #617834)================
A query with a FULL OUTER JOIN without an ON condition must be interpreted
as a KEY FULL OUTER JOIN, but this was not the case. This has been fixed.
================(Build #2398 - Engineering Case #619597)================
Predicates of the form "(p11 and p12 and .. ) OR (p21 and p22 and ...
) OR ( ...)" can be used for multi-index partial scans if for each term
"(pi1 and pi2 and ... )" an intersection of indexes can be built.
The SQL Anywhere Optimizer failed to build an index scan for a term "(pi1
and pi2 and ... )" if all the predicates can be used in a single index
scan.
For example:
select * from T where (T.X = 10 and T.Y = 20 ) OR ( T.Z = 30 and T.W = 40)
create index XY on T(X, Y)
create index ZW on T(Z, W)
A possible access plan is the union of the index scans: T<XY> UNION
T<ZW>.
================(Build #2398 - Engineering Case #619596)================
Partial index scans covered by the same subset of predicates have now normalized
cardinality estimation during optimization. Before this change, it would
have been possible for partial index scan I1, covered by the predicates {p1,p2,
.. pn}, to have had an estimated cardinality greater than another partial
index scan I2 covered by a proper subset of predicates P of the set {p1,p2,
..., pn}. This has been fixed.
================(Build #2396 - Engineering Case #619558)================
When using the "Ja_JP" or "JA_JP" locales on AIX, SQL
Anywhere incorrectly determined that the OS character set was EUC-JP, whereas
AIX actually uses IBM-943 (a.k.a "Windows-31J" and "windows-932")
and UTF-8 respectively for those locales. The "ja_JP" locale on
all UNIX platforms uses EUC-JP. On AIX 4.2 and earlier, AIX used the IBM-932
character set for the Ja_JP locale. SQL Anywhere does not support AIX 4.2;
it does not support the IBM-932 character set which is significantly different
from the Windows-932 / Windows-31J character set; and it does not support
the "Ja_JP.IBM-932" locale that is available on currently supported
versions of AIX. This problem has been fixed.
================(Build #2396 - Engineering Case #619338)================
Attempting to execute a SELECT statement that referenced a stored procedure
in the FROM clause could have caused the server to crash. This has been fixed.
================(Build #2395 - Engineering Case #618804)================
If a LOAD TABLE ... WITH CONTENT LOGGING statement was executed in a database
mirroring environment, and the mirror server was then stopped, restarting
the mirror server may have failed with:
assertion 100904: failed to redo a database operation - Error: Table 'sa_load_table_data_X'
not found
This has been fixed.
Workarounds for this problem are to add WITH CHECKPOINT ON to the LOAD TABLE
statement (which makes the problem much less likely to occur, but does not
completely eliminate it), or to use WITH ROW LOGGING instead.
================(Build #2394 - Engineering Case #619128)================
The server could have failed an assertion, or returned a spurious error,
if a query used a keyset cursor or if a keyset cursor was implicitly used
in the processing of a DELETE or UPDATE statement. For this to have occurred
there must have been concurrent updates (with respect to the lifetime of
the keyset). This was most likely to have happened if a global share by
all temporary tables was involved. If no temporary tables were involved,
only DELETE statements were likely to cause issues. The error most likely
to be seen was 'unable to find in index'; assertions included 101412 and
200502 (among others). This has been fixed.
================(Build #2394 - Engineering Case #619055)================
If the OS/locale charset did not match the database charset, the contents
of the msg_database column in the result set from the sa_server_messages()
system procedure would have been mangled. This has now been fixed.
================(Build #2394 - Engineering Case #619054)================
If the execution of a DELETE statement involved remote tables, and the DELETE
statement could not be handled in full passthru, then the server could have
failed assertion 201501 "Page for requested record not a table page
or record not present on page". This problem has now been fixed, and
a proper error message is returned.
================(Build #2394 - Engineering Case #619040)================
On Windows systems, the -oe server command line option was ignored if -qi
or -qw were also specified. This has been fixed.
================(Build #2392 - Engineering Case #618257)================
In some cases, operations on long strings (blobs) could have leaked memory
in the main heap. This memory would not have been reclaimed until the server
was restarted. In order for this problem to have occurred, the blob must
have been at least 8 database pages long, and must have been accessed using
a random-access interface such as byte_substr() with a starting offset of
at least 3 times page size. This has been fixed.
================(Build #2392 - Engineering Case #617662)================
If an application connected to a case sensitive database executed a remote
query that contained a Group By clause, and one of the columns referenced
in the Group By had a different case than the column reference in the select
list, then the server would have incorrectly failed the query with error
-149 "Function or column reference must also appear in a GROUP BY."
For example, the following query would have failed:
SELECT test.Column1 FROM proxy_t test GROUP BY test.column1
whereas the following queries:
SELECT test.column1 FROM proxy_t test GROUP BY test.column1,
and
SELECT test.Column1 FROM proxy_t test GROUP BY test.Column1
would have succeed. This problem would only have occurred if the local database
was case sensitive and proxy_t was a proxy table. This has now been fixed.
================(Build #2391 - Engineering Case #618459)================
If a primary server (S1) was somehow frozen for long enough that its connections
exceeded the liveness timeout, and then exited the frozen state, the loss
of its connection to the mirror server would cause it to send a stale status
to the arbiter which should have been disregarded, but was not. Restarting
S1 would result in it attempting to become the primary server if a connection
to the second mirror server (S2) could not be made, yielding either two primary
servers or an alternate server name conflict. This has been fixed. Stale
state information will now be disregarded when received.
================(Build #2391 - Engineering Case #617619)================
If multiple backup statements for the same database were executed concurrently
with the WAIT BEFORE START option specified, and there was at least one connection
with uncommitted operations, the server could have appeared to hang or run
very slowly. This problem has been fixed.
================(Build #2391 - Engineering Case #616981)================
An ALTER VIEW statement that changed the view definition, would have silently
dropped any INSTEAD OF triggers on the view. This has been fixed so that
the server will now return the error "Operation failed because table
or view '%1' has an INSTEAD OF trigger".
================(Build #2388 - Engineering Case #617804)================
Attempting to execute an INSERT statement with the WITH AUTO NAME clause
could have caused the server to crash. This has been fixed.
================(Build #2387 - Engineering Case #617640)================
Use of a timestamp that had a number of seconds with more than 9 digits after
the decimal place could have yielded unexpected results.
For example:
select datepart( ms, '14:44:33.9876543211' )
would have returned 128, instead of the expected result of 987.
This has been fixed by truncating the number of seconds in a timestamp at
9 decimal places before it is used.
================(Build #2387 - Engineering Case #617165)================
INSTEAD OF triggers on views were not being unloaded by the Unload utility
(dbunload). This has been fixed.
================(Build #2386 - Engineering Case #617177)================
On Solaris SPARC systems, the 32-bit SQL Anywhere libraries were linked against
libC.so.5, the compatibility libC variant, even though the libraries were
not compiled in compatibility mode (i.e., -compat=4 was not used when compiling
the libaries). A C++ application that was not itself linked against libC.so.5
could have crashed when trying to load these libraries. The libraries are
no longer linked against libC.so.5 and now are only linked against libCrun.so.1.
C++ client applications compiled with the -compat=4 compatibility flag, or
linked against libC.so.5, are not supported.
================(Build #2386 - Engineering Case #612617)================
If the row containing a particular unique value changed from one row to another,
and then back again, snapshot transactions open before or during the updates
might not return a row when expected, or return two copies of the expected
row. This has now been corrected.
================(Build #2385 - Engineering Case #617219)================
If an application connected using Open Client 15.5, and then subsequently
attempted to fetch a Time or Timestamp value, then the fetch would have failed
with a protocol error. This problem has now been fixed.
Note that this problem does not affect versions of Open Client prior to
15.5.
================(Build #2385 - Engineering Case #617203)================
If an ABS() function call was used in a stored procedure, batch statement,
or simple SELECT, INSERT, or UPDATE statement, then it was possible for the
function to report an overflow error. For this to occur, the argument to
the ABS() function must have been a NUMERIC or DECIMAL argument with a precision
and scale different from the values specified by database options. This problem
has been fixed.
================(Build #2385 - Engineering Case #617161)================
An HTTP request requiring certain character set conversion criteria may have
caused the SQL Anywhere server to crash. This has been fixed.
================(Build #2385 - Engineering Case #615212)================
When computing an aggregate function such as AVG() or SUM(), it was possible
for the result of the calculation to overflow the bounds of the data type
used for accumulation, leading to an answer that was not numerically correct.
Even if the option Ansi_integer_overflow was set to 'On', the overflow was
not reported as an error. If AVG() or SUM() overflowed an INT type, then
the argument to the aggregate can be cast to DOUBLE or NUMERIC to avoid the
overflow (with a concomitant performance degradation). In specific conditions,
an arithmetic operation could have caused a server crash. This has been fixed.
================(Build #2384 - Engineering Case #616985)================
If an application attempted to fetch long string data from a proxy table,
and the ODBC driver being used to connect to the remote server did not support
UNICODE entry points, then there was a chance the fetched data would have
been missing some characters. This problem has now been fixed.
Note, there are very few ODBC drivers that do not support UNICODE entry
points. As a result, this problem affects a very small number of applications
that use remote servers.
================(Build #2383 - Engineering Case #616214)================
The server allows the LOAD TABLE statement to be executed in a mode where
the contents of the input file are recorded into the transaction log so that
the original data source is no longer needed in the event of the database
recovery. The logging of file contents in the transaction log can be triggered
explicitly, e.g., if the WITH CONTENT LOGGING clause is used, or implicitly
for certain forms of LOAD TABLE, e.g., when the USING CLIENT FILE clause
is used. The LOAD TABLE statement could have failed with an error when executed
from within a stored procedure if the user executing the procedure was different
from the login user for the connection. This has been fixed so that the server
now executes the LOAD TABLE statement correctly in these circumstances.
================(Build #2383 - Engineering Case #581580)================
The server may have crashed if a Transact SQL SELECT INTO statement referenced
an OPENSTRING expression. This has been fixed.
================(Build #2381 - Engineering Case #616395)================
The system procedure sa_split_list() did not work as expected when a multi-character
delimiter was provided, and the string to be split was shorter than the delimiter.
No rows were returned, whereas the expected result was a single row containing
the string to be split. This has been fixed.
================(Build #2380 - Engineering Case #616227)================
Connection attempts that used TLS would have failed with handshake failures
on 64-bit Mac clients. This has been fixed.
================(Build #2380 - Engineering Case #607651)================
In extremely rare circumstances, fetching a string from a table could have
caused the server to hang. This would only have occurred if the string was
longer than the prefix size of the column, but less than the page size of
the database, and a string manipulation function such as TRIM() was being
used, and another connection was attempting to update the string at the same
time. This has been fixed.
================(Build #2379 - Engineering Case #617613)================
If a table was locked by a connection using LOCK TABLE ... WITH HOLD IN EXCLUSIVE
MODE and then it was dropped without an intervening commit or rollback, there
was a chance that the server could have crashed when the connection disconnected.
This has been corrected.
================(Build #2379 - Engineering Case #615834)================
The REGEXP_SUBSTR function could have returned incorrect results when the
start-offset parameter was specified. In particular, regular expressions
with '^' (match start of string) may not have matched when they should have,
and lookbehind assertions may have matched when they should not have. Also,
specifying an invalid start-offset or occurrance-number, may have returned
a match when it should not have. This has been fixed so that the start-offset
specifies the beginning of the expression to match, and '^' will match the
beginning of the expression starting at start-offset.
================(Build #2378 - Engineering Case #615627)================
When using snapshot isolation, the Validate utility (dbvalid), or the "VALIDATE
DATABASE" statement, may have spuriously report the error "Database
validation failed for page xxxx of database file". These errors would
then have disappeared after a clean shutdown of the database. This has been
fixed.
================(Build #2378 - Engineering Case #615614)================
Dropping a login policy, or a synchronization profile, would not have also
deleted the corresponding row in the system table ISYSOBJECT. This has been
fixed.
================(Build #2378 - Engineering Case #615239)================
A web services stored procedure did not automatically process query parameters
for HTTP PUT and POST methods. This has been fixed.
Examples:
CREATE SERVICE echo ...
CREATE SERVICE echo_elem URL ELEMENTS ...
CREATE SERVICE echo_path URL ON ...
HTTP Requests:
PUT echo?id=1 HTTP/1.1 ==>
HTTP_VARIABLE('id') == 1,
HTTP_HEADER('@HTTPQUERYSTRING') == id=1
PUT echo_elem/one/two?id=1 HTTP/1.1 ==>
HTTP_VARIABLE('id') == 1,
HTTP_VARIABLE('url1') == one,
HTTP_VARIABLE('url2') == two,
HTTP_HEADER('@HTTPQUERYSTRING') == id=1
PUT echo_path/one/two?id=1 HTTP/1.1 ==>
HTTP_VARIABLE('id') == 1,
HTTP_VARIABLE('url') == one/two,
HTTP_HEADER('@HTTPQUERYSTRING') == id=1
================(Build #2378 - Engineering Case #613341)================
If an application that was connected using jConnect or Open Client, queried
the metadata of a long nvarchar, nvarchar, nchar, date or time column, then
the metadata returned by the server would have been incorrect. This problem
has now been resolved.
Note, in addition to getting an updated server, an ALTER DATABASE UPGRADE
must be execute on each database, to update the metadata for jConnect and
Open Client applications.
================(Build #2377 - Engineering Case #615447)================
Queries containing procedure calls in the FROM clause may have failed to
execute, or the procedure was not in-lined which may have resulted in very
poor performance. For this problem to have occurred, the procedure must have
contained common table expressions defined with the "WITH [RECURSIVE]
..." clause, and the procedure must have qualified to be in-lined into
the query block in which it was used. This has been fixed.
For more information on in-lining procedures see "SQL Anywhere 11.0.1
» SQL Anywhere Server - SQL Usage » Query Processing » Query optimization
and execution » Semantic query transformations » In-lining simple system
procedures "
http://dcx.sybase.com/index.html#1101en/dbusage_en11/ug-optimizer-s-4906935.html
================(Build #2377 - Engineering Case #615255)================
When run on Windows CE, the server may have reported an inaccurate reason
when a file error occurred. A server that was using the ICU library (dbicudtnn.dll)
could have reported a general I/O error if the database file did not exist.
A server that was not using ICU could report that a database file did not
exist error when a different file error occurred. This has been fixed.
================(Build #2376 - Engineering Case #614782)================
If the plan chosen for a query used a nested-loops outer join, and the cursor
was used with a mixture of forward and backward fetches, it was possible
for the server to return the wrong answer for the query. This has been fixed.
A possible work-around for the problem is to use an insensitive or keyset-driven
cursor type.
================(Build #2374 - Engineering Case #614405)================
The server could have have an assertion, or crashed, when reinserting a deleted
non-null value into a unique index. In rare cases, database corruption was
possible. System and temporary table indexes were not affected. This has
now been fixed.
================(Build #2373 - Engineering Case #614247)================
The server may have crashed after query optimization of a statement with
a parallel plan, for which the EXCHANGE physical operator must preserve the
ordering of the rows from the input stream, and a prefilter predicate exists
before the Exchange operator. This has been fixed.
For example, if the query below has the plan "p<xx> Exchange
p<xx>", the output of the Exchange operator must preserve the
ordering of the rows on "p.id" provided by the scans of the index
"xx". This query crashed the server before this fix. The prefilter
predicate is "now() > now()".
select * into #temp1 from product;
create index xx on #temp1(id);
select p.id from #temp1 p where now() > now() order by p.id;
================(Build #2373 - Engineering Case #613999)================
OEM Edition servers would have crashed when started with the -fips switch.
This has been fixed.
================(Build #2371 - Engineering Case #613816)================
If an application connects using an older version of jConnect or Open Client,
and subsequently fetches a Time or Timestamp value, then the server is required
to round the fractional seconds portion of the Time/Timestamp value up to
the nearest 1/300th of a second. For these older versions of jConnect or
Open Client, the server would not always have properly rounded the fractional
seconds portion up to the nearest 1/300th of a second. This problem has now
been fixed.
Note that newer versions of jConnect and Open Client support microsecond
precision, so no rounding to 1/300th of second will occur if an application
uses these newer versions.
================(Build #2371 - Engineering Case #613642)================
It was not possible to set an HTTP status that was not explicitly supported
(or known) by the SQLAnywhere server. This has now been fixed. Any three
digit status code with an optional colon (':') delimited text message may
now be specified.
Examples:
CALL SA_SET_HTTP_HEADER( '@HTTPSTATUS', '999:User Code'); // outputs status
code with message: '999 User Code'
CALL SA_SET_HTTP_HEADER( '@HTTPSTATUS', '999'); // output status code only
with no text message: '999'
Limitations/Recommendations:
- Status codes must be >= 100 and <= 999.
- A user defined status text message is not translated into database character-set
when logged (log protocol option).
- It is recommended that user defined status messages are in English.
HTTP status code/message additions:
305 Use Proxy
307 Temporary Redirect
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
505 HTTP Version Not Supported
================(Build #2371 - Engineering Case #605645)================
On rare occasions, the execution of a VALIDATE DATABASE statement could have
reported spurious orphaned page errors. This has been fixed.
================(Build #2370 - Engineering Case #613672)================
The server may have crashed during query optimization for a statement with
subqueries which were flattened (i.e., transformed into joins). At least
one of the subquery must have contained a DUMMY table and the main query
block must have required a DISTINCT to be done. This has been fixed.
An example:
select * from
product p
where exists (select 30 as id from dummy, product p2 where p2.id-1 >
30+p.id )
and p.id+1 = 301 and exists(select 1 from sales_order_items soi where soi.id
> p.id)
================(Build #2370 - Engineering Case #612409)================
When connected to a multi-byte character set database, if an application
attempted to create a proxy table to a remote table that had an underscore
in its name, then there was a chance the server would fail the request with
the error "the table specification '<location-string>' identifies
more than one remote table". This problem would only have occurred if
the remote had multiple tables whose names differed only by the character
in the underscore location. For example, if a remote had tables named tab_1
and tabx1, and if the application attempted to create a proxy table to map
to tab_1, then the server would give the "more than one remote table"
error. This problem has now been fixed.
================(Build #2368 - Engineering Case #612462)================
Queries that contained a subquery that was rewritten by semantic transformations
to flatten subqueries, could have failed with the error "Assertion failure
106104 (...) Field unexpected during compilation". This problem would
only have occurred if the query block that was being flattened had a subquery
in the SELECT list with outer references. This has now been fixed.
Note, a potential workaround is to modify the query so that it is no longer
suitable for the semantic transformation that flattens the query block.
================(Build #2367 - Engineering Case #612301)================
If an error (such as "disk full") was encountered while extending
a dbspace, it was possible that the dbspace would be corrupted. Subsequent
startups may have reported assertion failure 201129 (file is shorter than
expected), or one of several other assertion failures. This problem has been
fixed.
Note that the problem did not affect growth of the transaction log.
================(Build #2367 - Engineering Case #612269)================
The SQL Anywhere HTTP log did not allow a format option to specify the logging
of the client port used in an HTTP request. Both the client IP address and
port were required to demarcate the use of a specific connection within the
log when a client made several keep-alive HTTP connections. The LogFormat
protocol option has been changes sp that it now supports the "@J"
format-string code to specify logging of the client port. The following LogFormat
is recommended to include the logging of the client port since this will
be the default in future releases:
@T - @W - @I:@J - @P - "@M @U @V" - @R - @L - @E
================(Build #2367 - Engineering Case #612268)================
While rare, a CREATE VIEW statement could have caused a server crash. This
has been fixed.
================(Build #2366 - Engineering Case #612094)================
An incorrect response length may have been recorded in the SQLAnywhere HTTP
log for a long lived HTTP connection, such as a pipelined connection wacorrect,
subsequent response lengths were cumulative. The problem occurred when HTTP
logging was enabled and the @L LogFormat specified the logging of the response
length (default). This has now been fixed.
================(Build #2365 - Engineering Case #611611)================
If an application executed a query similar to the following:
select * from T where price * (1 - discount) > 500
and the table T was a remote table, then it was possible the query would
have returned the wrong result. This was due to fact that the Remote Data
Access layer sometimes failed to include the parenthesis when generating
queries to be executed on remote servers. This problem has now been fixed.
================(Build #2365 - Engineering Case #611227)================
The MESSAGE statement did not allow specifying the EVENT, SYSTEM LOG and
DEBUG ONLY clauses at the same time. This has now been corrected.
================(Build #2365 - Engineering Case #610948)================
Attempting to execute an ALTER TABLE statement that added a primary or foreign
key would have returned a Runtime SQL error (SQLCODE -300) if the option
row_counts had been turned on. The workaround is to temporarily turn the
option off. This has been fixed.
================(Build #2365 - Engineering Case #606991)================
Starting a database, which had been backed up on a Windows CE device, could
have caused "Assertion Failed: 201129 (version.build) File is shorter
than expected". This problem was introduced in Engineering case 576669.
This has now been fixed.
================(Build #2364 - Engineering Case #611184)================
Attempting to convert a string to a UUID when the string included braces
as the first and last characters, would have resulted in a conversion error.
This has been fixed.
================(Build #2364 - Engineering Case #575556)================
Executing queries with full outer joins or Transact SQL outer joins could
have caused the server to crash, or behave unexpectedly, if a CONTAINS clause
was present in the same query block as the join. This has been fixed.
Note, with Transact SQL outer joins, a CONTAINS clause is permitted only
in the WHERE clause, and can only reference the preserved side of the join,
not the null-supplying side.
================(Build #2363 - Engineering Case #611350)================
The server may have hung while generating a cache dump. This has been fixed.
================(Build #2363 - Engineering Case #610974)================
If a REFRESH MATERIALIZED VIEW staement was executed with the WITH ISOLATION
LEVEL SNAPSHOT clause, and database recovered was later attempted using the
transaction log, recovery would have failed when attempting to access the
view. This has been fixed.
================(Build #2363 - Engineering Case #610724)================
Problems with an LDAP server could have caused a SQL Anywhere server, or
a client application using it, to hang. Calls to the LDAP library were synchronous,
so if the LDAP server was hung and did not respond, the SA server would have
waited forever for a response. This has been fixed by making the LDAP library
calls asynchronous and adding a timeout.
================(Build #2363 - Engineering Case #610718)================
If an application executed an UPDATE statement, and the UPDATE statement
involved proxy tables, then the server may have crashed when the UPDATE statement
could not be handled in full passthrough mode. This problem has now been
fixed, and a proper error message is returned.
================(Build #2363 - Engineering Case #590098)================
A server crash could have occurred while running the Index Consultant. This
has been fixed.
================(Build #2362 - Engineering Case #610505)================
Attempting to renaming an index (or text index) to an invalid name, would
have resulted in unexpected behaviour of following statements related to
the index. This has been fixed.
================(Build #2362 - Engineering Case #610115)================
The database server was vulnerable to a particular type of denial-of-service
attack. This has been fixed.
================(Build #2361 - Engineering Case #609706)================
When running, the database cleaner could have interfered wth transactions
by causing locking attempts to fail. This has been fixed by having the requesting
transaction wait for the cleaner.
================(Build #2360 - Engineering Case #609953)================
The HTTP server may have crashed due to certain circumstances. This has
been fixed.
================(Build #2359 - Engineering Case #609310)================
The fix for Engineering case 570493, in very rare cases, could have caused
the server to hang with one CPU at 100% usage when shutting down a database
with many events. This has been fixed.
================(Build #2358 - Engineering Case #609049)================
Some server, database, or connection properties may have shown values that
were too large, or that have rolled over. This would only have happened on
single core machines running the Personal server (dbeng11) on Unix platforms
(but not Linux). This has been fixed.
================(Build #2358 - Engineering Case #605414)================
On very rare occasions, if the number of allowed connections was exceeded,
the HTTPS server may have sent the "Service temporarily unavailable"
503 response in plaintext. This has been fixed.
================(Build #2357 - Engineering Case #608904)================
Additional drive flushing was added to improve recoverability (see Engineering
case 588740); however, this flushing could have made the server significantly
slower when no transaction log was present due to every commit causing a
checkpoint. This performance issue has been addressed by reverting to the
old flushing behaviour when no transaction log is being used.
================(Build #2357 - Engineering Case #608552)================
In rare cases, the executing the ATTACH TRACING statement could have caused
the server to crash. This has been fixed.
================(Build #2356 - Engineering Case #608342)================
A server participating in a mirroring system may, on rare occasions, have
crashed if an
outgoing connection to another server participating in the mirroring system
failed. This has now been fixed.
================(Build #2355 - Engineering Case #608339)================
On 11.0.1, builds 2309 through 2312 inclusive contained the fix for Engineering
case 588740; however, builds 2313 through 2354 inclusive accidentally reverted
back to the old behaviour. This regression has been fixed.
Note, testing has shown that the new correct behaviour can cause a significant
performance degradation for server running databases without a transaction
log (where every commit becomes a checkpoint). The amount of degradation
will depend on the application, and on the hardware in use.
================(Build #2355 - Engineering Case #606227)================
When running running on HPUX, Solaris or AIX systems, it was possible for
the server to
crash while receiving IPv6 traffic. This has been fixed.
================(Build #2354 - Engineering Case #606651)================
The creation of a proxy procedure for a procedure on a remote server may
have caused a server crash, or failed assertion 201503, if a proxy procedure
with the same name had been dropped as part of the execution of a DROP REMOTE
SERVER statement. This has now been fixed.
A work around for the problem is to drop all proxy procedures belonging
to a remote server before executing the DROP REMOTE SERVER statement.
================(Build #2353 - Engineering Case #596656)================
If an application made an external environment call, and the external environment
procedure subsequently made a server-side call that required acquiring a
lock that was already held by the connection making the external environment
call, then there was a chance the application would hang. This problem has
now been fixed.
================(Build #2352 - Engineering Case #607425)================
The number of nullable columns in a table is limited. This limitation is
based on the page size of the database. For 4K pages, the limit is approximately
32000 columns. Attempting to add too many nullable columns to a table using
ALTER TABLE would have resulted in a failed assertion, rather than an error
message. This has been fixed.
================(Build #2352 - Engineering Case #607234)================
The SQL Anywhere Python database interface, now works with Python 3.x.
================(Build #2350 - Engineering Case #606858)================
A possible, but unlikely, security hole involving secure communications on
MacOS systems has been fixed.
================(Build #2350 - Engineering Case #606835)================
The reason reported by the server for failing to start a database may have
been incorrect. When attempting to open a file, the server will retry on
certain errors. If it retries too many times it just reports 'database not
found'. This behaviour was much more likely with the changes for Engineering
case 605413, as sharing violations were now retried. This behaviour has now
been changed so that the server reports the last OS error when it fails to
open the database file.
================(Build #2349 - Engineering Case #606464)================
Queries with null-supplying derived tables, which have constants in the select
list, may have failed with "Run time SQL error -- *** ERROR *** Assertion
failed: 106105". This has been fixed.
================(Build #2347 - Engineering Case #605433)================
If an application attempted to execute an UPDATE statement that updated a
local table, but had a subquery in the SET clause that accessed a proxy table,
then the server would have crashed. This problem has now been fixed.
================(Build #2346 - Engineering Case #606038)================
If an application attempted to create a proxy table to a Micosoft SQL Server
table that contained a varchar(max) or nvarchar(max) column, then the server
would have incorrectly mapped the varchar(max) columns to varchar(1) and
the nvarchar(max) columns to nvarchar(1). This problem has now been fixed
and the server now correctly maps varchar(max) columns to long varchar and
nvarchar(max) columns to long nvarchar.
================(Build #2346 - Engineering Case #595999)================
With versions of the server that included the changes made for Engineering
case 555808, queries with a recursive union could have failed to match rows
on the recursive passes. Although there was nothing wrong with the fix itself,
the changes exposed the underlying problem, which has now been fixed.
A workaround is to drop indexes on the table(s) being queried recursively,
although there may a performance implications to doing this, which could
be significant.
================(Build #2344 - Engineering Case #605653)================
If a REORGANIZE TABLE statement failed due to the table having been locked,
then subsequent attempts to execute a REORGANIZE TABLE syatement would have
also failed. The error would have been that a reorgorganize was already
in progress. This has been fixed.
================(Build #2343 - Engineering Case #605413)================
If the server attempted to open a database file concurrently with antivirus
software, the database could have failed to start, or the server could have
failed with an assertion error. This has been fixed by adding a retry for
sharing violations on a file open.
================(Build #2343 - Engineering Case #605393)================
The value being maintained for the CacheFree property was not as documented
and was of limited use. The value now returned is the number of cache images
that contain no useful data. The values for the properties CacheFree+CachePinned+CacheFile
should give the current cache size (i.e. number of images currently in the
cache). The values for the properties CacheFile+CacheFree should give an
upper bound on the number of pages immediately available for reuse (without
resorting to growing the cache).
================(Build #2343 - Engineering Case #596419)================
When autostarting a database, database-specific options (such as -ds) which
had values containing quotation marks were not handled correctly. For example,
the following would not have worked correctly:
dbisqlc -c "dbf=my.db;dbs=\"d:\tmp\spacey path\""
This problem has now been corrected.
Note that using quotation marks on the command line to start a database
server worked correctly:
dbeng11 my.db -ds "d:\tmp\spacey path"
A related problem was found and fixed in dbisqlc which handled the START
DATABASE statement itself, and constructed a connection string containing
a "dbs=-ds ..." parameter, rather than passing the START DATABASE
statement to the server. Dbisqlc was not putting quotes around a -ds parameter
that contained spaces.
================(Build #2342 - Engineering Case #605039)================
When using using the "-im nw" command line option (in-memory, no-write
mode ), the server does not use a temporary file for the database; however,
sa_disk_free_space() was returning a row for the temporary dbspace. This
has been fixed.
================(Build #2341 - Engineering Case #594711)================
The cardinality estimation of an index having more than one sargable equality
predicate on a prefix column could have been incorrectly set to 0%. At least
one of the sargable predicates must have been an equality with a constant
and at least one of the sargable predicates must have been an equality with
a non-constant expression. This has been fixed.
For example:
There exists an index on T <X,Y>: create index T_xy on T (X,Y)
Select * from
T, R where T.X = 1 and T.X = R.X and T.Y > 10
================(Build #2341 - Engineering Case #587856)================
An application that was connected via jConnect or Open Client, that attempted
to insert or retrieve a date value prior to January 1,1753, would have been
incorrectly received an invalid date value error for the insert, and would
have been returned the date January 1, 1753 for the fetch. This problem has
now been fixed. Note that application must use newer versions of jConnect
or Open Client in order to get date support for dates prior to January 1,
1753. Also, the restriction of January 1, 1753 using jConnect or Open Client
still exists for datetime values.
================(Build #2338 - Engineering Case #596021)================
Database recovery using in-memory mode would have failed with assertion 201865.
The database must have had multiple dbspaces for this assertion to have occurred.
This has been fixed.
A workaround is to recover without in-memory mode, but thist will cause
the database on disk to be modified.
================(Build #2335 - Engineering Case #595699)================
In very rare cases, the Windows and Linux server may have hung and stopped
processing requests if request level logging was turned on. This has been
fixed.
================(Build #2335 - Engineering Case #595504)================
If an authenticated application connected to an authenticated database and
executed an external environment call, then there was a chance the external
call would fail with an authentication violation error. This problem has
now been fixed.
================(Build #2335 - Engineering Case #594929)================
If an application called a CLR stored procedure at exactly the same time
that another connection or event that made a CLR stored procedure call terminated,
then there was a small chance the server would have incorrectly returned
a thread deadlock error instead of completing the CLR call. This problem
has now been fixed.
================(Build #2335 - Engineering Case #583560)================
If an application that was connected to a local server, either via the SQL
Anywhere ODBC driver or the iAnywhere JDBC driver, attempted to perform a
wide or batched insert into a proxy table and the insert subsequently returned
with a conversion or some other error part-way through the insert, then the
rows leading up to the error would have been inserted into the proxy table
twice. This problem has now been fixed.
================(Build #2334 - Engineering Case #593472)================
If a subquery contained an equality predicate with an outer reference, and
the left and right expressions of the equality predicate had different domains,
then the computed result set may have been incorrect. The equality predicate
must have been of the form "local column = outer reference column".
This problem has now been fixed.
For example:
select * from R, S
where R.X NOT IN ( select T.X from T where T.N = S.I)
where the column T.N is of type numeric and the column S.I is of type integer.
================(Build #2334 - Engineering Case #593334)================
The error "Fatal error: Could not write to file" could have been
returned from the server when attempting to write to a file in a clustered
environment. While the clustering service was performing some tasks, it
was possible that the database server would be given an error ERROR_NOT_READY
when attempting to perform an operation on the file. The server now retries
the operation several times in this circumstance.
================(Build #2334 - Engineering Case #592887)================
Some database corruptions could have caused the cleaner to attempt to reference
pages beyond the end of the database. This situation is now caught, and the
server will halt with assertion failure 201301.
================(Build #2334 - Engineering Case #591546)================
When the server executed a CREATE VIEW statement, and the view's SELECT statement
referenced a materialized view that was not yet initialized, the statement
would have failed with the error "Cannot use materialized view 'viewname'
because
it has not yet been initialized". The script generated by dbunload
-n could have failed trying to recompile views. This has been fixed.
================(Build #2333 - Engineering Case #594916)================
In some circumstances, the server may have failed to recover a database with
assertion failure 201135 - "page freed twice". Some newly allocated
database pages were not being initialized. This has been fixed.
================(Build #2332 - Engineering Case #594528)================
In very rare situations, the server could have failed assertion 104908 at
shutdown. This has been fixed.
================(Build #2332 - Engineering Case #594492)================
In rare cases, a database mirroring server could have crashed at shutdown.
This has been fixed.
================(Build #2332 - Engineering Case #594470)================
Attempting to call the system procedure sa_performance_statistics(), could
have resulted in the failure of assertion 109510 on machines with many CPUs.
This has been fixed.
================(Build #2331 - Engineering Case #594121)================
The value of property('StartTime') could have been returned as NULL if used
in an event that was fired immediately after the server was started. This
has been fixed.
================(Build #2331 - Engineering Case #593273)================
The server could have crash when attempting to execute a statement having
a WHERE clause with a disjunction on sargable predicates, such that each
predicate can be used for a partial index scan. This has been fixed.
For example:
select * from R left outer join T where R.X = 10 OR R.Y = T.Y
Both "R.X = 10" and "R.Y = T.Y" are sargable. An index
must exist for on R<X> and R<Y>.
================(Build #2329 - Engineering Case #592860)================
On Unix systems, starting the server as a daemon could have hung if a fatal
error occurred while starting up. This included Linux Standalone and Network
services installed with the Service utility (dbsvc) as 'automatic on startup'.
This has been fixed.
================(Build #2329 - Engineering Case #591301)================
The server may have returned too many result rows if the query contained
a DETWEEN predicate with constants, and a parallel index-only scan was used.
This has been fixed.
================(Build #2328 - Engineering Case #593329)================
When a database was run on a server started in "in-memory" mode
(-im connand line option), and a checkpoint was performed during recovery,
the server could have hung on shutdown. This has been fixed.
================(Build #2328 - Engineering Case #593135)================
The server could have become deadlocked soon after starting a database. For
this to have occurred, the database in question must have had a large dbspace,
which must have been rapidly growing, and recent inserts and updates must
either have failed, or have been undone by another transaction. This problem
has now been fixed.
================(Build #2328 - Engineering Case #593118)================
Only users with DBA authority should be able to reset a login policy, even
if it is for themselves. The server was failing to check for this permission.
This has been fixed. The server now ensures that only users with DBA authority
can reset a login policy.
================(Build #2328 - Engineering Case #592589)================
Some computed bitstring values (i.e. those produced as a result of a set_bit,
&, |, ^ or ~) might not have hashed properly. Operations that can hash
bitstring values during their execution (for example, select distinct of
a bit column) could have returned incorrect results. This has been fixed,
but existing tables containing affected values will require an unload/reload.
Alternatively, if c is an affected column in table t, "update t set
c = ~c" can be run twice with a server containing the fix.
================(Build #2328 - Engineering Case #576709)================
A mirror transaction log file could have become corrupted after the file
was grown. The error received would have been "Error: Cannot open transaction
log file -- <mirror file name> is an invalid transaction log mirror."
The server was failing to update the mirror log file size at the appropriate
time. This has been fixed.
================(Build #2327 - Engineering Case #592981)================
Generating SQL procedures using the iAnywhere WSDL compiler (WSDLC) may have
failed if the target WSDL (Web Services Description Language) contained an
operation with a message referencing a complex fault type. This has been
fixed. Generating fault stubs for WSDLC -l sql ... is not supported. The
fault message type is now ignored and the SQL for the SOAP procedure is generated
as expected.
================(Build #2324 - Engineering Case #592912)================
In some cases, the database server was not able to fully recover from a crash,
and displayed an assertion failure message. The server console would have
shown that the server was able to recover the database, and a checkpoint
was completed successfully, but then assertion failure 100920 was displayed:
"Transaction log page X is corrupted." This problem has now been
fixed.
================(Build #2323 - Engineering Case #592425)================
When the server starts, the port numbers on which the server is listening
are displayed on the console, but only if they were not supplied on the command
line (using the -x tcpip(port=xxx) switch). This has been fixed - the port
numbers are now always displayed.
================(Build #2323 - Engineering Case #582778)================
Calling the system procedure sa_get_histogram(), which is used to obtain
the current state of a histogram on a specified column, could have caused
the server to deadlock. The probability of such a deadlock taking place was
extremely low and depended upon a number of factors. This problem has now
been resolved.
================(Build #2322 - Engineering Case #590692)================
The server may have modified the wrong table when executing an UPDATE or
DELETE on a view, if the view was specified in the FROM table-list as well.
This has been fixed.
================(Build #2320 - Engineering Case #591275)================
The JDBC based Remote Data Access classes are generally not recommended due
to their higher resource requirements and significantly lower performance,
when compared to the ODBC based Remote Data Access classes. However, for
those applications where an ODBC based Remote Data Access class is not an
option, improvements have now been made to increase the performance of fetching
results from a remote server using a JDBC based Remote Data Access class.
Nevertheless, even with these performance improvements, the recommendation
is still to use ODBC based Remote Data Access classes instead of the JDBC
based classes whenever possible.
================(Build #2320 - Engineering Case #581050)================
Under certain circumstance, execution of a MERGE statement could have caused
the server to raise assertion 100905 ("Articles on the table use do
not match those on the table"). The server will now execute the statement
correctly.
================(Build #2319 - Engineering Case #581709)================
During optimization process, the SQL Anywhere Optimizer optimizes subqueries
by considering different alternative strategies for computing the result
of the subquery. During othis process, the optimizer doesn't perform any
transformations which correspond to each alternative subquery strategies.
Instead, the estimated costs of different strategies are used to decide which
execution technique will be executed for this SQL statement in the final
access plan. The final best access plan is built to reflect the execution
strategy chosen for the subquery. In certain cases, when WINDOW subquery
strategy was chosen (see Strategy 4 and Strategy 5 below) the final best
access plan was missing the rowid expression of the table pushed into the
derived table (in the example below, the rowid of the table "sales_order_items
soi" from the main query block). This has been fixed.
For example:
The subquery optimization process supported by the SQL Anywhere Optimizer
since version 9.0, is described in the patent [1]. The example below illustrates
the five execution strategies considered during the optimization process
for a SQL statement using a grouped subquery. This issue is related to a
bug introduced in version 10.0.0 when two rowids must be built for each base
table to support Snapshot isolation. The bug would have manifest itself if
and only if Window Strategy 4 or Window Strategy 5 was chosen in the best
access plan.
[1] System and Methodology for Cost-based Subquery Optimization Using a
Left Deep Tree Join Enumeration Algorithm", Anisoara Nica, US Patent
20040220923, awarded August 2009
Original query Q0:
SELECT so.id, so.order_date, p.*
FROM sales_order so, sales_order_items soi, product p
WHERE
so.id = soi.id
AND soi.prod_id = p.id
AND p.quantity = (SELECT max(soi1.quantity) FROM sales_order_items soi1
WHERE soi1.prod_id = p.id )
SQL Anywhere Optimizer subquery execution strategy 1, Q1, evaluate subquery
as an expression:
SELECT so.id, so.order_date, p.*
FROM sales_order so, sales_order_items soi, product p
WHERE
so.id = soi.id
AND soi.prod_id = p.id
AND p.quantity = (SELECT max(soi1.quantity) FROM sales_order_items soi1
WHERE soi1.prod_id = p.id )
SQL Anywhere Optimizer subquery execution strategy 2, Q2, evaluate subquery
as an uncorrelated derived table:
SELECT so.id, so.order_date, p.*
FROM sales_order so, sales_order_items soi, product p,
(SELECT max(soi1.quantity), soi1.prod_id FROM sales_order_items soi1 GROUP
BY soi1.prod_id ) as DT2 (max, prod_id)
WHERE
so.id = soi.id
AND soi.prod_id = p.id
AND p.quantity = DT2.max AND p.id = DT2.prod_id
SQL Anywhere Optimizer subquery execution strategy 3, Q3, evaluate subquery
as a derived table with Bloom-filter predicates:
SELECT so.id, so.order_date, p.*
FROM sales_order so, sales_order_items soi, product p,
(SELECT max(soi1.quantity), soi1.prod_id FROM sales_order_items soi1 WHERE
soi1.prod_id IN Bloom-filter( p.id) GROUP BY soi1.prod_id ) as DT3 (max,
prod_id)
WHERE
so.id = soi.id
AND soi.prod_id = p.id
AND p.quantity = DT3.max AND p.id = DT3.prod_id
SQL Anywhere Optimizer subquery execution strategy 4, Q4, evaluate subquery
as an uncorrelated derived table with WINDOW functions:
SELECT so.id, so.order_date, p.*
FROM sales_order so, product p, //// <<-- NOTE that "sales_order_items
soi" was moved inside to the DT4
(SELECT max(soi1.quantity) OVER (PARTITION BY soi1.prod_id ), soi1.prod_id,
soi1.id FROM sales_order_items soi1 ) as DT4 (max, prod_id, id)
WHERE
so.id = DT4.id
AND DT4.prod_id = p.id
AND p.quantity = DT4.max AND p.id = DT4.prod_id
SQL Anywhere Optimizer subquery execution strategy 5, Q5, evaluate subquery
as a derived table with WINDOW functions, with Bloom-filter predicates:
SELECT so.id, so.order_date, p.*
FROM sales_order so, product p, //// <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<------------------------------------------NOTE
that "sales_order_items soi" was moved inside to the DT5
(SELECT max(soi1.quantity) OVER (PARTITION BY soi1.prod_id ), soi1.prod_id,
soi1.id WHERE soi1.prod_id IN Bloom-filter( p.id) FROM sales_order_items
soi1 ) as DT5 (max, prod_id, id)
WHERE
so.id = DT5.id
AND DT5.prod_id = p.id
AND p.quantity = DT5.max AND p.id = DT5.prod_id
================(Build #2318 - Engineering Case #591061)================
If a database had a partial write to the checkpoint log, then it was possible
that database recovery could have failed in a case which was actually recoverable.
This only affected encrypted databases. This has now been fixed.
================(Build #2318 - Engineering Case #591001)================
In very rare circumstances, the server may have crashed when it should have
returned the sql error SQLSTATE_SYNTACTIC_LIMIT. This may have occurred when
loading very compley view definitions, or executing a SELECT INTO into table
statement. This has been fixed.
================(Build #2317 - Engineering Case #590215)================
Database corruption was possible in certain rare circumstances. This has
been fixed.
================(Build #2317 - Engineering Case #589848)================
SQL Anywhere server could have generated a spurious "cardinality violation"
error when executing the MERGE statement if the statement being executed
did not contain any WHEN MATCHED clauses, or none of the specified WHEN MATCHED
clauses were unconditional, and there were at least two rows in the input
data set that matched a single target row and don't qualify for any of the
WHEN MATCHED clauses. This has been corrected so that the server will now
silently ignore these duplicate rows instead of generating a cardinality
violation error.
================(Build #2317 - Engineering Case #587671)================
The server may have crashed when trying to find matching materialized view
candidates. This would have happened when a materialized view candidate had
a very complex SELECT clause, and the server was close to stack overflow
or had too little cache space. This has been fixed.
================(Build #2316 - Engineering Case #590569)================
Only users with DBA authority should be able to execute COMMENT ON DBSPACE
statements, but the server was failing to check for this permission. This
has been fixed. The server now ensures that the user has DBA authority before
executing a COMMENT ON DBSPACE statement.
================(Build #2316 - Engineering Case #590401)================
If an application used a JDBC based Remote Data Access class, and the application
subsequently changed the setting for quoted_identifier or ansinull, then
the new setting would not get sent to the remote server. This problem has
now been fixed.
================(Build #2316 - Engineering Case #590156)================
The server may have incorrectly rewritten WHERE, ON, or HAVING clauses, causing
no rows, or too few rows, to be returned. This would have happened when the
server found redundant conjuncts and try to remove them. This has been fixed.
A sample of this type of query:
select 1 from T
where a = 1 and ( b = 2 or c = 8 ) and ( d = 4 or e = 10 )
and ( a = 1 or e = 7 or c = 9 )
================(Build #2316 - Engineering Case #590041)================
If query optimization with matching materialized views generated an error
while processing a materialized view candidate, the error was still returned
to the application. For example, if a materialized view candidate contained
additional tables for which the user did not have SELECT permissions, the
error "Permission denied: you do not have permission to select from
"tablename" would have been returned. This has been fixed. Now,
if an error is encountered while processing a materialized view candidate,
the error is ignored and the view is not used in the view matching process.
================(Build #2315 - Engineering Case #590020)================
When run on Unix systems, queries of the form "SELECT ... FROM directory_access_table
WHERE file_name=...", where directory_access_table was a proxy table
to a directory access server, would have returned an empty result set. This
problem would only have occurred if the server had been updated to include
the fix for Engineering case 569934. This problem has now been fixed and
the server will now properly return a result set.
================(Build #2314 - Engineering Case #589821)================
If the remainder() function was used with DECIMAL arguments and the value
of the second argument was zero, then NULL would have been returned and an
error was not generated when the divide_by_zero_error option was set to On
(the default value). This has been fixed.
================(Build #2314 - Engineering Case #589802)================
Applications would have been able to connect to a database using the database's
alternate server name, and then create, stop, and drop other databases on
the same server. This has been fixed, all of these operations are now disallowed
when connected through an alternate server name.
================(Build #2314 - Engineering Case #589646)================
The number of bytes required to store a bitstring column value could have
been under reported. This could then have potentially caused buffer overruns
in client applications. This has been fixed so that the correct byte suze
is now reported.
================(Build #2314 - Engineering Case #584486)================
Unloading a SELECT statement into a compressed variable could have caused
a server crash. This has been fixed.
================(Build #2314 - Engineering Case #581747)================
If a statement of the form "SELECT columns FROM table WHERE index_col
= value" was opened more than once by a connection, an OPEN or CLOSE
request could have failed with one of the following errors: "Cursor
already open", "Cursor has not been declared", or "Cursor
not open". The statement must have only involved one table, and the
where clause must have had one or more predicates of the form col = value
which can all be satisfied by one index. This has been fixed.
================(Build #2313 - Engineering Case #588924)================
If a timestamp column was defined with "not null default [utc] timestamp",
and an insert specified a null value for that column, then the insert would
have failed with a SQL error. In version 9 and earlier, the insert used the
default instead and did not fail. This behaviour has now been restored.
================(Build #2313 - Engineering Case #588720)================
If an application started Java, then subsequent connections to the server
may have found that the option settings for date_format, time_format, timestamp_format
and date_order were different than expected. This problem has now been fixed.
================(Build #2311 - Engineering Case #589406)================
Creating a text configuration object, or creating a text index from a text
configuration, did not qualify object names when they were logged in the
transaction log. This has now been corrected.
================(Build #2310 - Engineering Case #589219)================
If many connections attempted to make CLR external environment calls simultaneously,
then there was a chance that some of the requests would have failed with
a strange unhandled exception error. These unhandled exception errors would
come from the CLR external environment, and not from the server itself. This
problem has now been fixed.
================(Build #2310 - Engineering Case #588921)================
If an application attempted to query a non-nullable bigint column from a
proxy table, and the remote server class was asejdbc, then the request would
have failed with a strange conversion error. This problem has now been fixed.
================(Build #2310 - Engineering Case #588692)================
On Unix systems, if the transaction log for a primary server was not located
in
the server's current working directory, and was renamed when the mirror
server was unavailable and the primary server was restarted, synchronization
would have failed when the mirror server then became available again. This
has been fixed.
================(Build #2310 - Engineering Case #588499)================
The server would have stopped the TCP listener and printed the message "TCP
Listener shutting down (130)" to the console log, if it has accepted
a new client connection but the client side has already gone. This has been
fixed.
================(Build #2309 - Engineering Case #588740)================
We learned that in the interest of improved performance, Microsoft Windows
explicitly prevents certain documented methods of guaranteeing that data
has been written to the physical storage medium from working on IDE/SATA/ATAPI
drives (SCSI drives are unaffected). Recoverability after a power outage
could be compromised. The database server now performs additional operations
to flush data to disk to improve recoverability. In testing, there was no
measurable performance degradation by this change.
Relevant third-party articles:
http://perspectives.mvdirona.com/2008/04/17/DisksLiesAndDamnDisks.aspx
http://msdn.microsoft.com/en-us/library/dd979523%28VS.85%29.aspx
http://research.microsoft.com/apps/pubs/default.aspx?id=70554
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/browse_frm/
thread/4590ed3a4133828f/406cfb3a9deae044
================(Build #2309 - Engineering Case #588539)================
If an application attempted to access a JDBC based Remote Data Access server,
and the tsql_variables option was set to ON, then the server would have failed
the request with a syntax error. This problem has now been fixed.
================(Build #2309 - Engineering Case #588498)================
If a server attempted to abandon or cancel a request to start an external
environment, due to the server being extremely busy or overloaded, then there
was a very small chance the server would have hung. This problem has now
been fixed.
================(Build #2309 - Engineering Case #588497)================
Execution of the MERGE statement within SQL Anywhere could have caused the
server to crash under some specific circumstances. This problem has now been
resolved.
================(Build #2309 - Engineering Case #588329)================
If an application connected via jConnect used the method CallableStatement
to execute a stored procedure, then there was a chance the connection would
have terminated with a protocol error. This problem would only have occurred
if the stored procedure had an argument named @p# where # was an integer
between 0 and n-1 with n representing the number of arguments in the stored
procedure. For example, if an application connected via jConnect used CallableStatement
to execute a stored procedure named test, and if test had 3 arguments, and
if one of the arguments in test was named @p0, @p1 or @p2, then the server
would have dropped the connection with a protocol error. This problem has
now been fixed.
It should be noted that this problem does not affect applications using
the iAnywhere JDBC driver.
================(Build #2308 - Engineering Case #588076)================
If a proxy table existed in a case-sensitive database, and the proxy table
had an index on it, unloading and reloading the database would have failed
with the error "Cannot create item (<index_name>) in the specified
dbspace". This has been fixed.
================(Build #2308 - Engineering Case #588055)================
When running the CREATE ENCRYPTED/DECRYPTED DATABASE '<newdb>' FROM
'<sourcedb>' statement, if the transaction or mirror log name stored
in the source database file was unqualified, we would have tried to locate
it with respect to the engine's current working directory rather than the
location of the database file.
For example, if the engine was running in the directory /foo, the statement
CREATE ENCRYPTED DATABASE 'new.db' FROM '/bar/source.db' was issued, and
the transaction log name stored in source.db was 'source.log,' we would have
tried to open /foo/source.log.
If the current working directory had a version of the log file that was
incompatible with the source database, the operation would fail. This has
been fixed.
================(Build #2307 - Engineering Case #587888)================
Previously, if an application connected to a Web Edition server and attempted
to make use of a directory access server, the Web Edition server would fail
the request with a "this server is not licensed to support the 'Remote
Data Access' feature" error. This problem has now been fixed. Note that
attempting to make use of other remote data access server classes will still
give the "not licensed" error when the application is connected
to a Web Edition server.
================(Build #2307 - Engineering Case #587873)================
If an application made a CLR external environment call and then subsequently
cancelled the CLR request, there was a chance that the CLR external environment
would crash. This problem has now been fixed.
================(Build #2307 - Engineering Case #587795)================
Updates or deletes to temporary tables may have caused the engine to crash
if the temporary file had corrupted pages. This has been fixed.
================(Build #2307 - Engineering Case #586829)================
UPDATE and DELETE statements could have acquired intent locks on tables that
were not modified by the statement, possibly introducing concurrency or deadlock
problems to an existing application. This has been fixed.
================(Build #2306 - Engineering Case #587404)================
If an application made repeated calls to the CLR external environment, then
the CLR environment (not the server) would have leaked memory. This problem
has now been fixed.
================(Build #2306 - Engineering Case #587402)================
If an application made an external environment call, and another connection
that also made an external environment call closes at the exact same time,
then there was a very small chance that the server would have incorrectly
returned a thread deadlock error, rather than allowing the external environment
call to go through. This problem has been fixed.
================(Build #2306 - Engineering Case #587396)================
If two or more connections, or two or more events, that made CLR calls closed
or completed simultaneously, then there was a chance the CLR external environment
may have hung. This problem has now been fixed.
================(Build #2306 - Engineering Case #587214)================
When HTTP client debugging was turned on, calling the HTTP client procedure
would have resulted in a request time-out. This problem was introduced by
the changes made for Engineering case 565244, and would have occurred when
client logging was initiated, either with the -zoc command line option, or
by calling the system procedure sa_server_option(), to set the 'WebClientLogFile'
file name. This has now been fixed.
================(Build #2306 - Engineering Case #586596)================
The SQL Anywhere server allows specification of the isolation level for a
query as part of query text via the OPTION clause. This specification is
valid only for the current statement and is meant to override other specifications
of isolation level, e.g., those provided by the setting for the database
option isolation_level, and cursor flags provided by the application at PREPARE
and OPEN times.
The server failed to honour the per statement specification for isolation
level and used instead other specifications. This problem has been resolved.
Now the isolation level specified in the query text is given the highest
precedence.
================(Build #2306 - Engineering Case #586362)================
If an application made use of a global temporary table in an external environment
via a server-side connection, then there was a chance that the server may
have failed an assertion, hung, or crashed, when the application connection
closed. This problem has now been fixed.
================(Build #2306 - Engineering Case #586180)================
Under certain circumstances, the server could have failed an assertion, or
crashed, while
processing queries containing large strings. This has been fixed.
================(Build #2306 - Engineering Case #583380)================
The server may have returned the error "-890: Statement size or complexity
exceeds server limits", or needed a very long time to complete, for
very complex statements that used proxy tables and alias names that depend
on many other alias names. During the Describe Output or Open of the statement,
the server may have consumed a large amount of cache space and blocked other
requests. This has been fixed.
================(Build #2306 - Engineering Case #568264)================
The server could have hung, consuming CPU, while attempting to shutdown a
database if all workers were busy servicing other requests on different databases.
This has been fixed.
A workaround is to increase the -gn value of the server.
================(Build #2304 - Engineering Case #589655)================
No limit on the size of a CONTAINS query was imposed. The query length was
not checked, and number of terms was not counted. This could have lead to
queries that would have taken very long to execute, or to server crashes.
This has been fixed. Now, a CONTAINS query cannot contain more than 300 valid
terms (terms that are not in the STOPLIST
and are within permitted term length range).
================(Build #2304 - Engineering Case #587429)================
No limit on the size of a CONTAINS query was imposed. This has been fixed.
After this change, a CONTAINS query cannot contain more than 300 valid terms
(terms that are not in the STOPLIST
and are within permitted term length range).
================(Build #2304 - Engineering Case #586837)================
On Unix systems, the 64-bit server may have failed to start when the virtual
memory user limit (ulimit -v) was low relative to the sum of the physical
memory and swap space. This has been fixed.
================(Build #2303 - Engineering Case #586629)================
OPENXML namespaces may have caused the server to crash. This has been fixed.
================(Build #2303 - Engineering Case #579948)================
The system procedure sa_index_density(), could have reported 'Cannot convert'
errors. This has been fixed by changing the datatypes of the result set columns
"density" and "skew" from numeric(8,6) to double. As
a result, the definition of the sa_index_density procedure in the database
must be replaced for the fix to take effect. This can be accomplished by
executing: ALTER DATABASE UPGRADE PROCEDURE ON
A workaround is to rebuild the database prior to running sa_index_density.
Re-creating or reorganizing the offending index may also be a workaround.
================(Build #2301 - Engineering Case #585979)================
Using the BCP utility to insert data into a table could have failed with
a protocol error, if the version of Open Client that BCP used was older.
This problem has now been fixed.
================(Build #2298 - Engineering Case #584125)================
Specifying an IPv6 address with a port number for the HOST option, eg. LINKS=tcpip(host=(<ipv6
address>):<port>) would give an SQLE_CONNECTION_ERROR (-832) with
the text "Unexpected error 10" or "Mismatched braces near
'???'". This only happened when parentheses were used for both the TCP
parameter and the HOST option. This has been fixed.
As a workaround, use braces to specify the TCP options, eg. LINKS=tcpip{host=(<ipv6
address>):<port>}".
================(Build #2297 - Engineering Case #585713)================
Under rare circumstances, the server may have hung when run on Solaris systems.
This was more likely to have occurred on machines with greater parallelism
(e.g., Niagara chips) under a highly concurrent load. This has been fixed.
================(Build #2296 - Engineering Case #585282)================
If an application connected via Open Client or jConnect, and requested a
packet size greater than 512 bytes, the SQL Anywhere server would have restricted
the packet size to a maximum of 512 bytes. This restriction has now been
relaxed such that the maximum Open Client or jConnect packet size is now
4096 bytes for a version 11.0.1 or above server, and 1024 bytes for a version
10.0.1 server.
================(Build #2296 - Engineering Case #585056)================
If the database option Escape_character was set to OFF, attempting to change
a user's password via the NEWPWD connection string parameter would have failed
silently. This has been fixed. A workaround is to leave the escape_character
setting at its default (ON).
================(Build #2295 - Engineering Case #584152)================
A statement-level "after update of" trigger would not have fired
if the columns in the "of" list were modified by another trigger,
but were not present in the set clause of the originating query. This has
been fixed.
Note, row level triggers do not have this problem.
================(Build #2295 - Engineering Case #583353)================
The version of samonitor.sh included with the development version of the
SQL Anywhere Monitor on Unix platforms provided a start() method to spawn
the database server, but did not provide a stop() method to shut it down.
This has been fixed.
Note: if the desktop environment has a system tray supported by Java 1.6,
it is possible to shut down the server monitor cleanly by right clicking
on the SQL Anywhere Monitor logo and choosing "Shutdown"
================(Build #2295 - Engineering Case #583241)================
Under some specific circumstances, the server could have crashed while updating
tables with triggers. This has been fixed so that execution of UPDATEs now
takes place correctly.
A workaround is to recreate the table under question.
================(Build #2295 - Engineering Case #559258)================
The stored procedure debugger failed to report information about the size
of string and numeric data types when debugging a stored procedure. This
has been corrected.
================(Build #2291 - Engineering Case #584517)================
When validating a database, either using the VALIDATE DATABASE statement,
or with the Validate utility (dbvalid -d), an error would not have been reported
if a transaction log page was encountered in the database file. This has
been fixed.
Note, this situation would have been due to file corruption on the disk.
Transaction log pages are not stored within the database.
================(Build #2291 - Engineering Case #584512)================
When validating databases, using the VALIDATE DATABASE statement or the Validation
utility 'dbvalid -d'), spurious errors could have been reported under rare
circumstances. This has been fixed.
================(Build #2290 - Engineering Case #584466)================
The server was only looking at the groups that a user was a direct member
of when verifying authorities acquired via group inheritance. This has been
corrected so that the server now checks for inheritable authorities through
all group memberships, direct and indirect. For example, if 'group1' is a
member of 'group2' and 'user1' is member of 'group1', 'user1' will obtain
all inheritable authorities of group2 also.
================(Build #2287 - Engineering Case #584304)================
If an application executed an external environment procedure and subsequently
canceled the external call, then all other external environment requests
would have blocked until the external procedure being cancelled acknowledged
the cancel request. This problem has now been fixed.
================(Build #2281 - Engineering Case #583189)================
The server could have crashed in some circumstances after a table definition
was
reloaded. This has been fixed.
================(Build #2280 - Engineering Case #582789)================
The MobiLink server would still have tried to access the ml_scripts_modified
table in the consolidated database, even when it was running with MSDTC on
and its system objects were installed on an MLSD database specified by the
-cs command line switch. This would then have resulted in the MobiLink server
reporting the error message:
Table "ml_scripts_modified" not found
during each synchronization, when a pooled database connection was reused.This
problem has now been fixed.
================(Build #2280 - Engineering Case #581986)================
Executing certain illegal operations on catalog tables could have caused
the server to crash after the statement was rejected with an appropriate
error. This has been fixed so that the server now works correctly.
================(Build #2279 - Engineering Case #582799)================
The server could have crashed during a LOAD TABLE statement if the DEFAULTS
ON clause was used, and a load-time error occurred when evaluating or assigning
the default expression. This has been fixed.
The workaround is to fix the column default definition so that no error
occurs.
================(Build #2279 - Engineering Case #582756)================
The changes for Engineering case 544187 caused the server to have a limited
number of temporary files that it could create in the lifetime of the server
process (64K on non-UNIX systems, 4G on UNIX systems). The problem would
have shown up as an error writing to an invalid handle, and a fatal "disk
full" error would have been reported. On Windows, the message in the
server console would have looked like the following:
A write failed with error code: (6), The handle is invalid.
Fatal error: disk full when writing to "???"
This problem has been fixed.
A related problem was also fixed where failure to create a temporary file
for the utility_db would have cause the server to crash.
================(Build #2278 - Engineering Case #582405)================
When processing a simple query that bypassed the query optimizer, in some
cases it was possible for the server to crash if. This may have occurred
when the query contained the SELECT TOP n clause, and 'n' was was a host
variable, rather than a literal constant. This problem has now been corrected.
================(Build #2278 - Engineering Case #581957)================
The database option, divide_by_zero_erro, was removed in version 11.0.0.
It has now been re-instated. The default setting for the option is On (as
it was in version 10), which gives the same behavior as before this change,
i.e. an attempt to cause division by zero results in an error.
================(Build #2278 - Engineering Case #581046)================
A procedure with the statement
MESSAGE ... FOR CONNECTION ... IMMEDIATE
did not contain the IMMEDIATE clause in the stored definition of the procedure.
This has been fixed. A workaround is to execute the MESSAGE statement using
EXECUTE IMMEDIATE.
================(Build #2277 - Engineering Case #581980)================
If an application executed a statement of the form:
SELECT ... INTO LOCAL TEMPORARY TABLE localtemptab FROM extenv_proc()
where extenv_proc() was an external environment procedure that returned
a result set, then the SELECT ... INTO statement would have succeeded, but
attempting to subsequently access the newly created localtemptab would have
resulted in a 'table not found' error. This problem has now been fixed.
================(Build #2277 - Engineering Case #581979)================
Retrieving property('Platform') on a system running Windows 2008 R2 RC3,
would have returned "Windows7". This has been fixed, the property
now returns "Windows2008R2".
================(Build #2275 - Engineering Case #581752)================
If the mirror server in a mirroring system failed to start (e.g. due to a
TCPIP port conflict), it could have crashed when shutting down. This has
been fixed.
================(Build #2275 - Engineering Case #581586)================
If the -dt server command line option was used to specify a directory where
temporary files were to be created, the server did not use that location
when attempting to clean up old temporary files previously left behind when
a server did not shut down cleanly. This has been fixed.
A workaround is to specify the temporary file location using one of the
SATMP, TMP, TMPDIR or TEMP environment variables.
================(Build #2274 - Engineering Case #581249)================
If an application attempted to create a proxy table using the CREATE EXISTING
TABLE statement, and the remote server specified in the location clause does
not exist, then the server may have given a strange syntax error instead
of giving the "remote server not found" error. This problem has
now been fixed and the proper error will now always get returned.
================(Build #2274 - Engineering Case #580146)================
If an application attempted to drop a user that had externlogins defined,
then the server would have given an error indicating that externlogins were
defined. The server behaviour has now been changed to quietly drop externlogins
as part of dropping a user.
================(Build #2273 - Engineering Case #580773)================
The server could have hang in some very rare circumstances, when there was
considerable temporary file growth. This has now been fixed. A workaround
is to pre-grow the temporary file using the ALTER DBSPACE statement, or to
create a DiskSpace event to periodically grow the temporary file.
================(Build #2273 - Engineering Case #580390)================
If both a BEFORE UPDATE and a BEFORE UPDATE OF trigger were defined on the
same table, and the BEFORE UPDATE OF trigger was not the first to fire when
an update was performed using INSERT ... ON EXISTING UPDATE, then the BEFORE
UPDATE OF trigger would not have fired at all. This has now been fixed.
================(Build #2272 - Engineering Case #581032)================
The result set returned by the system procedure sp_sproc_columns() has been
changed to include information about parameter modes. The "column_type"
column was previously an integer value and was always 0. Now it is a varchar(5),
with values 'IN', 'OUT' or 'INOUT'. Also, for functions, the column_name
will be returned as @RETURN_VALUE for the function return value; a row for
this value was not previously returned.
================(Build #2272 - Engineering Case #580772)================
Executing a remote query that involved the use of the ROWID() function, where
the table specified to ROWID was a remote table, would very likely have caused
the server to crash when the query was processed in partial passthru,. This
problem has now been fixed.
================(Build #2272 - Engineering Case #580391)================
The fix for Engineering case 529193 was not complete, which meant spurious
referential integrity constraint violations could have been reported. This
has been corrected.
================(Build #2271 - Engineering Case #579826)================
It was possible for an INSERT statement to fail with an inappropriate error
"Invalid host variable". This error could have been given if a
wide insert was performed on a table, followed by a procedure or batch statement
issuing an INSERT to the same table. This has been corrected.
The problem can be avoided using "options(force optimization)"
on the INSERT statement.
================(Build #2271 - Engineering Case #577928)================
It was possible for the server to crash when executing an UPDATE or DELETE
statement for particular execution plans. This has been fixed.
================(Build #2270 - Engineering Case #580004)================
When describing arguments of a stored procedure called with non-positional
arguments, no information was returned from the server.
For example:
CREATE PROCEDURE foo ( IN a INTEGER, OUT b INTEGER )
BEGIN
SET b = a * 2
END
No information was returned when describing input arguments for the statement
"call foo( b=?, a=?)". This has been fixed.
================(Build #2270 - Engineering Case #579981)================
The second argument for the system function get_identity() is the number
of values to allocate. If this value was 0, the function did not adjust the
next available value for the table. If no inserts into a table defined with
a DEFAULT AUTOINCREMENT column had been made, get_identity('<table-name>',0)
returned NULL. This has been fixed. A value of 1 will now be returned in
this case.
================(Build #2270 - Engineering Case #578292)================
If a scheduled event was defined, and the event made a CLR external environment
call, then the server's, and the CLR external environment's, memory usage
would have continued to grow in size with each execution of the event. Note
that this problem was specific to the CLR external environment. The problem
has now been fixed such that the server will now grow and shrink as needed,
and the CLR external environment will shrink whenever garbage collection
kicks in.
================(Build #2269 - Engineering Case #578975)================
Under certain conditions, it was possible for the server to hang when performing
operations with long strings. This has been fixed.
================(Build #2268 - Engineering Case #578933)================
The FORWARD TO statement could have truncated the forwarded statements to
roughly a database page size in length. This has been fixed.
================(Build #2268 - Engineering Case #578153)================
If a database created with a version 9 or earlier server was backed up via
the Backup utility (dbbackup), or the BACKUP DATABASE statement, the backup
copy could not have been unloaded using the Unload utility from version 10
or later. This has been fixed.
================(Build #2268 - Engineering Case #577548)================
It was possible for the server to apply stale values in an UPDATE statement
if concurrent requests issued UPDATE statements at isolation level 0 or 1.
This would occur with particular timing when the UPDATE statements did not
bypass the query optimizer, and neither UPDATE statement contained a join,
or a subquery converted to a join. This has been fixed.
================(Build #2268 - Engineering Case #577297)================
If a procedure was used in the FROM clause of a query, it was possible for
the server to crash if the procedure result set had a particular form. This
has been fixed.
================(Build #2267 - Engineering Case #579215)================
The SQL Anywhere Python driver (sqlanydb.py) would have failed to load on
Mac OS X systems as a result of failing to load the SQL Anywhere C API runtime
library. The driver was looking for dbcapi.dll or libdbcapi_r.so, whereas
on Mac OS X the file name is libdbcapi_r.dylib. This has now been corrected.
================(Build #2267 - Engineering Case #579018)================
If an application created a proxy table and specified the remote owner in
the location clause, then attempting to access the proxy table would have
failed with a syntax error if the remote owner name was a keyword. This problem
has now been fixed.
================(Build #2266 - Engineering Case #580168)================
When a NUMERIC or DECIMAL column with precision greater than 47 was fetched
using OLE DB, ODBC, or JDBC, a memory buffer overrun would have occurred.
This would have resulted in a corrupted heap. The client application may
then terminate unexpectedly due to the corrupted heap. This problem has been
fixed.
================(Build #2266 - Engineering Case #578818)================
A busy server could have crashed, or given an error, when updating a text
index defined with the IMMEDIATE REFRESH clause. This has been fixed.
================(Build #2266 - Engineering Case #578616)================
If a server had a large number of connections making external environment
calls, to the same database-scoped external environment, and the external
environment process crashed due to heavy load, out of memory or some other
reason, then there was a small chance the server would also have crashed.
This has now been fixed.
================(Build #2266 - Engineering Case #578191)================
If a server had request-level logging enabled (eg -zr sql command line option)
while the stored procedure debugger was being used (ie Sybase Central was
in "Debug mode"), the server could have crashed. This problem has
been fixed.
================(Build #2265 - Engineering Case #578365)================
In extremely rare circumstances, the internal representation of the lower
bound of an index scan could have become corrupted for servers run on 32
bit systems. The problem could have manifested itself in many ways, although
the most likely would have been an incorrect result set being returned. This
has now been corrected.
================(Build #2265 - Engineering Case #578346)================
On parallel systems, highly concurrent (tens of connections) temporary table
modifications are now faster.
================(Build #2265 - Engineering Case #578130)================
If LOAD TABLE, or OPENSTRING were used, and all of the following conditions
were true:
- ENCODING 'UTF-8' was specified
- the destination table has both CHAR and NCHAR columns
- the CHAR encoding was not UTF-8
- file data that was destined for a CHAR column contained illegal characters
or characters which could not be converted losslessly to the CHAR encoding
the server could have crashed. This problem has been fixed.
================(Build #2260 - Engineering Case #577129)================
On some Linux distributions (eg Suse 11), the server may have taken an exceedingly
long time to write out a mini-core dump. This has been fixed.
================(Build #2260 - Engineering Case #577109)================
If an application maked use of the Java in the database feature, and a JAVA
stored procedure wrapper was defined such that the number of SQL arguments
in the stored procedure was greater than the number of arguments defined
in the Java method signature, then calling the Java stored procedure may
have crashed the server. This problem has now been fixed, and a Java signature
mismatch error will now be returned.
================(Build #2258 - Engineering Case #576689)================
SQL Anywhere HTTP client procedures defined with a PROXY clause would have
caused the server to crash. This has been fixed.
================(Build #2258 - Engineering Case #576669)================
Executions of a BACKUP DATABASE TO ... archive backup statement, using the
"with checkpoint log no copy" clause, would have been slower than
necessary, particularly when the transaction log file was large. This has
been fixed.
================(Build #2258 - Engineering Case #576213)================
If a SELECT statement included an alias specified as a single-quoted string,
and the string contained a double quote or backslash, a syntax error should
have been given, but was not. This has been fixed; an error will be reported
in this case.
================(Build #2257 - Engineering Case #576009)================
The size of the stack used by some database server threads was not governed
by the -gs and -gss server command line options. Some of these threads used
stacks that were excessively large (1MB) for a CE environment, and could
have lead to problems loading DLL's on some CE systems. These stack sizes
have been reduced to 64K or less. The default stack size for request tasks
is unchanged at 96K. Some versions did not allow a -gss value of less than
96K, but now values as low as 64K are permitted.
================(Build #2257 - Engineering Case #576008)================
If a query contained a LIKE predicate with a non-string value (Integer, Date,
etc.), then it was possible for the predicate to evaluate a little more slowly
than it could have. The non-string value was converted to NCHAR before the
comparison, and this imposed additional overhead that was not present in
previous versions. It is equivalent and faster to perform the comparison
using VARCHAR, which is now how the comparison is done.
================(Build #2256 - Engineering Case #575787)================
The transaction log on the mirror server in a mirroring system may have become
corrupt under rare circumstances. One example would be the mirror server
processing a log rename request when the primary server disconnects. Should
corruption occur, the database on the mirror server would have failed to
start with the error "Can't use log file since it is shorter than expected."
This has been fixed.
================(Build #2256 - Engineering Case #575782)================
Under certain rare circumstance, a mirror server may have crashed on shutdown
when processing a transaction log rename request. This has been fixed.
================(Build #2255 - Engineering Case #574473)================
The conflict() function, used with SQL Remote in RESOLVE UPDATE triggers,
did not return correct results. The result of the function was always FALSE.
This has been fixed.
================(Build #2254 - Engineering Case #575116)================
The changes for Engineering case 569934 enhanced performance for directory
access queries of the form:
SELECT [...,]contents[,...] FROM dir_table WHERE [...AND] file_name=[string|variable]
[AND...]
These quesries now execute much faster as the "file_name=" predicate
evaluation is now pushed down into the directory access server. Unfortunately,
if the "file_name=" was specified as a fully qualified reference
as in "dir_table.file_name=", then the predicate would not have
been pushed down. This problem has now been fixed.
================(Build #2254 - Engineering Case #574912)================
If a database contained a DISCONNECT event handler called E, and a transaction
log containing a DROP EVENT E statement was applied to the database, recovery
could have reported failed assertion 100904 ("Failed to redo a database
operation ... Event E in use"). This has been fixed.
================(Build #2253 - Engineering Case #574708)================
Executing a query that required a result set to be fetched from a remote
table, could have in very rare situations, caused the server to crash. This
problem has now been fixed.
================(Build #2253 - Engineering Case #574707)================
If an application made an external environment request, and the server was
under heavy load, then there was a chance the external environment would
have taken too long to respond to the request. In such situations, the server
would have timed out the request and returned control back to the application.
If the external environment responded to the request at exactly the same
time the server timed the request out, then there was a very small chance
the server would have hung. This has now been fixed.
================(Build #2252 - Engineering Case #574364)================
If an application accessed a connection-scoped external environment via an
HTTP request or from an event, then the external environment would have shut
down when the HTTP request finishes or when the event completed. As a result,
the next HTTP request or event that accessed the external environment required
that the external environment be restarted. The server has now been improved
such that starting an external environment is between 20% to 25% faster.
Note that applications that use a database-scoped external environment (i.e.
Java or CLR) will see a very modest performance improvement.
================(Build #2252 - Engineering Case #541908)================
For some forms of simple DELETE statements on tables with computed columns,
the server may have returned the following error:
*** ERROR *** Assertion failed: 106104 (...) Field unexpected during compilation
(SQLCODE: -300; SQLSTATE: 40000)
This has been fixed.
================(Build #2251 - Engineering Case #574222)================
During a full text search, with a very long query containing conjunctive
or disjunctive expressions only, the server could have failed with the error:
"Text query parser error: parse stack overflow at or before character
<n>". This has been fixed.
Examples of queries that would failed:
CONTAINS( col, 'apple & banana & tomato & cucumber & .....
& parsley' )
CONTAINS( col, 'dog | cat | camel | .... | chipmunk' )
where ... is a list of terms separated by the & or | operator.
================(Build #2251 - Engineering Case #574014)================
In some circumstances, it may have taken longer than expected to shutdown
a database when it was started and then immediately stopped. This would only
have been noticeable if the following three conditions were true:
a) cache collection was enabled on the previous run of the database,
b) cache warming was enabled on the current run of the database,
c) the server accessed a large number of pages during the cache collection
interval, i.e., the first queries executed against the database referenced
a large number of pages (as may be the case in a scan of a large table or
set of tables).
This has been fixed. Note, cache collection is on by default, and is controlled
by the -cc server command line option. A workaround is to disable cache warming
using the -cr- server command line option.
================(Build #2251 - Engineering Case #562236)================
In some cases, client applications running on Solaris systems may have hung
while communicating with the server through shared memory. Other symptoms
may also have included communication errors between the client and the server.
This was more likely
to happen on multi-processor machines. This has been fixed.
================(Build #2250 - Engineering Case #574475)================
Under very rare circumstances, a client-side backup that truncates or renames
the log may have hung the server. This has now been fixed.
================(Build #2250 - Engineering Case #573841)================
When starting a database created by a backup, particularly one created using
BACKUP ... WAIT BEFORE START ... WITH CHECKPOINT LOG NO COPY, the server
could have failed with an error of the form "Database cannot be started
-- <log file name> not expecting any operations in transaction log".
This problem has been fixed.
As a workaround, add "-a <log file name>" to the server's
command line. When recovery completes, the server will shut down. Afterwards,
restart the server normally (without the "-a <log file name>"
option).
================(Build #2250 - Engineering Case #573172)================
The server could have become deadlocked if the 'wait after end' option was
used when performing a backup. This has now been fixed.
================(Build #2250 - Engineering Case #571284)================
The server may have crashed following execution of an ALTER TABLE statement
that added or modified columns with a DEFAULT or COMPUTE clause, if all materialized
views had been dropped since the last server start. This has been fixed.
================(Build #2249 - Engineering Case #573636)================
After performing a database backup, a warning message of the form "Unable
to open backup log '...'" could have been sent to the client and console.
Note that this warning came as a "message" to the client, not as
a warning SQLCODE from the BACKUP statement. The problem was far more likely
to have occurred on Windows Vista or later when running as a non-elevated
process, as the server typically tried to write the log into the SQL Anywhere
installation directory which is not typically writable by non-elevated pocesses.
This problem was fixed by properly detecting which of the possible directories
for placement of backup.syb were writable, and adding the %ALLUSERSPROFILE%\SQL
Anywhere XX (XX=version number) directory to the list of possible directories.
On Vista and later, the %ALLUSERSPROFILE% directory is typically C:\ProgramData.
On earlier versions of Windows, it is typically C:\Documents and Settings\All
Users\Application Data.
================(Build #2249 - Engineering Case #573614)================
If requests were made to close several connections at the same time, then
the server may have taken much longer than necessary to close all the connections.
This problem was very rare and not very noticeable, but has been fixed.
================(Build #2249 - Engineering Case #573160)================
If an initial database size was specified in a CREATE DATABASE statement
or with the -dbs option on the Initialization utility (dbinit), the resulting
database would have been slightly larger (about 2MB) than the requested size.
This has been fixed.
================(Build #2248 - Engineering Case #573452)================
Fetching a result set may, on rare occasions, have caused an application
that connected using a newer version of Open Client 15 to hang or give a
protocol error. In addition, cancelling a request may also have caused the
application to hang or give a protocol error. These problems have now been
fixed.
Please note that if an application does use Open Client 15 to connect to
SQL Anywhere, then it will be necessary to update the version of Open Client
15 once this fix is installed.
================(Build #2248 - Engineering Case #573208)================
Full text searches, where both arguments to the NEAR operator were the same
token, would have matched documents containing a single copy of the token.
This has been fixed.
================(Build #2246 - Engineering Case #572935)================
If an UNLOAD ... INTO VARIABLE or UNLOAD ... INTO CLIENT FILE statement was
used to unload either a table or a query containing an NCHAR column, the
database server could crashed if the NCHAR character set was did not match
the destination character set. This problem has been fixed.
================(Build #2246 - Engineering Case #569704)================
Very complex queries, with more than 20 tables being joined, that were being
optimized using the 'FIRST-ROW' optimization goal, may have had inefficient
access plans. This has been fixed.
================(Build #2246 - Engineering Case #552067)================
The server could have become deadlocked if the 'wait after end' option was
used when performing a backup. For the deadlock to have occurred, there must
have been an active transaction when the backup attempted to truncate the
log, and then a checkpoint and commit must have occurred, in that order on
separate connections, between the time that the backup attempted to truncate
the log and when the backup noticed that there was an active transaction
(a very short time interval). This has now been corrected.
A work around in most cases is to omit the 'wait after end' option, as it
is often not required.
================(Build #2245 - Engineering Case #572347)================
For specific classes of the UPDATE statement, it was possible for the server
to consume too much memory while processing the request. In extreme cases,
the server could have failed with an out-of-memory error. This has been fixed.
================(Build #2244 - Engineering Case #572544)================
During full text searches using a text index with a GENERIC term breaker,
if a CONTAINS query contained a phrase with a term longer than MAXIMUM TERM
LENGTH, the positional
information for the term could have been lost. This could have caused incorrect
results to be returned. This has now been fixed.
Example:
Consider a text index on col1 of table t, built using a text configuration
with MAXIMUM TERM LENGTH equal to 7, MINIMUM TERM LENGTH equal to 1:
SELECT t.*
FROM t CONTAINS( col1, '"there is an elephant at the zoo"' );
Before this fix, the query above would be equivalent to:
SELECT t.*
FROM t CONTAINS( col1, '"there is an at the zoo"' );
and would miss documents containing the phrase "there is an elephant
at the zoo".
================(Build #2243 - Engineering Case #570098)================
In some circumstances, a 10.x server could have hung at shutdown if a parallel
backup had been performed, or an outbound HTTP connection (SOAP, etc) had
been used. When those features were used on an 11.x server, the server would
not have hung at shutdown, but unpredictable behaviour (crash, hang) could
have occurred at runtime. This problem has been fixed.
Note that the likelihood of encountering the problem with 11.x servers is
extremely small.
================(Build #2242 - Engineering Case #571957)================
The server could have generated a dynamic memory exhausted error when trying
to execute
a very complex statement. This has been fixed. The server will now return
the SQL error
SQLSTATE_SYNTACTIC_LIMIT.
================(Build #2241 - Engineering Case #571988)================
Fetching the connection property 'ServerNodeAddress', would have incorrectly
returned the client's node address rather than the server's. This has been
fixed.
================(Build #2237 - Engineering Case #571628)================
If an application called a stored procedure which in turn called a proxy
procedure, and the local stored procedure generated a warning prior to calling
the proxy procedure, then the server may have returned the error: "remote
server not capable". This problem has now been fixed.
================(Build #2237 - Engineering Case #570738)================
In very rare, timing dependent cases, a server backup could have hung while
starting up. This has been fixed.
================(Build #2237 - Engineering Case #569934)================
The server has been improved such that queries of the form:
SELECT [...,]contents[,...] FROM dir_table WHERE [...AND] file_name=[string|variable]
[AND...]
now execute much faster. In the above example, dir_table is a proxy table
to a directory access server, the WHERE clause contains zero or more AND
clauses and no OR clauses, and one of the predicates in the WHERE clause
is of the form file_name=[string | variable].
================(Build #2236 - Engineering Case #569932)================
While performing certain operations that require sorting large amounts of
data, such as creating an index, established temporary space limits that
were set using the "max_temp_space" database option, could have
been violated. This has been fixed.
================(Build #2235 - Engineering Case #570093)================
If a SELECT statement contained the clause FOR UPDATE BY LOCKS, and a cursor
was opened without specifying updatability cursor flags from the client application,
then the BY LOCKS specification could have been incorrectly ignored by the
server. This would only have happened if the statement was a simple query
that was processed bypassing optimization. The consequence of this was that
intent locks would not have been taken on the table being scanned. The only
API affected by this problem was Embedded SQL.
Also, if a statemented executing at isolation 3 used an index scan for a
table marked for update, then the rows of the table could have incorrectly
been locked with exclusive (write) locks, instead of intent locks. The consequence
of this was that other connections attempting to read the row could have
blocked, even if the row was ultimately not modified.
These problems have now been fixed.
================(Build #2235 - Engineering Case #567942)================
If a query was processed using a parallel execution plan, it was possible
for the statement to exceed the setting of the Max_temp_space option by a
factor of the number of branches in the plan. This has been fixed.
================(Build #2233 - Engineering Case #570896)================
In rare circumstances the server may have crashed when a new HTTP connection
was created. This has been fixed.
================(Build #2229 - Engineering Case #570652)================
If a version 10.x or later database had a torn (ie "partial") write
in the checkpoint log, the server could have reported assertion failures,
including 201866 (only on 10.x servers), 201869 (only on 11.x servers), 200502,
200505, or 200512. In the case of a single torn write, these failures should
not have been reported, and the database should be recoverable once the server
is upgraded to include this fix. If upgrading the server does not resolve
the assertion failures, the database is likely corrupt and does not just
have a torn write.
================(Build #2229 - Engineering Case #569314)================
The datepart() function could have returned an incorrect result for the CALWEEKOFYEAR
and CALYEAROFWEEK date parts for dates greater than December 29 of years
for which January 1 of the following year falls on Tuesday, Wednesday or
Thursday. The first week of a year is defined as the week containing the
year's first Thursday. All days in that week should have the same CALWEEKOFYEAR
and CALYEAROFWEEK values, even for days in the previous year. This has been
fixed.
================(Build #2229 - Engineering Case #568976)================
In rare, timing dependent circumstances, the server may have hung when executing
queries using intra-query parallelism. This has been fixed.
A workaround is to disable intra-query parallelism by setting the max_query_tasks
option to 1.
================(Build #2228 - Engineering Case #570493)================
In very rare cases, if an event fired while a database was being shutdown,
the server could have crashed. This has been fixed.
================(Build #2228 - Engineering Case #570476)================
A SQLAnywhere service, processing an x-www-urlencoded (standard GET or POST)
HTTP request which calls HTTP_VARIABLE() with an @BINARY attribute, will
return %-encoded (URL encoded) data. This has been fixed. An @BINARY attribute
will now implicitly decode the value without character set translation.
A new attribute, @TRANSPORT, has been added to allow the return of data in
its raw HTTP transport form. With this change, HTTP_VARIABLE may retrieve
x-www-form-urlencoded values in three different forms:
* No attribute - return a value that is %-decoded and character set translated
to the database character set encoding. %-encoded UTF-8 decoding is supported.
This should be the default usage for retrieving textual x-www-form-urlencoded
data.
* @BINARY should be used to retrieve x-www-form-urlencoded binary data values.
The value is %-decoded with no character set translation, UTF-8 %-encoded
data is not supported in this mode since %-encoded data are simply decoded
into their equivalent byte representation.
* @TRANSPORT will return the raw HTTP transport form of the value, where
%-encodings are preserved.
This change does not impact the usage of @BINARY for multi-part/form-data
form based uploads. The use of @TRANSPORT in this case is identical to @BINARY.
Prior to this change, the work-around was to HTTP_DECODE the value returned
by the HTTP_VARIABLE function when it was called with an @BINARY attribute.
================(Build #2228 - Engineering Case #570468)================
When attempting to create a proxy table, if the connection was subsequently
cancelled, either explicitly or implicitly, by shutting down the database
or server, then there was a small chance the server would have crashed. This
problem has now been fixed.
================(Build #2227 - Engineering Case #570140)================
Attempting to insert a binary or varbinary variable, or host variable, into
a Microsoft SQL Server proxy table with an image column would have failed
with an 'invalid precision' error when the length of the binary value was
between 8001 and 32768 bytes. This problem has now been fixed.
================(Build #2226 - Engineering Case #570141)================
In rare cases, the mirror server in a mirroring ssystem could have crashed
at shutdown. This has been fixed.
================(Build #2226 - Engineering Case #570128)================
A small amount of memory was being leaked when a CREATE ENCRYPTED DATABASE
or CREATE DECRYPTED DATABASE statement was executed. This has been fixed.
================(Build #2226 - Engineering Case #570116)================
The mirror server in a mirroring system could have hung while processing
log pages received from the primary server. This has been fixed.
================(Build #2226 - Engineering Case #570094)================
The server would have crashed when parsing a procedure that contained a CASE
statement with a WHEN clause which had an unary search condition other than
ISNULL. When unparsing the WHEN clause the server was expected a binary search
condition and crashed when attempting to access the second operand. This
has been fixed.
================(Build #2226 - Engineering Case #569784)================
If a procedure definition did not contain a RESULT clause, and returned its
results from a SELECT statement with a TOP n clause that used variables,
describing a query of the form:
SELECT *
FROM proc()
could have been incorrectly described by the server as having a single column
with the name "expression". The result set returned by the statement
would have had the correct schema. This has been fixed.
Calling the procedure directly (i.e. call proc()) was not affected by this
problem, and would be correctly described, so this statement can be used
as a workaround. Describing the schema of the result set using a RESULT clause
is also a workaround. To fix procedures created with older servers, an ALTER
PROCEDURE <proc> RECOMPILE has to be executed for each such procedure.
================(Build #2226 - Engineering Case #568421)================
Remote server capabilities were accidentally set OFF during a rebuild of
a case-sensitive database. This has been fixed.
================(Build #2225 - Engineering Case #616231)================
An HTTP/SOAP request may have caused the SQL Anywhere server to crash under
certain circumstances. This has been fixed.
================(Build #2223 - Engineering Case #570308)================
Attempting to return a result set from within a BEGIN ATOMIC block would
caused a memory leak in the server. This has been fixed.
Note that returning a result set from within an atomic block is not allowed,
and an error is issued in this case. This behaviour has not changed.
================(Build #2223 - Engineering Case #569942)================
If an application that was connected using Open Client executed a query that
generated a large column name, then there was a chance the application would
have exited with a TDS protocol error. This problem has now been fixed.
================(Build #2223 - Engineering Case #569776)================
When processing a SIMILAR TO, REGEXP or REGEXP_SUBSTR expression and the
request_timeout option was set, incorrect results could have been returned.
If the request_timeout option was not set, it was possible for a cancelled
expression to have taken several seconds, or more, to respond. This has been
fixed.
================(Build #2223 - Engineering Case #568674)================
Attempting to execute an CREATE ENCRYPTED DATABASE statement to create a
database encrypted with simple encryption, or the CREATE DECRYPTED DATABASE
statement to decrypt a database encrypted with simple encryption, without
having specified an encryption key, would have returned the error (-131 "Syntax
error near '(end of line)' on line 1"). This has been fixed.
As a workaround, add "KEY 'unused'" to either statement; whatever
key is specify will be ignored.
================(Build #2221 - Engineering Case #569759)================
Executing the CREATE ENCRYPTED DATABASE or CREATE DECRYPTED DATABASE statement
would have caused assertion 100202 if the source database was already running
and the filename given in the statement did not contain the '.db' suffix.
This has been fixed.
================(Build #2221 - Engineering Case #569753)================
A database server acting as the mirror server in a mirroring system, could
have hung in rare cases. This has been fixed.
================(Build #2221 - Engineering Case #569127)================
The result set returned from calling the system procedure dbo.sp_jdbc_primarykey()
may have contained more rows than it should. This problem was introduced
by the changes made for Engineering case 531119, and has now been fixed.
================(Build #2220 - Engineering Case #571436)================
A statement that used subsumed ORDER BY clauses in aggregate functions would
have failed with a syntax error. This type of statement was executed without
an error in version 9.0.2, and has now been fixed.
For example:
select list(e1 ORDER BY e2, e3 ), list( e4 ORDER BY e2,e3,e5)
from ....
The first ORDER BY clause 'e2, e3' is subsumed by the second ORDER BY clause
'e2,e3,e5'.
================(Build #2219 - Engineering Case #569330)================
The server could have crashed, or failed an assertion, if a materialized
view had been disabled soon after an update. This has been fixed.
================(Build #2218 - Engineering Case #569778)================
If an application made a PHP external environment call that generated a large
message, and then called exit(), there was a small chance that the server
would have crashed. This problem has now been fixed.
================(Build #2218 - Engineering Case #569327)================
If an application made an external environment call to a connection scoped
external environment process, and that process then set an error and exited,
then there was a chance the server would have crashed. This problem has now
been fixed.
================(Build #2218 - Engineering Case #569307)================
A SQLAnywhere service requiring authorization returned realm information
based on the request URL. This has been fixed. The realm is now always set
to the database name (or its alias) regardless of the request URL.
================(Build #2218 - Engineering Case #569298)================
In some cases, it was possible for recursive UNION queries to give incorrect
results. This has been fixed.
================(Build #2218 - Engineering Case #565232)================
In very rare circumstances, if a complex view which cannot be unflattened
(e.g., a grouped view) was used multiple times in the same statement, the
optimizer may have generated an access plan which computes an incorrect result
set. One of the conditions for this to have occurred was for a predicate
of the form " V.X theta [ANY|ALL] ( select aggregate(e) from V as
V1 where ... )" to be present in one of the query blocks of the statement.
This has been fixed.
================(Build #2217 - Engineering Case #568663)================
The server could have crashed during Application Profiling if any variables
or host variables were present in the workload. This has been fixed.
================(Build #2217 - Engineering Case #567543)================
If the WHERE clause of a query block contained many predicates using host
variables, it was possible that the PREPARE or OPEN times would have been
unnecessarily long. The server was not recognizing the two expressions with
host variables were the same. his has been fixed.
================(Build #2214 - Engineering Case #568991)================
Connecting to the server using Open Client and attempting to describe the
input parameters of a dynamic statement, would very likely have cause the
application to hang. This problem has now been fixed.
================(Build #2214 - Engineering Case #568984)================
If an application connected via HTTP and executed a PHP external environment
stored procedure with a long varchar or long binary argument, then there
was a very small chance the server would have crashed if the HTTP connection
was cancelled at exactly the same time that the PHP external environment
call was made. This problem has now been fixed.
================(Build #2213 - Engineering Case #568652)================
Adding two columns with default values to a global temporary table would
trigger assertion 100712 (page level logging already in progress).
================(Build #2213 - Engineering Case #568233)================
If a query had multiple uses of a function such as now() and one of the uses
was within a COALESCE expression, then it was possible for the query to unexpectedly
give different values for the two uses. For example, the following query
could return different values for time1 and time2:
create temporary function T_W( x int )
returns timestamp
begin
waitfor delay '00:00:00.500';
return NULL;
end
select coalesce( T_W(0), now() ) time1, coalesce( T_W(1), now() ) time2
In addition to now(), the following expressions also had this behaviour:
getdate()
today()
current date
current time
current timestamp
current utc timestamp
In addition to coalesce() expressions, the same problem could occur with
the now() or related function used within these expressions:
ISNULL()
IFNULL()
IF
CASE
ARGN
This has been fixed.
================(Build #2212 - Engineering Case #568821)================
Querying the deprecated server property MaxMessage, would have caused the
server to crash if the property MessageCategoryLimit was set to 0. This has
been fixed.
================(Build #2211 - Engineering Case #568660)================
Referential integrity constraints (i.e. primary keys, foreign keys or unique
constraints) involving long values may have resulted in unexpected errors.
This problem has now been fixed.
================(Build #2211 - Engineering Case #568645)================
On very rare occasions, the server may have failed to start on Solaris systems.
This has been fixed.
================(Build #2211 - Engineering Case #568641)================
Attempting to insert a large long binary value into a MicrosoftS SQL Server
proxy table, would have failed with a "wrong precision" error.
This problem was introduced by the fix for Engineering case 565651, and has
now been fixed.
================(Build #2211 - Engineering Case #568468)================
The SQL Anywhere server supports the "UPDATE( colname )" condition
that can be evaluated in statement-level trigger code to determine if the
value of the specified column has been modified from its original value in
any of the rows in the row set affected by the UPDATE/INSERT/MERGE statement
being executed. The server would have failed to evaluate the condition correctly
for multi-row sets under certain circumstances. This has been corrected so
that the server will now evaluate the condition correctly.
================(Build #2211 - Engineering Case #559399)================
If the deleted_length of a text index was greater than 50% of the doc_length,
the server should refresh the text index. However, it was possible to get
into a state where the pending length was very small and the deleted_length
was very large, yet refreshes still did not occur. The check for the pending_length
was occurring too early and prevented the server from ever checking the pending
length. As a result, the index was never being refreshed. This has been
corrected so that the server now checks that one condition or the other is
true to continue to the refresh code.
================(Build #2211 - Engineering Case #551622)================
The system procedure sa_get_user_status() required the connection calling
the procedure to have DBA authority in order to obtain information about
users other than the current user. Calling sa_get_user_status() from a procedure
owned by a user with DBA authority was not sufficient to return information
about other users. This has been fixed. Now, if sa_get_user_status() is called
from a procedure owned by a DBA, information about all users will be returned.
In addition to an updated server, this fix requires the sa_get_user_status()
procedure to be updated.
================(Build #2210 - Engineering Case #568431)================
If an application executed an external environment stored procedure, and
the external process terminated in the middle of the external call, then
there was a chance the server would have crashed. This problem has now been
fixed.
================(Build #2210 - Engineering Case #568422)================
Under rare circumstances, a server participating in a mirroring system may
have crashed on database shutdown. This has been fixed.
================(Build #2207 - Engineering Case #568831)================
A server running in a database mirroring system could have hung while log
pages were being sent from the primary server to the mirror server. The primary
server periodically sends a "catchup" request to the mirror to
ensure that the mirror does not get too far behind in applying log operations
that it has received from the primary and written to disk. It was possible
for this request to cause a hang if it was received at the same time as an
operation for a new connection was being processed in the transaction log.
This has been fixed.
================(Build #2207 - Engineering Case #568219)================
If the amount of available physical memory during an archive restore was
low (the threshold is around 20 MB), but this was not the case during the
archive backup, then the operation would have failed with an "insufficient
memory" error, regardless of the amount of available swap space. This
has been fixed.
================(Build #2207 - Engineering Case #568217)================
On Mac OS X systems, an archive restore could have failed with an "insufficient
space" error, even when enough space to complete the restore was available.
This has been fixed.
================(Build #2205 - Engineering Case #568091)================
Under rare circumstances, if starting a database that truncates the transaction
log at a checkpoint (i.e., WITH TRUNCATE AT CHECKPOINT clause to the START
DATABASE statement or on a server started with the -m command line option)
failed, the server may have crashed. This has been fixed.
================(Build #2204 - Engineering Case #567409)================
If a CREATE TABLE statement was executed using EXECUTE IMMEDIATE and a declared
temporary table with the same name already existed, an error was not given.
This has been fixed.
================(Build #2203 - Engineering Case #565447)================
Index corruption was possible if an index contained many (more than 64,000)
consecutive entries that differed by the same constant amount. A check to
ensure that the count value does not overflow when merging pages was missed.
This has been corrected.
================(Build #2202 - Engineering Case #567541)================
As a result of changes made for Engineering case 545640, SQLAnywhere DISH
services were not sending HTTP response headers. This has been fixed.
================(Build #2202 - Engineering Case #567427)================
If a transaction running under snapshot isolation attempted to update or
delete a row that had been deleted and committed by another transaction,
the update or delete would have failed with the wrong error. Typically the
error would have been "Unable to find in index 't' for table 't' (SQLCODE:
-189; SQLSTATE: WI005)", or it could have failed silently. This has
now been fixed.
================(Build #2201 - Engineering Case #567347)================
If an application connected to a server via Open Client, using a newer version
of Open Client 15, then it was likely that cancelling a request would have
given a protocol error on the next request to the server. This problem has
now been fixed.
================(Build #2198 - Engineering Case #567336)================
If response headers were added, modified or deleted by the external environment,
the (calling) SQL procedure had no way of inspecting and identifying changes
to the response headers. This deficiency has been corrected by adding the
functions HTTP_RESPONSE_HEADER( header_name ) and NEXT_HTTP_RESPONSE_HEADER(
header_name ) for value retrieval and iteration of response headers. Response
headers may be modified directly within a SERVICE procedure by calling SA_SET_HTTP_HEADER()
or may be modified through an external environment process such as a PHP
call through via SA_HTTP_PHP_PAGE.
The usage semantics of HTTP_RESPONSE_HEADER() and NEXT_HTTP_RESPONS_HEADER()
are the same as for HTTP_HEADER() and NEXT_HTTP_HEADER() respectively, which
are used to inspect the request HTTP headers.
================(Build #2197 - Engineering Case #567163)================
If an application attempted to start an external environment on a server
that was busy stopping or starting external environments for other connections,
there was a chance the server would have returned a thread deadlock or 'main
communication thread not found' error. There was also a chance, although
small, that the server would have crashed in this situation. This problem
has now been fixed.
================(Build #2197 - Engineering Case #567157)================
In very rare circumstances, the server could have crashed during startup
while recovering a database that used a mirror transaction log file. This
has been fixed.
================(Build #2197 - Engineering Case #562627)================
SQL Anywhere supports the "UPDATE( colname )" condition that can
be evaluated by trigger code to determine if the value of the specified column
has been modified from its current value in the row. The server was failing
to evaluate the condition correctly when the column value was modified internally
during statement execution. As one example, if the user statement did not
modify the column value, but a BEFORE trigger did, then the condition in
an AFTER trigger failed to evaluate to TRUE when it should. This has been
fixed so that the server will now evaluate the condition correctly, regardless
of when the column value is modified,
================(Build #2196 - Engineering Case #566986)================
The version of OpenSSL that is used in the RSA implementation on the Mac
has been upgraded to version 0.9.8k. This was done because of a bug in OpenSSL,
described here:
http://www.openssl.org/news/secadv_20090325.txt. Note that only the third
bug listed affected SQL Anywhere, and only on 64-bit Mac.
================(Build #2196 - Engineering Case #566957)================
The server may have crashed when executing a DML statement that modified
tables in an additional dbspace while a lazy checkpoint was in progress.
This problem was introduced by the changes for Engineering case 547392, and
has now been fixed.
================(Build #2196 - Engineering Case #566693)================
On certain processors other than x86 and x86_64 (64 bit HP-UX for example),
the server may have crashed in extremely rare conditions when using a connection
number to get connection information. Examples of getting this type of connection
information include getting a connection property for another user, or calling
sa_conn_info. This has now been fixed.
================(Build #2195 - Engineering Case #566805)================
Creating a string object shorter than, but within roughly a database page
size of, the 2^31-1 (2GB) upper length limit could have incorrectly resulted
in the SQL error MAX_STRING_LENGTH_EXCEEDED. This has been fixed.
================(Build #2195 - Engineering Case #566685)================
If a simple statement was processed by the server and bypassed the query
optimizer, it was possible for the server to choose an inefficient plan if
the statement contained a specific form of contradiction. For example, the
following statement could have generated a plan that would have read all
rows from TRange:
select * from TRange where x1 = 3 and x2 between 2 and 1
A more efficient plan would recognize that the BETWEEN predicate is never
true (2 > 1), and uses a prefilter to avoid fetching any rows from TRange.
This has been fixed so that the more efficient plan is selected.
================(Build #2195 - Engineering Case #566372)================
Data inserted into a compressed column may have caused a decompression error
when retrieved. This would only have occurred if the data was already compressed
so that compression would result in increased data length, the column was
created with the NO INDEX clause, and the data length was very close to a
multiple of 8 times the database page size. An error in calculating the maximum
possible length for the compressed data has been fixed.
================(Build #2194 - Engineering Case #566043)================
When working with .NET data sources and the OLEDB adapter using Visual Studio,
the Configure Dataset with Wizard dialog may have resulted in "Dynamic
SQL generation is not supported against a SelectCommand that does not return
any base table information." or theTableAdapter Query Configuration
Wizard dialog may have resulted in "Failed to get schema for this query".
The SQL Anywhere OLE DB provider has been corrected.
================(Build #2189 - Engineering Case #566165)================
In very rare circumstances, the server could have crashed if the procedure
debugger run a 'step into' or 'step over' request at the end of a procedure
or trigger. This has been fixed.
================(Build #2189 - Engineering Case #565837)================
When using the INPUT statement with dbisqlc, column inputs may have failed
if the length of the input record exceeded the capacity of the input buffer.
This failure could have been signalled by a conversion error, or it could
have gone undetected (the remaining columns having been truncated or set
to the null value. This problem has now been fixed.
================(Build #2188 - Engineering Case #566046)================
If the maximum value in an autoincrement column after performing a LOAD TABLE
statement was a negative value, the SYSTABCOL.max_identity value for that
column would have been set to a negative value. This would have caused subsequent
inserts into the table, which did not provide a value for the autoincrement
column, to generate errors. This situation could have arisen when rebuilding
a database having a table with an autoincrement column and only negative
values in the column. Note that the use of negative values with autoincrement
columns is discouraged. This has been fixed so that the max_identity value
in this situation will now be set to zero after the LOAD TABLE statement
completes.
================(Build #2188 - Engineering Case #566033)================
When running the SQL Anywhere Deployment wizard, the MSM installer type option
actually created an MSI installer type. This has been fixed.
================(Build #2187 - Engineering Case #566071)================
If an application used either the C_ODBC32 or C_ODBC64 external environments,
then returning result sets from the external environment could have taken
a long time, and resulted in thread deadlock errors due to the fact that
the C_ODBC external environments were not turning autocommit off. This problem
has now been fixed.
================(Build #2187 - Engineering Case #565880)================
If an application used either the C_ODBC32 or C_ODBC64 external environments,
then the server may have reported a connection dropped error when the application
disconnected. This problem has now been fixed.
================(Build #2187 - Engineering Case #565839)================
If an application used one of the connection scoped external environments
(i.e. PHP, PERL or one of the external C environments) and the SA server
was running on a non-Windows platform, then there was a chance the external
environment process would not have gone away once the application disconnected.
This problem was introduced by the changes made for Engineering case 559372,
and has now been fixed.
================(Build #2187 - Engineering Case #565835)================
The server may have crashed if the procedure debugger's connection, and the
debugged connection, stopped at the same time. This has been fixed.
================(Build #2187 - Engineering Case #565678)================
When the server was started with the -fips command line option ('All strong
encyption done using FIPS approved modules'), attempting to create an unencrypted
database would have failed with the error "The simple algorithm is not
available in FIPS mode". This has been fixed
================(Build #2187 - Engineering Case #565283)================
When evaluating predicates outside of DML statements (for example, in SET
or IF statements in procedures, triggers, events, or batches), the server
could have improperly treated UNKNOWN as FALSE. For example, the following
statement should set @str2 to NULL, but it was incorrectly being set to FALSE:
SET @str2 = if NULL like 'a' then 'TRUE' else 'FALSE' endif;
This has been fixed.
================(Build #2187 - Engineering Case #557812)================
If an UPDATE or DELETE statement used a keyset cursor and the statement executed
at isolation level 0 or 1, it was possible for the statement to update or
delete rows improperly. This could have occurred if another transaction deleted
a row identified by the UPDATE or DELETE statement and committed, and then
another transaction inserted a row and committed before the UPDATE or DELETE
statement had finished processing. In this case, the newly inserted row would
have been improperly processed by the UPDATE or DELETE statement. DELETE
and UPDATE statements use a keyset cursor if there is a possibility that
an updated row could be re-processed by the statement (for example if an
UPDATE modifies a column in the index scan, or if a join is present). This
has now been fixed.
A workaround would be to use a higher isolation level (2 or 3).
================(Build #2186 - Engineering Case #565286)================
The server could have released locks on rows prematurely. Data corruption,
crashes, unexplained deadlocks and incorrect query results were all possible.
For this to have occurred though, there must have been a significant amount
of contention for a particular row. This has now been corrected.
================(Build #2186 - Engineering Case #556111)================
In specific situations, it was possible for the server to crash when processing
a statement that contained a LIST aggregate function with an ORDER BY specification
inside of a subquery. This has been fixed.
================(Build #2186 - Engineering Case #523709)================
The server may have crashed when more than one Unload utility (dbunload)
was run concurrently with internal rebuild (ie. -an, -ar, -ac). This has
been fixed.
================(Build #2184 - Engineering Case #565474)================
An HTTP client procedure may have hung when receiving chunk mode encoded
data. For this problem to have occurred, the client needed to identify itself
as an HTTP/1.1 version client (by default it identifies itself as HTTP/1.0).
This may be done in the following ways:
SET 'HTTP(VER=1.1)'
TYPE 'HTTP:POST' and length of the values for input parameter equal or
exceed 8192 bytes
TYPE 'HTTP:POST' SET 'HTTP(CH=ON)'
This has been fixed.
================(Build #2184 - Engineering Case #563693)================
n some cases, it was possible for the server to report an error when processing
a statement that explicitly, or implicitly, used sys.dummy. The error would
have been reported as SQLCODE -300: '*** ERROR *** Assertion failed: 106105
(11.0.x.xxxx) "Unexpected expression type dfe_FieldOrigRID while compiling"'
For example, the following statement could have caused this behaviour:
select TE1.xidx
from (select * from sys.dummy) as D, TE1
where exists ( select * from TE2 where TE2.x = TE1.xidx and TE2.xidx <=
1 )
For the incorrect behaviour to have occurred, the statement must have had
a reference (explicit or implicit) to sys.dummy, where the dummy_col field
was not referenced, and there must have been an exists join optimization
used, where a generated distinct on rowids was needed. This has now been
fixed.
================(Build #2183 - Engineering Case #565257)================
In rare situations, access to a mirrored database could be blocked, making
the mirroring servers appear to hang. This has been fixed.
================(Build #2183 - Engineering Case #565244)================
The SQL Anywhere HTTP server will generate error responses that may be classified
into two categories: System and User error messages. System error messages
are generated for the following conditions: protocol errors, time-out and
cancel. User error messages are generally caused by a SQL error. It is
recommended that the application handle SQL errors within an EXCEPTION clause
and render application specific error responses. By default a User error
message is output in the body of the response as HTML or plain-text when
the SERVICE is configured as TYPE 'HTML' or 'RAW' respectively. User error
messages may have been returned using chunk-mode transfer encoding, while
keeping the connection alive. In the event that the web service encountered
an error when outputting its response, or was explicitly canceled by dropping
its database connection, the response message was prematurely truncated.
A change has been made to make the default behaviour more consistent, SQL
errors explicitly handled by the application are not affected by these changes.
By default System and User error messages:
- do not use chunk mode transfer encoding
- explicitly set 'Connection: close' response header
- shutdown the HTTP connection once the error message is sent
Any pending (pipelined) requests following the request encountering the
error are terminated. Also, an error response is guaranteed to close the
HTTP connection. Interrupting a response (already underway such that the
response headers have already been sent) will truncate the output and close
the HTTP connection. User error messages that are explicitly caught by the
EXCEPTION clause may also CALL SA_SET_HTTP_HEADER('Connection', 'close')
prior to issuing the error page to force the HTTP connection to close after
the response has been sent.
================(Build #2183 - Engineering Case #563344)================
In certain situations, the server could have crashed while processing a hash
join. This has been fixed.
================(Build #2183 - Engineering Case #557973)================
If an index already existed on a particular set of columns, attempting to
create a unique index over the same set of columns might have failed, if
the index contained deleted, but not cleaned, entries. This has been fixed.
Note, a work around would be to call sa_clean_database manually before creating
the index.
================(Build #2183 - Engineering Case #536347)================
Executing a LOAD TABLE statement with the clause CHECK CONSTRAINTS OFF, may
have failed if the table being loaded had publications. This has been fixed.
================(Build #2182 - Engineering Case #565102)================
If an application executed a PHP external environment procedure, and the
PHP procedure subsequently called exit, then the server would have taken
up to 5 seconds to return control to the application, and would then have
displayed a dropped connection message in the console. This problem has now
been fixed.
================(Build #2182 - Engineering Case #563835)================
The server uses column statistics to aid with query optimization. The statistics
are stored in the database catalog and are loaded into memory on demand,
and unloaded when not used for a period of time. Under very rare circumstances,
when running on multi processor systems, it was possible for the server to
think that no statistics existed for a specific column. The problem was likely
to have been self correcting over time and there were no correctness issues.
However, it was possible that the absence of column statistics may have caused
some queries to run inefficiently. This problem has been resolved.
================(Build #2180 - Engineering Case #564677)================
A failed COMMENT ON PROCEDURE statement could have prevented the procedure
from being dropped. This has been fixed.
Note, a workaround is to stop and restart the database before attempting
to drop the procedure.
================(Build #2175 - Engineering Case #563545)================
When executing several remote queries, if the remote queries contained NChar
variables in the WHERE clause, then some of the queries may have returned
an incorrect result. This problem has now been fixed.
================(Build #2174 - Engineering Case #564066)================
When an HTTP connection that had made an external environment call was closed
at the exact same time that the external environment exited, there was a
chance that the server would have crashed. This problem has now been fixed.
================(Build #2174 - Engineering Case #564046)================
The changes for Engineering case 559413 introduced a problem where attempting
to cancel a Java call could have caused the Jave VM to stop responding. This
has now been fixed.
================(Build #2174 - Engineering Case #564010)================
The server may have crashed if a floating point value was converted to a
string, and then subsequently cast to a string with a too small size. This
has been fixed.
================(Build #2168 - Engineering Case #563499)================
When processing a GROUP BY statement with a specific number of aggregates,
it was possible for the server to crash. This has been fixed.
================(Build #2166 - Engineering Case #562826)================
When backing up a database with no transaction log, a client-side transaction-log
only backup (i.e. using the Backup utility) would have caused the server
to crash. A transaction-log only server side backup (i.e. using the BACKUP
statement) did not cause a crash. Although a server side backup did not cause
a crash, the SQL error that was issued in this case gave no indication as
to what the failure actually was, i.e., it reported "Syntax error near
'backup option'". As well as fixing the crash, a more useful SQL error
code/message for the server-side case is now displayed: "Error during
backup/restore: No files are part of this backup".
================(Build #2165 - Engineering Case #562951)================
If a database was created with the DBA user specified as "dba"
(or Dba, DBa, DbA, dBA, dBa, dbA), unloading the database would have failed.
This has been fixed.
================(Build #2164 - Engineering Case #562535)================
The server may have crashed when trying to build a plan containing a hash
filter. This has been fixed.
================(Build #2161 - Engineering Case #562656)================
Attempting to fetch data from a proxy table, when connected using a non-DBA
user, would have failed if the remote server was one of SAJDBC or ASEJDBC.
A permissions problem on the global temporary table used to hold the rows
fetched from the remote server has now been fixed in newly created databases.
For existing databases, log in with a DBA user and execute the following
statement:
grant select,insert,update,delete on dbo.omni_rset_fetch_table to PUBLIC
================(Build #2160 - Engineering Case #562414)================
In exceptionally rare circumstances, the server could have hung during startup.
This hang would only have occurred when the server was run on a multi-processor
machine. This has been fixed.
================(Build #2160 - Engineering Case #562258)================
On Windows 2003, and sometimes on Windows XP, it was possible to start both
a personal server and network server which listened on the same TCPIP port.
If this occurred, clients could unexpectedly, and unreliably, get "Database
server not found" errors. This has been fixed As part of this change,
network servers on Windows Vista and Windows 2008 no longer start a TCPIP
listener on the 127.0.0.1:<port> address by default. Connections to
this address are still accepted by the TCPIP listener which starts on the
0.0.0.0:<port> address.
================(Build #2160 - Engineering Case #562171)================
The SQL Anywhere server generates "expression error" messages for
generic semantical problems in queries. Under certain circumstances, the
server could have generated an expression error with a parameter that did
not point to the correct problematic part of the query.
For example, the following query:
select manager_id,
sum(emp_id), max(manager_id) over (order by manager_id rows between manager_id
preceding and salary following) as max_mgr
from employee
where manager_id > 5
group by manager_id, salary, max_mgr
would have resulted in an error "Expression error near 'employee.manager_id
> 5'", rather than the more appropriate "Expression error near
'max(employee.manager_id) over( ... ) ... as max_mgr". The real problem
with this query is that the alias 'max_mgr' cannot refer to a window aggregate
expression, as the alias is part of the group by list.
This problem has been resolved.
================(Build #2157 - Engineering Case #561839)================
There was a possibility, although small, that a busy SQL Anywhere server
may have truncated HTTP response data. This has been fixed.
================(Build #2157 - Engineering Case #560935)================
Restoring a database from a backup archive using the RESTORE DATABASE command
with the RENAME option could have corrupted the transaction log associated
with the restored database. Translating the transaction log file using the
dbtran.exe utility would have resulted in an error indicating that the log
was missing a CONNECT operation. This has been fixed.
================(Build #2157 - Engineering Case #559844)================
If a query execution plan used a multiple index scan with an Except Merge
operator (EM), then it was possible for the statement to fail with an assertion
failure such as the following:
Assertion failed: 106502 - NULL in not-NULL work table column
In order for the failure to occur, one of the indexed columns in the query
must have been declared not-NULL. This has been fixed.
================(Build #2156 - Engineering Case #561554)================
It was possible for the server to crash while processing a specific builtin
function in the context of a procedure. This has been fixed.
================(Build #2156 - Engineering Case #561553)================
When a query of the form "SELECT f(c) from t where t.c < 5",
where f() was a user-defined function and t was a proxy table, was executed
the server would have attempted to push the "where c < 5" to
the remote server in order to reduce the number of rows being returned. Unfortunately,
due to the fix for Engineering case 555959, this behaviour was changed such
that the WHERE clause was no longer getting pushed to the remote, resulting
in more rows being fetched from the remote than necessary. Note that the
fix for case 555959 resulted in a performance degradation only, the resulting
result set was still correct. Nevertheless, this has now been resolved and
the WHERE clause will now properly be pushed to the remote server when it
is safe to do so.
================(Build #2156 - Engineering Case #561524)================
Under very specific and rare memory conditions, the server could have crashed
while performing a sort. This has been fixed.
================(Build #2156 - Engineering Case #561321)================
When aggregate functions processed a NULL value for one or more rows, they
generate the following warning: (SQLCODE 109) "Null value eliminated
in aggregate function". If the aggregate function was specified with
DISTINCT for its argument, this warning was not set for execution plans that
used the SingleRowGroupBy or OrderedGroupBy execution algorithms. This has
now been corrected.
================(Build #2156 - Engineering Case #561311)================
Executing a MESSAGE ... IMMEDIATE statement shortly before a connection was
disconnected, could, in rare timing dependent cases, have caused the application
to crash, or the message callback to run after the connection was disconnected.
This has been fixed.
================(Build #2156 - Engineering Case #557465)================
In exceptionally rare circumstances, the server may have crashed during the
rewrite phase of optimization, when attempting to execute a very large and
complex SELECT statement. This may have occurred when the server was close
to running ouf of stack space, or was low on cache. The problem was seen
with queries containing UNION, EXCEPT, INTERSECT, and deeply nested subselects.
This has been fixed. The server will now correctly return the error "-890:
Statement size or complexity exceeds server limits".
================(Build #2154 - Engineering Case #560678)================
If a database's CHAR collation was a tailored UCA collation with a sorttype
specified, then comparisons for catalog strings (such as table names and
user names) would have incorrectly ignored the sorttype. For example, the
Swedish collation UCA(locale=swe; sorttype=phonebook) considers 'v' and 'w'
to be different characters at the primary level; however, those letters would
have been considered equal during catalog string comparisons, as if the catalog
collation were UCA(locale=swe) with no sorttype specified. This problem has
been fixed.
================(Build #2153 - Engineering Case #560902)================
Complex queries involving proxy tables may have cause the server to crash.
Some known instances of this issue have been fixed.
================(Build #2151 - Engineering Case #564701)================
Executing a CREATE TABLE IF NOT EXISTS ... statement would have failed if
the table existed, but had not yet been used since the database was started.
This has been fixed.
================(Build #2151 - Engineering Case #560107)================
Table names in case insensitive databases are required to be unique under
case insensitive comparisons, e.g., names FOO and foo refer to the same table.
In some cases, the server may have allowed multiple tables with the same
name that differed only in case to be created. This has been fixed so that
the server will now generate the expected error.
Note, once a database contains multiple tables with the same names, all
variations of the name will refer to the same (somewhat non-deterministic)
instance of the table. The situation can be corrected by dropping and recreating
the tables. Any existing data needs to be saved and restored as necessary.
================(Build #2151 - Engineering Case #559822)================
If the optimizer selected a parallel execution plan for a query with a GROUP
BY operator on the right hand side of a nested loops join, and the group
by contained an AVG or other composite aggregate function, then it was possible
for the statement to incorrectly generate the error: "Field unexpected
during compilation". In this case the server would have continue to
process other requests. This problem has been fixed.
A workaround is to disable parallel plans by setting Max_query_tasks=1 as
a connection option, or in the query OPTIONS clause.
================(Build #2151 - Engineering Case #556175)================
Queries with unflattenable subqueries may have returned incorrect results,
or crashed the server. The following conditions must have been true for
the incorrect result set to have been, or for the server to have crashed:
- the query contained a subquery predicate (e.g., EXISTS() , NOT EXISTS())
which could not be flattened in the main query block, which was used in the
cost-based optimization by the SA Optimizer
- the subquery predicate was correlated to at least two tables from the
main query block
- a correlation expression was equated to a constant in the main query
block
For example:
select *
from f, i, fi
where f.fund_id = 1 <==== f.fund_id is a correlation expression for
the NOT EXISTS() predicate and it is equated to a constant
and f.fund_id = fi.fund_id
and fi.investor_id=i.investor_id
and i.investor_id not in ( select ib.investor_id <=== i.investor_id
is a correlation expression for the NOT EXISTS() predicate
from ba , ib
where f.fund_id = ba.fund_id <==== f.fund_id is a correlation
expression for the NOT EXISTS() predicate
and ib.bank_account_id=ba.account_id
)
================(Build #2150 - Engineering Case #560109)================
A reboot was required after the SQL Anywhere Monitor was installed when it
was to be used as a service. This problem has now been fixed, and a reboot
should no longer be required.
================(Build #2150 - Engineering Case #560056)================
If a connection was forcibly closed by the server (via DROP CONNECTION, liveness
or idle timeout), or was closed by the client libraries because of a liveness
timeout, the client application could have crashed if the next operation
it attempted was to open a cursor
without preparing it. This has been fixed.
================(Build #2150 - Engineering Case #559898)================
If an application made use of one of the Remote Data Access JDBC classes,
and the application then disconnected abnormally, then the connection to
the remote server was never closed. The problem did not exist if the application
used one of the Remote Data Access ODBC classes instead. This problem has
now been fixed.
================(Build #2150 - Engineering Case #559810)================
If an INSERT statement inserted a string into a CHAR or VARCHAR column with
character-length semantics, then it was possible for the server to fail with
the following assertion failure:
100914: string too long when recording operation in transaction log.
In order for the failure to occur, the inserted string must have had byte-length
semantics and it must have contained more characters than the column definition.
Further specific characteristics of the database and statement were needed
to reproduce the problem. This problem has been fixed.
================(Build #2148 - Engineering Case #559440)================
When run on Linux systems, a server that had been handling TCP/IP connections
could have displayed the message "epollerr: Bad file descriptor"
in the console on shutdown. Also, under very rare circumstances on all UNIX
platforms, the server could have experienced problems handling TCP/IP connections.
Both of these problems have now been fixed.
================(Build #2148 - Engineering Case #559413)================
If many connections made concurrent external environment requests, and some
of these requests failed due to thread deadlock, then attempting to close
one of these connections may have caused the client to hang. This problem
has now been fixed.
================(Build #2148 - Engineering Case #559372)================
If an application used one of the connection scoped external environments
(i.e. PHP, PERL or one of the external C environments); and the external
environment failed to start up due to high server load or time-out, then
there was a chance the external environment executable would not have ended.
This problem has now been fixed.
================(Build #2148 - Engineering Case #556123)================
Under certain circumstances, use of the system procedure sa_row_generator()
could have caused the server to crash, or enter an infinite loop. This problem
has been fixed.
Note that the result set of the stored procedure will be empty when the
specified values are not appropriate.
================(Build #2147 - Engineering Case #558973)================
Using the ATLER EXTERNAL ENVIRONMENT ... LOCATION statement to set the executable
path to a MBCS string, could have caused the server to subsequently fail
to launch the external environment. When fetching the external environment
location from the catalog, the server was not subsequently converting the
string to the OS charset. This has now been fixed.
================(Build #2147 - Engineering Case #558756)================
Attempting to execute a query that referenced a view containing a remote
query, could have crashed the server. The crash would have occurred if the
remote query had both GROUP BY and HAVING clauses, and/or aliases. This problem
has now been fixed.
================(Build #2147 - Engineering Case #558753)================
Attempting to cancel an external environment request while the server was
very heavily loaded may have caused the server to crash. Note that this problem
would have been quite rare. The problem has now been fixed.
================(Build #2147 - Engineering Case #558446)================
Executing an insert statement of the form: 'INSERT INTO <remote table>
ON EXISTING UPDATE SELECT * FROM <table>', would have caused the server
to correctly return an error; but, if the application attempted to execute
an insert statement of the form: 'INSERT INTO <table> ON EXISTING UPDATE
SELECT * FROM <remote table>', the server would have crashed. The problem
has now been fixed and the server now correctly returns an error in both
cases.
================(Build #2147 - Engineering Case #558001)================
Under certain circumstances, the server could have computed, and displayed,
incorrect statistics, For example, the selectivity may have been reported
as infinite. This were likely no side effects on query performance related
to this defect, which has now been corrected.
================(Build #2146 - Engineering Case #557311)================
A connection established by an HTTP request to an HTTP listener port, would
have leaked a small amount of memory when the connection was closed. This
has been fixed.
Connections to HTTPS listener ports were not affected by this problem.
================(Build #2145 - Engineering Case #557767)================
If an ALTER TABLE statement needed to rewrite the rows of the table (for
example, if a 17th nullable column is added) and the table contained long
or compressed strings, the operation could have taken much longer than necessary
and the database may have end up with many more free pages than before the
ALTER. The number of extra pages would have been approximately the number
of pages in the table in question. This has been fixed.
================(Build #2145 - Engineering Case #556989)================
The server may have crashed, or returned incorrect data, on GET DATA requests
if the cursor reused a query access plan for a simple SELECT statement. This
has been fixed
================(Build #2145 - Engineering Case #555940)================
Simple statements of the form "select TOP n from T order by T.X [asc|desc]"
may have had a very inefficient query access plan. This has been fixed.
================(Build #2144 - Engineering Case #557953)================
The Index Consultant may have caused the server to crash following query
optimization. The class of queries for which this could happen was characterized
by the existence of a comparison or EXISTS() subquery predicate in one of
the query blocks.
For example:
select * from sales_order_items soi1, sales_order_items soi2
where soi1.id = soi2.id
AND
soi1.quantity <
(
select avg( quantity ) from sales_order_items soi3
where soi3.prod_id = soi1.prod_id
);
This has now been fixed.
================(Build #2144 - Engineering Case #557870)================
If a table containing columns declared as compressed strings was used in
a parallel plan that contained a parallel hash join, it was possible, in
rare circumstances, for the server to have crashed. This has been fixed.
================(Build #2144 - Engineering Case #557802)================
In rare circumstances, server CPU usage could have been unnecessarily high.
The problem would only have occurred with certain layouts of memory within
a heap, and when certain heap operations were being performed on the heap.
This problem has been fixed.
================(Build #2144 - Engineering Case #557794)================
Under certain circumstances, it is possible that database indexes could have
become corrupt. This has been fixed.
================(Build #2144 - Engineering Case #557677)================
The server automatically collects and updates column statistics during the
execution of DML statements. Earlier versions of the server did the auto
collection only when a single DML statement affected more than a threshold
number of rows, in order to reduce the overhead of collecting statistics
on a relative basis. Support was added in release 10.0.1 to also do some
automatic statistics collection on all DML statements, including those affecting
as few as a single row. A subtle defect in this new support caused the server
to miss some opportunities for automatic statistics collection for UPDATE
statements, as opposed to the INSERT and DELETE statements. This has now
been corrected.
================(Build #2144 - Engineering Case #557332)================
If a string column used a UCA collation with accent or case sensitivity,
and the column appeared in an index with order DESC, then the server could
have returned incorrect answers for LIKE predicates on the column. Problematic
LIKE predicates started with a prefix of non-wildcard characters, such as
the following: "T.x LIKE '01234%'". This has been fixed.
================(Build #2144 - Engineering Case #556146)================
The optimizer may have generated a query access plan that used intra-query
parallelism that could not be executed in parallel, by underestimating the
execution cost. This has been corrected by adjusting the costing of such
enumerated plans during the optimization process so that it is closer to
what the server does during query execution. This was done by using a new
property of the partial access plans - "partitioned during execution".
Hence, less than optimal parallel plans are more likely to be estimated as
such by the optimizer.
================(Build #2143 - Engineering Case #557849)================
The Interactive SQL utility (dbisql), or the SQL Anywhere plug-in for Sybase
Central, could have crashed when opening the "Connect" dialog when
run with JRE 1.6.0 update 11. This has been fixed.
Note, SQL Anywhere 11.0.0 and 11.0.1 ship with JRE 1.6.0 update 4, which
does not suffer from this problem.
================(Build #2142 - Engineering Case #556771)================
On Windows platforms other than Windows Vista, performance counters for the
server were not visible in the performance monitor when the server was started
as a service. The code to check if the process was still alive was using
the wrong permissions to open the process. This has been corrected.
================(Build #2141 - Engineering Case #557328)================
If an application logged on the database using a userid with multibyte characters,
and the application subsequently made a Java in the database call, then there
was a chance the Java VM would have failed to start if this was the first
time a Java call was made since the database was started. This problem has
now been fixed.
The workaround is to log in using a userid without non-multibyte characters
and execute a START JAVA statement. Once the Java VM is successfully started,
making Java calls using userids with multibyte characters will work fine.
================(Build #2141 - Engineering Case #556913)================
SQL Anywhere JSON services incorrectly encoded the apostophe (') within a
string to a double backslash (\\), the backslash was not encoded. This has
been fixed so that a backslash is now correctly encoded to a double backslash,
and the apostrophe is not encoded.
================(Build #2141 - Engineering Case #556754)================
When deleting a row containing a CHAR or BINARY (i.e. string) column, there
were some circumstances where the space on the table page for the string
might not have been reclaimed. This problem only occurred with string data
shorter than approximately one page in size, and the string must have been
held active, either in a cursor or in a variable, then inserted into a new
row, and then deleted while still held active. The database cleaner must
also run after commiting the delete, but before closing the cursor or value
holding the string. This has been fixed.
================(Build #2139 - Engineering Case #556552)================
In certain cases, rebuilding a pre-10.0 database to version 10.0 or later
may have failed due to an incorrectly charset-converted database file-name.
The SQL error that was reported was:
"Cannot access file '<incorrectly-converted-file-name>.db'
-- The filename, directory name, or volume label syntax is incorrect."
This issue only occurred when using an OS charset whose label was not used
prior to version 10.0.0, such as "GBK". Additionally, for this
issue to have occurred, the database must have used a different charset than
the OS charset - specifically, the filename must contain characters that
require translation to be valid in the database charset. This has been fixed.
================(Build #2139 - Engineering Case #556516)================
If an application was using one of the JDBC based Remote Data Access classes
(i.e. either SAJDBC or ASEJDBC), and the remote login failed, then there
was a possibility that the error reported would not contain the actual reason
for the failed login. When jConnect throws a JZ00L SQLException, the actual
reason for the failed login is usually contained in a chained SQLException,
rather than the main SQLException. The server will now report the error on
the chained exception instead of reporting the topmost SQLException.
================(Build #2139 - Engineering Case #556162)================
If concurrent connections made DDL changes to the same global temporary table,
then it was possible for the server to fail to reapply the resulting transaction
log using the "-a" server command line option. Normal recovery
should have been performed properly. This has been fixed so that the server
will now be able to apply the transaction logs without error. Existing transaction
logs will work correctly as expected.
================(Build #2139 - Engineering Case #555626)================
If the server used a cached plan for a query with an IN list predicate which
contained a variable, and used the IN list predicate to return the rows in
descending order
using a table index, then the result set may have had fewer rows than it
should have.
For example, if table T1 had an index on column col, then the following
query may have return too few rows:
select * from T1 where col in ( 5, Var1 ) order by a desc;
This has been fixed.
================(Build #2138 - Engineering Case #556163)================
If the sa_validate() procedure was called without arguments, materialized
views were not being validated. This has been fixed.
Note, for changes to the sa_validate() procedure to take effect, the database
will need to be rebuilt with a server containing this fix.
================(Build #2138 - Engineering Case #556154)================
A server participating in mirroring system may have crashed if a mirroring
connection timed out due to liveness, or, on very rare occasions, if a connection
attempt to the partner or arbiter failed. This has been fixed.
================(Build #2138 - Engineering Case #555978)================
Executing a "CREATE PROCEDURE ... LANGUAGE ..." or a "START
EXTERNAL ENVIRONMENT ..." statement when connected to a case sensitive
database, would have failed with an "external environment not found"
error, if the external environment name was not specified in lower-case.
This problem has now been fixed.
================(Build #2138 - Engineering Case #555965)================
In rare and timing dependent circumstances, a request could have hung on
a heavily loaded server. This has only been observed when the request was
a cached statement with host variables containing data larger than the communication
buffer size, after a schema change, set option or drop variable. This has
been fixed.
Note, setting the max_client_statements_cached database option to 0 may
workaround this issue.
================(Build #2138 - Engineering Case #555961)================
The server's log window could have contained garbage characters if a language
DLL was used that was older than the server. There was also a very small
chance that the server could have crashed in this case. This has been fixed.
================(Build #2138 - Engineering Case #555959)================
If an application executed a remote query that involved a User Defined Function,
and the call to the function passed in column references as parameters, there
was a chance the server would have crashed when the server decided to run
the query in partial passthru mode. This problem has now been fixed.
================(Build #2138 - Engineering Case #555936)================
An attempt to drop a database whose page size was larger than the server's
page size, using the 'DROP DATABASE' statement, would have resulted in the
error "An attempt to delete database 'database file' failed", leaving
the reason for the failure unclear. The server will now raise the more specific
error, "Page size too big: 'database file'".
================(Build #2138 - Engineering Case #555808)================
For a query containing a WITH RECURSIVE table, if the estimated cardinality
of the recursive table after the first iteration was lower than 2 rows, the
optimizer would not have set the alternative JNL operator if an alternative
index existed. The resulting execution plans may have been very inefficient,
depending of the number of rows on the right hand side of the JoinHashRecursive
operator. This has been fixed.
Example:
with recursive Ancestor( child) as
(select row_num from rowgenerator R1 where R1.row_num = 1 )
UNION ALL
(select R2.row_num+100
from Ancestor, rowgenerator R2
where Ancestor.child = R2.row_num
) )
select * from Ancestor
Ancestor(child) has exactly one row after the first query block is computed.
Computing the second query block is very efficient if the executed plan is
"Ancestor<seq> JNL R2<row_num>". However, because the
optimizer did not set up the JNL operator, the inefficient plan "Ancestor<seq>
JH* R2<seq>" was executed.
================(Build #2138 - Engineering Case #551255)================
In certain circumstances, the server could have crashed, or otherwise failed,
when executing mutliple LOAD TABLE statements concurrently when in in-memory
no write mode (i.e., the server was started with the "-im nw" option).
This failure was far more likely to occur if one or more of the LOAD TABLE
statements failed with a SQL Error, as would be the case if the file being
loaded from could not be located or opened. There was also a very small
window of opportunity where the server could have crashed, or failed an assertion,
even if none of the LOAD TABLE statements failed. This has now been fixed.
================(Build #2138 - Engineering Case #550695)================
Under rare circumstances, the server could have crashed while trying to load
trigger definitions from the catalog. The error was likely to have occurred
while trying to compile an invalid query. This problem has now been fixed.
================(Build #2137 - Engineering Case #555789)================
In very rare circumstances, the server could have reported assertion failures
101428 or 101424 "Writing page with no position in file." when
running with AWE enabled and under periods of heavy activity or high server
stress. This has been fixed.
================(Build #2137 - Engineering Case #555769)================
If an application, or set of applications, constantly connected, made a Java
call, and then subsequently disconnected, then there was a chance the Java
VM used by the server would have thrown an 'out of memory' exception. This
problem has been fixed.
================(Build #2137 - Engineering Case #555765)================
There was a very small chance that the server would have returned a thread
deadlock error on an external environment call in situations where no actual
thread deadlock occurred. For this problem to have occurred, a previous valid
thread deadlock must have been returned by the server, resulting from a large
number of connections attempting to issue an external environment call at
the same time. This problem has now been fixed.
================(Build #2136 - Engineering Case #555623)================
The following fixes have been made to graphical plan descriptions:
1. Range expressions of a partial index scan are now always printed as "low
expression <[=] column name <[=] high expression [ASC |DESC]".
The low and high expressions can be NULL value if the real fence post was
set to NULL value; they can be '*' if the real fence post is not set (this
is actually an open range partial index scan).
2. Selectivity estimations are now printed with 9 decimal digits.
================(Build #2136 - Engineering Case #555622)================
Lower bounds are imposed on selectivity and cardinality estimates during
the optimization process. These bounds are meant to be greater than 0, but
less than one row of the result set of a physical operator, and are set to
be a very small percentage, which in the case of very big tables, or big
intermediate result sets (> 10,000,000 rows), were actually bigger than
one row. This has been fixed.
================(Build #2136 - Engineering Case #555390)================
If the option PUBLIC.quoted_identifier was set to 'off', executing the reload
script produced by Unload utility (dbunload) would have failed when attempting
to set subsequent options. This has been fixed.
================(Build #2136 - Engineering Case #554889)================
Simple SELECT, UPDATE, and DELETE statements with a specific predicate structure
could have caused the server to crash. A workaround to avoid the crash is
to set the option Max_plans_cached=0. This problem has been fixed.
================(Build #2136 - Engineering Case #553689)================
If a query contained at least two predicates on the same column T.A with
the following conditions:
1. there existed an equality predicate T.A = expression, with a selectivity
estimation of selectivity1, and the expression was not a constant
2. there existed a range predicate on T.A with constant bounds (for example,
T.A > 111), with a selectivity estimation of selectivity2
3. there existed an index on column T.A, where the column T.A may have been
the only column in the index, or the index had a prefix of other columns
before T.A, all of which are equated with constants in the query: e.g., the
index idx<C1, C2, A> is defined, and the predicates 'T.C1 = 10 and
T.C2 = 20 and T.A > 111 and T.A = R.X' are used in the query.
4. The selectivity estimation of the range predicate was much larger then
the selectivity estimation of the equality predicate, i.e., selectivity1
<< selectivity2
Such a query had an overestimated number of rows, and the execution plan
chosen by the optimizer may have been inefficient. This has been fixed.
================(Build #2135 - Engineering Case #555228)================
Under some circumstances the server could have crashed when a table was dropped.
This has bben fixed.
================(Build #2135 - Engineering Case #555181)================
In very rare circumstances, cancelling a DDL statement could have caused
the server to crash, cause corruption or possibly other erratic behaviour.
The cancel would need to have been detected after a DDL completed successfully,
but before the DDL was auto-committed, which is a very tiny window. Whether
or not a problem would be caused by a cancel at that time, and if so, the
nature of that problem also depended on the DDL itself and what the connection
did afterwards. This problem has been fixed.
================(Build #2135 - Engineering Case #554781)================
In a database mirroring system, if the mirror server was starting while the
transaction log on the primary server was being renamed, the primary server
could have crashed. This has been fixed.
================(Build #2134 - Engineering Case #554886)================
Some particular constructions of the LIST aggregate could have caused the
server to crash while processing the statement containing the LIST aggregate.
In order for the crash to occur, the LIST must have contained an ORDER BY
clause. This has been fixed.
================(Build #2134 - Engineering Case #554876)================
If an application established an HTTP session from the PHP external environment,
then the server may have hung or crashed. This problem has now been fixed.
================(Build #2134 - Engineering Case #554854)================
If the evaluation of certain expressions resulted in an error code, it was
possible for memory to be leaked. When this memory leak occured in an INSERT,
UPDATE, DELETE, or SELECT statement, the memory leak would have been transient.
In the case of stored procedures and triggers, this leak could have lead
to a slow increase in the size of the main heap. In that case, less memory
would have been available for caching file pages, or other purposes, until
a reboot. This problem has been fixed.
================(Build #2133 - Engineering Case #553289)================
If a query execution plan contained a SORT operator in a parallel execution
strategy, it was possible for the server to crash while processing the request.
This type of plan can be used during a CREATE INDEX statement. The crash
was timing and load dependent and would have predominantly affected servers
processing requests from multiple connections. This problem has been fixed.
================(Build #2132 - Engineering Case #554273)================
If a database mirroring system was running in asynchronous mode and experienced
a very high rate of transaction log page updates, the mirror server could
have crashed or reported a failed assertion. This has been fixed.
================(Build #2132 - Engineering Case #548870)================
A database could have become corrupted when deleting rows containing long
string (or binary) values that were indexed. The server then may have crashed,
or failed an assertion, when attempting to read rows from the table at a
later time. The server would likely have crashed during full validation of
a table corrupted in this manner. This has been fixed. Dropping and re-creating
the index should be a valid workaround.
================(Build #2130 - Engineering Case #553897)================
If an application used one of the C_ODBC32, C_ODBC64, C_ESQL32 or C_ESQL64
external environments and specified .dll or .so in the external name clause,
then the external environment would have incorrectly added an extra .dll
or .so to the shared object name and then give an error. This problem has
now been fixed.
Note that a workaround is to not specify the .dll or .so in the external
name clause.
================(Build #2130 - Engineering Case #553752)================
If a CREATE SYNCHRONIZATION SUBSCRIPTION statement was executed with an OPTION
clause that gets the option value from a variable (e.g. OPTION sv=@Var) and
the variable was set to null, then the server may have crashed, or inserted
a random option value into the catalogs. This has been fixed so that the
server now returns a sql error (SQLSTATE_BAD_SYNC_OPTION_VALUE) "Synchronization
option '%1' contains semi-colon, equal sign, curly brace, or is null".
================(Build #2129 - Engineering Case #553720)================
If an HTTP/1.1 client made a request on a keep-alive connection, and then
after receiving the response, did not send another full request over the
connection for one minute, the connection would have timed out and sent a
408 Request Timeout status message. This is consistent with the HTTP/1.1
specification, but if the HTTP client was Apache, it would have been confused
by the error message. The behaviour has been changed so that the error status
code is suppressed (and the connection is simply closed) if all of the following
are true:
- A complete request and response have previously been sent on the connection
- No data has been received on the connection since the most recent response
was sent
- The keep-alive timeout has expired
================(Build #2129 - Engineering Case #552311)================
If a SELECT statement contained a procedure call with arguments that contained
column references to other tables in the from clause, the server may have
return a "Column not found" error for these column references.
This would have occurred when the query rewrite process can remove tables
from the query.
For example:
create table T1( a int primary key )
create table T2( a int primary key, c int )
create procedure P1 ( u int ) begin select a from T1 where a = u;
end
select dt.* from T1 left outer join T2 on T1.a = T2.a, lateral( P1(T2.c)
) dt
For every row in T1 the left outer join can return at most one row because
of the join on primary keys. So the query rewrite removed the left outer
join and the table T2 from the query which caused a "Column T2.c not
found" error for the procedure argument. This has been fixed.
================(Build #2128 - Engineering Case #552595)================
In exceptionally rare conditions, typically while the server was under heavy
load or processing many backups on many databases simultaneously, a backup
could hang and the CPU usage of the server could have gone to 100%. This
has been fixed.
A workaround is to use a higher value on the -gn command line switch.
================(Build #2127 - Engineering Case #553064)================
If an application accidentally defined a Remote Data Access server that used
the SAJDBC class and connected back to the same database as the local user
connection, then an error indicating that the server definition was circular
was not displayed. This problem is now fixed and an error message is now
displayed. Note that this problem does not affect SAODBC class remote servers.
================(Build #2127 - Engineering Case #552760)================
If the default port number was already in use (eg. by another server), the
server may have failed to start TCP/IP, rather than choosing a different
port number. If the -z command line option was used, the error "TCP/IP
link, function bind, error code 10013" would have been displayed on
the server console. This would only have happened on Windows Server 2003,
and has now been fixed.
================(Build #2127 - Engineering Case #547498)================
Outer references are expressions used in a nested query block which reference
table columns from the outside of that query block. For example, in the query
below, 'T.Z+1' is an expression used in a subquery referencing the base table
column T.Z of the base table T which is in the FROM clause of the main query
block. Such expressions are now sometimes considered constants inside the
nested query block. These constants are used in many optimizations by the
SA optimizer, such as order optimization, functional dependencies optimization,
and MIN/MAX optimization. Previously, these outer references are always treated
as non-constants.
Q:
select *
from T
where T.X <> (select max(R.Y) from R where R.Z = T.Z+1)
================(Build #2127 - Engineering Case #545353)================
The cardinality estimation of the table expression "P key join F",
where P is the primary key table and F is the foreign key table, was incorrectly
computed in certain cases for multi-column keys. This has been fixed. Now,
the cardinality estimation for this class of table expressions is "card(F)
\ #of rows in F with at least one NULL value for multi-column key".
Example:
ALTER TABLE FOREIGN KEY ( fk1, fk2, ..., fkn) references P (pk1, pk2,...,
pkn)
Q:
select * from
F, P
where F.fk1 = P.pk1 and F.fk2 = P.pk2 and ... and F.fkn = P.pkn
returns all rows from the foreign key table F less the rows having at least
one NULL for the foreign key columns F.fk1, F.fk2, ..., F.fkn.
================(Build #2126 - Engineering Case #552648)================
Renaming a transaction log via a BACKUP statement could have failed as a
result of a transient sharing violation error on Windows. The error may have
been caused by a virus scanner or other software accessing the file as it
is being renamed. This has been fixed.
================(Build #2126 - Engineering Case #552587)================
If an application created a remote server and then accessed that remote server
using a different case than the one specified on the CREATE SERVER statement,
the server would have incorrectly opened additional connections to the remote
server. For example, suppose the application executed the following CREATE
SERVER statement:
CREATE SERVER MyServer CLASS ...
and then created two proxy tables as follows:
CREATE EXISTING TABLE table1 AT 'myserver...'
CREATE EXISTING TABLE table2 AT 'MYserver...'
If the application now queried "table1", the remote data access
layer would have correctly established a connection to the remote and returned
the requested data. If the application then queried "table2", the
data access layer should reuse the connection previously established to the
remote, but the server instead would have created a new connection to the
remote. This problem has now been fixed.
================(Build #2125 - Engineering Case #552465)================
If an application attempted to migrate tables containing unique constraints,
either by using sa_migrate or Sybase Central, then there was a possibility
that the migration would have failed because some of the foreign keys could
not have been created. This problem has now been fixed, but only if the remote
data access class involved is one of SAODBC or SAJDBC.
================(Build #2124 - Engineering Case #553103)================
During the optimization process, the optimizer creates and maintains order
properties for all physical operators placed in the access plans generated
as part of the search space generation process. These order properties are
used to decide if SORT physical operators are needed, for example to satisfy
an ORDER BY clause at the root of the access plan. Maintaining and tracking
order properties are expensive operations as described in [1]. For performance
reasons, the optimizer will now build and maintain only those order properties
needed by an interesting order property, such as the one imposed by an ORDER
BY clause. This change does not affect in anyway the performance of the order
optimization, it just makes the optimization process more efficient.
[1]“Database System with Methodology for Generalized Order Optimization”Matthew
Young-Lai, Anisoara Nica, 2007 US Patent 7,359,922.
================(Build #2124 - Engineering Case #552094)================
When AES_FIPS or AES256_FIPS database encryption was used for a long enough
period of time, the server would have eventually failed to allocate memory,
due to a small memory leak. This included use of the encrypt() or hash()
functions with FIPS algorithms, or if the -fips server command line option
was used. There was also a leak on the client side of approximately 1k per
TLS connection attempted. All of these leaks have now been fixed.
================(Build #2124 - Engineering Case #552066)================
If a SQL Anywhere database used with Replication Server was unloaded using
the Unload utility (dbunload), some tables and procedures used by Replication
Server would not have been included. This has been fixed.
================(Build #2122 - Engineering Case #552057)================
In general, applications that use Java in the database support install the
classes and jars to be used into the database. Doing so allows the database
to be moved from one machine to another, or from one platform to another.
The other benefit of installing classes and jars into the database is that
the SQL Anywhere class loader can then be used to fetch the classes and resources
from the database allowing each connection that is using Java in the database
support to have its own instance of these classes and its own copy of static
variables within these classes. In VERY rare cases, it is beneficial to have
the system class loader load a class instead of the SQL Anywhere class loader.
The only real reason for having the system class loader load the class is
that statics within classes loaded by the system class loader can then be
shared across all connections using Java in the database support. There are
of course many reasons why the system class loader should not be used:
1) since statics are shared across all connections, there is an issue with
the security of data
2) mixing classes loaded by the SA class loader and the system class loader
can lead to the VM throwing IllegalAccess and ClassCast exceptions
3) there is now the danger that the system class loader will get used for
loading classes that should actually have been loaded by the SA class loader
Because of these potentially serious problems, it has always been STRONGLY
recommended that all classes and jars to be used for Java in the database
support be explicitly installed within the database. However, for those rare
cases where the class really needs to be loaded by the system class loader,
the server's classpath argument (-cp) can be used to add directories and
jars to the classpath that the server builds for launching the JVM. Unfortunately,
as of version 10.0, the server's classpath argument was being ignored when
launching the JVM. This problem has now been fixed and the server's classpath
argument is now properly appended to the classpath the server builds when
launching the VM. Again, the use of the server's classpath argument is STRONGLY
discouraged; instead, it is STRONGLY recommended that all classes and jars
to be used for Java in the database support be installed explicitly in the
database.
================(Build #2122 - Engineering Case #551944)================
The fix for Engineering case 549983 introduced a problem such that two simultaneous
remote data access requests from two separate connections could have caused
the server to crash. This problem has now been fixed.
================(Build #2120 - Engineering Case #551750)================
Executing a Java stored procedure that attempted to fetch resources using
getResourceAsStream() or getResource(), would have had the fetch of the resource
fail. This problem has now been fixed.
Note that due to differences in compression schemes, it is strongly recommended
that jars containing textual resources be created without compression turned
on. For jars containing binary resources (ex. movies or images), using a
compressed jar will work fine.
================(Build #2120 - Engineering Case #551740)================
If a query contained an outer join and a predicate of that included the concatenation
operator (||), then the server could have returned the incorrect answer for
the query. In the incorrect case, the outer join was converted to an inner
join. This has been fixed.
For example, the following two queries should be equivalent, but the first
incorrectly returned no rows:
select R.row_num || 'z' x, string(R.row_num ,'z') y
from dummy D left outer join rowgenerator R on 1=0
where x = 'z'
select R.row_num || 'z' x, string(R.row_num ,'z') y
from dummy D left outer join rowgenerator R on 1=0
where y = 'z'
================(Build #2120 - Engineering Case #551739)================
When a TCP/IP connection abnormally disconnected from the server (for example
due to the DROP CONNECTION statement), there was a chance that a network
buffer was leaked. This has been fixed.
================(Build #2120 - Engineering Case #550103)================
Attempting to query a proxy table with a SELECT statement that used the FOR
XML RAW clause would have failed with an "invalid expression" error.
This problem has now been fixed.
================(Build #2119 - Engineering Case #551460)================
In very rare circumstances the server could have crashed when executing Java,
HTTP web procedures, or Remote Data Access RPC calls. This has been fixed.
================(Build #2119 - Engineering Case #551458)================
If an application that was connected using jConnect called DatabaseMetaData.getPrimaryKeys()
to get the primary key information for a table, the key sequence of the primary
key would not have been returned correctly. This problem has now been fixed.
================(Build #2119 - Engineering Case #548625)================
When the -z command line option was used, or when request level logging was
enabled, the server could have generated thousands of message of the form:
"Internal warning: <x> dispatch took <y> seconds"
where x is an object name and y is a number. This would have affected the
Windows platform only, and not necessarily on all Windows machines. This
has now been fixed.
A workaround is turn off the -z option or request level logging.
================(Build #2117 - Engineering Case #551112)================
If a database mirroring server encounters a failed assertion, the desired
behaviour is for the server to exit. This allows the mirroring partner server
to detect that a failure has occurred and take an appropriate action. After
a failed assertion on Windows, the server was exiting in such a way as to
cause Windows to display a dialog noting the abnormal exit. This prevented
the server from actually exiting until action was taken to clear the dialog,
and thus prevented the partner server from being notified. This has been
fixed.
In addition to this change, customers should consider configuring dbsupport
to ensure that it does not prompt when a failure occurs. For example:
dbsupport -cc autosubmit
or
dbsupport -cc no
A future version of the software may avoid the need to configure dbsupport
to prevent prompting in this situation.
================(Build #2116 - Engineering Case #550841)================
Entity headers and a response body should not have been returned by a web
service having explicitly set a 'Not Modified' HTTP status via a call to
sa_set_http_header ( '@HttpStatus', '304' ). The following response headers
were being returned:
Transfer-Encoding: chunked
Expires: ... GMT
Content-Type:...
As an artifact of the chunked transfer encoding, a response body consisting
of a 0 chunk length was returned. This has been corrected so that a response
body and the above headers will not be sent by the server when a 304 'Not
Modified' HTTP status has been explicitly set.
================(Build #2116 - Engineering Case #550803)================
When using the system procedure xp_sendmail(), if the message body contained
a period "." on a line by itself, text following that line would
have been removed from the message that was sent. A line containing a single
period is the end-of-message marker for the SMTP protocol. When sending a
line that begins with a single period, clients must precede it with another
period character, which xp_sendmail() was not doing. This has been fixed.
================(Build #2116 - Engineering Case #550729)================
The user-supplied comment clause provided by the WITH COMMENT clause that
may accompany the BACKUP statement was written to the backup.syb log in the
database character set, rather than the OS character set. All other information,
such as database name is written in OS charset. This has now been fixed.
================(Build #2116 - Engineering Case #550716)================
If an application updated a proxy table and then queried the TransactionStartTime
property, the value returned by the property would not have been properly
updated. This problem has now been fixed.
================(Build #2116 - Engineering Case #550676)================
Attempting to construct a string value longer than the server's maximum string
length (2^31-1) would have resulted in silent trucation of string data.
For example, the statement:
select length(repeat('a', 2000000000) || repeat('b', 2000000000))
returns 2147483647 (i.e., 2^31-1) characters, but does not raise a SQL error
to indicate the operation failed and truncated the string data. This has
been fixed so that SQL Error -1313 MAX_STRING_LENGTH_EXCEEDED will now be
generated whenever an operation attempts to construct a string value longer
than the server's internal maximum string length.
================(Build #2116 - Engineering Case #549396)================
Some arithmetic expressions in procedure statements could have been evaluated
with the incorrect result domain. This would have occurred when one of the
arguments had one of the following domains { BIT, TINYINT, UNSIGNED SMALLINT,
SMALLINT } and the other argument was either one of those domains or INT.
The result domain would have been INT. In some cases this could have lead
to a different result being returned than expected, for example if an overflow
would have occurred in the correct result domain. This problem has been fixed.
================(Build #2116 - Engineering Case #547213)================
The server could have looped forever executing a REORGANIZE TABLE statement.
This should only have occurred if the table had a clustered index that contained
non-unique values in the clustered column or columns. This has been fixed.
================(Build #2115 - Engineering Case #550555)================
The server could have crashed when executing the WRITE_CLIENT_FILE() function,
or when unloading a table to a client file. This failure was more likely
when the data being written was large (on the order of tens of megabytes),
and when the server was heavily loaded. This has been fixed.
================(Build #2114 - Engineering Case #550267)================
If an application set the java_vm_options option, and then attempted to start
the Java VM on a Unix system, there was a chance the extra VM options would
not have been used when the VM was launched. This problem has now been fixed.
Note that this problem does not exist on Windows platforms.
================(Build #2114 - Engineering Case #550252)================
If an application made a remote procedure call that contained output parameters
of type Float, and the remote server for that RPC was using one of the SAJDBC
or ASEJDBC classes, then the value of the Float output parameter would always
have been 0. This problem has now been fixed.
================(Build #2114 - Engineering Case #550246)================
If an application attempted to create a proxy table to a SQL Anywhere or
Micrsoft SQL Server remote server, and the remote table had an XML column,
then the server would have returned an undefined data type error. This problem
has now been fixed.
================(Build #2113 - Engineering Case #550116)================
In rare cases, a stored procedure call could have caused a server crash.
This has been fixed.
================(Build #2113 - Engineering Case #549940)================
If a transaction log was not completely written out to disk (e.g. during
a low disk space scenario), it was possible for the server to crash when
trying to apply a partial log operation during recovery. This has been fixed.
================(Build #2112 - Engineering Case #549983)================
If an application executed a query involving both proxy tables and local
tables, and the query had IN predicates that contained subqueries involving
proxy tables, then there was a chance executing the query would have caused
a server crash. This problem has now been fixed.
================(Build #2112 - Engineering Case #548260)================
The function REGR_R2( Y, X ) incorrectly returned NULL as the answer when
COUNT(*) * SUM( Y * Y ) was equal to SUM(Y) * SUM(Y). This has been corrected
so that the server will now return the correct answer of 1.
================(Build #2107 - Engineering Case #549085)================
A heavily-loaded server could have hang while running diagnostic tracing
with a high detail level. This has been fixed.
================(Build #2052 - Engineering Case #566058)================
Under very rare circumstances, a query plan using a hash join in an EXISTS
subquery could have caused the server to crash. This has been fixed.
================(Build #2052 - Engineering Case #564828)================
Following a cursor OPEN for a simple select statement that bypasses optimization,
the SQLCOUNT value could have been incorrectly set to 0, when the number
of rows was to be exact (ie. Row_counts was 'on'), and the number of rows
was estimated to be 0 . This has been fixed so that the correct setting
is now -1 in these cases.
================(Build #2050 - Engineering Case #545528)================
Inexpensive statements may have taken a long time to optimize (i.e. OPEN
time was high), or may have had inefficient access plans. This has now been
fixed. The only condition required for this to happen was that the parallel
access plans were considered by the optimizer.
For more info on intra-query parallelism see:
SQL Anywhere Server - SQL Usage
Query Optimizer
Query optimization and execution
Query execution algorithms
Parallelism during query execution
This change is particularly important when moving to version 11.0.1, from
10.0.1 or 11.0.0, and running the personal server (dbeng11). The 10.0.1 personal
server (dbeng10) and 11.0.0 personal server (dbeng11) are restricted to using
only one CPU, and only one core if the CPU has multiple cores.
Also, the 10.0.1 optimizer did not consider the number of maximum concurrent
threads (i.e. ConcurrentThreads global variable), and may generate parallel
plans which will not be executed in parallel by the 10.0.1 personal server,
only one parallel branch will process all the rows. This is a bug which was
fixed in 11.0.0 GA.
The 11.0.1 personal server can use all the cores available in one CPU, which
means the 11.0.1 optimizer will cost and generate access plans using parallel
physical operators when multiple cores are available. This difference in
behaviour related to the number of cores allowed to be used by the personal
server may result in a very different access plan being executed by 11.0.1
compared to the access plan executed by 11.0.0, for the same SQL statement.
================(Build #2047 - Engineering Case #563541)================
The server could have used an incorrect selectivity estimate for a predicate
containing IS [NOT] TRUE, IS [NOT] FALSE, or IS [NOT] UNKNOWN. This could
have lead to ineffecient access plans. This has been fixed.
================(Build #2046 - Engineering Case #559192)================
If an application fetched columns of type NUMERIC, DATE, TIME, or TIMESTAMP,
and the column was bound as a string in the client application, then performance
could have decreased. The slowdown was most apparent in statements where
a large number of rows were fetched with relatively little server processing
per row. This has now been fixed.
================(Build #2046 - Engineering Case #556127)================
If the server could not find a transaction log file when attempting to start
a database that needed recovery, it would have returned the misleading error
"Specified database not found" (SQLCODE -83). This has been fixed.
The error now returned in this situation is "Cannot open transaction
log file -- <filename>" (SQLCODE -106).
================(Build #2045 - Engineering Case #568216)================
On Advanced Edition servers, the value of the ServerEdition server property
was incorrect. This has been corrected.
================(Build #2589 - 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 #2569 - 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 #2564 - 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 #2550 - 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 #2545 - Engineering Case #654434)================
When sorting the plug-in names in the Plug-in dialog, an exception would
have been thrown if a plug-in was first reloaded. This has been fixed.
================(Build #2540 - Engineering Case #652248)================
Clicking 'Apply' on the Auditing tab filter pane, could have thrown an exception
causing Sybase Central to crash. This has been fixed.
================(Build #2539 - 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 #2537 - 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 #2535 - Engineering Case #651491)================
Typing Ctrl-Z in an unmodified editor would have marked it as modified. This
has been fixed.
================(Build #2523 - Engineering Case #648191)================
In the Text Configuration Object wizard, the minimum term length could have
been set to a value that exceeded the maximum term length. This has been
fixed.
================(Build #2522 - Engineering Case #630179)================
On the Connected Users or All Connected Users tabs, if two or more connections
were selected, and clicked on File->Disconnect, then Sybase Central would
have crashed. This has been fixed.
================(Build #2510 - Engineering Case #645005)================
When using the Unload or Extract Database wizards, if unload/extract into
a new database was chosen, and Strong encryption was specified with an encryption
key that didn't match the confirm encryption key, then the wizards would
have continued to report a key mismatch error even after the encryption type
was changed to Simple (where the encryption key is not used). This has been
fixed.
================(Build #2505 - Engineering Case #643698)================
On Mac OS systems, the Create Database wizard would have remained open after
successfully creating a database. With the Cancel button disabled, it was
necessary to click the Close box to close the wizard. Now, the wizard is
automatically closed when database creation is successful.
================(Build #2503 - Engineering Case #643457)================
Clicking the Back or Next button may not have updated the toolbar buttons
properly. This has been fixed.
================(Build #2500 - Engineering Case #642889)================
The changes for Engineering case 615994 introduced a problem where refreshing
the Domains folder, after having selected a non-proxy table's Columns tab,
would have caused a "Resource
governor" error. This has been fixed.
================(Build #2498 - Engineering Case #641998)================
When in Debug mode, the SQL editor for a view, trigger, procedure, function
or event, contained a menu item and toolbar button for the Query Editor,
even though the contents of the editor could not be modified. Similarly,
the SQL editor for a trigger, procedure or function, contained menu items
for translating the SQL to Watcom-SQL or Transact-SQL
dialects. Now, these menu items and toolbar buttons are no longer displayed.
================(Build #2478 - Engineering Case #637505)================
Opening the property sheet for an article that referenced a subset of a table's
columns and clicking the Cancel button to close it, would have caused the
subset of columns to not have been displayed the next time the property sheet
was opened. Pressing F5, or selecting View -> Refresh in the main Sybase
Central window, was required to get the property sheet to correctly display
the set of columns in the article. This has been fixed.
================(Build #2476 - Engineering Case #637026)================
Characters from a charset other than the one the computer usually operates
in could have been displayed as boxes in the text above the tabs in the right
pane. This has been fixed.
================(Build #2472 - Engineering Case #636305)================
When the transaction log contained many entries, sorting of the audit table
could have been very slow. This has been fixed by no longer allowing the
audit table to be sortable.
================(Build #2469 - Engineering Case #635629)================
If the Platform field on the Overview page had a long name, the horizontal
splitbar could not be moved to view it. This has been fixed.
================(Build #2464 - Engineering Case #634675)================
Sybase Central could have crashed when attempting to view the data of a table
after dropping the table's primary key by some means other than Sybase Central
(for example, via the Interactive SQL utility), and then refreshing the Sybase
Central viewer via F5 or View -> Refresh. This has been fixed.
================(Build #2459 - Engineering Case #636312)================
Selecting 'Undo' or 'Redo' (or typing Ctrl-Z or Ctrl-Y) while viewing a spatial
reference system's Definition tab, a system trigger's SQL tab, a Java class's
Description tab, or an external environment object's Contents tab, would
either have caused Sybase Central to crash or hang, when selecting another
object in the tree. This has been fixed.
================(Build #2459 - Engineering Case #634055)================
When editing a stored procedure or view in a separate window, the "Undo"
toolbar button was not enabled following a paste. This has been fixed.
================(Build #2459 - Engineering Case #634032)================
The 'Find/Replace' toolbar button did not work in an editor window if the
toolbar had been undocked. This has been fixed by preventing the toolbar
from being undocked.
A workaround is to use the menu item or F3 key to open the 'Find/Replace'
window.
================(Build #2459 - Engineering Case #634029)================
Pressing Shift+F10 while a syntax-highlighting editor had focus should have
opened its context menu, but did not happen consistently. This has now been
fixed."
================(Build #2459 - Engineering Case #633799)================
The "Find/Replace" window could have opened without any components
if it was opened from a window used to view a stored procedure or view. The
window typically contained only a grey or white rectangle. The problem happened
only when opening a file in the editor window, or when clicking "File/New".
This has now been fixed.
================(Build #2459 - Engineering Case #633784)================
The "Tools" button on the "Connect" window, and any toolbar
buttons in Sybase Central which have drop-down arrows, were drawn without
the usual button border and background gradient on Linux and Solaris computers.
This has now been fixed so that they have the correct background and border.
================(Build #2458 - Engineering Case #636304)================
Opening the Domain, Web Service or Spatial Reference System property dialogs
could have caused the Sybase Central to crash. This has been fixed.
================(Build #2455 - Engineering Case #633031)================
Sybase Central could have silently crashed on startup if an OEM.INI file
was installed which contained an entry before a section header. This has
been fixed; the entry is now ignored.
Note, this problem also affected the Interactive SQL and Console utilities,
as well as the MobiLink Monitor.
================(Build #2455 - Engineering Case #633011)================
The Login Mapping wizard's last page did not always display the current login_mode
option setting correctly. This has been fixed.
================(Build #2449 - Engineering Case #632174)================
The Foreign Key wizard could have caused Sybase Central to crash when creating
a second
foreign key on a table, if the creation of the first foreign key on the
table had automatically added a new column to the foreign table. This has
been fixed.
================(Build #2444 - Engineering Case #631122)================
After right-clicking a procedure or function and selecting "Execute
from Interactive SQL", the resulting dialog where the parameters are
specified had a row height for the table that was too small. This caused
text to be clipped in the "Value" column. This has been fixed.
================(Build #2436 - Engineering Case #629078)================
Sybase Central could have run out of memory when displaying a view, trigger,
procedure, event or external environment object in the right pane. This would
normally have occurred only if the Tasks pane was showing in the left pane.
This has been fixed.
================(Build #2436 - Engineering Case #629053)================
When sorting a column in the Data Details panel, an error could have occurred
stating "Error reading row. Accessing a closed connection object."
This has been fixed.
================(Build #2431 - Engineering Case #627756)================
Copying and pasting a table in Sybase Central would have failed if the table
had a primary key with a comment and the owner of the table was changed in
the Table Duplicate dialog. This has been fixed.
================(Build #2424 - Engineering Case #625800)================
Registering the plug-in, but not loading it immediately, would have caused
an exception to occur. This has been fixed.
================(Build #2424 - Engineering Case #625759)================
When in the Procedure debugger, clicking on the header of the breakpoint
icon column caused an error. This has been fixed.
================(Build #2424 - Engineering Case #625647)================
Changing the timestamp_format option from its default value of "YYYY-MM-DD
HH:NN:SS.SSS" could have caused a "Cannot convert '<value>'
to a timestamp" error to have occurred when selecting the Events or
Maintenance Plans folders in the tree. This has been fixed.
================(Build #2424 - Engineering Case #611985)================
Software installs that were built using merge modules (MSM files) created
by the SQL Anywhere Deployment Wizard would have failed to generate the .jpr
files needed to register plugins for Sybase Central. Consequently, the following
error would have occurred:
Error - EXCEPTION: java.io.FileNotFoundException: C:\Program Files\SQL Anywhere
11\java\SQLAnywhere.jpr (the System cannot find the file specified).
A similar error message would also have appeared for the file Mobilink.jpr
This has been fixed, so that MSMs now work correctly as well.
Note, MSI installs built with the Deployment Wizard did not exhibit this
behavior.
================(Build #2422 - Engineering Case #625515)================
Sybase Central did not allow stopping a Windows service in a "Delete
pending" state. This is now fixed. The Stop menu item is now enabled
for running services, regardless of
whether a delete is pending.
================(Build #2419 - Engineering Case #624727)================
Sybase Central could have crashed when opening the Procedures & Functions
folder. This has been fixed.
================(Build #2414 - Engineering Case #623758)================
If an attempt to set a database option in the Options dialog resulted in
the error "Invalid setting for option '<option-name>'", the
Options dialog would then have shown the invalid option value in the options
table the next time the dialog was opened. This has been fixed.
================(Build #2411 - Engineering Case #622934)================
If a file browser was open in Sybase Central, the Interactive SQL utility,
the Console utility, or the MobiLink Monitor, it was possible to crash the
program by clicking on the main application window, pressing the Esc key,
and then closing the file browser. This has been fixed.
================(Build #2401 - Engineering Case #619273)================
On Linux systems, Sybase Central would have hung on start-up when loading
the UltraLite plug-in. This has been fixed.
As a workaround, automatic loading of the UltraLite plugin can be disabled
by editing the file "$HOME/.sybase/Sybase Central 6.0.0/.scUserPreferences600"
and changing the line
"ProviderData/ultralite1101/Autoload=true" to read "ProviderData/ultralite1101/Autoload=false".
================(Build #2400 - Engineering Case #619758)================
When connected to a database running on a Windows Mobile (Windows CE) device,
if the database's Overview tab was selected, then Sybase Central would have
crashed. This has been fixed.
================(Build #2396 - Engineering Case #619388)================
When using Sybase Central's fast launcher, the timeout setting was ignored
and the launcher continued to run. This has been corrected.
================(Build #2395 - Engineering Case #619253)================
Executing any query in the Query Database dialog when debugging and at a
breakpoint, would have always displayed the error "Invalid plan.".
Showing a plan while debugging is not required so the Plan button has been
removed.
================(Build #2394 - Engineering Case #619039)================
The Execute Query menu item was enabled when in the debugger and not at a
breakpoint. This has been fixed.
================(Build #2391 - Engineering Case #618639)================
When viewing the Application Profiling "Details" pane for a large
trace, the pane could have taken a very long time to paint. This has been
fixed. Although the pane may still take several seconds to paint, it should
be two orders of magnitude faster.
Note, users who do not have this fix can still view the underlying data
by manually by querying the sa_diagnostic_* tables as described in the documentation.
================(Build #2390 - Engineering Case #618244)================
In the Options dialog, when disabling or enabling the fastlauncher checkbox,
the "Configure..." button was not disabled or enabled as appropriate
as well. This has been fixed
================(Build #2384 - Engineering Case #616956)================
When clicking the 'View Code' button in the breakpoints dialog, the error
"The source code could not be displayed for the <procedure/event/trigger>
because the database filter is excluding it." may have been shown. This
has now been fixed.
================(Build #2382 - Engineering Case #615481)================
When doing a 64 bit install, if only the SQL Anywhere and Administration
Tool features were selected, some operations in Sybase Central would have
failed. This has been fixed.
================(Build #2381 - Engineering Case #616437)================
Selecting a server's "All Connections" tab could have caused an
error and fail to display the list of connections, if Sybase Central was
connected only to the server's utility database. This has been fixed.
================(Build #2381 - Engineering Case #616435)================
When using the Create Database wizard to create a database on the local machine
while having no servers running the local machine, the newly created database
would have been started on the server, but would not have been the local
machine's default server. This has been fixed.
================(Build #2379 - Engineering Case #615994)================
If a domain was created after editing columns in a table, then the newly
created domain would not have appeared in the Table Editor's Data Type drop-down
list until the table was manually refreshed by pressing F5. This has been
fixed.
================(Build #2375 - Engineering Case #614016)================
Attempting to rename a Maintenance Plan using the wizard would always have
failed with the error "A maintenance plan with the specified name already
exists in this database". The old and new names were not being tracked
correctly by the wizard. This has been fixed.
================(Build #2352 - Engineering Case #607303)================
If F5 was pressed, or View -> Refresh Folder was selected, while creating
a new table in the Table Editor and Yes was answered when prompted to save
the table, right-clicking to display a popup menu would have failed. This
has been fixed.
================(Build #2351 - Engineering Case #607048)================
When using the Table Editor for SQL Anywhere or UltraLite, or when using
the Table Mapping Editor for MobiLink, a check box would sometimes have required
two single clicks to change its value. This has been corrected so that only
a single click is sufficient.
================(Build #2350 - Engineering Case #606841)================
When using the Table wizard to create a new table, if the F5 key was pressed
before saving the table, and answering 'No' to the "Do you want to save
changes" dialog, would either have caused Sybase Central to crash or
have caused the dialog to have been displayed repeatedly. This has been fixed.
================(Build #2350 - Engineering Case #606726)================
If the Table editor or the Column property sheet was used to change a column's
data type and its unique setting to 'not unique', then the change from 'unique'
to 'not unique' would have been ignored. This has been fixed.
================(Build #2327 - Engineering Case #592976)================
When using the debugger in the Sybase Central, right-clicking in the Editor
to show the popup menu would have make the cursor disappear. This has now
been fixed.
================(Build #2325 - Engineering Case #592467)================
There was an arbitrary limit of 1000 on the number of messages which could
be shown on the "Messages" or "Archive Messages" tabs
for a message store. That limit has now been relaxed. If there is enough
memory to display all the messages, they will be displayed. Under low memory
conditions, only the last 1000 messages will be displayed, but a warning
message will now be displayed in this case.
================(Build #2320 - Engineering Case #591832)================
When using the debugger in the Sybase Central, a NullPointerException could
have been thrown when leaving debugging mode. This would likely have occurred
infrequently, but has now been fixed.
================(Build #2320 - Engineering Case #591824)================
When running on Windows Vista, menu items that toggle a property on or off
would not always have shown the check mark next to the menu item's text.
Similarly, menu items that choose a value from a mutually exclusive set of
values would not always show a sphere next to the currently selected value.
Both of these problems have now been fixed.
================(Build #2317 - Engineering Case #590803)================
When using the debugger in Sybase Central, sometimes a breakpoint was hit
and the error "The source code could not be displayed for the <procedure/event/trigger>
because the database filter is excluding it." was incorrectly shown.
This has now been fixed.
================(Build #2314 - Engineering Case #589829)================
Selecting the Data tab for either an invalid or disabled view, or a disabled
or truncated materialized view, would have caused Sybase Central to crash
when attempting to recompile and/or refresh the view. This has been fixed.
================(Build #2302 - Engineering Case #586188)================
Opening the Events folder could have caused a "Can't decode condition
name" error if an event was created via Interactive SQL utility, instead
of via Sybase Central. This has been fixed.
================(Build #2279 - Engineering Case #582808)================
The Apply button on a property sheet could have become enabled even when
no changes had been made on the property sheet. For this to have occurred,
the property sheet had to contain a formatted text field or spinner control.
This is now fixed.
================(Build #2278 - Engineering Case #582186)================
The "View Data in Interactive SQL" menu item was not always enabled
or disabled appropriately. Specifically, for views owned by SYS, the menu
item was disabled, rather than enabled; for invalid, disabled and uninitialized
views, the menu item was enabled, rather than disabled. Now, the menu item
is only enabled for non-materialized views which are valid, and materialized
views which are both enabled and initialized.
================(Build #2274 - Engineering Case #581622)================
If multiple Java classes, or external environment objects, were selected
in the right pane and File -> Print... was select from the menu, then
multiple Print dialogs would have been shown. Now a single Print dialog is
shown.
================(Build #2272 - Engineering Case #581036)================
Sybase Central running on Windows systems with the zh_HK locale would have
defaulted to zh_CN instead of EN. This occurred because jdk1.6 added a new
country code for Hong Kong.
The problem hass now been fixed.
================(Build #2272 - Engineering Case #580743)================
Editing a table on the "Data" tab in Sybase Central, or in the
"Results" panel of the Interactive SQL utility, could have left
the table locked until the tool disconnected from the database. The table
lock could in turn have prevented other operations in Sybase Central from
completing (e.g. the Unload Database wizard in the SQL Anywhere plug-in,
or the Deploy wizard in the MobiLink plug-in). This has been fixed.
================(Build #2270 - Engineering Case #580057)================
Using Sybase Central to triggering an event in a 9.x database, would have
produced the error "Procedure 'sa_conn_list' not found" after the
event was triggered. This has
been fixed.
================(Build #2262 - Engineering Case #577938)================
Sybase Central could have occasionally reported an internal error on startup,
when the Fast Launcher option was turned on. This has been fixed.
================(Build #2251 - Engineering Case #574022)================
When editing a table's schema using the table editor, the Cut, Paste, Delete
and Undo toolbar button enabled states would not have been updated if the
Ctrl key accelerators were used to perform these operations. This has been
fixed.
================(Build #2248 - Engineering Case #573427)================
When creating, duplicating or renaming an object, Sybase Central would have
performed a case-sensitive comparison to determine if an object with the
same name already existed in the database. Now, a case-insensitive comparison
is performed.
================(Build #2237 - Engineering Case #571643)================
When editing a table's schema with the table editor, typing a Ctrl or Alt
key combination could have initiated editing of the focused cell and either
selected a menu item or opened a menu. This has been corrected so that typing
a Ctrl or Alt key combination now performs the latter operation,and does
not initiate editing.
================(Build #2222 - Engineering Case #569797)================
When unloading or extracting a database into a new database that was created
with strong encryption, the Unload and Extract Database wizards would have
display the encryption key in plain text in the Unload or Extract Database
Messages Dialog. This has been corrected so that now the encryption key is
displayed as "***".
================(Build #2221 - Engineering Case #569124)================
When a Synchronization Model was modified to include either handle_DownloadData
or handle_UploadData events, the model file could not have then been re-opened.
An error message would have been displayed stating "unknown or missing
event ID handle_DownloadData" or "unknown or missing event ID handle_UploadData".
This has been corrected.
================(Build #2213 - Engineering Case #568426)================
When browsing permissions for tables and views, a user might have been listed
more than once on the Permissions page of the property sheet for a table
or view. Similarly, a table or view might have been listed more than once
on the Permissions page of a user's property sheet. When fetching permissions,
rows with the same grantee but different grantor, were not properly grouped.
This has been fixed.
================(Build #2211 - Engineering Case #568632)================
When viewing table data for a SQL Anywhere database, Sybase Central could
have reported an internal error. This has been fixed. The problem was highly
timing dependent.
================(Build #2210 - Engineering Case #568475)================
On the Basic Dbmlsync page of the Synchronization Profile's property sheet,
only a single publication could have been specified. In addition, if a synchronization
profile was created with multiple publications via the Interactive SQL utility,
then the publications would have been lost when the property sheet was used
to modify the synchronization profile. Now the property sheet supports multiple
publications.
================(Build #2209 - Engineering Case #556960)================
The "Join Type" value on the "Join" page of the Query
Editor could not be reset to its initial empty value. This has been corrected
so that now it can.
================(Build #2201 - Engineering Case #567556)================
If a SQL Remote user was copied to the clipboard and the Message Types tab
was selected, and then right-clicked within the right pane, a Paste menu
item would have been shown. This menu item would never have been enabled
after a SQL Remote message was copied to the clipboard. This has been fixed
so that the menu item is no longer present.
================(Build #2186 - Engineering Case #565663)================
The German (DE), French (FR), and Chinese (ZH) language help files were missing
for Sybase Central 6.0.0. This has now been corrected.
================(Build #2160 - Engineering Case #562456)================
Changing a column's data type via its property sheet would have been reflected
immediately in the Table editor when switching pages in the property sheet.
As well, the change would not have been reverted if Cancel was clicked in
the property sheet. This has been fixed.
================(Build #2160 - Engineering Case #562318)================
A column check constraint's property sheet did not show the constraint's
column, while a table check constraint's property sheet showed a "Column:"
label with an no column name. A boolean test on the constraint type was inverted.
This has been fixed.
================(Build #2157 - Engineering Case #561801)================
In rare circumstances, selecting a table in the tree and clicking its Data
tab, would either have caused an "Invalid ORDER BY specification"
error or the table's rows would not be sorted by the primary key. This has
been fixed.
================(Build #2148 - Engineering Case #559360)================
Sybase Central allowed for explicitly adding members to, or removing members
from, the diagnostics group, but in some instances the members would not
have actually been added or removed. This has been fixed by no longer permitting
this. Now members can be added to, or removed from, the diagnostics group
implicitly by granting or revoking Profile authority via the user's properties
dialog. In addition, Sybase Central no longer allows deleting the diagnostics,
rs_systabgroup and SA_DEBUG groups, nor change any of these groups to users.
================(Build #2148 - Engineering Case #559197)================
When creating a new user, or changing an existing user's Profile authority
setting, Sybase Central would not have always updated its group memberships
in the Users & Groups folder. This has been fixed.
================(Build #2144 - Engineering Case #556453)================
Newly added or modified DATE values on the "Data" tab for a table,
could have been displayed using the canonical YYYY-MM-DD format rather than
that specified in the "Date_format" database option. This has been
fixed.
================(Build #2142 - Engineering Case #556447)================
When editing a DATE value in the "Results" pane of the Interactive
SQL utility (dbisql), or on the "Data" tab in the SQL Anywhere
plug-in for Sybase Central, if the date was typed in, rather than using the
date chooser dialog, the value entered was ignored when the value was updated.
This has been corrected so that the value entered is now sent to the database.
================(Build #2140 - Engineering Case #556724)================
Using the "Request Logging" page of a server's property sheet to
attempt to enable request level logging for all connections to a database,
or for a single connection, would have caused Sybase Central to crash. This
has been fixed.
================(Build #2138 - Engineering Case #555827)================
When using the Create Table wizard to create a new table, or the Table Duplicate
dialog to duplicate a table, the default_value for the dbspace option was
ignored; that is, the dbspace selection in the wizard or dialog would have
always defaulted to "system". This has been corrected so that it
now defaults to the value of the default_dbspace option, if the option value
corresponds to the name of a dbspace.
================(Build #2135 - Engineering Case #555211)================
Sybase Central would have crashed when attempting to use the Column property
sheet to rename a column that had not yet been saved to the database. This
has been fixed.
================(Build #2133 - Engineering Case #554373)================
Sybase Central would have crashed if the server was shut down while the Performance
Monitor tab was displayed. This has been fixed.
================(Build #2133 - Engineering Case #554369)================
Using the property sheet to rename a primary key, foreign key or unique constraint,
could have caused Sybase Central to crash. This has been fixed.
================(Build #2129 - Engineering Case #553759)================
The "Replace All" action in the syntax highlighting editor could
have corrupted the text if the action was restricted to the selected text.
This has been fixed.
================(Build #2124 - Engineering Case #552355)================
The table editor could have crashed when the Compressed column heading was
selected. It could also have crashed when opening, if the last time a column
heading was selected in the Table editor, the Compressed column was selected.
This has been fixed.
================(Build #2122 - Engineering Case #551967)================
Attempting to view a column value which contained image data would have crashed
Sybase Central. This has been fixed.
================(Build #2120 - Engineering Case #551695)================
The Table editor would have allowed the removal of all columns from a new
table (that is, a table which had yet to be saved to the database) by selecting
all columns and then selecting Edit -> Undo, clicking the Undo toolbar
button, or typing Ctrl-Z. This has been fixed. Now attempting to remove all
columns from a new table causes an error dialog to be displayed.
================(Build #2117 - Engineering Case #551146)================
When creating or renaming an object, if the name specified was a SQL keyword,
Sybase Central could have erroneous issued a warning that the specified name
would need to be double-quoted when used in a SQL script. This has been fixed.
Now, Sybase Central only issues a warning if the specified name is both a
SQL keyword and a SQL reserved word.
================(Build #2117 - Engineering Case #549461)================
When attempting to update data in a proxy table on the "Data" tab
in Sybase Central, or by manipulation of the result set in the Interactive
SQL utility, the operation would have failed with the error "Feature
remove savepoints not implemented." This been fixed.
================(Build #2117 - Engineering Case #545987)================
In the Text Configuration Object wizard, the defaults for the term breaker
and maximum term length were "Generic" and "1" respectively.
These were not particularly useful defaults. They have been changed so that
the wizard now provides a reasonable default for the term breaker based on
the database's CHAR collation, and the maximum term length based on both
the database's CHAR collation and the currently selected term breaker. The
term breaker now defaults to N-gram if the database's CHAR collation is a
Chinese (936ZHO, 950ZHO_HK, 950ZHO_TW, EUC_CHINA, EUC_TAIWAN), Japanese (932JPN,
EUC_JAPAN) or Korean (949KOR, EUC_KOREA) collation; otherwise, it defaults
to Generic. The maximum term length now defaults to 20 if the Generic term
breaker is selected; otherwise, for N-gram it defaults to 2 if the database's
CHAR collation is a Chinese, Japanese or Korean collation, and 4 otherwise.
================(Build #2116 - Engineering Case #550723)================
If the Data tab for a table or view was selected, columns were added, modified
or removed from the table or view, and the Data tab was selected again, then
the column changes would not have been reflected in the Data tab. This has
been fixed.
================(Build #2110 - Engineering Case #550379)================
Sybase Central would have failed to load plugins on start-up when it was
run on Korean Windows systems. The wrong codepage was being used to read
the .jrp file. This has been fixed.
================(Build #2615 - 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 #2614 - 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 #2608 - 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 #2606 - 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 #2602 - Engineering Case #666960)================
When connected to an ASE database, the "Help" menu could have contained
redundant separators. This has been fixed.
================(Build #2591 - 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 #2591 - 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 #2588 - 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 #2587 - 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 #2586 - 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 #2578 - 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 #2575 - 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 #2573 - 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 #2562 - 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 #2554 - 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 #2554 - 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 #2549 - Engineering Case #655607)================
The text in the Favorites sidebar could have disappeared if the mouse was
moved over it. This has been fixed.
================(Build #2546 - 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 #2545 - 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 #2543 - Engineering Case #653929)================
The Interactive SQL utility ignoring the setting of the "Automatically
refetch results" option and assumed it was on. This has been fixed.
================(Build #2538 - Engineering Case #652037)================
The Unload utility (dbunload) could have crashed when attempting to unload
a database into an existing database. A crash would have occurred when a
data-only unload (-d) was being done, and a user or table in the source database
did not exist in the destination database. If the unload was done through
the Sybase Central Unload wizard, the wizard would have crashed. This has
been fixed.
================(Build #2537 - Engineering Case #652075)================
The changes made for Engineering case 644855, to correct a crashing problem
when the Windows desktop appearance was changed, caused fonts to not render
properly in the result set table. Some characters could have been displayed
as boxes in the column headers for result sets. This has been fixed.
================(Build #2532 - Engineering Case #650177)================
Both the Interactive SQL utility and Sybase Central use the same syntax highlighting
editor to display SQL. On Mac OSX systems only, hitting the tab key in the
editor would have caused all the text in the editor to be selected and indented
1 tab stop. This has been fixed. Now, when the tab key is pressed, if any
text in the editor is selected then that text is indented 1 tab, otherwise
a tab character is inserted at the current insertion point.
================(Build #2528 - Engineering Case #649492)================
The Ping utility (dbping) can be used to specify an ODBC driver or driver
manager library (-l option). If the Unix driver manager included with SQL
Anywhere (libdbodmX.so) was used as the argument for the dbping -l option,
dbping would have returned the error 'Failed to load ODBC driver'. This has
been fixed so that dbping can be used with libdbodmX.so.
================(Build #2527 - Engineering Case #649468)================
When a SQL error occurred that was not in the last SQL statement entered,
an error dialog was displayed that had a 'Continue' and a 'Stop' button.
Hitting the escape key had no effect. Thisn has been corrected so that hitting
the escape key on this dialog now selects the 'Stop' action.
For example, open the Interactve SQL utility (dbisql), connect to database
and enter the following:
select * from foo;
select 'hello'
Since there is no table foo, the first statement generates an error dialog
with a 'Stop' and 'Continue' button. Hitting escape here is now the same
as pressing the 'Stop' button.
================(Build #2526 - Engineering Case #649123)================
If editing table data using the "Results Panel", (or the "Data"
tab in Sybase Central), failed because of a database error, the result would
have been a crash (version 11.0.1 and earlier), or an incomplete error message
(12.0.0 and later). This has been fixed so that the software does not crash,
and the complete error message is displayed.
================(Build #2525 - Engineering Case #648045)================
When the Interactive SQL utility (dbisql) was run on AIX systems, interrupting
a long-running statement by pressing CTRL-C would have resulted in dbisql
crashing. This has been fixed.
================(Build #2523 - Engineering Case #648204)================
The changes made for Engineering case 644855 could have resulted in the Interactive
SQL utility (and Sybase Central) crashing when displaying a result set if
run on Windows Vista or Windows 7. This has been fixed.
================(Build #2522 - Engineering Case #647341)================
The OUTPUT...FORMAT FIXED statement wrote DECIMAL, DOUBLE, NUMERIC, SMALLINT,
and TINYINT values left-aligned. They are now correctly written right-aligned,
like the other numeric data types.
Note, There is no guarantee that FIXED format files created by DBISQL use
the same column widths as DBISQLC.
================(Build #2514 - Engineering Case #645986)================
If the database server reported a "definite" rowcount for a query
but then returned fewer than that many rows, dbisqlc could have displayed
a subset of the rows, or possibly no rows at all. This has now been fixed.
When using the "Connect with an ODBC Data Source" option in the
"Action" dropdown list of the "Login" tab of the connection
dialog with the 64-bit versions of the dbisqlc utility and dbmlsync, no
DSNs would have been displayed; and the 32-bit versions would only have shown
DSNs that used an ODBC driver with the same major version of SQLAnywhere
as dbisqlc and dbmlsync. This has been fixed, so that 32-bit and 64-bit versions
now display all SQLAnywhere DSNs defined for SQLAnywhere version 6.0 and
up.
Dbisqlc did not correctly handle certain connection string components which
did not have a shortform (such as the new "Server" parameter).
This problem has been fixed.
================(Build #2512 - Engineering Case #643157)================
When running the deployment wizard, if the main SQL Anywhere install did
not include all components, the deployment could have failed. For example,
if UltraLite was not present, the Deployment Wizard for Windows Mobile would
have raised the following error:
Running CabWiz ...
CabWiz Command Line:
"C:\Program Files\SQL Anywhere 11\ce\cabwiz\cabwiz.exe" "C:\Documents
and Settings\admin\Desktop\sqlany11.inf" /dest "C:\Documents and
Settings\admin\Desktop\" /compress
CabWiz Output:
Windows CE CAB Wizard
Error: Section [SourceDisksNames] - path C:\Program Files\SQL Anywhere
11\ultralite\ce\ARM.50 not found
Error creating .CAB file
C:\Documents and Settings\admin\Desktop\sqlany11.CAB
This has been fixed.
================(Build #2510 - Engineering Case #644855)================
If the Interactive SQL utility (dbisql) was open, and the results of a query
were displayed, changing the Windows desktop theme from "Windows XP"
to "Windows Classic", or otherwise changing the Window style from
"XP" to "Classic", would have caused dbisql to crash.
This has been fixed.
This issue could have manifest itself any time the Windows look-and-feel
was changed from something other than Windows Classic to Windows Classic.
It would also have affected Sybase Central if a table was selected in the
"Folders" panel.
This issue only occurred on Windows computers. Operation on other operating
systems was not affected.
================(Build #2497 - Engineering Case #642010)================
If a Initialization utility command line used exceptionally long filenames
and encryption key, and the encryption key contained at least one single
quote character, the resulting database may have been unusable. The server
would always have reported an incorrect encryption key. This has been fixed.
================(Build #2496 - Engineering Case #641131)================
When connected to a database using an ODBC data source which used the ASA
9.0 ODBC driver, the Interactive SQL utility could have crashed if an INPUT
statement was executed which processed TIME, DATE, or TIMESTAMP data. This
has been fixed.
================(Build #2496 - Engineering Case #637447)================
The ALT left cursor and ALT right cursor keys on Solaris systems control
the desktop and cannot be used to view executed SQL statements. The get around
this limitation, the keys used now for viewing previous and next SQL statements
on Solaris systems are the keys CTRL-up cursor and CTRL-down cursor respectively.
================(Build #2486 - Engineering Case #639140)================
When the Options window was opened from the Query Editor, all of the options
for the Text Completer would have been inadvertently turned off. This has
been fixed.
================(Build #2485 - Engineering Case #639018)================
The Query Editor could have crashed when opened if the initial SELECT statement
contained "*" and at least one explicit column name in the column
list. This has been fixed.
================(Build #2485 - Engineering Case #639002)================
Changes made to the WHERE and HAVING tabs in the Query Editor were ignored
after the Options button was clicked. This has been fixed.
================(Build #2485 - Engineering Case #638986)================
The Query Editor could have crashed if the last time it was opened a join
had been added to the query, but the join type was left unspecified (blank).
This has been fixed.
================(Build #2484 - Engineering Case #638862)================
The Interactive SQL utility would have crashed if a file was imported and
then subsequently text was pasted into the editor. This has been fixed.
================(Build #2484 - Engineering Case #638856)================
The Interactive SQL utility, the Console utility, and Sybase Central, could
have terminated without an error message. This could have happened when closing
an "Options" dialog, and possibly at other points, due to an uninitialized
variable. This has been fixed.
================(Build #2480 - Engineering Case #637991)================
The Interactive SQL utility could have crashed when completing a DELETE statement,
if a table alias was given. This has been fixed.
================(Build #2480 - Engineering Case #637877)================
When completing column names for tables that have aliases, the alias is now
displayed in the completion list, and the alias is now used in the completed
text. For example, if the completer is opened after "Comp" in the
following statement:
select Comp from customers C1, customers C2
the completer will include "Company (C1 - customers)" and "Company
(C2 - customers)". If the second item is selected, the completed text
will read:
select C2.CompanyName from customers C1, customers C2
Previously, "Comp" would be replaced by "CompanyName",
which was ambiguous.
================(Build #2479 - Engineering Case #637203)================
The column alignment used by the OUTPUT statement for the FIXED file format
was often inappropriate for the data type. In general, numbers should be
right-aligned, while everything else is left-aligned. This has been fixed.
================(Build #2476 - Engineering Case #637174)================
If a file was inserted using the "Edit/Insert File" menu item,
the file would have been locked by dbisql until dbisql was closed. If the
Fast Launcher option was turned on, the file was locked until the Fast Launcher
also shut down (which by default happens after 30 minutes of inactivity).
Now, the file is unlocked as soon as its text has been added to the "SQL
Statements" field.
================(Build #2476 - Engineering Case #637165)================
The following defects related to the menu bar, which occurred only on Mac
OS X systems, have now been fixed:
- The "Check for Software Updates" menu item was missing
- The text for submenus were indented more than was required
- There were a number of spurious separators at the end of certain menus.
================(Build #2476 - Engineering Case #636558)================
All of the items in the "File" menu (and others) would have been
disabled after clicking a source control-related menu item, if that source
control action failed. This would have occurred when using the "custom"
source control option. This has been fixed.
================(Build #2474 - Engineering Case #636544)================
There is a tool in the "Connect" window which creates an ODBC DSN
from the contents of the window. If a DSN had been selected in the window,
its contents were not included in the newly created DSN which usually made
the new DSN useless. Now, the new DSN contains the parameters of the selected
DSN.
================(Build #2472 - Engineering Case #636310)================
In the "Connect" window, "Tools/Save as ODBC Data Source"
can be clicked to save the contents of the window as a DSN. That window was
not closing when the Esc key was pressed. This has been fixed so that now
it does.
================(Build #2472 - Engineering Case #634445)================
As a side-effect of the changes made for Engineering case 627780, the Start
Server in Background utility (dbspawn) on Windows no longer allowed the database
server start line to be passed as a single quoted string. This behaviour
has now been restored to its previous state on Windows only, and only for
versions 10.0.1 and 11.0.1. Version 12 will retain
the new behaviour as per the documentation.
================(Build #2468 - Engineering Case #635468)================
On Mac OS X systems only, the names of favorites in the Favorites sidebar
would have disappeared when the mouse was moved over them. This has been
fixed.
================(Build #2468 - Engineering Case #635443)================
When not connected to a database in the SQL Anywhere Console utility (dbconsole),
the "File/Options" menu is disabled. The "Options" context
menus for the "Connections", "Properties", and "Messages"
panels were not disabled. This has been corrected so that now they are disabled.
================(Build #2465 - Engineering Case #634906)================
Setting the "Show results from each statement" option would have
resulted in incorrect behavior: Attempts to sort, select all, or copy column
data would have resulted in an attempt to fetch more rows if required. That
attempt should not have been made. When "Show results for each statement"
is On, only the rows already fetched can be sorted. This has been corrected.
================(Build #2463 - Engineering Case #634503)================
When completing the name of a column in a SELECT statement following the
FROM clause, the completed text could have included the owner name for the
table which contained the column, but not the table name. This was not valid
SQL. Now, the owner name is not part of the inserted text.
================(Build #2459 - Engineering Case #633775)================
Exporting source control commands from the "Custom Source Control Options"
window could have caused the Interactive SQL utility to crash on Mac OS X
systems. This has been fixed.
================(Build #2459 - Engineering Case #628564)================
The Interactive SQL utility would have returned a function sequence error
when connected to an UltraLite database and a query was executed if the “Commit
after every statement” option was checked (under Tools/Options/UltraLite/Commands).
This has now been fixed.
A workaround is to uncheck the “Commit after every statement” option.
================(Build #2458 - Engineering Case #633744)================
On Mac OS X systems, the name of a saved history file was given the extension
"..sq", rather than ".sql", when an explicit file extension
was not entered. This has been fixed.
================(Build #2458 - Engineering Case #633610)================
The "Find/Replace" dialog could have failed to find text when the
"Look in selection" box was checked. This was most likely to happen
if the selection started far from the start of the text, and ended close
to the end of the text. This has been fixed.
================(Build #2456 - Engineering Case #633268)================
The changes for Engineering case 632526 may have caused the "SQL"
field in the Plan Viewer window to become unusably short after the "Get
Plan" button was clicked. This has been fixed.
================(Build #2453 - Engineering Case #632743)================
The text fields on the second page of the Index Consultant were too narrow
to display even their default values. This problem was most apparent on
Mac OS X systems, although it could also have occurred on any platform if
the font used by the application was sufficiently large, or if the look-and-feel
for that platform had a wide border for text fields. This has been fixed.
================(Build #2451 - Engineering Case #632545)================
Pressing a non-character key (e.g LeftArrow, Alt, Space, etc.) could have
inserted a hollow box character to the SQL Statements field. This has been
fixed.
This problem was more readily seen on Linux systems than on Windows.
================(Build #2451 - Engineering Case #632526)================
The Plan Viewer window could have opened with a width that was wider than
the monitor if the "SQL Statements" field contained a SQL statement
which was itself longer than could be displayed on the monitor. This has
been fixed.
================(Build #2449 - Engineering Case #632177)================
The text completer would not have suggested any names following a string
of the form "owner.partialTableName" if "owner" was the
same as "partialTableName". This would have occurred when trying
to complete the name of a system table, e.g.:
SELECT * FROM sys.sys
This problem would have affected text completion in SELECT, DELETE, and
UPDATE statements and has now been fixed.
================(Build #2448 - Engineering Case #631781)================
The text completer could have failed to suggest column names at the end of
a dotted expression if the SQL statement spanned more than one line. For
example, if the completer was opened at the end of the following statement:
SELECT * FROM customers C
WHERE C.
it should have suggested the columns in the "Customers" table,
but it did not. This has been fix so that now it does.
================(Build #2443 - Engineering Case #631028)================
Creating the first user DSN by clicking the "Save as ODBC Data Source"
Tools button could have silently failed. This has been fixed.
================(Build #2443 - Engineering Case #591837)================
The Index Consultant in the Interactive SQL utility would have failed to
process queries containing line-terminated comments (ie -- or //). This
has been fixed.
As a work around, removing the comments allowed the analysis to proceed.
================(Build #2442 - Engineering Case #630522)================
The Interactive SQL utility (dbisql) could have crashed if more than one
dbisql window was opened by clicking the "Window/New Window" menu
item, the first window was close, then the "Preferences" item in
the "Interactive SQL" menu was clicked. This bug also had the
symptom of always showing the preferences for the first window, never for
any of the subsequently opened windows. This has been fixed.
================(Build #2441 - Engineering Case #630219)================
On non-Windows computers, a proportional font was used when displaying results
as text in the Interactive SQL utility. This prevented the columns from lining
up correctly. Now, a monospaced font is used. On Windows computers, a monospaced
font has always been used.
================(Build #2441 - Engineering Case #630040)================
Messages in the Run Script window could have been truncated. The problem
did not occur on all systems; it depended on the selected system font. The
problem would have occurred on Windows for example, if "MS UI Gothic"
was selected for the desktop icon font. This has been fixed.
================(Build #2439 - Engineering Case #629768)================
The file browser that opened after clicking the "Save" button in
the Index Consultant did not prevent interaction with the wizard while it
was open. This has been corrected so that it does.
================(Build #2439 - Engineering Case #629569)================
As of the changes made for Engineering case 568632, running a DESCRIBE statement
in an Interactive SQL utility window always resulted in an error message.
This has been fixed.
================(Build #2438 - Engineering Case #629458)================
Clicking the Close button in the title bar of the Query Editor was considered
equivalent to clicking the OK button. This was incorrect; it should have
been equivalent to clicking the Cancel button. This has been fixed.
================(Build #2435 - Engineering Case #628553)================
Execution of an INPUT statement which used an explicit encocoding of "utf-16"
would have worked if the input file had the same endianness as the platform,
but would have failed if the endianess was different, even if the byte-order-mark
was present in the file. This has been fixed.
================(Build #2434 - Engineering Case #628443)================
Reconfiguring the fast launchers (Interactive SQL and Sybase Central) could
have caused the launchers to become unresponsive. The symptom was that there
could have been multiple dbisql.exe / scjview.exe processes on the computer
rather than just one. This has now been fixed.
================(Build #2434 - Engineering Case #628256)================
The Interactive SQL utility (dbisql) could have reported an internal error
if a column header for a result was clicked, dbisql had not already cached
the entire result and then fetching the remaining rows was canceled. This
has been fixed.
================(Build #2434 - Engineering Case #628253)================
The Interactive SQL utility option isql_print_result_set was being ignored.
This has been corrcted so that it is once again respected.
================(Build #2433 - Engineering Case #627956)================
When executing a batch of statements, if an INPUT USING statement failed
to connect to the source database, an error message was displayed, but execution
continued unconditionally. Now, the "on_error" setting is respected.
================(Build #2431 - Engineering Case #627657)================
The list of SQL functions suggested by the editor's Text Completer was incomplete
when connected to a version 11.0 database. This has been fixed.
================(Build #2430 - Engineering Case #627528)================
If the Support utility (dbsupport) attempted to send an email, either by
explicit command using the -cet option or when a crash occurred, and the
configured mail server was either non-existent, running on a different port,
or down at the time of the attempt (i.e. the connection to the mail server
failed), then dbsupport would have crashed. This has been fixed.
================(Build #2430 - Engineering Case #627526)================
Attempts to create, edit, or modify Windows Mobile proxy ports from the "Connect"
dialog would have silently failed on Windows Vista or Windows 7 if user access
control (UAC) was enabled. This has been fixed.
================(Build #2429 - Engineering Case #552627)================
If the language DLL was missing, the utilities createcert, viewcert, createkey,
and mlfiletransfer would all have continued to execute, but would not have
output any string resources. These utilities will now fail in this case
with an appropriate error message.
Also, the usage text for createcert and viewcert will now display the options
in alphabetical order.
================(Build #2427 - Engineering Case #623276)================
On Windows systems, a reload of a pre-version 10 database file could have
hung. Unix
systems were not affected. This has been fixed.
================(Build #2426 - Engineering Case #626481)================
The caret had to be within a statement's text for the "single step"
menu item (SHIFT+F9) to work. This restriction has now been relaxed so that
if the caret is in whitespace or a comment before a statement, "single
step" executes the next statement.
For example, consider the following code:
/*
Lorem ipsum
*/
select 123;
If the caret is anywhere within the comment, or on the blank line before
the SELECT statement, pressing SHIFT+F9 now executes the SELECT statement.
Previously, an error message saying the caret was not on a statement would
have been displayed.
================(Build #2426 - Engineering Case #626474)================
The SQL cited in the "ISQL Error" window did not display blank
lines. As a result, the line number in the database error message might not
have corresponded to the displayed SQL if the statement contained blank lines.
This has been fixed.
Also, the line and column shown in the status bar of the main DBISQL window
is no longer updated if the caret (insertion point) is moved in the text
field that shows the SQL in the "ISQL Error" window.
================(Build #2425 - Engineering Case #625305)================
Queries that reported warnings could have caused dbisqlc to crash, hang,
report that the prepared-statement resource limit had been exceeded, or misbehave
in a variety of other ways. This problem has been fixed.
================(Build #2423 - Engineering Case #625641)================
The Interactive SQL utility could have reported an error on some Windows
computers that its preferences or history file could not be saved. The error
message quoted a file name which typically included a directory under the
"Documents and Settings" directory which was not the home directory
of the current user. This has been fixed.
Note, this same problem has the potential to affect Sybase Central, DBConsole,
and MobiLink Monitor, though their symptoms are likely to be different.
================(Build #2423 - Engineering Case #624956)================
With dbisqlc, when invoking the "OUTPUT TO" statement without a
FORMAT clause, or before explicitly setting the OUTPUT_FORMAT option at least
once in a session, the generated output file would not have been in the expected
"TEXT" output format (ie comma-separated values). This problem
has been fixed.
A related change has also been made to the values accepted for the SCREEN_FORMAT
option by dbisqlc on UNIX platforms. Prior to this change, dbisqlc accepted
both "TEXT" (for the default columnar display) and "ASCII"
(for comma-separated values). These options have been renamed to COLUMNS
and CSV respectively. The old values of TEXT and ASCII are still accepted
but are deprecated.
================(Build #2422 - Engineering Case #625325)================
When using the Service utility to delete a service that was running, the
warning "The specified service is running. The service will be deleted
when is is stopped." was reported. The warning should read "The
specified service is running. The service will be deleted when it is stopped."
The wording has now been corrected.
================(Build #2422 - Engineering Case #624986)================
If the Interactive SQL fast launcher was enabled, and there was enough connection
information on startup to attempt a connection, the main dbisql window could
have, very occasionally, got into a state where it did not paint correctly.
This has been fixed.
There are a number of workarounds:
- Minimize and then restore the dbisql window, or
- Resize the window, or
- Turn off the fast launcher for dbisql
================(Build #2415 - Engineering Case #624040)================
In the Interactive SQL utility, the DESCRIBE CONNECTION command could have
returned garbage characters if the connection string contained non-ASCII
characters. This has been fixed.
================(Build #2415 - Engineering Case #624034)================
Clicking a column header name in the Results panel to sort the column when
all of the rows had not been fetched yet, could have caused the Interactive
SQL utility to report an internal error. The problem was timing-sensitive,
and did not happen every time. This has been fixed.
================(Build #2412 - Engineering Case #623095)================
The text completer would have suggested names of text index tables, which
was not useful. These table names are no longer listed by the text completer.
================(Build #2407 - Engineering Case #621504)================
The exception System.NullReferenceException could have resulted when using
the SQL Anywhere CE Deployment Wizard (cedeploy) on 64-bit Windows to deploy
SQL Anywhere to a Windows Mobile device. This problem has been fixed.
================(Build #2400 - Engineering Case #619728)================
If rebuilding a database failed for some reason, the Unload utility (dbunload)
would have output some unnecessary information to unprocessed.sql. This has
been fixed.
================(Build #2393 - Engineering Case #618967)================
The Interactive SQL utility (dbisql) would have crashed when attempting to
export a binary value using an OUTPUT statement with the HEXADECIMAL OFF
or HEXADECIMAL ASIS clause. This has been fixed.
================(Build #2383 - Engineering Case #617154)================
The Interactive SQL utility (dbisql) could have failed to connect when using
a Japanese DSN name that was passed as a connection parameter. Double-byte
characters were being mangled when provided in a parameter to dbisql. This
has now been fixed.
================(Build #2383 - Engineering Case #616038)================
If the Log Translation utility (dbtran) was run using both the -m (read log
files from a directory) and -ir (range of log offsets) flags, the following
error would have been reported:
Transaction log file '<logfile1>' overlaps with transaction log file
'<logfile2>'
This has been fixed.
================(Build #2378 - Engineering Case #615655)================
For some types of page corruption, the Validate utility (dbvalid) could have
reported incorrect page numbers. This has now been corrected.
================(Build #2378 - Engineering Case #613984)================
Rebuilding version 9 or earlier databases using the Unload utility (dbunload)
could have failed with the error "Unable to start specified database:
autostarting database failed" if the old database had been run with
database auditing. This has been fixed.
================(Build #2374 - Engineering Case #613637)================
Unloading a version 11 database using the Unload utility (dbunload) such
that dbunload used its internal unload/reload mechanism (i.e. -ii), could
have then caused the Translation utility (dbtran) to crash when scanning
the new database's transaction log for particular tables (command line option
-it).
================(Build #2369 - Engineering Case #613261)================
Executing a query like the following from SQL Server Management Studio (2005):
select * from saoledblink..SYS.syscollation;
would have failed with the error:
Msg 7356, Level 16, State 1, Line 1
The OLE DB provider "SAOLEDB.11" for linked server "saoledblink"
supplied nconsistent metadata for a column. The column "collation_order"
(compile-time ordinal 4) of object ""SYS"."syscollation""
was reported to have a "DBCOLUMNFLAGS_ISFIXEDLENGTH" of 0 at compile
time and 16 at run time.
The problem occurred for BINARY(n) columns. The DBCOLUMNFLAGS_ISFIXEDLENGTH
schema attribute was set true (0x10) at run time. This problem has been fixed.
================(Build #2368 - Engineering Case #612641)================
The Deployment wizard would have failed to work properly on Windows Vista
and Windows 7. The wizard would have claimed to complete successfully, but
the resulting MSI was invalid. The wizard was attempting to create a temporary
file in the Program Files directory, which is disallowed by Windows Vista
and Windows 7. This has now been corrected.
A workaround for this issue is to run the deployment wizard as an administrator.
================(Build #2368 - Engineering Case #612491)================
When connected to an UltraLite databaseand trying to import table data from
a database using the Import Wizard, a dialog would have been displayed asking
to select a database name from an empty list of databases. The list of databases
is no longer offered since the concept has no meaning when connected to an
UltraLite database.
================(Build #2368 - Engineering Case #609454)================
When trying to bind null values for string or blob columns, the SQL Anywhere
C API would have crashed in the call to sqlany_execute(). This has been fixed.
Also, when binding null values, dbcapi required a valid type to be specified.
This is no longer required.
================(Build #2366 - Engineering Case #612128)================
Clicking the "GENERATE/INSERT statement" menu item in the Results
panel, when the row contained a long character column (e.g. more than 100K),
the Interactive SQL utility could have taken a very long time to generate
the statement. This has been corrected so thgat it now happens almost instantaneously.
================(Build #2365 - Engineering Case #611368)================
The Interactive SQL utility (dbisql) was using only the "sqlconnect"
environment variable when connecting from the command line, where it should
have been using "SQLCONNECT", as it did in version 10 and earlier.
Now, dbisql will look for "SQLCONNECT", and if that variable is
not set, it will look for "sqlconnect". This is the same algorithm
used by the non-graphical command line tools (e.g. dbping).
Note, the "ULSQLCONNECT" environment variable is now treated the
same way.
This change only affects machines running non-Windows operating systems.
================(Build #2365 - Engineering Case #608314)================
When the Application Profiling wizard was run on an encrypted database, it
would have failed with the error: "This database does not support encrypted
tables." This has now been fixed.
================(Build #2363 - Engineering Case #610723)================
If the Data Source utility (dbdsn) was used to create an ODBC data source,
but the -c
option was not specified, a data source would have been created containing
"LINKS=ShMem,TCPIP". This has been fixed, the -c option is now
required when -w is used.
================(Build #2357 - Engineering Case #608742)================
The following statements were added e added in version 11.0.1:
CREATE ENCRYPTED [TABLE] DATABASE newfile FROM oldfile
KEY newkey [ALGORITHM alg] [OLD KEY oldkey]
CREATE DECRYPTED DATABASE newfile FROM oldfile KEY oldkey
Execution of either of these statements in the Interactive SQL utility would
have left the values of "oldKey" or "newKey" in plain
text in the command history. This has been corrected so that these values
are now obfuscated.
================(Build #2357 - Engineering Case #585015)================
Exporting numeric values to an Excel spreadsheet would have failed when running
the Interactive SQL utility on Windows systems which were configured to use
something other than a period for the decimal separator in numbers. This
has been fixed.
Also, it is now possible to consistently export TIME, DATE, and TIMESTAMP
values to Excel spreadsheets.
================(Build #2354 - Engineering Case #606465)================
If the "kerberos" connection parameter, or its short form "krb",
was given on the command line, the Interactive SQL utility would not have
connected to the database unless a userid was also given. This has been fixed.
================(Build #2351 - Engineering Case #607061)================
The DBTools function DBCreatedVersion() was not able to handle databases
that used strong encryption. This has been fixed.
================(Build #2350 - Engineering Case #606626)================
When using the Interactive SQL utility (dbisqlc) to connect, and attempting
to use integrated logins or kerberos, (i.e. dbisqlc -c "integrated=yes"
or dbisqlc -c "kerberos=yes"), it would have displayed the connection
dialog without first attempting to connect. Similarly, the the statements
CONNECT USING 'integrated=yes' and CONNECT USING 'kerberos=yes' with dbisqlc,
would also have displayed the connection dialog without first attempting
to connect.
This has been fixed so that a connection with be attempted in these cases
and if the connection attempt is successful, the connection dialog will not
be displayed.
================(Build #2349 - Engineering Case #606440)================
If a DSN was created using the Data Source utility (dbdsn), attempting to
modified the userid or password of the DSN using the ODBC Administrator would
have reported no errors, but it would have failed to change either of these
fields. This has been fixed.
================(Build #2338 - Engineering Case #595746)================
If the Interactive SQL utility executed a DROP statement which included an
"IF EXISTS" clause, subsequent statements in the same batch would
not have been parsed correctly. The symptom was that an unexpected error
message would have been displayed, which referred to more than one of the
statements which followed the DROP statement. This has been fixed.
================(Build #2333 - Engineering Case #594897)================
The initial directory used by the file browsing windows in the graphical
administration tools was "C:\Windows\System32" on Vista and Windows
7. The inappropriate initial directory was chosen only when the application
was launched from an icon (e.g. in the "Start" menu.) This has
now been changed to the system-defined user home directory, which is the
initial directory used on Windows XP.
================(Build #2331 - Engineering Case #594476)================
On Linux systems, invoking the Service utility (dbsvc) with the options "-l
-cm" would have given unexpected results. In particular, it would not
have displayed the service creation command. This has been fixed.
================(Build #2331 - Engineering Case #594130)================
If the Interactive SQL utility, Sybase Central, or DBConsole reported an
internal error, and the link to check for software updates was clicked, it
would not say that updates were available, even if they were. This has been
fixed.
================(Build #2325 - Engineering Case #592728)================
The list of TCP/IP protocol options in the Connect dialog was incorrect.
The list should not have contained the options 'TDS' or 'BroadcastListener',
and the option 'SendBufferSize' was missing. These have been fixed.
Note, these issues affected the Connect dialog when connecting to SQL Anywhere,
regardless of which program was being used -- DBISQL, Sybase Central, or
DBConsole.
================(Build #2324 - Engineering Case #592421)================
Executing the utility SASetupAspNet.exe would have caused an unhandled exception
"Could not load file or assembly iAnywhere.Data.SQLAnywhere" to
be thrown. This problem has been fixed.
================(Build #2320 - Engineering Case #592035)================
Clicking the "Get Plan" button in the Plan Viewer window could
have caused the Interavtive SQL utility to crash if it, or another Plan Viewer
window, was executing a statement at that time. This has been fixed.
================(Build #2320 - Engineering Case #592018)================
It was possible for the Interactive SQL utility (dbisql) to have crashed
when clicking the File/New menu item, or by pressing CTRL+N, when connected
to a database and the contents of a file was being displayed. The problem
was timing dependent, and was more pronounced the longer the database latency
was. This has been fixed.
================(Build #2317 - Engineering Case #590602)================
Executing a SQL statement, immediately followed by an OUTPUT statement and
nothing else, would have cause an internal error if the "Show separate
Messages pane" option was set on. This has been fixed.
================(Build #2310 - Engineering Case #588950)================
The Import Wizard could have crashed when clicking the Back button on the
"Where do you want to save the data" page, if "In an existing
table" was selected but no table was selected in the list. This has
been fixed.
================(Build #2310 - Engineering Case #588940)================
When using the Import Wizard to import data from a file, if the file specified
did not exist, an incomplete error message was displayed. This has been corrected
so that the message is now complete.
================(Build #2307 - Engineering Case #587256)================
If a database with a foreign key declared as "NOT NULL" was unloaded
or rebuilt, the resulting reload.sql or database contained the foreign key
without "NOT NULL" declared. This has been fixed.
================(Build #2302 - Engineering Case #586427)================
A typo in the message displayed when connecting to an unsupported database
type has been fixed.
================(Build #2302 - Engineering Case #586414)================
When running the Interactive SQL utility in a command window, if the output
was redirected to a file, and the "-q" command line option was
not specified, error messages would not have been displayed in the command
window. This was a problem because the user had to press ENTER to continue
the script, but the message saying to do that was redirected to the file.
This has been corrected spo that the error output is now sent to the STDERR
device, which is displayed in the console .
To workaround this problem, use the "-q" command line option.
That will print the error message in the console and will not prompt the
user to press a key to continue.
================(Build #2297 - Engineering Case #585530)================
The changes for Engineering case 568426 broke the Table and View permissions
grid support for 9.x databases. This has now been fixed.
================(Build #2297 - Engineering Case #585046)================
Consider an UltraLite database with a table as follows:
CREATE TABLE tbl1(a INTEGER, PRIMARY KEY (a))
INSERT INTO tbl1 VALUES (10000000)
Fetching the results using the Interactive SQL utility (dbisql) in command-line
mode as follows:
dbisql -ul -c "uid=dba;pwd=sql;dbf=c:\temp\test.udb" select
a from tbl1
would have returned the value 1000. The value was truncated in the display,
and was only an issue when displaying the results to the command shell.
This is now fixed.
================(Build #2296 - Engineering Case #585024)================
When inserting or updating a row using a table on the "Result"
tab, values read from a file were silently truncated at 1,000,000 characters.
This limitation has been removed.
Note, this bug affected both the Interactive SQL utility, and the "Data"
tab in Sybase Central.
================(Build #2277 - Engineering Case #577932)================
When deploying SQL Anywhere using the Deployment wizard, the PHP Extenv DLLs
were being deployed (php-<PHP version>_sqlanywhere_extenv11.dll), but
not the PHP SQL Anywhere DLLs (php-<PHP_version>_sqlanywhere.dll).
These have now been added to the list of files deployed.
================(Build #2276 - Engineering Case #560069)================
When executing a VALIDATE statement, or running the Validation utility (dbvalid),
table validation would have failed to report errors when an index did not
contain all the rows in the table. This has now been corrected.
Note, when validating a database with a 10.0.1 server between 3920 and 3930
inclusive, it was also possible for errors to be reported, when in fact there
were no error. I this case, the 10.0.1 server should be updated to a build
number of 3931 or higher, and the validation rerun to see if the errors are
still reported.
================(Build #2274 - Engineering Case #581454)================
The following improvements/fixes have been made related to exporting data
from a SQL Anywhere database to Excel files, via the Microsoft Excel ODBC
driver:
1. Attempting to export CHAR, LONG VARCHAR, NCHAR, NVARCHAR or LONG NVARCHAR
values, would have failed with a message that the type was unsupported. Now,
these types are mapped to VARCHAR (the closest type supported by the Excel
driver).
Note that the Excel ODBC driver only supports text column widths up to 255.
Attempting to export longer values, will still get an error message.
2. The driver portion of the OUTPUT USING string had to be specified as
"Driver=" or "driver=". Now, that part of the string
is treated without respect to case, so "DRIVER=" is also accepted.
3. REAL, FLOAT, and BIGINT values could not have been exported due to limitations
in the Excel ODBC driver. These limitations have been worked around.
4. Numbers that were not MONEY or SMALLMONEY were exported as CURRENCY (i.e.
they were displayed with a dollar sign in the Excel spreadsheet). Now they
are exported as numbers. MONEY and SMALLMONEY are still exported as CURRENCY.
5. The Export Wizard would consistently have failed when exporting to tables
it had to create. The error message was "Syntax error in the CREATE
TABLE statement". This has been fixed.
================(Build #2272 - Engineering Case #580133)================
The OUTPUT USING statement's ability to export results to Excel files has
been improved:
1. The CREATE TABLE ON clause is now supported. Previously, consistently
creating tables was not possible, although exporting to existing tables worked.
2. If the table name was quoted with backticks, the output operation would
have failed. This has been fixed.
3. The OUTPUT statement would not have worked at all if the USING clause
contained "driver=" rather than "dsn=". This has been
fixed.
4. Exporting a result set which contains primary key columns with the CREATE
TABLE ON clause would have failed, as the Excel ODBC driver does not support
the required SQL to designate primary keys. This limitation has now been
worked around.
For datatypes that the OUTPUT statement cannot handle, such as BINARY or
LONG BINARY, the user must do the conversion to a supported type explicitly.
Note that the Interactive SQL utility in version 10 and earlier did allow
exporting BINARY columns, although it simply treated bytes as characters
when it wrote them to the Excel file. It's unclear whether that was a "good
thing" in general. To emulate that behavior in now, use the following:
SELECT ID, Name, Description, Size, Color, Quantity,
UnitPrice, CAST(Photo AS LONG VARCHAR )
FROM Products;
OUTPUT USING 'DSN=MyEXCELDSN' INTO tabProducts CREATE TABLE ON
Also note that the Microsoft Excel ODBC driver treats the file as read-only
by default. To write to the file, turn off the "Read only" flag
in the DSN or, if not using a DSN, include "ReadOnly=0" as a connection
parameter in the OUTPUT statement.
For example:
SELECT * FROM Departments;
OUTPUT USING 'Driver=Microsoft Excel Driver (*.xls);
dbq=c:\test\test.xls;ReadOnly=0'
INTO Departments CREATE TABLE ON
================(Build #2270 - Engineering Case #580538)================
When connected to a slow server, immediately doing something to modify the
contents of the "SQL Statements" field, would have cause the Interactive
SQL utility to crash with the exception "java.lang.IllegalStateException:
Attempt to mutate in notification". This has now been fixed.
================(Build #2265 - Engineering Case #613455)================
The SQL Anywhere Update Service could have recommended the incorrect bitness
of a Windows EBF. For example, the Update Service could have recommended
both bitnesses of the 11.0.1 Maintenance Release to customers of 11.0.0;
or, it may recommended a 64-bit EBF to customers running 32-bit Windows.
This has been corrected.
================(Build #2263 - Engineering Case #578001)================
If an ODBC escape sequence was used that was preceded by a keyword, it was
mangled by the Interactive SQL utility. The first and last characters were
stripped off. This has now been fixed.
================(Build #2261 - Engineering Case #575755)================
The Maintenance Release and EBF installs were not correctly updating the
product version number in the .NET configuration file 'machine.config'.
This has been fixed.
================(Build #2260 - Engineering Case #574920)================
A client side backup of a database with a path and filename length greater
than 69 bytes in the client character set, could have failed or truncated
the filename. This has been fixed.
================(Build #2257 - Engineering Case #575983)================
When editing a DATE or TIMESTAMP value in a result set, the editor would
not have accepted dates in the ISO format (YYYY-MM-DD). This has been corrected
so that the ISO format is now accepted.
================(Build #2254 - Engineering Case #575149)================
The changes made for Engineering case 556453 introduced a bug that caused
the Interactive SQL utility (dbisql) to crash when attempting to edit a DATE
value in a result set. This has been fixed.
================(Build #2252 - Engineering Case #574314)================
Attempting to modify a service that was already running using the Service
utility (dbsvc) with the -w "create service" command line option
would have failed. The utility would have deleted the server, but would not
have been able to re-create it. This has been fixed. If the service is running,
dbsvc will now report an error and will not delete the service.
================(Build #2252 - Engineering Case #557829)================
If the MobiLink Listener (dblsn) was started with the -q option ("run
in minimized window"), and it was then restored by double clicking on
the icon from the today screen, the "shutdown" button did not appear.
This has been fixed.
================(Build #2243 - Engineering Case #572179)================
On Linux systems, the Service utility (dbsvc) would not have stopped MobiLink
services correctly. This has been fixed. The correct command was correctly
echoed to the console but not actually executed. A workaround is to execute
the command that was echoed.
================(Build #2240 - Engineering Case #571817)================
NCHAR, NVARCHAR, and LONG NVARCHAR values from a SQL Anywhere database were
exported as CHAR to an Oracle database if DBISQL had to create a table in
the Oracle database to hold the data. This has been fixed.
================(Build #2235 - Engineering Case #571252)================
The INPUT USING, or Import Wizard, was not able to import REAL values from
a SQL Anywhere database to an UltraLite database. This has been fixed.
================(Build #2230 - Engineering Case #570799)================
When exporting to an UltraLite database using the Export wizard, the corresponding
OUTPUT statements added to the command history would have been incomplete
if no password was given for the UltraLite database. This has been fixed.
================(Build #2222 - Engineering Case #571460)================
On Linux systems, the Service utility (dbsvc) would not have honored the
-pr (nicelevel) and -a (user) command line options. This has been fixed.
================(Build #2222 - Engineering Case #570940)================
On Japanese Linux systemss, the Service utility (dbsvc) would not have output
any messages. This has been fixed.
================(Build #2210 - Engineering Case #568436)================
When running on a Windows machine configured to use the 1252 code page, if
the Interactive SQL utility (dbisql) attempted to open a file which contained
a Euro sign (€), it would have asked for which code page to use to interpret
the file. Now, dbisql recognizes that the Euro sign is part of the Windows
1252 code page, and reads the file without prompting. This change also fixes
similar behavior when a file contains any of the following characters:
€ U+20AC Euro sign
Ž U+017D Latin capital letter Z with caron
ž U+017E Latin small letter Z with caron
================(Build #2210 - Engineering Case #567778)================
Some of the files required to enable Windows Accessibility features were
being installed in the wrong directory. This could have resulted in the
Administration tools (eg Sybase Central)not running. This has been fixed.
================(Build #2198 - Engineering Case #567361)================
On some non-Windows platforms, pressing CTRL+C when the Interactive SQL utility
(dbisql) was running in console mode could have caused spurious error messages
which reported an unexpected signal 11, or "SIGSEV" error. This
has been fixed so that these messages no longer appear when CTRL+C is pressed.
================(Build #2196 - Engineering Case #567017)================
When using the SQL Anywhere Support utility to check for updates (dbsupport
-iu), it may have returned "Error checking for updates. Please try again
later." Subsequent retries by the same dbsupport instance would also
have failed. A counter variable was not being reset. This has now been fixed.
================(Build #2195 - Engineering Case #566830)================
It was not possible to export NUMERIC values to a new MySQL table if the
precision of the source column was greater than 15. This has been fixed.
Note that exporting data into an existing table did not have this problem.
================(Build #2194 - Engineering Case #566689)================
Importing a table into an UltraLite database may have failed if it contained
NCHAR or NVARCHAR columns. This has been fixed so that the importer converts
NCHAR and NVARCHAR columns into VARCHAR columns. The operation may still
fail if the UltraLite database cannot represent the characters being imported,
so this is guaranteed to work only if the UltraLite database is created with
a UTF8BIN collation sequence.
================(Build #2194 - Engineering Case #566673)================
Exporting data from a SQL Anywhere database to a MySQL table could have failed
if the Interactive SQL utility (dbisql) was asked to create a table for the
data, and the data contained any of the following SQL Anywhere types: TINYINT,
UNSIGNED SMALLINT, UNSIGNED INT, UNSIGNED BIGINT, or TIMESTAMP. The mapping
of data types between SA and MySQL was incorrect, this has been fixed.
================(Build #2187 - Engineering Case #565874)================
If an alias or correlation name was entered in the Query Editor, and then
the "OK" button was clicked while the editor for the alias or correlation
name was still open, the editor's value could have been ignored. This has
been fixed.
Note, a workaround is to press ENTER after typing in the alias/correlation
name, and then click the "OK" button.
================(Build #2186 - Engineering Case #565664)================
When run on machines with only one network adapter, checking the box "Only
show local servers" in the "Find Servers" dialog would not
have displayed local servers. This has been fixed.
================(Build #2182 - Engineering Case #565061)================
Dbisqlc would have reported an error, and then crashed, if there was a version
mismatch with the language DLL (e.g., dblgen11.dll). This problem has been
fixed.
================(Build #2182 - Engineering Case #565050)================
The Import wizard could have crashed if the "Next" button, on the
page which asks for a destination table name, was clicked before the page
has initialized. This has been fixed.
================(Build #2176 - Engineering Case #564472)================
The Interactive SQL utility (dbisql) could have reported an internal error
if, when connected to an UltraLite database, the text completer was opened
in a SELECT statement and the caret was immediately after a period. This
has been fixed.
================(Build #2168 - Engineering Case #563319)================
When creating or upgrading a database, the server looks for a file called
authenticate.sql, which is used to set the database_authentication option.
The file should reside in the <install_dir>\scripts directory, but
the server would continue to look elsewhere if it was not found there. This
has been fixed so that it looks for this file only in the scripts directory.
================(Build #2166 - Engineering Case #563202)================
The Interactive SQL utility (dbisql) would have reported an internal error
when attempting to use the Import Wizard to import data from a SQL Anywhere
database while connected to an UltraLite database. This has been fixed.
================(Build #2161 - Engineering Case #562605)================
If more than one of the dblocate filtering options (-p, -s, -ss) was used
and a hostname or IP address was specified, only one was used. There was
an implicit ordering and only the first of the ordering that was specified
would have been used; the second and subsequent options would have been ignored.
The ordering was:
hostname/IP address specified on command line
-p
-s
-ss
This has been fixed. If more than one of these options is specified, they
are all now applied.
================(Build #2158 - Engineering Case #561989)================
The Interactive SQL utility (dbisql) would have failed to launch on Windows
machines when run as a console application, if a connection parameter was
given and the parameter value contained a space. This has been fixed.
================(Build #2157 - Engineering Case #620981)================
The Relay Server State Manager (rshost) would have crashed on Linux systems
when run with no parameters. This has now been fixed.
================(Build #2148 - Engineering Case #559431)================
Attempting to execute an INPUT USING statement would have cause the Interactive
SQL utility to crash if the connection string was empty or missing. This
has been fixed.
================(Build #2148 - Engineering Case #559412)================
The OUTPUT USING statement could have failed to export the results of a DESCRIBE
statement. This has been fixed.
================(Build #2148 - Engineering Case #559185)================
Attempting to execute a CONNECT statement could have crashed the Interactive
SQL utility (dbisql) if it was started without an initial connection. This
has been fixed.
================(Build #2146 - Engineering Case #558554)================
If a user-defined domain was created with char-length semantics, the Unload
utility (dbunload) would not have preserved this attribute. This has now
been fixed.
================(Build #2146 - Engineering Case #558481)================
The Interactive SQL utility (dbisql) could have crashed when executing a
statement which returned a result set, if the redirection operator ( ">#"
) was used to save the result set to a file. This has been fixed.
Note, this problem only affected graphical operation of the program.
================(Build #2142 - Engineering Case #557507)================
If the statement:
set option public.login_mode='Standard,Integrated'
was executed, it would have been recorded in the transaction log as
set option public.login_mode='Standard'
This could have affected mirroring environments where the login_mode was
set correctly on the primary server, but not on the mirror. This has been
fixed.
================(Build #2141 - Engineering Case #545463)================
The Interactive SQL utility (dbisql) would have crashed if a START DATABASE
... ON statement was executed when it was not connected, and had never been
connected. This has been fixed.
================(Build #2138 - Engineering Case #556121)================
Changes made as part of the fix for Engineering case 554242, introduced a
problem where running the Validation utility (dbvalid) with a user who did
not have DBA authority, or execute permission on the dbo.sa_materialized_view_info
procedure, would have failed
with the error message:
Permission denied: you do not have permission to execute the procedure
"sa_materialized_view_info"
This has been fixed.
================(Build #2135 - Engineering Case #555250)================
The name of the current user did not appear in the list of owners in the
Import Wizard on the page that asks "Where do you want to save the data"
if the current user does not own any database objects. Now, the user name
always appears in the list of owners.
================(Build #2135 - Engineering Case #555245)================
Under rare circumstances, selecting a table type in the Query Editor could
have caused an internal error. This problem was highly timing-dependent.
This has been fixed.
================(Build #2135 - Engineering Case #555208)================
Interactive SQL utility options, which were set from a .SQL file while it
was running as a console application, would not have been saved. This has
been corrected so that now they are.
================(Build #2134 - Engineering Case #554242)================
The Validation utility (dbvalid) was not validating materialized views by
default. The utility was generating a list of tables to validate that only
included base tables. This has been corrected incorporate initialized materialized
views in either the fresh or stale state.
================(Build #2130 - Engineering Case #553911)================
The Service utility (dbsvc) included with versions 10.0.0 and up, did not
recognize services created with pre-10.0 versions of dbsvc. This has been
fixed. Old services can now be viewed, deleted, started and stopped. If an
old service is created using the patched dbsvc, the new service will no longer
be visible by pre-10.0 dbsvc.
================(Build #2130 - Engineering Case #553561)================
The OUTPUT statement would have unnecessarily re-executed the query which
generated the last result set, if the Interactive SQL utility was run in
windowed mode and the result set had not already been displayed. This has
been fixed so that the statement is not re-executed in this case.
================(Build #2129 - Engineering Case #551297)================
When unloaded using the Unload utilities external unload (i.e., dbunload
-xx or -xi), a table containing binary values could have had the contents
of these values truncated. The binary values would typically have to have
been longer than approximately 500 bytes for this bug to occur. This has
been fixed.
A workaround is to use an internal unload.
================(Build #2128 - Engineering Case #552779)================
When executing an "OUTPUT" statement, dbisqlc would have executed
the current query two extra times. Some output file formats require a particular
date format to be used and in version 10.0.0 and later, changing the date
format option on a connection does not affect cursors that are already open.
To work around this change of behaviour, dbisqlc closed the current query,
changed the DATE_FORMAT option to the format required by the output file
format and then reopened the query to write the result set to the output
file. It then closed the query again, restored the old DATE_FORMAT option,
and reopened the query. Thus the query was executed a total of three times.
Note that the Java-based dbisql has always executed the query a total of
two times (once for the original query, once for the OUTPUT statement). That
behaviour is not addressed by this change.
The problem in dbisqlc has been corrected in most cases by avoiding the
close/set-date-format/reopen operations if the requested output file format
does not have a mandated date format or if the current date format matches
the date format required by the output file format. If the specified output
file format requires a specific date format and it is different from the
current date format, the query will still be executed two extra times. To
avoid executing the query multiple times, set the DATE_FORMAT option for
the current connection as listed below before executing the query for the
first time:
Output file format DATE_FORMAT setting
DBASEII MM/DD/YY
DBASEIII YYYMMDD
FOXPRO YYYMMDD
WATFILE YYYY/MM/DD
Output file formats not listed above do not have a mandated date format
and dbisqlc will not close/reopen the current query to execute the OUTPUT
statement.
================(Build #2126 - Engineering Case #552771)================
Using a poorly formed connection string ("-c" command line option)
could have caused the Interactive SQL utility (dbisql) to crash on startup.
This has been fixed.
================(Build #2124 - Engineering Case #552196)================
Quoted SQL identifiers that were part of the Interactive SQL utility's command
line were inadvertently stripped of their quotes before being passed to the
database. This has been fixed.
For example, the following command line was not being handled correctly:
dbisql -c "uid=dba;pwd=sql" CREATE TABLE "123TEST"
( c INT )
================(Build #2121 - Engineering Case #551820)================
If a PARAMETERS statement was run from an Interactive SQL window a dialog
was displayed prompting for the values. If the PARAMETERS statement was then
rerun, the prompt was not displayed, and the previously values were used.
This behavior was not intentional and has been corrected. Now, the prompt
is displayed each and every time the PARAMETER statement is executed.
================(Build #2117 - Engineering Case #551124)================
Typing completion would have inadvertently added the table's owner name when
completing a column name after a table alias in the following places:
1. The column list in a SELECT statement
select C. from customers C
^
2. The WHERE clause in a DELETE statement
delete from customers C where C.
^
3. The SET or WHERE clauses of an UPDATE statement
update Customers C set C.
^
update Customers C set C.City = 'Waterloo' where C.
^
This has been fixed by suppressing adding the owner's name if the inserted
text immediately follows a table alias.
================(Build #2115 - Engineering Case #550503)================
When running in console mode, if a SQL statement caused a warning, and the
"-q" command line option was not used, the Interactive SQL utility
would have prompted the user to press ENTER before continuing. This has been
corrected so that the warning message is now printed, and the user is not
prompted. This was the behavior in version 10.0.1 and earlier.
================(Build #2114 - Engineering Case #550083)================
Clicking the "Generate/INSERT statement" menu in the "Results"
pane could have incorrectly caused the error "An INSERT statement could
not be generated. The results are from more than one table or contain only
computed columns." This has been fixed.
Note, this problem appeared on the "Data" tab in Sybase Central,
and has been fixed as well.
================(Build #2110 - Engineering Case #549466)================
The "-host" and "-port" command line options were completely
ignored when connecting to a SQL Anywhere database. This problem also affected
the Console utility (dbconsole) as well. It has now been fixed.
As a workaround, use the "-c" command line option instead.
================(Build #2110 - Engineering Case #549048)================
When displaying results as text, the row count was not being displayed under
each result set. This has been corrected so that the count will now be displayed,
unless the result is returned from a stored procedure.
================(Build #2615 - 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 #2354 - Engineering Case #606024)================
A logic bug in the server may have caused database indexes to become corrupt
under certain circumstances. The corruption would typically have manifest
itself by generating SQLCODE -189 when deleting from an indexed column, followed
by raising assertion 106200 - "Unable to undo index changes during rollback".
The possibility of corruption was greater when using large page sizes with
non-unique indexes over a small number of short columns. This problem has
now been fixed. The corruption can be eliminated by dropping the affected
index and recreating it with a server with this fix.
================(Build #2275 - Engineering Case #581542)================
If a database had a schema with a very large number of columnsa, it was possible
that when dbxtract was run, that the select statement generated to extract
the data from some of the tables would have used an incorrect column order.
This would likely have resulted in the rebuild failing, since the data types
of the columns in the new database would not match the data that have been
extracted from the remote database. The problem has now been fixed.
Note that this problem only affected dbxtract, and not dbunload.
================(Build #2569 - 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 #2405 - Engineering Case #619254)================
If a database had been initialized with the UCA collation sequence, and to
respect accent sensitivity on all UCA string comparisons, it was likely that
operations on tables without a SUBSCRIBE BY clause in the publication definition
would have failed to replicate. No errors would have been reported, but operations
that should have replicated would not have been sent. This has now been fixed.
================(Build #2383 - Engineering Case #616829)================
If the SQL Remote Message Agent (dbremote) connected to a database that had
remote or consolidated users defined, but did not have a publisher defined,
then dbremote would not have reported any errors, but would have simply reported
"Execution Complete". This has been corrected so that dbremote
will now report an error indicating that no publisher was defined in the
database.
================(Build #2354 - Engineering Case #467100)================
When very rare, a client application using a shared memory connection could
have hung forever while executing a statement. This has been fixed.
================(Build #2341 - Engineering Case #596641)================
If all of the following conditions were met, then SQL Remote would have continued
to hold locks in the database until the next time that it needed to send
the results of a SYNCHRONIZE SUBSCRIPTION to a remote database:
1) SQL Remote was running in send-only mode (-s)
2) SQL Remote was running in continuous mode
3) SQL Remote was satisfying a resend request for user "X", and
was forced to re-scan the transaction logs
4) While scanning the transaction log, a SYNCHRONIZE SUBSCRIPTION operation
was scanned for a user "Y"
5) User "Y" had already been sent the results of the SYNCHRONIZE
SUBSCRIPTION operation in a previous run of SQL Remote.
This has been fixed by releasing the locks when the send phase of dbremote
reaches the end of the transaction log and determines that the SYNCHRONIZE
SUBSCRIPTION operation does not need to be sent to the remote user.
The problem can be worked around by stopping and starting the dbremote process
that was running in send-only mode.
================(Build #2622 - 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 #2583 - Engineering Case #664633)================
A synchronization using FIPS end-to-end-encryption could have corrupted a
FIPS encrypted UltraLite database. This has been corrected.
================(Build #2568 - Engineering Case #660263)================
Incorrect results were possible for a deeply nested (at least a depth of
three) aggregate subquery. This has been corrected.
================(Build #2567 - 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 #2563 - 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 #2551 - Engineering Case #655358)================
During the loading of data using the UltraLite Load XML to Database utility
(ulload), columns whose values were NULL may have been set to default values.
This has been fixed.
================(Build #2546 - 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 #2546 - 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 #2531 - Engineering Case #650010)================
Some large integers were being improperly scanned. This has been corrected.
================(Build #2524 - Engineering Case #648499)================
Incorrect results were possible when an aggregate function was used in an
ORDER BY clause, and when the GROUP BY expressions were contained in the
ORDER BY expressions. This has been corrected.
================(Build #2523 - Engineering Case #648218)================
An aggregate computation on the left side of join may have produced incorrect
results when more than one group was generated as a result of a GROUP BY.
This has been fixed.
================(Build #2515 - Engineering Case #646356)================
The error SQLE_MEMORY_ERROR could have been reported on Windows Mobile devices
when a removable media card was ejected, or when the device returned from
standby. The operation should have been silently retried for a few seconds
and then SQLE_DEVICE_IO_FAILED reporting if the operation still failed. This
has now been corrected.
================(Build #2506 - Engineering Case #643960)================
The changes for Engineering case 635800 introduced a problem for applications
running on Palm devices. Applications could have hung while saving or restoring
state, for example on database shutdown. This has now been fixed.
================(Build #2498 - Engineering Case #642173)================
Erroneous results were returned when host indicator variables were used multiple
times. This has been corrected.
For example, the statement
SELECT 1 + :x + :x:y + :x
would generate incorrect results when a value was substituted for :x. A
work-around would be to remove the :y from the statement, since host indicator
variables are parsed but not processed in UltraLite.
================(Build #2482 - Engineering Case #636651)================
The use of START AT or FIRST in a subquery may have resulted in incorrect
results. This was corrected.
================(Build #2471 - Engineering Case #635800)================
The error, SQLE_TOO_MANY_CURSORS, would have been reported when there were
more than 32 prepared statements for a cursor, each of which had a parameter
set. The limit should have been 64 prepared statements. This was corrected.
================(Build #2424 - Engineering Case #625866)================
A SQL statement whose text exceeded 64K could have caused a crash.This has
been corrected.
================(Build #2419 - Engineering Case #624960)================
Each time a table or index was dropped, 16 bytes of store memory was leaked.
This could have resulted in a slow growth of the database file over time
with an application that created and dropped many tables or indexes. This
has now been fixed.
================(Build #2332 - Engineering Case #594373)================
When used with a BIGINT argument, the INTTOHEX function could have returned
an incorrect value. This has been corrected.
================(Build #2331 - Engineering Case #593523)================
The addition of fractional days to a timestamp value would have been incorrect.
This was corrected.
================(Build #2326 - Engineering Case #592873)================
By specifying the primary key in a separate clause of the CREATE TABLE statement,
the UltraLite runtime allowed tables to be created with Long column types
(ie. BLOBS, CLOBS) as primary keys.
For example: 'CREATE TABLE t1( v1 LONG VARCHAR, PRIMARY KEY(v1))'
The use of long datatypes in indexes is not supported by UltraLite, and
inserting into the resulting table would have resulted in a crash. This has
been corrected, long datatypes are now flagged as invalid when used in an
index.
================(Build #2317 - Engineering Case #590607)================
Incorrect results may have been obtained for functions with a variable number
of arguments, when NULL was specified as the first argument. This has been
corrected.
================(Build #2314 - Engineering Case #589666)================
When converting NUMERIC values to a VARCHAR, the server could have truncated
the results when the precision of the NUMERIC value exceeded 30. This has
been fixed by changing the conversion to produce a VARCHAR with size 2 plus
the precision of the source NUMERIC value.
================(Build #2296 - Engineering Case #585018)================
Calling the function SetParameter(), could have caused the UltraLite runtime
to crash when the database had no base tables. This has been fixed.
================(Build #2286 - Engineering Case #584691)================
A new "IF NOT EXISTS" clause can now be optionally specified in
CREATE TABLE, CREATE INDEX, and CREATE PUBLICATION statements. If this clause
is present, and the object named in the statement already exists, then executing
the statement will not modify the database and no error will be returned.
The complete syntax for the new clause in the various statements are:
- CREATE TABLE [IF NOT EXISTS] table-name (...)
- CREATE [UNIQUE] INDEX [IF NOT EXISTS] index-name ...
- CREATE PUBLICATION [IF NOT EXISTS] publication-name ...
================(Build #2276 - Engineering Case #581269)================
There were no implementations for the datatypes LONG BINARY and LONG VARCHAR.
These have now been added.
================(Build #2273 - Engineering Case #580353)================
Queries with TOP or START AT clauses were incorrectly flagged with an error
when they exceeded 64K. This restriction has now been removed.
================(Build #2271 - Engineering Case #580016)================
Unexpected behavior could have occurred when IN predicates were used in subqueries
in INSERT, UPDATE, and DELETE statements. This has been corrected.
================(Build #2270 - Engineering Case #578612)================
An INSERT statement, with a VALUES clause containing subquery expressions,
could have caused a crash. This has been corrected.
================(Build #2255 - Engineering Case #575325)================
When doing concurrent database operations during a synchronization, uploaded
LONG VARCHAR or LONG BINARY columns could have been corrupted in the consolidated
database. This is now fixed.
================(Build #2255 - Engineering Case #575181)================
If an UltraLite application had more than one open table or result set, and
an attempt was made to execute the SQL SYNCHRONIZE statement, the UltraLite
runtime would have returned the error SQLE_SCHEMA_UPGRADE_NOT_ALLOWED (-953).
This has now been fixed.
================(Build #2204 - Engineering Case #567790)================
Incorrect results, including bogus error messages, could have been obtained
when aliases (from the SELECT list) were referenced in a GROUP BY clause.
This has been corrected.
================(Build #2188 - Engineering Case #566828)================
Errors that occurred while running a SQL passthrough script in schema-diffing
mode were not being marked as critical, which could have caused the database
schema to become corrupted. This has been fixed.
================(Build #2183 - Engineering Case #565097)================
The metadata returned for a query with a UNION operator, could have been
incorrect. This has now been corrected
================(Build #2181 - Engineering Case #564679)================
An INPUT ststement, with multiple references to the same host variable, could
have been handled incorrectly when the leftmost reference was the host variable
by itself in the VALUES list, and another reference occurred in an expression
that was more complicated than just the host variable by itself.
For example,
INPUT INTO tab( pk, col1 ) VALUES( :hv, 100 - :hv )
This has been fixed so that the final substitution for non-leftmost host-variable
references is delayed so that the type of the first reference can be established.
================(Build #2162 - Engineering Case #562689)================
Using the concatenation operator '+' with VARCHAR and UUID did not produce
correct results. This has been fixed.
================(Build #2160 - Engineering Case #562245)================
Using the MobiLink file-based download to transfer files on Palm devices
to a VFS volume, could have failed. The error reported would have been STREAM_ERROR_INTERNAL.
On some devices, VFSFileSeek returns an EOF error when seeking to the end
of file, but the seek actually succeeds. A work around for this problem has
been implemented.
================(Build #2160 - Engineering Case #562227)================
Aggregates in sub-queries, containing outer references, were not always handled
correctly. This could have resulted in:
- bogus diagnostics regarding misplaced aggregation
- some illegal usages were not diagnosed
- incorrect results in some cases
This has been corrected.
================(Build #2156 - Engineering Case #561596)================
Incorrect values were being used by the SQL scanner for some hexadeciml constants.
This was corrected
================(Build #2150 - Engineering Case #561118)================
The persistent store was not being properly closed on open failure (such
as authentification failure) with write-at-end configuration. This could
have lead to problems reconnecting to the database. The store is now closed
on an open failure.
================(Build #2150 - Engineering Case #559941)================
NULL values were not being handled properly in single-valued SELECT queries.
The value was treated as if it was not null, and an unpredicatable value
was used. This has been corrected.
================(Build #2150 - Engineering Case #559897)================
If a critical error occurred and an application then called db_fini, without
first closing the connection, the database could have become corrupted.
This has been fixed.
================(Build #2149 - Engineering Case #561095)================
Incorrect results could have been obtained with queries containing IF search
expressions, aggregate functions, or references to columns not specified
in the GROUP BY clause. These are now diagnosed as errors.
================(Build #2149 - Engineering Case #559481)================
Executing an ALTER TABLE statement could have caused unneccessary database
growth.
================(Build #2146 - Engineering Case #557837)================
Incorrect results were possible when there was both an equality condition
and another redundant conjunctive expression such as:
x >= 2 AND x = 3
with only a column name on one side of the comparison. That column name
must also have been the first column in an index. This has now been fixed.
================(Build #2144 - Engineering Case #557685)================
UltraLite and UltraLiteJ erroneously accepted DEFAULT TIMESTAMP as a clause
in the CREATE TABLE and ALTER TABLE statements, and treated the clause as
if DEFAULT CURRENT TIMESTAMP had been entered. Attempts to execute CREATE
TABLE or ALTER TABLE statements with this clause will now result in a syntax
error.
================(Build #2140 - Engineering Case #556539)================
UltraLite and UltraLiteJ were not able to recognize a correlation name following
the table name in UPDATE and DELETE statements. Without this ability, WHERE
clauses that require the correlation name to disambiguate column references
could not be written.
For example:
update Employee E
set salary = salary * 1.05
where EXISTS( SELECT 1 FROM Sales S HAVING E.Sales > Avg( S.sales)
GROUP by S.dept_no )
The syntax for UPDATE and DELETE statements was been expanded to correct
this.
================(Build #2135 - Engineering Case #555033)================
Providing the function ML_GET_SERVER_NOTIFICATION() with long MobiLink stream
parameters (longer than 128 characters) could have caused the results of
the function call to be incorrect. This has been fixed so that the poll will
now work with arbitrary length
stream parameters
================(Build #2133 - Engineering Case #553600)================
A query of the form: "SELECT * FROM table-expression" could have
been misdiagnosed as a syntax error when there was exactly one column in
the select list. This has now been fixed.
================(Build #2126 - Engineering Case #552672)================
The combination of the HAVING clause containing a single-row subquery, and
a temporary table referenced in the ORDER BY and/or GROUP BY clauses, could
have produced incorrect results or a crash. This has now been fixed.
================(Build #2124 - Engineering Case #552144)================
The SQL script file passed to UltraLite’s ALTER DATABASE SCHEMA FROM FILE
statement and used by the SQL Passthrough feature, must have been in a specific
format. Each SQL statement must have ended with ‘go’ on a line by itself.
For example:
ALTER TABLE T RENAME R
go
This format was assumed and if 'go' was not found on a line by itself, nothing
would have been executed, but no error would have been generated. Now, the
error SQLE_SCRIPT_MISSING_DELIMITER (-1315) is generated if 'go' is not found
on a line by itself. Moreover, with this change the file may end with 'go<eof>'
(previously, it had to be 'go\n'). Note that even single line script files
must end with the “go” separator. This includes SQL Passthrough scripts.
So the following is a correct example of adding a SQL Passthrough script:
call ml_add_passthrough_script( ‘script1’, null, null, ‘ALTER TABLE T RENAME
R\ngo’ )
If an error occurs and only part of the file is applied, the database must
be shutdown and restarted (and the schema will as it was prior to the ALTER
DATABASE statement).
================(Build #2121 - Engineering Case #551692)================
If a query consisted of a non-zero number of UNION DISTINCT operations, followed
by a non-zero number UNION ALL operations, the result set could have had
twice as many columns as were specified by the query. The leftmost columns
would have been correct, while the rightmost extra columns were bogus. The
alorithm for creating the selection list for the overall query was flawed,
and has now been corrected.
================(Build #2278 - Engineering Case #582152)================
When using the the SQL Preprocessor (sqlpp) command line tool to generate
code for UltraLite, the -eu command line option was supposed to flag SQL
that UltraLite cannot handle. When this option was on, the following UltraLite-supported
statements would have been incorrectly flagged as Disallowed language extensions:
CREATE SYNCHRONIZATION PROFILE ...
ALTER SYNCHRONIZATION PROFILE ...
DROP SYNCHRONIZATION PROFILE ...
SYNCHRONIZE ...
This has been corrected. The workaround is to not use the -eu command line
option on SQLPP.
================(Build #2429 - Engineering Case #627238)================
The Include directory reference for the UltraLite CustDB sample on Windows
Mobile 6 platforms was incorrect. The Windows Mobile 6 platform Include directory
pointed to the %sqlanyX%\h directory, but should have pointed to %sqlanyX%\SDK\Include.
While correcting this, it was noted that there were inconsistencies in the
quoting of the Include directory across the projects. Now all references
are quoted.
================(Build #2427 - Engineering Case #626666)================
The UltraLite CustDB sample application About dialog incorrectly stated "for
Windows CE" for all Windows platforms. This has been removed from the
dialog text.
================(Build #2589 - 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 #2586 - Engineering Case #668855)================
Attempting to start Sybase Central on Linux systems would have failed with
the error message:
"The library /opt/sqlanywhere11/lib32/libulhltool11_r.so could not
be loaded. This may be because the provider is being re-loaded (in which
case you need to restart the viewer) or because the library could not be
found in the SQL Anywhere installation. Service management will not be available."
This has been corrected.
================(Build #2566 - 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 #2538 - 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 #2507 - Engineering Case #643953)================
In the Extract Database wizard for UltraLite, when checking or unchecking
publications using the space bar instead of the mouse, the Next button would
not have been enabled or disabled appropriately. This has been fixed.
================(Build #2464 - Engineering Case #634612)================
When F5 was pressed, or View -> Refresh Folder was selected, while creating
a new table in the Table Editor and No selected when prompted to save the
table, then the prompt to save dialog would have been shown again. This has
been fixed.
================(Build #2462 - Engineering Case #634440)================
In the Table Editor, a primary key column could have been marked for deletion
by selecting the column and pressing the Delete key, even though the Delete
menu item and Delete toolbar button were disabled. In such cases, attempting
to save the table could have caused Sybase Central to crash. This has been
fixed so that now pressing the Delete key does nothing when one or more of
the selected columns is in the primary key.
================(Build #2434 - Engineering Case #628275)================
Clicking Finish in the Load Database wizard would have caused Sybase Central
to crash if a database id was not specified on the last page of the wizard.
This has been fixed.
================(Build #2428 - Engineering Case #627061)================
The table on the Synchronization Information page of the Database property
sheet was editable, although changing the values had no effect. This has
been corrected so that the table is now read-only.
================(Build #2427 - Engineering Case #626662)================
The Load Database wizard would crash on a second attempt if the first attempt
failed, or was canceled, before completion. This has been fixed.
================(Build #2426 - Engineering Case #626469)================
In rare situations, the UltraLite plugin could have caused Sybase Central
to crash when being closed. This has been fixed.
================(Build #2414 - Engineering Case #623597)================
If a table's property sheet, or its Primary Key wizard, was opened while
the table's Data tab was showing, then any attempt to modify the table would
have resulted in a "Schema upgrade not currently allowed" error.
This has been fixed.
================(Build #2413 - Engineering Case #623481)================
If the Set Primary Key wizard was proceeded through without making any changes
and the Finish button was clicked, then an extraneous error message would
have been shown. Now the wizard simply closes.
================(Build #2413 - Engineering Case #623323)================
On the last page of the Create Database wizard, if a database name was specified
that differed from the database file name, then the database name would have
been ignored. The database would have appeared in the tree using the file
name, not the database name that was specified. This has been fixed.
================(Build #2413 - Engineering Case #623280)================
Renaming a table using its property sheet, and then attempting to open a
column's details on the Property sheet's Columns tab, would have caused Sybase
Central to crash. This has been fixed.
================(Build #2412 - Engineering Case #622944)================
When attempting to Cut and Paste a synchronization profile, the Paste operation
would have failed. This has been fixed.
Also, if a synchronization profile was first copied to the clipboard and
then modified before being pasted back from the clipboard into Sybase Central,
then the pasted synchronization profile would have contained the modifications.
This behaviour was at odds with all standard clipboard implementations and
has been corrected. Now, a copy of the synchronization profile is placed
in the clipboard and a copy is pasted from the clipboard so that the pasted
object exactly matches the copied object.
================(Build #2411 - Engineering Case #622767)================
If a user's property sheet was opened, the password changed, Apply clicked
and then the password changed and Apply clicked again, Sybase Central would
have crashed. This has been fixed.
================(Build #2411 - Engineering Case #622761)================
When editing table data in an UltraLite database, if a row was deleted and
the connection to the database was immediately dropped, then the delete would
not have been committed. This has been fixed.
================(Build #2411 - Engineering Case #622759)================
When editing table data in an UltraLite database, Sybase Central would not
have confirmed delete, update and cancel operations, even when the corresponding
UltraLite plug-in preferences were set to confirm these operations. This
has now been fixed.
================(Build #2488 - Engineering Case #638271)================
The methods ResultSet.getTimestamp() and ResultSet.setTimestamp() quietly
manipulated the database timestamp value as UTC. As a result, the javascript
methods Date.toString() and ResultSet.toString() would have reported different
values offset by the timezone difference. These methods now manage timetamps
in localtime relative to ULPOD. Databases with timestamp values stored prior
to this fix might contain values that were UTC based.
================(Build #2276 - Engineering Case #581830)================
The implementations of CreationParms::AddRef and CreationParms::Release,
contained confusing casting. Both methods cast the POD object to a ConnectionParms
object, which has now been fixed.
================(Build #2221 - Engineering Case #568836)================
Incorrect results could have been obtained when using an index which had
nullable columns In some cases, fewer rows were returned than were required.
This has been fixed..
================(Build #2160 - Engineering Case #562181)================
The UltraLite M-Business component was missing the following methods:
Class SyncParms:
String getPublications()
setPublications( String publication_list )
These methods are used to set the publications that will be used for synchronization
(publications control which tables get synchronized). The publications are
specified as a comma separated string. Earlier versions of the UltraLite
M-Business API used a "publication mask" to identify the publications
for synchronization. A mask was an internal number representing a set of
publications. The publication mask methods
were removed in version 11.0, and these methods were meant to replace them.
================(Build #2588 - 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 #2465 - Engineering Case #634532)================
Connections to a database using a large cache on Windows Mobile devices,
could have failed with the error SQLE_DYNAMIC_MEMORY_EXHAUSTED. This has
been fixed.
================(Build #2251 - Engineering Case #561616)================
Application errors could have occurred after opening and closing more than
255 connections. Each .NET connection allocated two SQLCAs, but only one
was freed when the connection was closed. The other would not have been
freed until the connection was garbage collected. This has been fixed.
A workaround for this problem is to call GC.Collect() regularly.
================(Build #2155 - Engineering Case #557818)================
When running on Windows CE devices, an UltraLite database could have failed
to start, reporting SQLE_DYNAMIC_MEMORY_EXHAUSTED, when the default cache
size chosen for the database was too large. The default cache size that is
now chosen takes the physical memory available in to consideration, and limits
our size accordingly. The cache size allocated on Windows was also somewhat
reduced. Specifying the cache_size connection parameter with an appropriate
value will work around this problem.
================(Build #2114 - Engineering Case #550260)================
When using UltraLite .NET, the ULConnection's SyncResult was not updated
after doing a synchronization via the SYNCHRONIZE SQL statement. This has
been fixed.
================(Build #2113 - Engineering Case #550120)================
An UltraLite .NET synchronization initiated by the SYNCHRONIZE SQL statement
would have hung if no global listener was provided via the DatabaseManager::SetGlobalListener
method. The unmanaged code always registered a global sync listener to send
sync status messages, but the managed code only created a listener for these
messages if the DatabaseManager::SetGlobalListener method was called, which
resulted in the hang. Now the unmanaged code now only registers a global
sync listener when SetGlobalListener is called.
================(Build #2598 - Engineering Case #665884)================
The UltraLite Load utility (ulload) would have crashed if the input XML contained
a synchronization profile, but no tables. This has been fixed.
================(Build #2589 - Engineering Case #665116)================
The UltraLite Unload utility (ulunload) would not have unloaded an empty
Synchronization Profile, such as:
CREATE SYNCHRONIZATION PROFILE "sp" ''
The query used to obtain the profile string for a specified Synchronization
Profile returned null. This would have resulted in the profile being skipped
during the unload. This has been fixed.
================(Build #2260 - Engineering Case #575493)================
The Unload Database or Upgrade Database wizards in the UltraLite plugin for
Sybase Central could have failed if the XML file was located in a path that
contained spaces. This has been fixed.
================(Build #2165 - Engineering Case #562972)================
Attempting to export data from a SQL Anywhere database into an UltraLite
database could have failed if a value being exported was a Date. This would
happen when the option return_date_time_as_string was set to ‘off’. This
is now fixed.
================(Build #2165 - Engineering Case #562971)================
Attempting to export data from a SQL Anywhere database into an UltraLite
database would have failed if a value being exported was null and the target
column in the UltraLite database was a unique identifier column. This is
now fixed.
================(Build #2147 - Engineering Case #557960)================
The UltraLite Unload utility (ulunload), when run with the -s option "Unload
schema as SQL statements", would have generated invalid unique constraints
when they contained more than one column. This has been fixed.
================(Build #2626 - Engineering Case #674740)================
Applications with small row limits (due to tables with a lot of columns),
several indexes and many open cursors (more than 8) on one table may have
experienced an ArrayIndexOutOfBounds exception while committing an update.
This has been fixed.
================(Build #2626 - Engineering Case #674441)================
Applications with small row limits (due to tables with a lot of columns),
many indexes, or large downloads, may have experienced an ArrayIndexOutOfBounds
exception while committing the download or while another thread was committing
a change parallel to a synchronization. This has been fixed.
================(Build #2622 - Engineering Case #674032)================
A database's in-memory state may have become corrupt if it had many indexes
on large tables and small row limits. This would have resulted in an ArrayIndexOutOfBounds
exception. The database itself was not actually corrupted and could have
been used after disconnecting and reconnecting. This has been fixed.
================(Build #2620 - Engineering Case #673561)================
The changes for Engineering case 623303 caused additional debug integrity
checks to be accidentally turned on. Row pages were being checked on every
INSERT and DELETE. This has now been fixed.
================(Build #2606 - Engineering Case #669242)================
An ArrayIndexOutOfBoundsException could have been thrown during a COMMIT.
This has been fixed.
================(Build #2569 - Engineering Case #660501)================
Incorrect results were possible when executing a query with an IN list consisting
of a single host variable. This has been corrected.
The work-around is to rewrite
expression in ( ? )
as
expression = ?.
================(Build #2568 - Engineering Case #660387)================
Incorrect results were possible for a deeply nested (at least a depth of
three) aggregate subquery. This has been corrected.
================(Build #2563 - Engineering Case #658845)================
Result set rows could have been presented in an incorrect order when all
of the following conditions were present for a SQL query:
- An index existed in which the first column (say col1) was specified to
be in descending order
- The query contained a search condition of the form "col1 LIKE expression"
where the expression started with non-wildcard characters.
- The query contained an ORDER BY starting with col1
This has been corrected.
================(Build #2555 - Engineering Case #652975)================
A NullPointerException was possible with large temporary tables and row limitation.
This was corrected.
================(Build #2551 - Engineering Case #655880)================
Second and subsequent '%' characters were not being handled properly in LIKE
clauses. This was corrected.
================(Build #2545 - Engineering Case #653070)================
A COMMIT could have failed after a failed synchronization involving clobs
or blobs. The failure could have left the blobs and/or clobs present in the
transaction log in a bad state. This has been corrected. A work-around is
to disconnect and then to reconnect to the database.
================(Build #2541 - Engineering Case #652920)================
A NullPointException was possible when executing an UPDATE statement when
nothing was updated. This was corrected.
================(Build #2529 - Engineering Case #649655)================
The result set returned by a query could have had an incorrect ordering when
different indexes could have been used to implement WHERE conjuncts and ORDER
BY clause This was corrected.
An example would be
SELECT * FROM table WHERE c1 = 10 ORDER BY c2
where c1 and c2 each were the first column in different indexes.
================(Build #2529 - Engineering Case #649528)================
Execution of DROP TABLE and DROP INDEX statements would not have failed when
the affected table was being referenced by another prepared statement. This
has been corrected.
================(Build #2507 - Engineering Case #644075)================
The DROP PUBLICATION statement was not being autocommitted, like other schema
changing statements. This has been fixed.
================(Build #2507 - Engineering Case #640579)================
Attempts to unload an UltraLiteJ database using the ULjUnload utility would
have resulted in a Null Pointer exception if the database had publication
IDs that were not numbered continuously from 1. This can occur if publications
are created then dropped. For example:
CREATE PUBLICATION pub1 ...
CREATE PUBLICATION pub2 ...
DROP PUBLICATION pub1
This has been fixed.
================(Build #2505 - Engineering Case #643660)================
The DATEPART and HOUR functions would have returned the Hours partion of
timestamps based on a 12 hour clock instead of a 24 hour clock. As a result,
any afternoon timestamps would have returned the wrong Hours value. This
has been fixed.
================(Build #2492 - Engineering Case #640515)================
An application could have failed to reconnect to a database created with
a user specified EncryptionControl. UltraLiteJ was failing to call EncryptionControl.initialize()
on connect, hence the database could not be opened. This has been fixed.
To workaround the problem, use code that explicitly invokes the initialize()
method prior to connecting to the database. For example:
// password = password to access database
// config = config object to access database
// MyEncryptionControl = user defined class extending EncryptionControl
EncryptionControl enc = new MyEncryptionControl();
enc.initialize( password );
config.setPassword( password );
config.setEncryption( enc );
conn = DatabaseManager.connect( config );
================(Build #2482 - Engineering Case #638596)================
The use of START AT or FIRST in a subquery may have resulted in incorrect
results. This was corrected.
================(Build #2480 - Engineering Case #638147)================
1. SyncParms.setAuthenticationParms( ",a,,b," ) was interpreted
as only having two authentication parameters ("a" and "b")
when it should be interpreted as 5 parameters ( "", "a",
"", "b" and "" ). This has been fixed. Blank
parameters are now correctly processed.
2. The documentation states that only the first 128 characters of each parameter
are sent to the MobiLink server, but no limit was actually enforced. This
resulted in corrupt data being sent to the MobiLink server if a value was
excessively large. This has been fixed. Extremely large strings (greater
than 21K characters) are now truncated prior to sending to the MobiLink server,
and the MobiLink server will however report an error now if the authentication
parameters' lengths exceed the server's limit of 128 bytes.
================(Build #2474 - Engineering Case #636438)================
The exception "ianywhere.ultralitej.implementation.JrException: UltraLiteJ
Error[-280]: Publication 'ul_no_pub' not found" may have been reported
for Connection.resetLastDownloadTime(Connection.SYNC_ALL_DB_PUB_NAME). A
workaround would be to call Connection.getLastDownloadTime(Connection.SYNC_ALL_DB_PUB_NAME).getTime()
prior to the call to resetLastDownloadTime(). This has been fixed.
================(Build #2472 - Engineering Case #636315)================
A database could have been corrupted when run with Lazy Loading and a prepared
query, which required a temporary table, was reused. This has been corrected
================(Build #2461 - Engineering Case #634294)================
Due to a bug in some BlackBerry OS versions, an UltraLiteJ application may
have failed to create a database on some simulators and devices. Typically,
the result would have been an I/O or access control error. This condition
may have occurred more frequently if UltraLiteJ was uninstalled and re-installed.
This has been fixed.
================(Build #2458 - Engineering Case #633740)================
Blobs and Clobs in temporary tables were not always being freed. This has
been corrected, truncation of temporary tables will now free blobs within
the freed rows.
================(Build #2458 - Engineering Case #633257)================
When synchronizing a table with NOT NULL LONG BINARY or NOT NULL LONG VARCHAR
columns, downloading an update to such a column could have resulted in an
UljException -300 "Run time SQL error -- fatal". This has been
fixed.
================(Build #2458 - Engineering Case #633003)================
Attempting to execute an UPDATE statement on a table with multiple indexes
and lazy loading, could have failed in various ways by throwing Java exceptions.
This was corrected
================(Build #2445 - Engineering Case #631404)================
The NOT NULL FOREIGN KEY clause was misdiagnosed as invalid in ALTER TABLE
statement. This was been corrected.
================(Build #2443 - Engineering Case #631030)================
Databases could not have been created on SD cards and the internal flash
of some older RIM devices. There were two problems in the RIM Operating
System late in the 4.2.1.x versions, extending to the 4.2.2.48 version, that
would have caused problems creating databases on these devices. An input
stream could not have been opened until something had been written to the
file, and the database file would have been destroyed on the second write
to the start of the file. These problems were resolved by reprogramming some
of the support for these devices so that the problems were not encountered.
================(Build #2434 - Engineering Case #628176)================
The changes for Engineering case 626303 caused the rollback after a synchronization
failure to possibly corrupt the database. This has been corrected.
================(Build #2433 - Engineering Case #627895)================
Since the change made for Engineering case 616657, very large indexes (3
or more levels) may have become corrupted resulting in an illegal cast java
error. When the page size was increased, the number of rows in the table
required to trigger this problem increased significantly. A work around would
be to increase the page size. This has now been fixed.
================(Build #2430 - Engineering Case #627381)================
The changes for Engineering case 619360 introduced a problem such that when
creating a database on a BlackBerry SDCard, or flash file store (file:///store),
and then releasing the database connection without doing any reads, a Null
Pointer exception could have resulted.
For example:
conn = DatabaseManager.createDatabase( config );
conn.release();
This has now been fixed.
================(Build #2427 - Engineering Case #626241)================
The UltraLiteJ Database Load utility (ULjLoad) would have failed with a syntax
error for tables with a name that was a reserved word, and either it was
involved in a foreign key, or it had data in the source XML file. This has
been fixed.
================(Build #2425 - Engineering Case #619360)================
UltraLiteJ could not have created a database in BlackBerry internal flash
on some models, such as 8300, 9700. This was due to a problem in the BlackBerry
software. A solution was found that was not impacted by the bug.
================(Build #2419 - Engineering Case #624826)================
Database corruption was possible when a null byte array was assigned to a
host variable using the PreparedStatement set method. This has been corrected.
================(Build #2413 - Engineering Case #623303)================
Database corruption was possible when there were multiple connections and
UPDATE statements are used with one of them. A COMMIT on a connection, when
another connection had an uncommitted UPDATE, could have caused the old row
in the UPDATE transaction to be incorrectly given the object_id of where
that row appeared in the uncommit log. This was corrected.
================(Build #2411 - Engineering Case #622871)================
A NullPointerException was possible when calling a DATEFORMAT function that
had a host variable as the first argument. This has been fixed.
================(Build #2406 - Engineering Case #619359)================
A NullPointerException was possible when there was a small difference in
row-limitation thresholds (see ConfigPersistent.setRowMinimumThreshold, setRowMaximumThreshold).
This has now been corrected.
================(Build #2393 - Engineering Case #618972)================
The J2ME Record Store did not record page reads or writes. This has been
corrected.
================(Build #2391 - Engineering Case #618423)================
When a download exceeded 4K is size, and the page size had been set to greater
than 4K, the synchronization would have failed, possibly with an ArrayIndexOutOfBoundsException.
This has been fixed.
================(Build #2381 - Engineering Case #616657)================
On BlackBerry devices and simulators, very large tables/databases (many rows)
could have resulted in an OutOfMemory error, even when lazy loading and row
limiting was enabled. This has been fixed.
================(Build #2373 - Engineering Case #614064)================
UltraLiteJ databases created as File Write At End or In Memory, would not
have allowed alter operations if there transactions with multiple operations
on the same row.
For example:
Given a table Test that had synchronization disabled, after the sequence
INSERT INTO Test( num, val ) VALUES( 1, 0 )
UPDATE Test SET val = 2 WHERE num = 1
COMMIT
it would have no longer been possible to alter the schema of table Test.
Attempts to do so would have resulted in UltraLiteJ Error[-121]: Permission
denied: unsynced transactions
This has now been fixed.
================(Build #2371 - Engineering Case #613986)================
Synchronizations could have failed after multiple updates and database closings.
This has now been fixed.
================(Build #2371 - Engineering Case #613838)================
When a row minimum threshold was specified that was too low (< 200), UltraLiteJ
would have chosen 200, and then checked the maximum threshold. If the maximum
threshold was less than the (adjusted) minimum threshold, it would choose
minimum+500. This has been corrected so that it now accepts a minimum row
threshold of 100 and if the maximum is less than theminimum, the maximum
is set to minimum + 50.
Note that applications may be forced to use small threshold values if they
have many transactions awaiting synchronization. This is fixed by synchronizing
more frequently.
================(Build #2371 - Engineering Case #613429)================
An UltraLiteJ database with many committed transactions (more than the row
maximum threshold) may have encountered a Null pointer exception during deletes
and updates. This has been fixed.
================(Build #2363 - Engineering Case #610279)================
The use of a host variable in the left operand of a LIKE operator could have
given incorrect results. This was corrected.
================(Build #2362 - Engineering Case #610520)================
The STRING() SQL function would have returned NULL when any of the parameters
were null.
This has been corrected so that if any parameters passed to the STRING()
function are non-NULL, then any NULL parameters are treated as empty strings.
This now conforms with the SQL Anywhere server.
================(Build #2359 - Engineering Case #608737)================
When utilities or applications attempt to connect to a database with 10000
or more rows and 5 or more indexes, the exception 'java.lang.OutOfMemoryError:
Java heap space exception' could have occurred if lazy index loading was
disabled. This has been fixed. The handling of large numbers of indexes has
been improved and utilities now use lazy loading, but it is possible for
this exception to still occurr for large databases.
A work around is to increase the heap space in the java starting line by
adding the VM option -Xmx256m. This also applies to the batch file that starts
uljunload, uljload and uljinfo.
================(Build #2358 - Engineering Case #609096)================
Rows containing non-ascii7 characters in VARCHAR() columns (but not LONG
VARCHAR columns) would have resulted in strings padded at the end with '\u0000'
characters.
For example (using SQL escape sequences) the string 'Ann\u00E9e' would have
downloaded as 'Ann\u00E9e\u0000' the and string 'Enqu\u00EAte qualit\uooE9
deux' would have downloaded as 'Enqu\u00EAte qualit\uooE9 deux\u0000\u0000'.
This has been fixed.
================(Build #2358 - Engineering Case #608354)================
The use of a host variable as the right operand of a LIKE operator, could
have given incorrect results when an index was used to optimize the search
condition. This was corrected.
================(Build #2356 - Engineering Case #608332)================
When executing a SQL statement that lead to an internal conversion between
Numeric types, the source Numeric value may have been corrupted by the conversion.
For example, if a value 5.12 in a Numeric(5,2) column was converted to a
Numeric(5,1) column, the source value would have been changed to 5.10 after
the conversion. This has been fixed.
================(Build #2356 - Engineering Case #608321)================
A host variable used by itsself as an item in an IN list could have caused
a crash (Null pointer exception). This has now been corrected.
================(Build #2355 - Engineering Case #608101)================
When processing a synchronization download, rows with VARCHAR columns that
had the total size exceeding the database page size would still have been
downloaded and processed. Following the synchronization, if these rows were
deleted, the database would have been in an error state. For example, if
the page size is 256, then the maximum size of VARCHAR columns is 243, due
to page overhead. However, UltraLiteJ would have accepted a VARCHAR of 244
bytes long during download. This has been fixed. Now UltraLiteJ will properly
reject rows that are too big due to VARCHAR columns' sizes, which means the
synchronization will fail.
================(Build #2354 - Engineering Case #607934)================
The system functions DAYS() and WEEKS(), when called with a single argument
under J2ME, could have generated incorrect results that were off by one.
This was now been corrected.
================(Build #2352 - Engineering Case #607117)================
Use of the WEEKS() and DAYS() functions could have erroneously thrown an
OVERFLOW exception. This has now been corrected.
================(Build #2347 - Engineering Case #606273)================
When the SQL statement ALTER TABLE ADD FOREIGN KEY was executed, the system
table sysfkcol did not contain the foreign columns for the new foreign key.
This meant that the foreign key relation would have been corrupt once the
database reboots. This has been fixed.
================(Build #2341 - Engineering Case #596417)================
There was a scenario, although rare, where an UltraLiteJ client may have
hung and no longer have been able to synchronize when MobiLink server farms
are involved. This has been fixed.
================(Build #2331 - Engineering Case #594465)================
The addition of fractional days to a timestamp value would have been incorrect.
This was corrected.
================(Build #2325 - Engineering Case #592670)================
A connection failure could have occurred following an application crash.
This would have occurred when there was an active temporary table and a commit
or rollback had been executed following the first fetch using the temporary
table. This has been corrected.
================(Build #2324 - Engineering Case #592638)================
Some DELETE operations may corrupted the database. This occurred when a row
was deleted from a multi-level index which was sufficienly full that no index-page
reduction was required, and no subsequent operations modified the database
page in question. This has been fixed.
================(Build #2321 - Engineering Case #592269)================
Very large dates or timestamp values, such as "9999-12-31", would
not have synchronized. The synchronization would have failed, possibly due
to the exception "UltraLiteJ Error[-85]: Communication error Unexpected
end of file from server", and the MobiLink sync log may have shown an
error like "[-10308] Upload data for column 15 of table 'SalesOrder_1_0_getlist'
is invalid"; however the column identified was not the column causing
the problem. It was also possible that no error was detected, but that subsequent
columns may have been corrupted. This has been fixed.
================(Build #2314 - Engineering Case #590017)================
When converting NUMERIC values to a VARCHAR, the server could have truncated
the results when the precision of the NUMERIC value exceeded 30. This has
been fixed by changing the conversion to produce a VARCHAR with size 2 plus
the precision of the source NUMERIC value.
================(Build #2313 - Engineering Case #590045)================
When executing a SELECT DISTINCT query against a newly created table with
no data, the runtime would have crashed with a NullPointerException. This
has been fixed.
================(Build #2313 - Engineering Case #589437)================
A single-value SELECT could have produced incorrect results when the select
list involved non-trivial expressions (such as function calls). This has
been corrected.
================(Build #2309 - Engineering Case #587308)================
The UltraLiteJ runtime would have crashed if a SQL statement had too many
terms (exceeding 150). UltraLiteJ used a fixed size stack to store the tokens
of the statement when parsing it. The problem has now been resolved by growing
the stack when necessary.
================(Build #2297 - Engineering Case #585735)================
For some queries, a result set row could have indicated that a column value
was not null, even if the value is null. Retrieving this value could then
have returned misleading, or invalid data. This has now been fixed.
================(Build #2297 - Engineering Case #585306)================
Reading a blob (long binary) value from the database would have taken 7 times
longer than it did to write the blob (as tested on a BlackBerry Bold). This
has been fixed.
================(Build #2276 - Engineering Case #582144)================
There were no implementations for the datatypes LONG BINARY and LONG VARCHAR.
These have now been added.
================(Build #2272 - Engineering Case #580647)================
Setting a TIME column from a java.util.Date, with only time information filled
in, could have failed with the Java 2 Micro Edition (J2ME). This has been
corrected.
================(Build #2270 - Engineering Case #580186)================
An INSERT statement, with a VALUES clause containing subquery expressions,
could have caused acrash. This has been corrected.
================(Build #2255 - Engineering Case #575495)================
When an INSERT or UPDATE was pending upload on a row, and there was a no-sync
DELETE on the same row, there may have been a row left in the row page store
for the table after the clean-up that is done after a successfull upload.
Had Index Persistence been turned off for the database and a row with the
same primary key been inserted or downloaded afterwards, there would have
been a primary key violation the next time the database was shutdown and
re-connected to.
Also, primary key violations could have occurred on databases with Index
Persistence tuirned off after error recovery from failed synchronizations.
These problems have now been fixed.
================(Build #2254 - Engineering Case #574929)================
When an UltraLiteJ client did a ping-only synchronization to a MobiLink server,
the authenticate_user connection event was not fired. This has been fixed.
A work around is to sync a single table (download only) with a different
script version, where that script does not have any upload or download scripts.
================(Build #2254 - Engineering Case #572973)================
During a large download, an out of memory error could have occurred on BlackBerry
devices and simulators. This has been fixed. The row limiting algorithm has
been improved, increasing the capacity of large downloads. To enable row
limiting, first enable lazy loading of indexes, then use ConfigPersistent.setRowMaximumThreshold()
and ConfigPersistent.setRowMinimumThreshold() to appropriate values (try
50,000 / (maximum cols per table + 1)).
================(Build #2223 - Engineering Case #569952)================
If an error occurred in the middle of the execution of a TRUNCATE TABLE statement
(11.0.1) or API (11.0.0, 11.0.1), a rollback of the deletes would not have
been done. This has been fixed.
Synchronizations with the special truncate table download_delete_cursor
may have resulted in a fatal error if a second connection did a commit after
the truncate was applied, but before the the synchronization completed.
This would have occurred only if there were more than a few rows in the table
being truncated (248 for 1K page size). This has been fixed.
================(Build #2223 - Engineering Case #569951)================
The number of rows affected was not being reported following the execution
of a TRUNCATE TABLE statement. This has been fixed.
Execution of a TRUNCATE TABLE statement would have failed with an SQLE_UNCOMMITTED_TRANSACTIONS
error ("You cannot synchronize or upgrade with uncommitted transactions
<table name>"), if there were any uncommitted transactions, even
on the current connection. This has been fixed. The TRUNCATE TABLE statement
will now only report an error if there are uncommitted inserts and updates
on another transaction. With this respect, TRUNCATE now behaves exactly
like DELETE.
================(Build #2219 - Engineering Case #569020)================
1. When two separate connections (including one that might be synchronizing)
are accessing the database in parallel, some lock row conflicts or download
conflicts may not have been detected.
For example:
Connection 1 deletes row with primary key value 2 but does not commit
Connection 2 inserts row with primary key value 2 - here there was an undetected
row locked or download conflict if connection 2 was synchronizing
When connection 1 was rolled back, a database corruption mau have occurred.
This has been fixed.
2. Duplicate primary keys during a download were not detected. If the download
contained two or more rows with the same primary key, the last row would
be kept (this is not neccessarily correct if the download_cursor script does
not have an ORDER BY clause). This has been fixed. UltraLiteJ will now report
the SQLE_DUPLICATE_ROW_FOUND_IN_DOWNLOAD error when this is detected. Like
UltraLite, this error is only reported for duplicate rows in the download_cursor
- no detection is done for duplicate rows in the download_delete_cursor,
or if the same primary key is in both the download_cursor and download_delete_cursor.
3. The all database synchronization would not have included new tables if
the database was synchronized before the table was added (unless the application
was restarted). This has been corrected.
================(Build #2210 - Engineering Case #568460)================
All database resources were not completely freed when an ALTER TABLE DROP
INDEX statement was executed. In particular, the database pages for the
rows and indexes of the table, before the table is rebuilt, were not being
freed. This has been corrected.
================(Build #2207 - Engineering Case #568263)================
A database could have been corrupted by an ALTER TABLE statement which changed
the nullability of a column. Because the nullability of a column affects
the internal storage format of row, all rows in the table must be reformatteded
when the nullability changes. This has been implemented.
================(Build #2204 - Engineering Case #567944)================
Incorrect results, including bogus error messages, could have been obtained
when aliases (from the SELECT list) were referenced in a GROUP BY clause.
This was corrected.
================(Build #2197 - Engineering Case #567328)================
When using an UltraLiteJ database with auto checkpointing and persistent
indexes, if two connections were open on separate threads it was possible
that changes committed to the database by the second connection may have
been lost, and space in the database lost. This would have occurred when
one connection was synchronizing (Connection.synchronize()) and the second
connection was commiting changes to the database (inserts, updates and/or
deletes), and the application terminated abnormally (power lost, crash).
If the Connection.synchronize() call completed successfully, or with an ULjException,
changes would not have been lost. This has now been fixed.
================(Build #2197 - Engineering Case #564479)================
When run on BlackBerry devices, the download of a large download_delete_cursor
of a table with many columns, UltraLiteJ could have reported an out of memory
error when the BlackBerry ran out of object handles. This would have occurred
even when many of the deletes were to be ignored by the client. The handles
used by a download are a factor of the number of rows times the number of
columns in each row. This has been fixed. UltraLiteJ normally applies the
download after all rows have been received, however, now it immediately rejects
deletes for non-existant client rows, and reduces significantly the handles
used by all other download deletes. In an ideal situation, the download_delete_cursor
script would reduce the number of rows sent by not sending any download deletes
if the last download timestamp was the newer value, or if the row corresponding
to the delete was never on the client (creation date greater than last download
timestamp).
================(Build #2190 - Engineering Case #566450)================
When executing queries involving index scans, the boundary values for the
scans could, in some cases, have been evaluated incorrectly causing the queries
to fail to return any results. This has been fixed
================(Build #2181 - Engineering Case #564866)================
An INPUT ststement, with multiple references to the same host variable, could
have been handled incorrectly when the leftmost reference was the host variable
by itself in the VALUES list, and another reference occurred in an expression
that was more complicated than just the host variable by itself.
For example,
INPUT INTO tab( pk, col1 ) VALUES( :hv, 100 - :hv )
This has been fixed so that the final substitution for non-leftmost host-variable
references is delayed so that the type of the first reference can be established.
================(Build #2162 - Engineering Case #562827)================
Using the concatenation operator '+' with VARCHAR and UUID did not produce
correct results. This has been fixed.
================(Build #2161 - Engineering Case #562619)================
Incompatible configurations could not have been used for connections. For
example, a database created with shadow paging would not have permited a
connection using a configuration that specified "at end" processing.
This has been corrected. Now, the physical configuration from the database,
not the configuration, is used when connecting to the database.
================(Build #2160 - Engineering Case #562398)================
Aggregates in sub-queries, containing outer references, were not always handled
correctly. This could have resulted in:
- bogus diagnostics regarding misplaced aggregation
- some illegal usages were not diagnosed
- incorrect results in some cases
This has been corrected.
================(Build #2156 - Engineering Case #561603)================
Synchronizing with UltraLiteJ, through the Relay Server to a MobiLink server
farm with more than one server, would have caused erratic behaviour. This
has been fixed.
================(Build #2150 - Engineering Case #559694)================
The persistent store was not being properly closed on open failure (such
as authentification failure) with write-at-end configuration. This could
have lead to problems reconnecting to the database. The store is now closed
on an open failure.
================(Build #2149 - Engineering Case #560924)================
Executing an ALTER TABLE statement could have caused unneccessary database
growth.
================(Build #2149 - Engineering Case #559678)================
Incorrect results could have been obtained with queries containing IF search
expressions, aggregate functions, or references to columns not specified
in the GROUP BY clause. These are now diagnosed as errors.
================(Build #2149 - Engineering Case #558580)================
Incorrect results could have been obtained with queries containing a temporary
table on left side of a LEFT OUTER JOIN. This has been fixed.
================(Build #2148 - Engineering Case #559403)================
If a connection with a Configuration object failed, for example due to an
incorrect password, a connection then with a corrected configuration object
would have caused a SQLE_CONFIG_IN_USE error to have been thrown. This has
been fixed.
================(Build #2128 - Engineering Case #553309)================
A cursors position in a result set was not always correct after changes were
made (i.e. inserts, updates and deletes). This has been corrected.
================(Build #2125 - Engineering Case #552323)================
The conversion of NUMERIC values to or from VARCHAR was incorrect. This has
now been corrected. UltraLiteJ should now produce the same conversions as
does UltraLite.
================(Build #2124 - Engineering Case #552226)================
The cast of a LONGVARCHAR value to VARCHAR value could have caused a crash.
This has now been fixed.
================(Build #2121 - Engineering Case #551839)================
Host variables used as function arguments did not work correctly. This has
now been fixed.
================(Build #2108 - Engineering Case #549142)================
The LIKE operation could have produced incorrect results. The operation did
not operate case insensitively, and the first character of a range was not
accepted. This problem has now been fixed.
================(Build #2618 - Engineering Case #673024)================
The message "Number of tables that are never synchronized:" would
have returned the number of tables that were synchronized instead of the
number that were never synchronized. This has been fixed.
Also, the message "Number of tables that will always be uploaded:"
was incorrect and misleading and the number displayed was invalid. This
message has been changed to "Number of tables that are in publications:"
and the output has been corrected.
================(Build #2486 - Engineering Case #634340)================
Synchronizations that worked fine on a BlackBerry Bold 9700 with OS 5.0.0.351,
failed when the device was upgraded to 5.0.0.743. The application did not
use BES or BIS communication, but tried Direct TCP, WAP 2.0 and WAP 1.x.
When using BES or BIS communication, there was no issues with synchronization.
This problem has been report to Research In Motion since it was discovered
that calls to InputStream.read() had an additional 10 seconds overhead with
OS 5.0.0.743 when using WAP 2.0 (and simillar delay with DirectTCP and WAP
1.x). UltraLiteJ has now been patch edto reduce the impact of this issue.
For the most reliable synchronization, a device should be paired with a
BES (BlackBerry Enterprise Server) or the application should use BIS communication
(application provider can join RIM partner program for free and then apply
to use the BIS protocol).
================(Build #2451 - Engineering Case #632530)================
The UltraLiteJ Database Unload utility (ULjUnload) would have output control
characters (other than \t \r \n) or non-ASCII characters (>= \u007f) into
its XML output without escaping them. This would have made the resulting
XML file unreadable by many tools, including the UltraLite Load XML to Database
utility (ulload). This has been fixed.
================(Build #2354 - Engineering Case #607936)================
When a nullable column had a column default specified, and a row with that
column set to null was inserted, the null value is ignored and the column
default value was inserted instead. This behaviour was incompatible with
UltraLite and SQL Anywhere. More seriously, when a nullable column had a
column default specified, and the table with that column was altered by an
ALTER TABLE statements, all the rows with null values in that column would
have been replaced by the column defaults. The following SQL statements were
affected. In all these cases, null values would have been replaced by column
defaults.
1. INSERT () VALUES ();
2. INSERT () select-statement;
3. ALTER TABLE ADD column-definition;
4. ALTER TABLE DROP column-name;
5. ALTER TABLE ALTER column-definition.
This has been corrected. Now all the null values are preserved in these
scenarios.
================(Build #2354 - Engineering Case #607636)================
Under virtually all circumstances, the Database Information utility (ULjInfo)
would have terminated abnormally when opening a valid database file. The
error message would have been "getOrdinal(string) not supported".
This has been corrected.
================(Build #2350 - Engineering Case #606678)================
If a database contained BINARY type data that ended with one or more bytes
of 0's, the 0's would have be truncated by ULjUnload when written to the
output. This has been fixed.
================(Build #2350 - Engineering Case #606629)================
When the XML input to ULjLoad contained one of the two following scenarios,
ULjLoad would have rejected the file, even when it should have accepted it.
1. If a foreign key constraint comes before the definition of the primary
table;
2. If the order of the tables in the data part does not follow the order
of the tables in the schema part;
These problems have been fixed, but rearranging the schema definition or
the data in the XML will workaround these problems..
================(Build #2349 - Engineering Case #606247)================
When unloading VARCHAR or LONG VARCHAR data, the special characters "(double
quote) and `(apostrophe) were not replaced by their escaped counterparts
" and ' in XML. This may have caused the unloaded XML file
to be invalid.
In addition the characters \r(carriage return), \n(line break) and \t(tab)
were not replaced by the character references 
 
 and 	.
As a result the these characters were being treated exactly the same as empty
spaces in the unloaded XML file.
These problems have now been fixed.
================(Build #2328 - Engineering Case #593143)================
When running the database transfer tool on a BlackBerry Bold, the buttons
were too small to display all text. Only the first character, plus some ellipses
showed up on all buttons. This has been fixed.
Now, all buttons display normally. However, the layout of the buttons is
affected. They are aligned to the left, instead of in the center.
After the fix, buttons on other models of the BlackBerry remain legible.
================(Build #2296 - Engineering Case #585077)================
The Database Transfer utility would have failed to transfer some databases.
After establishing the connection, the utility would have immediately finished
the transfer, and the progress bar on the client would still have indicated
0%. The log on the desktop utility would have shown a negative value for
chunks of data expected. This has been fixed.
================(Build #2156 - Engineering Case #562037)================
When using the UltraLiteJ Database Load utility (uljload) with the -d option,
in combination with the -a option, in order to load data into an existing
database with the schema information in it, no data was loaded into the database.
This has been fixed.
================(Build #2155 - Engineering Case #560908)================
When the UltraLiteJ Database Transfer tool was run on a BlackBerry device
or simulator, a user may have left the password field blank assuming that
the utility would use the default password "dba". However, leaving
the password field blank would have resulted in a failure to connect to the
database. This has been corrected. If the password is now left empty, the
default password will be used to connect to the specified database.
================(Build #2147 - Engineering Case #562026)================
Using the UltraLiteJ Database Load utility (ULjLoad) with the -a, -i or -f
options may have caused the tool to crash or produce incorrect results. The
rows loaded without the -i switch would still be synced to the server. The
-a switch would not load schema information from an existing database file.
The -f switch would crash the tool. These problems have now been fixed.