SQL Anywhere Bug Fix Readme for Version 17.0.0, build 2053
Choose a range of build numbers for which to display descriptions. For example if you want to see what was fixed since the last build you applied then change 1062 to the build number of that last Support Package. Click Update Readme to make those changes take effect. to Update Readme
A subset of the software with one or more bug fixes. The bug fixes are
listed below. A Bug Fix update may only be applied to installed software
with the same version number.
While some testing has been performed on the software, you should not distribute
these files with your application unless you have thoroughly tested your
application with the software.
A complete set of software that upgrades installed security/encryption components
while only updating the SQL Anywhere components to the level of the previously
released build for a given platform.
These are generated so that security/encryption changes can be provided quickly.
If any of these bug fixes apply to your installation, iAnywhere strongly recommends
that you install this fix. Specific testing of behavior changes is recommended.
================(Build #1486 - Engineering Case #798416)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1t.
================(Build #1443 - Engineering Case #796406)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1s.
================(Build #1410 - Engineering Case #795323)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1r.
================(Build #1351 - Engineering Case #793255)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1q.
================(Build #1310 - Engineering Case #791709)================
A new client network option has been added, “allow_expired_certs”. When set,
MobiLink clients will accept a server certificate that has either expired
or is not yet valid and continue with the synchronization (unless there is
some other problem with the certificate). By default, the sync will fail
in this case with an appropriate error, which was the previous behavior.
================(Build #2006 - Engineering Case #796815)================
The .NET 4.0 version of the SQL Anywhere .NET Data Provider has been removed.
Microsoft no longer provides security updates, technical support or hotfixes
for .NET 4.0. Later versions of .NET 4 continue to be supported by the SQL
Anywhere .NET Data Provider.
================(Build #1270 - Engineering Case #789513)================
SetupVSPackage.exe did not register the SQL Anywhere .NET DDEX Provider with
Visual Studio 2015. This problem has now been corrected.
================(Build #1287 - Engineering Case #790641)================
There are now multiple versions of the node.js drivers shipped for JavaScript
clients and JavaScript external environments, as well as the open-source
driver hosted on github.com and npmjs.com. A driver is now available for
each of the following node.js versions: 0.10, 0.12, and 4.x.
================(Build #2010 - Engineering Case #797189)================
If the server is started with either TLS or HTTPS and a certificate that
(a) uses the SHA-1 hashing algorithm and (b) expires in 2017 or later, a
warning is now displayed on the console. The warning states that a SHA-1
certificate is being used, and that the certificate should be upgraded to
SHA-2.
================(Build #1384 - Engineering Case #794651)================
SQL Anywhere spatial support now permits geometries to be created outside
of the SRS bounds. Geometries were previously allowed to exceed SRS bounds
by 50% in each direction, but beyond that SQLE_SLERR_OBJECT_OUT_OF_SRS_BOUNDS
(-1484) would have been raised. The same error would also have been raised
on round-earth SRS if the geometry points exceeded the maximum allowable
range (lon -360 to 360; lat –180 to 180). These geometries can now be created
provided that all points can be represented in the SRS coordinate system
and the geometry remains trivially valid.
In case of a round-earth SRS, the coordinates will be wrapped so that they
fall within the allowable range. If latitude crosses a pole, it is adjusted
relative the the pole that it crosses and the longitude is adjusted by 180
degrees to compensate. Longitude is simply adjusted by 360 degrees until
it falls in the allowable range. The resulting geometry is then checked
against the specific SRS bounds.
When a geometry is created that exceeds the SRS bounds, it is flagged as
such. If that geometry is used in an index, it is treated as though it consumes
the entire SRS, effectively causing a linear scan over the out-of-bounds
geometries. Other internal indexing is also disabled.
Lack of index support will cause queries over tables that include out-of-bounds
geometries to be slow, but they should work as expected.
In order to detect geometries that are not indexable, a new predicate ST_IsIndexable()
has been added. A geometry is indexable if it is trivially valid and fits
within the expanded bounds of the SRS. For example:
select new ST_Point( 0, 0, 1000004326 ).ST_IsIndexable() — returns 1 because
it is within the SRS bounds
select new ST_Point( 210, 0, 1000004326 ).ST_IsIndexable() — returns 1 because
it is within the expanded SRS bounds (bounds + 50%)
select new ST_Point( 361, 0, 1000004326 ).ST_IsIndexable() — returns 0 because
it is outside of the expanded SRS bounds
For a round-earth SRS with standard boundaries (lon –180 to 180; lat –90
to 90), ST_IsIndexable() will always return 1.
================(Build #1384 - Engineering Case #794347)================
The server could have failed an assertion or fail to create some valid round-earth
geometries. This has been fixed.
================(Build #1382 - Engineering Case #794129)================
The server performs performance rewrites on ISNULL and COALESCE function
argument lists based on the nullablility of the arguments. More rewrites
can now also be done if the argument contains a referencing old or new column
of a trigger.
================(Build #1455 - Engineering Case #782143)================
In previous versions, SQL Anywhere had two licensing models: per seat licensing
and processor licensing. In SQL Anywhere 17, processor-based licensing is
replaced by core-based licensing.
The licensing utility, dblic.exe, has been updated to recognize a new license
type (core) and has removed (processor) from the list of valid license types:
SQL Anywhere Server Licensing Utility Version 17.0.0.1000
Usage: dblic [options] license_file ["user name" "company
name"]
@<data> expands <data> from environment variable
<data> or file <data>
Options (use specified case, as shown):
-l <type> license type: perseat or core
-k <key> registration key
-o <file> append output messages to file
-q quiet: do not display messages
-u <n> number of users or processors for license
================(Build #1215 - Engineering Case #786658)================
Starting in version 16, the Interactive SQL utility displayed a warning on
shutdown (or disconnect) if there were uncommitted database changes, and
the option to commit on exit was not enabled. The window that contains that
warning now has a checkbox which allows for suppressing the warning. It can
also be disabled, or re-enabled, by going to the Options dialog and the SQL
Anywhere -> Execution tab.
================(Build #1283 - Engineering Case #792599)================
UltraLiteJ for Android is now supported on Android 6.0 platforms. Supported
platforms are: Android 6.0 ARM 32bit, Android Intel 6.0 32bit and 64bit (using
32bit binaries).
================(Build #1189 - Engineering Case #786041)================
UltraLite is now supported for 32-bit Linux. Users should take note of the
following special instructions for installation. When installing for the
first time, or overwriting a current installation, then the option "1.
Create a new installation" should be selected and then the components
desired to be installed can be selected. Note that 32-bit UltraLite will
be available for install. If, instead, the user wishes to upgrade an existing
install, then the setup program must be run twice. The first time, to install
the new feature, 32-bit UltraLite, choose the menu item "2. Modify
an existing installation". Then run the setup again, to update all of
the rest of the files, choose the menu item "3. Upgrade an existing
installation".
================(Build #1218 - Engineering Case #787421)================
UltraLiteJ for Android is now supported on Android arm64 platforms. The
existing 32-bit ARM libraries will work on CPUs with arm64-v8a architecture.
================(Build #1217 - Engineering Case #787356)================
UltraLiteJ for Android is now available for Android x86 platforms. Native
libraries built for x86 CPU architecture are now available. These libraries
also work on devices with x86_64 CPUs.
================(Build #1164 - Engineering Case #784657)================
In the Create User Wizard dialog, if there was no authentication defined,
the LDAP authentication policy drop down would be empty but it would still
be possible to select “This user authenticates using an LDAT server”. Doing
this caused an NPE when the wizard completed.
Now the LDAP related controls are not shown on the page unless there is
an authentication policy defined.
================(Build #1163 - Engineering Case #784577)================
Right clicking on a MobiLink Server command line and choosing Copy would
have caused a null pointer exception. This has been fixed.
================(Build #1420 - Engineering Case #795641)================
On Linux systems, opening help did not work if the machine used a network
proxy. This has been fixed.
================(Build #2019 - Engineering Case #797284)================
The Apache Relay Server could have crashed while it was shutting down. This
has been fix.
================(Build #1432 - Engineering Case #795977)================
If the SQLANY17 environment variable had been set to a path that included
spaces, then the iis7_plus_setup.bat file in %SQLANY17%\RelayServer\IIS directory
would have created directories in the wrong locations, causing the setup
to fail. This has now been fixed
================(Build #1258 - Engineering Case #789326)================
The Relay Server for Apache did not relay all duplicate HTTP response headers
received from the backend server that had the same header name, regardless
of value. Only the last duplicate header that was read was sent back to the
client. This has been fixed.
================(Build #1414 - Engineering Case #790558)================
If a SQL Remote or Dbmlsync hook procedure had been owned by dbo, they would
not have been found by the log scanning tool, and thus would not have been
called during replication or synchronization. This has now been fixed.
================(Build #1341 - Engineering Case #792594)================
If the SQL Anywhere MobiLink Client had to scan a large number of blobs from
the transaction log, it could have been slow. The performance of the log
scanning code when scanning blobs has been improved, although the benefits
of this change are highly dependent on the available memory and processor
power of the machine, as well as the blobs themselves.
================(Build #1331 - Engineering Case #792439)================
If an HTTP server or other intermediary converted an HTTP response to be
chunked-encoded, the synchronization would have failed. This has been fixed.
================(Build #1237 - Engineering Case #788219)================
It was possible that when a synchronization with HTTP or HTTPS failed, a
duplicate HTTP request could have been sent to the server. This would most
likely have lead to a sync failure, but there was a small chance that this
could cause data corruption. This has now been fixed.
================(Build #1157 - Engineering Case #784330)================
If HTTP or HTTPS was being used for synchronization, and a new MobiLink synchronization
request was sent to a socket on which a different synchronization had already
taken place or on which a synchronization was currently active, the MobiLink
Server could have reported an error indicating the ml-session-id had changed
or could have disconnected the active synchronization. This has now been
fixed and the MobiLink Server allows for new HTTP synchronizations to arrive
on the same socket as a previous or active synchronization.
================(Build #1451 - Engineering Case #796694)================
The MobiLink server could have crashed when using restartable downloads with
the –wn option set to be greater than 1. This has been fixed.
================(Build #1428 - Engineering Case #796136)================
The MobiLink server could have crashed when using HTTPS with –wn set to be
greater than 1.
================(Build #1411 - Engineering Case #795422)================
Clients could have crashed the MobiLink server after successfully authenticating.
This has been fixed.
================(Build #1397 - Engineering Case #795574)================
A number of problems with restartable downloads have been fixed:
- The sync server could have crashed
- The sync server could have reported an error instead of waiting if the
sync being restarted had not yet finished
- Download restarts were unnecessarily slow
- If a remote sent more than one restart request for its download, the
last one sent would sometimes fail because the server processed the last
one received, which may have been different from the last one sent
- It was possible to store more restartable download data than specified
with the –ds switch
- Failed, restartable syncs waiting for a resumption request would have
appeared stuck in the sending download phase of the MobiLink Profiler
================(Build #1396 - Engineering Case #794717)================
There were a number of problems with restartable downloads:
- the MobiLink server could have crashed
- the MobiLink server could have reported an error instead of waiting,
if the sync being resumed hadn’t yet finished
- download resumption was unnecessarily slow
- if a remote sent more than one restart request for its download, the
last one sent would sometimes fail because the server processed the last
one received, which may have been different from the last one sent
- it was possible to store more resumable download data than specified
with the –ds switch
- failed, resumable syncs waiting for a resumption request would appear
stuck in the sending download phase of the MobiLink Profiler
These issues have now been fixed.
================(Build #1356 - Engineering Case #793877)================
The MobiLink server would only have shown the major and minor parts of a
version string in a trace file and suppress the patch level of the client.
This problem is fixed. Now the MobiLink server will show the full client
version string including the major, minor, and patch strings as well as the
build number in its trace file.
================(Build #1343 - Engineering Case #792866)================
The MobiLink server could have crashed. This has been fixed.
================(Build #1334 - Engineering Case #792597)================
A file I/O error during a file transfer upload could have been reported as
protocol error 400. This has been fixed.
================(Build #1268 - Engineering Case #789932)================
UltraLite clients could get into a state where every sync would fail with
error -10400: “Invalid sync sequence ID for remote ID”. This has been fixed.
================(Build #1243 - Engineering Case #788454)================
The MobiLink server would have generated the error: “[-10013] Version ‘…’
not found in the ml_script_version_table. Cannot synchronize”, if a client
requested a sync with a script version that was not implemented in the consolidated
database. Implementing the script version into the consolidated database
and syncing again, the MobiLink server would still complain with the same
error. This problem is now fixed.
The workaround is to restart the MobiLink server.
================(Build #1231 - Engineering Case #787658)================
The MobiLink server could have crashed when using HTTP. This has now been
fixed.
================(Build #1180 - Engineering Case #785534)================
If an attempt was made to get a bit, tinyint or decimal data type from an
IDataReader from the UploadData object, a System.InvalidCastExecption error
would have been thrown. This has now been fixed.
================(Build #1180 - Engineering Case #785533)================
It was possible that when attempting to get a GUID data type from a DBRowReader,
a System.FormatExecption exception could have been thrown, even though there
was no issue with the format of the GUID. This issue has now been fixed.
================(Build #1180 - Engineering Case #785453)================
There were two problems when gathering integer values from a DBRowReader
from the MobiLink .NET API.
- If an attempt was made to get an unsigned smallint, integer or bigint
from a DBRowReader, a System.OverflowException would have been thrown if
the value was greater than the maximum value for the signed version of the
data type.
- If an attempt was made to get a tinyint from a DBRowReader, a System.InvalidCastExpection
would have been thrown.
Both these issues have been fixed.
================(Build #1180 - Engineering Case #751840)================
If the machine where the MobiLink Server was running had a localized setting
such that the decimal separator was not a period (for example, a comma),
there were a number of problems when the MobiLink .NET API was used to synchronize
data.
- Attempting to get a decimal data type from an IDataReader from the UploadData
object could have resulted in a System.FormatExecption error
- Attempting to get a real, double or decimal data type from a DBRowReader
could have resulted in a System.FormatExecption error
- Attempting to use a real or double data type in a DBParameter added to
a DBCommand could have resulted in an error indicating that the value could
not be converted to a real or double
These problems have now been fixed.
================(Build #1360 - Engineering Case #793794)================
In some circumstances, retrieving a query result set from an Oracle database
through the SQLA ODBC driver could have been slow, especially for tables
with a small row width, because the ODBC driver fetched only 20 rows from
the database server each time. In order to make the fetching row size more
flexible, a new DSN configuration parameter, “Fetch array size (rows)” has
been introduced. This parameter can be set from the “Configuration for SQL
Anywhere driver for Oracle” dialog box on Windows, or using the new DSN entry,
FetchArraySize=xxx on UNIX. The default value for this new parameter is
20 and the default value will be used if the setting for this parameter is
not specified or if this parameter is set to be zero.
Increasing the “Fetch array size” reduces the number of round trips on the
network, thereby increasing performance. For example, if your application
normally fetches 100 rows, it is more efficient for the driver to fetch 100
rows at one time over the network than to fetch 20 rows at a time during
five round trips over the network. However, increasing the “Fetch array
size” will also increase the memory usage by the ODBC driver.
================(Build #1261 - Engineering Case #789321)================
The output data from stored procedure calls could have been truncated by
the SQL Anywhere ODBC driver for Oracle, if the SQL_C_WCHAR data type was
used when binding the INPUT_OUTPUT or OUTPUT parameters, and the Oracle OCI
library, version 12.1.0.2.0 was used. This problem is now fixed.
================(Build #1462 - Engineering Case #797203)================
When using the SQL Anywhere .NET provider, it was possible to get an exception
when closing a pooled connection. The exception error text was “Invalid user
ID or password”.
This exception could have occurred for any condition where a connection
was not returned to a pool, for example, when a password had changed. The
complete list of conditions for which a connection is not pooled are described
at http://dcx.sap.com/index.html#sqla170/en/html/814d6d5c6ce2101482c9b5abd7938330.html.
This problem has been fixed. The .NET application will no longer see the
exception, and the connection is closed but not pooled.
================(Build #1462 - Engineering Case #797124)================
When using the SQL Anywhere .NET provider, it was possible to get a NullReferenceException
when calling ClearAllPools. This exception could have occurred in multithreaded
.NET applications that open or close pooled connections while another thread
calls ClearAllPools. This problem has been fixed. The .NET application will
no longer see the exception.
================(Build #1356 - Engineering Case #793308)================
The performance of the ADO.NET connection pool was slow compared to the .NET
ODBC bridge. Several changes have now been made to improve the performance.
================(Build #1349 - Engineering Case #793189)================
When attempting to call a stored procedure with many parameters with long
names, an error could have been returned indicating that parameters were
mismatched.
For example, when attempting to call a stored procedure with 99 very long
parameter names:
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_2",
10);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_1",
5);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_55",
550);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_54",
"string");
.
.
.
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_98",
980);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_97",
970);
myCommand.Parameters.AddWithValue("@param_with_a_very_long_name_99",
990);
SADataReader myDataReader = myCommand.ExecuteReader();
the SQL Anywhere .NET provider should have matched parameter names with
actual parameter names so order should not have mattered. The provider was
not setting aside enough memory for the parameter name lookup, resulting
in matching by order rather than name.
This problem has been fixed.
================(Build #1298 - Engineering Case #791082)================
When loading and unloading the SQL Anywhere ADO.NET provider assembly via
AppDomain.CreateInstance with connection pooling enabled, the unload of the
assembly would hang in Sap.Data.SQLAnywhere.SAUnmanagedDll.Finalize(). This
has been fixed.
A workaround is to disable connection pooling on the connection string (Pooling=False).
================(Build #1271 - Engineering Case #785764)================
When using the .NET GetSchemaTable() method for a query on a table whose
name was not unique, an exception could have occurred in the provider. This
problem has been fixed.
For example, suppose the following query was executed against the table
“employees” owned by DBA, and there also exists a table “Employees” owned
by the user GROUPO.
SACommand cmd = new SACommand("SELECT * FROM DBA.employees", conn);
SADataReader reader = cmd.ExecuteReader();
DataTable schema = reader.GetSchemaTable();
An exception was raised in the GetSchemaTable call. When the tables have
the same letter case, then an exception would not have occurred but the wrong
schema information could have been returned.
================(Build #1257 - Engineering Case #787963)================
The .NET Data Provider would have generated an exception when attempting
to connect to a database server that had more than two digits in the minor
version. For example, the provider would have generated System.ArgumentOutOfRangeException
parsing the following version string:
SAP IQ/16.0.101.1215/20034/P/sp10.01/…
This problem has been fixed.
The normalized version string that is returned by the ServerVersion property
now has the following format:
##.##.###.####
^ ^ ^ ^
| | | |
| | | Build Number
| | Minor Version
| Major Version
Release Version
This new format is also used in the DataSourceInformation collection (DataSourceProductVersion
and DataSourceProductVersionNormalized).
================(Build #1218 - Engineering Case #787422)================
The changes for Engineering case 766113 caused the .NET Data Provider to
attempt to set the CHAINED option to ON when connecting to the utility database.
This resulted in the error “Permission denied: you do not have permission
to execute a statement of this type” when connecting to the utility database,
due to this option being disallowed for the utility database. This problem
has now been fixed.
================(Build #2030 - Engineering Case #797513)================
In the SQL Anywhere Profiler, when the "Operations" or "Blocking"
tab was selected, clicking the Edit/Copy menu did nothing. This has been
fixed.
================(Build #2000 - Engineering Case #788771)================
The filter grammar used by the SQLA Profiler contains some keywords that
are made up of multiple words. Most of these keywords are run together without
an intervening blank (e.g. "ConsoleMessage"), but two include a
blank: "this week" and "last week".
In order to make the grammar easier to use, the Profiler now accepts "ThisWeek"
and "LastWeek" as synonyms for "This Week" and "Last
Week".
================(Build #1461 - Engineering Case #797126)================
The SQL Anywhere Profiler could have blocked statement execution in the database
to which it was connected if triggers fired. This has been fixed.
================(Build #1441 - Engineering Case #796314)================
In the SQL Anywhere Cockpit, when trying to filter the database property
list or the alerts list, the list will always clear. This has been fixed.
================(Build #1440 - Engineering Case #796269)================
The SQL Anywhere Profiler could have incorrectly reported low CPU usage if
the server process used fewer logical processors than were available on the
machine. This has been fixed.
================(Build #1351 - Engineering Case #793262)================
The "Profiling" tab of the SQL Anywhere Profiler contains two tables:
the top one lists the stored procedures that were called, while the bottom
one shows the SQL source for the selected procedure. The vertical scroll
position of the second (source) table was always reset to the top whenever
the Profiler read new stored procedure profiling data. For a busy database,
that meant that reading the source could have been very difficult because
the contents were always being scrolled to the top. This has been fixed.
================(Build #1348 - Engineering Case #793124)================
When running the SQL Anywhere Cockpit, the following message would occasionally
have been written to the database server console “Cannot convert ‘’ to timestamp”.
It was also possible for this message to have been reported in a message
box when interacting with the SQL Anywhere Cockpit in a browser. This has
been fixed.
================(Build #1343 - Engineering Case #792865)================
The SQL Anywhere Profiler has a "Statements" tab which lists the
statements that have been executed and how long they took. If a saved profiler
session file (a .sqlap file) was loaded, statements were shown executing
twice as often as they actually were. This has been fixed.
================(Build #1325 - Engineering Case #792141)================
After a 30 minute period of inactivity the SQL Anywhere Cockpit will automatically
log out the user. If the alert configuration dialog was open when this happened,
the user was logged out but the dialog remained open. This has been fixed
so that the dialog now closes.
================(Build #1321 - Engineering Case #792086)================
On the Thing Inspector for the “CPU usage is high” alert, there is a server
settings tile. Clicking on the links in the server settings tile would have
incorrectly navigated to the “Properties” page of server Thing Inspector.
Now, clicking on the links in the server settings tile opens the Server Thing
Inspector and navigates to the “Settings” page.
================(Build #1312 - Engineering Case #790676)================
The SQL Anywhere Profiler's filter syntax includes a time unit (seconds,
minutes, hours, days, or weeks). Previously, the names of the times had to
be specified in English, unlike the rest of the filter syntax which is localized.
Now, localized versions of the keywords "seconds", "minutes",
"hours", "days", and "weeks" are accepted.
The symbols for these units are NOT localized, and continue to be "s",
"m", "h", "d", and "w". "min"
can also be used to denote minutes.
================(Build #1310 - Engineering Case #791661)================
When copying numeric data from a result set to the clipboard in the Interactive
SQL utility or SQL Central, the copied value would have incorrectly included
the thousands separator when copying cells or column. This has been fixed
so that the thousands separator is not used in any copied data.
================(Build #1308 - Engineering Case #791559)================
When the "Operations" tab was selected, clicking the "Tools/Suggest
Index for Statement" menu did nothing. Now, it opens the Index Consultant
for the selected statement.
A work-around for this problem is to right-click the operation on the "Operations"
tab, and click "Suggest Index for Statement" from the context menu.
================(Build #1300 - Engineering Case #791227)================
UI5 clickjack thwart introduced in version 1.28 now implemented in the SQL
Anywhere Cockpit.
================(Build #1289 - Engineering Case #790739)================
In the SQL Anywhere Profiler, the tooltip for the "Server Load"
panel contains a timestamp which is usually formatted using whatever timestamp
format the system (OS) has been configured to use. On Japanese and Chinese
systems, the timestamp was formatted with incorrect characters. This has
been fixed.
================(Build #1284 - Engineering Case #790552)================
When running the SQL Anywhere Cockpit, in some circumstances an error similar
to the following may have been printed to the database server log:
Error while evaluating SQLA Cockpit Alerts
Cannot convert '' to timestamp
"dbconsole"."update_expr_data" at line 34
This has been fixed.
================(Build #1277 - Engineering Case #790264)================
The SQL Anywhere Profiler could have crashed immediately after applying a
filter if the "Operations" tab was selected. This issue was intermittent,
and depended on the position of the mouse on the screen at the time the filter
was applied. This problem has now been fixed.
================(Build #1276 - Engineering Case #790217)================
When starting the SQL Anywhere Profiler, a spurious error message could have
been reported saying that "You do not have 'SET ANY SYSTEM OPTION' system
privilege." This message could have been reported if the user didn't
have the SET ANY SYSTEM OPTION system privilege. Now, this error message
is not reported, even if the user does not have the system privilege.
================(Build #1252 - Engineering Case #788849)================
If the "Filter" field in the Profiler window had focus, and a large
number of operations had been collected, just moving the cursor (caret) in
the "Filter" field could have been unusually slow. This has been
fixed.
A number of other minor corrections have also been made to the "Filter"
field:
1. If the "Filter" field was empty, and you right-clicked, then
clicked "Paste", the text was incorrectly shown grey and
in
italics.
2. It was possible for the prompt text (e.g. "Filter") to remain
in the component after clicking in it.
3. Under Window's "Classic" desktop theme, the component looked
disabled, even when it wasn't.
4. The rollover effects for the button in the SearchField were
being shown only when the mouse button was down. Effects
should be shown while the mouse is over the button
regardless of the mouse button state.
5. When the MRU list was open, rolling the mouse over the list
should have selected the item under the mouse.
================(Build #1250 - Engineering Case #788767)================
The SQL Anywhere Profiler could have in rare situations crashed when trying
to opening a.SQLAP file, if that file could not be opened (because it was
on a network drive, say, and connection to the drive was subsequently lost.)
This has been fixed.
================(Build #1208 - Engineering Case #786878)================
Filter expressions in the SQL Anywhere Profiler allow for localized keywords.
The localized version of the "severity" keyword were not recognized
by the software. Now, it is. This bug prevented filtering and highlighting
from working correctly on non-English computers.
================(Build #1208 - Engineering Case #786874)================
Filter expressions in the SQL Anywhere Profiler allow for localized keywords.
The localized versions of "executionTime" and "blockedTime"
keywords were not recognized by the software. Now, they are. This bug prevented
filtering and highlighting from working correctly on non-English computers.
================(Build #1207 - Engineering Case #786805)================
The following issues in the SQL Anywhere Profiler related to filtering have
been fixed:
- On non-English computers that are configured to use 12-hour clocks, filtering
by time would always have resulted in no matching operations.
- Setting a time range in the "Server Load" panel did not work
on non-English computers.
- The "Add Filter Epression" window contains a combobox containing
names of users that have connected. Previously, if a given user had connected
more than once, the name would appear more than once in the combobox. Now,
names appear only once.
================(Build #1203 - Engineering Case #786683)================
The SQL Anywhere Profiler could have crashed when disconnecting from a database
when clicking the "Cancel" button in the status dialog that is
shown while the Profiler disconnects. This problem did not occur consistently.
This has been fixed.
================(Build #1202 - Engineering Case #786608)================
The following Index Consultant issues have been fixed in the SQL Anywhere
Profiler:
- If the workload contained too many statements to hold in memory at once,
the Workload Index Consultant could have crashed with an error message that
did not explicitly say that it had run out of memory. Now, a clear error
message is displayed, and the program does not crash.
- Statements with host variables were not being considered by the Index
Consultant. Now, they are.
================(Build #1201 - Engineering Case #788630)================
In SQL central, it was not possible to set the server’s quitting time on
the property sheet’s Options page if the timestamp_format option was set
to a non-default value (the default is YYYY-MM-DD HH:NN:SS.SSS). This has
been fixed. The property sheet now uses a free-form text field rather than
a masked text field. Also, the current time is now shown in the same format
as is required for setting the quitting time.
================(Build #1190 - Engineering Case #788633)================
In SQL Central, the Unload Database wizard could have crashed after unloading
the database. The crash was intermittent, and happened only rarely. It has
been fixed.
================(Build #1190 - Engineering Case #786123)================
When opening the SQL Anywhere Cockpit from SQL Central, if the Cockpit supported
both IPv4 and IPv6 addresses then an IPv6 address would have been used. Now
an IPv4 address is used.
================(Build #1187 - Engineering Case #785850)================
The connection cookie may not have expired for users in the SQL Anywhere
Cockpit. This has been corrected.
================(Build #1184 - Engineering Case #785748)================
The following issues surrounding the SQL Anywhere Profiler's reporting of
row locks have been corrected:
1 - When connected to a database, row locks were not consistently shown
on the "Blocking" tab's "Blocking Objects" panel.
2 - When row locks were shown on the "Blocking Objects"panel,
they appeared as "Table" locks
3 - When a table lock was shown in the top table of the "Blocking Objects"
panel, the details (lower) panel could have incorrectly contained row locks
for database tables other than the one selected in the upper table.
================(Build #1183 - Engineering Case #785694)================
In the SQL Anywhere Profiler, there is a "File/Clear" menu that
discards the profiling data collected so far. If the profiling session was
subsequently saved to a file, the file would have included profiling data
collected before clicking "File/Clear". This has been fixed so
that the data collected before clearing is no longer saved to the file.
================(Build #1182 - Engineering Case #785758)================
The SQL Anywhere Cockpit was vulnerable to clickjacking. This has been fixed.
================(Build #1177 - Engineering Case #785393)================
It was possible for the Profiler to list a non-existent statement on the
"Operations" tab when connected to a database. The statement did
not appear when the profiling session was saved to a file and the file then
opened. The SQL for the bogus statement was typically the word "TABLE".
This has been fixed.
================(Build #1177 - Engineering Case #785388)================
The SQL Anywhere Profiler's filter was inadvertently cleared after disconnecting
from a database. Now, the filter is not changed when disconnecting.
================(Build #1177 - Engineering Case #785385)================
The SQL Anywhere Profiler indicates intervals of expected reduced server
performance with a pale red background in the "Server Load" panel
and on the "Operations" tab. These intervals correspond to backups,
checkpoints, growing the cache, etc. The red background was being shown only
after the server operation completed. The Profiler should have (but did
not) shown it while the operation was executing. This has been fixed.
================(Build #1174 - Engineering Case #785194)================
The SQL Anywhere Profiler could have crashed if a filter was set, and a statement
in the profiled database blocked. This has been fixed.
================(Build #1163 - Engineering Case #788632)================
In the SQL Central Create Database wizard, when starting a new local server
to create the database, the server name would have defaulted to the database
file name. This could result in an invalid server name or a server name that
wasn’t recommended. For example, if the database file name contained characters
other than 7-bit ASCII. This has been fixed. Now if the database file name
isn’t a valid or recommended server name, then the wizard generates a random
server name.
================(Build #1163 - Engineering Case #788631)================
In SQL Central, if a breakpoint was deleted from the Breakpoints window
when the breakpoint's stored procedure was not selected, the breakpoint was
still shown when the procedure was subsequently selected. This has been
fixed.
================(Build #1465 - Engineering Case #796899)================
The Embedded SQL function sqlda_string_length would have returned inconsistent
results for some types in certain situations. If the column in a query was
described as DT_DATE, DT_TIME, DT_TIMESTAMP, DT_NSTRING, or DT_STRING, the
length reported by this function is correct before fill_sqlda is called,
but was incorrect after fill_sqlda was called.
The following example illustrates the use of sqlda_string_length:
for( col = 0; col < sqlda->sqld; col++ ) {
sqlda->sqlvar[col].sqllen = sqlda_string_length( sqlda, col ) - 1;
sqlda->sqlvar[col].sqltype = DT_STRING;
}
fill_sqlda( sqlda );
In the above example, if sqlda_string_length is called after the fill_sqlda
call, the lengths returned are 1 greater than before.
This problem has been fixed. The sqlda_string_length function will now
account for the fact that the fill_sqlda function (or any of its variants)
has been called.
================(Build #1465 - Engineering Case #796408)================
Execution of an Embedded SQL SET DESCRIPTOR statement would have failed to
copy the last two bytes of data from a host variable of type VARCHAR or BINARY
to the SQLDA variable data array.
For example, consider the following code fragment:
static DECL_VARCHAR(17) myvc;
.
.
.
myvc.len = 17;
memmove( (char *)myvc.array, "12345678901234567", 17 );
EXEC SQL ALLOCATE DESCRIPTOR sqlda1 WITH MAX 10;
EXEC SQL SET DESCRIPTOR sqlda1 COUNT = 1;
length = 17;
EXEC SQL SET DESCRIPTOR sqlda1 VALUE 1 TYPE = 448, LENGTH = :length;
fill_sqlda( sqlda1 );
EXEC SQL SET DESCRIPTOR sqlda1 VALUE 1 DATA = :myvc;
_check_condition( SQLCODE == 0
&& strncmp( (char *)myvc.array,
((VARCHAR *)(sqlda1->sqlvar[0].sqldata))->array, 17 )
== 0 );
free_filled_sqlda( sqlda1 );
The array field ((sqlda1->sqlvar[0].sqldata))->array ) would have
contained all but the last two characters of the myvc variable.
This problem has been fixed. With the new version of DBLIB, any Embedded
SQL applications that use DECL_VARCHAR and DECL_BINARY must be recompiled
using the Embedded SQL preprocessor (sqlpp).
The Embedded SQL GET DESCRIPTOR statement, which copies data from the SQLDA
to the host variable, does so correctly.
================(Build #1403 - Engineering Case #795135)================
If a connection string contained a START= parameter which included an -ec
or -xs option containing a path and filename with spaces, a parsing error
could have been given even if the value was enclosed in quotes.
For example: UID=…;PWD=…;DBF=mydatabase.db;START=dbeng17 -xs “https(identity=my
spacey file.id;identity_password=test)”
This has been fixed.
================(Build #1164 - Engineering Case #784668)================
Support has been added to Embedded SQL for wide deletes and updates. Two
new samples have been added to demonstrate wide operations in Embedded SQL.
The examples are found in the following folders:
samples\SQLAnywhere\ESQLWideDelete
samples\SQLAnywhere\ESQLWideInsert
================(Build #1467 - Engineering Case #797242)================
If the JDBC setMaxFieldSize was used to truncate the length of a binary column
transmitted from the database server to the client, a crash may have occurred
in the JDBC application. The JDBC setMaxFieldSize(int max) function sets
the limit for the maximum number of bytes that can be returned for character
and binary column values in a ResultSet object produced by this Statement
object. For example, if the binary column length is 300,000 and max is 256,
then a crash may have occurred in a getBytes call for that column. The following
is an example of a query that can produce binary column values with length
300,000.
select cast(repeat( '0123456789', 30000 ) as long binary) from sa_rowgenerator(1,4)
This problem also affected the Interactive SQL utilty (dbisql) when fetching
BINARY columns.
The problem has been fixed.
================(Build #1165 - Engineering Case #784055)================
A JDBC application could have found that fetching result sets with long varchar,
long nvarchar or long binary columns took much longer with a scrollable cursor
(i.e. an insensitive or sensitive statement) when compared to a non-scrollable
cursor (i.e. a forward only statement). This difference in performance was
most noticeable if most of the long values were smaller than 256K. The performance
issue has now been fixed and scrollable cursors now perform as well as non-scrollable
cursors.
================(Build #1451 - Engineering Case #796700)================
If a column that is longer than the SQL_ATTR_MAX_LENGTH value (default 256K)
was bound as SQL_C_BINARY and a multi-row fetch was performed, then the ODBC
driver would have crashed.
For example, if the column in the following query was bound as SQL_C_BINARY
and the row array size was 4, then the ODBC driver would have crashed when
attempting to fetch the rowset, provided that the SQL_ATTR_MAX_LENGTH value
was less than 300,000.
select cast(repeat( '0123456789', 30000 ) as long varchar) from sa_rowgenerator(1,4)
This problem has been fixed.
Note, this problem also affects the Interactive SQL utilty (dbisql) when
fetching BINARY columns.
================(Build #1434 - Engineering Case #796090)================
Using the SQL Anywhere ODBC driver, calling SQLGetTypeInfo() would have returned
the following information in the result set when connected to an SAP IQ database
server:
TYPE_NAME=table DATA_TYPE=SQL_VARCHAR COLUMN_SIZE=32767 LP= LS= CREATE_PARAMS=
NULLABLE=1 TYPE_ORDINAL=1
The "table" type is not a suitable SQL_VARCHAR data type declarative
and is not equivalent to the "char" data type. This row should
not appear in the result set.
Using the SQL Anywhere JDBC driver, the DatabaseMetaData.getTypeInfo() call
will also include "table" in the result set when connected to an
SAP IQ database server.
These problems have been fixed.
================(Build #1422 - Engineering Case #795701)================
If the high-order byte in the val field of a SQL_NUMERIC_STRUCT was non-zero,
then the SQL Anywhere ODBC driver may not have converted the numeric value
correctly before sending it to the database server. The column value must
be bound as a SQL_NUMERIC type and be sufficiently large enough in order
for this to have occurred. For example, the representation of 31415926535897932384626433832795028.8419
in a SQL_NUMERIC_STRUCT is such that the high-order byte of the val field
is 0xec. An incorrect value would would have been stored in the table column.
This problem has now been fixed.
================(Build #1304 - Engineering Case #791481)================
When using the SQL Anywhere ODBC driver, the character size, display size,
and octet length information returned by the ODBC functions SQLDescribeCol
and SQLColAttribute were wrong for CHAR(x CHAR) or VARCHAR(x CHAR) columns
when connected to a multi-byte character set (MBCS) database using the “wide”
interface API (UNICODE mode).
Given a table with the following columns.
c_nchar nchar(42),
c_charchar char(42 char),
c_char char(126)
The c_charchar column will hold at most 42 national characters. For example,
a 932JPN database column holds 42 Japanese double-byte characters which requires
at most 84 bytes of memory to store. A UTF-8 database column holds 42 Japanese
double-byte characters which requires at most 168 bytes of memory to store
(4*42=168 is the worst-case scenario for UTF-8 surrogate code points).
For the c_charchar column, character size and display size should be 42.
Character size is the number of characters, not the number of bytes.
For the c_charchar column, the octet length is the maximum number of bytes
required to store these characters in memory on the client (e.g., number
of characters * 2 for double-byte, number of characters * 4 for UTF-8).
For a DBCS database like 932JPN, the ODBC driver reported 84 for the character
size, 84 for the display size, and 84 for the octet length. The character
size and display size were incorrect. There was no problem when the ODBC
application was compiled for and run in ANSI mode (for example, when using
SQLDriverConnectA rather than SQLDriverConnectW).
This problem has now been fixed. For each of the columns noted above, the
following is now reported.
Column 1:
SQLDescribeCol: column name = c_nchar
SQLDescribeCol: data type = SQL_WCHAR
SQLDescribeCol: character size = 42
SQLColAttribute(SQL_DESC_DISPLAY_SIZE): character size = 42
SQLColAttribute(SQL_DESC_LENGTH): character size = 42
SQLColAttribute(SQL_DESC_OCTET_LENGTH): byte size = 168
Column 2:
SQLDescribeCol: column name = c_charchar
SQLDescribeCol: data type = SQL_CHAR
SQLDescribeCol: character size = 42
SQLColAttribute(SQL_DESC_DISPLAY_SIZE): character size = 42
SQLColAttribute(SQL_DESC_LENGTH): character size = 42
SQLColAttribute(SQL_DESC_OCTET_LENGTH): byte size = 84
Column 3:
SQLDescribeCol: column name = c_char
SQLDescribeCol: data type = SQL_CHAR
SQLDescribeCol: character size = 126
SQLColAttribute(SQL_DESC_DISPLAY_SIZE): character size = 126
SQLColAttribute(SQL_DESC_LENGTH): character size = 126
SQLColAttribute(SQL_DESC_OCTET_LENGTH): byte size = 126
================(Build #1287 - Engineering Case #790651)================
When using the version 12 or 16 ODBC driver, any query that began with the
prefix “insert" was incorrectly categorized as an INSERT statement.
Beginning version 17, any query that began with the prefix “insert",
“update", “delete", or “merge" was incorrectly categorized
as an INSERT, UPDATE, DELETE, or MERGE statement. This problem has been fixed.
Note that the comparison was case-insensitive (insert, Insert, INSERT, etc.
all match).
For example, if the query “updateInventory( 100 )”s executed, the ODBC driver
would have assumed this was an UPDATE statement.
================(Build #1238 - Engineering Case #787903)================
If the StartLine (START) connection parameter contained the string “-n” anywhere
in the text, it is interpreted as if the -n option was specified. This could
have affected the final server name that was chosen.
For example:
dbisql -c "UID=DBA;PWD=sql;START=dbeng16.exe -z -o c:\y-n\output.log;Server=SRV1;
DBN=DBN1;DBF=demo.db"
This problem has been corrected.
================(Build #1232 - Engineering Case #788053)================
If a User Data Source Name (DSN) was created with the same name as a System
Data Source Name, the original System Data Source could not have been examined
or modified using the ODBC Configuration for SQL Anywhere window of the Windows
ODBC Data Source Administrator.
Furthermore, an attempt to modify the System DSN would have always resulted
in a modified version of the User DSN being written over the System DSN.
This problem has been fixed.
As a work-around, the dbdsn/iqdsn tool can be used to create/modify user
and system data sources.
================(Build #1451 - Engineering Case #796698)================
When CSRF tokens were enabled, modify requests that failed due to CSRF issues
(expired, invalid, no cookie or missing) would not have included the HTTP
response header "X-CSRF-Token: required". This has been fixed.
================(Build #1451 - Engineering Case #796644)================
Any update requests (bind) of a principal entity which modified a navigational
property (from principal role) to a dependent entity would have ignored the
changes to that navigational property. Navigational properties that modified
from dependent role to a different principal entity where not ignored. This
has been fixed.
================(Build #1451 - Engineering Case #796643)================
Attempting to do an insert or update of an entity with a link where one of
the ends had multiplicity 0..1 could be rejected as a constraint violation.
This happened when the entity being linked to was already linked to by another
entity. The existing link must be removed to preserve the multiplicity.
This has been fixed. If the principle multiplicity is 0..1 or 1, the dependent
multiplicity is 0..1, and the dependent end is nullable, the OData Producer
will now remove the existing link.
================(Build #1428 - Engineering Case #795921)================
If a new user made many parallel requests and the metadata has not been built
for that user, the OData Producer will attempt to build the same metadata
in parallel but only keep one copy.
This has been fixed.
================(Build #1402 - Engineering Case #795072)================
Attempting to do a POST or PUT to modify a link using $links, where one of
the ends had multiplicity 0..1, could have been rejected with an invalid
cardinality error. This would have happened when the entity was already linked
to another entity and had to be detached in order to be attached to the new
one. This has been fixed. If the principle multiplicity is 0..1 or 1, the
dependent multiplicity is 0..1, and the dependent end is nullable, the OData
Producer will now remove the existing link.
================(Build #1386 - Engineering Case #794408)================
If a modification request was made to the OData Producer using the repeatable
requests feature, the response to the request could have been flushed back
to the client before the database connection was committed. If there was
an error during the commit this would have resulted in the client getting
incorrect data. This has been fixed.
================(Build #1341 - Engineering Case #792765)================
The OData Producer's processing of the GET request header “X-CSRF-Token:
FETCH” was not case insensitive. Although the documentation uses “FETCH”,
the producer looks for “Fetch”. This has been fixed, “FETCH” is now case
insensitive.
================(Build #1341 - Engineering Case #792761)================
A user’s first request could have been very slow and if there were many users
with different access permissions, users would have encountered occasional
slow requests.
On first request, the OData Producer must build the metadata for that user,
which it then caches. If there are many users with different permissions,
the cache may unload metadata for a particular user. In this case when that
user makes a subsequent request, their metadata must be rebuilt.
This has been fixed. The database query for retrieving the metadata has
been improved.
================(Build #1257 - Engineering Case #789270)================
The value of the Location HTTP header in responses to POST requests was not
properly encoded so that it could be used directly as an URL. This has now
been fixed.
================(Build #1196 - Engineering Case #786419)================
The OData Producer may have ignored a directive to accept a media type if
it had a quality score of 0. Example: "*/*;q=0". If no other suitable
media type was acceptable, the request would have failed with UNACCEPTABLE
response. This has been fixed.
================(Build #1196 - Engineering Case #786369)================
The OData Producer would have ignored HTTP ACCEPT headers when formatting
error responses. This has been fixed. If a request accepts JSON responses
instead of XML, the error will now be returned in JSON.
================(Build #1196 - Engineering Case #783811)================
Service Operations whose underlying database stored procedures containd SQL
keywords as names of the result set columns would not have been useable with
the option ServiceOperationColumnNames=database. Requests for such service
operations would have resulted in HTTP 500 - Internal Server Error. This
has been fixed.
================(Build #1196 - Engineering Case #782946)================
The OData Producer would have generated generic 'HTTP 500 Internal Server
Error' errors when there were issues with the data source (the database)
being unavailable (for example the database server was not running). Administrators
would then have needed to look up diagnostic dump files to view the actual
error. This has been fixed. For common database connection errors due to
the server being unavailable, the producer now returns an HTTP 500 error
with appropriate error message (and does not generate a diagnostic file).
The HTTP status code for some connection errors has been changed to 'HTTP
500 Internal Server Erro'r instead of 'HTTP 400 Bad Request'.
================(Build #1432 - Engineering Case #795979)================
When using the SQL Anywhere OLE DB provider, attempting to move forward more
than one record using the Recordset.Move function would have failed if the
cursor type was a forward-only no-scroll cursor. This problem has been fixed.
================(Build #1362 - Engineering Case #793846)================
When using a SQL Anywhere OLE DB Linked Server object from Microsoft SQL
Server, a COMMIT or ROLLBACK of a distributed transaction would have failed.
For example, when attempting to update a row in the Contacts table of the
SQL Anywhere demonstration database using Microsoft SQL Server:
begin tran t2;
update SQLATest.demo.groupo.contacts set surname = surname + t.val
from (select 2 i, '???' val) t where id = t.i;
commit tran t2;
select surname from SQLATest.demo.groupo.contacts where id <= 4;
error messages, including one indicating that the OLE DB provider “reported
an error committing the current transaction”, were displayed. This problem
has now been fixed.
Also fixed are nested transactions using ADO and native SQL Anywhere OLE
DB. Microsoft SQL Server does not support nested distributed transactions.
Note, transactions using Linked Servers are always distributed transactions.
================(Build #1359 - Engineering Case #794768)================
When data was cryptographically hashed using SHA-1 or SHA-256, a small amount
of memory was leaked. This could have occurred when a connection was made
to the database server (hashing the password), when the HASH function was
used. , or in a number of other possible cases in the server.
This also applied to MobiLink server. The leak could have occurred on each
synchronization where MobiLink’s built-in authentication was used, including
if an LDAP authentication failed over to built-in authentication.
This leak has now been fixed.
================(Build #1359 - Engineering Case #794337)================
Repeatedly calling the various new PKI routines to generate key pairs, verify
or sign messages, or encrypt or decrypt data using RSA, would have caused
the database and MobiLink servers to leak memory. This problem has been fixed.
================(Build #1320 - Engineering Case #792036)================
The SQL Anywhere Cockpit no longer includes connections made by the Cockpit
itself in counts of connections to the server and in lists of connections.
Cockpit connections are also excluded from calculations used to determine
when alerts are raised. Specifically, Cockpit connections are excluded in
the following places:
- The “total connections” tile which is shown on the Home and Connection
worksets and on the property sheet for several alert types.
- The list of connections on the connections workset. This list always
excluded Cockpit connections.
- The list of “CPU Intensive Connections” on the property sheet for the
“CPU Usage is high” alert.
- The count of connections on the Overview page of the Database property
sheet.
- The list of “Long running requests” on the property sheet for the “Long
running operation” alert.
- The “Temporary File Usage” by connection list on the property sheet for
the “High temporary file usage” alert.
- The “Connections with Locked Heaps” list on the property sheet for the
“Cache panic” alert.
- Calculation of alert conditions for the following alert types: “long
running operations”, “connection blocking” and “number of connections”
================(Build #1263 - Engineering Case #789607)================
In rare circumstances, the SQL Anywhere installer on Unix could have crashed
during an upgrade. This has been fixed.
A work around is to uninstall the old SQL Anywhere software and perform
a new installation of the new software.
================(Build #1243 - Engineering Case #773002)================
Generated 64-bit MSI installs had the BIN32 directory in the PATH environment
before the BIN64 directory. Also, the path contained an extra backslash between
the SQL Anywhere directory and the BIN32 or BIN64 directories. Both these
problems have now been corrected.
================(Build #1064 - Engineering Case #786881)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1p.
================(Build #1063 - Engineering Case #785926)================
On Mac OS X systems, failing to allocate memory could have caused the process
to crash. This applied to all processes within the SQL Anywhere product,
and has now been fixed.
================(Build #1063 - Engineering Case #785089)================
The library dbrsa16.dll was missing in the client install for SQL Anywhere
for Windows. The client install has now been modified to include this file.
================(Build #2038 - Engineering Case #797805)================
The server could have deadlocked or hung if a dbspace was being extended
at the same time as a user-defined event was being loaded or reloaded. This
problem has been fixed.
================(Build #2023 - Engineering Case #784718)================
In very rare cases, in a parallel work load that performs rollbacks that
target a unique index, a server may have failed assertion 200112 - "Failed
to undo index delete". This has been fixed. Note, a database upgrade
is required to implement this fix.
================(Build #2021 - Engineering Case #797239)================
In very rare circumstances, requesting the stack_trace via sa_stack_trace()
of another connection could have caused the server to crash. This has been
fixed.
================(Build #2019 - Engineering Case #797233)================
A query containing a GROUPING function in the HAVING clause, that did not
appear elsewhere in the query, could have incorrectly returned a syntax error.
This has been fixed.
Note, a workaround is to include the expression containing the GROUPING
function in the select list.
================(Build #2019 - Engineering Case #797161)================
If the database server was shut down while hosting HTTP or HTTPS connections,
it could have crashed. This was more likely with the personal server than
the network server. This has been fixed.
================(Build #2000 - Engineering Case #797290)================
If the “quoted_identifier” option was set to ‘off’, upgrading the database
using the Database Upgrade utility (dbupgrad) or the “alter database upgrade”
statement would have failed with a syntax error. This has been fixed.
================(Build #2000 - Engineering Case #797289)================
If the list of CC or BCC recipients supplied to xp_sendmail was created in
SQL using string functions or concatenation, it was possible for the recipient
lists to be ignored. This has been fixed.
================(Build #2000 - Engineering Case #797285)================
Some error messages would have contained ‘???’ when raised. This has been
corrected.
Some occurrences of COLUMN_NOT_FOUND have been modified to contain additional
information and will now give COLUMN_NOT_FOUND_IN_TABLE.
Calling sp_read_db_pages() could have raised FEATURE_REQUIRES_UPGRADE. This
has been corrected to now raise READ_DB_PAGES_CACHE_TOO_SMALL.
================(Build #2000 - Engineering Case #796892)================
Under very rare circumstances, the server could have crashed when using the
Cockpit. This has been fixed.
================(Build #2000 - Engineering Case #790498)================
On 64-bit systems, preparing or executing a statement in the Javascript external
environment may have given an error, or caused the node executable to crash.
This has been fixed
================(Build #2000 - Engineering Case #785052)================
The Interactive SQL utility and SQL Central allow editing table data without
writing an explicit INSERT, UPDATE, or DELETE statement. Manipulating a row
which contained an NCHAR/NVARCHAR/LONGNVARCHAR column could have failed if
its value contained characters which could not be represented in the database's
CHAR character set. This has been fixed.
Here's specifically what didn't work:
- When adding a row, foreign characters in NCHAR columns could be converted
to escape characters (0x1A).
- If an NCHAR column was part of a table's primary key, the row could not
be deleted if the column's value contained foreign characters.
- When updating a row with foreign characters in an NCHAR column, a message
saying that the row had been updated was returned, but could not be refreshed.
================(Build #2000 - Engineering Case #783537)================
In specific conditions where “internal use only” features were used, it was
possible that parallel execution plans were not considered when they should
have been. This lead to execution plans that did not use parallelism. This
has been fixed.
================(Build #1700 - Engineering Case #791283)================
Under rare circumstance, the server could have crashed when executing a statement
involving a stored procedure or user defined function defined with SQL SECURITY
INVOKER. This has been fixed.
================(Build #1493 - Engineering Case #798668)================
In some cases, creating a circular string could have resulted in the server
entering an endless loop. This has been corrected.
================(Build #1481 - Engineering Case #798158)================
Calling the system procedure sa_refresh_text_index(), in the presence of
text indexes with names that could only be used as quoted identifiers, could
have caused an error to be returned. This has been fixed.
Note, this issue could be observed during dbunload –g if text index names
contained multibyte characters. A workaround is to manually refresh the text
indexes.
================(Build #1479 - Engineering Case #798114)================
Spatial methods that generate SVG use a viewBox element whose size is computed
from the input geometry’s bounding box plus a small fixed constant. Some
browsers (notably Microsoft IE) have problems scaling SVG elements with small
viewBoxes and so may not have rendered the generated SVG correctly. This
change adds two new format parameter names, “MinViewBoxWidth” and “MinViewBoxHeight”,
to the format parameters accepted by SVG-generating methods (ST_AsSVG, ST_AsSVGAggr,
ST_AsXML, ST_AsText). These parameters permit specifying numeric values
for the minimum viewBox width and height. If left unspecified, the minimum
viewBox width and height defaulted to 0.0002, which was the previous behaviour
before this change.
For example, the expression “new ST_Point(0,0).ST_AsSVG(‘MinViewBoxWidth=0.3;MinViewBoxHeight=0.2’)”
generates SVG in which the viewBox enclosing the point has width 0.3 and
height 0.2.
================(Build #1477 - Engineering Case #797911)================
The server would have given a 'Table not found' error if an application attempted
to create a HANA proxy table and the actual HANA table had a mixed case owner,
schema or table name. This problem has now been fixed.
Note that with this change the application must now ensure that the proper
case is used when specifying owner, schema and table name in the AT clause
of the CREATE EXISTING TABLE statement.
================(Build #1477 - Engineering Case #797907)================
In rare cases, attempting to call the system procedure sp_objectpermission()
could have led to a server hang. This problem has been fixed.
================(Build #1477 - Engineering Case #797902)================
When processing a statement that returned many rows with a very low per-row
cost, it was possible for the total time to be higher than it should have
been. This has been fixed.
Measured slowdown was about 250 nanoseconds per row returned to the client.
================(Build #1474 - Engineering Case #797752)================
Inserting a round-Earth geometry could have failed with "Error parsing
geometry internal serialization” (SQLCODE –1415). This has been fixed.
================(Build #1473 - Engineering Case #797716)================
A busy server that had statement profiling enabled, might have crashed while
logging the plans or the text of expensive queries. This has been fixed.
Note, this problem only affected Windows and Linux systems.
================(Build #1470 - Engineering Case #797560)================
If a computer running the database server had at least 128 CPUs, connections
may have reported incorrect statistics. This has been fixed.
================(Build #1470 - Engineering Case #797545)================
Under very rare circumstances, the server may have returned an incorrect
result set or a syntax error for queries with a PIVOT clause. This has been
fixed
================(Build #1466 - Engineering Case #797401)================
Under rare circumstances, the database server could have crashed while updating
the column statistics at the end of a DML statement. This has been fixed.
================(Build #1466 - Engineering Case #797365)================
When attempting to use the Upgrade Database wizard to change a database's
security model from definer to invoker, the security model would have remained
unchanged. This has been fixed.
================(Build #1466 - Engineering Case #782470)================
Under very rare circumstances, it may have taken a long time to cancel a
complex query during optimization. This has been fixed
================(Build #1462 - Engineering Case #797145)================
Under very rare circumstances, the server would have crashed if the GROUP
BY clause of a query contained outer references. This has been fixed
================(Build #1459 - Engineering Case #797001)================
The ROW constructor did not verify the uniqueness of the specified field
names. This has been fixed
================(Build #1457 - Engineering Case #796847)================
The SELECT INTO statement was incorrectly creating a table with FLOAT columns
for DOUBLE columns of the select's result set. This has been fixed
================(Build #1457 - Engineering Case #796705)================
An authenticated server may have given authentication errors to connections,
even though the authentication string was a valid string provided by SAP.
This has been fixed.
================(Build #1452 - Engineering Case #796738)================
The server may have returned an incorrect result set if a query had an inner
query block with a GROUP BY CUBE or ROLLUP and an outer query block had predicates
in the WHERE clause. This has been fixed.
================(Build #1449 - Engineering Case #796579)================
It was possible for the server to crash when sp_parse_json was executed using
input that contained mismatched data types, where one type was a null and
the other type was an object or an array. For example, the following would
have crashed the server: [ {a: null}, {a: {b:1} } ]. This has now been fixed.
A workaround is to ensure that all objects within an array have exactly
the same data type. In the previous example, it could be fixed by changing
the input to: [ {a: {b:null} }, {a: {b:1} } ].
================(Build #1444 - Engineering Case #791217)================
When connected to a version 17 server, attempting to restore archive backups
created with versions 16 or older would have returned the error “Backup file
format is invalid”. This has been fixed.
================(Build #1440 - Engineering Case #796262)================
On Unix systems, if a server was started with the –ud option, and that server
attempted to start a database file that was already running on another server
(with a different name), the new server may have crashed on shutdown. The
reported error message also did not correctly indicate that the database
file was in use. This has been fixed.
================(Build #1435 - Engineering Case #796139)================
Under very rare circumstances, the SQL Anywhere server could have crashed
when executing a complex query with large number of threads executing in
parallel. This problem has now been fixed.
================(Build #1434 - Engineering Case #796085)================
When calling xp_startsmtp with a trusted_certificate file, and specifying
just the filename (instead of “file=<filename>”), would have cause
xp_startsmtp to return error code 1. This has been fixed.
================(Build #1434 - Engineering Case #796081)================
On systems running Microsoft Windows, the server may have crashed on startup
when attempting to obtain disk drive parameters if the disk driver did not
properly implement the IOCTL_STORAGE_QUERY_PROPERTY correctly. When successful,
the information returned by this system call can be seen using the following
SQL query.
SELECT DB_EXTENDED_PROPERTY( 'DriveModel' );
This problem has been fixed. If the disk drive parameters cannot be determined,
the drive model will now be “Unknown”.
================(Build #1428 - Engineering Case #795922)================
If a web procedure URI began with “https_fips://” indicating that HTTPS should
be used with the FIPS-certified libraries, calling the procedure would result
in SQLCODE -980, “The URI ‘<uri>’ is invalid”. This has been fixed.
================(Build #1428 - Engineering Case #795917)================
Certain assertion numbers could have been raised in more than one situation.
This has been fixed so that assertion numbers are now unique.
================(Build #1426 - Engineering Case #795751)================
In very rare cases, cancelling a statement that processed an XML document
could have taken a long time. This has been fixed.
================(Build #1424 - Engineering Case #795599)================
Under very rare circumstances, the server may have crashed during a database
cleaner run if there had been tables dropped and views created shortly before.
This has been fixed.
================(Build #1421 - Engineering Case #795609)================
The SQL functions NUMBER(*) and RAND() may have returned duplicate values
if they were executed below an Exchange query plan node of a parallel query
execution. This has been fixed.
================(Build #1418 - Engineering Case #795546)================
If a server was using the -zoc switch to log web procedure calls, and a web
procedure that used chunked encoding was called, the server could have crashed.
This has been fixed.
================(Build #1418 - Engineering Case #794511)================
Under very rare circumstances, the server may have crashed while receiving
host variables from a TDS based connection if the receiving TDS token stream
violated the TDS protocol definition. This has been fixed. The server will
now return a SQLSTATE_COMMUNICATIONS_ERROR error in this situation.
================(Build #1410 - Engineering Case #795349)================
If a database was created or upgraded with a version 10, 11, or 12 server,
but not upgraded any further, and contained a table or view called 'SYSROLEGRANTS',
an attempt to upgrade that database to version 17 would have failed. This
has been fixed.
================(Build #1410 - Engineering Case #795335)================
In very rare cases, the server could have crashed while closing a connection
that made external environment calls to a connection scoped external environment.
The problem would show up if the external environment had open cursors at
the time the connection was closed. The problem has now been fixed
================(Build #1405 - Engineering Case #795198)================
When using a JSON data structure containing empty arrays (represented in
a string as ‘[]) as input to the sp_parse_json procedure, it was possible
for the server to crash. This has been fixed.
================(Build #1401 - Engineering Case #795027)================
In rare cases, using the new PKI routines to verify or sign messages, or
encrypt or decrypt data using RSA, could have caused the server to crash.
This problem has been fixed.
================(Build #1393 - Engineering Case #794728)================
If the wrong identity file password was supplied to the database server,
the error message displayed by the server would have been similar to “Error
parsing certificate file, error code=0x06065064”. This has been fixed.
================(Build #1393 - Engineering Case #794593)================
Incorrect results could have been returned if SQL SECURITY INVOKER user defined
function was invoked multiple times in a single statement, with at least
two calls being made by different users. For example, the issue would have
occurred if the same UDF was invoked from a view referenced in a query, and
in the SELECT list of the query directly. This has been fixed.
================(Build #1387 - Engineering Case #794531)================
When creating a foreign key with an ON DELETE SET DEFAULT or ON UPDATE SET
DEFAULT action on a column with no default value, the error message returned
by the server would have failed to reference the table name: “Constraint
'<column>' violated: Invalid value for column '<table>’ in table
'???'”. This has been fixed so that the table name is now referenced.
================(Build #1384 - Engineering Case #794343)================
The server could have crashed executing a spatial query in a low memory situation.
This has been fixed.
================(Build #1364 - Engineering Case #793880)================
In rare case, cached plans for client statements that used host variables
of type TIMESTAMP_STRUCT within expressions could potentially have returned
an incorrect result. This has been fixed. A workaround is to disable plan
caching by setting option max_plans_cached=0.
================(Build #1361 - Engineering Case #793824)================
Under very rare circumstances, the server may have crash when using a RANK
aggregate function. This has been fixed.
================(Build #1359 - Engineering Case #794878)================
The dbmanageetd tool can be used to read and write .etd files. When used
to write files in ETD format, some trace event records were written improperly,
generating files which could not be read. This has been fixed.
================(Build #1358 - Engineering Case #793740)================
Under extremely rare circumstances, the server could have crashed or hung
when creating an event. This has been fixed.
================(Build #1358 - Engineering Case #793674)================
When processing a statement that contained a subselect expression where the
select-list item used a LIST or COUNT aggregate, it was possible for the
statement to fail assertion 106901 - "Expression value unexpectedly
NULL in write". This has now been fixed.
================(Build #1356 - Engineering Case #793457)================
When the time_zone option was set, the value of the @@dbts global variable
was returned in the computer’s time zone, not that of the database. This
has been fixed.
================(Build #1353 - Engineering Case #793370)================
The version of OpenLDAP used by the SQL Anywhere server and client libraries
has been upgraded to 2.4.43.
================(Build #1352 - Engineering Case #792816)================
The server may have failed the non-fatal assertion 102604 - "Error building
sub-select" if a query contained a distinct that could have been eliminated,
the query cursor was not declared with read-only, and there was a publication
with an subselect in the Subscribe-by
clause. This has been fixed.
================(Build #1346 - Engineering Case #792898)================
The server may have crashed or failed assertion 109512 - "Freeing already-freed
memory" during a DROP ROLE or DROP USER statement if there were multiple
extended grants (e.g. SET USER and CHANGE PASSWORD). This has been fixed.
Note, a workaround is to revoke extended grants before dropping a Role or
User.
================(Build #1346 - Engineering Case #792313)================
The server can perform a fast TRUNCATE TABLE if the table is referenced by
foreign key tables and all the foreign key tables are empty. Under some circumstances
a fast truncate was not being executed. This has been fixed.
================(Build #1345 - Engineering Case #793009)================
In some combinations of logs and a backed up database, the server did not
realize that the database did not need recovery and failed to start the database.
A “Log not found” error was thrown instead. This has been fixed.
================(Build #1345 - Engineering Case #792925)================
If an execution plan executed a subquery (a subselect expression, EXISTS,
or ANY/ALL) many times, and the subquery was very cheap, then the overall
execution time of the query was higher than it could have been. This has
been fixed.
================(Build #1340 - Engineering Case #792440)================
The value of a database variable was being cached too eagerly in simple cached
DML statements. This has been fixed.
Note, that in order to observe the issue, the database variable had to have
changed frequently.
================(Build #1339 - Engineering Case #792644)================
Providing a min_ticks parameter to the system function sp_property_history()
may have incorrectly caused no rows to be returned when the server was running
on Windows systems.
For example:
SELECT MAX( ticks ) INTO @tv FROM sp_property_history ( 'ActiveReq' );
-- wait a few seconds
SELECT * FROM sp_property_history ( 'ActiveReq', @tv );
-- no rows
SELECT * FROM sp_property_history ( 'ActiveReq', NULL ) WHERE ticks >=
@tv;
name,ticks,time_recorded,time_delta,value,value_delta
'ActiveReq',30460700,'2015-11-22 16:55:26.028-05:00',990,0.0,0.0
'ActiveReq',30461700,'2015-11-22 16:55:27.028-05:00',1000,0.0,0.0
'ActiveReq',30462700,'2015-11-22 16:55:28.028-05:00',1000,0.0,0.0
'ActiveReq',30463710,'2015-11-22 16:55:29.038-05:00',1010,0.0,0.0
...
This has been fixed. As a temporary workaround, divide ticks by 10 on Windows:
SELECT * FROM sp_property_history ( 'ActiveReq', @tv/10.0 );
================(Build #1334 - Engineering Case #792549)================
Under rare circumstances, the server could have crashed when getting the
procedure stack trace. This has been fixed.
================(Build #1334 - Engineering Case #792498)================
Under very rare circumstances, the server may have failed assertion 104904:
"latch count not 0 at end of request", or others, after executing
a REORGANIZE TABLE statement with PRIMARY KEY, FOREIGN KEY or INDEX clause,
or after shrinking an index. This has now been fixed.
================(Build #1334 - Engineering Case #792266)================
The UPDATE statement [SQL Remote] is executed by the Message Agent of SQL
Remote to determine existing and new recipients of the rows in a table:
UPDATE table-name
PUBLICATION publication-name
{ SUBSCRIBE BY subscription-expression |
OLD SUBSCRIBE BY old-subscription-expression
NEW SUBSCRIBE BY new-subscription-expression }
WHERE search-condition
expression : value | subquery
The statement does not modify any of the rows in the database, but puts
records in the transaction log to indicate movement of rows from or to a
recipient.
Since this type of UPDATE statement does not modify any rows, it should
not execute any BEFORE or AFTER triggers. Before this change it improperly
called BEFORE UPDATE triggers on the target table, leading to wasted work
in some cases. This has been fixed, BEFORE UPDATE triggers are no long called
for this type of statement.
================(Build #1333 - Engineering Case #792271)================
Server may have crashed if a user interrupted starting the SQL Anywhere Cockpit.
This has been fixed.
================(Build #1328 - Engineering Case #792263)================
In some situations, creating an index on a very large table could have caused
the server to appear to be hung. This condition did go away once the index
was created. The is now been fixed.
================(Build #1328 - Engineering Case #792227)================
Some valid round-earth geometries could have failed to input properly, either
giving an error, failing an assertion, or causing a server crash. This has
been fixed.
================(Build #1327 - Engineering Case #792221)================
If the server encounters a fatal database error it then writes a minidump
file. During this process the server may have overwritten this minidump file,
or created another minidump file due to a crash when freeing static data.
This has been fixed.
================(Build #1325 - Engineering Case #791615)================
Temporary file names for the server and various utilites were generated using
a standard library function that may have produced somewhat predictable file
names. These predictable temporary file names could have been exploited in
various ways. Collisions between processes or threads were also possible
and could have resulted in undesirable behaviour. This has been fixed.
A workaround that mitigates most of the issues is to set SATMP to a location
that is only writable by the engine and other trusted users.
================(Build #1320 - Engineering Case #792037)================
In very rare cases, the server could have crashed dereferencing a bad pointer
or connections could have failed to unblock. This has been fixed.
================(Build #1318 - Engineering Case #791896)================
In very rare cases the server may have failed assertion 201501: “Page X:Y
for requested record not a table page”. This has been fixed.
================(Build #1313 - Engineering Case #791754)================
In very rare timing dependent cases, recording event tracing could have resulted
in the server crashing. This has now been fixed.
================(Build #1310 - Engineering Case #791667)================
The function ST_PointOnSurfac()e requires an ST_Polygon or ST_MultiSurface
as input. Similarly, the function ST_IsRing() requires an ST_LineString as
input. Using these functions on valid geometry types may have resulted in
an error indicating that the geometry type was incorrect. This has been fixed.
================(Build #1310 - Engineering Case #791665)================
When creating a LineString with a round-earth SRS, points that were 180 degrees
longitude apart were rejected as being nearly antipodal, even if they were
physically close together. For example, the following geometry would have
failed to load, even though it is a relatively short line: LineString (-180
-84, 0 -90). This has been fixed.
================(Build #1310 - Engineering Case #790722)================
Under very rare circumstances, the server may have crashed or failed an assertion
"Assertion failed: 109512 Freeing already-freed memory". This has
been fixed.
To work around the problem, plan caching can be turned off (option Max_plans_cached
= 0).
================(Build #1308 - Engineering Case #791554)================
Zero-length LineStrings were not handled properly by the set operations,
ST_IsSimple, and ST_Buffer. Passing such a LineString to ST_Buffer may have
caused the server to fail an assertion. This has been fixed.
ST_IsSimple now returns TRUE if there are only two points in the LineString.
LineStrings containing more than two points that are also zero-length are
not considered to be ST_IsSimple.
Set operations now treat the zero-length LineString as a single point.
Zero-length segments within a given LineString whose overall length is non-zero
are ignored.
================(Build #1304 - Engineering Case #791165)================
In some situations, when a table had hundreds of Foreign Key constraints
defined an insert in that table may have caused a server crash. Behavior
has now been changed to throw an error instead.
================(Build #1297 - Engineering Case #788462)================
The server may have incorrectly returned the error "Function or column
reference to 'rowid' must also appear in a GROUP BY", when a select
with aggregation had a correlated subquery in its select list and the subquery
contains an outer join that returned constants from the null-supplying side.
For example:
select ( select sum(T2.b2)
from T2 left outer join ( select 1 as x from T3 )
V3 on 1=1
where T1.a1 = T2.a2
) as Z,
count(*)
from T1
group by T1.a1
This query below has a main query block with GROUP BY T1.a1, a subquery
with alias Z, and an outer reference to the subquery using T1.a1. The null-supplying
side of the outer join V3 returns a constant "1 as x".
This has been fixed.
================(Build #1296 - Engineering Case #780893)================
Under rare circumstances, the server may have returned the error "Invalid
use of an aggregate function" when a query contained a proxy table and
an aliased flattenable subquery with grouping in the select list of a query
block. For example: The below query has a subquery with an alias name "s1"
and would have returned the above error:
select *
from ( select ( select sum(V1.a1) x from T1 V1 ) as s1
from T1 V2
) V0,
T2_proxy
This has now been fixed.
================(Build #1288 - Engineering Case #790670)================
Accessing a proxy table mapped to a remote Oracle table which had special
characters in its name (such as ‘/’, ‘$’, ...) was reporting syntax errors
such as ORA-0903 and ORA-0933. The problem was due to the table identifiers
not being delimited properly, which has now been fixed.
================(Build #1286 - Engineering Case #790600)================
In some cases, UPDATE statements that included SET <variable> = <expression>
could have failed to evaluate the expression for the variable, setting it
to NULL instead. This has been fixed.
A workaround is to issue a separate query before issuing the update. For
example,
UPDATE T SET @var = T.x, T.y = 4 WHERE T.z=1
becomes
SELECT T.x INTO @var WHERE T.z=1;
UPDATE T SET T.y = 4 WHERE T.z = 1;
================(Build #1286 - Engineering Case #790589)================
In very rare situations, a server could have crashed if an application that
made a connection-scoped external environment call closed the connection
while the server machine was under heavy load. This problem has now been
fixed.
================(Build #1275 - Engineering Case #790149)================
In extremely rare circumstances, it was possible for the server to crash
during shared memory communication. This has been fixed.
================(Build #1271 - Engineering Case #789369)================
Simple-encrypted version 10 databases would have failed to start on a version
17 server. This has been fixed.
================(Build #1268 - Engineering Case #789852)================
If a server was running on a Unix system with multiple network adapters and
the MyIP parameter was used with a link-local IPv6 address (i.e. one that
begins with “fe80::”), clients may not have been able to find the server
using TCP/IP. This has been fixed.
================(Build #1267 - Engineering Case #789740)================
The server may have returned a sequence value for CURRVAL even if NEXTVAL
was never called in the current connection for this sequence. This has been
fixed.
================(Build #1267 - Engineering Case #786626)================
The server did not allow the use of sequence.currval as a default column
value. This has now been implemented.
================(Build #1259 - Engineering Case #789267)================
The changes for Engineering case 786183 did not completely resolve a problem
where domain users explicitly present in the local group were no longer being
located. This has been corrected so that local users or domain users that
are members of a local group, as well as domain users who are indirectly
members of a local group (by virtue of being a member of a global group placed
within a local group) are now found and the group name is checked for an
integrated login mapping.
================(Build #1246 - Engineering Case #787344)================
HTTP web services that invoked a procedure call may not have returned the
correct result set if the result set description of the procedure can change
in each procedure call. This has been fixed.
================(Build #1245 - Engineering Case #788586)================
Several of the secured feature system procedures like sp_create_secure_feature_key(),
sp_alter_secure_feature_key(), etc. have a parameter named auth_key. The
documented name of the parameter for the sp_use_secure_feature_key() is auth_key
as well, however the actual implementation used a different parameter name.
This has been corrected. The parameter name is now consistent with the other
secured feature system procedures and the documentation.
================(Build #1245 - Engineering Case #788580)================
If an unusual error occured while executing the system procedure sp_generate_key_pair(),
any subsequent calls to sp_generate_key_pair() on any connection could have
caused that connection to hang. This has been fixed.
================(Build #1245 - Engineering Case #788560)================
When processing a statement that contained a subselect expression with the
select list item being either the LIST or COUNT aggregate and a GROUP BY
clause that contained only constant expressions or outer references to outer
query expressions, it was possible for the statement to fail with the error:
Assertion failed: 106901 "Expression value unexpectedly NULL in
write"
This has now been corrected.
================(Build #1243 - Engineering Case #788457)================
Several SQL statements for creating objects accepted both the “OR REPLACE”
and “IF NOT EXISTS” clauses at the same time. This has been fixed so that
at most one of these two clauses can be used. The following SQL statements
were affected:
CREATE GLOBAL TEMPORARY TABLE (v17)
CREATE MUTEX (v17)
CREATE SEMAPHORE (v17)
CREATE SPATIAL REFERENCE SYSTEM
CREATE SPATIAL UNIT OF MEASURE
================(Build #1243 - Engineering Case #788412)================
If an application made a SQL SECURITY DEFINER procedure call which changed
the effective user to something other than the logged in user, and the procedure
subsequently made a remote data access request with that different effective
user, and if there was no externlogin for that effective user, then there
would have been some instances where the remote connection succeeded without
the required externlogin. This issue has now been fixed.
================(Build #1242 - Engineering Case #788528)================
When executing an UNLOAD statement with QUOTES ALL option specified, the
quotes in CHAR values were not escaped. This has been fixed.
Note, when the QUOTES ALL option is specified, only single quote (‘) and
double quotes (”) can be specified as the quote character.
================(Build #1242 - Engineering Case #788401)================
Several SQL statements for creating or altering objects would have accepted
some clauses more than once and silently ignored all but the last one. Others
would give an unhelpful error message like “Syntax error near ‘(end of line)’
on line 1”. This has been fixed so that duplicate clauses are no longer permitted
and will raise error code -1933 in the following statements:
CREATE/ALTER FUNCTION (web service)
CREATE/ALTER LDAP SERVER
CREATE/ALTER MIRROR SERVER
CREATE/ALTER ODATA PRODUCER
CREATE/ALTER PROCEDURE (web service)
CREATE/ALTER SERVICE
CREATE/ALTER SPATIAL REFERENCE SYSTEM
CREATE/ALTER SPATIAL UNIT OF MEASURE
CREATE/ALTER TIME ZONE
CREATE/ALTER USER
================(Build #1238 - Engineering Case #788300)================
Attempting to start or stop multiple OData Producers simultaneously could
have, in some cases, lead to one or more of the Producers failing to start
or stop. This problem has now been fixed.
================(Build #1238 - Engineering Case #788247)================
When running a statement with very complex expressions (for example in the
WHERE or SELECT clause), it was possible for the server to fail an assertion
or a crash when the statement was closed. The complexity of the expression
needed was related to the maximum cache size. This has been fixed.
================(Build #1238 - Engineering Case #786492)================
If a multi-threaded application instantiated separate DbmlsyncClient objects
on separate threads, it was possible for the application to have crashed
if the Init function was called concurrently on multiple threads. The SYNCHORNIZE
command in the SQL Anywhere database engine uses the Dbmlsync API, so concurrent
calls to the SYNCHRONIZE command on different connections could also result
in a crash of the database server. These issues have now been fixed.
================(Build #1237 - Engineering Case #788218)================
Attempting to unload a version 16 database that had sync publications defined
would have failed with a “column server_protocol not found” error. This problem
has now been fixed.
================(Build #1237 - Engineering Case #788197)================
When connecting to an authenticated server using SQL Anywhere tools such
as Interactive SQL or SQL Central, executing statements that would modify
the database would have failed with the error: "-98 Authentication violation".
This problem was introduced by changes made for Engineering case 785757 and
has now been fixed.
================(Build #1237 - Engineering Case #787878)================
Stopping an HTTP(S) listener by calling the system procedure sp_stop_listener()
while processing an HTTP request, could have crashed the server. This has
been fixed.
================(Build #1232 - Engineering Case #669578)================
When executing particular forms of complex queries with very large expressions,
it was possible for the server to fail a fatal assertion. This has been fixed
so that these statements now report one of the two following errors:
SYNTACTIC_LIMIT 54W01 -890 "Statement size or complexity exceeds
server limits"
DYNAMIC_MEMORY_LIMIT 54W19 -1899 "Statement requires too much memory
during query execution"
================(Build #1230 - Engineering Case #787950)================
If an application executed the following sequence:
- a remote procedure call using a different effective user than the current
logged in user, followed by
- a DROP REMOTE CONNECTION to drop the remote connection created above,
followed by
- a remote procedure call using a different effective user than the one
above
then there was a small chance the server would have crashed when the second
remote procedure call completed. This problem has now been fixed.
It should be noted that this problem can in rare cases manifests itself
when the SQL Anywhere Cockpit is used to change the Cockpit settings.
================(Build #1228 - Engineering Case #761650)================
The server may have issued an error, for example "Column <name>
not found", if an INSERT, UPDATE or DELETE statement on a local table
referenced a proxy table, and the changing table had a publication that referenced
in its publication WHERE clause additional tables.
This has been fixed.
================(Build #1222 - Engineering Case #787092)================
In certain rare scenarios, a cached plan for a statement that did not qualify
for simple bypass and which contained a host variable, could have returned
incorrect results or thrown the runtime assertion failure 106900 - "Expression
value unexpectedly NULL." This included statements where the host variable
was inserted automatically by statement parameterization.
Note that both plan caching for non-bypass client statements and automatic
statement parameterization were new features in version 17, and so earlier
server versions are unaffected.
In all known repros the same host variable expression either appears at
least twice in the statement or else is used in a comparison predicate against
a column that occurs in the join key of a hash join.
This has been fixed.
One workaround is to disable all plan caching by setting the connection
option max_plans_cached=0. If the incorrect behaviour is only observed on
statements where the host variable was inserted by automatic statement parameterization,
another workaround is to disable only statement parameterization by setting
connection option parameterization_level=’Off’.
================(Build #1221 - Engineering Case #787592)================
Certain sub and dynamic classes built using a 1.8 JDK could not been installed
in the database. This problem has now been fixed.
================(Build #1221 - Engineering Case #787529)================
When creating a foreign key, the schema of the primary table was locked in
exclusive mode. This meant that creating the foreign table failed if another
connection was using the primary table. Further, the entire range of the
primary table was always locked, leading to an error if any row of the primary
table had uncommitted updates.
This has been changed. The schema of the primary table is now locked in
shared mode instead of exclusive. The row range of the primary table is locked
only if there is at least one row in the foreign table.
With these changes, it is now possible to create foreign keys from empty
foreign tables even when there is another connection with uncommitted row
changes in the primary table.
================(Build #1221 - Engineering Case #787277)================
Under rare circumstances, the server could have crashed while tracing statements
with diagnostic tracing (application profiling). This has been fixed.
================(Build #1219 - Engineering Case #787419)================
Invoking a stored procedure that used a temporary table T (declared by invoker)
with different definitions of T would have returned an error. The restriction
was now been relaxed to allow some mismatch between the table definitions.
Note that this is not the recommended use. It is expected that a stored
procedure will be using the exact same definition of the temporary table
in all executions.
================(Build #1218 - Engineering Case #738277)================
The server may have crashed, or returned unexpected errors, if a SELECT from
DML referenced proxy or IQ tables. This has been fixed.
================(Build #1217 - Engineering Case #787345)================
The changes for Engineering case 783569 introduced the possibility of a server
crash when executing a Remote Data Access statement when an error was encountered
during creation of an underlying cursor. This crash has now been fixed.
================(Build #1217 - Engineering Case #787340)================
The server would not have started if a server name with spaces was entered
in the server startup dialog window. This has been fixed.
================(Build #1213 - Engineering Case #787105)================
Repeatedly executing INSERT statements with a VALUES clause containing two
or more rows could have caused a crash in memory constrained environments.
This has been fixed.
================(Build #1212 - Engineering Case #787014)================
Under very rare circumstances, the server could have returned an error, an
incorrect result, or entered an infinite loop, if a query contained Transact
SQL outer joins in subqueries that were part of a disjunctive clause. This
has been fixed.
================(Build #1210 - Engineering Case #785328)================
IF and CASE expressions can be optimized in some cases when used in search
conditions. These optimizations can remove unneeded subquery invocations
or identify new sargable predicates. In particular, IF expressions are generated
when a view V is used in the null-supplying side of an outer join and V contains
a column that is a constant.
The following changes have been made to provide better performance for queries:
1. If a subselect expression has a LIST or COUNT aggregate in the select
list and there is neither a GROUP BY nor a HAVING clause, then the subselect
expression cannot be NULL. If the expression is used in the SELECT list,
it will be described as not-NULL.
2. When considering a search condition of the form cond IS TRUE where
cond cannot be UNKNOWN, then simplify to cond.
3. When considering a search condition of the form cond IS FALSE where
cond cannot be UNKNOWN, then simplify to NOT cond.
4. When considering a search condition of the form cond IS UNKNOWN:
a. If cond cannot be UNKNOWN, simplify to FALSE
b. If cond is a comparison condition of the form c0 = c1 where one input
(say c0) cannot be NULL, then simplify to c1 IS NULL. Other comparison relations
(<,<=,>=,>,<>) are supported.
5. When considering expr IS NULL:
a. If expr is CAST( e1 AS type ) and the cast cannot introduce NULL,
simplify to e1 IS NULL
b. If expr cannot be NULL, simplify to FALSE
c. If expr is known to be the NULL value at open time, simplify to TRUE
d. If expr is IF pred THEN lhs ELSE rhs END IF, simplify according to
the rules described below.
6. When considering a comparison condition e1 = IF cond THEN lhs ELSE
rhs END IF, simplify it as described below. The IF expression may appear
on the left or right of the comparison, and all comparison relations are
supported.
The following table shows the simplified conditions generated for the following
condition:
IF pred THEN lhs ELSE rhs END IF IS NULL
The simplification is only performed in cases where lhs / rhs could not
generate an error or where they would necessarily be evaluated. The pred
condition must be either a comparison predicate or an IS NULL predicate.
Simplified Condition Notes
FALSE None of pred/lhs/rhs can be NULL
pred IS UNKNOWN lhs/rhs cannot be NULL
(pred IS UNKNOWN) OR (lhs IS NULL) lhs == rhs (special case)
(pred IS UNKNOWN) OR (pred and lhs IS NULL) rhs cannot be NULL
(pred IS UNKNOWN) OR (NOT pred AND rhs IS NULL) lhs cannot be NULL
pred pred cannot be UNKNOWN and lhs is known- at-open NULL and
RHS cannot be NULL
NOT pred pred cannot be UNKNOWN and rhs is known- at-open NULL
and LHS cannot be NULL
pred AND lhs IS NULL pred cannot be UNKNOWN and rhs cannot be NULL
NOT pred AND rhs IS NULL pred cannot be UNKNOWN and lhs cannot be NULL
lhs IS NULL pred cannot be UNKNOWN and rhs == lhs (special case)
The following table shows the simplified conditions generated for the following
condition:
e1 = IF cond THEN lhs ELSE rhs END IF
Simplified Condition Notes
cond AND e1 = lhs The RHS is known to be the NULL value at open
time
NOT cond AND e1 = rhs The LHS is known to be the NULL value at open
time
(cond AND e1 = lhs) OR (NOT cond AND e1 = rhs) The cond is either a comparison
condition or an IS NULL condition and lhs and rhs are either
a known value or a column expression.
================(Build #1207 - Engineering Case #786804)================
If an application fetched a result set containing an nvarchar(1024) column
from a remote server, then that column value would have been invalid if the
original value was exactly 1024 nchar characters in length. This problem
has now been fixed.
================(Build #1204 - Engineering Case #786755)================
Procedures and functions that contained at least one input parameter of ROW
or ARRAY type and the procedure/function body was a single, query may have
incorrectly reported the error “Correlation name not found”. This has been
fixed.
================(Build #1202 - Engineering Case #786610)================
Under very rare circumstances, the server could have crashed when accessing
a PUBLIC database variable. This has been fixed.
================(Build #1200 - Engineering Case #785327)================
When comparing values of type CHAR and NCHAR, SQL Anywhere uses inference
rules to determine the type in which the comparison should be performed.
Generally, if one value is based on a column reference and the other is not,
the comparison is performed in the type of the value containing the column
reference. If a view column (v) was defined as a string literal of type NCHAR
was used in a query where the same constant string was used elsewhere as
an expression (c), and the query had 100 or fewer constants, then a comparison
between a CHAR column and the constant literal (c) might have incorrectly
failed to use the CHAR type. This has been fixed.
Further, when a query contained two tables (say R and S) where one had a
CHAR column and the other an NCHAR column (say R.ch and S.nch) and both columns
were equated to the same constant, then the server could have improperly
inferred that the two columns are equal:
R.ch = 'A' AND S.nch = 'A' ==> R.ch = S.nch
This inference is not correct. This has been fixed and such conditions are
no longer improperly inferred.
================(Build #1200 - Engineering Case #785325)================
When inserting into a table, if the SELECT block contained the sa_rowgenerator
procedure, then a work table was used. This has been changed. The work table
is no longer generated unless other conditions require it.
================(Build #1200 - Engineering Case #785322)================
When estimating the cost of a join, the server considers any expensive predicates
that might be evaluated. For example, if there is a subquery predicate, it
will affect the cost of evaluating the join.
These expensive predicates were not always included in the cost of evaluating
equi-joins. This has been changed so these predicates are considered when
estimating the cost of a plan.
For a particular customer query affected by this issue, run time reduced
from 18,268 sec to 247.8 sec with this optimization.
================(Build #1200 - Engineering Case #785318)================
When using the Plan Viewer tool in dbisql, the "Detailed statistics"
executes the plan. In this mode, precise timing is not recorded for every
node in the plan in order to minimize the distortion introduced by timing.
Nevertheless, more information is available and after this change it is now
displayed.
Statistics now included for all plans that have been executed:
In the graphical plan, if the plan has been executed then every node has
at least the following in Subtree Statistics:
- Invocations (actual)
- RunTime (estimate)
- RowsReturned (estimate and actual)
If the plan has been executed, every table scan and index scan node has
the following:
- Total rows read -- rows that were read from the table before applying
any search conditions
- Total rows pass scan predicates -- if there are scan predicates, this
line indicates how many rows passed the scan predicates [otherwise, the line
is not included]
- Total rows returned -- rows that pass all predicates for the scan and
were returned
Further, if the plan has been executed then individual predicates show the
actual number of evaluations and number of times they were true. Previously
this was only shown for “Detailed and node statistics”.
If a plan has been executed, the root node now contains the following:
- RunTime – the actual active time is always shown. In certain cases it
was not available.
- ReqCountBlockIO / ReqTimeBlockIO
- ReqCountBlockLock / ReqTimeBlockLock
- ReqCountBlockContention / ReqTimeBlockContention -- only if request
timing is enabled with –zt
- CPUTime –- in addition to the estimate, the measured approximate CPU
time is now shown
- QueryMemMaxUseful and QueryMemLikelyGrant –- these are always included
now if the plan was executed.
If a plan has been executed, the row counts for each node are now used to
determine line thickness in the graphical plan viewer. Previously, these
were only available when “Detailed and node statistics” were available.
Formatting changes:
The title for nodes in the graphical plan now includes the number of rows
returned for the node. If the node was invoked multiple times, the invocation
count is also displayed.
Eg.
Table Scan (750 rows/10 invocations)
Scan employee sequentially
When stored procedures appear in a plan, the correlation name for the procedure
is displayed. This allows us to distinguish among multiple instances of the
same procedure.
If a predicate has a cost estimate (for example, it contains a subquery),
then the predicate has a suffix “cost .123 sec” to indicate the estimate
cost per evaluation.
When generating a text plan (EXPLANATION or PLAN), if the plan has actually
been executed (for example, in the RememberLastPlan), then actual row counts
and number of invocations are now included.
When generating a text plan (EXPLANATION or PLAN), if the plan includes
an Exchange, then only the first branch is displayed. There is an indication
of how many branches were present. If the plan was executed, then the row
count of each branch is included separated by semicolons.p4
================(Build #1200 - Engineering Case #785292)================
In some contexts, duplicate rows do not affect the result of a query. For
example, when generating rows for a UNION DISTINCT operation, duplicates
are eliminated.
This change modifies the DerivedTable operator so that in contexts where
duplicates are not needed, the operator eliminates duplicates eagerly. When
the derived table would return a row that is a duplicate of the immediately
previous row, it is eliminated. Duplicate detection is based only on the
prior row so the cost of detection is low but only rows that are immediately
repeated are eliminated.
When eager duplication detection is selected for a plan, the graphical plan
shows “Eliminate duplicates eagerly yes”. For plans with statistics, the
number of duplicates eliminated is shown.
For a query of about 1.5 million rows with many duplicate values, this optimization
can improve run-time by up to 30%.
================(Build #1200 - Engineering Case #785291)================
INSERT statements did not use parallel execution plans. This has been changed
so that parallel plans are now considered for the SELECT block if the other
restrictions of parallel plans are met.
================(Build #1200 - Engineering Case #785289)================
If a query contains an ANY or ALL subquery that is not correlated to the
outer query block, the server may choose an execution plan materializing
all rows of the subquery one time with an index so each row of the outer
block can be compared to the stored results. If the subquery also contained
a UNION where at least one branch required a work table and at least one
branch did not then the plan included work tables under the union for all
branches requiring materialization. These were redundant due to the materialization
at the root and are no longer included.
================(Build #1200 - Engineering Case #785271)================
When estimating how many rows are returned for an ad-hoc join (one that is
not a PK/FK join), histograms on the joined columns are usually used to estimate
how many rows will match. When one or both of the columns are declared as
unique, histograms were previously not considered and in some cases this
caused the number of returned rows to be underestimated due to skew in the
inputs.
This change includes information from the histograms to increase the estimated
number of rows.
================(Build #1200 - Engineering Case #785266)================
During the semantic transformation phase of query processing, the server
normalizes and extends predicates in the query in order to find useful search
conditions.
One step of predicate normalization considers equality predicates that partition
values. Consider:
R.x = 1 AND T.x = R.x ==> T.x = 1
Before this change, this normalization also inferred join conditions, for
example:
R.x = 1 AND T.x = 1 ==> R.x = T.x
The inferred predicate is correct, but it does not help find a faster way
to execute the query. These additional join conditions are no longer generated
when the equality partition contains a constant.
================(Build #1196 - Engineering Case #790977)================
Under very rare timing dependent condition, an index that had long hash values
could have some assertions (for example: 200114 - Can't find values for
row ... in index ...). This has been fixed.
================(Build #1191 - Engineering Case #786183)================
Engineering case 776698 resolved a problem where a domain group was included
in a local group, but users in the domain group were not being located in
the local group (via indirection). It introduced a problem where domain users
explicitly present in the local group were no longer being located. This
problem has been corrected. Indirect lookups are now performed separately
from direct lookups.
================(Build #1191 - Engineering Case #786120)================
In very rare cases, the transaction log can become corrupted. The symptoms
of the corruption can appear as checksum failures on page 0 of the transaction
log. This has been fixed.
================(Build #1191 - Engineering Case #786112)================
When setting the QuittingTime server property using the system procedure
sa_server_option(), parsing of the provided date string did not respect the
date_order or nearest_century options. The date_order was always assumed
to be YMD and the nearest_century was always assumed to be set to 50 , despite
any connection, user, or public settings. This has now been fixed.
================(Build #1188 - Engineering Case #785869)================
The system stored procedure sp_plancache_contents() would have returned incorrect
values within column "build_avg_msec". This has been fixed.
================(Build #1187 - Engineering Case #785858)================
In some cases, dynamic cache resizing on Linux systems might not have behaved
correctly. This has been fixed.
================(Build #1187 - Engineering Case #785851)================
SQL Anywhere installations no longer include PHP drivers. They are now posted
to a web page, but the versions posted only include the .0 release of each
major/minor version.
The PHP external environment attempts to load the external environment DLL
that matches the current phpversion(), which includes the release number.
Unless the release number is 0, or an appropriate driver was previously installed,
the correct driver will not be found and the PHP external environment will
fail to start.
This has been fixed. If a DLL with the full version number is available,
it will be used. Otherwise the DLL with the .0 release number will be used.
e.g. PHP 5.6.5 would use the 5.6.0 DLL.
SQLA 12.0.1 and 16.0.0 should continue to work as before, but the fix was
included to allow for possible future changes.
Workarounds include (one of):
- rename the SQLA PHP modules to a name that will be found
- set up a php.ini file containing the “extension” setting that will load
the SQLA PHP modules
- compile the PHP drivers in the SDK directory to match your PHP installation
================(Build #1183 - Engineering Case #785674)================
In rare cases, the database server could have hung indefinitely on start-up
when running on Windows 7 or later. This was due to a bug in Windows, KB
2719306. This has been fixed so that the server now works around the bug
if it detects that Windows does not have the patch installed.
================(Build #1182 - Engineering Case #785640)================
If the Content-Type header begins with "multipart/" but is not
"multipart/form-data" (e.g. multipart/mixed), the HTTP server would
have returned a 400 error, even though the request itself is valid.
This has been fixed. The body of the request is not parsed for these Content-Types,
nor is it accessible through HTTP_VARIABLE( ‘body’ ). The body may be accessed
through the HTTP_BODY() function.
================(Build #1181 - Engineering Case #785537)================
On Windows systems, if the SQL Anywhere database server was spawned by an
application and that application did not include environment strings (in
particular, the SystemDrive environment variable), then the database server
would not have been able to resolve the location of the ALLUSERSPROFILE folder
correctly. The folder path would have contained an unresolved environment
string, possibly resulting in misplaced files. A check has now been added
for this problem and the current directory will be used instead.
================(Build #1180 - Engineering Case #785455)================
The SingleCLR property is not necessarily numeric. It is a version number,
and, on unsupported platforms, is "NONE." It should not, therefore,
be trackable by the property history feature. This has been fixed.
================(Build #1180 - Engineering Case #785450)================
The version of OpenSSL used by all SQL Anywhere products has been upgraded
to 1.0.1o.
================(Build #1180 - Engineering Case #785391)================
If a batch containing an EXECUTE IMMEDIATE statement used syntax that was
allowed in both Transact SQL and Watcom SQL dialects, and the connection
executed a Transact SQL statement immediately before executing the batch,
“Procedure immediate not found” error could have been returned. This has
been fixed.
As a side effect of this change, to execute procedure [immediate] in a Transact
SQL batch, the user now has to use “exec immediate” or “execute [immediate]”.
================(Build #1177 - Engineering Case #785381)================
In timing dependent cases, the sever may have crashed when calling sa_procedure_profile(),
sa_procedure_profile_summary(), or sa_flush_statistics(), or preparing to
store procedure statistics, while other connection performed an operation
that caused a procedure to be unloaded. This has been fixed.
================(Build #1176 - Engineering Case #785331)================
Under rare circumstances, the server could have hung while the STACK_TRACE
function, or sa_stack_trace procedure, were being called and a procedure
that used a remote table was simultaneously being called. This has been
fixed.
================(Build #1176 - Engineering Case #785330)================
Under some circumstances, running the Index Consultant against workloads
that included queries against remote tables may have caused the server to
crash. This has been fixed.
================(Build #1173 - Engineering Case #785134)================
Under rare circumstances, a long running, memory intensive query could have
caused the server to crash. This has been fixed.
================(Build #1173 - Engineering Case #784735)================
Under rare circumstances, a query that generated a large intermediate result
set containing strings of medium length (usually in the range of 128-256
bytes long) could have crashed the server. This has been fixed.
================(Build #1165 - Engineering Case #784731)================
Under rare circumstances, cancelling a parallel query could have caused a
memory leak. This has been fixed.
================(Build #1164 - Engineering Case #784717)================
Attempting to use the SYNCHRONIZE statement while connected to a server running
on Linux/ARM would have failed with a “feature not supported” error. This
problem has now been fixed.
================(Build #1164 - Engineering Case #784450)================
ST_Distance computations between planar points, or between a planar point
and a non-curve line segment, were inappropriately rounded to the nearest
multiple of the SRS gridsnap value. Consequently, a measured distance less
than the SRS tolerance could have been rounded up to a value greater than
or equal to tolerance, which could have caused the predicate ST_WithinDistance
to return FALSE for a specified distance of zero, even though the predicate
ST_Intersects returned TRUE for the same pair of geometries. This has been
fixed.
================(Build #1163 - Engineering Case #780004)================
Under rare circumstances, a query executed using a parallel bloom filter
operator could have caused a server crash or an assertion failure - “memory
allocation too large”. This has been fixed.
================(Build #1157 - Engineering Case #783734)================
Under rare circumstances, an AUTO/MANUAL text index operation could have
failed to return an error when an error was encountered. This has been fixed.
================(Build #1157 - Engineering Case #782601)================
If the query for which the graphical_plan was being calculated included a
reference to a stored procedure that was expected to return a result set,
but did not do so, the SELECT graphical_plan( … ) statement would have returned
a warning at OPEN time. This has been fixed.
Note, the issue could also have affected some queries referencing such a
stored procedure.
================(Build #1064 - Engineering Case #788051)================
If a server was running on a Unix machine (other than Mac OS X) with multiple
network adapters and the MyIP parameter was used with a link-local IPv6 address
(i.e. one that begins with “fe80::”), clients may not have been able to find
the server using TCP/IP. This has been fixed.
================(Build #1064 - Engineering Case #788026)================
Under rare circumstances, the server may have crashed, or failed an assertion:
“Assertion failed: 109512 Freeing already-freed memory”. This has now been
fixed.
================(Build #1064 - Engineering Case #787646)================
When the database server was running on Unix, calling the system functions
property(‘HTTPAddresses’) and property(‘HTTPSAddresses’) may have returned
duplicate values (eg. “IP1:port;IP2:port;IP1:port;IP2:port”). This has been
fixed.
================(Build #1064 - Engineering Case #786305)================
When using Java external environments on Mac OS X systems, the server may
not have automatically found the latest installed JRE. This has been fixed.
================(Build #1064 - Engineering Case #668971)================
When attempting starting a second server on an already started database,
the second server would have reported permission denied errors. It should
have reported instead “Resource temporarily unavailable”. This only happens
on HP and AIX. This has now been fixed.
================(Build #1063 - Engineering Case #787711)================
Clients using shared memory on Linux could have, in rare circumstances, crashed
and caused the server to crash. This has been fixed.
================(Build #1063 - Engineering Case #785941)================
If the SATMP environment variable was set to a long value (near its limit),
the server may have run into unexpected errors in the shared memory port.
This has been fixed.
Note that the length of the SATMP path is intentionally limited on Linux,
and that has not changed.
================(Build #2000 - Engineering Case #797427)================
Searching within the MobiLink plug-in could have caused a "Cannot connect
to database" error. This has been fixed.
================(Build #1471 - Engineering Case #797608)================
Attempting to open the Set Primary Key wizard while a primary key constraint,
foreign key constraint, unique constraint, table check constraint, or column
check constaint was selected in the Constraints tab, would have caused SQL
Central to crash. This has been fixed.
================(Build #1462 - Engineering Case #797151)================
Copying and pasting, or dragging and dropping, an ARTICLE or TABLE onto a
PUBLICATION could have caused SQL Central to crash. This has been fixed.
================(Build #1440 - Engineering Case #796258)================
SQL Central allow for viewing the contents of a database table. It the table's
primary key is calculated (e.g. has a default value of "autoincrement"),
SQL Central could have reported an internal error in the following cases:
- A row was inserted without providing an explicit value for the primary
key, then the column header was clicked to sort the table, or
- A row was inserted without providing an explicit value for the primary
key, a second row was added without an explicit primary key value, and then
an attempted was made to edit one of the rows.
There may be other ways to cause the internal error.
Also, copying a cell containing the special "(DEFAULT)" value
would incorrectly copy text of the form “com.sybase.resultSetTable.DefaultValue@xxxxxx”,
rather than the word "default".
These issues have been fixed. Note, these issues also affected the Interactive
SQL utility, whaich has also been fixed.
================(Build #1390 - Engineering Case #794675)================
If a users only connection to a server was a connection to the utility database,
then attempting to open the server property sheet would have failed with
a permission denied error. Now the property sheet opens but only the General
page is shown.
================(Build #1390 - Engineering Case #794674)================
If a users only connection to a server was a connection to the utility database,
then attempting to open the SQL Anywhere Cockpit would have failed with a
permission denied error. The "Open SQL Anywhere Cockpit" menu item
is now disabled in this case.
================(Build #1390 - Engineering Case #794673)================
If a server was running the utility database along with other databases,
and a user was connected to the utility database only, then attempting to
work with another database on the same server could have resulted in a permission
denied error. Specifically, an error would occur if a database was selected
in the tree or its property sheet was opened. This has been fixed.
================(Build #1390 - Engineering Case #794672)================
The popup menu for a utility database would have contained two consecutive
menu separators. This has been fixed.
================(Build #1390 - Engineering Case #794671)================
If attempting to connect to a database via a Connection Profile failed, then
SQL Central could have crashed. This has been fixed.
================(Build #1236 - Engineering Case #788161)================
In SQL Central, the "Create Service Wizard" allows for creating
a Windows service for a SQL Anywhere server/utility. Each service runs under
a Windows account. By default, the local system account is used, but any
user can be used.
If the user does not already have the Windows "Log on as service"
privilege, a prompt is displayed asking whether to grant it to the user.
If "Yes" was clicked, SQL Central would have failed to grant the
privilege unless SQL Central was running as an administrator. This has been
fixed. Now, the usual elevated privilege prompts are displayed, and the
"Log on as a service" privilege will be granted.
================(Build #1224 - Engineering Case #787707)================
When editing numeric table values in Interactive SQL or SQL Central, the
value typed could have been subject to unexpected rounding errors before
the value was sent to the database. This problem would occur if the value
could not be exactly represented as a 64-bit IEEE 754 floating point number.
It has now been fixed.
================(Build #1217 - Engineering Case #787354)================
Sybase Central can generate documentation for objects in a SQL Anywhere database.
After the files are generated, the user is asked if they want to view the
resulting HTML files. On Mac OS X systems, electing to generate the HTML
files into a directory whose path included a non-ASCII character would have
caused the browser not to open, and Sybase Central would report an internal
error. This has been fixed so that now the browser opens correctly.
Note that the problem was limited to opening the web browser. The HTML files
are generated without issue.
================(Build #2029 - Engineering Case #797243)================
The Interactive SQL utility (dbisql) could have reported an internal error
on shutdown in some intermittent, timing-dependent cases. This has been fixed.
================(Build #2023 - Engineering Case #797605)================
Executing a statement or a batch of statements which resulted in a lot of
asynchronous messages being sent back to the client could have caused the
Interactive SQL utility to become unresponsive for many minutes when it was
run as a windowed application. This has been fixed.
================(Build #2000 - Engineering Case #797075)================
If a user owned a table or procedure with the same name as a system table
or procedure (eg. a user with an “sa_split_list” procedure), that object
would not have been included if the database was unloaded with Unload Database
utility (dbunload). This has been fixed.
================(Build #2000 - Engineering Case #788758)================
In the "Connect" dialog, the computer mentioned in the "Host"
field can be pinged connecting to a database on a different computer. This
window did not handle the case where multiple hosts were specified. This
has been fix so that now it does.
================(Build #2000 - Engineering Case #743754)================
The syntax highlighting editor paints the background of brackets a different
colour when the caret is adjacent to a bracket. The matching bracket is
also highlighted to more easily identify pairs of brackets.
The colour used for the highlighting should have been (but was not) customizable,
along with all of the other colours the editor uses. This has been corrected
so that the colour used for bracket highlighting can now be set.
================(Build #1458 - Engineering Case #796852)================
In the Interactive SQL utility, the SQL editor can show procedure, function,
and (spatial) method prototypes in a tooltip for the editor. When an opening
parenthesis is typed, the editor communicates with the database to see if
the text to the left of the parenthesis is a procedure so that it can compose
the prototype for the tooltip. The editor is unresponsive for the time needed
for that database check. For slow databases, the editor would have hang for
a couple of seconds when typing an opening parenthesis, which made it unusable.
The editor configuration dialog has a checkbox, "Show tool tips".
The SQL editor would have performed the database check even if this box was
cleared. Now, the database check is skipped if the box is cleared.
KBA 2306369 https://service.sap.com/sap/support/notes/2306369
================(Build #1435 - Engineering Case #796140)================
Clicking a favorite for a database connection could have left the Interactive
SQL utility unresponsive to input with a "Connecting to database"
message shown. This was most likely to happen when there was already a connection
to a database when the favorite was clicked. This has been fixed.
================(Build #1432 - Engineering Case #795982)================
On OS X systems, the "Expression Editor" window, which is part
of the "Query Editor" was displayed correctly only the first time
it was opened. When opened subsequent times, only its title bar appearred.
It was impossible to resize the window back to its normal size. This has
been fixed.
================(Build #1432 - Engineering Case #795980)================
Error messages that were too long to fit on a single line in the History
panel were drawn so they overlapped the statement timing text, making the
error message difficult or impossible to read. This has been corrected so
that the error messages are now line wrapped.
================(Build #1397 - Engineering Case #794961)================
The text completer could have mistaken the keyword "ON" following
a table name as a table alias. If the completer was used to fill in the name
of a column in that table, the column name wouldn have been prefixed by "on.",
which was incorrect. This has been fixed.
================(Build #1397 - Engineering Case #794889)================
The Connect window allows connecting to a SQL Anywhere database using a connection
string, and contains a list of recently used connection strings. Passwords
in the list of connection strings were not removed when they were saved.
This has been corrected so that now they are.
================(Build #1396 - Engineering Case #794832)================
When using the Unload utility to do an online rebuild (dbunload –ao), it
performs a check that the number of rows in a table or materialized view
in the old database matches the new database. This check was not valid for
MANUAL refresh materialized views, which are not refreshed by default during
database reload. Furthermore, if the –g option was specified, and the view
was refreshed during reload, it may still not have been in exactly the same
state as the original view. This has been fixed.
Note that manual materialized views still have to be manually refreshed
after a rebuild unless –g option is specified.
================(Build #1383 - Engineering Case #794821)================
If the Interactive SQL utility (dbisql) was run as a command line program
from an SSH shell (or similar), and the SSH connection was closed, it was
possible for dbisql to then consume 100% of the CPU. This has been fixed.
================(Build #1339 - Engineering Case #792652)================
The "Compare Plans" window could have crashed the Interactive SQL
utility while comparing plans if one plan contained a subquery that was not
in the other plan. This has been fixed.
================(Build #1319 - Engineering Case #791975)================
A review of Java diagnostics revealed an incorrect coding practice that could
have caused the Interactive SQL utility to become unresponsive under rare
circumstances. This has been fixed.
================(Build #1309 - Engineering Case #791613)================
Statements were not added to the "History" tab until they had completed
executing. This had the inadvertent side-effect of delaying all asynchronous
messages associated with the statement from being displayed until after the
statement had completed. This has been fixed so that statements are added
to the "History" panel as soon as they start executing. Asynchronous
messages are displayed as they are received by the Interactive SQL utility.
As part of this change, a second bug was fixed. If an empty asynchronous
message was received, a blank line was not (but should have been) displayed
on the "History" panel. Omitting the blank line prevented subsequent
asynchronous messages from the same statement from being displayed consistently.
This has also been fixed.
================(Build #1303 - Engineering Case #791422)================
The Service utility (dbsvc) for Linux would have failed to start a service
on SuSE 11 systems. The following error message was displayed:
sbin/start-stop-daemon: invalid option -- 'c'
Try `/sbin/start-stop-daemon --help' for more information
This has now been fixed.
================(Build #1298 - Engineering Case #791163)================
The usage screen for the Service utility (dbsvc) for Linux was missing [options]
for all use-cases other than "delete.” They have now been added. Also,
the capitalization of options for -t flag has been corrected. It was also
possible for the wrong PID to be written to the PID file, resulting in failure
to start some services. This has been fixed.
================(Build #1257 - Engineering Case #789269)================
The Text Completer did not include support for the following statements:
ALTER ODATA PRODUCER
CREATE [OR REPLACE] ODATA PRODUCER
DROP ODATA PRODUCER [IF EXISTS]
These have now been added.
================(Build #1257 - Engineering Case #789262)================
If multiple rows were selected in a result table, pressing the Delete key
or clicking the "Delete Row" context menu deleted only the first
selected row, rather than all of the selected rows. This has been fixed
so that all of the selected rows are now deleted.
================(Build #1249 - Engineering Case #788698)================
Changes for Engineering case 768658 prevented the Interactive SQL utility
from committing on shutdown (or when disconnecting) when connected to any
type of database other than SQL Anywhere or SAP IQ. This has been fixed.
================(Build #1238 - Engineering Case #788303)================
The Interactive SQL utility could have crashed after executing a statement,
or after disconnecting from a database. The problem was timing-dependent,
and appeared only on certain computers. It has now been fixed.
================(Build #1235 - Engineering Case #788105)================
When a statement is executed, the SQL is added to the History panel where
its execution time, result set count and update counts are also displayed.
If a statement or batch returned more than about 10 result sets, and the
SQL was longer than the History panel was wide, the SQL could have been displayed
as wide as the panel, effectively pushing the execution time and counts so
far to the right that they could not be seen. This has been fixed.
================(Build #1235 - Engineering Case #788097)================
On Ubuntu systems, creating a service with dbsvc may have resulted in the
following error messages:
update-rc.d: warning: start runlevel arguments (2 3 5 ) do not match SA_demosvc
Default-Start values (2 3 5)
update-rc.d: error: expected runlevel [0-9S] (did you forget "."
?)
A temporary workaround is to run the update-rc.d command manually after
receiving the above error message:
sudo /usr/sbin/update-rc.d SA_demosvc start 60 2 3 5 . stop 80 S 0 1 4 6
.
This has been fixed.
================(Build #1231 - Engineering Case #788025)================
In the Interactive SQL utility, DATE, TIME, and TIMESTAMP table values can
be formatted using the locale rules (the default), or using the database
server's formatting options. When editing a cell value in the "Results"
panel when server formatting was selected, the DATE/TIME/TIMESTAMP value
would have been incorrectly shown using the locale-specific formatting. For
example, on a German computer, if a TIMESTAMP value was edited which the
database server would have rendered as "2015-08-05 15:54:29.768",
the cell editor value would have been "05.08.2015 15:54". Note
the use of periods rather than dashes to separate the parts of the date,
as well as the order of the date parts. Further, if anything other than an
ISO-formatted value was given in the cell editor, it could have been parsed
incorrectly, which would end up inserting an incorrect value into the table.
Now, the cell editor's value uses the same formatting as the server.
This change affects DBISQL if server formatting of dates, times, and timestamps
is selected. It also affects SQL Central which always formats dates, times,
and timestamps using the database's formatting options.
================(Build #1229 - Engineering Case #787888)================
Adding a row to a table from the "Results" panel with a UNIQUEIDENTIFIER
column would have caused Interactive SQL to crash. This has been fixed.
This problem only affected new rows added from the scrolling table component
in the "Results" panel. Editing an existing row was fine. Executing
an explicit INSERT statement was also fine.
This bug also affected the "Data" tab for tables in SQL Central.
================(Build #1221 - Engineering Case #787530)================
An XML value can be viewd from a result set in its own window. That window
contains a tab called "XML" which contains a "Format"
button. Clicking the button formats the XML to make it more readable. f
the column value included a self-closing element which contained whitespace
within the tag, it was not recognized as a self-closing element, and all
subsequent indenting was wrong.
For example, "<e><e /></e><f>Test</f>"
should be formatted
<e>
<e />
</e>
<f>Test</f>
but was incorrectly formatted
<e>
<e /></e>
<f>Test</f>
This has been fixed.
================(Build #1209 - Engineering Case #786957)================
The "Tools/Compare Plans" menu could have been enabled when connected
to a database that was not SQL Anywhere or IQ. Now, the menu is enabled
only when connected to SQL Anywhere or IQ databases.
================(Build #1202 - Engineering Case #786627)================
If an attempt to connect to a SQL Anywhere database failed, an error message
with a "Help" button was shown. Clicking the button opened a web
browser, but the browser would have reported a 404 error (page not found).
This has now been corrected so that the browser opens a page which describes
the error.
================(Build #1193 - Engineering Case #786259)================
XML values can be displayed in their own window by double-clicking them.
That window contains a number of tabs, one of which is "XML Outline",
which renders the XML value as a tree. On non-Windows computers, clicking
on an expandable node in the tree could have expanded the wrong node, or
could have done nothing. This has been fixed.
================(Build #1193 - Engineering Case #786243)================
It was possible for the Interactive SQL utility to have reported an out-of-memory
error in the Import wizard when importing data which contained very long
column values. This has been fixed.
================(Build #1187 - Engineering Case #785827)================
If a service was created that required an ODBCINI setting using the Service
utility (dbsvc) on some Linux distros, the service would have failed to start
or would have behaved incorrectly. This was due to the ODBCINI environment
variable setting not propagating through to the started service. Affected
distros include Red Hat 5, SuSE 12 (when using the LSB service interface),
and possibly others. This has been fixed.
================(Build #1173 - Engineering Case #785128)================
Explicitly specifying the -up option of the Unload utility (dbunload) would
have also turned the –v option on as well. This has been fixed.
================(Build #1167 - Engineering Case #784929)================
If the Broadcast Repeater utility used the -x option was used to stop an
existing dbns, it would work (the first dbns would shut down), but the second
dbns would remain running. This has been fixed.
================(Build #1166 - Engineering Case #784802)================
Rapidly pressing the F5 or F9 keys to repeatedly execute a statement could
have caused the Interactive SQL utility to report an internal exception.
This has been fixed.
================(Build #1165 - Engineering Case #784736)================
If an INPUT or OUTPUT statement completed on a different tab, the "SQL/Execute",
"SQL/Stop" (et al) menus and their associated toolbar buttons were
not enabled correctly; “Execute” was disabled, and “Stop” was enabled. As
a result, even though the statement had completed, it was not possible to
execute any more statements on the tab. This has been fixed.
Note that the problem was specific to the INPUT and OUTPUT statements, and
they had to be running on a tab that was not selected when the statement
completed. If the statement was running in the selected tab, the menus and
toolbar buttons were enabled correctly.
================(Build #1165 - Engineering Case #784723)================
The Interactive SQL utility could have reported an internal error if the
Query Editor was opened after losing the connection to a SQL Anywhere database.
This has been fixed.
================(Build #1164 - Engineering Case #784665)================
The Interactive SQL utility could have reported an internal error when starting
to edit a row of table data and then inserting a new row by opening the context
menu for the row header, rather than the row itself. This has been fixed.
================(Build #1164 - Engineering Case #784649)================
When exporting data to an ASE database, the "Owner" combobox on
the Export Wizard page where a table name is specified could have contained
a given owner name many times. This has been corrected so that now the name
appears only once.
================(Build #1163 - Engineering Case #784567)================
The SQL Anywhere Profiler could have crashed when running the Index Consultant
on an entire workload if the workload contained statements that were executed
by users that have since been dropped. This has been fixed.
================(Build #1064 - Engineering Case #787289)================
Execution of the Unload utility (dbunload) with the online rebuild options
-ao or -aob could have caused it to crash or incorrectly report a syntax
error if run against a version 16 or earlier database. This has been fixed
so a descriptive error is now reported.
================(Build #1351 - Engineering Case #793253)================
On Japanese and Chinese systems, mnemonics for items in the "Connect"
menu were incorrectly in the middle of the menu text, rather than at the
end. This has been fixed.
================(Build #2003 - Engineering Case #796749)================
UltraLite error parameters were truncated when they exceed roughly 70 bytes
(the size of the parameters field in the SQLCA data structure).
This has been addressed by internal changes to store full error parameter
info, new C++ APIs to access it, and updates to other tools and languages.
Existing APIs based on the SQLCA or ul_error_info structure, which includes
the ULError class, continue to truncate error parameters because of the nature
of those structures.
Here is an example of parameter truncation using the ulsync tool:
Error: Sync failed: Synchronization failed due to an error on the MobiLink
server: [-10002] Message: ODBC: [SAP][ODBC Driver][SQL Anywhere]Primary key
f
ulsync now reports:
Error: Sync failed: Synchronization failed due to an error on the MobiLink
server: [-10002] Message: ODBC: [SAP][ODBC Driver][SQL Anywhere]Primary key
for table 'basic' is not unique: Primary key value ('100') (ODBC State =
23000, Native error code = -193). Table Name: basic. Primary Key(s): 100
[SQLCODE -857/SERVER_SYNCHRONIZATION_ERROR]
For C++, use the new ULConnection::GetLastErrorMessage(), which is equivalent
to ULConnection::GetLastError() and ULError::GetString(), except without
truncation. A new error callback provides full error info as well (see ULDatabaseManager::SetErrorCallbackEx()).
================(Build #1381 - Engineering Case #794181)================
The runtime would have crashed if a temporary table exceeded the maximum
row size. This has been fixed. The runtime will now correctly report the
error SQLE_MAX_ROW_SIZE_EXCEEDED.
================(Build #1353 - Engineering Case #793459)================
When executing a query containing a comparison operator in the WHERE clause,
the UltraLite runtime could have returned incorrect rows, or failed to return
the expected rows. This would have occurred when the rows had NULL values
for the index used to perform the query. This has been fixed.
================(Build #1286 - Engineering Case #790646)================
The UltraLite WinRT component failed to synchronize over HTTPS using non-persistent
HTTP 1.0 connections. This has been fixed.
================(Build #1253 - Engineering Case #788991)================
If an UltraLite client crashed or was terminated in the middle of a download-only
synchronization, it was possible for the client to enter a state where all
subsequent synchronizations would fail with SQLE_UPLOAD_FAILED_AT_SERVER
and the MobiLink log would report mismatched sequence IDs. This has been
fixed.
================(Build #1208 - Engineering Case #786956)================
The UltraLite WinRT component was failing the Windows App Certification Test.
This has now been fixed.
The main impact of this fix is that the Close() methods of the following
classes were renamed to CloseObject(): IndexSchema, TableSchema, DatabaseSchema,
Table, ResultSet, PreparedStatement, and Connection. This is because these
classes implicitly implement the Windows.Foundation.IClosable interface,
which has a Close() method. The CloseObject() method performs actions specific
to the UltraLite component.
================(Build #1174 - Engineering Case #785272)================
The UltraLite Runtime library could have caused a crash when processing nested
queries, typically with at least 32 levels of nesting. This has been fixed.
Now, if UltraLite cannot process such queries due to resource constraints,
a SQLE_RESOURCE_GOVERNOR_EXCEEDED error is signaled.
================(Build #1165 - Engineering Case #784517)================
The Close method of the Connection class of the UltraLite WinRT component
was not visible in the projection to JavaScript, even though it was visible
in the projections to C++ and C#. This has been fixed by the addition of
the method CloseJS to Connection, which is equivalent to Close, and is visible
in the JavaScript projection.
Similarly, the Close method in the following classes were not visible in
the projection to JavaScript:
DatabaseSchema
IndexSchema
PreparedStatement
ResultSet
Table
TableSchema
This has been fixed by adding CloseJS methods to these classes.
================(Build #1064 - Engineering Case #788994)================
On iOS (or Mac OS X), UltraLite synchronizations could have reported a protocol
error on a network failure, rather than succeeding or reporting the correct
stream error. This has been fixed.
================(Build #1384 - Engineering Case #788865)================
An Embedded SQL application using TCHAR datatypes may have encountered a
compile error. This has been fixed.
================(Build #1162 - Engineering Case #784515)================
If UltraLite table values whose primary key contained DATE columns were edited,
SQL Central and the Interactive SQL utility would not have been able to refetch
the edited row values; an error message was shown to the user. If the user
then tried to delete that row, the software would have reported an internal
error. This has been fixed so the error no longer occurs.
This change also fixes the behavior where selecting a row, then clicking
one of the menus from the "Generate" context menu would have generated
a SQL statement that contained a literal DATE value which could not be processed
by the database.
================(Build #1419 - Engineering Case #795326)================
If an operation was performed that would result in a SQLE_INDEX_NOT_UNIQUE
error, UltraLite would incorrectly report the error as SQLE_PRIMARY_KEY_NOT_UNIQUE.
This has been fixed.
================(Build #1451 - Engineering Case #796453)================
The value supplied to FileTransfer.setRemoteKey() was ignored by UltraLiteJ
for Android. This has been fixed.
================(Build #1440 - Engineering Case #796325)================
With UltraLiteJ for Android, file transfers would have faild over a secure
connection with a MobiLink communication error code 207 "no trusted
root certificates were provided", even though the trusted root certificate
for the server was in the certificate store of the OS. This has been fixed.
A security patch contains an already-released version of the software but includes
updated security components. This process allows the software to be tested more quickly
so that important security fixes are released to customers quickly. Two build numbers
are recorded for security patches: one build number identifies the build of the software
that was previously tested and released; the other is the build of the new security
components that have been updated in the release
The following security patches have been released.