SQL Anywhere Bug Fix Readme for Version 12.0.1, build
3406
Choose a range of build numbers for which to display
descriptions. For example if you want to see what was fixed since the last
EBF you applied then change 3152 to the build number of that last EBF. Click
Update Readme to make those changes take effect. to Update
Readme
A subset of the software with one or more bug fixes. The bug fixes are
listed below. A Bug Fix update may only be applied to installed software
with the same version number.
While some testing has been performed on the software, you should not distribute
these files with your application unless you have thoroughly tested your
application with the software.
A complete set of software that upgrades installed software from an older
version with the same major version number (version number format is
major.minor.patch). Bug fixes and other changes are listed in the "readme"
file for the upgrade.
For answers to commonly asked questions please use the following URL:
Frequently Asked Questions
If any of these bug fixes apply to your installation, iAnywhere strongly recommends
that you install this fix. Specific testing of behavior changes is recommended.
================(Build #3320 - Engineering Case #663991)================
Under some circumstances, queries with cached plans and queries containing
complex correlated subqueries may have returned incomplete results if they
were executed as parallel plans. This has been fixed.
Note, a workaround is to disable intra-query parallelism (set MAX_QUERY_TASKS=1).
================(Build #3315 - Engineering Case #661791)================
A query containing a join between two or more tables could have returned
an incorrect result if the executed query plan used an Index-Only Scan of
some index T_idx over table T. For the problem to have occurred, a column
T.col must have participated in a non-equality join predicate (e.g. "T.col
< S.col", or "T.col BETWEEN S.col1 AND S.col2"), and there
must have existed one or more columns in index T_idx preceeding T.col that
did not participate in equality predicates. This has been fixed.
================(Build #3347 - Engineering Case #668833)================
The dbmlsyc command line option -qi prevents the tray icon or window from
being displayed. This behaviour is identical to the -qi option of the database
server. The option has existed since 11.0.1, but was not referenced in the
usage text or the documentation. The usage text has been corrected
================(Build #3362 - Engineering Case #671955)================
The new property "ianywhere.qa.server.disableDeleteRules" has been
added to the QAnywhere server properties that can be specified in the configuration
file that can appear after the -m option of the MobiLink command. When set
to True (default is False), this property disables the message delete rules
and archiving processes that automatically run while the server is running.
This property would normally not be used, but it is useful, along with the
property "ianywhere.qa.server.disableNotifications", in the scenario
where more than one MobiLink server is running on a given consolidated database,
and the servers are not in a server farm configuration. In this case, the
MobiLink servers must be configured such that only one of the servers is
running message delete rules and the QAnywhere notifier.
================(Build #3347 - Engineering Case #668832)================
The dblsn command line option -qi prevents the tray icon or window from being
displayed. This behaviour is identical to the -qi option of the database
server. The option has existed since 11.0.1, but was not referenced in the
usage text or the documentation. The usage text has been corrected
================(Build #3338 - Engineering Case #667520)================
A new command line option 'uninstallall' (or 'ua') has been added to SetupVSPackage.exe.
When specified, the 'uninstallall' option will cause SetupVSPackage to remove
all versions of SQL Anywhere assemblies from the Global Assembly Cache.
For example:
SetupVSPackage.exe /ua
================(Build #3292 - Engineering Case #659363)================
The Timeout, SendBufferSize, and ReceiveBufferSize TCP options now have upper
limits. Values specified above these limits will result in connection failure
(-832). The limits are:
Timeout: 3600 seconds
SendBufferSize: 1048576 bytes (1 MB)
ReceiveBufferSize: 1048576 bytes (1 MB)
================(Build #3371 - Engineering Case #674389)================
On Windows desktop platforms, the Winsock version 1 library has been replaced
by the Winsock version 2 library. As a result, Wsock32.lib has been replaced
by Ws2_32.lib. A few applications (MobiLink, Relay Server) that need Microsoft
additional functionality, such as TransferFile, also include Mswsock.lib.
The result is the elimination of the Wsock32 DLL and a smaller execution
time footprint (36K less).
Note, this change also affects the ADO .NET provider, the OLE DB provider,
MobiLink server, Relay Server Outbound Enabler, database server, all SA software
requiring TCPIP running on Windows.
================(Build #3284 - Engineering Case #657471)================
The PHP external environment and the PHP driver now support PHP versions
5.3.3, 5.3.4, and 5.3.5.
================(Build #3406 - Engineering Case #678806)================
The ENCRYPTED KEY '<key>' clause is now supported in the openstring
OPTIONS clause. This is useful for reading in files created using UNLOAD
with the ENCRYPTED clause.
================(Build #3393 - Engineering Case #677104)================
Current login policy allowed putting a restriction over the number of failed
login attempts a user can make before the user's account is locked. However,
this restriction did not apply to users with DBA authority. Regardless of
the number of failed login attempts, a DBA user was always allowed to login
if correct credentials are provided. This made DBA accounts vulnerable to
brute force attacks. This has been changed with the new option, max_failed_login_attempts.
The value of this option is also applied to users with DBA authority. However,
to prevent complete database lock down, an automatic unlock time of 1 minute
is also applied. At the time of database restart, a DBA user will also be
allowed to make one failed login attempt, regardless of the number of failed
login attempts stored in the catalog.
================(Build #3370 - Engineering Case #673210)================
The NodeType connection parameter is used by read-only scale-out to possibly
redirect a connection to a different server. Previously, NodeType supported
the values DIRECT, PRIMARY and COPY. Support has now been added for MIRROR
and READONLY values.
MIRROR - When the NodeType connection parameter is set to MIRROR, and you
have connected to a copy node or the primary server, the connection is redirected
to the mirror server.
READONLY - When the NodeType connection parameter is set to READONLY, and
you have connected to a copy node or the primary server, the connection is
redirected to the copy node in its branch with the lowest load. If there
are no copy nodes, the connection is redirected to the mirror server. If
you have connected to the mirror node the connection is accepted since the
mirror server does not know the status of the copy nodes. READONLY is used
to connect to any read-only server, either a copy node or the mirror.
================(Build #3338 - Engineering Case #667668)================
The following two extensions have been made to the -xa option:
1) The dbn= value can be "*", which means any database can use
this server as an arbiter.
2) The auth= value can be:
a) omitted, which means no validation of the authentication string provided
by a mirror server is done.
b) a single value, which means all databases must use the same authentication
string.
c) a list of values with the same number of entries as specified by dbn=
(i.e. previous behavior)
================(Build #3287 - Engineering Case #657712)================
Additional information is now saved for graphical and long plans. This additional
information includes:
- Known values for expressions are now dumped in the plans. For example,
a stored procedure parameter known at the optimization time is dumped as
'parm1[100]' if its name is 'parm1' and its known value is '100'.
- For long plans generated by the application profiling, extra information
related to the optimization process is now dumped. For example, 'Plan [ Total
Cost Estimate: 3.5657, Costed Best Plans: 1, Costed Plans: 13, Optimization
Time: 0.074541, Estimated Cache Pages: 590 ]' This type of information is
already present for long plans generated by calling the explanation() function.
- Information related to the cached plan of a statement is now dumped in
its long plan.
- Predicates used to generate fence posts for a partial index scan are now
dumped in the long plans generated by the application profiling. This type
of information is already present for long plans generated by calling the
explanation() function.
Also, graphical plans with statistics saved during tracing did not actually
contain any statistics. This has been fixed.
================(Build #3363 - Engineering Case #672080)================
The following new entry point has been added to the dbtools library:
DBLogFileInfo function
Obtains the log file and mirror log file information of a non-running database.
Prototype
short DBLogFileInfo ( const a_log_file_info * );
Parameters
A pointer to a structure. See a_log_file_info structure
.
Return value
A return code, as listed in Software component exit codes
.
Remarks
The DBLogFileInfo function returns the log file and mirror log file paths
of a non-running database file. Note that this entry point will only work
for databases that have been created with SQL Anywhere 10.0.0 and up.
-----------------------------------------------
Here is the necessary information for the new a_log_file_info structure:
typedef struct a_log_file_info {
unsigned short version; // set this to DB_TOOLS_VERSION_NUMBER
MSG_CALLBACK errorrtn;
const char * dbname; // database file name spec
const char * encryption_key; // database file encryption key
char * logname; // buffer for returning log file name
size_t logname_size; // size of the logname buffer
char * mirrorname; // buffer for returning mirror log file name
size_t mirrorname_size; // size of the mirrorname buffer
void * reserved; // reserved for internal use, must set to NULL
} a_log_file_info;
================(Build #3300 - Engineering Case #662054)================
When deploying, the directory used by the Interactive SQL utility, Sybase
Central, the Console utility, and the MobiLink Monitor, can now be specified.
To do this, an OEM.ini file must be deployed along with these utilities.
The file must contain the following lines:
[preferences]
directory={preferences files directory|
where "preferences_files_directory" is a fully-qualified directory
name, e.g. "c:\work\prefs". The directory name should not end
in a separator (backslash on Windows; forward slash on Unix and Mac OS X).
Preferences files include:
.isqlPreferences12_32
.isqlPreferences12_64
.isqlHistory12
.jlogon12
.textCompleter12
.SybaseCentralEditor610
.scUserPreferences610_32
.scUserPreferences610_64
among others.
================(Build #3299 - Engineering Case #661493)================
The certificate utilities, Certificate Viewer (viewcert), Certificate Creation
(createcert), and Key Pair Generator (createkey), now run on 64-bit Windows.
================(Build #3276 - Engineering Case #655157)================
If there were any missing messages, SQL Remote would have asked for a resend
after it had reached its receive polls given by the -rp option. This resend
logic could have caused the publisher to re-scan the transaction log(s) and
slow down replicating new transactions, especially on heavy load databases.
This has been changed so that when a message in a multi-part message series
(SQL Remote will generate multiple messages for a single transaction to form
a multi-part message when the transaction is too big to fit in a single message)
is missing, SQL Remote will not immediately ask for a resend, if the received
messages are not followed by any messages that contain a commit or any messages
that belong to another multi-part message series. This new logic will help
users who
need to shut down or kill SQL Remote when it is sending multi-part messages
to its subscribers.
================(Build #3339 - Engineering Case #667716)================
A new name type ul_name_type_qualified has been added to ul_column_name_type
in tjhe header ulcpp.h. When this new name type is used in conjunction with
the GetColumnName function in the ULResultSetSchema class, a qualified name
for the associated column in the ResultSet can be obtained, if possible.
If the column represents a correlated table, then that qualified name is
used; if the column represents a table column, then that qualified name is
used; if the column has an alias name, then that name is used. Otherwise,
an empty string is returned.
================(Build #3308 - Engineering Case #663307)================
UltraLite now supports the 'armv7' architecture when targeting iOS. With
the just-released Xcode and SDK versions, the default includes armv7.
================(Build #3292 - Engineering Case #659615)================
Some internal optimization algorithms have been generalized and improved.
This may change plans for queries.
================(Build #3335 - Engineering Case #667152)================
Some internal optimization algorithms have been generalized and improved.
This may change plans for queries.
================(Build #3324 - Engineering Case #665538)================
ZLIB compression has been added to UltraLiteJ for the Android. This is accomplished
with the following addition methods:
setZlibCompression( boolean )
setZlibDownloadWindowSize( int )
setZlibUploadWindowSize( int )
zlibCompressionEnabled()
================(Build #3315 - Engineering Case #664390)================
End-to-end encryption (e2ee) has been added to UltraLiteJ for the Android
platform. This was accomplished by using the new methods in the StreamHTTPSParms
interface:
void setE2eePublicKey( String file_name )
String getE2eePublicKey()
The file_name is the name of an RSA public key file used in the encryption.
================(Build #3309 - Engineering Case #663502)================
A new UltraLiteJ utility, ULjExportBuilder, has be added. This utility takes
an existing J2SE UltraLiteJ database and produces a more compact file that
can be deployed to J2SE or RIM clients. An equivalent database can then be
created from the exported file.
usage: ULjExportBuilder database-file exported-file
The required two arguments are file names. The database must not be encrypted
and must be a shadow-page database (the default).
To invoke the export functionality from a Java program, create an object
com.ianywhere.ultralitej.pgmsutility.ULjExportBuilder (there are no arguments
passed to the constructor) and then invoke the export method with one argument
which is a two-element String array containing the names of the database
and export files respectively.
The exported file can placed on a client device using, for example, a MobiLink
file transfer. The database may be imported using an import method which
has three arguments:
java.io.InputStream which is used to read the exported file
String to specify the name of the database
null (no encryption) or an EncryptionControlObject which will be used to
encrypt pages within the database.
(1) On Rim devices the methods are:
DatabaseManager.importDatabaseFileME (import to a RIM file in flash or on
an SD-card)
DatabaseManager.importDatabaseObjectStore (import to the Rim Object store)
(2) On J2SE:
DatabaseManager.importDatabaseFile (import to a file )
================(Build #3373 - Engineering Case #673646)================
It was possible to check both the "Task runs on a schedule" and
"High priority" boxes in the Remote Task Properties window. These
options are mutually exclusive, so this should have been disallowed. This
has been fixed.
================(Build #3373 - Engineering Case #673641)================
Renaming of a member of a destination alias would have caused an error message
saying that there was a problem saving the "deletion rule". Destination
alias members can now be successfully renamed without getting an error message.
When deleting the members of a destination alias, the exception generated
is now explicitly ignored if the client being deleted doesn't actually exist.
================(Build #3338 - Engineering Case #655987)================
The "Apply" button on the property sheet for a Remote Task was
not enabled when various changes were made. Now, the button is enabled correctly.
================(Build #3291 - Engineering Case #658860)================
Sybase Central would have crashed when using the QAnywhere plugin to define
a property for a connector and the property was given both a blank name and
value. Now, the creation of properties with blank names is prevented, as
these are meaningless in any case. A message box indicating that the property
name must not be empty is displayed.
================(Build #3284 - Engineering Case #657284)================
The MobiLink Server log file viewer in Sybase Central might not have listed
all synchronizations in a given log file separately if the log file contained
messages from more than one run of the MobiLink Server. This has been fixed.
================(Build #3284 - Engineering Case #657068)================
In the MobiLink Server Log File Viewer, selecting a synchronization could
have resulted in the window becoming unresponsive if the synchronization
contained hundreds of thousands of messages. This has been fixed.
Also, it was noticed that synchronizations were not initially listed in
chronological order if the log file contained output for more than one run
of the MobiLink Server. This has also been fixed.
================(Build #3281 - Engineering Case #656863)================
If a synchronization model had script errors that were fixed without opening
the Events editor or saving the model, attempting to deploy the model would
have erroneously failed because of a script error. This has been fixed.
================(Build #3280 - Engineering Case #656291)================
If a Destination Alias defined in a Server Store was deleted, the alias was
still shown in Sybase Central until the QAnywhere server completed the deletion.
That could have taken up to a minute, or could never have happened if the
QAnywhere server was not running. If deleting the alias was tried a second
time, an obscure error message would have been displayed saying that the
alias could not be deleted. Now, the Destination Alias is removed from Sybase
Central as soon as the user deletes it, the same as in earlier versions of
Sybase Central.
================(Build #3275 - Engineering Case #654759)================
Changes to the members list were not saved when the OK button in the property
sheet for a destination alias. Also, the Apply button was not enabled after
a member was added, removed, or edited. Both of these problems have now been
fixed.
================(Build #3268 - Engineering Case #653058)================
When creating a rule with a "Custom" schedule type, the schedule
that was saved could have been incorrect if "Run rule every" was
turned off in the "Schedule Editor" window. The rule was saved
such that it was run every 10 minutes. This has been fixed.
================(Build #3266 - Engineering Case #652577)================
Sybase Central could have crashed while the property sheet for a client message
store was open, if adding a new property was started, but then the action
was cancelled. This has been fixed.
================(Build #3325 - Engineering Case #665535)================
When exporting to a database in the MobiLink Monitor, the values exported
to the per-table details table (called mlm_by_table by default) were the
per-sync values instead of the per-table values. This has been fixed.
================(Build #3299 - Engineering Case #661035)================
When deploying a Synchronization Model for an existing remote database and
only deploying to file, the generated Windows batch file would have failed
when execute. For example, a "You are not connected to a database"
error could have occurred when the batch file tried to apply the generated
SQL file to the remote database. This has been fixed.
To workaround the problem, change this line in the generated batch file:
set CONNECTION=%1
to this:
set CONNECTION=%~1
================(Build #3289 - Engineering Case #658482)================
When a MobiLink Monitor instance that already had a horizontal scroll bar,
was connected to a MobiLink server, the Utilization Graph time scale (if
Utilization Graph was enabled) would have been different than the Chart time
scale. After being connected long enough for the horizontal scroll bar to
be redisplayed, the scroll bar position would have been incorrect and the
Overview Marquee Tool would have fluctuated between the inconsistent time
scales. This has been fixed.
A workaround is to use the Marquee Tool, or change the zoom to fix the display,
or disable the Utilization Graph to prevent the problem.
================(Build #3286 - Engineering Case #657979)================
The MobiLink Monitor's Zoom To Selection menu or toolbar button might not
have panned to the selected synchronization until it was used a second time.
This has been fixed.
================(Build #3268 - Engineering Case #653055)================
Any parameters entered on the MobiLink Monitor's command line with a Multibyte
Character Set would have been mangled. This has been fixed.
================(Build #3349 - Engineering Case #669235)================
When starting the QAnywhere Agent (qaagent) with the command line option
"-qi", the MobiLink Listener and the MobiLink Client processes
were not also launched with "-qi" options, resulting in system
tray icons on Windows Mobile devices. This has been corrected.
================(Build #3303 - Engineering Case #662456)================
On a Windows Mobile device, the QAnywhere Agent (qaagent) would have sometimes
given the following error messages at start up:
E. 2011-03-14 08:33:50. Error registering with DBLSN code: -1
The error message was displayed in a message box, even when qaagent was
executed in quiet mode. This has been fixed. Now, qaagent is more tolerant
to dblsn slowness at startup. Also, a message box is not displayed when
qaagent is executed in quiet mode (-q or -qi), and the message is logged
in the qaagent console and log file.
================(Build #3391 - Engineering Case #676505)================
Under rare, timing dependent conditions, the Relay Server may have reported
a fatal error "RSF11016: Freeing already freed memory block in shared
memory". The Relay Server's shared memory manager would have protected
itself from this illegal operation and continued to operate normally. This
error may have occurred right after RSE2000, RSE3008 or Relay Server shutdown.
This has been fixed by eliminating the redundant freeing.
================(Build #3384 - Engineering Case #675317)================
Under extreme load conditions, the Relay Server may log errors on shared
memory operations. This logging operation may have crashed the web server
worker process. Also, for 12.x Relay Servers, the line label for such logging
has the format of <pricessId.threadId.ShmDebug>. The threadId could
have been wrong. Both of these problem have now been fixed.
================(Build #3376 - Engineering Case #674187)================
A web server worker thread may have crashed when it failed to load the localized
language resource (e.g dblge12.dll). The reasons for the failure may have
included the file not being found due to path and registry info, or the account
associated with the worker did not have permission to read the resource.
The symptom was a truncated log line with a missing end-of-line. This has
been fixed so that the crash will no longer occur and an unlocalized error
message is displayed regarding the loading error.
================(Build #3376 - Engineering Case #674120)================
A web server worker may have crashed when logging lengthy debug messages
that had not been localized. This has been fixed.
================(Build #3364 - Engineering Case #672213)================
The Relay Server may have become unrecoverable due to continuous errors from
the shared memory manager when one of the backend servers had been serving
more that four types of clients. This has been fixed so that a hard limit
of 1600 client types is in effect. When the new limit is reached, a graceful
error will be reported without affecting the rest of the requests.
================(Build #3345 - Engineering Case #668791)================
When the Relay Server Outbound Enabler failed a backend connection test,
it may have crashed, or have been unable to recover even after the backend
became available again. This has been fixed.
================(Build #3332 - Engineering Case #666845)================
The Relay Server admin and monitor extensions may have slowly leaked memory.
Eventually, admin or monitoring requests would have failed without any trace
in the HTTP error log, IIS access log, or in the Relay Server log. This problem
has been fixed so that recycling is no longer necessary. To workaround this
problem, users may setup application pool recycling for the admin and monitoring
extension.
================(Build #3327 - Engineering Case #664284)================
The Relay Server Outbound Enabler would have stopped discovering Relay Servers
after the last Relay Server was disabled from a server farm. The Outbound
Enabler would have become unusable until restarted. This is fixed so that
the Outbound Enabler will now attempt to discover new Relay Servers at the
rate specified by the existing Outbound Enabler -d switch.
================(Build #3323 - Engineering Case #663171)================
The Relay Server may not have responded to HTTP GET requests for non-relay
purposes. For example, using a browser to visit the rs_admin extension would
have resulted in a connection drop without a response. A load-balancer trying
to test the Relay Server service via the rs_server extension, would also
have resulted in a connection drop without a response regardless of the status
of the relay service. This has been fixed so that a useful response is now
provided when HTTP GET requests are issued against various Relay Server extensions.
================(Build #3315 - Engineering Case #661112)================
It was possible for synchronizations to fail if any of the 'certificate_name',
'certificate_company', or 'certificate_unit' parameters were supplied, even
though the value of these parameters matched the corresponding field values
in the server's certificate, if they were encoded as Unicode in the server's
certificate. This has been corrected.
================(Build #3314 - Engineering Case #664283)================
Relay Server enable/disable events were not broadcast to connected Outbound
Enablers. For example, disabling the last Relay Server from a Relay Server
farm was not going to suffer the issue described in Engineering case 664284,
but when adding a Relay Server to the Relay Server farm, it would also not
have woken up the Outbound Enablers to start utilizing the new Relay Server.
The user workaround is to restart the Outbound Enabler. This problem has
been fixed.
================(Build #3314 - Engineering Case #664139)================
When a Relay Server starts up, its description was logged and the startup
verbosity was applied properly, but those values were not stored correctly
for later consumption. Such as for the admin tool to export the configuration
or for the next configuration update to properly determine if an updated
was required. This problem has been fixed.
================(Build #3311 - Engineering Case #663936)================
On Unix systems, the second field in the Relay Server's log, which is the
thread ID, may shown a negative number. The type used to store the thread
ID value was not big enough on Unix systems, as thread IDs tend to be large,
and could have overflowed. This has now been fixed.
================(Build #3308 - Engineering Case #663261)================
The Relay Server Outbound Enabler on MacOS may have failed to receive all
download data from the backend server. If Relay Server for Apache was used,
then it would have appended a 500 HTTP error page to the data, which most
likely would have caused client failure. This has now been fixed.
================(Build #3306 - Engineering Case #663061)================
Proxy support for the Relay Server Outbound Enabler may only have worked
with HTTPS against some HTTP 1.1 proxy servers. The down channel using HTTP
instead of HTTPS would have connected successfully at first but then would
have been dropped by the proxy after a period of being idle. This problem
is proxy specific and it does not affect all HTTP proxy environments. This
problem has been fixed in the Relay Server so that an update to the Outbound
Enabler is not required (see Engineering case 662749). The workaround is
to use HTTPS, or apply the Outbound Enabler fix from case 662749.
================(Build #3305 - Engineering Case #662749)================
Proxy support for the Relay Server Outbound Enabler may only have worked
with HTTPS against some HTTP 1.1 proxy servers. The down channel using HTTP
instead of HTTPS would have connected successfully at first but then would
have been dropped by the proxy after a period of being idle. This problem
is proxy specific and is does not affect all HTTP proxy environments. This
problem has been fixed in the Outbound Enabler so that HTTP will now also
work. The workaround is to use HTTPS.
================(Build #3300 - Engineering Case #661849)================
When using the Service utility (dbsvc) to start a Relay Server service with
a large configuration on a slow machine, it may have reported startup errors
while the service was still in the pending start state. A fix was made to
the Relay Server to correct this problem.
================(Build #3298 - Engineering Case #660995)================
When connected to a Relay Server, and no Outbound Enabler providing the backend
service had connected yet, the connection was expected to timeout within
the application timeout time specified by the client. However on IIS7, some
J2SE http clients may have become stuck writing to a server that was no longer
reading and eventually failed the write and then perform a delayed internal
retry without processing the response sent by the web server. This change
modifies the Relay Server to provide the expected fail fast experience according
to the timeout against such J2SE clients.
================(Build #3291 - Engineering Case #658710)================
When the Relay Server was being reconfigured, a crash may have occurred in
the rs_client.dll, and all http requests served by the same worker process
would have failed. The web server would then have replenished the worker
pool and the Relay Server would have continued to operate with the new configuration.
The issue is highly timing sensitive and is very difficult to reproduce.
This crash has now been fixed.
================(Build #3284 - Engineering Case #655574)================
The integrated Outbound Enabler library was not being unloaded correctly
when the Mobilink server shutdown. The library eventually unloaded when the
MobiLink server executable exited and no bad side effects where observed
as a result, but this condition is now fixed.
================(Build #3283 - Engineering Case #656716)================
The Relay Server could have leaked heap memory under the following conditions:
- On the response to the first HTTP request in the session, or specifically,
anytime a cookie was set, if the response was long and came in small packets.
- A small number of bytes were leaked on Upchannel and Dnchannel creation.
This has been fixed.
================(Build #3282 - Engineering Case #657026)================
The MobiLInk server would immediately refuse to startup, if it could not
make any connections to the consolidated database, even when it was running
as a Windows service.
This behaviour has changed so that the MobiLink server will retry to make
connections, when it is running as a Windows services. The retries are once
a minutes for ten minutes. If it still cannot make a connection after that,
it will refuse to startup.
================(Build #3267 - Engineering Case #652382)================
The Relay Server did not work with a Relay Server Outbound Enabler (RSOE)
that was behind an HTTP 1.0 proxy. The Relay Server has now been fixed to
adapt to HTTP version downgrades done by an HTTP 1.0 proxy, and is needed
when working with a 12.0.1 RSOE in conjunction with a HTTP 1.0 proxy.
================(Build #3278 - Engineering Case #655989)================
Sybase Central would have crashed whenu attempting to open a Relay Server
configuration file which was zero-length, or that contained only whitespace.
This has been fixed.
================(Build #3273 - Engineering Case #654244)================
On some Chinese Windows systems, the fields for entering the MAC address
for back end servers was too narrow to see both digits of each byte of the
address. This has been fixed.
================(Build #3353 - Engineering Case #670360)================
The SQL Anywhere synchronization/replication components, including the MobiLink
client (dbmlsync) and SQL Remote (dbremote), could have given the error 'No
off-line transaction log file found and on-line transaction log starts at
offset XXXXX'. This would have occurred:
1) if no transaction-logs-directory was given on its command line; and
2) if the length of the transaction log name including its absolute path
was greater than 128 bytes.
This problem is now fixed and the length of the transaction log name plus
its absolute path has been extended to 1024 bytes.
================(Build #3341 - Engineering Case #668425)================
The MobiLink client now prints information about the operating system and
machine architecture on which it is running to the log. It also prints the
platform for which the executable was compiled. This is similar to what
the MobiLink server and the database server already do.
================(Build #3303 - Engineering Case #662639)================
When a SQL Anywhere database is used as a remote database, the MobiLink client
(dbmlsync) generates a remote ID which is a GUID for the database during
the first synchronization. This remote ID is used by the Mobilink server
to identify the remote. MobiLink keeps a list of synchronizing remotes in
the ml_database table. When a blank padded SA database was used as a remote,
a remote ID would have been generated during the first synchronization,
sent to the MobiLink server and stored in the ml_database table. On all
subsequent synchronizations, a blank padded version of the remote id would
then have been sent. The results of this were:
1) The server would not have been recognized on the second sync that the
same remote was synchronizing and would treat the second sync as a first
sync. That is to say the server would not have used state information it
had from the first sync when processing the second. Third and subsequent
sync's were not affected. This would have had no impact unless the first
synchronization had failed.
2) Two entries would have been made in the ml_database table for each remote.
One would contain the blank padded remote id and the other would contain
the unpadded id.
This behaviour has now been fixed. Now, on first synchronization the remote_id
assigned to the remote database will be blank padded.
================(Build #3298 - Engineering Case #650856)================
Synchronizations using HTTP-based communication protocols (including HTTP,
HTTPS and other encrypted HTTP protocols) could have failed intermittently.
When synchronizations failed, they would do so after the download had been
applied and committed, and would have reported an error message like: "Data
read failed. Requested 2 bytes but got 0 bytes." When this occurred
the MobiLink server would have reported the error: "Connection was dropped
due to lack of network activity". These failures were only likely to
occur when applying the download to the remote database took longer than
the stream timeout interval, which is 4 minutes by default. This problem
has now been resolved
================(Build #3278 - Engineering Case #655955)================
Several memory leaks have been fixed in the MobiLink Client.
================(Build #3278 - Engineering Case #655953)================
Several memory leaks have been fixed in the MobiLink client. These leaks
would primarily affect applications using the dbmlsync API.
================(Build #3272 - Engineering Case #653930)================
The Console utility could have stopped refreshing database and/or server
properties after changing the set of properties which were displayed, even
after it was restarted. The problem was sensitive to the speed with which
properties were selected or unselected. This has been fixed.
================(Build #3263 - Engineering Case #651692)================
When a plug-in failed to load on startup, other plug-ins may then not work
correctly. This has been fixed.
================(Build #3326 - Engineering Case #665837)================
The changes for Engineering case 661112 introduced a bug where the MobiLink
client could have crashed, or the check of the certificate_name, certificate_company,
or certificate_unit could have failed, if any of the certificate fields were
encoded as Unicode in the server's certificate. This has been fixed.
================(Build #3275 - Engineering Case #650719)================
After a failed download, an attempt to restart the download may have failed
and reported a "Protocol Error" or a read failure. This has been
fixed.
================(Build #3376 - Engineering Case #674250)================
When the MobiLink Server ran against a consolidated database running on Microsoft
SQL Server, the MobiLink server could have reported the following error message:
[-10002] Consolidated database server or ODBC error: ODBC: [Microsoft][SQL
Server Native Client 10.0][SQL Server]
Cannot drop the table '#elbat_yraropmet_ymmud_a_si_siht', because it
does not exist or you do not have permission.
(ODBC State = 42S02, Native error code = 3701)
This error would have occurred in one of the following situations:
1) a deadlock was detected during upload;
2) an error occurred in a trigger that was defined on an upload table; or
3) the 'XAXT_ABORT' option was set to 'ON' in one of the user-defined scripts.
This problem is fixed now.
================(Build #3354 - Engineering Case #669465)================
The MobiLink server could have crashed when handling restartable downloads
and the restartable download cache was too small to hold all possible restartable
downloads at one time. This has been fixed.
================(Build #3301 - Engineering Case #662072)================
When deploying a Synchronization Model with conflict resolution to a SQL
Anywhere or Sybase IQ database, the SQL generated to create a global temporary
table checked twice for an existing table. Although this did not cause any
errors, the generated SQL has been fixed so that it now only checks once
for an existing table before creating a global temporary table.
================(Build #3289 - Engineering Case #658453)================
When using MobiLink synchronization and timestamp-based downloads with an
Oracle Real Application Cluster (RAC) system, there is a chance of missing
rows to be downloaded if the clocks of the Oracle cluster nodes differ by
more than the time elapsed between the MobiLink server fetching the next
last download timestamp and fetching the rows to be downloaded. This problem
is unlikely on a RAC system with synchronized node clocks, but the likelihood
increases with larger node clock differences. A workaround is to create either
a modify_next_last_download_timestamp or modify_last_download_timestamp script
to subtract the maximum node clock difference.
Note that at least since version 10i, Oracle has recommended using Network
Time Protocol (NTP) to synchronize the clocks on all nodes in a cluster,
and NTP typically runs by default on Unix and Linux. With cluster nodes properly
configured to use NTP, their clocks should all be within 200 microseconds
to 10 milliseconds (depending on the proximity of the NTP server). Since
Windows Server 2003, the Windows Time Service implements the NTP version
3 protocol and it runs by default. Also, as of version 11gR2, Oracle Clusterware
includes the Oracle Cluster Time Synchronization Service (CTSS) to either
monitor clock synchronization or, if neither NTP or Windows Time Service
is running, it will actively maintain clock synchronization. However CTSS
and Windows Time Service are less accurate than NTP,
To avoid missing rows when Oracle RAC node clocks differ by up to one second
more than the time between fetching the next_last_download_timestamp and
the rows to be downloaded, now the MobiLink server will subtract one second
from the next_last_download_timestamp fetched from the consolidated database,
if
1) the Oracle account used by the MobiLink server has execute permission
for SYS.DBMS_UTILITY,
2) the consolidated database is an Oracle RAC system,
and (only for MobiLink version 12.0.0 and up)
3) there is no generate_next_last_download_timestamp script.
For Oracle RAC node clocks that may differ by greater amounts, you can avoid
the problem by defining a generate_next_last_download_timestamp, modify_next_last_download_timestamp
or modify_last_download_timestamp script to compensate for the maximum node
clock difference.
================(Build #3286 - Engineering Case #657869)================
If the MobiLink Server's memory use grew more than 4GB in less than 5 minutes,
the TRACKED_MEMORY ppv value would have been incorrect. As a consequence,
for all 12.0.1 platforms and non-Windows 12.0.0 platforms, the MobiLink server
cache could have erroneously shrunk and not recovered. This has been fixed.
A work around is to use a larger -cinit option value, and if the problem
persists to disable dynamic cache resizing by specifying the same value for
-cmax and -cmin.
Also, on 12.0.0 for Windows, the cache could have failed to stabilise.
This has also been fixed.
================(Build #3277 - Engineering Case #655780)================
The method MLResultSet.getBigDecimal(L/java/lang/String;) unnecessarily threw
a 'method not supported' exception. This has been fixed.
================(Build #3273 - Engineering Case #653183)================
The NUM_CONNECTED_SYNCS ppv metric and the "Synchronizations",
"Started Synchronization Rate", "Synchronizations Started",
and "Unknown Connected Clients" metrics incorrectly considered
syncs that had failed during the download and were waiting to be restarted
as being connected and so would show an incorrect value in the log or in
the SA Monitor. Also, as a consequence, the server would prompt for confirmation
to kill active syncs during hard shutdown even if all the syncs in the system
are waiting to be restarted. This has been fixed.
================(Build #3265 - Engineering Case #652263)================
The usage text for the Relay Server Outbound Enabler didn't describe what
were the valid options for the -cr option. This has been corrected so that
the values are now listed for the tcp options, server certificate options,
and client certificate options.
In addition, http authentication options, proxy options, and proxy authentication
options, have been added in version 12.0.1.
================(Build #3153 - Engineering Case #660428)================
The MobiLink server could have crashed during shutdown if user spawned Java
threads printed to System.out or System.err after the ShutdownListeners were
notified of shutdown. This has been made much less likely to happen. A work
around is to ensure all user threads are stopped before the ShutdownListeners
return.
================(Build #3344 - Engineering Case #668612)================
The MobiLink Replay utility (mlreplay) could have crashed when synchronizing
unsigned big integers using the Replay API. This has been fixed.
================(Build #3315 - Engineering Case #664140)================
Sometime the MobiLink Listener (dblsn) could have taken a few minutes to
shutdown if the shutdown was initiated by the QAnywhere Agent (qaagent).
This problem has been fixed.
================(Build #3311 - Engineering Case #663629)================
When replaying a recorded protocol file more than once with the same client
without using the –ap option, all replay sessions after the first would have
failed due to a progress mismatch warning received from the MobiLink server
(this is expected). However, the error message that appears in the MLReplay
log in this situation does not make it clear that the problem will disappear
if the –ap option is used. So, the MobiLink Replay utility has been changed
so that when it receives an unexpected progress mismatch from the MobiLink
server, an error message saying so is logged, which points the user to use
the –ap option.
================(Build #3292 - Engineering Case #657721)================
There was a memory leak in the iAS ODBC driver for Oracle. The memory leak
would have occurred when an application tried to make a connection but the
ODBC driver was not able to obtain a valid database connection. This problem
has now been fixed.
================(Build #3284 - Engineering Case #657397)================
When the consolidated database was running on an Oracle server, the MobiLink
server could have displayed the error: 'ORA-00001: unique constraint ...
violated' and then refused further synchronization requests. This would have
occurred when the MobiLink server schema in the consolidated database was
upgraded from a version earlier than 11.0.0, and the synchronization request
was for a new MobiLink user and/or MobiLink remote database.
This problem has been fixed in the upgrade scripts for Oracle.
The following steps can be used to correct the problem if the Oracle consolidated
database had already been upgraded with the old upgrade scripts:
1) Shut down all MobiLink servers;
2) Execute the SQL file against the Oracle consolidated database with the
following command line:
sqlplus LoginID/Password@TNSServerName @%SQLANY12%\MobiLink\Upgrade\fix_ora.sql
Replace the LoginID, Password, and TNSServerName in the above command line
with your own login information.
================(Build #3387 - Engineering Case #675805)================
It is possible, although rare, for the machine.config file to contain multiple
registered SQL Anywhere ADO.NET providers. When unregistering, the SetupVSPackage.exe
utility only removed one SQL Anywhere ADO.NET provider from the machine.config
file. This problem has been fixed so that SetupVSPackage.exe now looks for
all registered SQL Anywhere ADO.NET providers.
================(Build #3359 - Engineering Case #671397)================
The following Entity Framework datetime functions were not mapped to SQL
Anywhere functions:
AddDays, AddHours, AddMicroseconds, AddMilliseconds, AddMinutes, AddMonths,
AddSeconds, AddYears, DiffHours, DiffMicroseconds, DiffMilliseconds, DiffMinutes,
DiffMonths, DiffSeconds, DiffYears.
For example:
Entities db = new Entities();
var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays(
x.OrderDate, DateTime.Now ) > 100 );
string trace = ( ( ObjectQuery ) query ).ToTraceString();
This problem has been corrected by adding new function handlers for mapping
Entity Framework datetime functions to the SQL Anywhere functions 'DATEADD'
and 'DATEDIFF'.
================(Build #3347 - Engineering Case #669227)================
On systems running Windows Vista or later, when using the Visual Studio Add
Connection wizard the SQL Anywhere .NET provider listed USER DSNs only in
the ODBC Data Sources drop-down list. The SYSTEM DSNs are omitted. This problem
has been corrected. The SetupVSPackage tool must be run to install this fix.
It should be noted that on 64-bit Windows, only the 64-bit SYSTEM DSNs are
listed (after this correction). Any 32-bit SYSTEM DSNs are not displayed.
In Visual Studio 2008's design environment (which is 32-bit on 64-bit platforms),
the Test Connection button will attempt to establish a connection using the
32-bit equivalent of the 64-bit DSN. If the 32-bit DSN does not exist, the
test will fail.
================(Build #3342 - Engineering Case #667672)================
The Entity Framework function 'DiffDays' was not mapped to the SQL Anywhere
function 'Days'.
For example:
Entities db = new Entities();
var query = db.SalesOrders.Select( x => x ).Where( x => EntityFunctions.DiffDays(
x.OrderDate, DateTime.Now ) > 100 );
string trace = ( ( ObjectQuery ) query ).ToTraceString();
This problem has been fixed.
================(Build #3341 - Engineering Case #668141)================
Calling the method SATcpOptionsBuilder.ClientPort could have caused the exception
InvalidCastException to have been thrown.
For example:
SATcpOptionsBuilder options = new SATcpOptionsBuilder( "localonly=yes;port=6873"
);
string cport = options.ClientPort;
This problem has been fixed.
================(Build #3340 - Engineering Case #667762)================
SetupVSPackage.exe would have failed to add some dlls to the Global Assembly
Cache on 64 bit Windows systems. This problem has been fixed.
Also, a new command line option 'salocation' (or 'saloc') has been added
to SetupVSPackage to allow specifying the SQL Anywhere install location.
If 'saloc' is specified, SetupVSPackage will use it to locate the necessary
dlls. If 'saloc' is not specified, SetupVSPackage will use SQL Anywhere registry
keys to locate the dlls.
================(Build #3337 - Engineering Case #667441)================
Misleading error messages would have been returned to the client when opening
a connection using an invalid DSN. This problem has been fixed.
================(Build #3328 - Engineering Case #667927)================
The SQL Anywhere .NET Provider, running in 64-bit mode, might have inadvertently
attempted to load a 32-bit language resource DLL (e.g., dblgen12.dll) and
failed with an error. This problem has been corrected.
================(Build #3310 - Engineering Case #663470)================
On CE devices, if multiple applications were running simultaneously, the
library dbdata.dll could have been deployed multiple times to the temp directory.
This problem has been fixed.
Additionally, the version number has been added to the native dll name (i.e.
dbdata12.dll). This will allow running multiple versions of the provider
simultaneously on Windows CE.
================(Build #3299 - Engineering Case #661459)================
The .NET provider was incorrectly assuming that a Sybase IQ 12.7 server supported
the NCHAR datatype. This resulted in a failure to establish a connection
to a Sybase IQ 12.7 server. This problem has been fixed.
================(Build #3286 - Engineering Case #657542)================
The results of an Entity DAta Model query could have been non-deterministic.
For example, having a GridView with the properties "AllowPaging"
and "AllowSorting" set to "True", would have returned
a "Result is non-deterministic" warning (SQLCODE 122). This has
been fixed by adding an ORDER BY clause to the generated SQL.
================(Build #3280 - Engineering Case #656481)================
An application using the ADO .Net provider, and calling the method SAConnection(),
could not have successfully connected to an IQ 12.7 server. A run-time error
(iAnywhere.Data.SQLAnywhere.SAException) would have occurred when the provider
tried to parse the server version string. This problem has been resolved.
================(Build #3276 - Engineering Case #654446)================
If there were multiple applications running simultaneously, the ADO.NET provider
could have failed to load dbdata.dll. This has now been fixed.
================(Build #3384 - Engineering Case #675293)================
If an initial connection was made to a blank-padded database, and the connection
was redirected because of the NodeType connection parameter, the connection
would have incorrectly failed with the error "Database cannot be started
-- ???". If the LogFile connection parameter was used to get more information,
the generated file would have contained the line "Communication function
i_cs_ProtocolErrorP code 0". This has been fixed.
================(Build #3352 - Engineering Case #670185)================
If a client was attempting to connect over TCP/IP to a server that had just
shut down, it is possible that the connection would have returned a SQLE_CONNECTION_ERROR
error rather than a SQLE_SERVER_NOT_FOUND. This has been fixed.
================(Build #3344 - Engineering Case #668603)================
In rare cases, an application could have failed to connect because of a TCP/IP
communication link failure. No specific reason for the failure would have
been logged to the file specified by the LOGFILE connection parameter. This
has been fixed.
Note, this problem affected the .Net provider, the ODBC, JDBC and OLEDB
drivers as well.
================(Build #3297 - Engineering Case #660204)================
Specifying a TCP timeout value of more than 2147 seconds could have caused
connection failures. This has been fixed.
================(Build #3294 - Engineering Case #659643)================
An application could have crashed if it was attempting an Integrated Login
or Kerberos connection and the connection to the server was lost. This could
have occurred if the server was stopped or terminated during the connection.
This has been fixed.
================(Build #3376 - Engineering Case #671099)================
When the ODBC driver ware loaded, part of its initialization involved loading
and initializing the system TCP/IP libraries, even in cases where TCP/IP
would not be used (eg. creating or viewing a DSN through the Data Source
utility). This could have caused delays or problems with some firewall software.
This has been fixed so that the TCP/IP libraries are now only loaded and
initialized when they will be used.
Note, this change also affect the other SQL Anywhere client libraries as
well, i.e. DBLib, OLEDB, ADO.NET, etc.
================(Build #3372 - Engineering Case #669581)================
If an application attempted to perform a wide or batched insert, and the
application did not bind or set enough parameters to match the number of
parameters within the prepared INSERT statement, and the wide insert or batch
insert size was greater than 1, then the application would have crashed.
This problem has now been fixed.
================(Build #3364 - Engineering Case #672184)================
If an application attempted to perform a wide insert using the SQL Anywhere
ODBC driver, or a batched insert using the SQL Anywhere JDBC driver, then
there was a very small chance the application would crash if the system was
low on memory or under stress. This problem has now been fixed.
================(Build #3286 - Engineering Case #657826)================
When using the Microsoft ODBC Data Source Administrator, a crash may have
resulted if an encrypted password had been specified and the "Test Connection"
button was used. This has been fixed.
================(Build #3267 - Engineering Case #652752)================
When starting dbisqlc, or an ODBC application with a connection string containing
LINKS=TCPIP, if there is an error connecting the connection dialog is displayed.
It was incorrectly defaulting to "connect to a running database on another
computer", losing the LINKS=TCPIP setting. If TCP parameters were specified,
such as LINKS=TCPIP(PORT=2638), then it worked correctly. This has now been
fixed.
================(Build #3309 - Engineering Case #662896)================
When using the OLEDB provider, if a statement was prepared, executed, and
then the ADO MoveFirst() (OLE DB RestartPosition() ) method was called when
the cursor type was forward-only, the statement would have become unprepared.
Subsequent attempts to execute the prepared statement would then have failed.
This problem has been corrected.
================(Build #3291 - Engineering Case #658887)================
The OLE DB DBSCHEMA_FOREIGN_KEYS rowset returned the following indicated
integer values for the UPDATE_RULE or DELETE_RULE referential actions.
CASCADE 0
if referential action is NULL 1
SET NULL 2
SET DEFAULT and RESTRICT 3
These values, derived from the ODBC SQLForeignKeys result set, did not match
the following OLEDB constants defined for these referential actions.
DBUPDELRULE_NOACTION = 0x0
DBUPDELRULE_CASCADE = 0x1
DBUPDELRULE_SETNULL = 0x2
DBUPDELRULE_SETDEFAULT = 0x3
Furthermore, the DBSCHEMA_FOREIGN_KEYS rowset should have returned strings
rather than integers for the UPDATE_RULE or DELETE_RULE referential actions.
The OLE DB specification states:
If a rule was specified, the UPDATE_RULE or DELETE_RULE value is one of
the following:
"CASCADE" — A <referential action> of CASCADE was specified.
"SET NULL" — A <referential action> of SET NULL was specified.
"SET DEFAULT" — A <referential action> of SET DEFAULT was
specified.
"NO ACTION" — A <referential action> of NO ACTION was specified.
Providers should return NULL only if they cannot determine the UPDATE_RULE
or DELETE_RULE. In most cases, this implies a default of NO ACTION.
Also, the fix for Engineering case 620136 did not handle the situation when
there was no declared Primary Key in the primary table but there were table
or column (not nullable) Unique Constraints that permitted the addition of
foreign keys.
These problems have been fixed. The Upgrade utility should be used to update
the OLE DB schema rowset support in any database used with ADO, ADOX or OLE
DB.
================(Build #3266 - Engineering Case #651383)================
As of the changes for Engineering case 633120, a SQL query producing multiple
result sets was not handled correctly by the SQL Anywhere OLE DB provider.
This problem has now been corrected. The cursor is no longer closed after
the first result set is processed.
================(Build #3390 - Engineering Case #676364)================
The version of zlib used by the SQL Anywhere and MobiLink clients and servers
contained security vulnerabilities documented under US CERT Vulnerability
notes VU#680620 and VU#238678. These are fixed in zlib version 1.2.3. SQL
Anywhere and MobiLink clients and servers now use zlib version 1.2.5.
Links:
http://www.kb.cert.org/vuls/id/680620
http://www.kb.cert.org/vuls/id/238678
================(Build #3376 - Engineering Case #674262)================
When 64 bit versions of SQL Anywhere, MobiLink or the Relay Server were installed,
and none of the corresponding 32-bit features were installed (which is the
default feature selection), the Start menu shortcuts to dblang.exe ("Change
language to <language>") would not have worked. This has been
fixed.
================(Build #3367 - Engineering Case #672577)================
If the PATH environment variable placed earlier versions of SQL Anywhere
before version 12.0 in the path, then newdemo.bat would have launched earlier
versions of SQL Anywhere utilityes, but used the version 12 Scripts folder.
This may have resulted errors if the earlier version did not support the
same SQL language that was used by the scripts in the Scripts folder. This
problem has been fixed. The newdemo.bat file will now reference the tools
explicitly by their path.
Note, the newdemo.bat file is referenced by the SQL Anywhere documentation
whenever it is desirable to start with a newly initialised version of the
demonstration database.
================(Build #3365 - Engineering Case #672739)================
A number of edits have been made to the SQL Anywhere server, the MobiLink
server and UltraLite error messages to improve readability and to make the
wording more consistent with the SQL Anywhere documentation. These changes
include minor grammatical corrections, and changes to enforce consistency
with hyphens and capitalization. No changes were made to SQLCODE, SQLSTATE,
or ODBC error states for any of these messages.
================(Build #3364 - Engineering Case #669747)================
On Linux systems, when installing the SQL Anywhere Monitor EBF, the installer
would have removed the old copy from the samonitor_oldXX directory after
migrating samonitor.db. This behavior was different from 12.0.0 EBFs which
would always have left the old copy in the samonitor_oldXX directory. This
has been fixed.
================(Build #3364 - Engineering Case #661180)================
On Linux systems, if the SQL Anywhere Monitor EBF was installed as a non-root
user, and the SQL Anywhere Monitor service had been started by the root user,
the following error messages would have been displayed:
Migrating SQL Anywhere Monitor database
Connecting...
Can't connect to source database.
[Sybase][JDBC Driver][SQL Anywhere]Specified database not found
Rolling back files in /opt/samonitor12 ...
wc: ./.ebf_20110601-1149/samonitor.db: Permission denied
Cleaning up ...
This has been fixed so that the following error message is now displayed:
The setup program was unable to stop a running instance of SQL Anywhere
Monitor.
Please stop it manually and run the setup program again.
A workaround is to stop the SQL Anywhere Monitor service manually, then
re-run the EBF installer.
================(Build #3359 - Engineering Case #668771)================
When building a Deployment wizard install MSI, and select Chinese (ZH) as
the deployment language. progress messages would have been displayed in English.
This has been corrected so that they are now displayed in Chinese.
================(Build #3355 - Engineering Case #669408)================
On Unix, if SQL Anywhere was installed into the default location as user
A, logging in as user B and checking for updates would have failed with an
error like, "Could not check for updates." The installed.ini file
only had read and write permissions for the current user and group. This
has been fixed by giving broader permissions on the file so it could be used
by "other" users.
================(Build #3354 - Engineering Case #668766)================
When creating a 64-bit Deployment wizard MSI install, containing both 64-bit
and 32-bit software, only one set of Sybase Central plugins would have been
registered when installing on a 64-bit system. This has been corrected so
that both 32-bit and 64-bit plugins are now registered.
================(Build #3353 - Engineering Case #668768)================
After uninstalling a Deployment wizard .MSI install made with default contents,
several .JPR files would have been left behind in the SQL Anywhere 12\java
directory.
This has been fixed so that these files are now correctly uninstalled.
================(Build #3348 - Engineering Case #669407)================
When uninstalling on Solaris, it was possible to see an error like:
find: stat() error /opt/sybase/sqlanywhere12/sun/jre160/lib: no
such file or directory
This has been fixed. It should be noted that despite the error, the uninstaller
would have completed successfully.
================(Build #3345 - Engineering Case #668765)================
When running the Deployment Wizard, clearing the default MSI name in the
Destination Path page of the wizard and clicking the Next button would have
caused an unhandled exception. This occurred due to the fact that the filename
was not valid. This has been corrected by graying out the Next button if
the filename is left blank.
================(Build #3321 - Engineering Case #665004)================
When trying to connect using the Ruby DBI interface, the driver did not raise
an error if the username/password was invalid. Instead it silently failed.
This has been fixed.
================(Build #3301 - Engineering Case #669009)================
When upgrading from 12.0.0 to 12.0.1, if the 12.0.0 samples had been installed
to a non-default location, the upgrade to 12.0.1 installed any new or reorganized
samples to the default sample location. This has now been fixed.
Note that 12.0.1 EBFs can be now applied directly to 12.0.0 installations
- effectively performing an upgrade. Therefore if a 12.0.0 installation
has not yet been upgraded to 12.0.1, use of a 12.0.1 EBF with this fix will
avoid this problem. If a 12.0.0 installation had been upgraded with a build
without this fix, uninstalling the product will not remove all the sample
files. Those files will need to be removed manually.
================(Build #3298 - Engineering Case #661242)================
A silent install of SQL Anywhere Monitor in which the location of the database
(DIR_SQLANY_MONITOR) was not specified, would have caused the database to
be installed to %SystemDrive%\CommonDocFolder. This has been fixed so that
the correct default location is now used (%ALLUSERSPROFILE%\Documents\SQL
Anywhere Monitor 12).
================(Build #3298 - Engineering Case #661188)================
The 64-bit UltraLite ODBC driver (Bin64\ulodbc12.dll) was not being correctly
registered. This would have resulted in the failure of Interactive SQL and/or
Sybase Central to load an UltraLite database. The has been fixed.
Alternatively, the driver can be registered manually using the following
command:
regsvr32.exe %SQLANY12%\Bin64\ulodbc12.dll
================(Build #3295 - Engineering Case #660190)================
The folder names under %SQLANYSAMP12%\UltraLiteJ\Android\CustDB used mixed
case and in some cases were incorrect in the GA release of 12.0.1. This
caused Eclipse to fail when building the sample. This has been fixed such
that future remastered releases will use the correct case. However, EBF
installs will not fix these incorrect folder names. A workaround is as follows:
Before attempting to build the sample in Eclipse, ensure that the sub-directory
names are as show below. Note that all names are lower case and that hyphens
(-) should be used, not underscores (_), where applicable.
libs
res
src
libs\armeabi
res\drawable-hdpi
res\drawable-ldpi
res\drawable-mdpi
res\layout
res\menu
res\values
src\com
src\com\sybase
src\com\sybase\custdb
================(Build #3281 - Engineering Case #659357)================
Running the Deployment wizard when SQL Anywhere had been installed to directory
with a path containing multi-byte characters would have caused the generation
of the MSI to fail with an error like: "C:\Syç¾ç½²\SQL Anywhere 12\bin32\dblib12.dll
(Not Found)". This has been fixed.
================(Build #3403 - Engineering Case #678259)================
A SQL Anywhere http procedure call may, on rare occasions, have caused the
server to crash. This has been fixed.
================(Build #3402 - Engineering Case #677515)================
Running REORGANIZE TABLE on a table with foreign key indexes when the database
was under heavy update/delete load, had a chance of corrupting the table.
Specifically, the indexes on the table would have contained more values then
the table itself. This has been fixed.
================(Build #3402 - Engineering Case #677251)================
If an embedded SQL application or a stored procedure first opened a READ
ONLY cursor on a simple SELECT query qualifying for optimizer bypass, and
later opened an UPDATE cursor for the same query, a positioned update to
the second cursor could have failed with SQLCODE -192 ("Update operation
attempted on non-updatable query"). This has been fixed.
For the error to occur in version 11, the first cursor would need to be
explicitly declared FOR READ ONLY, because FOR UPDATE is the default (c.f.
documentation for DECLARE CURSOR statement). In version 12.0.0 and later,
cursor updatability depends upon cursor type (c.f. documentation for SELECT
and PREPARE statements) but defaults to FOR READ ONLY for ESQL.
================(Build #3402 - Engineering Case #671017)================
In a certain virtual machine implementation, CPU topology detection (which
is performed at server startup) could spin consuming 100% of a single logical
CPU. The VM software had bugs which reported CPU information to the guest
operating system in a manner that does not meet Intel's specifications. Changes
have now been made so that SQL Anywhere can tolerate the bugs in the VM software
without affecting correct CPU detection in other nvironments.
================(Build #3401 - Engineering Case #677962)================
When a database was shut down (for example, as part of server shutdown) and
the database was a high availability mirror or a read-only scale-out copy
node, the server could have hung in rare timing dependent cases. If the server
was hung due to this problem, there would have been messages like the following
in the server console:
A write failed with error code: (6), The handle is invalid.
Fatal error: disk full when writing to "???"
This has been fixed.
================(Build #3401 - Engineering Case #665212)================
Statements using user-defined functions eligible for inlining could have
failed unexpectedly. This problem could have affected databases created with
earlier versions and reloaded to a version 12 database if such databases
contained views referencing inlinable user-defined functions. Such databases
could have failed to be reloaded. This has now been fixed.
================(Build #3400 - Engineering Case #677803)================
If an invalid certificate was encountered by the server running on the Mac,
the error reported may have been "Error parsing certificate file, error
code 0". This has been fixed, the error code should have been non-zero
if an error occurred.
Note, this problem also affected SQL Anywhere clients running on the Mac.
================(Build #3399 - Engineering Case #677327)================
In some cases, SQL Anywhere HTTP procedures and the HTTP server would have
failed to process received chunked mode transfer encoded data when the chunk
length meta-data contained leading zeros. This has been fixed.
================(Build #3396 - Engineering Case #676210)================
Execution of a SET REMOTE OPTION would have failed if the value of the setting
was larger then 256 bytes. This was due to the schema of the ISYSREMOTEOPTION
table which has a 255 byte limit on the length of the settings column. The
server has been changed to provide a more appropriate error message.
================(Build #3395 - Engineering Case #672573)================
Using either mixed case or upper case when specifying the ".dll"
portion of the assembly name in a CLR external environment procedure, could
have caused the external environment to fail to run the specified method
within the assembly. For example, an external name clause like:
external name 'MyTest.DLL::MyNameSpace.MyTestClass.MyMethod() int'
would have failed to execute MyNameSpace.MyTestClass.MyMethod, but an external
name clause like:
external name 'MyTest.dll::MyNameSpace.MyTestClass.MyMethod() int'
would successfully find and execute MyMethod. This problem has been fixed.
Note that a workaround is to simply lower case the ".dll" portion
of the assembly name.
================(Build #3394 - Engineering Case #675326)================
When run on a Windows Mobile device, the server could have crashed if the
"Authentication parameters" field in an existing "SYNCHRONIZATION
PROFILE" was modified. This has now been fixed.
================(Build #3393 - Engineering Case #674559)================
1) In a read-only scale out environment, if a copy node was automatically
added (no CREATE MIRROR SERVER statement was executed), but the database
server was restarted and used a different TCP/IP address or port, it would
have failed to connect properly to other mirror servers. This has been fixed
so that copy node servers and primary servers that have this fix will automatically
continue to be able to connect if the copy node's TCP/IP address or port
changes the first time the copy node connects.
2) If an ALTER MIRROR SERVER statement was executed to adjust a copy node's
connection string, that copy node may have temporarily failed to connect
properly to other servers. This has also been fixed.
================(Build #3392 - Engineering Case #676664)================
After the changes for Engineering case 661663, passing an invalid certificate
to a web procedure (i.e. CREATE FUNCTION ... URL '...' CERTIFICATE '...')
may have caused the server to crash when the procedure was executed. This
has been fixed.
================(Build #3392 - Engineering Case #676015)================
Queries involving spatial predicates over an indexed geometry column may
have failed to select a plan that used the spatial index if the table was
very large (several gigabytes at least). This has been fixed.
================(Build #3391 - Engineering Case #676495)================
1. A copy node can now act as an arbiter for the database it is copying in
a high-availability system with mirroring. The arbiter and both partners
must be running the updated software to take advantage of this change. As
before, a partner cannot act as arbiter for its own database. When defining
the arbiter to refer to a copy node, use an arbitrary mirror server name
for the arbiter that does not match the server name of any of the database
servers in the HA system. The name of the arbiter mirror server isn't actually
used for connecting. For example:
CREATE MIRROR SERVER "scaleout_child" AS COPY connection_string
= 'server=scaleout_child;host=winxp-2:6878';
CREATE MIRROR SERVER "TheArbiter" AS ARBITER connection_string
= 'server=scaleout_child;host=winxp-2:6878';
Note that there is no database server in the HA system that is running with
the server name "TheArbiter": it is just being used as a placeholder
in the mirror server definitions to hold the connection string for the arbiter.
2. Copy nodes could have reported a log mismatch error in certain cases
involving a failure of both the primary server and the arbiter. This problem
has been fixed.
3. There was a race condition that could have allowed an arbiter server
to create two separate internal states for the same mirroring system. This
problem has been fixed.
================(Build #3388 - Engineering Case #676007)================
The server would have failed to rename the request log correctly if the option
RequestLogNumFiles was set to 1. This has been fixed.
================(Build #3388 - Engineering Case #674917)================
Under rare conditions, the server could have crashed when processing queries
with intra-query parallelism. This has been fixed.
The crash can be worked around by disabling intra-query parallelism by setting
the database option MAX_QUERY_TASKS=1.
================(Build #3385 - Engineering Case #644908)================
After an ALTER TABLE statement, some views may have been incorrectly marked
as INVALID. The problem only occurred for views in which the altered table
occurs multiple times in the logical expansion of the view definition. This
has been fixed.
================(Build #3384 - Engineering Case #671906)================
When processing an UPDATE statement, the server could have constructed erroneous
values for the OLD table that would have been created for AFTER ROW or AFTER
STATEMENT triggers. This could have lead to incorrect results if the AFTER
trigger referenced these values, or could have resulted in the statement
failing with an SQL error. The problem would have occurred if and only if
the following conditions hold:
1) The UPDATE statement modifies a table that had a primary key, UNIQUE
constraint, or unique index.
2) The UPDATE statement modified a column included in the primary key, UNIQUE
constraint, or unique index, such that the new value matched a value already
existing in the index.
3) The modified table had an AFTER ROW or AFTER STATEMENT trigger
This problem has been corrected.
================(Build #3382 - Engineering Case #674782)================
If a server involved in a high availability mirroring system had active TLS
connections, the server may have hung indefinitely due to a thread deadlock.
This has been fixed.
================(Build #3382 - Engineering Case #674753)================
In rare, timing depending cases, a primary, mirror or copy node server could
have hung while shutting down. This has been fixed.
================(Build #3381 - Engineering Case #674704)================
If a directory access server was queried, and one of the files was owned
by a user that did not exist on the system where the server was running,
then the server would have crashed. This problem has now been fixed.
================(Build #3381 - Engineering Case #674537)================
Simple INSERT statements referencing a table with an article defined with
a non-empty WHERE and/or SUBSCRIBE BY clause could have occasionally failed
with a "Column not found" error for the column referenced in either
WHERE or SUBSCRIBE BY clause. Re-execution of the same INSERT would, in most
cases, have succeeded with no error. This has been fixed.
================(Build #3380 - Engineering Case #674550)================
Calling the system function WRITE_CLIENT_FILE could have incorrectly resulted
in the error "Client library reported a permissions error accessing
object ('<FILENAME>') during transfer" if there were multiple
READ_CLIENT_FILE or WRITE_CLIENT_FILE calls in a batch, procedure, or function
referring to the same client file name. This could have happened if the client
executed a batch or procedure, which in turn called other functions or procedures
which ended up doing multiple READ_CLIENT_FILE or WRITE_CLIENT_FILE calls
during the execution of the batch or procedure that was executed by the client.
This has been fixed by explicitly closing the file at the end of the function
call. The file was previously closed at the end of the request.
================(Build #3379 - Engineering Case #673173)================
The fix for Engineering case 661622 missed the situation where a subselect
that referenced two tables from the main query block, and was equated to
a constant, could also have caused the server to fail an assertion or crash
.
For example:
Select *
from T1, T2
where 10 = (select e1 from R where p(R,T1, T2) ) and ..
This has now been fixed.
================(Build #3377 - Engineering Case #674582)================
The server would have crashed when inserting several values lower then MIN_DBL
(about 1e-306, which is the smallest double which can be stored in normalised
format) which still can be stored using denormalized double values. This
was fixes by forcing all of the denormal double values to be rounded down
to zero.
================(Build #3377 - Engineering Case #674320)================
After a MANUAL or AUTO REFRESH text index was renamed, it may not have been
found by subsequent statements. This has been fixed.
Note that restarting the database server eliminates the problem
================(Build #3375 - Engineering Case #674027)================
When using read-only scale-out and the NodeType=COPY parameter, the connection
may have been incorrectly redirected to a parent node or a node which had
a higher load than the current node. Also, in very rare timing depending
cases with concurrent clients connecting with NodeType=COPY, the server could
have crashed. These problems have now been fixed.
================(Build #3375 - Engineering Case #673704)================
In very rare circumstances, the histogram cleaner could have caused the server
to crash. This has now been fixed.
================(Build #3371 - Engineering Case #673844)================
The server may have crashed while attempting to log a deadlock error between
connections. For this to have happened, the Log_deadlocks option needed to
have been set to 'on', and at least one of the connections that was participating
in the deadlock needed to be executing a query that had a parallel plan.
There are two possible workarounds:
1) Turn off intra-query parallelism by setting the Max_query_tasks option
to 1, or
2) Set the Log_deadlocks option to 'off'
This problem has been fixed.
================(Build #3371 - Engineering Case #673212)================
1) If one TCP/IP address for one partner server in the partner/mirror/primary
server connection string in the MIRROR SERVER or -xp configuration was correct,
but the TCP/IP address for the other mirror partner server was incorrect,
it was possible for the primary server to have skipped performing checkpoints
indefinitely. This could only occur with the incorrect TCP/IP address configuration
and if the mirror servers contained the fix for Engineering issue 660851.
This has been fixed so that the primary server checkpoints normally.
2) If a High Availability or read-only scale-out server failed to connect
to another server, there may not have been any indication of the failed connect.
This has been fixed by logging a message to the console for each failed connection.
3) A High Availability or read-only scale-out server may have displayed
the message "... recovery n% complete" where n was a number less
than zero or much greater than 100. This has been fixed.
================(Build #3369 - Engineering Case #675686)================
The server may have failed assertion 101412 - "Page number on pages
does not match page requested", if the database/connection option 'chained'
was set to 'off'. This has been fixed.
================(Build #3369 - Engineering Case #673014)================
When a SQL Anywhere ROOT service processes a request and queries its HTTPServiceName
connection property, its name "root" is appended to the first path
element (if one is present). This has been fixed. The HTTPServiceName for
a ROOT service is always "root".
================(Build #3369 - Engineering Case #672879)================
If a High Availability partner or copy node encountered a problem (such as
the log file being inconsistent compared to the partner or parent), it would
have shutdown the problem database. If the same server was also running one
other database (other than the database that was mirrored or a participating
in read-only scale-out) the server may have also incorrectly shutdown. This
has been fixed so that the mirror server or copy node server will only shutdown
the server if the only database running is the problem database.
================(Build #3369 - Engineering Case #672858)================
The server could have crashed if a table was being dropped at the same time
as a proxy table was being created. This has been fixed.
================(Build #3365 - Engineering Case #672430)================
In very rare situations, the server may have hang on shutdown, if while in
the process of shutting down the option MaxMultiProgrammingLevel was increased.
This has been fixed.
================(Build #3365 - Engineering Case #665184)================
The server would have incorrectly returned the error "XPath parser error:
syntax error at or before character 0 <--" if a stored procedure
contained a SELECT statement with an openxml clause that used a variable
for the xpath string. This has been fixed.
================(Build #3364 - Engineering Case #672207)================
When attempting to use the IS [NOT] DISTINCT FROM predicate in a query that
involved proxy tables the server would have failed the query with a strange
"unknown node type" error. This problem has now been fixed and
the IS [NOT] DISTINCT FROM predicate can now be used with proxy tables.
================(Build #3363 - Engineering Case #672077)================
Executing a query that joined two or more External Environment result sets
could have caused the server to crash if the join resulted in a very large
result set. This problem has now been fixed.
================(Build #3363 - Engineering Case #672076)================
When inserting a string literal value into a time or timestamp column of
a proxy table, if the string literal contained more than 3 digits of precision
within the fractional seconds portion of the time/timestamp value, then the
fractional seconds would have been truncated to 3 digits of precision. This
problem has now been fixed.
Note that this fix only applies to ODBC based Remote Data Access servers.
The fractional seconds precision will still be truncated to 3 digits of precision
for JDBC based Remote Data Access servers.
================(Build #3363 - Engineering Case #671911)================
The system function OPENSTRING allows a text file to be parsed and interpreted
as a relational table. The schema for OPENSTRING can be explicitly specified
or can be provided by means of an existing database table. If a remote (IQ
or other proxy) table was used to specify the OPENSTRING schema then the
server can behave erratically, including crashing. This problem has now been
resolved.
================(Build #3361 - Engineering Case #671711)================
The changes for Engineering case 624047 could have caused a server running
high availability mirroring, or a read-only scale-out copy node, to fail
assertion 200131. The failure was timing dependent, and required accessing
an empty table with an index from a read-only connection. This has been fixed.
================(Build #3360 - Engineering Case #659138)================
In exceptionally rare cases, the server may have crashed if two procedure
debuggers had been attached to a database and one of them disconnected while
a new connect request for a user to debug was being executed. This has been
fixed.
================(Build #3360 - Engineering Case #655524)================
A MERGE statement on a table that had a column with DEFAULT AUTOINCREMENT
would have increased the autoincrement value for every matching row independently
of whether the value had already been used for an INSERT or not. This behaviour
has been improved so that the server only generates a new autoincrement value
if the matching branch is an INSERT and the value will be used.
================(Build #3357 - Engineering Case #670990)================
If the number(*) function was used in the VALUES clause of an INSERT statement,
then the server would have returned a non-fatal assertion error 106103. This
has been fixed so that the correct error is now returned.
================(Build #3356 - Engineering Case #670896)================
An "HTTP 404 Not Found" error could have occurred from a web service,
if the database that contained that web service was not started at the same
time the server was started. This could have happened if the database was
started via an ODBC DSN, or with the "START DATABASE" statement.
The problem did not occur when the name of the database file was specified
on the command line when starting the server. It also would not occur if
the database name was specified when calling the web service. This has been
fixed.
================(Build #3356 - Engineering Case #670866)================
The following query would have incorrectly returned a 1 indicating the date
string was acceptable:
select isdate('1234+')
While the following query failed with a runtime error indicating the date
string was not acceptable:
select date('1234+')
This problem has been fixed. The "isdate" query now returns 0.
At a minimum, the timezone indicator (+) must be followed by hours. For
example, '2011+5' is acceptable.
Also, if a date string contained a timezone offset of "+" or "-"
and was followed by the Z (Zulu) timezone indicator (e.g., '1234-12-31+Z'),
no error was diagnosed. This has been corrected.
================(Build #3356 - Engineering Case #670838)================
In rare timing dependent cases, if a High Availability mirror server was
in the process of taking over as the primary, it could have failed. The 201120
assertion failure could have been logged to the console log. This problem
could only have affected servers containing the fix for Engineering issue
663964. This has been fixed.
================(Build #3355 - Engineering Case #669965)================
A database server using web services could have crashed in very rare situations
when an HTTP connection was shutdown. This has been fixed.
================(Build #3354 - Engineering Case #670486)================
In exceptionally rare cases, the server could have crashed when executing
a non-parallel query that contains a hash join. The crash would only have
occurred if all of the following conditions were true:
- the probe input of the hash join had already consumed a lot of memory
for hash tables
- a child of the hash join returned an error
- a hash based parent query node of the hash join needed to allocate memory
for the hash table and is restricted by the memory governor, so that it had
to acquire memory from other hash based query nodes.
This problem has been fixed.
================(Build #3354 - Engineering Case #670403)================
When a database was shut down (for example, as part of server shutdown) and
the database was a high availability mirror or a read-only scale-out copy
node, the server could have hung in rare timing dependent cases. If the
server was hung due to this problem, there would have been messages like
the following in the server console:
A write failed with error code: (6), The handle is invalid.
Fatal error: disk full when writing to "???"
This has been fixed.
================(Build #3353 - Engineering Case #669448)================
When performing a backward index scan (a rare occurrence) while there were
heavy concurrent updates to the index, there was a small chance that the
server could have made a comparison to a random value with unpredictable
results. This has been fixed.
================(Build #3352 - Engineering Case #670202)================
In rare timing dependent cases, a primary, mirror or copy node server could
have crashed or hung.
Also in rare timing dependent cases, partner servers starting for the first
time could have fail to have chosen a primary after the changes for Engineering
case 663964.
These problems have been fixed.
================(Build #3352 - Engineering Case #669633)================
The SQL Anywhere Server provides a system procedure sa_refresh_materialized_views()
that can be used to refresh all currently stale materialized views. Invoking
the procedure with an argument value of 0 would have caused an error to be
reported if at least one of the materialized views failed to be refreshed.
This procedure is invoked by the reload script generated by the Unload utility
when executed with the "-g" command line switch. This problem has
now been resolved.
================(Build #3351 - Engineering Case #647802)================
The server may have failed assertion 106104 "field unexpected during
compilation" for queries containing correlated subselects in the WHERE
clause. The WHERE subselect predicate must have been of the form "T.X
= (subselect referencing R.Y)" where R.Y was an outer reference. This
has now been fixed.
================(Build #3349 - Engineering Case #669431)================
When attempting to cancel a Remote Data Access request to an ODBC based remote
server, there was a very small chance that the server would have become unresponsive
if all three of the following was true:
- the local server was running on a Windows based system
- the local server had a restricted (or small) number of CPUs or cores
(either due to the limitations of the server machine or VM, or as a result
of using the -gt or -gtc command line option)
- the remote server was not defined to utilize the new "driver=SQL
Anywhere Native" feature
This problem has now been fixed.
================(Build #3347 - Engineering Case #668989)================
In rare timing dependent cases, a transaction which was successfully committed
on a primary server could have been lost. In order for there to have been
a chance of this occurring, all of the following needed to be true:
- the application was connected to a primary server that lost quorum (the
server lost the connection to both the mirror and arbiter servers)
- the application stayed connected to this server (the old primary server)
even though the network connection to other servers dropped
- the application was in the middle of committing a transaction between
the time that the old primary server lost its connection to the mirror and
arbiter server, and when the old primary server restarted as the new mirror
server because it lost quorum
- the old mirror server took over as the new primary (the mirror server
must have been able to connect to the arbiter server for this to occur)
This has been fixed so that the application may now receive the new error
for this situation, "The transaction may not be committed because the
primary server lost quorum."
================(Build #3346 - Engineering Case #663056)================
In exceptional rare situations the server could have crashed or failed assertions
106808, 100913, or 111706 if very long property values are queried. This
has been fixed by truncating property values to the max varchar length of
32000 bytes.
================(Build #3343 - Engineering Case #664702)================
Queries using the spatial cast function TREAT( type1 AS type2 ) could have
failed to return a syntax error when it was used incorrectly, and instead
could have returned meaningless result sets. This has been fixed.
================(Build #3342 - Engineering Case #659608)================
When making an external environment call, if the external environment procedure
made a server side request that ended up leaving a cursor on a temporary
table open, then the server could have crashed when the connection was closed.
This problem has now been fixed.
================(Build #3341 - Engineering Case #668109)================
Attempting to start two High Availability partner servers without state files
(for example, starting them for the first time) could have, in rare timing
dependent cases, failed to have one server start as the primary. If this
occurred, one partner started as the mirror, and the other partner server
looped indefinitely attempting to determine which role it should take. This
has been fixed.
Also, if a mirror server was in the middle of taking over as the primary
when it was shutdown, the database shutdown could have hung until any remaining
connections were disconnected. This has been fixed.
================(Build #3340 - Engineering Case #667930)================
In rare situations, the server could have crashed when generating or updating
a histogram for a string column. This problem has been corrected.
================(Build #3340 - Engineering Case #667901)================
If an application connected via jConnect and then subsequently attempted
to use the {} JDBC escape sequence when making a stored procedure call, then
there was a chance the server would have returned an incorrect "variable
@p0 not found" error at the time the stored procedure statement or result
set was closed. This problem has now been fixed.
================(Build #3340 - Engineering Case #667900)================
If the Transact-SQL ROWCOUNT option was used to limit the number of rows
returned by a cursor, the cursor may have skipped the first row in the result
set in some cases. This incorrect behaviour only occurred for queries in
which optimization was bypassed, and the plan contained a SortTopN operator,
rather than a RowLimit operator. This incorrect behaviour was introduced
as part of the fix for Engineer case 653706, and has now been fixed.
================(Build #3339 - Engineering Case #667686)================
If an application attempted to cancel or drop a connection that was in the
process of making a connection-scoped external environment call, then there
was a very small chance the server would have crashed. This problem has now
been fixed.
================(Build #3339 - Engineering Case #660691)================
When accessing a directory or file using a Directory Access Server, if the
name of the directory or file contained a multi-byte character where one
of the bytes in the character was 0x5C, then the Directory Access Server
would have failed to find the directory or file. This problem has now been
fixed.
================(Build #3338 - Engineering Case #667518)================
When merging recent data distribution information into a table's histogram,
the server could have allocated up to one database page worth of data outside
of the database cache and then failed to free the memory. The leak could
eventually have caused the server to fail due to a lack of memory on 32-bit
platforms, or due to lack of swap space on 32-bit or 64-bit platforms. This
has now been corrected.
================(Build #3338 - Engineering Case #667001)================
If a stored procedure or a user defined function with the hidden definition
appeared on the stack when an error occurred, subsequent call to the TRACEBACK
function could have returned the statements from the hidden definition. This
has been fixed so that the output of the TRACEBACK function now contains
the string '<hidden>' instead of the statements from the hidden procedures
or user defined functions.
================(Build #3336 - Engineering Case #667316)================
When unloading a database, the server would have incorrectly output a "dynamic
result sets" clause for non-external environment procedures in the reload.sql
file. This problem has now been fixed and the "dynamic result sets"
clause is now only output for external environment procedures.
There are a few points of note:
1) this problem would only have occurred with stored procedures that were
created using an older SA 12.0.1 server
2) this fix will only affect new procedures that are created
3) the existence of the "dynamic result sets" clause for non-external
environment procedures is in fact a no-op and does not affect performance
or behaviour of the non-external environment procedure.
================(Build #3336 - Engineering Case #667314)================
If more than one connection attempted to install or remove Java external
environment objects at the same time, then there was a chance the server
would have crashed or failed assertions. This problem has now been fixed.
================(Build #3335 - Engineering Case #667142)================
In very rare timing dependent cases, the server could have crashed when a
database was stopping. Also in rare cases, it was possible for an automatically
started database to not automatically stop when there where no longer any
connections to it. Both of these problems have now been fixed.
================(Build #3332 - Engineering Case #661440)================
In rare cases, the server may have crashed while performing DDL and DML operations
concurrently. This has been fixed.
================(Build #3331 - Engineering Case #666639)================
The detection of processor geometry (number of physical processors, cores
and threads) was incorrect for certain Intel x86/x64 processors, including
the Intel Xeon E5405. The server would have detected all cores and threads
as belonging to a single physical processor. This problem has been corrected.
================(Build #3328 - Engineering Case #666182)================
An HTTP request over a persistent keep-alive connection to a SQL Anywhere
HTTP server may have failed if a previous request on that connection had
sent an unexpected body. This has been fixed.
For HTTP methods other than POST, the body may be retrieved using HTTP_VARIABLE('TEXT')
or HTTP_VARIABLE('BODY') as dictated by the Content-Type. An HTTP POST method
is assumed to have a Content-Type of application/x-www-form-urlencoded unless
otherwise specified (as with any other HTTP method, alternate Content-Types
may be accessed using HTTP_VARIABLE('TEXT') or HTTP_VARIABLE('BODY')).
================(Build #3328 - Engineering Case #665657)================
The problems described here affect Windows CE 5.x kernels only. Note that
Windows Mobile 6 platforms use the Windows CE 5.x kernel.
With version 11.x, the server was not able to create a cache larger than
32MB. Attempting to do so would have caused the error "Not enough memory".
With version 12.x, the server would have automatically and erroneously restricted
the cache size to a size smaller than 32MB.
The default maximum cache size was erroneously restricted to a value less
than 32MB.
The "percentage" notation for cache sizes (eg, "-c 50p")
erroneously based the percentage on a value that was less than 32MB, rather
than the total system memory as documented.
These problems have been corrected.
================(Build #3328 - Engineering Case #665630)================
Upgrading a database that had been created with the -dba switch (to set the
DBA username and password) could have failed. This has been fixed.
================(Build #3328 - Engineering Case #662419)================
A mirror node in a mirroring system could have failed to recover its database
if the database used sequence generators, and the primary and mirror roles
switched between the
servers. This has been fixed so that servers can now recover logs that exhibit
this problem.
================(Build #3327 - Engineering Case #666011)================
When a root server was committing and sending log pages to a copy node, the
root server could have experienced poor performance. Root servers which had
frequent commits, and copy nodes running on slow computers or connected through
high latency connections, would have shown the most noticeable poor performance.
This has been fixed so that the performance of the copy node latency will
have a smaller affect on the root node by using the equivalent of asynchronous
log page synchronization.
When using the "SET MIRROR OPTION synchronization_mode = '<value>'"
statement, where <value> was asynchronous or asyncfullpage, the server
was incorrectly treating this as a synchronous synchronization. This has
been fixed as well.
================(Build #3326 - Engineering Case #665799)================
On Windows systems, a minidump might not have been generated under certain
circumstances. This has been fixed.
================(Build #3326 - Engineering Case #665665)================
The server could have crashed when increasing the CurrentMultiProgrammingLevel
using the system procedure sa_server_option() if there wasn't enough memory
available. This has been fixed.
================(Build #3326 - Engineering Case #661622)================
Execution of a query with a subselect predicate correlated on two different
tables from the main query block may have caused an assertion failure in
the server. This has now been fixed
For example:
Select *
from T1, T2
where T1.X = (select e1 from R where p(R,T1, T2) ) and ..
The predicate "T1.X = (select e1 from R where p(R,T1, T2) )" has
a subselect and references both tables T1 and T2 from the main query block.
================(Build #3326 - Engineering Case #635353)================
The server could have hung when a connection disconnected, or was dropped.
This was more likely to have occurred if the server was under heavy load.
This has been fixed.
================(Build #3325 - Engineering Case #665684)================
If an application attempted to establish a Remote Data Access connection
to an ASE server, and that connection request failed over to a different
ASE server, then the Remote Data Access connection request would have failed.
This problem has now been fixed.
================(Build #3324 - Engineering Case #665524)================
An exclusive table lock on a non-transactional global shared temporary table
could have caused the server to crash on subsequent INSERT, UPDATE or DELETE
statements. This has been fixed.
All conditions must have been met (non-transactional, shared global temp
table,
and LOCK TABLE WITH EXCLUSIVE) for the crash to have occurred. If any of
these three can be relaxed, the crash will be avoided.
================(Build #3324 - Engineering Case #665522)================
The attachment specified by the attachname parameter of the system procedure
xp_sendmail() may not have been received properly by the recipient's mail
client. This has been fixed.
================(Build #3324 - Engineering Case #661066)================
If a range of values was supplied for the TCP/IP option ClientPort, connection
attempts may have been slow if the server was not found, or if multiple hosts
were supplied for the Host option. This has been fixed.
================(Build #3323 - Engineering Case #665325)================
When validating a database using the VALIDATE statement or the Validation
utility (dbvalid), the operation could not have been cancelled. This has
been fixed.
================(Build #3319 - Engineering Case #661036)================
Activity executing on the utility_db could have caused a crash, memory corruption,
or other unpredictable behaviour, if the cache were to shrink at the same
time. This problem has been fixed.
================(Build #3317 - Engineering Case #664695)================
In rare situations, the server could have erroneously reported the error
"Not enough memory" at startup. This problem has been corrected.
================(Build #3317 - Engineering Case #664490)================
Cancelling a query that referenced spatial functions could have caused the
server to crash, although the probability was exceedingly small. This has
been fixed.
================(Build #3315 - Engineering Case #664348)================
In very rare timing dependent cases, the server could have crashed or hung
on shutdown if there were active client requests during shutdown. The databases
would have already been stopped before the failure, so there was no chance
of data loss. This has been fixed.
================(Build #3315 - Engineering Case #664292)================
In rare situations, the server could have crashed if a log truncation or
rename (dbbackup -x or -xo or -r) took place while the server was processing
a large number of transactions, especially long-running transactions. This
has been fixed.
No workaround for this problem is known, except to avoid performing log
truncation or renaming when the server is handling large numbers of inserts,
updates or deletes.
================(Build #3314 - Engineering Case #664247)================
If the system procedure sa_get_user_status() was run on a database with an
extremely high number of user definitions, the procedure would have blocked
DDL statements and could not have been cancelled until its result had been
materialized. This has been fixed.
================(Build #3314 - Engineering Case #663940)================
In very rare cases, a spatial query that applied one of the following methods
to a complex geometry value may have returned an incorrect result, or an
error:
1. all set operations: ST_Union, ST_Intersection, ST_Difference, ST_SymDifference
2. certain aggregation functions: ST_UnionAggr, ST_IntersectionAggr
3. certain spatial predicates: ST_Intersects, ST_Overlaps, ST_Within, ST_Disjoint,
ST_Touches, ST_Crosses, ST_Contains, ST_Relate
This has been fixed.
================(Build #3311 - Engineering Case #663596)================
Attempting to insert a variable of type long binary, varchar or nvarchr into
a proxy or IQ table that had been generated using the REPEAT() function could
have caused an incorrect value to be inserted. It should be noted that this
problem would only have occurred if the fix for Engineering case 662000 had
already been applied. This problem has now been fixed.
================(Build #3309 - Engineering Case #663459)================
Attempting to autostart a database server on Windows CE when one was already
running was incorrectly giving the error:
"Unable to start specified database: server exit code -11728"
(where the number could vary).
This has been fixed to return the correct error:
"Database server already running"
Note that on Windows CE only one database server can be running at a time,
even if when attempting to start a second server with a different name.
================(Build #3309 - Engineering Case #659115)================
The server may have crashed if a query block contained an alias definition
and the expression of the alias used columns that could be folded as a constant,
(in the example below, alias v011 can be folded as a constant if column T2.a2
was created as NOT NULL), and the alias name was used in a subselect of the
query block and in the GROUP BY clause of the query block.
For example:
select if T2.a2 is null then 99999 else 11111 endif as v011,
(select count(*) from T1 where T1.a1 = v011) as c
from T2,T3
where T2.a2 = T3.a3
group by v011
This has been fixed.
================(Build #3306 - Engineering Case #663259)================
The Remote Data Access feature is now capable of loading the SQL Anywhere
ODBC driver directly. If a remote server is defined similar to the following:
CREATE SERVER remote-server CLASS 'saodbc' USING 'driver=SQL Anywhere
Native;...'
where the the USING clause contains the key pair "driver=SQL Anywhere
Native", and the remainder of the USING clause provides all the connection
parameters necessary to successfully connect to the remote SQL Anywhere server,
then the remote data access layer will load the SQL Anywhere ODBC driver
directly and bypass the Windows ODBC Driver Manager on Windows based platforms
and the SQL Anywhere ODBC Driver Manager on UNIX platforms. The benefit to
loading the SQL Anywhere ODBC driver directly is that, although the ODBC
driver still needs to be installed, it no longer needs to be registered if
it is only being used for the remote data access support. What's more, if
there are multiple copies of the ODBC driver installed, then loading the
ODBC driver directly will guarantee that the ODBC driver for the current
server version gets used rather than one that was registered with a previous
version of SQL Anywhere. It should be noted that if the application also
makes use of non-SQL Anywhere remote servers or if there are SQL Anywhere
remote servers defined without the "driver=SQL Anywhere Native"
key pair, then the remote data access layer will still use a Driver Manager
for those other remote servers.
================(Build #3305 - Engineering Case #663283)================
The server may have chosen less that optimal plans for queries with predicates
of the form 'T.X=(unknown expression)' if an index on T(X) existed. The
'(unknown expression)' could have been, for example, a variable whose value
was not used for queries inside the procedures, or could have been a complex
expression (i.e. "R.Y+1"). This has now been fixed.
================(Build #3305 - Engineering Case #661663)================
For each outgoing HTTPS web procedure connection, a small amount of memory
was leaked which could eventually have lead to memory exhaustion. This has
been fixed.
================(Build #3303 - Engineering Case #662025)================
In some cases, the server would have displayed recovery progress messages
incorrectly when recovering a large transaction log. In this situation, either
no messages would have been displayed or an incorrect percentage would have
been displayed. This has been fixed.
================(Build #3303 - Engineering Case #661633)================
Execution of an "UPDATE ... PUBLICATION ... WHERE .." statement
with a complex WHERE clause may have caused the server to crash. This has
been fixed.
================(Build #3302 - Engineering Case #662452)================
Attempting to start a connection-scoped external environment, and then canceling
the start request before the external environment completed the startup process,
could have caused the server to crash. This problem has now been fixed.
================(Build #3302 - Engineering Case #661193)================
Atempting to call a Java external environment stored procedure or function
with a very long binary or string input argument, could have taken a very
long time to execute. This problem has now been fixed.
================(Build #3301 - Engineering Case #662000)================
Attempting to insert a variable of type LONG BINARY into a proxy could have
taken a very long time, even though the variable was only a few megabytes
in length. This problem has been resolved and the performance of inserting
LONG BINARY variables into proxy tables has been greatly improved. Note that
this fix also improves the performance of inserting LONG VARCHAR and LONG
NVARCHAR variables into proxy as well.
================(Build #3300 - Engineering Case #660851)================
When a primary server lost its connections to both the mirror and arbiter
servers as a checkpoint was performed, the database on the primary may not
have been recoverable. Typically, it would fail assertion 100904. This
has been fixed.
Similarly, in cases where a primary server lost its connections to both
the mirror and arbiter servers as a checkpoint was performed, the next time
the primary and mirror servers were connected and attempt to synchronize,
the mirror server may have in rare situations reported "Database "<name>"
mirroring: database is not compatible with primary; files must be replaced"
and then stop with the message "Database server shutdown due to incompatible
files for database mirroring". This has been fixed to reduce the possibility
of this occurring. It is possible for this to still occur, so then the database
running on the current primary must be manually copied or backed up to the
mirror server so that the server can successfully synchronize again.
The primary server could have hung, again in rare situations, if only one
of the two connections between it and the mirror server was dropped, for
example due to a liveness timeout. This has been fixed.
When the mirror server was becoming the primary server there was a small
possibility it could have hung after reporting it was starting a checkpoint
and then reporting it was recovering. This has been fixed.
================(Build #3299 - Engineering Case #661453)================
If the distance parameter of the proximity search condition contained letters,
the server could have silently failed, and returned some result, instead
of reporting an error. This has been fixed.
For example, the following query would not report an error and would behave
as if the
full text query was 'apple NEAR[2] oranges':
SELECT *
FROM t CONTAINS( 'apple NEAR[ 2b ] oranges' )
Note that the following query was correctly reporting an error:
SELECT *
FROM t CONTAINS( 'apple NEAR[ b ] oranges' )
================(Build #3298 - Engineering Case #661034)================
Under rare conditions, the server could have hung while executing a query
with multiple GROUP BY clauses. This may have occurred when the workload
executing on the server suddenly changed (i.e. if many requests arrived almost
simultaneously). This has been fixed. A workaround is to disable intra-query
parallelism for the affected query (SET TEMPORARY OPTION MAX_QUERY_TASKS=1).
================(Build #3297 - Engineering Case #660629)================
When connected to an ASE 15.5 server and attempting to make a remote request
to SQL Anywhere, there was a chance the request would have failed with an
"unkown token 35" error. This problem has now been fixed.
Note that this problem only affected remote requests from ASE to SQL Anywhere.
The problem did not affect making remote requests from SQL Anywhere to ASE
via Remote Data Access.
================(Build #3297 - Engineering Case #660446)================
Performing a backup with a TRANSACTION LOG RENAME would have caused read-only
connections to the database on the mirror server to be dropped. This has
been fixed.
================(Build #3297 - Engineering Case #658330)================
Execution of an INSERT ON EXISTING UPDATE statement, with CASCADE as the
foreign key update option, would have resulted in a foreign key constraint
violation error when updating values which were logically the same, but had
different physical representation. For example, in case insensitive database
changing 'EMPLOYEE' to 'employee'. This has been fixed.
================(Build #3296 - Engineering Case #660432)================
Creating a variable with an initial value specified as a host variable did
not give a syntax error in some cases. This has been fixed.
================(Build #3296 - Engineering Case #660248)================
If an application connected via jConnect or Open Client and made an external
environment call that returned a result set, then the server may have crashed.
This problem has now been fixed.
================(Build #3296 - Engineering Case #659870)================
Empty string values indexed by an IMMEDIATE text index were not counted towards
the total number of documents indexed, unless more than one column was indexed
and the value in at least one of the columns was neither an empty string
nor NULL. This problem caused scores for full text queries to be lower then
they should have been if all the documents were correctly counted. Additionally,
a memory leak could have occurred in this situation. This has been fixed.
Note, if a text index was created or updated using a server with this problem,
it may be necessary to rebuild the index with an updated server if problems
are encountered with the index.
================(Build #3295 - Engineering Case #660235)================
On Windows Vista and later operating systems, whenever a new server executable
had to be launched in order to autostart a database, launching the executable
may have failed when a relative path to the server executable was specified.
For example, dbspawn mybin\dbsrv12.exe -n myserver my.db, or using "...;start=mybin\dbsrv12.exe..."
in a connection string, could have fail to launch the server executable.
This problem has been fixed.
================(Build #3295 - Engineering Case #660211)================
In rare circumstances, calling the system procedures sa_locks, sa_describe_shapefile,
st_geometry_dump, sa_list_cursors, or sa_mirror_server_status, could have
caused the server to crash, or could have caused unpredictable behaviour.
The problem was more likely to have occurred when small cache sizes were
used. This problem has been fixed.
================(Build #3295 - Engineering Case #660194)================
Execution of a query on a Directory Access proxy table with a WHERE clause
that contained a predicate of the form "file_name = variable",
may have sometimes run very slowly while running very quickly most other
times. This problem has now been fixed such that the query performance is
now consistently fast from one run to the next.
================(Build #3295 - Engineering Case #660057)================
If a foreign key was created with both MATCH and CHECK ON COMMIT clauses,
and the database subsequently required recovery, recovery would have failed
when replaying the statement from the transaction log. This has been fixed.
================(Build #3295 - Engineering Case #652949)================
The trigger operation condition 'UPDATE( {column-name} )' did not return
TRUE if the column value had been changed by a previously running BEFORE
UPDATE row-level trigger only. This has been fixed.
================(Build #3295 - Engineering Case #652244)================
An internal unload/reload (i.e. dbunload -ii) that encountered a SQL error
could have hung or caused a subsequent unload/reload on the same server to
hang. This problem has been fixed.
================(Build #3294 - Engineering Case #659804)================
If a proxy table or proxy procedure was defined with variables in the AT
clause, then the AT clause would have been incorrectly truncated if the length
of the AT clause after variable expansion was greater than the length of
the original AT clause. This problem has now been fixed.
================(Build #3294 - Engineering Case #659639)================
When making a Java external environment call, if the stored procedure had
an argument of type char (note that this is a single char value rather than
a java.lang.String), and a NULL value was passed in for the char argument,
then the server would have failed the request with a Java NullPointerException.
It should be noted that the Java VM would have continued to run in this situation
and the connection was still able to make subsequent Java external environment
calls. This problem has now been fixed such that passing a NULL char value
to a Java external environment call will result in a char with zero value
being passed down to the Java method. Again, it should be noted that this
problem does not affect passing NULL string values to java stored procedures.
================(Build #3294 - Engineering Case #659631)================
If an application enlisted a connection within a DTC transaction and then
subsequently attempted to perform a DTC commit on the transaction after explicitly
unenlisting it first, then the application would have hung until the server
was shut down. This problem has now been fixed and the commit request will
now immediately fail as expected.
================(Build #3294 - Engineering Case #659370)================
Inlining of simple functions could have generated unexpected errors or incorrect
results. For incorrect results to have occurred, the caller of the function
had to have variables defined with the same names as the inlined function.
This has been fixed.
================(Build #3294 - Engineering Case #613299)================
Queries involving indexes could return incorrect results, and using tools
such as the Validate Database Wizard in Sybase Central, or the Validation
utility, could have reported index corruption when there was in fact none.
For this to have occurred, the index must not have been unique and there
must be many consecutive rows with the same indexed value. This has been
fixed.
================(Build #3292 - Engineering Case #658985)================
Unexpected deadlocks could have occurred when using the UPDLOCK hint at isolation
level 3. For example, if two transactions issued the statements
SELECT t.c FROM t WITH (UPDLOCK) WHERE t.pk = 1
UPDATE t SET c = 2 WHERE t.pk = 1
concurrently at isolation level 3, a deadlock would have occurred if both
connections managed to issue the SELECT before either issued the UPDATE.
This has been fixed.
================(Build #3292 - Engineering Case #658849)================
If an application on a Unix system attempted to make a TCP/IP connection
to a server that was not running, the connection attempt may have failed
with error code -832 "Found server but communication error occurred".
This has been fixed, the correct error code should be
-100 "Database server not found".
================(Build #3291 - Engineering Case #657823)================
The fix for Engineering case 620136 did not handle the situation where there
was no declared Primary Key in the primary table but there were table, or
column, (not nullable) Unique Constraints that permit the addition of foreign
keys. This problem has been corrected.
================(Build #3290 - Engineering Case #658114)================
The server would have crashed if a SELECT statement useed the FOR XML EXPLICIT
clause, and a null value was used for the CDATA directive. This has been
fixed
================(Build #3290 - Engineering Case #656998)================
Remote queries with many aliases in grouped derived tables may have taken
a long time to execute. This has been fixed.
================(Build #3289 - Engineering Case #657621)================
If a server (S2) acting as mirror saw a dropped connection to the primary
server (S1) after a temporary network outage, it could have attempted to
become primary while S1 was still running. S2 would then have failed during
startup because S1 still owned the alternate server name for the database.
This error would also have caused S2 to shut down. If S1 needed to restart,
it would have been unable to take ownership of the database because S2 was
unavailable and the arbiter's state had been updated to indicate that S2
was the owner.
Also, when a server acting as primary (S1) accepted an inbound connection
from the mirror (S2), S1 attempted to make an asynchronous outbound connection
to S2 if one did not already exist. If this connection attempt failed, S2
would have failed to receive updates from S1.
These problems have now been fixed.
================(Build #3288 - Engineering Case #658302)================
If many contiguous index entries were removed from an index with no intervening
inserts, concurrent snapshot transactions could have seen incorrect results,
and in rare circumstances, foreign rows could have been added without matching
primary rows. This has been fixed.
================(Build #3287 - Engineering Case #658189)================
If a copy node (S3) was starting just as its intermediate node parent (S2)
was receiving pages from the root (S1), S3 could have failed to receive some
of the pages and would have reported a corrupt transaction log file. This
has been fixed.
================(Build #3287 - Engineering Case #658130)================
SQL Anywhere web client procedures were not able to proxy https requests.
This has been fixed.
The following example routes an https request destined for 'securehost'
(default port 443) through a proxy host named 'squid' listening on port 8080:
create or replace procedure test()
URL 'https://securehost/service'
TYPE 'HTTP:GET'
PROXY 'http://squid:8080';
================(Build #3287 - Engineering Case #658121)================
On some Windows machines, attempting to make a TCP connection to a Personal
Server on the same machine may have failed. This has been fixed.
================(Build #3287 - Engineering Case #657987)================
The server could have crashed, or failed assertion 200114, when processing
a LIKE predicate. This has been fixed.
================(Build #3287 - Engineering Case #657812)================
A number of read-only scale-out issues have been fixed.
1) The server could have crashed or otherwise failed in rare cases when
one or more read-only scale-out children were added to a node. This could
have occurred if one node was stopped or restarted.
2) If a parent node was restarted and had a lower log offset than it's child,
the child could have shutdown with the message "Database server shutdown
due to incompatible files for database mirroring." Restarting the child
node after the parent caught up to primary would succeed. Now the child node
no longer stops and the child node will start applying log changes once its
parent gets to a higher log offset.
3) If a parent copy node was started with child nodes already running, a
child node and possibly other nodes could have hung.
4) If a copy node was connected to it's alternate parent, and then it's
alternate parent stopped, the copy node may have stopped applying updates.
The copy should have connected to the primary server to receive updates but
was actually not receiving updates. Note that sa_mirror_server_status may
show that the node which is not receiving updates is connected, when in fact
it was not. Now the copy node will connect to the primary server if neither
the parent nor alternate parent servers are available.
5) An ALTER MIRROR SERVER statement that only changed the alternate parent
was ignored until the server being altered was restarted. For example, if
ServerC had parent ServerB:
ALTER MIRROR SERVER 'ServerC' AS COPY FROM SERVER 'ServerB' OR SERVER
'ServerA'
was ignored by ServerC until it was restarted. Now the alternate parent
is effective on the server being altered once it has applied the log offset
with the ALTER MIRROR SERVER statement.
6) Attempting to SET MIRROR OPTION auto_add_server to the alternate server
name for the primary server incorrectly resulted in an error.
7) If read-only scale-out copy nodes had a primary server as their root
node, and the primary server failed over to the mirror server, then all client
connections to all copy nodes were incorrectly dropped.
================(Build #3285 - Engineering Case #657520)================
In very rare cases, the server asserts with assertion error 102300 "File
associated with given page id is invalid or not open" if request level
debugging is turned on and includes plan logging and there are schema changes
around. This has been fixed. To work around the problem plan caching can
be turned off (option Max_plans_cached = 0) or plan logging can be turned
off (switch -zr without "plan" and "all").
================(Build #3285 - Engineering Case #654801)================
The SQL Anywhere Optimizer may have incorrectly pruned, without costing,
optimal plans during query optimization. This has been fixed. This incorrect
pruning would most probably have affected the final execution plans for
complex, but inexpensive (i.e., the optimal plan has a small runtime) queries.
================(Build #3284 - Engineering Case #657586)================
If a call was made to the Java external environment, and the stored procedure
had an argument of type tinyint and a NULL value was passed in for the tinyint
argument, then the server would have failed the request with a NullPointerException.
It should be noted that the Java VM would continue to run in this situation
and the connection was still able to make subsequent Java external environment
calls. This problem has now been fixed such that passing a NULL tinyint value
to a Java external environment call will result in a byte with zero value
being passed down to the Java method.
================(Build #3284 - Engineering Case #656691)================
If a query was rewritten by the optimizer to use a materialized view, the
query would incorrectly have returned zero rows if a spatial predicate was
applied to the rows originating from the view. This has been fixed.
================(Build #3283 - Engineering Case #656828)================
Adding the CHECK IMMEDIATE REFRESH clause to a CREATE MATERIALIZE VIEW statement
would have caused the server to crash. This has been fixed.
================(Build #3283 - Engineering Case #656264)================
When connected to a database that had the same character set as the OS, and
a query like the following was executed:
SELECT ... FROM dirtab WHERE file_name = '...'
where dirtab was a directory access table and the file_name string literal
contained non-ASCII characters, there was a chance the server would have
crashed. This problem has now been fixed.
================(Build #3282 - Engineering Case #656847)================
If a derived table was joined with the rest of the query using a Join Nested
Loops operator, the performance of the query may have suffered when the derived
table had to be computed many times due to many rows generated by the left
hand side of the Join Nested Loops. The optimizer was choosing such a plan
if the estimated number of rows of the left hand side was very small. If
this estimation was wrong (e.g., the optimizer estimates one row for the
left hand side but in reality the left hand side produces 1,000 rows), the
derived table was computed many, many times during execution. This has been
fixed so that the optimizer considers only Join Hash or Join Sort Merge operators
for the derived tables if it is correct to do so.
================(Build #3282 - Engineering Case #656839)================
If an INSERT or UPDATE statement affecting the value of a spatial column
was canceled, or a run-time error was encountered during execution, there
was a possibility that the server would have failed assertion 112701: "Failed
to convert geometry to EWKB for the redo log -- transaction rolled back [-301]
['40W01']". This has been fixed.
================(Build #3281 - Engineering Case #656650)================
The system procedure sa_db_list() did not validate its database id parameter
if the value was a positive integer. This would have resulted in a single
row result set containing the value provided. Now, if the value is not a
valid database id, the procedure will return an empty result set.
================(Build #3281 - Engineering Case #655981)================
Values for the ApproximateCPUTime property is never expected to decrease
between calls, as it represents an estimate of accumulated CPU time for a
connection. However, for connections that had accumulated approximately
1000 seconds of CPU time, the counter could have periodically receded by
approximately 400 seconds.
================(Build #3279 - Engineering Case #656272)================
The INSERT ON EXISTING SKIP statement did not report the correct number of
inserted and
updated rows using @@rowcount and sqlcount. This has now been corrected.
================(Build #3279 - Engineering Case #655749)================
Execution of an INSERT ... ON EXISTING SKIP statement did not report the
correct number of inserted and updated rows using @@rowcount and sqlcount.
This has been fixed
================(Build #3279 - Engineering Case #654294)================
When canceling a query involving spatial operations, there was a small probability
the server could have crashed, or failed to release resources. This has been
fixed.
================(Build #3278 - Engineering Case #655972)================
The fix for Engineering case 636018 missed a case, which has now been corrected.
Description of case 636018:
Queries involving indexes containing long values could have returned incorrect
results. Index corruption was possible, but not likely..
================(Build #3278 - Engineering Case #654938)================
In rare cases, a corrupt TCP packet could have caused the server to crash.
The server now validates the packet header before do anything with the packet.
If it is corrupt, the packet is dropped.
================(Build #3277 - Engineering Case #655533)================
Under rare circumstances, inserting the result from the Round Earth linestring()
function, or using the linestring() function in a query, could have crashed
the server, if the line string crossed the equator. This has been fixed.
================(Build #3275 - Engineering Case #654790)================
In very rare cases, the server may have crashed with a floating point exception
when slightly loaded. This has been fixed.
================(Build #3273 - Engineering Case #654284)================
The server could have crashed if the STOP SERVER or STOP ENGINE statement
was called from an event or HTTP connection. This has been fixed.
Note that the 'STOP SERVER' syntax is new to version 12 (older servers support
'STOP ENGINE').
================(Build #3273 - Engineering Case #654259)================
The changes for Engineering case 650489 may have caused execution remote
procedure calls to an ASE remote server to fail with a strange "unchained
transaction mode" error. This problem has now been fixed.
================(Build #3272 - Engineering Case #653591)================
Attempting to attach tracing to an older version database file could have
caused the server to crash. This has been fixed so that attempting to attach
tracing to an older version file now returns the error "ATTACH TRACING
could not connect to the tracing database" (-1097).
================(Build #3272 - Engineering Case #556778)================
The return values of the built-in functions user_id() and suser_id() may
have incorrectly been described as not nullable even if the function argument
was not nullable. This may have lead to the assertion error 106901 "Expression
value unexpectedly NULL in write". This has been fixed so that the functions'
results are always described as nullable.
================(Build #3270 - Engineering Case #653245)================
The value for the column "columns" for the system view SYS.SYSFOREIGNKEYS
is generated using a LIST() function, but the function did not include an
ORDER BY and so the result returned could have varied. This has been fixed
by adding an ORDER BY clause.
Note, the system view must be recreated by upgrading or rebuilding the database
for the new view definition to be used.
================(Build #3270 - Engineering Case #652911)================
If an INSTALL JAVA UPDATE statement was executed to update an existing java
class, the server would have incorrectly added a new system object id rather
than reuse the already assigned object id. This problem has now been fixed.
================(Build #3269 - Engineering Case #653590)================
Diagnostic tracing, or application profiling to LOCAL DATABASE could not
be used when the server was started with the command line option -sb 0 (disable
broadcast listener). This has been corrected. A workaround is to manually
supply a connection string (ATTACH TRACING TO <connstr>) with the DoBroadcast=NO
option, rather than using the LOCAL DATABASE clause.
================(Build #3269 - Engineering Case #653588)================
If tracing was suddenly detached (because, for example, the server receiving
the tracing data was shut down) at the same time as a deadlock occurred,
a deadlock victim may have failed to write a ROLLBACK to the transaction
log. This may have lead to an incorrect partial commit of a deadlocked transaction.
This has been fixed. This problem is expected to be very rare.
================(Build #3269 - Engineering Case #635956)================
A query with a CUBE, ROLLUP, or GROUPING SETS clause and HAVING predicates
may have returned an incorrect result set. The query must not have had any
aggregate functions, and the grouping sets must have contained the grand
total which should have been filtered by the HAVING predicates, but instead
it was returned as a valid row.
For example:
select n_comment from nation group by cube (n_comment) HAVING n_comment
like 'alw%';
The result set would have contained all the rows with n_comment for which
the predicate "n_comment LIKE 'alw%' is TRUE, but also the row "(NULL)".
This has now been fixed.
================(Build #3268 - Engineering Case #652592)================
Attempting to connect to a read-only scale-out database with a non-ASCII
database name using the NODETYPE connection parameter could have incorrectly
failed with a "Specified database not found" error. The database
name was being sent back in either OS-charset or DB-charset, but the client
needed it to be in client-charset. This has now been fixed.
================(Build #3267 - Engineering Case #652791)================
If a statement for a directory access table failed with the error SQLSTATE_OMNI_REMOTE_ERROR,
and this statement was the last statement of the transaction then all subsequent
remote server statements of this connection would have failed with the same
error. This has been fixed.
================(Build #3267 - Engineering Case #652759)================
If a table was included in a MobiLink publication and one or more options
were defined for that publication, but there were no synchronization subscriptions
defined, the table could not be ALTERed to, for example, add a new column.
This has been fixed.
================(Build #3267 - Engineering Case #652756)================
When validating a table that contained spatial data on 32-bit x86 systems
where the processor did not support the SSE2 instruction set (the minimum
required for SA spatial features), the database server would have reported
a non-fatal assertion error
113300 or 113302 "failed to build cursor to validate". This problem
has been fixed and the underlying error is now reported: SQL error (-1515)
-- Support for spatial is not available for this CPU.
================(Build #3267 - Engineering Case #651294)================
When starting a 32-bit server with a large initial number of request tasks
(-gn option), the server could have failed to start by reporting an error,
crashing or quietly exiting. This problem has been fixed by reducing the
maximum cache size to accommodate the address space needed for the stacks
of the request tasks.
================(Build #3266 - Engineering Case #652587)================
When running a database without a transaction log, performance could have
been significantly slower than in previous versions. This problem has been
corrected. See Engineering case 608904 for a similar issue..
================(Build #3266 - Engineering Case #652543)================
The server may have crashed during inserts into a view, if the view column
was not a base table column. This has been fixed. Now the correct error SQLSTATE_NON_UPDATEABLE_VIEW
is returned.
================(Build #3265 - Engineering Case #651694)================
If the connections between servers in a mirroring system used encryption,
the primary server could have hung when performing an operation which required
exclusive access to the database (e.g. a checkpoint) if other update activity
was also occurring. This has been fixed.
================(Build #3264 - Engineering Case #652107)================
If a foreign key had both ON UPDATE and ON DELETE actions, renaming a column
referenced by the foreign key could have caused one of the system triggers
to be deleted and the other to be left unchanged. A trigger for an ON UPDATE
action could have been converted to an ON DELETE action. This has been fixed.
================(Build #3264 - Engineering Case #651846)================
On Windows systems, the performance monitor might not have displayed counter
values provided by the server. Typically this would have happened when a
shared memory client that was attached to the server terminated abnormally.
Counter values should not display for subsequent servers until all processes
holding handles to the dead server (e.g. shared memory clients) are terminated.
This has been fixed.
================(Build #3263 - Engineering Case #651658)================
On Windows systems, SQL Anywhere provides a version 1 (registry) performance
provider. Windows should generate WMI classes automatically after the counter
dll is registered, but these classes were generated only after instances
of these objects (i.e. server, database and connection) existed in a process
running in session 0 (i.e. as a service in Vista and up). This has been
fixed.
================(Build #3262 - Engineering Case #651323)================
When the distance between two ST_Points exceeded the spatial reference system's
tolerance by at least a factor of 1, but less than a factor of sqrt(2), the
spatial relations ST_Equals and ST_Intersects could have incorrectly returned
TRUE. This has been fixed.
================(Build #3262 - Engineering Case #651169)================
If a database containing a table with a uniqueidentifier column was unloaded
using the Unload utility (dbunload) with one of the external unload options
(-xi or -xx), and the resulting reload.sql script was executed using the
Interactive SQL utility, a conversion error would have been reported. This
has been fixed. A workaround is to avoid using -xx or -xi when rebuilding
the database.
================(Build #3262 - Engineering Case #650337)================
Queries with an outer join having the same base table as the preserved and
null-supplying sides could have returned incorrect result sets. Conditions
where this could happen:
1. the outer join is of the form : T as T1 LEFT OUTER JOIN T as T2 ON(p)
2. the ON predicate p has only equijoins, and at least two equijoins
3. p is of the form : T1.c1 = T2.c1 and T1.c3 = T2.c2
4. there exists an unique index on T < c1,c2>
This has been fixed.
================(Build #3261 - Engineering Case #650740)================
Execution of a DROP DATABASE statement would have failed if the automatically
generated database alias name was an invalid identifier. This has been fixed.
================(Build #3261 - Engineering Case #650690)================
The server would have returned assertion failed 100905 "Articles on
the table use do not match those on the table definition", if a table
had publications and a simple INSERT with multiple row value constructors
was executed. For example: insert into tab1 values (1,'a'),(2,'b'). This
has been fixed.
================(Build #3153 - Engineering Case #647077)================
When run on Mac OS X systems, the server would have exited with the error
"Failed to
become daemon" if both the -um and -ud command line options were specified.
This was due
to a limitation in the OS X GUI infrastructure. This has been fixed. The
-um flag is now ignored if -ud is specified.
A workaround is to use dbspawn instead of -ud.
================(Build #3387 - Engineering Case #675894)================
In Sybase Central, you can generate HTML documentation for a database to
which you are connected. That documentation includes cross-reference information
for stored procedures -- a list of procedures a given procedure calls, and
a list of the procedures which call the given procedure. This cross-reference
information was not being generated for those stored procedures which used
the Transact SQL dialect. Cross-reference information for procedures which
used the SQL Anywhere dialect were generated fine. This has been fixed so
that cross-reference information is generated for stored procedures that
are written using either dialect.
================(Build #3376 - Engineering Case #674243)================
The text completer in the Interactive SQL utility and Sybase Central usually
suggests SQL statements (e.g. DELETE,INSERT,SELECT) when starting to typing
a statement. There was a problem that prevented statements from being suggested
when typing a new statement if there was already a statement on a later line,
and there was no command delimiter (i.e. a semicolon) between the new statement
and the existing one. In this case, only matching SQL keywords and database
object names would be suggested. This has been fixed.
================(Build #3339 - Engineering Case #667675)================
After the Database Documentation Wizard completed, a prompt asked whether
to view the generated documentation. If "Yes" was clicked, a browser
window was supposed to open to show the documentation, but the browser failed
to open if the path to the generated files contained a space. This has now
been fixed.
================(Build #3327 - Engineering Case #666024)================
Using Sybase Central's searching capabilities to search in a Version 11.0
or earlier database would have caused Sybase Central to crash. This has been
fixed.
================(Build #3327 - Engineering Case #666013)================
Using Sybase Central's searching capabilities to search for a single backslash
would have caused Sybase Central to crash. This has been fixed.
================(Build #3297 - Engineering Case #660656)================
After updating an external environment object via File->Update..., the
object's Contents tab would not always have reflected the changes made to
the object. This has been fixed.
================(Build #3292 - Engineering Case #659177)================
If a non-initialized materialized view or text index was selected in the
tree and the Data tab was selected in the right-pane, then attempting to
switch from one mode (Design, Debug or Application Profiling) to another
would have caused a refresh of the materialized view or text index to be
prompted for twice. This has been corrected so that there is now only one
prompt.
================(Build #3279 - Engineering Case #656454)================
When connected to a database that contained one or more publications, and
the property sheet for a Publication was opened and an Article was selected
in the "Subscribe by restriction" tab, the Editor pane at the bottom
of the tab would have been disabled except when the 'expression' radio button
was checked. When the Editor pane was disabled it was still possible to right
click on it to reveal a pop-up menu that allowed for search and replace in
the box. The menu is now disabled when the Edit pane is disabled.
================(Build #3278 - Engineering Case #655945)================
On the database Fragmentation tab, the shortcuts for Zoom In (Ctrl++) and
Zoom Out (Ctrl+-) did not work with the numeric keypad. This has been fixed.
================(Build #3278 - Engineering Case #644464)================
If a database had two or more 'post_login_procedure' option settings, then
attempting to connect to the database would have failed with a "Subquery
cannot return more than one row" error. This has been fixed.
================(Build #3273 - Engineering Case #654249)================
The External Environments folder was erroneously including an entry for dbmlsync.
This has been fixed.
================(Build #3266 - Engineering Case #652547)================
Altering the schedule for an event to remove a days-of-month specification
did not set SYSSCHEDULE.days_of_month to null. This has been fixed.
================(Build #3264 - Engineering Case #651520)================
Displaying the results of an Index Consultant run of a large workload could
have required an excessive amount of memory, causing Sybase Central to crash
if there was not enough physical memory available. This has been fixed.
================(Build #3262 - Engineering Case #651723)================
Opening a column's Property sheet would have caused the error: "Support
for spatial is not available for this CPU", when the server was run
on a system with on a Pentium III processor. The same error would also have
occurred in the Function and Domain wizards, and the Spatial Reference Systems
folder if it was selected in the tree. These issues have been fixed.
================(Build #3405 - Engineering Case #676727)================
When editing a TIMESTAMP column value in the "Results" panel, the
editor did not distinguish between AM and PM, always assuming AM. This has
been corrected so that the editor now distinguishes between the two.
================(Build #3400 - Engineering Case #676844)================
Attempting to perform an unload with reload of a database, using the Unload
utility or the dbtools DBUnload function, may have failed with a "Cannot
find index named ...' error if the index had a comment. This problem has
now been fixed.
================(Build #3391 - Engineering Case #674748)================
Attempting to unload and reload a SQL Anywhere database from version 10.0.0
and later could have failed if the database contained a large number of integrated
logins, and several of the integrated logins had comments associated with
them. This problem has now been fixed.
================(Build #3388 - Engineering Case #676033)================
When a statement cannot be executed by the Interactive SQL utility, the error
is displayed in an error window. That window contains a "Help"
button which, which clicked, can display a menu of relevant help topics (for
the error message and for the type of statement being executed). Opening
this error window could have taken a non-trivial amount of time if the online
documentation for SQL Anywhere was not installed. In those cases, the software
had to check with the DocComment Exchange (DCX) server to see if help was
available for the statement in question. While the Interactive SQL utility
is doing this check, it could be unresponsive. The problem was most acute
on machines that were not connected to the internet at all. This has been
fixed so that the error dialog opens without delay, and Interactive SQL remains
responsive at all times.
================(Build #3385 - Engineering Case #675496)================
Explicitly opening the Text Completer when the "SQL Statements"
field contained only matching parentheses would have caused the Interactive
SQL utility to crash. This has been fixed.
================(Build #3383 - Engineering Case #675147)================
The Interactive SQl utility's Import wizard usually remembers the names of
recently-imported files and presents them in the combo-boxes where a file
can be selected to import. A bug was preventing the list of file names from
being remembered. This has been fixed.
================(Build #3382 - Engineering Case #674931)================
The 32-bit versions of Sybase Central, the Interactive SQL utility, the Console
utility, and the MobiLink Monitor, could have failed to start on 32-bit Windows
systems under "low" memory conditions. The point at which memory
becomes low is difficult to quantify, and depends heavily on the number of
other programs running on the machine, and their locations in memory. This
has been fixed.
As part of this change, the message that is displayed when the Java Virtual
Machine can't start has been improved to include the actual JVM error.
================(Build #3375 - Engineering Case #674024)================
The toolbar buttons in the Interactive SQL utility were not enabled if a
stored procedure was executed from Sybase Central and the procedure completed
with errors. This has been corrected so that the toolbar buttons are now
enabled correctly.
================(Build #3374 - Engineering Case #674063)================
When typing a single-line SQL comment, the Text Completer could have opened
while typing. This has been corrected so that the Text Completer remains
hidden unless it is explicitly opened.
================(Build #3374 - Engineering Case #673852)================
With both 32 bit and 64 bit versions of SQL Anywhere installed on a 64 bit
Windows system, using the Deployment wizard to create a 32 bit install would
have displayed the 64-bit UltraLite feature. Attempting to install the MSI
that was created in this way on a 32-bit Windows system would have caused
the following error:
Module C:\Program Files\SQL Anywhere 12\BIN64\ulodbc12.dll failed to register.
HRESULT -2147024703. Contact your support personnel.
This has been fixed.
================(Build #3368 - Engineering Case #669572)================
If the Service utility (dbsvc) was used to shut down a service, and the service
took a long time to shut down, dbsvc may have reported that an error occurred.
For example, if checkpointing one of the databases took longer than 3 seconds.
The server would still have shut down eventually. This has been fixed.
================(Build #3364 - Engineering Case #669412)================
When run on Linux systems, the Service utility (dbsvc) requires the LSB init-functions.
Some Linux distributions do not installed by default so the must be installed
manually in order to use dbsvc
For example, on Fedora, run the following command:
yum install redhat-lsb redhat-lsb.i686
================(Build #3363 - Engineering Case #672088)================
The Extraction utility could have incorrectly extracted an event from a consolidated
database for a user that would be not be created in the remote database.
This has now been corrected.
================(Build #3354 - Engineering Case #670521)================
Attempting to modify NCHAR, NVARCHAR or LONG NVARCHAR values, using the scrolling
table in the "Results" panel, would have silently failed if the
value was loaded from a file. This has been fixed.
================(Build #3353 - Engineering Case #669783)================
The Update Checker could have informed that there were updates, even when
it had been asked not to. Specifically, if there had been a new documentation
release (in a new language, say), and the Uupdate Checker had been configured
to not show informational messages, you would still have been notified.
This has been fixed.
================(Build #3351 - Engineering Case #670020)================
The Support utility (dbsupport) may have silently failed to submit diagnostic
information if it was a first-time submission. This has been fixed.
================(Build #3350 - Engineering Case #669411)================
When run on some Linux distributions, the Interactive SQL utility (or any
of the graphical administration tools) may not have displayed Chinese characters
correctly. This has been fixed.
Workaround:
1. Shut down any graphical administration tools (Sybase Central, Interactive
SQL (dbisql), the MobiLink Monitor, SQL Anywhere Monitor, or SQL Anywhere
Console utility (dbconsole) that are running.
2. Run the following commands:
mkdir $SQLANY12/sun/jre160_x86/lib/fonts/fallback
ln -s /usr/share/fonts/truetype/arphic/*.ttc $SQLANY12/sun/jre160_x86/lib/fonts/fallback
ln -s /usr/share/fonts/truetype/wqy/*.ttc $SQLANY12/sun/jre160_x86/lib/fonts/fallback
================(Build #3347 - Engineering Case #669218)================
Using an encrypted command file did not work on big endian computers (typically
running Solaris or AIX). The symptom was an error message "Could not
decrypt command file." This has been fixed.
================(Build #3344 - Engineering Case #666960)================
When connected to an ASE database, the "Help" menu could have contained
redundant separators. This has been fixed.
================(Build #3343 - Engineering Case #668397)================
The SQL Passthrough feature was removed in version 12 and three associated
tables (sync_passthrough_progress, sync_passthrough_script, and sync_passthrough_status)
were dropped. The Unload utility did not properly handle the case where a
pre-version 12 database contained these tables and they were not empty. This
has been fixed.
================(Build #3340 - Engineering Case #667932)================
For a table with no foreign keys, SQLForeignKeys would have returned a single
row with NULLs in most columns. This problem could have resulted in a java.lang.NullPointerException
in the Interactive SQL utility's Query Editor. This has been fixed so that
when the table has no foreign keys, no rows will be returned.
================(Build #3329 - Engineering Case #666434)================
When using output redirection for a READ statement that referenced a file
containing another READ statement, the dbisqlc utility would have reported
an error such as "invalid file number". This problem has been corrected.
Example: "READ file1.sql >& output.txt"
file1.sql:
read file2.sql
go
SELECT ...
file2.sql:
SELECT ...
================(Build #3329 - Engineering Case #665710)================
When executing a SELECT statement such as "(select 1)" that begins
with open parenthesis, the dbisqlc utility would have reported a syntax error.
This problem has been fixed.
================(Build #3327 - Engineering Case #665673)================
If the Interactive SQL utility was launched from a program using the Apache
Portable Runtime, and standard output and/or standard error file handles
were redirected, an internal error could have been reported. This has been
fixed.
================(Build #3326 - Engineering Case #663937)================
In the Interactive SQL utility, setting the "on_error" option to
"continue" was not preventing warnings from being displayed in
a popup window. This has been corrected so that when the option is set to
"continue", warnings are now displayed in the "Messages"
pane.
================(Build #3325 - Engineering Case #665670)================
The execution tree in the Plan Viewer window could have partially obscured
the bottom part of the tree drawing if a display option for the plan was
changed to make it larger (by turning on "Show percent cost", for
example). This has been fixed.
================(Build #3324 - Engineering Case #637476)================
Importing data from a database that was not a SQL Anywhere or UltraLite database
into an UltraLite database, using the Interactive SQL INPUT statement or
the Import Wizard, could have failed. This would have occurred if a new table
was to be created for the imported data and the data contained one or more
INTEGER columns. This has been fixed.
================(Build #3321 - Engineering Case #662766)================
When using the Deployment wizard to build an MSI install containing both
64-bit and 32-bit software, the jvm.dll in the sun\jre160_x64\bin\server
directory was being replaced by the 32-bit version. This could have occurred
whenever two different files were included with the same name, in a directory
with the same name, and with the same parent directory. This has been corrected.
================(Build #3314 - Engineering Case #637446)================
Exporting TIME values to a DB2 database with an OUTPUT USING statement in
the Interactive SQL utility would have failed. This has been fixed.
================(Build #3311 - Engineering Case #663786)================
The Server Enumeration utility (dblocate) may have failed to list some running
database servers if many (over around 50) servers were running in the TCP/IP
subnet. This problem was more likely if the -d option ("brief list
of databases running on each server"). This has been fixed by increasing
the UDP receive buffer size used by dblocate. For some Unix/Linux operating
systems, in order for this change to take effect, the system maximum UDP
receive buffer size may need to be increased. On Linux, this can be done
by increasing the sysctl net.core.rmem_max setting.
================(Build #3308 - Engineering Case #663279)================
Clicking the "Stop" toolbar button in the Interactive SQL utility
often did not stop execution if many short-running statements were being
executed. It did work correctly if executing a single long-running statement.
This has been fixed.
The workaround for this problem is to use the SQL->Stop menu item, which
always works.
================(Build #3305 - Engineering Case #663123)================
Creating an ODBC data source for IQ from the Connect dialog did create a
DSN, but it was not created correctly. The following issues have been fixed:
1. The driver name for the data source was always "SQL Anywhere 12"
rather than "Sybase IQ". This prevented the data source from being
listed in the "Data Source Names" window unless you checked "Show
all data sources". Also, to connect using the data source, the SQL
Anywhere ODBC driver had to be installed.
2. Creating a system data source would fail on machines that did not have
"dbdsn" installed. This would be a problem on computers running
Vista or Windows 7 which have IQ installed, but not SQL Anywhere.
================(Build #3304 - Engineering Case #662944)================
On Mac OS X, the tool tips for the "zoom in", "zoom out",
"reset view", and "save image" buttons in the "Value
of Column" dialog indicated that the Control key should be held down
to activate the button. This was incorrect, it should have shown the Command
key. This has now been fixed.
================(Build #3303 - Engineering Case #656680)================
The Interactive SQL utility could have become unresponsive when executing
a statement which returned a result set if the entire result set cannot be
returned due to a row lock. This has been fixed.
================(Build #3301 - Engineering Case #662233)================
The connection properties on the Advanced page of the Connect dialog were
not filled when attempting to reconnect following a disconnect. For this
problem to have occurred, the IQ plug-in for the Interactive SQL utility
would needed to have been loaded. That plug-in is loaded by default starting
in version 12.0.1.
A similar problem affected the TLS packet encryption parameters on the Network
page.
Both of these problems have now been fixed.
================(Build #3295 - Engineering Case #660005)================
If a file was opened in the Interactive SQL utility and then the window was
closed, the file would still have been locked by the dbisql process if the
"Enable fast launcher" option was on. This has been fixed.
================(Build #3292 - Engineering Case #659337)================
SQL changes in the Plan Viewer and Spatial Viewer windows were ignored if
the Editor component had been selected, "Options" was clicked and
then dismissed by clicking "OK". This has been fixed.
This issue had at least one other symptom: If a file was opened, "Options"
for the editor was selected, either by right-clicking as described above
or by opening the Options window, then clicked "OK", subsequent
changes in the Editor would not have caused the Interactive SQL utility's
window title text to include an asterisk. The asterisk indicates that there
are unsaved changes in the editor.
================(Build #3292 - Engineering Case #659140)================
The text completer may not have suggested any matches if there was an empty
single quoted string earlier in the statement, or in a previous statement.
This has been fixed.
================(Build #3289 - Engineering Case #658334)================
If a database option value contained a single quote, the reload script generated
by the Unload utility would have resulted in a syntax error when the database
was reloaded. This has been fixed.
================(Build #3286 - Engineering Case #653316)================
When deleting rows from an UltraLite database, the Interactive SQL utility
would have incorrectly reported the number of rows affected by a DELETE.
The message "1 row(s) deleted" would have been shown in the Message
pane, regardless of how many rows were deleted. This has been fixed.
================(Build #3285 - Engineering Case #657324)================
Installations created by the Deployment wizard were to be missing the following
files from the assembly\v2\ directory:
iAnywhere.Mobilink.Client.dll
iAnywhere.QAnywhere.Client.dll
iAnywhere.QAnywhere.Resources.dll
iAnywhere.QAnywhere.ws.dll
These files were being installed in the Global Assembly Cache (GAC), but
an additional copy was not also put in the assembly\v2 directory. This has
been corrected so that these files are now installed in both locations.
================(Build #3281 - Engineering Case #658169)================
When using the Service utility (dbsvc) for Linux to create an automatic service
(when the machine boots) on Linux SUSE 11 for the SQL Anywhere server, the
server may have started before the network service had been started. As a
result, some applications running inside the SQL Anywhere server may have
failed to work properly. This issue would have affected SQL Anywhere Server
Monitor deployments. This has been fixed.
================(Build #3281 - Engineering Case #656897)================
Attempting to execute a SQL statement that was made up only of full-width
space characters (U+3000, the "Ideographic Space") would have caused
the Interactive SQL utility to crash. This has been fixed.
================(Build #3278 - Engineering Case #637456)================
Attempting to import NCHAR types from ASE using the INPUT statement or the
Import Wizard, would have failed with the message "Cannot convert ''
to a varbit". This has been fixed.
================(Build #3278 - Engineering Case #631019)================
Two issues relating to using the INPUT and OUTPUT statements (and their corresponding
wizards) to move data between SQL Anywhere and ASE have been fixed.
Importing a table from ASE which had TIMESTAMP columns into a new table
would have failed. The ASE TIMESTAMP type was being misinterpreted as being
equivalent to the SQL Anywhere TIMESTAMP type, which is false.
Exporting data from SQL Anywhere into ASE would have reported various conversion
issues for SQL Anywhere DECIMAL values.
================(Build #3277 - Engineering Case #655607)================
The text in the Favorites sidebar could have disappeared if the mouse was
moved over it. This has been fixed.
================(Build #3275 - Engineering Case #654981)================
The Console utility could have stopped refreshing connection properties after
changing the set of properties which were displayed, even after restarting
DBConsole. This has been fixed.
================(Build #3274 - Engineering Case #654636)================
Opening a .saplan file in the "Plan Viewer" window and clicking
the "Print" button did not do anything. This has been corrected
so that it prints the plan. There was no problem printing plans which were
generated by clicking the "Get Plan" button.
================(Build #3274 - Engineering Case #654635)================
If HTMLHelp documentation for SQL Anywhere was installed, it was possible
for the Index Consultant to open DCX help under some circumstances. This
has been fixed.
================(Build #3274 - Engineering Case #654425)================
In the Options window, the components for editing the quitting time were
enabled even if the "Quitting time" checkbox was not checked. Now,
the components are disabled when the checkbox is not checked.
================(Build #3274 - Engineering Case #654253)================
In versions of the Interactive SQL utility 10.0.0 and later, using an ISQL
parameter for the value of an option in a SET OPTION statement did not work
because the parameter was not substituted correctly. This has been fixed.
================(Build #3270 - Engineering Case #653743)================
The Import wizard would have reported an internal error when importing a
shapefile if no spatial reference system was selected. This has been fixed.
================(Build #3365 - Engineering Case #672208)================
The changes for Engineering case 655157 introduced a problem such that when
multiple consecutive pinging messages appeared in the incoming message box,
SQL
Remote would have generated the warning message:
Deleting duplicate message from ...
and then deleted the duplicate pinging messages.
This problem is fixed so that all the duplicate pinging messages are now
processed without complaint.
================(Build #3346 - Engineering Case #668757)================
SQL Remote for SQL Anywhere (dbremote) now supports HTTP and HTTPS as a message
type for SQL Remote messages for remote databases. Users wishing to use the
HTTP or HTTPS message type from a remote database will configure the remote
database using the SET REMOTE OPTION command, in the same way that the FILE,
FTP and SMTP message type is configured. The HTTP/HTTPS message type uses
the following control parameters that are set by the SET REMOTE OPTION statement:
• url : Specify the server name or IP address and optionally the port number
of the HTTP server being used, separated by a semi-colon. If requests are
being passed through the Relay Server, you can optionally add an URL suffix
to indicate which server farm the request should be passed to. url=’server-name[:port-number][url_suffix]’
• https : Specify whether to use HTTPS (https=YES) or HTTP (https=NO).
• certificate : To make a secure (HTTPS) request, a client must have access
to the certificate used by the HTTPS server. The necessary information is
specified in a string of semicolon-separated key/value pairs. You can use
the file key to specify the file name of the certificate, or you can use
the certificate key to pecify the server certificate in a string. You cannot
specify a file and certificate key together. The following keys are available:
file : The file name of the certificate.
certificate : The certificate itself.
company : The company specified in the certificate.
unit : The company unit specified in the certificate.
name : The common name specified in the certificate.
Certificates are required only for requests that are either directed to
an HTTPS server, or can be redirected from a non-secure to a secure server.
Only PEM formatted certificates are supported.
certificate=’key=value[:key=value]'
• user : The HTTP server user ID. Authenticates to third-party HTTP server
and gateways using RFC 267 Basic Authentication. user=’userid’
• password : The HTTP server password. Authenticates to third-party HTTP
server and gateways using RFC 267 Basic Authentication. password=’password’
• debug : When set to YES, all HTTP commands and response are displayed
in the output log. This information can be used for troubleshooting HTTP
support problems. The default is NO.
• proxy : Specifies the URI of a proxy server. For use when SQL Remote must
access the network through a proxy server. Indicates that SQL Remote is to
connect to the proxy server and send the request to the message server through
it. proxy=’http://proxy-server[:port-number]’
• client_port : Identifies the port number on which SQL Remote communicates
using HTTP. It is provided for and recommended only for connections through
firewalls that filter "outgoing" TCP/IP connections. You can specify
a single port number, ranges of port numbers, or a combination of both. Specifying
a low number of client ports could result in SQL Remote being unable to send
and receive messages if the operating system has not released the ports in
a timely manner after SQL Remote closes the port on a previous run. client_port=’nnnn[-mmmm]’
Unlike the FTP or SMTP message type, which relies on a third-party FTP or
E-mail server, the HTTP message type makes use of the web services functionality
that exists in the SQL Anywhere database engine to act as
the HTTP server, which we refer to as a "message server". In order
to setup the message server, you only need to run the sr_add_message_server
on the consolidated database, and ensure that the database server has
been started with the -xs http[s] switch. If starting the HTTP[S] listener
on a database server hosting the consolidated database is a performance or
security concern, then you can use a separate database server, as long as
the database you run sr_add_message_server on has identical SQL Remote definitions
to your consolidated database. For more information on how to setup a consolidated
database to be a message server, how to setup a separate message server,
or how to use the Relay Server to forward HTTP requests from remote database
to the message server, please read the tutorials and full documentation.
The SQL Remote documentation has been updated to include information about
the new message type. A PDF file called "sqlremote1201.pdf" has
been installed with the EBF that includes information on the HTTP message
type, as well as changes to SET REMOTE OPTION command.
================(Build #3405 - Engineering Case #678597)================
When running in a continuous mode, SQL Remote would have leaked about 10
kilobytes of memory in every attempt of sending messages to its subscribers.
This problem has now been fixed.
================(Build #3367 - Engineering Case #667109)================
If SQL remote (dbremote) was running in continuous mode, it was possible
for it to have have reported "Execution Complete", but no errors
or warnings would have been printed to the dbremote log indicating why the
process had stopped. This has been fixed.
================(Build #3297 - Engineering Case #660813)================
If the database was blank padded and the database option Compression was
set to be -1, .SQL Remote would have logged the following warning message
in its output file:
Option DBA.Compression contains invalid value -1
The value -1 is a valid value, it was the blank padding that was causing
the option to be treated as invalid. This problem has been fixed.
================(Build #3278 - Engineering Case #656093)================
The Log Translation utility (dbtran) and SQL Remote could left temporary
files undeleted after execution. This has been fixed.
================(Build #3277 - Engineering Case #655351)================
Temporary files created by SQL Remote and Log Translation utility may not
have been deleted. This problem has been fixed.
================(Build #3404 - Engineering Case #678229)================
If the remote database schema in a synchronization was updated from an existing
remote database that had the same schema, except for the case of identifiers
(such as table names or owner names), errors could have resulted. The table
mappings would have become invalid, clicking on such a table mapping would
have caused an unexpected error dialog, and script generation errors could
have occurred. This has been corrected.
================(Build #3340 - Engineering Case #667934)================
The attempt to add a second primary key was not diagnosed in an ALTER TABLE
statement. This has been corrected.
================(Build #3374 - Engineering Case #673856)================
Sometimes the TLS internal communication error (220) was reported without
a useful system error code (e.g. Certicom error code) for further analysis.
This has been corrected.
================(Build #3363 - Engineering Case #672094)================
Renaming a table that was marked as no-sync or all-sync would have changed
it to a normal synchronizing table if the new name didn't have the "_nosync"
or "_allsync" suffix. This has been fixed. The table will now
retain its old sync type unless the previous name did have one of the special
suffixes ("_nosync", "_allsync", and "_download_only")
and the new name does not since a change to the sync type is implied by the
removal of the special suffix.
================(Build #3348 - Engineering Case #668396)================
Join queries with predicates in the WHERE or ON clauses that involved columns
not in indexes have now been improved.
================(Build #3315 - Engineering Case #664633)================
A synchronization using FIPS end-to-end-encryption could have corrupted a
FIPS encrypted UltraLite database. This has been corrected.
================(Build #3302 - Engineering Case #662477)================
When resuming a download, the sent and received statistics are restored from
the previous sync and continue as expected from that point, except the byte
counts, which were reset to zero. This has now been fixed. The byte counts
(like the row statistics) are cumulative for resumed downloads. These statistics
are available to the synchronization observer callback and are contained
in the sync-results object.
================(Build #3300 - Engineering Case #662074)================
The following UltraLite resumable-download problems are now fixed:
In rare cases, UltraLite incorrectly computed where to resume the download.
When this occurred, the subsequently resumed download was effectively corrupted,
likely causing a synchronization error. (To recover, the download must have
been rolled back.)
When resuming a download, the server continued to use the original 'timeout'
specification, but UltraLite used the default. If a non-default timeout value
was specified, the resumed download may have timed out even though the network
connection was fine (though it still maked progress).
Sometimes the sync-info (or sync-result) 'partial_download_retained' flag
was false after trying to resume a download when there was still a partial
download present. (Workaround is to only make use of this flag when first
set - attempting to subsequently resume when there is no partial download
is safe and returns an error.)
As well, the following problem is fixed:
The COMMITTING_DOWNLOAD sync observer state was signaled later than it should
have been. The observer saw UltraLite was still receiving the download, when
in fact it had begun committing the download.
================(Build #3295 - Engineering Case #660263)================
Incorrect results were possible for a deeply nested (at least a depth of
three) aggregate subquery. This has been corrected.
================(Build #3295 - Engineering Case #659922)================
A syntax error could have been incorrectly generated for an outer reference
occurring in a subquery containing another nested subquery, where the outer
reference was to the right of the nested subquery. This has been corrected.
================(Build #3290 - Engineering Case #658549)================
Result set rows could have been presented in an incorrect order when all
of the following conditions were present for a SQL query:
- An index existed in which the first column (say col1) was specified to
be in descending order
- The query contained a search condition of the form "col1 LIKE expression"
where the expression started with non-wildcard characters.
- The query contained an ORDER BY starting with col1
This has been corrected.
================(Build #3275 - Engineering Case #654684)================
References to derived table columns may have been incorrect when temporary
tables were present and the derived table was used to load the temporary
table. This has been corrected.
================(Build #3275 - Engineering Case #654648)================
The substr() function was permitting LONG VARCHAR values to be used as the
first argument to the function. This has been corrected
================(Build #3272 - Engineering Case #653884)================
The Mobilink Server would have logged the error "Light weight poll request
failed" after every poll attempt from an Ultralite client (through the
use of the ML_GET_SERVER_NOTIFICATION function), even if the polls were actually
successful. This has been fixed
================(Build #3328 - Engineering Case #666232)================
The "Go To Table" and "Go To Foreign Key" menu items
for the ER Diagram tab did not always work. The "Go To Table" menu
item did nothing if the database tree node was collapsed. The "Go To
Foreign Key" menu item did not work at all. These have now been fixed.
================(Build #3298 - Engineering Case #661008)================
Right-clicking on an UltraLite database in the UltraLite Sybase Central plug-in,
will show a list of database properties, one of which is the database file
name. If the file name contained multi-byte characters, they could have been
displayed as mangled characters. This has now been fixed.
================(Build #3294 - Engineering Case #659866)================
If an invalid value was specified for the "(other)" parameter on
the Synchronization Profile property sheet, then it was not possible to clear
this invalid value unless the property sheet was closed and F5 was pressed.
This has now been fixed.
================(Build #3279 - Engineering Case #656087)================
When connecting from Sybase Central to an UltraLite database with multi-byte
characters in its file name, the database name would have appeared with mangled
characters. This has been fixed.
================(Build #3265 - Engineering Case #652188)================
When a table was selected in the tree and the Indexes tab was shown in the
right pane, there was no File -> New -> Index... menu item. As such,
it was only possible to start the Index wizard from the toolbar button. This
has been fixed.
================(Build #3370 - Engineering Case #672372)================
Execution of an ALTER DATABASE SCHEMA FROM FILE statement may have failed
with a SQLE_SCRIPT_MISSING_DELIMITER error when using a SQL file generated
from ulunload or ulinit. This has been fixed.
================(Build #3281 - Engineering Case #656844)================
ULPod may have caused AvantGo clients to crash when calling the method TableAGDBSet
getTableAGDBSet. This has been fixed.
================(Build #3326 - Engineering Case #664507)================
ULDataAdapter class may have reported the error SQLE_TOO_MANY_TEMP_TABLES
even if the Dispose() method was invoked. This has been fixed.
================(Build #3275 - Engineering Case #653158)================
The methods ULConnection.CountUploadRows, ULConnection.GetLastDownloadTime,
and ULConnection.ResetLastDownloadTime would have failed on Windows desktop
when provided named publications instead of ULConnection.SYNC_ALL_DB. This
has been fixed.
================(Build #3301 - Engineering Case #661930)================
In some cases, the UltraLite Database Unload utility (ulunload) would have
generated foreign keys in its XML output file that were not really in the
database being unloaded. This has been fixed.
================(Build #3274 - Engineering Case #653467)================
If an UltraLite database had a table with a LONG VARCHAR column, and that
column contained XML data, attempting to view that data in the Interactive
SQL utility's cell editor (in the XML Outline tab) could have failed with
the error: "An invalid XML character (Unicode: 0x0) was found in the
element content of the document". This is now fixed.
================(Build #3406 - Engineering Case #671994)================
Doing an FETCH ABSOLUTE instead of a FETCH RELATIVE could have caused the
cursor to move to an incorrect row if the query contained a subquery. This
could have resulted in a -197 error code when trying to get column values.
The GetRowCount() method does an absolute fetch internally, so the problem
could have occurred when invoking this method. This has now been fixed.
================(Build #3403 - Engineering Case #672633)================
When the MobiLink server was running on an OS with a multi-byte character
set, and a synchronization request from an Android UltraLiteJ application
caused a synchronization error at the server, the UltraLiteJ runtime could
have caused an application crash. This has been fixed.
================(Build #3401 - Engineering Case #677867)================
Null values retrieved with ResultSet.getString( col_no ) were returned as
an empty string. This has been fixed. Now, null values are retrieved as
null with this method.
================(Build #3395 - Engineering Case #675363)================
A null pointer exception was possible when a host variable occurred in the
HAVING clause This was corrected.
================(Build #3387 - Engineering Case #675642)================
Database corruption was possible when the UltraLiteJ Runtime was under row
limitation stress (when the maximum and minimum row limitation values are
close together). This has now been corrected.
================(Build #3387 - Engineering Case #674898)================
Multi-threading access to an UltraLiteJ database may have resulted in a null
pointer or other exception. This problem would have occured if another thread
was accessing many rows in a single operation (i.e. updating a table with
a large number of rows and indexes with small row limiting values). This
has been fixed.
================(Build #3376 - Engineering Case #674206)================
The DatabaseManager.release() method is designed to be used only once to
release all resources associated with the UltraLiteJ runtime. However, some
DatabaseManager methods (eg. connect) did not return an error, but silently
failed when called after the call to release(). This has been fixed. Now,
a ULjException is thrown with the error code SQLE_NOT_CONNECTED if a connect()
or createDatabase() is called after the call to release().
================(Build #3372 - Engineering Case #673483)================
When the method Connection.emergencyShutdown() was called, existing connections
on the database did not have their states changed to NOT_CONNECTED. This
has been fixed.
Also, the method DatabaseManager.connect() now returns SQLE_INVALID_PARAMETER
if passed a NULL configuration.
================(Build #3369 - Engineering Case #673051)================
It was not possible to use ZLib data compression with HTTP synchronization
as the methods to enable compression appeared in StreamHTTPSParms, rather
than StreamHTTPParms. This has been fixed by moving the methods from StreamHTTPSParms
to StreamHTTPParms. Existing applications will continue to run because StreamHTTPSParms
is a subclass of StreamHTTPParms.
================(Build #3354 - Engineering Case #669242)================
An ArrayIndexOutOfBoundsException could have been thrown during a COMMIT.
This has been fixed.
================(Build #3345 - Engineering Case #668820)================
Calling the method DatabaseManager.release() would have caused the error:
"No implementation found for native Lcom/ianywhere/ultralitejni12/implementation/JniDbMgr;.release
()V". This has been corrected by implementing the method DatabaseManager.release().
Note that prior to this fix, UltraLiteJ for Android would have done the
equivalent of DatabaseManager.release() when the UltraLiteJ application terminated.
Now it is possible for the application to execute DatabaseManager.release()
at a specific point in time.
================(Build #3339 - Engineering Case #667720)================
The following methods have been implemented in ResultSetMetadata for UltraLiteJ
for Android:
String getAliasName( int column_no )
String getDomainName( int column_no )
String getCorrelationName( int column_no )
String getQualifiedName( int column_no )
String getTableColumnName( int column_no )
String getTableName( int column_no )
String getWrittenName( int column_no )
Previously, they returned the value "N.Y.I.". They now return
values that closely approximate those returned by the UltraLiteJ runtime
for Blackberry.
================(Build #3336 - Engineering Case #667519)================
The following get-by-name APIs were missing from ResultSet for UltraLiteJ
for Android and have now been added:
java.io.InputStream getBlobInputStream( String name )
boolean getBoolean( String name )
byte[] getBytes( String name )
java.io.Reader getClobReader( String name )
java.util.Date getDate( String name )
DecimalNumber getDecimalNumber( String name )
double getDouble( String name )
float getFloat( String name )
long getLong( String name )
int getSize( String name )
String getString( String name )
UUIDValue getUUIDValue( String name )
boolean isNull( String name )
================(Build #3301 - Engineering Case #662232)================
The performance of database changes on first update (commit) after starting
up has been improved.
================(Build #3297 - Engineering Case #660797)================
During a large (at least 15 MB) data synchronization, the UltraLiteJ native
library for Android could have caused a Dalvik VM memory overflow condition
similar to the following:
WARN/dalvikvm(641): ReferenceTable overflow (max=512)
...
ERROR/dalvikvm(641): Failed adding to JNI local ref table (has 512 entries)
...
ERROR/dalvikvm(641): VM aborting
The memory overflow condition would have occurred during a Connection.synchronize(
SyncParms parms ) call, where a SyncObserver was defined in the SyncParms.
This has been fixed.
================(Build #3297 - Engineering Case #660501)================
Incorrect results were possible when executing a query with an IN list consisting
of a single host variable. This has been corrected.
The work-around is to rewrite
expression in ( ? )
as
expression = ?.
================(Build #3295 - Engineering Case #660387)================
Incorrect results were possible for a deeply nested (at least a depth of
three) aggregate subquery. This has been corrected.
================(Build #3290 - Engineering Case #658845)================
Result set rows could have been presented in an incorrect order when all
of the following conditions were present for a SQL query:
- An index existed in which the first column (say col1) was specified to
be in descending order
- The query contained a search condition of the form "col1 LIKE expression"
where the expression started with non-wildcard characters.
- The query contained an ORDER BY starting with col1
This has been corrected.
================(Build #3278 - Engineering Case #655880)================
Second and subsequent '%' characters were not being handled properly in LIKE
clauses. This was corrected.
================(Build #3388 - Engineering Case #676069)================
The UltraLiteJ Database Unload utility (uljunload) did not allow specifying
the page size on a new databases. A new flag -z has been added to uljunload
to specify the page size in bytes.
================(Build #3369 - Engineering Case #673024)================
The message "Number of tables that are never synchronized:" would
have returned the number of tables that were synchronized instead of the
number that were never synchronized. This has been fixed.
Also, the message "Number of tables that will always be uploaded:"
was incorrect and misleading and the number displayed was invalid. This
message has been changed to "Number of tables that are in publications:"
and the output has been corrected.