SQL Anywhere Bug Fix Readme for Version 10.0.1, build 4075
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 3415 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.
Moderate testing has been performed on the software, but full testing has not
been performed. Customers are encouraged to verify the suitability of the software
before releasing it into a production environment.
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
================(Build #3664 - Engineering Case #496567)================
The MobiLink system table ml_qa_status_history in a consolidated database
would have grown without limit. The problem only occurs for ASE consolidated
databases. To correct this in existing ASE consolidated databases, the trigger
ml_qa_repository_trigger needs to be changed by running the following script
on the consolidated database after it has been initialized with the MobiLink
setup script:
delete from ml_qa_status_history where msgid not in (select msgid from ml_qa_repository)
go
commit
go
drop trigger ml_qa_repository_trigger
go
create trigger ml_qa_repository_trigger on ml_qa_repository for delete
as
delete from ml_qa_repository_props from deleted d, ml_qa_repository_props
p
where d.msgid = p.msgid
delete from ml_qa_delivery from deleted d, ml_qa_delivery p
where d.msgid = p.msgid
delete from ml_qa_status_history from deleted d, ml_qa_status_history p
where d.msgid = p.msgid
go
================(Build #3893 - Engineering Case #571233)================
When the -pi option 'ping MobiLink server' was used on the MobiLink client
(dbmlsync) command line, dbmlsync would have returne an exit code of 0 (indicating
success), even if it was unable to contact the Mobilink server. This has
been fixed, and a non-zero exit code will now be returned in this case.
================(Build #3685 - Engineering Case #495705)================
When the MobiLink Client was launched using the Dbmlsync Integration Component,
it was possible to view the username and password in the dbmlsync command
line in plain text. This has been corrected so that the Dbmlsync Integration
Component will encrypt all the command line options and settings before passing
them to dbmlsync. Dbmlsync will then decrypt the options and settings.
Note, this fix does not apply to the Dbmlsync Integration Component running
on Windows CE systems.
================(Build #3560 - Engineering Case #480085)================
If transaction log files for multiple databases were stored in a single directory,
the MobiLink client dbmlsync might not have been able to synchronize any
of these databases, even if there were no offline transaction log files for
any of these databases. To resolve this, a new command line option has been
added to dbmlsync:
-do disable offline logscan (cannot use with -x)
When this new option is used, dbmlsync will not attempt to scan any offline
transaction logs. Therefore, dbmlsync with -do should be able to synchronize
a database that is stored with all the other databases in a single directory,
as long as this database does not have any offline transaction log files.
However, if actual offline transaction log files are requested (for instance,
if the minimum progress offset is located
in an offline transaction log or if an uncommitted transaction starts from
an offline transaction log), dbmlsync with -do will raise an error and refuse
to run the synchronization.
================(Build #3505 - Engineering Case #471582)================
The MobiLink clients will now include its version and build number with each
synchronization, and the MobiLink server will display this information in
its log. As a result, the MobiLink log will now contain lines like the following:
Request from "Dbmlsync Version 11.0.0.1036 Debug Internal Beta"
for: remote ID: e08b39d1-e3fa-4157-969b-8d8679324c00, user name: template_U1,
version: template_test
instead of lines like this:
Request from "MLSync" for: remote ID: 45ef79ab-195e-4f76-805b-95eef2773e8f,
user name: template_U1, version: template_test
================(Build #3474 - Engineering Case #464303)================
When determining where to begin scanning the transaction log, dbmlsync will
now ignore subscriptions if they do not contain any of the tables that are
currently being synchronized. Previously when building an upload, dbmlsync
scanned the log from the lowest progress value of any subscription involving
the MobiLink user who is synchronizing.
To take advantage of this optimization, you should now define your publications
as disjoint (not sharing any tables) whenever possible. This will result
in a major performance improvement when one subscription is being synchronized
more frequently than another.
For example, suppose publications P1 and P2 share no tables. P2 is synchronized
daily and P1 is synchronized hourly. Each time P1 is synchronized, its progress
is advanced by 1000. The following table shows the segment of log scanned
for each synchronization based on the old and new behavior:
log scanned log scanned
Action P1's progress P2's progress (old behavior) (new behavior)
sync P1 1000 1000 1000-2000 1000-2000
sync P1 1000 2000 1000-3000 2000-3000
sync P1 1000 3000 1000-4000 3000-4000
sync P1 1000 4000 1000-5000 4000-5000
You should be able to define your publications as disjoint except where
two publications contain the same table but with different WHERE clauses.
Defining disjoint publications should never limit functionality because the
dbmlsync -n option can accept a comma separated list of publications which
causes the union of the publications to be synchronized.
For example, suppose table T1 is to be synchronized throughout the day,
and tables T1 and T2 are to be synchronized at the end of the day. Previously,
you might have defined your publications as follows:
- P1 contains T1
- P2 contain T1 and T2.
- Synchronize during the day with the dbmlsync option -n P1
- Synchronize at the end of the day with the dbmlsync option -n P2
In order to take advantage of the new optimization, two publications should
be defined: P1 contains T1, and P2 contains T2. During the day dbmlsync
will synchronize using the -n P1 option. At the end of the day dblmsync
will synchronize using -n P1,P2. This does the same thing, but is much more
efficient with the new log scanning behavior.
================(Build #3838 - Engineering Case #558085)================
The MobiLink server now supports two new command options,
-vR show the remote ID in each logging message
-vU show the ML user name in each logging message
When both -vR and -vU are specified, the MobiLink server will add the remote
ID and the MobiLink user to each message logged:
yyyy-mm-dd hh:mm:ss. <sync_id> ({remote_id},{user_name})
When started with -vR and without -vU, the prefix will be just the remote_id:
yyyy-mm-dd hh:mm:ss. <sync_id> (remote_id,)
and the MobiLink user name will be empty. When started with -vU and without
-vR, the
prefix will be just the user name:
yyyy-mm-dd hh:mm:ss. <sync_id> (,user_name)
and the remote ID will be empty.
The new feature may be useful for MobiLink users who are running the MobiLink
server with the command options -on or -os, as the logging messages for a
synchronization can span multiple MobiLink server logging files, which makes
it is hard to find out the remote ID and MobiLink user name for a given sync
ID from such logs. This extra logging information will only apply to the
synchronization threads. For the main thread of the MobiLink
server, the logging messages will still contain the following prefix,
yyyy-mm-dd hh:mm:ss. <Main>
because there is no remote ID or MobiLink user name for the main thread.
These two command line options will not be affected by the -v+ option, that
is, the MobiLink server will not add the remote ID or the ML user name into
its logging messages, even if the -v+ option is used. Therefore, the description
for the -v+ option
has been changed to - "show all verbose logging specified with lower
case letters".
================(Build #3595 - Engineering Case #486422)================
The MobiLink server for Windows x64 now supports both RSA and ECC stream
encryption. Note that the MobiLink server does not support FIPS-compliant
RSA on Windows x64.
================(Build #3508 - Engineering Case #472237)================
The MobiLink server is now supported on Windows x64. The supported consolidated
databases are SQL Anywhere and Oracle (see Engineering case 472238 for details).
An x64 JRE install is required, which is available at:
http://downloads.sybase.com/swd/detail.do?baseprod=144&client=ianywhere&relid=10260
To install this JRE:
Download and run SA_1001_JRE_UPD.exe. The install will locate an existing
SQL Anywhere 10 installation, and install a Java Runtime Environment for
x64.
To install the x64 MobiLink server:
1) Install the EBF normally on a x64 computer, and then go to Add/Remove
Programs (Programs and Features in Vista), select SQL Anywhere 10 and click
on the Change button.
Check that Modify is selected and click on the Next button.
2) The Select Features dialog will appear and it will show the MobiLink
for x64 features under "MobiLink". 32 bit MobiLink features will
be displayed under "MobiLink (32 bit)".
Check the checkboxes for MobiLink to install MobiLink for x64 and click
on the Next button.
3) Click the Next button on the next dialog to implement the modifications.
4) Click the Finish button on the last dialog to complete the installation.
================(Build #3492 - Engineering Case #468862)================
Previouly, the MobiLink server only supported "blocking download ack"
mode. Now, the MobiLink server also supports "nonblocking download ack"
mode. This mode may be controlled with the "-nba+" (use nonblocking
download ack) or "-nba-" (use blocking download ack) command line
options, with "-nba-" being the default. Nonblocking download acknowledgement
mode provides a significant performance advantage over blocking download
acknowledgement mode, but may not be compatible with some existing scripts.
The following is the documentaion update:
MobiLink now supports two modes of download acknowledgement: blocking and
non-blocking. Prior to this change, MobiLink only supported blocking download
acknowledgement. When you turn on download acknowledgement, the default continues
to be blocking.
Note: Download acknowledgement is not on by default. To turn it on, use
the dbmlsync "SendDownloadACK" extended option or the UltraLite
"Send Download Acknowledgment" synchronization parameter. Download
acknowledgement is not required to ensure that data is successfully downloaded.
Download acknowledgement simply allows you to get acknowledgement of a successful
download immediately (in the download); otherwise the acknowledgement occurs
in the next upload.
To set non-blocking download acknowledgement, use the new mlsrv10 option
-nba+.
Non-blocking download acknowledement is recommended because it provides
a significant performance advantage over blocking download acknowledgement.
However, non-blocking download acknowledgement cannot be used in the following
cases:
- Clients prior to 10.0.0 do not support non-blocking acknowledgement.
- You cannot use non-blocking acknowledgement with the Notifier scripts
that are generated by MobiLink Model mode.
QAnywhere messaging uses non-blocking download acknowledgement. You cannot
change this setting for QAnywhere: You will get an error if you specify both
-m and -nba- on the mlsrv10 command line.
To provide extra optional functionality to the new non-blocking download
acknowledgement, two new MobiLink events have been added: nonblocking_download_ack
and publication_nonblocking_download_ack.
nonblocking_download_ack connection event
-----------------------------------------
Function: When using non-blocking download acknowledgement, this event lets
you update your database based on the successful application of the download.
Parameter name Description Order
-------------- ----------- -----
s.remote-id VARCHAR(128) N/A
s.username VARCHAR(128) 1
s.last_download TIMESTAMP 2
This event is only called when using non-blocking download acknowledgement.
When in non-blocking mode, the download transaction is committed and the
synchronization ends when the download is sent. This event is called when
the synchronization client acknowledges a successful download. This event
is called on a new connection, after the end_synchronization script of the
original synchronization. The actions of this event are committed along with
an update to the download time in the MobiLink system tables.
Due to the special nature of this script, any connection-level variables
set during the synchronization are not available when this event is executed.
For example, the following script adds a record to the table download_pubs_acked.
The record contains the remote ID, first authentication parameter, and the
download timestamp.
INSERT INTO download_pubs_acked( rem_id, auth_parm, last_download )
VALUES( {ml s.remote_id}, {ml a.1}, {ml s.last_publication_download}
)
publication_nonblocking_download_ack connection event
-----------------------------------------------------
Function: When using non-blocking download acknowledgement, this event lets
you update your database based on the successful application of the download
of this publication.
Parameter name Description Order
-------------- ----------- -----
s.remote-id VARCHAR(128) N/A
s,username VARCHAR(128) 1
s.last_publication_download TIMESTAMP 2
s.publication_name VARCHAR(128) 3
s.subscription_id VARCHAR(128) 4
This event is only called when using non-blocking download acknowledgement.
When in non-blocking mode, the download transaction is committed and the
synchronization ends when the download is sent. When the synchronization
client acknowledges a successful download, this event is called once per
publication in the download. This event is called on a new connection and
after the end_synchronization script of the original synchronization. The
actions of this event are committed along with an update to the download
time in the MobiLink system tables.
Due to the special nature of this script, any connection-level variables
set during the synchronization are not available when this event is executed.
For example, the following script adds a record to a table called download_pubs_acked.
The record contains the publication name, the first authentication parameter,
and a download timestamp:
INSERT INTO download_pubs_acked( pub_name, auth_parm, last_download )
VALUES( {ml s.publication_name}, {ml a.1}, {ml s.last_publication_download}
)
================(Build #3474 - Engineering Case #464488)================
The MobiLink server now buffers pending writes more efficiently during HTTP
synchronizations. This change allows the server to use significantly less
memory, which may make for less swapping to disk.
================(Build #3746 - Engineering Case #539813)================
A new command line option (-sv) has been added to the MobiLink Listener to
allow for specifying the script version used for authentication. The default
value is ml_global.
================(Build #3509 - Engineering Case #472228)================
The Mobilink Redirector now support "IIS6 in IIS5 isolation mode".
IIS5 allows processing of multiple persistent HTTP request responses within
a single entry into the web server extension. However IIS6 in IIS5 isolation
mode disallows that possibly due to the stricter HTTP system driver. To work
around this, the redirector will exit the extension after a single request-response
cycle, while persisting the backend connection for later use. This change
should increase concurrency, especially when the backend servers are the
bottleneck.
To turn on IIS5 isolation mode on a IIS6 server using the IIS Manager, right
click on IIS Manager->Web Sites and select Properties. Bring up the Service
page and select the "IIS 5.0 isolation mode".
================(Build #3592 - Engineering Case #483452)================
The IAS Oracle driver requires Oracle's OCI client libraries. If these libraries
are not installed properly, the IAS driver would have silently failed to
load. The driver will now load,, but will fail when first used by an application.
The application can query the failure and will receive an error which indicates
the OCI library is missing.
================(Build #3835 - Engineering Case #556527)================
A new network protocol option 'http_buffer_responses' has been added. When
set to 'On', HTTP packets from MobiLink will be completely streamed into
an intermediary buffer before being processed, instead of processing the
bytes as they are read off the wire.
Syntax: http_buffer_responses = { off | on }
Protocols: HTTP, HTTPS
Default: off
Because of the extra memory overhead required, this feature should only
be used to work-around HTTP sync stability issues. In particular, the ActiveSync
proxy server for Windows Mobile devices will throw away any data that is
not read within 15 seconds after the server has closed its side of the connection.
Because MobiLink clients process the download as they receive it from MobiLink,
there is a chance they will fail to finish reading an HTTP packet within
the allotted 15 seconds causing synchronization to fail with stream error
code STREAM_ERROR_READ, when synchronizing using non-persistent HTTP. By
specifiying 'http_buffer_responses=On', the client will read each HTTP packet
in its entirety into a buffer before processing any of it, thereby beating
the 15 second timeout.
================(Build #3595 - Engineering Case #485478)================
Support has now been added to deploy native amd64/x64 ESQL and C++ applications
to 64 bit Windows platforms (64 bit XP and later). The engine is supported,
as well as static and dynamic versions of the in-process runtime library.
Encryption is also supported, although FIPS is not.
The following new files are included in the install:
ultralite\x64
ultralite\x64\uleng10.exe
ultralite\x64\ulstop.exe
ultralite\x64\mlczlib10.dll
ultralite\x64\mlcrsa10.dll
ultralite\x64\mlcecc10.dll
ultralite\x64\lib
ultralite\x64\lib\vs8
ultralite\x64\lib\vs8\ulrt.lib
ultralite\x64\lib\vs8\ulimp.lib
ultralite\x64\lib\vs8\ulrt10.dll
ultralite\x64\lib\vs8\ulbase.lib
ultralite\x64\lib\vs8\ulrsa.lib
ultralite\x64\lib\vs8\ulecc.lib
ultralite\x64\lib\vs8\ulrtc.lib
ultralite\x64\lib\vs8\ulimpc.lib
ultralite\x64\lib\vs8\ulrtc10.dll
================(Build #3505 - Engineering Case #471339)================
UltraLite clients will now send their version and build number up to the
MobiLink server during synchronization. A line similar to the following
will appear in the server log:
Request from "UL 10.0.0.2862" for: ...
================(Build #3557 - Engineering Case #480217)================
When using UltraLite database for M-Business Anywhere, MIMEList POD may be
used to display data from the database in tabular format. The new feature
is only intended to use with the MIMEList POD. Please note that it is not
supporting the full AGDBSet attributes and methods. The following code snippets
show the two ways to bind to the AGDBSet object:
Example 1: Binding UltraLite table to AGDBSet
connection = databaseManager.openConnection( openParms );
agdbSet = connection.getTableAGDBSet( "ULProduct" );
Example 2: Binding UltraLite result set to AGDBSet
statement = connection.prepareStatement( "select prod_id, prod_name,
price from ULProduct order by price" );
resultSet = statement.executeQuery();
agdbSet = resultSet.getAGDBSet();
================(Build #3886 - Engineering Case #568866)================
The UltraLite Initialize Database utility (ulinit) is used to create an UltraLite
database, based on information in the SQL Anywhere database that it is connected
to. If the schema being extracted from the SQL Anywhere database contained
elements that UltraLite did not support (like column datatypes or default
values), the utility would have failed. Ulinit has been changed so that by
default, it will attempt to create an UltraLite database that comes as close
as possible to the SQL Anywhere database. For example, if a column in the
SQL Anywhere database included the DEFAULT TIMESTAMP clause (a default that
UltraLite does not support), a warning is generated and a default of CURRENT
TIMESTAMP is generated instead. In particular, if a default in the SQL Anywhere
database is not supported in the UltraLite database, the default value is
ignored and creation continues. This enhancement was made because, in some
cases, it’s possible the SQL Anywhere tables cannot be modified, and yet
a reasonable UltraLite alternative is available. The ulinit utility also
now has a –f switch that can be used to make the utility fail if the exact
schema does not match (in other words, the old behavior is given and the
utility will fail).
This fix also addressed a problem where warnings were emitted into the SQL
file if the ulinit utility was run with –l.
================(Build #3616 - Engineering Case #486877)================
When generating the download stream, in very rare circumstances, it was possible
for MobiLink to have incorrectly translated a string if the remote database
used a multi-byte character set. It was likely that the ending byte(s) of
one string would end up at the start of the next string in the same row.
This problem has now been fixed.
================(Build #4075 - Engineering Case #630073)================
The contents of the combobox in the "Schedule Editor" window could
have been truncated on some systems, depending on which font was being used
by Sybase Central. This has been fixed.
================(Build #4060 - Engineering Case #626459)================
A UDP Gateway's property sheet would have shown the default destination port
as -1. This has been corrected so that the correct value of 5001 is now shown.
================(Build #4057 - Engineering Case #625625)================
Sybase Central would have generated an error when attempting to create a
notifier, gateway or carrier with any of the following characters in its
name: '[', ']', '^', '%', '_'. A similar error would have occurred when attempting
to rename a notifier, gateway or carrier and any of these characters were
used in the new name. This has been fixed.
================(Build #4052 - Engineering Case #624574)================
Attempting to connect to a newly created message store at the end of the
Client Store wizard could have failed there already was network server running
the computer and its "-gd ALL" option was not used. This has been
fixed.
================(Build #4046 - Engineering Case #622889)================
When entering a file location in the Deploy Synchronization Model wizard,
typing in a file name that did not include the folder would have resulted
in an error when clicking Next. This has been fixed. A workaround is to specify
the folder.
================(Build #3993 - Engineering Case #606888)================
When redeploying a synchronization model to a SQL Anywhere remote database
using the wizard initialized with the last settings, the extended options
for the SQL Anywhere client could have been corrupted. This has been fixed.
================(Build #3951 - Engineering Case #587246)================
If a synchronization model was created that contained mappings with errors,
and then the mappings were deleted or disableds, the sync model could still
not have been deployed. The workarounds to this were to either recreate or
enable the mapping, or manually edit the sync model file and remove the scripts
with errors. This has been fixed.
================(Build #3894 - Engineering Case #558915)================
When deploying a Synchronization Model to file, any characters in .SQL files
that are not supported by the OS console code page would be changed to a
substitution character, even though the character would have been displayed
correctly in the MobiLink plug-in. This has been fixed so that .SQL files
now use UTF-8 character encoding. The generated .bat or .sh file is still
written using the console code page, since it must run in a console, but
the UTF-8 character encoding is now specified when the Interactive SQL utility
is invoked in the .bat or .sh file.
================(Build #3891 - Engineering Case #571282)================
When creating a synchronization model, if a custom download subset was choosen,
without specifying one or more tables to join, then the download_cursor events
would not have been generated. Instead errors like the following would have
appeared as comments in the Events editor:
/*
* ERROR: Unexpected error encountered while generating event.
* Error for: RHS of #set statement is null. Context will not be modified.
table-scripts\download_cursor.vm
* [line 59, column 8]
*/
This problem only happened in the New Synchronization Model wizard, not
when custom download subset was enabled in the Mappings editor. The problem
has been fixed for new synchronization models.
To work around the problem, in the Mappings editor change the Download Subset
(Dnld. Sub.) to None and then back to Custom, then switch back to the Events
editor.
================(Build #3890 - Engineering Case #570923)================
If a database error occurred when trying to install or update the MobiLink
System Setup, the error message would have included the SQL statement that
was being executed, which could have lead to the message box being too large
for the screen. This has been fixed. Now the SQL statement is only shown
when the Details are shown.
================(Build #3853 - Engineering Case #559653)================
When connected to an authenicated SQL Anywhere database from the MobiLink
plug-in in Sybase Central using the "Generic ODBC DSN" option,
the connection would have been read-only. This has been fixed.
================(Build #3830 - Engineering Case #555007)================
Sybase Central could have crashed when attempting to change the visible columns
(via View -> Choose Columns...), or column widths, while the MobiLink
11 node was selected in the tree. In addition, when in Model mode, the list
of columns under the View -> Sort menu would sometimes not have contained
all the displayed columns when the MobiLink 11 node was selected in the tree.
Both of these issues have now been fixed.
================(Build #3782 - Engineering Case #546869)================
The property sheet for connectors contained a "Transmission Rules"
page. This was incorrect because connectors do not have transmission rules;
they have delivery conditions. As a result, that page has been replaced with
a new "Delivery Conditions" page in which the single delivery condition
for the connector can be typed.
================(Build #3756 - Engineering Case #542239)================
If the Admin Mode Connection Script wizard was used to create event scripts
for handle_UploadData and handle_DownloadData events, they would get an "unknown
event" error when syncing. The problem was that the event scripts were
created with the names "handle_uploaddata" and "handle_downloaddata"
(note the differences in case). This has been fixed.
================(Build #3722 - Engineering Case #535973)================
Changes made to property values on the "Client Properties" page,
in a server message store's property window, would not have been saved if
the client was "(Default)". This has been corrected so that they
are now saved correctly.
Also, if connecting using a QAnywhere connection profile was not possible,
Sybase Central would have crashed rather than reporting the error. This has
been corrected as well.
================(Build #3717 - Engineering Case #534320)================
Sybase Central could have crashed while using the QAnywhere plugin, if the
connection to a server message store was unexpectedly lost. This has been
fixed.
================(Build #3712 - Engineering Case #481976)================
When creating a new synchronization model for an existing remote database,
the column order may not have been correct for upload_fetch or upload_fetch_column_conflict
events. This has now been fixed. To fix existing synchronization models (after
installing this fix), each synchronizing table must be set to 'Not Synchronized',
the model saved, and then set back to their previous synchronization settings.
================(Build #3707 - Engineering Case #532452)================
The changes for Engineering case 530534 (which was a followup fix to Engineering
case 491400) were incomplete, resulting in the Overview marquee not updating
when zoomed out with the marquee at the leftmost position. This has been
fixed.
================(Build #3686 - Engineering Case #482703)================
The installed version of the MobiLink system setup could not have been found
by the Sybase Central MobiLink Plug-in for Microsoft SQL Server when the
default_schema was different than the connected user. This has been fixed
so that when checking schema with a Microsoft SQL Server consolidated database,
the default_schema is now used.
Note, a work around is to make the current user the owner of the MobiLink
system setup.
================(Build #3684 - Engineering Case #499301)================
When using the New Remote Tables command to add a table to a remote schema
in a synchronization model, if the consolidated table had columns matching
the timestamp column for timestamp-based download, or logical delete column
for logical deletes, then an invalid column mapping would have been created.
This would have caused script generation errors. This has been fixed. A work
around would be to create a new sync model.
================(Build #3678 - Engineering Case #496106)================
When deploying a Synchronization Model to a Microsoft SQL Server database,
in which the name of the table owners were different then the current user's
username, an error would have occurred. This has been fixed.
================(Build #3662 - Engineering Case #495225)================
When editing a synchronization model, if one or more rows in the column mapping
editor were marked for deletion, attempting to revert changes to the model
could have caused Sybase Central to crash. The same problem could have occurred
when attempting to select another item in the tree and answering "No"
to the "Do you want to save changes?" dialog. This has now been
fixed.
================(Build #3650 - Engineering Case #492960)================
Server-initiated synchronization requires the SendDownloadAck extended option
to be enabled, but this would not be enabled for a SQL Anywhere remote database
that had been setup for SIS through deployment from a synchronization model.
This has been fixed. The workaround for this is to enable SendDownloadAck
on the remote advanced options page when deploying.
================(Build #3619 - Engineering Case #487721)================
When IMAP, POP3 or LDAP authentication was enabled for a synchronization
model, the generated authenticate_user event would have used the incorrect
case for the class name, and the generated MobiLink server command line would
not have enabled Java scripts with mlsupport.jar in the class path. Both
problems have been fixed. The workaround is to manually fix the script and
command line.
================(Build #3615 - Engineering Case #486574)================
When deploying a synchronization model, statements to create triggers did
not specify the owner (or schema) for the trigger, so permission problems
and invalid triggers could have resulted when deploying as a different user
than the table owner. This has been fixed so that the owner, or schema, is
now specified in the generated SQL for creating and dropping triggers for
Oracle, Microsoft SQL Server, ASE and DB2 consolidated databases. In SQL
Anywhere databases, a trigger is always owned by the same owner as the table,
so the problem did not occur.
A workaround is to deploy to a SQL file and manually edit the SQL.
================(Build #3603 - Engineering Case #485380)================
In the Create Synchronization Model wizard, if 'Download Subset by User or
Remote ID' used a column in the same table, it would only have been enabled
for tables where the column was also synchronized, and was a string type.
This has been fixed. Now the column must only exist in the consolidated table.
Note that the chosen column's type should be able to be implicitly compared
with a string, or errors may occur when downloading with the generated download
script.
================(Build #3594 - Engineering Case #484295)================
If a synchronization model was used to create timestamp-based downloads with
an Oracle consolidated database, and the MobiLink server used a different
timezone than the consolidated database, then some data might not have been
downloaded. The problem was that the trigger generated to maintain the last-modified
time used CURRENT_TIMESTAMP, which uses the client's timezone. This has been
fixed so that the generated triggers now use SYSTIMESTAMP (which uses the
consolidated database's time zone.) A workaround is to manually change the
trigger, either in a generated SQL file or deployed in an Oracle consolidated
database.
================(Build #3583 - Engineering Case #483335)================
When entering a multi-line rule condition, it would have been saved in a
way that caused the line to appear to have been run together when the line
was next edited. This has been fixed.
================(Build #3522 - Engineering Case #473860)================
If a synchronization model was deployed with HTTPS or TLS as the stream type,
the generated batch file for starting the MobiLink server could have given
an "Unable to convert the string <string> to a numeric value"
error, because the stream parameters were incorrectly separated by commas
instead of semi colons. This has been fixed.
A workaround is to edit the generated batch file to use semicolons instead
of comma for the stream parameters by changing this line:
set STREAM="%STREAM_TYPE%(port=%PORT%,tls_type=%TLS_TYPE%,fips=%FIPS%,certificate=%CERTIFICATE%)"
to the following:
set STREAM="%STREAM_TYPE%(port=%PORT%;tls_type=%TLS_TYPE%;fips=%FIPS%;certificate=%CERTIFICATE%)"
================(Build #3510 - Engineering Case #472503)================
Deploying a synchronization model created with an exisiting UltraLite database
could have caused an error. This problem has been fixed.
================(Build #3497 - Engineering Case #469851)================
If a rule was created whose condition expression contained a newline character,
once saved to a ".qar" file, the file could not have been read
properly. Embedded newlines were not being escaped with the line continuation
character when they were written. This has ben fixed so that the condition
is now saved correctly.
================(Build #3475 - Engineering Case #465042)================
The way destination aliases are handled by the QAnywhere server changed in
version 10.0.1 in a way that the plug-in didn't handle correctly. The list
history entries for multi-addressed messages were including all of the messages
sent to the alias members. This has now been fixed so that only those history
entries whose addresses match the destination address shown in the Messages
panel are shown.
================(Build #3474 - Engineering Case #464834)================
The "Start Agent" menu item associated with a .QAA file was missing
a keyboard mnemonic. This has been correct so that it now has one.
================(Build #3474 - Engineering Case #464348)================
The following predefined variables, ias_Originator and ias_StatusTime, were
missing from the list of predefined variables listed in the Rule dialog used
when composing deletion or transmission rules. This has been fixed.
================(Build #3470 - Engineering Case #462939)================
In order to not miss conflicts, the upload_fetch and upload_fetch_column_conflict
scripts need to prevent modification of the rows it has selected before they
are updated. Previously, for SQL Anywhere consolidated databases, the upload_fetch
and upload_fetch_column_conflict scripts generated for a model with conflict
detection used the HOLDLOCK table hint. Now these scripts use the UPDLOCK
table hint. For scripts deployed to a SQL file already, replace HOLDLOCK
with WITH (UPDLOCK) in the upload_fetch and upload_fetch_column_conflict
scripts.
================(Build #4073 - Engineering Case #629597)================
The initial position of the main window for the MobiLink Monitor could have
placed the window underneath the Windows task bar. This has been fixed.
Note, this problem also affected the Interactive SQL utility, Sybase Central,
and the SQL Anywhere Console utility.
================(Build #3856 - Engineering Case #562833)================
When the MobiLink Server had a large number of synchronizations running concurrently
(in the range of 10000), a MobiLink Monitor connected to it could have become
unresponsive, and not displayed new information in a timely manner. This
has been fixed.
================(Build #3839 - Engineering Case #554383)================
In the MobiLink Monitor Details Table, if the optional column "connection_retries",
or optional columns starting with "download_" or "sync_",
were enabled, the column labels for these columns would have been misaligned
by one or two columns. A similar problem would have occurred when exporting
to a database, where that data was exported to incorrect columns in the database
tables. Both of these problems have been fixed.
================(Build #3836 - Engineering Case #556925)================
The fix for Engineering case 553312, may have prevented restarting the MobiLink
Monitor after disabling the Details Table, Utilization Graph, or Overview
panes. This has been fixed. Pane sizes are now also properly restored when
re-enabling after restarting.
================(Build #3818 - Engineering Case #553312)================
If the MobiLink Monitor's Details Table, Utilization Graph, or Overview panes
were disabled, when reenabled they might not be visible, under some circumstances,
or a program error may have occurred. Also, resizing a pane or the application,
could have produced unexpected results. These problems have been fixed. Now
when resizing the application, only the Chart pane size is changed; and when
resizing a pane, only the panes on either side of the splitter bar are affected.
================(Build #3790 - Engineering Case #548455)================
When attempting to export synchronized data to an Oracle database, the application
could have given a false positive for a table's existence, which would have
resulted in an export failure since it would not have tried to create the
table for the current user. This has been fixed.
Also, exports to Oracle previously used the Date data type. Now, for Oracle
9 or later Timestamp is used instead of Date.
================(Build #3737 - Engineering Case #539499)================
If the Overview, Details Table or Graph were disabled in the MobiLink Monitor,
closing the Monitor and restarting it would have resulted in a Java null
pointer exception. This has been fixed. A workaround is to edit the settings
file (.mlmMonitorSettings in version 10 and earlier, .mlMonitorSettings11
in version 11) to restore display of the disabled feature. For the Overview,
change ShowOverview=false to ShowOverview=true. For the Table, change ShowTable.
For the Graph, change ShowGraph.
================(Build #3731 - Engineering Case #538156)================
Long running MobiLink Monitors could have hang or crashed with a RuntimeException
"the monitor doesn't send any-order commands". This has been fixed.
================(Build #3693 - Engineering Case #530534)================
The changes made for Engineering case 491400, to correct a problem with the
marquee in the overview panel flashing excessively when connected to a MobiLink
server, introduced drawing artifacts when the horizontal scroll bar was used
to move the marquee. This has been fixed.
================(Build #3642 - Engineering Case #491400)================
The marquee in the overview panel would have flashed excessively when connected
to a MobiLink server. This has been fixed. A workaround is to drag out the
marquee to a new region, or to pause the auto scrolling.
================(Build #3553 - Engineering Case #478704)================
When connecting to a MobiLink server via HTTP or HTTPS, the Monitor sent
more HTTP or HTTPS requests than necessary. Excessive flushing caused most
requests to be shorter than they should have been. This has been fixed.
================(Build #3531 - Engineering Case #475263)================
The MobiLink Monitor could have failed with a NegativeArraySizeException.
The failure was more likely when under very heavy load. This has now been
fixed.
================(Build #3984 - Engineering Case #605417)================
The QAManagerFactory.getInstance() method of the QAnywhere .NET client would
have thrown the exception System.DllNotFoundException when the native library
qany9.dll or qany10.dll was missing. This exception may have been unexpected
by a QAnywhere application, and has now been fixed. A QAException is now
thrown in this situation, with ErrorCode 1000 (QAException.COMMON_INIT_ERROR)
and Message containing the System.DllNotFoundException.
================(Build #3715 - Engineering Case #533612)================
On a slow devices, the QAnywhere client (qaagent) would sometimes have given
the following error messages at start up: "Error registering with DBLSN
code: -1" and "Failed to start QAnywhere Agent (register with DBLsn)".
This has been fixed so that the QAnywhere client is now much more tolerant
to lengthy dblsn startup times.
================(Build #3715 - Engineering Case #533249)================
The download phase of a synchronization could have failed with a -194 error
("No primary key value for foreign key"). This was most likely
to have occurred during large synchronzations or when the database engine
is under considerable stress. This has now been fixed.
================(Build #3703 - Engineering Case #531730)================
After modifying the incremental download size of the QAnywhere Agent using
the -idl option, it would not have been possible to reset the size to the
default value of -1. Attempting to set the size to -1 would have left the
incremental download size unchanged.
This has been fixed. Now, specifying any non-positive number for the -idl
option will reset the incremental download size to -1.
================(Build #3679 - Engineering Case #496969)================
When the QAnywhere Agent was running on a device that was not connected to
a network, each time a QAnywhere application queued a message the CPU usage
increased slightly. This has been fixed so that now, when the device is
not connected to a network, queueing a message uses about the same amount
of CPU regardless of whether or not the QAnywhere Agent is running. Moreover,
the required CPU usage stays constant as messages are queued.
================(Build #3661 - Engineering Case #494356)================
A QAnywhere .NET application could have hung if a QAManager API method was
interrupted by an exception in one thread and another thread subsequently
called a method on the QAManager that was interrupted. This has been fixed.
================(Build #3641 - Engineering Case #491104)================
Any modifications to the client message store properties, after the clients
first synchronization, would not have been propagated to the server message
store as expected.
This had been fixed.
================(Build #3641 - Engineering Case #490862)================
A QAnywhere .NET application could have crashed with a memory access vio;ation
when terminating. This was due to a race condition, which has been fixed.
================(Build #3601 - Engineering Case #485588)================
The QAnywhere Agent could have used an excessive amount of memory during
message transmission when a large number of messages were queued. This has
been fixed.
================(Build #3592 - Engineering Case #484359)================
If a user was using the QAnywhere SQL API to receive messages asynchronously
with the ml_qa_listen_queue procedure, and another user using the same message
store sent a message to this queue (ie. local messaging), the message would
not have been received.
This has been fixed.
================(Build #3592 - Engineering Case #484293)================
When using the QAnywhere Client SQL API to receive messages, they would not
have been synchronized back to the originator. This caused the messages to
remain in the "Pending" state indefinitally on the originating
client, and on the server. This has now been fixed.
================(Build #3592 - Engineering Case #484272)================
The QATransactionalManager class would have failed to re-receive a message
with large content (exceeding MAX_IN_MEMORY_MESSAGE_SIZE in size) after it
was received once and a rollback was done. This problem applied to the C#,
Java and C++ QATransactionalManager classes. This has now been fixed.
================(Build #3592 - Engineering Case #484266)================
The QAnywhere Agent and MobiLink Listener could have crashed when started
with the "@file" command line option, if "file" did not
exist. This has been fixed.
================(Build #3580 - Engineering Case #480759)================
When making a call to a QAManager with the DBF and AutoStart connection parameters,
the database server would not have been autostarted. Instead, a -101 error
"not
connected" would have been logged by the QAManager, but was not reported
back to the application. It should be noted that a QAManager will autostart
the database server when the Open method is called. The issue was that when
the database server was shut down after Open had been called, then subsequent
QAManager operations would have failed because the database connection had
been terminated, but the error codes returned to the application do not indicate
that the connection to the database was bad, thus not allowing the application
to Close and Open the QAManager to recover from the error. This has been
fixed. If the ErrorCode of a QAException is greater than or equal to 2000,
then the error means the same as ErrorCode - 1000, and also that a database
connection failure has occurred (ie. SQL Anywhere native code -101). When
a database connection error is detected, it is possible to re-Open a QAManager
without recreating it and setting its properties and message listeners again.
This is done by calling Close() then Open() again. Note that the properties
of the QAManager cannot be changed after the first Open() and subsequent
Open() calls, and must supply the same acknowledgement mode.
================(Build #3566 - Engineering Case #481022)================
A Java mobile webservices application compiled with JDK 1.5 could have failed
with an error at the server saying "'SOAP-ENV' is an undeclared namespace."
This has been fixed.
Note that because the mobile webservices runtime (iawsrt.jar) is built with
JDK 1.5, Java mobile webservices applications must be compiled with JDK 1.5
and up as well.
================(Build #3510 - Engineering Case #472920)================
A mobile webservices client application could have failed with a NullReferenceException
when processing a SOAP response that contained elements described as <any>
in the WSDL description. This has been fixed.
Note: this problem occurs when processing <row> elements contained
within <SimpleDataset> elements in result sets returned by SQL Anywhere
SOAP services.
================(Build #3501 - Engineering Case #470812)================
If the QAnywhere Agent was started with a custom policy (ie. transmission
rules) where each rule was a scheduled rule, QAnywhere would still have behaved
as though the policy was automatic. The messages put in a queue would have
been transmitted immediately, and push notifications would have resulted
in an immediate message transmission, instead of message transmissions happening
on the defined schedule. This has been fixed so that the transmission rules
are now all scheduled rules, message transmissions happen only at the scheduled
times.
================(Build #3494 - Engineering Case #469146)================
If the return type of a method in a WSDL document contained the method name,
the WSDL compiler would have generated an incorrent C# method signature for
the asynchronous method call.
For example:
public WSResult AsyncCategoryBrowseResponseResponse CategoryBrowse(CategoryBrowseRequest
request) // incorrect
should be:
public WSResult AsyncCategoryBrowse(CategoryBrowseRequest request)
// correct
A problem with the generation of asynchronous C# method signatures has been
corrected.
================(Build #3493 - Engineering Case #469002)================
When run on Windows CE, the reserved stack sizes for all threads in the QAnywhere
agent, the Listener and the MobiLink client have been changed to be as follows:
qaagent.exe: 64 KB
dblsn.exe: 64 KB
dbmlsync.exe: 128 KB
Previously, 1MB per thread of address space was reserved, while only a portion
was actually allocated, or "committed".
================(Build #3492 - Engineering Case #468735)================
If a QAnywhere message in the server database with an expiration date, was
synchronized down to a client device before it had expired, the message would
not have transitioned to an expired state, and hence would not have been
deleted by the default server delete rule. This has been fixed.
Note that a QAnywhere message in the server database with an expiration
date, that is not delivered to the client device before it expires, will
also transition to an expired state and be deleted by the default server
delete rule. This was the case before this change.
================(Build #3492 - Engineering Case #467246)================
When there were a large number of messages in the message store that were
ready for transmission (eg. 200 12KB messages), and the QAnywhere Agent was
started on a Windows Mobile 5 device, the synchronization process would have
consumed 100% CPU for a significant period of time (eg. 1 minute). Further,
if the upload failed after it had started, for whatever reason, each subsequent
synchronization would have consumed CPU for a longer period each time. This
performance problem has now been significantly alleviated so that synchronizations
with QAnywhere will not get progressively longer after upload failures.
================(Build #3489 - Engineering Case #467712)================
A .NET application would have crashed when trying to send a text message,
if the QAManager is closed. Problems with detecting that message repository
objects were open have been corrected. Now, the message: "The QAManager
is not open." (error code 1021) will be returned.
================(Build #3478 - Engineering Case #465708)================
After it has started all necessary processes, the QAnywhere Agent now prints
a line like this to the console window and log file:
I. 2007-04-11 11:21:54. There are 23 processes running
This is useful in diagnosing problems on Windows CE devices with Windows
Mobile 5, and previous OSes, because there is a fixed limit of 32 processes
that can be running at once. After that, the OS will start shutting down
applications in a not completely deterministic way.
================(Build #3474 - Engineering Case #461846)================
It was possible for QAnywhere applications to get into a state where calls
to GetQueueDepth would have taken an usually long time to return, and eventually
have thrown a QAException "error getting queue depth". If a device
crashed, or was powered off while the QAnywhere Agent was marking messages
to be uploaded, a flag was left set that GetQueueDepth checked. This problem
has been fixed by adding code to reset the flag in appropriate circumstances.
================(Build #4012 - Engineering Case #614034)================
When a 9.0.2 QAnywhere client synchronized, the MobiLink server would have
displayed the following errors:
Expecting 1 parameters in script, but only found 4: update ml_qa_global_props
set modifiers = ?, value = ? where client = ? and name = ?
Unable to open upload_update .
This has been fixed by a change to the upload_update script for the table
ml_qa_global_props, version ml_qa_2.
================(Build #3970 - Engineering Case #593120)================
The QAnywhere server could have stopped sending and receiving messages with
an Enterprise Messaging Server, through its JMS connector, when connectivity
to the EMS was interrupted and subsequently restored. This has been fixed.
================(Build #3952 - Engineering Case #585035)================
The QAnywhere server could have stopped sending/receiving messages with an
Enterprise Messaging Server, through its JMS connector, when a SQLException
was thrown by the JDBC driver. This has been fixed.
Where possible, the QAnywhere server should recover gracefully from exceptions
thrown by the JDBC driver and continue processing messages.
================(Build #3800 - Engineering Case #550080)================
In the Sybase Central QAnywhere Plugin, if when connected to a server message
store a client was created, and then the view refreshed, the newly created
client would not have been displayed. This has been fixed.
================(Build #3779 - Engineering Case #546171)================
When a delivery condition that referenced message properties was specified
for a QAnywhere connector, message transmission to the connecting messaging
system would have been disabled. This has been fixed.
================(Build #3779 - Engineering Case #546164)================
During the execution of server transmission rules, it was possible for the
QAnywhere server to repeatedly report a java.util.NoSuchElement exception,
and abort the rule execution. This has been fixed.
================(Build #3775 - Engineering Case #545690)================
When a message was sent to a destination alias, the QAnywhere Server may
not have immediately generated push notifications for some members of the
alias. This could have resulted in the server taking as long as a minute
to push notifications to clients. This has been fixed.
================(Build #3772 - Engineering Case #467274)================
When a QAnywhere application (using SQL Anywhere as the message store) queued
messages in time zone A, and then the time zone of the device was changed
to time zone B with time earlier than time zone A, the queued messages would
not have been transmitted until the time in time zone B reached the time
that the messages were queued in time zone A. This has been fixed so that
the messages queued in time zone A are now sent immediately when the device
is online in time zone B.
Note that the issue of time zone independence with QAnywhere has not been
completely addressed. All time values used in transmission rules refer to
local time. Also, the special variable ias_StatusTime, used in transmission
rules, refers to local time.
================(Build #3727 - Engineering Case #537595)================
The changes for Engineering case 534179 introduced a problem where the QAnywhere
Server's logging messages could have been output as garbled text. This has
now been corrected.
================(Build #3715 - Engineering Case #533728)================
A small window of opportunity existed in the QAnywhere server where a statement
could be closed and removed from the statement cache, just as another thread
was preparing the statement to be closed. This resulted in some operations
being performed on a closed statement, resulting in a JDBC error. This has
been fixed
================(Build #3705 - Engineering Case #531967)================
The QAnywhere Server would have throw an ObjectRepositoryException if it
was configured to use a delete rule with an empty condition clause. That
is, if a rule was given that had nothing written to the right of the equals
sign. One such rule might look like: "AUTO=" This has been fixed.
Specifying an empty condition clause now specifies that all available messages
should be deleted.
================(Build #3703 - Engineering Case #531766)================
If a JMS message bound for a QAnywhere client was missing its native address,
and no default address was specified for the JMS connector, the QAnywhere
Server would have reported a NullPointerException. This has been fixed. The
server now reports the proper error message
================(Build #3691 - Engineering Case #523757)================
The QAnywhere Server did not always report errors after processing a badly
formatted Server Management Request (SMR). The SMRs that suffered from this
problem were those that contained any XML elements that did not exactly match
those expected by the server (ie, misspelled elements, or elements not included
in the DTD), in which case the processing of the request would fail silently.
This has been fixed so that the QAnywhere server will now report an error
whenever it comes across an unrecognized XML element. The QAnywhere server
will now also validate the XML elements in a case insensitive way. As long
as the opening tag matches the closing tag, the case is ignored.
================(Build #3686 - Engineering Case #499959)================
With ASA databases the QAnywhere server caches prepared statements to avoid
re-preparing them on each statement execution. During periods of high activity
however, the server could have reported "Resource governor for 'prepared
statements' exceeded", followed by the failed execution of a SQL statement.
This problem has now been fixed.
================(Build #3618 - Engineering Case #487581)================
Initializing a scheduled transmission rule containing an "EVERY"
clause and a "START DATE" clause set to a date that had already
passed, in the QAnywhere server or
in the QAnywhere Ultralight Agent, would have caused the rule to be immediately
and repeatedly executed many times on startup. This has been fixed.
================(Build #3608 - Engineering Case #486050)================
Logs created during the nonblocking_download_ack synchronization event were
being logged with the logger source name of "ianywhere.unknown.category",
instead of the remote id name of the client being synchronized as expected.
This has been fixed.
================(Build #3590 - Engineering Case #478153)================
When the MobiLink server was running with QAnywhere messaging enabled and
a JMS connector was configured and there is a high volume of JMS traffic
between QAnywhere clients and a JMS system, the Java VM running in MobiLink
would have used a continuously increasing amount of heap memory and may eventually
have reached an out-of-memory condition. This has been fixed.
================(Build #3581 - Engineering Case #482742)================
QAnywhere documentation lists IAS_TEXT_CONTENT and IAS_BINARY_CONTENT as
constants a that can be used to refer to the two different message content
types in selector, transmission, and delete rules. However, the QAnywhere
server was recognizing the constants IAS_TEXTCONTENT and IAS_BINARYCONTENT
instead. This would have caused rules using the documented constants to not
work as desired. This has been fixed so that both constant formats are now
recognized.
================(Build #3581 - Engineering Case #482741)================
If a QAnywhere Server Management Request was used to cancel messages in a
Server Store, messages were cancelled even after they had already been downloaded
to the message recipient. This could cause consistency problems in the server
store and possibly disable message transmissions on the receipient device.
This has been fixed.
================(Build #3562 - Engineering Case #480532)================
The QAnywhere server's logging mechanism was allocating a large amount of
additional memory for each new client. This could have caused the Moblink
server to run out of memory when working with a large number of clients.
This has been fixed.
================(Build #3557 - Engineering Case #477156)================
When a large number of clients (more than 2500) had contacted the MobiLink
server, with all indicating they wished to receive push notifications, the
server would have consumed a large amount of CPU evaluating transmission
rules. This has been fixed.
NOTE (for 9.0.2 only): It is also important to run the MobiLink server
with the command line option
-sl java ( -Dianywhere.qa.db.upgradeDeliveryColumns=true )
in order to get the most out of this performance improvement. This option
causes the MobiLink server to reorganize the QAnywhere message store tables,
and add further indexes to these tables, to obtain optimal performance of
MobiLink with QAnywhere.
================(Build #3547 - Engineering Case #477294)================
There was a security issue with logging on the QAnywhere client during initialization.
This has been fixed.
================(Build #3513 - Engineering Case #472632)================
Messages with a NULL originator in the server message store, would have caused
message processing to halt. This has been fixed as follows: the QAnywhere
Agent has been changed so that messages with a NULL originator will not be
uploaded until the store ID is set on the client. The QAnywhere connector
has been changed so that if a message with NULL originator somehow gets into
the server message store, the message will be marked as unreceivable and
skipped, not halting further message processing.
================(Build #3508 - Engineering Case #471045)================
The memory usage of the MobiLink server with QAnywhere messaging enabled
would have increased by a small amount at each client synchronization. The
amount of increase was reduced by about 90% by changes made for Engineering
case 471798. This increase has now been reduced by a further 5%. While not
completely resolved, the memory increase has been significantly reduced,
and it continues to be addressed.
================(Build #3475 - Engineering Case #465712)================
When running the consolidated database on a server that uses snapshot isolation
(Oracle 10g for example), it was possible that MobiLink would have redelivered
messages to QAnywhere clients that were previously received and acknowledged.
This problem would have occurred when there was a long-running transaction
on the consolidated database, which caused the last_download_timestamp to
stay fixed at the time that the transaction began. It has now been fixed.
================(Build #4051 - Engineering Case #624021)================
The documentation erroneously indicated that for Windows and Windows CE,
if no trusted certificates were provided, MobiLink clients would automatically
load the certificates from the OS's trusted certificate store. This feature
has now been implemented.
================(Build #3894 - Engineering Case #572196)================
It was possible for the MobiLink client (dbmlsync) to have sent an incorrect
last download timestamp up to the MobiLink server, if dbmlsync had been running
on a schedule, and ALL of the following had occurred during the last synchronization
:
1) All of the data in the download stream had been applied, but had not
yet been committed to the remote database.
2) An SQL Error had been generated by dbmlsync before the download had been
committed. Examples of errors that could have occurred include an error occurring
in the sp_hook_dbmlsync_download_ri_violation or the sp_hook_dbmlsync_download_end
hooks, or an error occurring as dbmlsync had attempted to resolve referential
integrity issues.
3) Another hook had been defined in the remote database that would have
executed on another connection. For example, the sp_hook_dbmlsync_download_log_ri_violation
or the sp_hook_dbmlsync_all_error hooks would have executed on a separate
connection.
This problem has now been fixed, and the proper last download timestamp
is now sent up to the MobiLink server in the synchronization when this situation
occurs.
================(Build #3887 - Engineering Case #570503)================
When using secure streams and an invalid TLS handshake occured, the MobiLink
server could have waited for a full network timeout period before disconnecting.
This has been fixed. The MobiLink server will now immediately terminate the
network connection with a "handshake error" error message.
================(Build #3865 - Engineering Case #563844)================
The MobiLink client (dbmlsync) would have occationally reported the error:
Failed writing remote id file to '<filename>'
Despite the error, synchronizations would have continued successfully, and
the remote id file would have appeared on the disk in good order. This problem
has been fixed.
================(Build #3853 - Engineering Case #562027)================
When running on Sun SPARC systems, the MobiLink client (dbmlsync) would have
complained about "missing transaction log files", if there were
any offline transaction log files bigger than 2GB. This problem now been
fixed.
================(Build #3849 - Engineering Case #560943)================
The dbmlsync ActiveX component was not able to launch the dbmlsync application
properly on Windows if some or all of the dbmlsync options are given by a
file, and the dbmlsync command line contained the option @filename. This
problem has now been fixed.
================(Build #3831 - Engineering Case #555444)================
When synchronizing using HTTPS through an HTTP proxy, MobiLink clients would
have incorrectly appended the url_suffix to the HTTP CONNECT request, which
could have caused some proxies and servers to fail. This has been fixed.
================(Build #3822 - Engineering Case #580190)================
If an error had occurred while the MobiLink client (dbmlsync) was applying
a download, and there had also been referential integrity errors that dbmlsync
could not resolve, then dbmlsync would have reported that the download had
been committed, even though it had been rolled back. This has been corrected
so that dbmlsync now correctly reports that the download was rolled back.
================(Build #3821 - Engineering Case #554271)================
If the MobiLink client (dbmlsync) was run against a database with a character
set that was different from the operating system's character set, then errors
generated by the database would have been garbled when displayed in the dbmlsync
log. This has been corrected so that these messages will now be displayed
correctly.
================(Build #3773 - Engineering Case #544956)================
If MobiLink Client was performing a synchronization, and the status of the
last synchronization was unknown, it was possible for the MobiLink Server
to have reported that the synchronization had started twice. The MobiLink
Log with no extra verbosity might contain the following messages:
Request from "Dbmlsync Version 10.0.1.3750" for: remote ID:
rem1, user name: rem1, version: v1
Request from "Dbmlsync Version 10.0.1.3750" for: remote ID:
rem1, user name: rem1, version: v1
Synchronization complete
This problem has been fixed.
================(Build #3755 - Engineering Case #542185)================
When the properties of the visual or non-visual version of the Dbmlsync ActiveX
Component were examined from a development environment, it would incorrectly
have been described as "iAnywhere Solutions Dbmlsync ActiveX Component
9.0.1". The string has now been changed to properly reflect the true
version of the component.
================(Build #3741 - Engineering Case #540407)================
In the dbmlsync log file it was possible for a message to occasionally be
omitted, or for two messages to be mixed together. For example, a line like
the following might occur in the log:
E. 2008-08-06 16:24:34. Timed out trying to readTimed out trying to
read 7 bytes.
This has been fixed.
================(Build #3734 - Engineering Case #538936)================
The Dbmlsync Integration Component could have crashed during a call to the
Run method. As well, the OS would sometimes have detected a heap error. This
has been fixed.
================(Build #3715 - Engineering Case #533746)================
If a download was interrupted by a network failure, it was possible for the
MobiLink client (dbmlsync) to fail to create a restartable download file.
Furthermore, dbmlsync would have displayed a network error to the dbmlsync
log, but then attempted to apply the partial download, which would almost
certainly have failed. This has been fixed so that dbmlsync now creates a
restartable download file and does not attempt to apply the partial download.
================(Build #3708 - Engineering Case #546742)================
The MobiLink client (dbmlsync) could have crashed when reporting certain
TLS or HTTPS errors. Certain TLS errors could have caused a null pointer
dereference during creation of the error message string. This has now been
corrected.
================(Build #3628 - Engineering Case #488862)================
The MobiLink client could have reported internal error 1003 during , and
would have most likely occurred when the increment size was quite large,
or if the server was slow to apply the upload. This has now been corrected.
================(Build #3620 - Engineering Case #486539)================
A synchronization could have failed with the error:
- Could not find subscription id for subscription of <ML user> to
<publication>.
or
- SQL statement failed: (-101) Not connected to a database
if all the following were true:
1) the synchronization was scheduled and the time before the next scheduled
sync was more than a 2 minutes
2) for some row in the syssync table, "log_sent" was greater than
"progress". (This occurs when dbmlsync sends an upload to the
MobiLink server, but does not receive an ack/nack to indicate that the upload
was applied to the consolidated database or not)
3) hovering was enabled
This problem has now been fixed.
================(Build #3619 - Engineering Case #487690)================
Normally, the MobiLink client dbmlsync ignores the server side state on the
first synchronization of a subscription, although there was a problem where
dbmlsync might have respected the server side state on a first synchronization,
if an exchange was performed with the server to confirm the progress offsets
of other subscriptions that had previously synchronized. As a result of
this, data could have been lost and synchronizations could have failed with
the error "Progress offset mismatch, resending upload from consolidated
database's progress offset" being reported twice. This has been fixed.
================(Build #3619 - Engineering Case #487689)================
If the MobiLink client dbmlsync did not receive an ack/nack from the server
after sending an upload it has no way of knowing whether the upload was successfully
applied to the server. The best way to resolve this situation is to perform
an 'extra exchange' with the server before the next synchronization to request
the status of the upload, but dbmlsync did not perform this extra exchange
after an unacknowledged upload that occurred during the first synchronization
of a subscription. This would not have resulted in any data loss, but might
have increased the time required for the next synchronization as it might
cause two uploads to be built and sent to the MobiLink server. This has been
corrected so that an extra exchange is now performed in this case to eliminate
the possibility of sending two uploads.
================(Build #3619 - Engineering Case #487687)================
If the MobiLink client dbmlsync failed during the brief time between when
an upload was completed and when state information in the database was updated,
then the server would not have been queried at the start of the next sync
to determine if the upload was successfully applied to the consolidated database.
This problem would have occurred extremely rarely, and in most cases would
have been harmless. The result was simply that the next synchronization
took a little longer because an upload was built and uploaded, then rejected
by the server, and a new correct upload was built and uploaded. However
if the failure occurred on a subscription's first synchronization, it could
have resulted in operations being uploaded to the server twice, which would
usually have caused the synchronization to fail with server side errors.
This has been fixed so that the syssync table is updated prior to the end
of the upload. As a result an extra exchange may occur when the end of the
upload was not sent, but the client should never fail to do an extra exchange
when it is required.
================(Build #3618 - Engineering Case #487516)================
If a database had been initialized with the -b option (blank padding of strings
for comparisons), then the log scanning would not have read the delete_old_logs
database option properly. The log scanning code would always have used the
default value of 'Off', regardless of the value set in the database. This
problem has now been fixed.
================(Build #3610 - Engineering Case #486446)================
When running on a slow network, the MobiLink client dbmlsync could have reported
'Internal Error (1003)'. This problem has been corrected.
================(Build #3608 - Engineering Case #485878)================
If a remote database synchronized an NCHAR column that was included in multiple
publications, or if a database initialized with a multi-byte character set
synchronized a CHAR column that was included in multiple publications, then
dbmlsync would have incorrectly reported that a column subset mismatch existed
on the column in question. This has been fixed.
================(Build #3574 - Engineering Case #481905)================
When the MobiLink client dbmlsync was run against a database created using
Turkish settings, it would fail shortly after startup with the message:
SQL statement failed: (-141) Table 'sysarticlecol' not found.
This problem has been fixed.
================(Build #3553 - Engineering Case #475760)================
If multiple publications were being synchronized separately, and the MobiLink
client (dbmlsync) was running in hover mode, but the SendTriggers extended
option for the publications were not all the same, it was possible for dbmlsync
to not have synchronized trigger actions when they should have been, or to
have synchronized trigger actions when they should not have been. This problem
has now been fixed, but introduces a behaviour change. When multiple publications
are synchronized in hover mode, if the SendTriggers option changes from one
synchronization to the next, a complete rescan of the transaction log is
now executed to ensure that the proper SendTriggers option is used. This
could result in synchronizations taking longer than before, with the benefit
that the data in the synchronization is correct.
================(Build #3544 - Engineering Case #477290)================
If logscan polling was disabled (using the -p command line option or the
DisablePolling extended option) and a progress offset mismatch occurred,
then the MobiLink client would have sent a new upload using the remote progress
value. If the remote progress was greater than the consolidated progress,
then this could have resulted in data loss, as operations on the remote could
have been lost. If the remote progress was less than the consolidated progress,
this could have resulted in server side errors applying the upload, as the
same operation might have been uploaded more than once. This problem is now
fixed. When a progress mismatch occurs a new upload will be sent from the
consolidated progress unless the -r, -ra or -rb options are used.
================(Build #3532 - Engineering Case #473724)================
When both the graphical and non-graphical Dbmlsync Integration Components
(ActiveX components) were unregistered, they left the following key in the
registry:
HKEY_CLASSES_ROOT\TypeLib\{A385EA65-7B23-4DC3-A444-2E759FF30B14}
This key is now removed when both components have been unregistered.
================(Build #3509 - Engineering Case #471958)================
If the primary key of a table being synchronized, was not defined as the
initial column or columns of the table, it was possible for the MobiLink
Server to crash while processing the download_delete_cursor for that table.
It was more likely for the MobiLink Server to crash if the options -b or
-vr were specified on the MobiLink server command line. The problem has
now been fixed.
================(Build #3503 - Engineering Case #471007)================
When the MobiLink client (dbmlsync)was run with table locking enabled, this
is the default and is the case unless the extended option locktables is set
to off, the expected behaviour is for synchronizations to fail unless dbmlsync
can obtain locks on the tables being synchronized. A problem that would have
allowed synchronizations to continue when dbmlsync failed to obtain the locks,
has now been fixed.
================(Build #3486 - Engineering Case #466996)================
It was possible for a dbmlsync synchronization to fail with the following
error messages:
... Communication error occurred while sending data to the MobiLink server
... Internal error (???!s).
... Communication error occurred while sending data to the MobiLink server
... Unspecified communication error
This problem was most likely to have occurred when a slow network was being
used. With a slow network, dbmlsync could have become blocked on a network
write. which prevented the sending of a liveness message. To correct this
problem, dbmlsync will no longer attempt to send liveness messages when it
is blocked on a write.
A possible workaround for this problem would be to use the timeout communication
parameter to increase the liveness timeout.
================(Build #3474 - Engineering Case #463668)================
A memory leak would have occurred in the MobiLink client when synchronizing
BIT strings. This has been fixed.
================(Build #3984 - Engineering Case #488676)================
The HTTP option 'buffer_size' was limited to 64000 (64KB). On slow networks
and/or large uploads or downloads, the overhead due to HTTP could have been
significant. The 'buffer_size' option is now limited to 1000000000 (1GB).
When using slow networks to perform HTTP or HTTPS synchronizations, tests
could be done with larger values for 'buffer_size' to see if synchronization
times improve.
For versions 11.0.1 and up, this change only applies to the -xo option of
the MobiLink server. The -x option already allows larger values.
================(Build #3891 - Engineering Case #571465)================
If a network error occurred in the MobiLink Monitor, the SQL Anywhere Monitor,
QAnywhere, or the Notifier, there could have been garbage characters trailing
the error string.
For example:
"The server monitor was unable to contact the MobiLink server. The
host 'mlstress02' is still available. Error: Timed out trying to read 128
bytes. rWms"
This has been fixed.
================(Build #3854 - Engineering Case #562083)================
The MobiLink server could have silently ignored bad HTTP requests. In particular,
subsequent requests received by MobiLink server B, for a session started
in MobiLink server A, would have been silently ignored. The error was particularly
likely to appear if an HTTP intermediary was misbehaving and sending different
HTTP requests for the same session to different MobiLink servers. This has
been fixed, and this case will now issue an error.
================(Build #3817 - Engineering Case #553300)================
Network error messages in the MobiLink monitor, the SA Monitor, the Notifier
or the QAnywhere server could have been garbled on non-English machines.
This has been fixed.
================(Build #3788 - Engineering Case #548144)================
If a network error occurred during a read from the stream, some MobiLink
Java clients could have hung with 100% CPU utilization. This has been fixed.
The MobiLink Monitor, the SQL Anywhere Monitor, the Notifier and QAnywhere
are all affected by this.
================(Build #3788 - Engineering Case #548033)================
When synchronizing through a third-party server or proxy and using TLS or
HTTPS, the sync could have failed with the stream error code STREAM_ERROR_READ
and system error code 4099 (hex 1003). This has now been fixed.
================(Build #3662 - Engineering Case #495146)================
Synchronizations with may have failed or hung, particularly on slow or low-quality
networks. This has been fixed.
================(Build #3662 - Engineering Case #495145)================
HTTP or HTTPS synchronizations may have failed or hung, particularly on slow
or low-quality networks. This has been fixed.
================(Build #3652 - Engineering Case #493337)================
MobiLink clients could have failed to parse Set-Cookie HTTP headers sent
by web servers and would have returned the error STREAM_ERROR_HTTP_HEADER_PARSE_ERROR.
This has been fixed.
================(Build #3645 - Engineering Case #489903)================
Some HTTP intermediaries add more information to the HTTP User-Agent header.
This was causing failed synchronizations, and has now been fixed.
Note that any intermediary that removes the information put into the User-Agent
by the MobiLink client will cause synchronizations to fail.
================(Build #3630 - Engineering Case #489258)================
The HTTP synchronization parameter buffer_size was not always respected,
particularly when using zlib compression, which could have caused upload
performancto degrade for large uploads. This has been fixed. Also the default
values for buffer_size have been increased as follows:
Palm - 4K
CE - 16K
all other platforms - 64K
and the maximum value for buffer_size has been increased from 64K to 1G.
================(Build #3576 - Engineering Case #482124)================
The UltraLite and MobiLink security DLLs/shared objects had entry points
that were inconsistent with those used by the SQL Anywhere database server.
This has been corrected. The DLLs/shared objects and the binaries that load
them, must be at the noted build number or later, or else the DLL/shared
object will fail to load and an error (indicating missing/invalid DLL/shared
object) will be issued.
================(Build #3534 - Engineering Case #475962)================
Clients connecting via the -xo option were not able to saturate the number
of database workers specified by the -w option. This has been corrected so
that the number of -xo clients that can concurrently connect is equal to
the number of database worker threads.
================(Build #3490 - Engineering Case #468347)================
MobiLink clients would never have timed-out a connection if the timeout synchronization
parameter was set to zero. This has been fixed so that connections will
now timeout after the maximum timeout period of 10 minutes if the server
has not responded in this period.
================(Build #3483 - Engineering Case #466812)================
HTTP synchronizations through third party web servers, or proxies that use
cookies, could have failed with stream error STREAM_ERROR_HTTP_HEADER_PARSE_ERROR.
Also, if the server used the "Set-Cookie2" header, the client would
never have sent the cookie back up to the server. These problems have now
been fixed.
================(Build #3479 - Engineering Case #465947)================
MobiLink clients that use TLS or HTTPS would have crashed if they were not
able to load the appropriate TLS stream dlls (mlcrsa10.dll, mlcecc10.dll,
mlcrsafips10.dll and sbgse2.dll). This has been fixed. They will now report
the error "Failed to load library x" (STREAM_ERROR_LOAD_LIBRARY_FAILURE).
================(Build #4070 - Engineering Case #629058)================
A Java VM running inside the MobiLink server could have run out of memory
if the server had many requests with different script versions and some sync
scripts made calls to DBConnectionContext.getConnection(). This has been
fixed.
================(Build #4070 - Engineering Case #562039)================
The start times for synchronizations reported by the MobiLink Monitor and
the MobiLink Server, when used with the -vm option, could have been incorrect
if the MobiLink Server had been running for several days. Also, the output
for the -vm option could have been incorrect if a request used non-blocking
download acks, and phase durations reported by -vm option could have been
slightly different than phase times reported by the MobiLink Monitor. These
issues have now been fixed.
================(Build #4047 - Engineering Case #623106)================
New http, https and oe stream options have been added to the MobiLink server
that will cause it to print additional errors, analogous to the errors printed
by the -vf option.
Usage:
-x http(...;log_bad_request={yes|no})
-x https(...;log_bad_request={yes|no})
-x oe(...;log_bad_request={yes|no})
The default value for these noew options is "no".
If log_bad_request is enabled and a request disconnects before the server
receives a complete set of HTTP headers, the server will print these errors:
[-10117] Stream Error: Failed reading an incomplete HTTP request
[-10117] Stream Error: This connection will be abandoned because of previous
errors
If log_bad_request is enabled and a request contains an unknown User-Agent
or unknown request type, the server will print these errors:
[-10117] Stream Error: Unknown HTTP User-Agent or request type
[-10117] Stream Error: This connection will be abandoned because of previous
errors
This option is most useful when debugging network issues. For example,
you can connect to the ML server using a web browser on the remote device
and if the device can reach the server, then these errors will be printed.
================(Build #4016 - Engineering Case #614417)================
The MobiLink server could have crashed when processing a synchronization
request from a client, if the client was older than version 10 and was syncing
UUID columns. This has been fixed.
================(Build #4015 - Engineering Case #611373)================
The MobiLink server could have occasionally given the following error:
A downloaded value for table 'table_name' (column #column_number) was either
too big or invalid for the remote schema type
and then aborted the synchronization, when a client was trying to download
data from a table that contained NCHAR, NVARCHAR or LONG NVARCHAR columns,
even when NCHAR, NVARCHAR or LONG NVARCHAR data was uploaded in a previous
synchronization. This problem has now been fixed.
================(Build #4001 - Engineering Case #611414)================
When using the iAS Oracle ODBC driver, attempting to execute an INSERT, UPDATE,
or DELETE statement with SQLExecDirect immediately after executing a SELECT
statement with the same statement handle, would have failed with the following
error message:
ORA-24333: zero iteration count
This problem is fixed now.
================(Build #4001 - Engineering Case #611373)================
The MobiLink server could have occasionally given the following error:
A downloaded value for table 'table_name' (column #column_number) was either
too big or invalid for the remote schema type
and then aborted the synchronization, when a client was trying to download
data from a table that contained NCHAR, NVARCHAR or LONG NVARCHAR columns,
even when NCHAR, NVARCHAR or LONG NVARCHAR data was uploaded in a previous
synchronization. This problem has now been fixed.
================(Build #3984 - Engineering Case #605651)================
The MobiLink server would have thrown the exception IllegalCastException
when assigning the null reference to the Value property of an IDataParameter
when using the MobiLink Direct Row API to download data. This has been fixed.
A work around is to assign DBNull.Value instead.
================(Build #3968 - Engineering Case #591002)================
The changes for Engineering case 582782 could have caused the MobiLink server
to be much slower for small sync than servers without the fix. This problem
would have occurred when a consolidated database was running on an Oracle
RAC. The slowness is in the Oracle server: fetching the minimum starting
time of the open transactions from gv$transaction can take as much as a couple
of seconds and it is much slower than from v$transaction. This has now been
corrected.
================(Build #3943 - Engineering Case #585456)================
The queue lengths in the Utilization Graph of the MobiLink Monitor could
have been incorrect and the RAW_TCP_STAGE_LEN, STREAM_STAGE_LEN, HEARTBEAT_STAGE_LEN,
CMD_PROCESSOR_STAGE_LEN metrics printed by the -ppv option could also have
been incorrect. These issues have now been corrected.
================(Build #3943 - Engineering Case #585258)================
The MobiLink server would not have shown any script contents, if the scripts
were written in Java or .NET, even when the verbose option (-vc) was specified
in its command line. This problem is fixed now.
================(Build #3939 - Engineering Case #584310)================
Download performance of the MobiLink server has been improved for tables
that contain no BLOB columns, when the consolidated database is running on
Microsoft SQL Server.
================(Build #3931 - Engineering Case #582782)================
When a consolidated database was running on an Oracle RAC, the MobiLink server
could have skipped rows being downloaded to remote databases in a time-based
download. In the following situations, rows modified in the Oracle database
could be missed from the download stream:
1) the MobiLink server connected to one node on an Oracle RAC;
2) another application, A connected to another node on the same Oracle RAC;
3) application A modifies rows in a synchronization table without commit;
4) a MobiLink client, R1 issues a synchronization request that contains
a time-based download from this table;
5) the MobiLink server completes the synchronization request successfully;
6) A commits its transaction;
Then the rows modified by application A would not be down loaded to remote
R1. This problem has now been fixed.
Note, as a result of this change, the Oracle account used by the MobiLink
server must now have permission for the GV_$TRANSACTION Oracle system view
instead of V_$TRANSACTION. Only SYS can grant this access. The Oracle syntax
for granting this access is:
grant select on SYS.GV_$TRANSACTION to <user-name>
================(Build #3930 - Engineering Case #582589)================
If 10 MobiLink Monitors or SQL Anywhere Monitors connected to the same MobiLink
server, and the last to connect then disconnected, then the MobiLink server
could have crashed. This has been fixed.
================(Build #3922 - Engineering Case #580222)================
If the MobiLink Server had been started with "-s 1" command line
option, to indicate that the server should always apply changes to the consolidated
database one row at a time, then the MobiLink Server would still have executed
SAVEPOINT commands. SAVEPOINT commands are not needed when running in single
row mode, so they are no longer executed when the MobiLink Server had been
started with "-s 1".
================(Build #3891 - Engineering Case #567906)================
The MobiLink server could have crashed when multiple -x options were specified
on the command line, with at least one being HTTP and another being HTTPS.
This could have happened, for example, when a VPN connection was created
or dropped in the middle of a non-persistent HTTP/HTTPS synchronization,
and the network intermediaries were set up such that one path resulted in
HTTP and the other resulted in HTTPS. This has been fixed.
================(Build #3888 - Engineering Case #570656)================
If a MobiLink synchronization script included the two characters "ui"
inside an {ml ...} structure for named parameters, and the "ui"
characters were not part of a named parameter, then MobiLink would have incorrectly
replaced the "ui" with a question mark when it sent the command
to the consolidated database. For example, the following script would have
had no problem, since the "ui" in this case was part of the named
parameter "build":
INSERT INTO t1(pk,build) VALUES ( {ml r.pk}, {ml r.build})
However, the following script would have failed, because the "ui"
in the column list for the insert would have been replaced:
{ml INSERT INTO t1(pk,build) VALUES ( r.pk, r.build )}
This has now been fixed.
================(Build #3872 - Engineering Case #565651)================
If an application executed a query like "select ... for t where c =
v', where c was a char or varchar column, v was as variable of type nchar
or nvarchar, and t was a proxy table to a remote table in Microsoft SQL Server,
then the query would have failed with SQL Server reporting the error "The
data types varchar and ntext are incompatible in the equal to operator."
This problem has now been corrected.
================(Build #3864 - Engineering Case #564829)================
When the MobiLink server was listening for HTTP and/or HTTPS requests, and
a load balancer or any other utility (eg. the RSOE) performed a simple TCP/IP
connect, then an immediate close without sending any bytes, the MobiLink
server would have taken four minutes to time out the socket. If too many
such connections happened in a short time, the MobiLink server could have
run out of sockets earlier than necessary. This has been fixed.
================(Build #3860 - Engineering Case #563592)================
When run on Windows systems, both the MobiLink server and the Relay Server
Outbound Enabler (RSOE) could have held onto sockets for longer than necessary.
This would have caused both to use up sockets faster than necessary, possibly
exhausting system socket limits. With the RSOE, needless timeouts could also
have occurred. This behaviour was particularly evident with non-persistent
HTTP/HTTPS connections, and appeared to be very much OS and machine dependent.
This has been fixed.
================(Build #3860 - Engineering Case #563592)================
When run on Windows systems, both the MobiLink server and the Relay Server
Outbound Enabler (RSOE) could have held onto sockets for longer than necessary.
This would have caused both to use up sockets faster than necessary, possibly
exhausting system socket limits. With the RSOE, needless timeouts could also
have occurred. This behaviour was particularly evident with non-persistent
HTTP/HTTPS connections, and appeared to be very much OS and machine dependent.
This has been fixed.
================(Build #3858 - Engineering Case #563405)================
The MobiLink server could have crashed if a IDataReader returned by MLUploadData
was not closed. If the server didn't crash it would have leaked memory. The
crash would have occurred at a random time after the synchronization completed.
This has been fixed.
Note that enclosing the use of the IDataReader in a 'using' block will automatically
close it.
================(Build #3857 - Engineering Case #563404)================
Synchronizations could have failed with protocol errors when some, but not
all, of the parameters for a delete command in the .NET irect row API were
set to DBNull.Value or null. This has been fixed so that an exception will
be thrown when attempting to execute the command.
================(Build #3840 - Engineering Case #558232)================
The MobiLink Monitor has a default filter which highlights failed synchronizations
in red. Failed synchronizations logged by the MobiLink Server were not being
shown in the Monitor in red as the server was telling the Monitor that every
sync was successful. This has been fixed.
================(Build #3833 - Engineering Case #555985)================
The MobiLink server would given an error message that the classpath was too
long if the Java classpath given in the -sl java option was longer than about
3000 characters. This restriction has been removed.
================(Build #3832 - Engineering Case #555616)================
he MobiLink server was allocating more memory than necessary and thus wasting
memory. The amount wasted was approximately equal to 13% of the -cm option
value. This has now been fixed.
================(Build #3831 - Engineering Case #555034)================
Push notifications over a SYNC gateway may have stopped working after the
listener reconnected. The was timing dependent and was more likely to have
occurred when there was a proxy, a redirector, or a relay server being used
between the listener and the SYNC gateway of the MobiLink server. The listener
may have reconnected to the SYNC gateway when the IP address of the remote
device had been changed, when the QAAgent registered with the listener on
startup, or a communication error had occurred. This problem has now been
fixed.
================(Build #3821 - Engineering Case #553482)================
Prior to executing the "begin_connection_autocommit" script, the
MobiLink server will temporarily turn on auto-commit on the ODBC connection,
due to restrictions with some consolidated databases. On ASE consolidated
databases, this will generate a warning (SQL_SUCCESS_WITH_INFO) in the ODBC
driver:
"AutoCommit option has changed to true. All pending statements on this
transaction (if any) are committed."
This warning was being generated whether the begin_connection_autocommit
script was defined or was absent. This has been fixed. The server will now
only turn on auto-commit when the script is defined and will only execute
the script if it is defined. If the script is defined, it is still possible
to see this warning logged in the MobiLink server console log. This is expected
behaviour.
================(Build #3819 - Engineering Case #553748)================
When using the iAS ODBC driver for Oracle, calling SQLColAttribute with an
attribute code of SQL_DESC_TYPE_NAME would not have returned the type names
of columns. This has now been fixed.
================(Build #3818 - Engineering Case #553387)================
The following fixes have been made to support MobiLink in DB2 Mainframe Compatibility
Mode
- The ml_pt_script table did not have an explicit ROWID column. This was
required for the CLOB column. Some D2M deployments support an implicit ROWID,
and some do not, inluding compatibility mode. Fixed by adding an explicit
ROWID column.
- The SQL used for JCL-based CREATE PROCEDURE statements included the SQL
body of the stored procedure. This worked most of the time, but not under
compatibility mode. Now, the external-procedure form of CREATE PROCEDURE
is used, which doesn't include the body (which of course isn't necessary
because it is in the *.xmit files).
- The SQL used to create the SQL-based D2M stored procedures didn't escape
single quotes. This wasn't noticed because D2M treats most unquoted text
between single quotes as a string, so it just worked. Single quotes are now
escaped in the procedure body, inside the call to DSNTPSMP.
- The D2M ml_add_pt_script stored procedure didn't work under compatibility
mode, for several reasons:
1) it had a VARCHAR( 256 ) parameter (the flags for the SQL Passthrough
script) that caused conversion problems inside the procedure when run under
compatibility mode. This parameter has been changed to VARCHAR( 255 ).
2) it referenced a Unicode string, which isn't supported under compatibility
mode. This has been fixed by replacing it with a non-Unicode string.
3) it used a form of the SIGNAL statement that isn't supported under
compatibility mode. This has been corrected.
================(Build #3814 - Engineering Case #552321)================
If an error or warning occurred when commiting, the MobiLink server would
not have reported any error or warning messages. If it was an error, the
MobiLink server would have just failed the synchronization request without
giving any reasons. This problem is fixed.
================(Build #3811 - Engineering Case #539627)================
Some lines printed to the MobiLink server log would not have caused LogListeners
to fire. In particular, warning 10082, "MobiLink server has swapped
data pages to disk out:<...> concurrently used pages:<...>",
never triggered LogListeners. This has been fixed.
================(Build #3808 - Engineering Case #551858)================
If a remote server used character length semantics for a string column (e.g.
a SQLAnywhere remote with an nchar column, or an UltraLiteJ remote with a
char column), and the column on the remote database was smaller than the
column in the consolidated database, then the MobiLink server could have
failed to report the truncation. The server was already counting the number
of characters in the the column coming out the consolidated, but it wasn't
checking the length against the domain info given by the remote. This has
now been fixed
================(Build #3808 - Engineering Case #551813)================
Messages printed to the MobiLink server log could have been mangled on systems
with non-English character sets. This would have happened most often on errors
from QAnywhere or the Notifier. This has now been fixed.
================(Build #3806 - Engineering Case #547906)================
If a column in the consolidated database was larger than the corresponding
column in the remote database, then the MobiLink server may have crashed
when synchronizing. This has been fixed so that the sync will now abort with
the error -10038.
================(Build #3794 - Engineering Case #548580)================
Synchronizing a UNIQUEIDENTIFIER field in a remote database to Oracle via
MobiLink would have resulted in a 32 character UUID, followed by a NULL character
and three other characters (typically also NULL). When sending GUIDs to Oracle,
MobiLink was removing the hyphens to match the GUIDs generated by the SYS_GUID()
function in Oracle, but was not trimming the ODBC bind length to account
for the hyphen removal, thus resulting in 4 extra bytes in the string representation
of the UUID in Oracle. These four extra characters have now been removed.
================(Build #3788 - Engineering Case #548032)================
The MobiLink server would have printed the warning, "[10082] MobiLink
server has swapped data pages to disk", after it had swapped 5000 pages
to disk, or about 20MB of row data. This has been changes so that it now
prints this message after the first time the server must swap to disk. This
should make it easier to diagnose performance problems when -cm is set slightly
too small.
================(Build #3787 - Engineering Case #547730)================
If a corrupted UltraLite or SQL Anywhere remote client synchronized with
a MobiLink server, it was possible for protocol errors to be generated. When
this occurred, the MobiLink server console log would have shown the text:
I. <1> failed reading command with id:%d and handle:%d
I. <1> Synchronization complete
This has been fixed. Now, the error message "[-10001] Protocol Error:
400" will be displayed and a synchronization error will be reported.
================(Build #3787 - Engineering Case #547716)================
Attempting to add a blob to the download stream when using the MobiLink Direct
Row API and the MLPreparedStatement.setBytes() method, would have failed.
The method would have returned the error "Value is out of range for
conversion" if the length of the byte array was larger than 65536 bytes.
This problem has now been fixed.
================(Build #3786 - Engineering Case #547206)================
Non-persistent HTTPS synchronizations could sometimes fail with stream error
STREAM_ERROR_WRITE and a system error code of 10053. This has been fixed.
================(Build #3779 - Engineering Case #546256)================
When connected to a DB2 Mainframe (D2M) consolidated database, the MobiLink
server could have held locks across COMMITs, causing increased contention
and sometimes resulting in deadlock or timeout errors. This has been fixed.
================(Build #3779 - Engineering Case #546173)================
When uploading timestamp data with the .NET Direct Row API, an exception
could have been thrown. Even if an exception wasn't thrown, the fractional
part of the timestamp would have been incorrect. When downloading timestamps
with the .NET Direct Row api, values would have been incorrect by a few seconds.
Both of these problems have now been fixed.
================(Build #3779 - Engineering Case #545762)================
The MobiLink system stored procedures for DB2 Mainframe were created with
a default isolation level of RR (Repeatable Read = Serializable) instead
of CS (Cursor Stability = Read Committed). This has been fixed.
================(Build #3772 - Engineering Case #544763)================
The -nc option, which limits the number of concurrent sockets opened by MobiLink
server, wasn't feasible to use with non-persistent HTTP/HTTPS, because sockets
that could have been continuations of valid synchronizations might have been
rejected. The -sm option has been improved to provide similar functionality
to -nc when used with non-persistent HTTP/HTTPS. Furthermore, the MobiLink
server should usually have provided HTTP error 503 (Service Unavailable)
to the remote when the -sm limit was reached and sessions were kicked out.
If the -nc limit was reached, however, the error would instead have been
a socket error -- usually with a system code about being unable to connect,
but experience has shown the system code can vary.
Note, to limit the number of concurrent synchronizations for non-persistent
HTTP/HTTPS, the -nc option should be set significantly higher than -sm.
The greater the difference between -sm and -nc, the more likely (but never
guaranteed) the 503 error will be sent to the remote instead of a socket
error.
================(Build #3769 - Engineering Case #544943)================
The MobiLink server could have hung, or crashed, when using encrypted streams.
The behaviour was highly dependent on both timing and data size. This has
now been fixed.
================(Build #3769 - Engineering Case #544321)================
An HTTPS synchronization through a proxy server that required authentication
would have failed. When using HTTPS through a proxy server, the client first
sends a CONNECT HTTP request to establish a channel through the proxy. Unfortunately,
authentication challenges was only active for GET and POST requests. This
has been corrected so that CONNECT requests are now active as well.
================(Build #3746 - Engineering Case #541075)================
If the MobiLink Server was processing an invalid upload stream, it was possible
for the MobiLink Server to have crashed. The MobiLink Server will now fail
the synchronization.
================(Build #3746 - Engineering Case #540200)================
When running the MobiLink server with minimal verbosity, and using the MobiLink
Listener (dblsn), the message "Disconnected from consolidated database"
would have appeared in the server log. This has been corrected. The connection
used by dblsn will now be reused by the next dblsn client.
================(Build #3739 - Engineering Case #539812)================
The MobiLink server name given by the -zs command line option was not shown
in the title bar of the MobiLink server window. This problem is corrected.
================(Build #3737 - Engineering Case #539309)================
If the MobiLink Server had been started with the -nba+ switch, it was possible
for the MobiLink Server to have crashed if a non-blocking download acknowledgment
was received from a remote database, and the MobiLink Server had lost all
its connections with the consolidated database. The MobiLink server will
now properly report that all connections to the consolidated database have
been lost.
================(Build #3735 - Engineering Case #537962)================
If an error occurred when executing a Java or .NET synchronization script,
and operations had been performed on the connection returned from the DBConnectionContext.getConnection
method, it was possible for those operations to have been committed to the
consolidated database. In order for this to have occurred, the Java or .NET
synchronization script would have to have been executed before any SQL scripts
were executed in the transaction by the MobiLink Server. As a workaround,
a SQL synchronization script that does nothing could be defined that executes
at the start of the transaction. For example, define a begin_upload connection
event that calls a stored procedure, that does nothing, to prevent a problem
in the handle_uploadData event resulting in operations performed in the handle_uploadData
event from being accidentally committed. This problem has now been fixed.
================(Build #3731 - Engineering Case #538347)================
If the MobiLink server was started unsuccessfully (i.e invalid parameter,
unable to connect to database, invalid stream specified), and no logging
option was specified (-o or -ot), then the server would have displayed an
error dialog and waited for the shutdown button to be pressed. After waiting
about a minute for the manual shutdown, the server could then have crashed.
This has been fixed.
Note, this problem should only have occurred on systems where a GUI was
used.
================(Build #3730 - Engineering Case #537917)================
A download_delete_cursor script that returned NULL and non-NULL values for
the primary key columns of a synchronized table would have made the MobiLink
client behave erratically: the client could have deleted rows that should
not have been deleted, or could have displayed the following error message:
SQL statement failed: (100) Row not found
This problem has been fixed. The MobiLink server will now complain if a
download_delete_cursor returns NULL as well as non-NULL values for the primary
key columns of a synchronized table, and will then abort the synchronization.
The download_delete_cursor script must return NULL values for all the primary
key columns (the MobiLink client will delete all
the rows from the corresponding sync table) or non-NULL values (the client
will delete specific rows specified by the primary
key values).
================(Build #3730 - Engineering Case #534179)================
Java messages could have been corrupted on operating systems with non-English
character sets. Character set conversion was not being done correctly. This
has been fixed
================(Build #3727 - Engineering Case #538954)================
Server Initiated Synchronizations, using persistent connections, didn't scale
well as it required persistent resource per connected client on the backend
server, as well as onintermediaries like the Redirector or Relay Server.
This limitation may have caused large deployments to require a server farm,
which is not supported until version 11.x. Now with this change, an alternative
solution is provided based on light weight polling. This alternative is based
on a new caching notifier in the MobiLink server, and a client API for polling
the notification (MobiLink Lightweight Polling API). The caching notifier
refreshes the current set of notifications by executing a request_cursor
against the database at a setable frequency. The cache is exposed for clients
to poll without involving database access, nor authentication via the same
MobiLink server port.
Caching notifier
A caching notifier is a notifier with a request_cursor that return a result
set with 1, 2 or 3 columns. The first column is the key of the notification,
the optional second column is the subject of the notification and the optional
third column is the content of the notification. A caching notifier doesn't
need gateways or tracking information in order to push notifications down
to clients. Clients are expected to initiate connection and poll at the
cache refresh frequency. Users may define multiple caching notifiers for
different business logic, and they can co-exist with other regular or caching
notifiers.
MLLP API
Development resources are found under the following location
%SQLANY10%\MobiLink\ListenerSDK\windows\src\mllplib.h
%SQLANY10%\MobiLink\ListenerSDK\windows\x86\mllplib.dll
%SQLANY10%\MobiLink\ListenerSDK\windows\x86\mllplib.exp
%SQLANY10%\MobiLink\ListenerSDK\windows\x86\mllplib.lib (import library
for the dll)
MLLP client will dynamically load various ML client stream library.
Example MLLP client app
Please see %SQLANYSH10%\samples\MobiLink\SIS_CarDealer_LP2
================(Build #3727 - Engineering Case #537609)================
If a synchronization contained tables for which no rows were uploaded or
downloaded, the MobiLink server would have allocated more memory than was
neccessary. This has been fixed so that the memory usage will be proportional
to the number of columns in empty tables multiplied by the number of upload
transactions. In tests with 50 concurrent syncs of 200 empty tables with
6 columns per table, the peak memory used by MobiLink server dropped by 178MB,
or about 3kB per column. Systems that synchronize many empty tables, or use
transactional uploads (i.e. the -tu option on dbmlsync), will see improved
performance with this fix.
================(Build #3727 - Engineering Case #536746)================
When an encryption library could not found, the MobiLink server would have
issued a misleading message indicating corruption:
Invalid or corrupt network interface library: xxxxx
This has been corrected so that now the MobiLink server issues the message:
Failed to load library xxxxx
he documentation for the load library message indicates that a license may
be required, which is appropriate in this case.
================(Build #3715 - Engineering Case #533805)================
If a consolidated database was running on an Oracle 9i or later server, the
MobiLink server could have sent clients a next_last_download_time (a timestamp
value used to generate a download in the next synchronization) that was earlier
than the last_download_time (a timestamp value used to generate the download
in the current synchronization). This problem could have caused a MobiLink
client to complain when it was trying to apply the downloaded file. This
problem has now been fixed.
================(Build #3715 - Engineering Case #533804)================
When the MobiLink server was under heavy load, the Mobilink monitor may have
crashed, hung or disconnect from the Mobilink server. This has now been
fixed.
================(Build #3678 - Engineering Case #498056)================
Scripts can be created that use user-defined parameters that are denoted
by the {ml u.parm} syntax. Some ODBC drivers have a problem though with
how the MobiLink server translates the SQL statement which would pass the
parameter with IN/OUT attributes. This can now be overcome by using the
new notation {ml ui.parm}. The MobiLink server will now pass this parameter
with IN attributes.
A workaround previous to this new feature would be to code the script as
a stored procedure call.
================(Build #3671 - Engineering Case #493219)================
When using non-persistent HTTP, the length of the end_synchronization phase
in the Monitor could have been shown as taking a long time (at least equal
to the connection timeout interval), even though the sync successfully completed
much earlier. The strange display made it hard to interpret what was going
on. This has been fixed.
================(Build #3668 - Engineering Case #495980)================
In order to optimize database access, the MobiLink scripts can be considered
"read-only" when the -f option is specified. In this mode, the
ml_global version of scripts would have been checked for changes before each
synchronization. This has been corrected so that
the check is only done once at startup.
================(Build #3654 - Engineering Case #493708)================
Older MobiLink clients (version 8 and 9) may have failed to synchronize with
an "Out of memory" error. This error should have been reported
as "unknown character set". This has been corrected. The character
translation mechanism can no longer translate characters from DECKanji or
Turkish8 (possibly others). There is no workaround for this issue.
================(Build #3650 - Engineering Case #492788)================
Trying to use the named parameter ODBC_State with the report_odbc_error script
would have resulted in an error, with ODBC_State being reported as an invalid
system parameter. This has been fixed.
================(Build #3650 - Engineering Case #490209)================
An error would have been reported when some valid options were entered in
the dbmlsync option dialog on CE. The options affected included -q -Q -qc
-o -ot -os and -wc. This has been fixed.
================(Build #3647 - Engineering Case #492197)================
A client which sent malformed communications protocol to the MobiLink server,
could have casused the server to crash. This has been fixed.
================(Build #3637 - Engineering Case #490590)================
Synchronizations using TLS, HTTP, or compression could have failed. Also,
mlfiletransfer, dblsn, and all components connecting to the MobiLink server
could have failed. The failure manifestation was highly data-dependent, but
the most likely error was a protocol error. Synchronizations from older (ie.
versions 8 & 9) clients were not affected by this problem. In the extremely
unlikely event that the lost bytes go unnoticed by the other end of the network
connection, or internally in MobiLink server, then there might be lost data.
For example, in a row operation, a sequence of bytes in the middle of a VARCHAR
column value may have been removed. This has been fixed.
================(Build #3635 - Engineering Case #490481)================
When attempting to shut down a MobiLink server using mlstop, as well as pressing
'q' on UNIX or clicking on the 'Shut down' button on Windows simultaneously,
then the MobiLink server could have crashed. This problem was due to a race
condition, which has now been corrected.
================(Build #3632 - Engineering Case #489597)================
The MobiLink server would have reported an incorrect error if the server
was running in blocking ack mode, but an event for non blocking ack (-nba+)
mode has been defined. The error reported was: "There is no download
data script defined for table:.. ". This has been corrected.
================(Build #3631 - Engineering Case #489100)================
The MobiLink server must hold all table data needed for currently active
synchronizations. When the total concurrent amount of table data exceeded
the server's cache memory (-cm option) by more than 4200MB the server could
have failed. This has been fixed.
================(Build #3630 - Engineering Case #489266)================
The MobiLink server could have silently failed a ping request from a 9.0.2
or earlier MobiLink client if the client's command line contained any options
of upload_only and/or download_only. This problem has now been fixed.
================(Build #3623 - Engineering Case #488272)================
When the MobiLink server can not store all the data needed for all the synchronizations
in the cache memory (-cm flag), it must swap some to a temporary file. This
data could have been written to the file more often than needed. This has
now been fixed.
================(Build #3623 - Engineering Case #488271)================
When the MobiLink server displayed warnings about the amount of memory that
was swapped to disk, the number reported for "concurrent pages"
was the maximum number of concurrent pages for current instance of the server.
This created the impression that the page usage always increased. This has
been corrected so that this number is now the number of concurrent pages
in use at the time of the warning.
================(Build #3617 - Engineering Case #487339)================
If an older client (version 8.0 or 9.0) synchronized against the MobiLink
server in a way that a second synchronization was attempted before the first
finished (the client was terminated before the server was finished), the
server would have allowed the second synchronization to proceed. This has
been corrected so that subsequent synchronizations will fail until the first
has competed. This problem does not apply to version 10.0 clients, as their
new protocol detects and handles this situation in a different manner.
================(Build #3611 - Engineering Case #486579)================
A MobiLink client, synchronizing via HTTP, that set the connection timeout
to less than the default 240 seconds, could have been disconnected by the
MobiLink server with a connection timeout error. This has been fixed.
================(Build #3609 - Engineering Case #486224)================
Some HTTP intermediaries can inject a redundant User-Agent HTTP header, resulting
in synchronizations failing. This is been fixed so that as long as the first
User-Agent is the one the MobiLink server expects, it will allow the redundant
header.
================(Build #3609 - Engineering Case #486223)================
Some HTTP intermediaries can convert non-chunked HTTP or HTTPS requests into
chunked requests. The MobiLink server currently cannot accept chunked requests,
and would have crashed when it received them. This has been fixed so it will
now fail the synchronization with the error "unknown transfer encoding"
if it receives chunked requests.
Note that this change only applies to the -x option, and not to the -xo
option.
================(Build #3601 - Engineering Case #485242)================
When using the Dbmlsync Integration Component, an exception could have occurred,
or corrupt data could have been retrieved, if the UploadRow event or the
DownloadRow event was enabled. For this to have occurred, the handler for
the above event must have called the ColumnValue method on the IRowTransfer
object more than once with the same index, and the index used must have corresponded
to a column containing a string or BLOB value. This problem has now been
fixed.
A work around for this problem would be to ensure that the ColumnValue method
is not called more than once for a single index by storing the value retrieved
by the first call in a variable and working with that value.
================(Build #3600 - Engineering Case #485285)================
Some memory could have been leaked by the MobiLink server when using non-persistent
HTTP or HTTPS (persistent=0 at the client). The size of the leak was proportional
to the number of HTTP GET requests, so large downloads would have caused
greater leaks. A small leak could have occurred as well if a communication
error occurred. The impact of the leaked memory could have included failed
synchronizations and/or MobiLink server crashes. This has now been fixed.
================(Build #3600 - Engineering Case #485276)================
When a consolidated database was running on a DB2 or DB2 mainframe server,
the MobiLink server, using the native IBM DB2 ODBC driver, may not have retried
uploads when deadlocks occurred. This problem has now been fixed.
================(Build #3588 - Engineering Case #482520)================
An upload that contained invalid or corrupt table data could have crashed
the MobiLink server. The MobiLink server will now correctly fail the synchronization
when it encounters invalid data..
================(Build #3583 - Engineering Case #483230)================
Ping synchronizations from a MobiLink client would have failed if the MobiLink
Server had been connected to a consolidated database where the authenticate_parameters
event existed. This has now been fixed.
================(Build #3575 - Engineering Case #478491)================
The MobiLink server would have crashed on startup when run on AIX 5.3 TL06
systems. This has now been resolved by having the installer turn off the
execute bit on all shared objects on AIX so that the libraries will not be
preload into the OS library cache.
================(Build #3570 - Engineering Case #481521)================
When synchronizing with HTTP or HTTPS, the MobiLink server could have caused
too many HTTP request/response cycles. The extra exchanges and extra bytes
on the wire would have made synchronizations take longer. This problem was
timing-dependent, and its likelyhood was inversely proportional to the round-trip
time between the client and server. This has been fixed.
================(Build #3557 - Engineering Case #472648)================
The MobiLink server could have entered into an infinity loop and generated
a very large output file, or have even crashed, if the execution of an upload_fetch,
download_cursor, or download_delete_cursor script caused an error, or if
the number of columns in the result set generated by any of these cursors
did not match the number of columns defined
in the corresponding remote table, and the handle_error or handle_odbc_error
script returned 1000 when these errors occurred. This problem has been fixed.
The MobiLink server will now abort the synchronization if any of these unrecoverable
errors
occur during synchronization. The errors in the user-defined scripts must
be fixed.
================(Build #3554 - Engineering Case #479237)================
The MobiLink server could have exhausted cache memory when multiple version
8.0 or 9.0 MobiLink clients were concurrently synchronizing large numbers
of tables. The server could have crashed, or shut down with the message "Unable
to allocate memory.". THis has now been fixed.
Increasing the amount of cache memory using the -cm server option is a work
around for this problem.
================(Build #3554 - Engineering Case #476095)================
The MobiLink server could leak memory when synchronizing and using the Listener.
This includes using the Notifier alone, or with QAnywhere. This is now fixed.
================(Build #3553 - Engineering Case #471931)================
The MobiLink server could have crashed when calling a stored procedure which
generated error messages that were longer than 256 characters. This has
been fixed.
================(Build #3550 - Engineering Case #475008)================
When using a load balancer that tested the MobiLink server availability by
probing the server network port, the server may have shutdown. This shutdown
was due to the server believing that it could no longer accept new connections.
This has been corrected.
================(Build #3535 - Engineering Case #472778)================
Secure-streams startup errors, for example when a bogus certificate identity
password was used, would not have prevented the server from starting. The
error would only have been detected on the first synchronization. This may
have resulted in a server crash, depending on the error. This has been fixed.
================(Build #3534 - Engineering Case #474873)================
Synchronizing with a version 8 client, could have caused the MobiLink server
to crash. This would have usually happened after a log offset mismatch. This
has been fixed.
================(Build #3527 - Engineering Case #474631)================
In the Windows Explorer, the files mlrsa_tls10.dll, mlrsa_tls_fips10.dll
and mlecc_tls10.dll would have appeared versionless when their properties
were inspected. This has been corrected.
================(Build #3517 - Engineering Case #545516)================
The MobiLink server now requires the ASE native ODBC driver, version 15.0.0.320,
which can be retrieved from the Sybase Software Developer Kit - 15 ESD #14,
for consolidated databases running on ASE 12.5 or ASE 15.0 database servers.
This is required due to a bug in the older versions of the ASE native ODBC
driver, that has now been fixed.
================(Build #3516 - Engineering Case #470202)================
Named parameters found in scripts would have been parsed and incorrectly
substituted for, when found in comments and quoted strings. This could have
caused parameters to be passed in the wrong order, or an error message to
be generated, when the number of parameters did not match what was expected.
This has been fixed.
Note, the following forms of comments are recognized:
-- (two hyphens)
// (two forward slashes)
/* */
The first two forms cause the script text to be ignored until the end of
a line.
The last form causes all text between the "/*" and "*/ to
be ignored. This form of comment cannot be nested.
Any other type of vendor specific comment will not be recognized and should
not be used to comment out references to a named parameter.
================(Build #3515 - Engineering Case #466074)================
Certain x.509 server certificates would have been erroneously rejected by
the client during the TLS handshake, causing the connection to fail. Certificates
generated by 10.0 gencert were particularly likely to be rejected. This problem
has been resolved by upgrading to newer versions of the Certicom TLS libraries.
================(Build #3507 - Engineering Case #471798)================
The MobiLink server could have leaked 2K bytes of memory per synchronization
if compressed streams were being used (ie. the "compression" client
option was not "none"). The leak depended directly on how the first
uploaded bytes of the synchronization flow on the network between the client
and server, so the leak was somewhat random from client's point of view.
The synchronization was not affected by the leak. This has now been fixed.
================(Build #3504 - Engineering Case #472238)================
The "iAnywhere Solutions 10 - Oracle" ODBC driver is now supported
on Windows x64 systems.
================(Build #3504 - Engineering Case #471149)================
When run on Windows 2000, the MobiLink Server was unable to determine the
IP address of the remote client, and thus was unable to ignore a request
when the stream option 'ignore' was specified. This has been fixed.
================(Build #3490 - Engineering Case #468129)================
When an error occurs during synchronization, the MobiLink server should display
the full details of the error, including the MobiLInk user name, remote ID,
script version, row values (if available), etc. However, if no -vr command
line option was specified, the row values were not displayed in the error
context by the MobiLink server. This has been corrected.
================(Build #3488 - Engineering Case #467441)================
The built-in MobiLink authentication classes that authenticate to external
LDAP, POP3 and IMAP servers were unable to read a property if the ScriptVersion
of the property was defined as 'ml_global'. It is now possible to define
both the authenticate_user connection script and MobiLink properties needed
for authentication using the special 'ml_global' connection script.
Note that the ml_global property can be over-ridden with a script version
specific property, similar to the way connection scripts work.
================(Build #3484 - Engineering Case #466696)================
When a MobiLink server was started with the Java VM loaded, an error related
to network issues could have caused the server to crash when shutting down.
This has been fixed.
================(Build #3482 - Engineering Case #466685)================
When synchronization tables on an ASE database server were created with the
'datarows' locking scheme, the MobiLink server could have silently skipped
rows that were inserted by other connections without a commit. The ASE server
doesn't block any other connections that are trying to query the rows from
a table that were created with 'datarows' locking scheme, even when there
are uncommitted inserts for this table. The MobiLink server now works around
this behaviour properly to ensure that no rows are skipped.
By default, the MobiLink server now queries the minimum transaction starting
time from master..systransactions and then sends this timestamp to the client
as the last download timestamp. In the next synchronization for this client,
the MobiLink server will use this timestamp as the last download time for
download. In order to get the starting time, the user ID the MobiLink server
uses to connect to an ASE server must have select permission and the master..systransactions
table. If the user does not have proper permissions, the MobiLink server
will present a warning message and get the download time from the ASE function
getdate(), reverting to the old behaviour where rows could be missed in the
download. With this change, it's now possible that the MobiLink server may
send duplicate data to clients, if there are any open transactions that modified
any tables in the synchronization database or any databases on the ASE database
server when MobiLink server is doing a download. Although the clients are
able to handle duplicate data, this behavior may reduce MobiLink server performance.
The MobiLink server now includes a new command line switch so you can the
behaviour of the MobiLink server with respect to tables with the 'datarows'
locking scheme. The -dr switch can be used to tell MobiLink that none of
the synchronizing tables use the 'datarows' locking scheme. The -dt switch
on the MobiLink server has also been enhanced to include Adaptive Server
Enterprise in addition to Microsoft SQL Server. The -dt switch can be used
to force MobiLink to detect transactions only within the current database
when determining the last download time that will be sent to the remote database.
The -dt switch should be used if all the synchronizing tables are located
in a single database, as this could reduce duplicate data sent by the MobiLink
server to the clients.
================(Build #3475 - Engineering Case #464889)================
If the -sl option (set Java options) was used more than once on the MobiLink
server command line, an error such as "unrecognized argument" could
have occurred. This has now been corrected.
For example "mlsrv10 -sl java ( opt1 ) -sl java (opt2 ) ..." now
correctly parses as "mlsrv10 -sl java( opt1 opt2 ) ..."
================(Build #3475 - Engineering Case #464885)================
When the MobiLink server was configured to support synchronization requests
from version 9 clients using the -xo option, the following error could have
occurred at shutdown: "[-10117] Stream Error: Unable to open a 'tcpip'
network connection. An error occurred during shutdown.". This has been
fixed so that the error no longer occurs.
================(Build #3470 - Engineering Case #456446)================
The MobiLink server could have hung when run on Unix systems. This has been
fixed.
================(Build #3420 - Engineering Case #466887)================
Using encrypted streams could have resulted in failed synchronizations, particularly
on Mac systems. This has been fixed.
================(Build #4051 - Engineering Case #624041)================
If the action command in the message handler did not contain any arguments,
the MobiLink Listener may have crashed. This has been fixed.
================(Build #3790 - Engineering Case #548463)================
Using the Certificate creation utility (createcert) to create certificates
or certificates requests would have failed with the error "Error occurred
encoding object", when provided non-ASCII input. This has been fixed.
================(Build #3767 - Engineering Case #544613)================
In an SIS environment, if a MobiLink client device went offline (device a),
and then another client device (device B) came online with the same device
address (ie. IP address/port) as A, and an SIS UDP notification for client
A was sent by the notifier, then client B would have received and rejected
the notification with an error similar to the following:
Error: <Notifier(QAnyNotifier_client)>: Request 1604437321 is accepted
by invalid respondent 'ias_receiver_lsn'. Please check the message filters
on the listener
This error would have happened whenever a UDP notification for client A
was sent, resulting in wasteful SIS notifications. This has now been fixed.
For 9.0.2, the fix was made only for MobiLink with messaging (QAnywhere)
for ASA consolidated databases. In later versions, the fix applies to all
MobiLink Notifiers in all supported consolidated databases.
================(Build #3739 - Engineering Case #539799)================
Notifier errors were cataglorized as MobiLink server errors. Errors such
as failing to resolved a delivery path to a remote device, and/or failing
a push attempt, was resulting in an error line in the MobiLink server log
that began with an "E.". This also caused an new entry in the system
event log. Notifier errors can be highly repeatative, if the business logic
was not implemented in a way that minimized failing attempts. Since these
failures are not affecting syncs, they have been recataglorized as informational
messages that begin with "I." instead. Two sub labels, "<SISI>"
and "<SISE>" have also been added to differentiate notifier
informational message and notifier error message.
Notifier informational message will now take on the following format:
I. YYYY-MM-DD HH:MM:SS. <Main> <SISI> ...
Notifier error message will now take on the following format:
I. YYYY-MM-DD HH:MM:SS <Main> <SISE> ...
================(Build #3720 - Engineering Case #535235)================
The Listener utility (dblsn) with persistent connection turned off, may have
failed to confirm message delivery or action execution. This may also have
caused the MobiLink server to report protocol errors. This has been fixed.
================(Build #3699 - Engineering Case #498343)================
When the visual version of the Dbmlsync Integration Component activex was
used on Japanese Windows XP, the font selected for the log window did not
support Japanese characters. As a result any Japanese text printed to the
log window was garbled. An appropriate font is now used.
================(Build #3680 - Engineering Case #498031)================
The MobiLink File Transfer utility (mlfiletransfer) did not send liveness
packets. This meant that for downloads of large files, the MobiLink server
would have timeouted the client. This has been fixed.
================(Build #3670 - Engineering Case #496545)================
The Certificate Creation utility createcert would have generated invalid
server certificates when signing them using a CA certificate generated by
gencert (the previous certificate generation utility). Although the server
certificate itself looked fine, clients would not have been able to properly
identify the trusted CA certificate that signed it, and so it would have
been rejected as untrusted, even when the client had the correct CA certificate
in its list of trusted CAs. This has been fixed.
================(Build #3615 - Engineering Case #487169)================
The Listener may have displayed an error dialog shortly after startup when
handling notifications. This problem was timing sensitive, subsequent errors
would have gone into the log file and to the console only. This has been
fixed so that errors in handling notification will no longer cause an error
dialog to be displayed. A workaround is to add the -oq switch to the dblsn
command line.
================(Build #3611 - Engineering Case #486546)================
The Certificate Creation utility createcert allowed users to create certificates
using ECC curves that were not supported by MobiLink or SQL Anywhere servers
or clients. This has been fixed. The list of supported curves has been
reduced to the following seven curves: sect163k1, sect233k1, sect283k1, sect283r1,
secp192r1, secp224r1 and secp256r1.
================(Build #3588 - Engineering Case #483427)================
An attempt to stop a MobiLink service using the Service utility dbsvc would
have failed with a message like "dbmlstop: No such file or directory".
This has been fixed.
================(Build #3586 - Engineering Case #481845)================
The following fixes have been made to the Listener utility
1) IP tracking was sometimes not firing BEST_IP_CHANGE event when the Listener
was run on Windows CE.
2) Engineering case 466446 introduced a problem in the Listener where options
following the options -ga or -gi may have been misinterpreted.
3) Asynchronous IP tracking (-ga) was not working on Windows CE devices.
Note, the Listener command line option -ga has been deprecated and asynchronous
IP tracking is now implicit. The default of -gi has been changed from 10
seconds to 60 seconds. The polling mechanism now serves only as a backup.
Users should not need to use -gi except for trouble shooting.
================(Build #3582 - Engineering Case #482832)================
When the visual form of the Dbmlsync Integration Component was used on Japanese
Windows 2000, the font selected for the log window did not support Japanese
characters and so these were not rendered correctly. This problem did not
occur on Windows XP. This problem has been fixed on Japanese Windows 2000
only, as it does not occur in any other environment.
================(Build #3577 - Engineering Case #482373)================
Any MobiLink utility with a GUI could have crashed when it attempted to display
a large message (ie. greater than 28,000 bytes), when the application was
running in minimized mode. This problem affects only Windows systems, and
was more likely to have occurred if the application was running with the
full verbosity enabled (-dl command line option). This has now been corrected.
================(Build #3554 - Engineering Case #479090)================
When the MobiLink listener (dblsn) used both non-persistent connections (i.e.
using -pc- switch explicitly) and confirmation, the notifier may have missed
doing some fallback pushes when the listener was in the middle of confirming
a previous notification. The problem has been fixed.
================(Build #3547 - Engineering Case #476819)================
When User Account Control (UAC) is enabled, applications cannot have been
registered with the provider for Windows Mobile Device Center (WMDC), either
from dbasinst or from the provider itself. The reason for this was that applications
are registered in the registry under HKEY_LOCAL_MACHINE, which requires administrator
privileges when UAC is enabled. Although dbasinst has been elevated, and
can set these registry entries, the provider was not. This has been corrected
so that applications are now registered under HKEY_CURRENT_USER instead.
However, this means that applications will now only be registered with a
specific user, instead of automatically being registered with all users of
a particular machine. The first time dbasinst is invoked after the patch
has been applied, it will automatically move all registry entries from HKEY_LOCAL_MACHINE
to HKEY_CURRENT_USER.
================(Build #3543 - Engineering Case #477203)================
When using the Dbmlsync Integration Component (ActiveX) and the Message
event was called, the msgID value was set to 0 for some messages that should
have had unique identifiers. In particular this was reported for the message
"Unable to find log offset ....", although other messages were
likely affected as well. The msgID value for these messages would not have
been filled in correctly with a unique value. This has now been corrected.
================(Build #3535 - Engineering Case #476077)================
The 64 bit versions of mlstop.exe and mluser.exe not included in the 10.0.1
install. This has been corrected.
================(Build #3527 - Engineering Case #474617)================
The certificate utilities createcert.exe and viewcert.exe as well as dbcecc10.dll
were missing version info. This has been fixed.
================(Build #3522 - Engineering Case #473528)================
A long running Listener utility dblsn.exe may have crashed when persistent
connections were used. This has been fixed.
================(Build #3512 - Engineering Case #472777)================
When the Certificate Creation utility (createcert) prompted for an encryption
type, RSA vs ECC, it accepted lowercase 'r' or 'e', but not uppercase 'R'
or 'E'. This has been corrected.
================(Build #3502 - Engineering Case #470594)================
The MobiLink Listener would likely have failed to send confirmation of notification
delivery or confirmation of actions, if persistent connections were explicitly
turned off (ie dblsn.exe -pc- ). This problem has been fixed.
================(Build #3500 - Engineering Case #470335)================
To determine if a downloaded file has changed, the MobiLink File Transfer
utility calculates a hash of its copy of the file and sends it up to the
server. The server calculates a hash of its own copy and compares it with
the hash of the remote file, and if they don't match, it transmits its entire
copy of the file down to the remote. However, if the only change to the
file is that extra bytes had been appended to the end, the file was transmitted
incorrectly and the resulting file on the remote contained only the new portion
-- the original portion of the file was lost. This has been fixed.
================(Build #3490 - Engineering Case #468602)================
The MobiLink file transfer utility mlfiletransfer did not display national
characters properly on the command line. This has been fixed.
================(Build #3482 - Engineering Case #466446)================
Two command line options have been added to the MobiLink listener (dnlsn)
for controlling ip tracking behavior.
1. The -gi option controls the ip tracker polling interval. The default
is 10 seconds.
example: dblsn.exe -gi 30
2. The -ga option is for asynchronous ip tracking. The -gi option is ignored
when -ga is used.
example: dblsn.exe -ga
================(Build #3470 - Engineering Case #462782)================
If MobiLink authentication failed, the MobiLink File Transfer utility (mlfiletransfer)
would not have reported a useful error message. This has been corrected so
that it will now report "MobiLink authentication failed". Also,
the methods MLFileTransfer and ULFileTransfer will now return the stream
error code STREAM_ERROR_AUTHENTICATION_FAILED.
================(Build #3470 - Engineering Case #462291)================
The MobiLink File Transfer utility (mlfiletransfer) was accepting an empty
string as a valid script version (e.g. mlfiletransfer -v "" ...).
This has been fixed. The empty string is now rejected, just as if no script
version was supplied at all.
Note, this fix also applies to the MLFileTransfer and ULFileTransfer methods
in the various UltraLite interfaces.
================(Build #4072 - Engineering Case #627776)================
On big-endian machines, the 64-bit iAS ODBC driver could have returned random
values when an application was trying to retrieve the following statement
attributes:
SQL_ATTR_METADATA_ID
SQL_ATTR_ROW_NUMBER
SQL_ATTR_ROW_ARRAY_SIZE
SQL_ATTR_PARAMSET_SIZE
SQL_ATTR_MAX_LENGTH
SQL_ATTR_MAX_ROWS
The driver was using SQLUINTEGER for these statement attributes. It has
been corrected to now use SQLULEN.
================(Build #4070 - Engineering Case #628952)================
The MobiLink server would have shown the following error:
Invalid Date-time segment. Year value out of range
and aborted any synchronization requests, if the consolidated database was
running on an ASE server with a database that was using a multi-byte charset,
and the MobiLink server was running on a Windows system that was using a
non-English Date format. This problem has now been fixed.
================(Build #4061 - Engineering Case #626951)================
The iAS Oracle ODBC driver could not detect connection status correctly when
a connection was forcibly disconnected by the server. Due to this problem,
an application, such as the MobiLink server, might not re-establish a new
connection and would have reported the same errors repeatedly. This problem
is fixed now.
================(Build #3921 - Engineering Case #573625)================
If an application asked for the connection status through the following ODBC
API
SQLGetConnectAttr( hdbc, SQL_ATTR_CONNECTION_DEAD, ... )
after an error occurred, the iAnywhere Solutions ODBC driver for Oracle
could told the application that the connection was still alive, even though
the connection had actually been killed, or had timed out. If this problem
occurred for the MobiLink server main connection, in most cases, the server
would have displayed the following messages:
[10009] MobiLink table 'ml_scripts_modified' is damaged
[-10020] Unable to flush scripts
and refused any synchronization requests. This MobiLink server would then
have needed to be be restarted in order to carry on any synchronization.
This problem is fixed now.
================(Build #3898 - Engineering Case #574354)================
The iAS ODBC driver for Oracle could have crash in a stored procedure call,
if the stored procedure contained char or varchar type INOUT parameters,
and the data length of these parameters was greater than 2000 bytes (1000
bytes for driver versions, 9.0.2 and 10.0.1). This has now been fixed.
================(Build #3894 - Engineering Case #570915)================
When the iAS ODBC driver for Oracle was used by the MobiLink server to upload
multiple CHAR type columns to a consolidated database running on an Oracle
9.2.0.8 server, it could have failed with the error;
"ORA-01461: can bind a LONG value only for insert into a LONG column"
This problem has now been fixed.
================(Build #3834 - Engineering Case #556326)================
Applications running on Unix systems, and using the iAS ODBC driver for Oracle,
could have received an "Out of memory" error when calling SQLTables,
SQLColumns, SQLPrimaryKeys, SQLForeignKeys, SQLProcedureColumns, SQLProcedures,
or SQLStatistics. This problem has now been fixed.
================(Build #3784 - Engineering Case #547049)================
After calling SQLGetTypeInfo, the application would not have been able to
get the column names through problem could have prvented exporting MobiLink
Monitor data to an Oracle database. This has now been fixed.
================(Build #3778 - Engineering Case #546072)================
The iAS ODBC driver for Oracle could have crashed when the application tried
to create multiple connections concurrently. This problem was more likely
to have occurred on Unix systems. This problem has now been fixed.
================(Build #3715 - Engineering Case #533749)================
The iAS ODBC driver for Oracle could have given mangled error and warning
messages to the application when it was running on a operating system that
used a multi-byte character set, such as a Japanese or Chinese. This problem
is now fixed.
================(Build #3686 - Engineering Case #499969)================
When the event of a download_cursor, or a download_delete_cursor, in a MobiLink
server synchronization logic was written as:
{call procedure_name( ?, ? )}
for consolidated databases running on an Oracle server, the iAS ODBC driver
for Oracle may have given the error:
ORA-06553: PLS-306: wrong number or types of arguments in call to 'procedure_name'
if the stored procedure returned a result set and the word, "call"
was not all in lower-case. This has now been fixed.
================(Build #3670 - Engineering Case #496568)================
The iAS ODBC driver for Oracle could have shown poor performance when concurrent
access was required by multi-threaded applications, such as the MobiLink
server. This problem has been corrected.
================(Build #3649 - Engineering Case #492667)================
If a Windows application called the function SQLColAttribute() with SQL_DESC_OCTET_LENGTH
when using the iAS ODBC driver for Oracle, it could have been returned the
transfer octet length in characters, rather than in bytes. Due to this problem,
the application could have incorrectly truncated data. This problem has now
been fixed.
Note, this problem should not happen if the application is the MobiLink
server. The MobiLink server does not call the ODBC function SQLColAttribute().
================(Build #3635 - Engineering Case #490229)================
An application using the iAS ODBC driver for Oracle may have crashed if a
SQL statement caused an error on the Oracle database server or the OCI library,
and if the error message returned from the Oracle server or the OCI library
was greater than 466 bytes in length. This problem is now fixed.
================(Build #3633 - Engineering Case #489741)================
If an application using the iAS Oracle driver issued a "call procedure_name"
statement (without open and close parentheses) through the ODBC functions
SQLPrepare or SQLExecDirect, and the procedure "procedure_name"
returned a result set, the driver could have crashed when the "Procedure
returns results" check-box was checked on Windows, or the "ProcResults"
entry was set to 'yes' on UNIX. This has now been fixed.
================(Build #3605 - Engineering Case #485483)================
If an application used the iAnywhere ODBC driver for Oracle to fetch result
set from a packaged procedure, the driver would have reported the following
error:
[Sybase][iAnywhere Solutions - Oracle][Oracle]ORA-06553: PLS-306: wrong
number or types of arguments in call to {procedure name}
This problem could have caused the MobiLink server to fail the download,
when a download_cursor or download_delete_cursor event was written as:
{ call package_name.procedure_name ( ?, ?, ...) } or
{ call schema_name.package_name.procedure_name( ?, ?, ... ) }
This problem has been fixed. Now this event can be written as:
{ call [schema_name.][package_name.]procedure_name( ?, ?, ... ) }
================(Build #3571 - Engineering Case #480434)================
The iAS ODBC driver for Oracle could have returned numeric data with a comma
"," as the decimal point on some international installations if
the Oracle database used commas as the decimal point. However, the MobiLink
server is able to handle numeric data that uses commas as a decimal point
for download, which would have caused it to abort the synchronization. This
problem has now been fixed.
================(Build #3474 - Engineering Case #464640)================
The IAnywhere Oracle ODBC driver could have crashed if the following ODBC
API functions were called in this order:
SQLAllocHandle( ..., SQL_HANDLE_STMT, ...) (returns SQL_SUCCESS)
SQLExecDirect( ..., "select ...", ... ) (returns SQL_SUCCESS)
SQLExecDirect( ..., "insert...", ...) (returns SQL_ERROR)
SQLFreeStmt( ..., SQL_UNBIND) with the same statement handle.
The number of columns of the result set was not reset to zero when the same
statement handle was reused. This problem has now been fixed.
================(Build #3589 - Engineering Case #483578)================
When creating a download using the MobiLink Java direct row API, some actions
could haver destabilized the MobiLink server. Setting parameters with incompatible
data, or setting columns multiple times with null values that were not nullable,
could have caused the MobiLink server to send an invalid row to the synchronization
client, or crash. This has been fixed.
================(Build #3576 - Engineering Case #481994)================
When using the MobiLink Java DirectRow api, setting or getting data of types
Date, Time or Timestamp could have worked incorrectly. When using a ResultSet,
the returned value could have been null, When using a PreparedStatement,
the value could have been set as null. This has been fixed.
================(Build #3503 - Engineering Case #471044)================
When accessing column values in the upload using Java direct row handling,
the ResultSet.getObject() method could have returned null instead of an object
representing the column value. Methods such as ResultSet.getString(), ResultSet.getInteger()
etc. would have worked correctly. This is now fixed.
================(Build #3493 - Engineering Case #468558)================
The MobiLink plug-in may have failed to create an index on the timestamp
column used for timestamp-based synchronization if the consolidated database
was an Oracle consolidated database. The script the plug-in uses (in ml-template.zip)
has been fixed and the column is now properly indexed.
================(Build #3692 - Engineering Case #528978)================
The SQL Remote Message Agent (dbremote) could have displayed the error, "SQL
statement failed: (-260) Variable 'n?' not found", where ? was an integer
greater than or equal to 10, if a replication table contained more than 9
columns (they could have beeb CHAR, BINARY or BIT type columns) with a data
length greater than 256 bytes. This problem has now been fixed.
================(Build #3927 - Engineering Case #581542)================
If a database had a schema with a very large number of columnsa, it was possible
that when dbxtract was run, that the select statement generated to extract
the data from some of the tables would have used an incorrect column order.
This would likely have resulted in the rebuild failing, since the data types
of the columns in the new database would not match the data that have been
extracted from the remote database. The problem has now been fixed.
Note that this problem only affected dbxtract, and not dbunload.
================(Build #4039 - Engineering Case #619254)================
If a database had been initialized with the UCA collation sequence, and to
respect accent sensitivity on all UCA string comparisons, it was likely that
operations on tables without a SUBSCRIBE BY clause in the publication definition
would have failed to replicate. No errors would have been reported, but operations
that should have replicated would not have been sent. This has now been fixed.
================(Build #4020 - Engineering Case #616829)================
If the SQL Remote Message Agent (dbremote) connected to a database that had
remote or consolidated users defined, but did not have a publisher defined,
then dbremote would not have reported any errors, but would have simply reported
"Execution Complete". This has been corrected so that dbremote
will now report an error indicating that no publisher was defined in the
database.
================(Build #3990 - Engineering Case #467100)================
When very rare, a client application using a shared memory connection could
have hung forever while executing a statement. This has been fixed.
================(Build #3982 - Engineering Case #596641)================
If all of the following conditions were met, then SQL Remote would have continued
to hold locks in the database until the next time that it needed to send
the results of a SYNCHRONIZE SUBSCRIPTION to a remote database:
1) SQL Remote was running in send-only mode (-s)
2) SQL Remote was running in continuous mode
3) SQL Remote was satisfying a resend request for user "X", and
was forced to re-scan the transaction logs
4) While scanning the transaction log, a SYNCHRONIZE SUBSCRIPTION operation
was scanned for a user "Y"
5) User "Y" had already been sent the results of the SYNCHRONIZE
SUBSCRIPTION operation in a previous run of SQL Remote.
This has been fixed by releasing the locks when the send phase of dbremote
reaches the end of the transaction log and determines that the SYNCHRONIZE
SUBSCRIPTION operation does not need to be sent to the remote user.
The problem can be worked around by stopping and starting the dbremote process
that was running in send-only mode.
================(Build #3718 - Engineering Case #479191)================
When SQL Remote was scanning the active transaction to determine which operations
to send, it was possible for the process to have crashed when it had reached
the end of the active transaction log. This has been fixed.
================(Build #3691 - Engineering Case #528650)================
If the precision for a DECIMAL or NUMERIC column was greater than 30, then
SQL Remote and RepAgent would only have replicated up to 30 digits in accuracy
to a remote or secondary database, and the Log Translation utility (dbtran)
might only have written 30 digits in accuracy to a SQL file. The rest of
the digits would have been replaced by zero. This problem has been fixed.
The accuracy of the replicated/translated data should now be as high as it
was stored in the original database.
================(Build #3734 - Engineering Case #536374)================
HotSync may have logged a -305 error for a synchronization failure, and potentially
other database corruption. This has been fixed.
================(Build #3977 - Engineering Case #594913)================
UltraLite primary key constraints must be named "primary". This
requirement was not being enforced when the primary key was defined. This
has been corrected so that now it is. Databases that have primary key constraints
not named "primary" should be rebuilt.
================(Build #3970 - Engineering Case #592873)================
By specifying the primary key in a separate clause of the CREATE TABLE statement,
the UltraLite runtime allowed tables to be created with Long column types
(ie. BLOBS, CLOBS) as primary keys.
For example: 'CREATE TABLE t1( v1 LONG VARCHAR, PRIMARY KEY(v1))'
The use of long datatypes in indexes is not supported by UltraLite, and
inserting into the resulting table would have resulted in a crash. This has
been corrected, long datatypes are now flagged as invalid when used in an
index.
================(Build #3946 - Engineering Case #561596)================
Incorrect values were being used by the SQL scanner for some hexadeciml constants.
This was corrected
================(Build #3928 - Engineering Case #581269)================
There were no implementations for the datatypes LONG BINARY and LONG VARCHAR.
These have now been added.
================(Build #3924 - Engineering Case #580353)================
Queries with TOP or START AT clauses were incorrectly flagged with an error
when they exceeded 64K. This restriction has now been removed.
================(Build #3921 - Engineering Case #580016)================
Unexpected behavior could have occurred when IN predicates were used in subqueries
in INSERT, UPDATE, and DELETE statements. This has been corrected.
================(Build #3854 - Engineering Case #562245)================
Using the MobiLink file-based download to transfer files on Palm devices
to a VFS volume, could have failed. The error reported would have been STREAM_ERROR_INTERNAL.
On some devices, VFSFileSeek returns an EOF error when seeking to the end
of file, but the seek actually succeeds. A work around for this problem has
been implemented.
================(Build #3841 - Engineering Case #557837)================
Incorrect results were possible when there was both an equality condition
and another redundant conjunctive expression such as:
x >= 2 AND x = 3
with only a column name on one side of the comparison. That column name
must also have been the first column in an index. This has now been fixed.
================(Build #3838 - Engineering Case #557685)================
UltraLite and UltraLiteJ erroneously accepted DEFAULT TIMESTAMP as a clause
in the CREATE TABLE and ALTER TABLE statements, and treated the clause as
if DEFAULT CURRENT TIMESTAMP had been entered. Attempts to execute CREATE
TABLE or ALTER TABLE statements with this clause will now result in a syntax
error.
================(Build #3835 - Engineering Case #556539)================
UltraLite and UltraLiteJ were not able to recognize a correlation name following
the table name in UPDATE and DELETE statements. Without this ability, WHERE
clauses that require the correlation name to disambiguate column references
could not be written.
For example:
update Employee E
set salary = salary * 1.05
where EXISTS( SELECT 1 FROM Sales S HAVING E.Sales > Avg( S.sales)
GROUP by S.dept_no )
The syntax for UPDATE and DELETE statements was been expanded to correct
this.
================(Build #3809 - Engineering Case #551692)================
If a query consisted of a non-zero number of UNION DISTINCT operations, followed
by a non-zero number UNION ALL operations, the result set could have had
twice as many columns as were specified by the query. The leftmost columns
would have been correct, while the rightmost extra columns were bogus. The
alorithm for creating the selection list for the overall query was flawed,
and has now been corrected.
================(Build #3785 - Engineering Case #547234)================
When the UltraLite SQL functions length() and char_length() were used on
LONG VARCHAR columns, the results were incorrectly the lengths of the strings
in bytes, rather than characters. Note that some characters require multiple
bytes internally. The function byte_length() is used to determine the length
in bytes of the string. This has been fixed.
================(Build #3779 - Engineering Case #495369)================
The performance of some queries has degraded from what it was in version
9. Further optimizations have been added so that the performance has been
restored.
================(Build #3688 - Engineering Case #500482)================
Incorrect diagnostics could have been generated when there were comma-specified
joins followed by operation-specified joins (LEFT OUTER JOIN, for example),
and an ON condition in the operation-specified joins referenced a column
from the comma-separated joins. This was now bee corrected.
A work-around is to place the comma-separated table expressions in parentheses.
For a query such as:
SELECT * FROM tab1, tab2, tab2 LEFT OUTER JOIN tab4 ON tab4.x = tab1.y
the work-around is to rewrite the query as:
SELECT * FROM ( tab1, tab2, tab2 ) LEFT OUTER JOIN tab4 ON tab4.x = tab1.y
================(Build #3664 - Engineering Case #495240)================
If an ALTER <column> statement encountered an error, subsequent statements
could have erroneously failed with the error SQLE_SCHEMA_UPGRADE_NOT_ALLOWED,
and/or the runtime could have experienced a crash at some later point. This
has been fixed.
================(Build #3664 - Engineering Case #494963)================
When there were at least three joins in a query table expression and there
was a reference from the ON condition to a column in a table at least three
preceding, an incorrect syntax error may have occurred. This has been corrected.
================(Build #3659 - Engineering Case #494259)================
A column could have been altered to have a different datatype, even when
column was in a foreign key or constraint. This is now disallowed.
================(Build #3655 - Engineering Case #493762)================
Incorrect results could be obtained for for some queries that used indexes
in which there was more than one nullable column. This was corrected.
================(Build #3653 - Engineering Case #493478)================
Incorrect results could have been returned for for some queries with row
limitation (using FIRST, TOP, and/or START AT clauses), when a query was
not read-only and when a temporary table was required to execute the query.
For example:
SELECT TOP 14 * FROM table ORDER BY table.column
when there was no index that could be used to order the data. This has now
been fixed.
================(Build #3650 - Engineering Case #492675)================
Incorrect results could have been returned for for some DISTINCT ORDER BY
combinations. This would have occurred when a DISTINCT clause was used and
there were no unique indexes that could be used to guarantee distinctness,
there was an ORDER BY clause and no indexes exist to effect that ordering
and not all of the the ORDER BY constituents were found in the SELECT list.
For example:
SELECT DISTINCT last_name FROM people ORDER BY birth_date
This has now been corrected.
================(Build #3649 - Engineering Case #492344)================
An erroneous conversion error could have been detected when an IF expression
involved an aggregate. For example: "IF count(n) > 50 THEN 'good'
ELSE 'bad' ENDIF" This has been corrected.
================(Build #3646 - Engineering Case #492031)================
In order to drop a table from the database, it must first be removed from
all publications. Failing to remove the table from any publications prior
to attempting to drop it would have resulted in an error. However, the UltaLite
database would have been left in a corrupt state after the error was returned,
as the operation was not fully rolled back. This has now been fixed.
================(Build #3626 - Engineering Case #488699)================
Table expressions with brackets may have caused syntax errors. For example,
Select * from (table1) left join table2
This was corrected by adjusting the syntax to handle more general bracketing.
================(Build #3622 - Engineering Case #488275)================
It was possible for downloaded rows that contained long varchar or long binary
columns to have been corrupted. Symptoms ranged from garbage characters
read from a row to crashing the database. The problems were caused by an
uninitialized variable, so the operations that can trigger the bug were varied.
This has now been corrected.
================(Build #3611 - Engineering Case #486556)================
When running on a slow network an UltraLite application could have failes
with the error message 'Internal Error (1003)'. This problem has now been
fixed. This change is similar to the fix for the MiobiLink client, Engineering
case 486446.
================(Build #3605 - Engineering Case #485815)================
The DATEADD() function did not detect overflow situations. This has been
corrected.
================(Build #3599 - Engineering Case #485004)================
A constant at the start of an aggregate selection could have caused erroneous
results. An example would be:
SELECT 999, count(*) FROM TABLE
where the incorrect result was a row for each row in the table, instead
of a single row. Constants were not being marked as aggregates when they
occurred in aggregate selections. This has been fixed.
================(Build #3596 - Engineering Case #484452)================
It was possible for UltraLite to allow duplicate entries into unique key
indexes, or it could have incorrectly reported a duplicate entry in a unique
key. For this to have occurred, a table would need to have been left open
while many hundreds of updates were happening to the same row, as well as
many other inserts and deletes needed to occur to other tables concurrently.
This is now fixed.
================(Build #3573 - Engineering Case #481254)================
An UPDATE statement would have updated only one row, even if more rows satisfied
the WHERE conditions, if the column in the WHERE clause was indexed.
For example, consider a table with the following schema:
CREATE TABLE Tab1( pk int not null primary key, value varchar(1) not null
)
CREATE INDEX val_index ON Tab1( value )
The following statement could possibly update more than one row:
UPDATE Tab1 SET value = ‘x’ WHERE value = ‘y’
However, since there is an index on value, this update would have only updated
at most one row. This has been fixed and it will now update all qualifying
rows.
================(Build #3570 - Engineering Case #481467)================
Calling the byte_length() function with an integer value for the parameter,
would have returned a value inconsistent with SQL Anywhere server. This has
been corrected.
================(Build #3570 - Engineering Case #481427)================
Calling the byte_length() function with a NULL for the parameter would have
returned a random value instead of NULL. This has been corrected.
================(Build #3569 - Engineering Case #481432)================
The changes to the UltraLite runtime for Engineering case 480878, caused
it to not send the upload progress in the first synchronization, which is
what the MobiLink server expects. However, this change also caused the runtime
to stopped sending the last download timestamp on the first synchronization
as well. This resulted in the MobiLink server using a default timestamp of
0000-01-00 00:00:00.000000, which could be rejected by the consolidated database
as an invalid timestamp. This has been fixed so that the runtime now sends
the last download timestamp on the first synchronization, but not the upload
progress.
================(Build #3564 - Engineering Case #480878)================
Synchronization of a recreated database could have fail if the remote id
was still the same. By default a new database will have a randomly generated
UUID for a remote id. This has been fixed.
================(Build #3550 - Engineering Case #476708)================
The problem requires the schema of the UltraLite database to have a table
with a unique constraint (other than the primary key) and another table referencing
that unique constraint with a foreign key. When a delete is downloaded, all
rows referencing the deleted row (via a foreign key to the table) should
also be deleted to maintain referential integrity. This was working properly;
however, a similar scenario existed if an update was downloaded and the foreign
key referencing the row did so by referencing a unique constraint instead
of the primary key. This has been fixed.
================(Build #3539 - Engineering Case #476195)================
Erroneous results could have been returned for a query with both START AT
and TOP clauses. This has been corrected.
================(Build #3537 - Engineering Case #476372)================
Synchronizing more than one database at a time using encryption or compression,
could have caused the UltaLite runtime to crash. This has been fixed.
================(Build #3536 - Engineering Case #476112)================
Erroneous results could have been returned for a query with an inner join
and a WHERE clause containing a subquery. This has been corrected.
For example:
SELECT COUNT(*) FROM kb_baseclass INNER JOIN customer ON kb_baseclass=customer
WHERE customer IN (SELECT client FROM contact)
================(Build #3530 - Engineering Case #475138)================
Erroneous results could have been obtained for queries with joins containing
a derived table with GROUP BY, and a WHERE clause referencing a column from
the derived table. This has been corrected.
================(Build #3523 - Engineering Case #473449)================
Database file space allocated for long varchar or long binary columns was
not properly reclaimed on deletion of the row in some cases. As a result,
the database file could have grown unexpectedly. This has been fixed. Applying
this fix will prevent further unnecessary growth but not reclaim the lost
space within the database file. To reclaim space, the database file must
be recreated.
================(Build #3511 - Engineering Case #472364)================
UltraLite allows a publication to be created with a predicate for each of
its tables. This allows users to filter rows in a table being synchronized.
If the predicate contained a subquery, it was possible that the predicate
evaluated to the wrong result, either allowing all rows to be uploaded, or
none to be uploaded. This has been fixed.
Also, note that there are two errors in the documentation. Under UltraLite
– Database Management and Reference/Working with UltraLite Databases/Working
with UltraLite publications/Publishing a subset of rows from an UltraLite
table, the following are incorrect:
"Palm OS: You cannot use a CREATE PUBLICATION statement with a WHERE
clause on this platform."
In fact, a WHERE clause can be used on Palm OS.
The paragraph "What you cannot use in a WHERE clause"
In fact, you can use columns from tables not in the article (or even not
in the publication). You can also use subqueries.
================(Build #3502 - Engineering Case #470176)================
There was no implementation for the ODBC function SQLSynchronizeW() in the
Runtime, even though it is defined in ulodbc.h. This has been corrected by
implementing SQLSynchronizeW().
================(Build #3502 - Engineering Case #466683)================
The runtime could have crashed at the end of an HTTPS synchronization. This
has been fixed.
================(Build #3499 - Engineering Case #469974)================
An application would have failed to autostart the engine when using a quoted
StartLine value that contained spaces in the path. For example, the following
startline would have failed with SQLE_UNABLE_TO_CONNECT_OR_START:
StartLine="\Program Files\uleng10.exe"
This problem has been fixed.
This problem can be worked-around by making the opening quote the second
character:
StartLine=\"Program Files\uleng10.exe"
or by enclosing the entire quoted value in single quotes:
StartLine='"\Program Files\uleng10.exe"'
================(Build #3491 - Engineering Case #468456)================
For certain MobiLink server errors, such as authentication failure, a second
error may have appeared later in the log: "Download failed with client
error xxx" when download acks had been turned on. This could have been
confusing, since it suggested the error originated on the client, when the
true error was reported further up in the server log. This has been corrected;
the second error message will no longer appear.
================(Build #3486 - Engineering Case #467268)================
Synchronizations that took longer than ten minutes could have been timed-out
by the MobiLink server, if the synchronization parameter 'timeout' was set
to zero. MobiLink clients send keep-alive bytes to the MobiLink server at
an interval of half the timeout value to keep the connection active, UltraLite
was not sending these bytes if the timeout value was set to zero. This has
been fixed.
================(Build #3482 - Engineering Case #466456)================
If an application had an open cursor, and another transaction deleted a row
that affected that cursor, it was possible for the cursor to have been positioned
on the wrong row. This has been fixed.
================(Build #3478 - Engineering Case #465693)================
If the ExecuteQuery method detected an error, a non-null ResultSet could
still have been returned. This was corrected.
================(Build #3475 - Engineering Case #465368)================
If the Timeout synchronization parameter was set to a value that was too
low, and a TLS or HTTPS synchronization was being done over a slow channel,
the runtime may have attempted to send a liveness packet before the TLS handshake
had been completed, causing the synchronization to fail in a number of different
ways. The MobiLink server may have reported a handshake or protocol error,
or the client could have crashed. This has been fixed
================(Build #3475 - Engineering Case #465151)================
The UltraLite runtime would have accepted the empty string as a valid script
version. This has been fixed. The empty string is now rejected, just like
if it had been set to NULL.
================(Build #3474 - Engineering Case #464837)================
A synchronization would have failed if it used publications, and the runtime
did not know if the MobiLink server had received the upload of the previous
synchronization. This has been fixed.
================(Build #3474 - Engineering Case #464473)================
When executing the statement ALTER TABLE ADD FOREIGN KEY there was not check
that the new foreign key rows all had matching primary rows. A check has
been added so that the statement will now fail if a primary row is missing.
================(Build #3473 - Engineering Case #464158)================
A new statement, ALTER DATABASE SCHEMA FROM FILE, now allows for alteration
an UltraLite database schema. This statement replaces the 9.0.2 schema upgrade
feature that was implemented with the UpgradeSchemaFromFile() / ApplyFile()
methods from this previous release.
Because Ultralite error callback is active during the upgrade process, the
application is notified of errors during the conversion process. For example,
SQLE_CONVERSION_ERROR reports all values that could not be converted in its
parameters. Errors do not mean the process failed. The final SQL code after
the statement returns is a 130 warning in this case. These warnings describe
operations of the conversion process and do not stop the upgrade process.
Note: There is no mechanism to support the renaming of tables, columns or
publications. Also, renaming a table is processed as a DROP TABLE and CREATE
TABLE operation.
Caution: Resetting the device during the upgrade process leaves the database
unusable.
To upgrade the schema with this new statement:
1. Define a new schema by creating a SQL script of DDL statements. The character
set of the SQL script file must match the character set of the database you
want to upgrade.
The UltraLite utilities ulinit or ulunload can be used to extract the DDL
statements required for this script. Use these utilities to ensure that the
DDL statements required are syntactically correct.
- For ulunload, use the –n and –s [file] options.
- For ulinit, use the –l [file] option.
See the UltraLite Database Management and Reference documentation for details.
2. Review the script and ensure that:
- That non-DDL statements have not been included. Including non-DDL statements
does not have the expected effect.
- Words in the SQL statement are separated by spaces.
- Only one SQL statement can appear in each line.
- Comments are prepended with '--' and only occur at the start of a line.
3. Backup the existing database.
4. Run the new statement using the following syntax:
ALTER DATABASE SCHEMA FROM FILE ‘<filename>’
For example:
ALTER DATABASE SCHEMA FROM FILE 'MySchema.sql'
5. The existing database is upgraded with the new schema using the following
process:
- Both the new and existing database schemas are compared to see what
differs.
- The schema of the existing database is then altered accordingly.
- Rows that do not fit the new schema are dropped. When this occurs, a
SQLE_ROW_DROPPED_DURING_SCHEMA_UPGRADE (130) warning is raised.
For example, if a uniqueness constraint was added to a table, and there
are multiple rows with the same values, all but one row will be dropped.
Alternately, if an attempt to change a column domain causes a conversion
error, then that row will be dropped. That is, say a VARCHAR column is converted
to an INT column, if the value for a row is “ABCD”, then that row is dropped.
Lastly, if the new schema has new foreign keys where the foreign row doesn't
have a matching primary row, these rows are also dropped.
If dropping rows is not the desired behavior of the schema upgrade, detect
the warning and restore from backup.
================(Build #3470 - Engineering Case #460942)================
Table names exceeding 128 characters were not handled correctly. In particular,
they were being improperly trunctated, allowing duplicate tables with the
same apparent name to be created. Such table names are now diagnosed as
syntax errors.
================(Build #3470 - Engineering Case #460745)================
As of the release of SQL Anywhere 10.0, synchronization concurrency was reduced.
In particular, other threads and processes were blocked from entering the
UltraLite runtime during upload, and while waiting for MobiLink to create
the download. This has been fixed.
================(Build #3470 - Engineering Case #456783)================
When the DEFAULT clause specified a character string for a column in a CREATE
or ALTER table statement, and the length of that character string exceeds
126 characters, the characters string was truncated to 125 characters, instead
of 126 characters. This has been corrected.
================(Build #3470 - Engineering Case #456698)================
The special value NULL, used by itself in certain SELECT expressions, could
have given incorrect results. For example, the query "select NULL union
select NULL" did not give the correct results. This has been corrected.
================(Build #3470 - Engineering Case #456644)================
Calling UltraLite_ResultSet.Set did not set NOT NULL when a value was supplied.
This could have also have affected the Set methods in various components.
This has been fixed.
================(Build #3470 - Engineering Case #456070)================
If CreateDatabase was called to create an encrypted database, and an encryption
key waspassed via the connection parameters but ULEnableStrongEncryption
wasn't called, CreateDatabase would have created an unencrypted database
without reporting any warnings or errors. This has been fixed so that CreateDatabase
will now fail in this situation with SQLE_ENCRYPTION_NOT_ENABLED. When attempting
to connect to an encrypted database and an encryption key was provided, but
ULEnableStrongEncryption wasn't called, the runtime would have reported SQLE_BAD_ENCRYPTION_KEY,
which could have been misleading. This has been corrected so that the runtime
will now report SQLE_ENCRYPTION_NOT_ENABLED for this as well. Also, when
attempting to connect to an unencrypted database and an encryption key is
provided, but ULEnableStrongEncryption isn't called, the connection will
still succeed, but the runtime will now report a warning SQLE_ENCRYPTION_NOT_ENABLED_WARNING.
Note that these changes only apply to applications that use the C++ or embedded
SQL interfaces and don't use the UltraLite engine. Applications that use
the engine, or any of the components, did not have these problems since they
always call ULEnableStrongEncryption internally.
================(Build #3437 - Engineering Case #463517)================
On Windows CE devices, database corruption could have occurred due to a bug
in Windows CE related to growing the database file. A change to the runtime
to close and reopen the file after growing it has been implemented in an
attempt to work around the problem.
================(Build #3503 - Engineering Case #470582)================
The error 'Function or Column name reference "Unknown" must also
appear in GROUP BY', may have been erroneously raised when an IF expression
involved an aggregate function.
For example:
IF count(n) > 50 THEN 'good' ELSE 'bad' ENDIF
This has been corrected.
================(Build #4063 - Engineering Case #627238)================
The Include directory reference for the UltraLite CustDB sample on Windows
Mobile 6 platforms was incorrect. The Windows Mobile 6 platform Include directory
pointed to the %sqlanyX%\h directory, but should have pointed to %sqlanyX%\SDK\Include.
While correcting this, it was noted that there were inconsistencies in the
quoting of the Include directory across the projects. Now all references
are quoted.
================(Build #4061 - Engineering Case #626666)================
The UltraLite CustDB sample application About dialog incorrectly stated "for
Windows CE" for all Windows platforms. This has been removed from the
dialog text.
================(Build #4067 - Engineering Case #628275)================
Clicking Finish in the Load Database wizard would have caused Sybase Central
to crash if a database id was not specified on the last page of the wizard.
This has been fixed.
================(Build #4061 - Engineering Case #626662)================
The Load Database wizard would crash on a second attempt if the first attempt
failed, or was canceled, before completion. This has been fixed.
================(Build #4048 - Engineering Case #623481)================
If the Set Primary Key wizard was proceeded through without making any changes
and the Finish button was clicked, then an extraneous error message would
have been shown. Now the wizard simply closes.
================(Build #4047 - Engineering Case #623280)================
Renaming a table using its property sheet, and then attempting to open a
column's details on the Property sheet's Columns tab, would have caused Sybase
Central to crash. This has been fixed.
================(Build #3785 - Engineering Case #547224)================
When selecting data using the Interactive SQL utility, from an UltraLite
database that was UTF8 encoded, it was possible for extra garbage characters
to have be displayed at the end of the string. For example, if a VARCHAR
column contained the string 'für' (the middle letter is u umlaut) and the
database was UTF8 encoded, selecting that column would have displayed a garbage
character at the end (typically a box). Note that this was a display problem
only. This has been fixed. A possible work around is to cast the data as
VARCHAR(x), where x is a value big enough to display the data.
================(Build #3664 - Engineering Case #494155)================
UltraLite requires that each table have a primary index. Using SQL statements,
it was possible to remove or rename this primary key, which would eventually
have lead to a crash of the UltraLite application. Attempting to remove or
rename a table's primary key will now result in an error.
================(Build #3660 - Engineering Case #494579)================
When changing a column's DEFAULT value to "No default value", a
syntax error would have been reported. The plugin was incorrectly executing
the statement ALTER TABLE t ALTER c DROP DEFAULT. This has been fixed so
that the plugin now uses the correct syntax ALTER TABLE t ALTER c DEFAULT
NULL.
================(Build #3656 - Engineering Case #493741)================
An attempt to alter a column to DEFAULT NULL would have been ignored. This
has now been corrected.
================(Build #3635 - Engineering Case #490471)================
When connected to two UltraLite databases and attempting to unload the first
into the second, when the Finish was clicked on the page that asked for the
destination database, the wizard would not have noticed the change in the
selected destination database on that page and then tried to load into the
default destination database, which in this case was the same database as
the source database. This has been fixed so that the wizard now correctly
records the selection, and/or correctly pops up a dialog letting the user
know that the source database is the same as the destination database.
================(Build #3635 - Engineering Case #490312)================
Attempting to unload a database using the Sybase Central Unload wizard, that
was not currently connected to, into an XML or SQL file would have failed
with a null pointer exception. This has been fixed.
================(Build #3634 - Engineering Case #490210)================
When viewing the properties of a table in the UltraLite plug-in for Sybase
Central, it was possible to change the table’s synchronization type of Normal,
Always or Never. Doing this would have created a new table with a different
suffix (either empty, _nosync or _allsync), however the original table would
not have been dropped. This has been fixed.
================(Build #3634 - Engineering Case #489538)================
When examining the properties of a foreign key that was created as CHECK
ON COMMIT, the properties would always have been reported that CHECK ON COMMIT
was off. This has been fixed.
================(Build #3600 - Engineering Case #484889)================
Attempting to unload an UltraLite database while selecting a long list of
tables to unload, would have caused Sybase Central to crash. This has been
fixed.
================(Build #3470 - Engineering Case #462362)================
The Unload wizard could still have tried to connect, even if there was a
failure. If the failure was ignored and the user clicked on Finish again,
Sybase Central could have crashed. This was most likely to have occurred
if unloading from a currently connected database. This problem may also have
occurred with other wizards. These problems have been fixed.
================(Build #3470 - Engineering Case #456562)================
When selecting publications in the Extract Wizard, if one publication was
selected, the appropriate tables were displayed. However if more than one
publication was selected, no tables were displayed. This has been fixed.
================(Build #3906 - Engineering Case #575142)================
Invalid metadata could have been constructed for a UNION DISTINCT operation.
The Interactive SQL utility uses this metadata for display purposes when
connected to an UltraLite database. This could have resulted in abnormal
terminations for statements such as: "SELECT 1 UNION DISTINCT SELECT
2". This has now been corrected.
================(Build #3755 - Engineering Case #541478)================
The table name was not reported for SQLE_PRIMARY_KEY_NOT_UNIQUE when this
error was encountered during a synchronization. This has been fixed.
================(Build #3742 - Engineering Case #540390)================
A comparison between an integer and a BINARY value (in a SQL statement) would
have caused a conversion error, 'Cannot convert numeric to a binary'. This
has been corrected.
================(Build #3689 - Engineering Case #500825)================
Attempting to execute queries where the number of join operations exceeded
15, could have caused the UltraLite runtime to crash. This has been fixed.
================(Build #3677 - Engineering Case #497511)================
The diagnosis of invalid GROUP BY expressions has been enhanced.
================(Build #3662 - Engineering Case #493738)================
Performing an ALTER TABLE statement on a table with blob columns may have
caused corruption in the database. The most likely symptom of this would
have been a crash when selecting from a table that has been altered. This
has now been fixed.
================(Build #3660 - Engineering Case #494710)================
Incorrect results could have been returned when there was an ORDER BY clause
that caused a temporary table to be generated. For this to hace occurred
there must have been a subquery expression in the select list that referred
to a table that could be updated, and the query had to have been potentially
updateable (FOR READ ONLY was not specified).
This was corrected. The work-around is to specify FOR READ ONLY on the query.
================(Build #3592 - Engineering Case #484074)================
A LIKE condition of the form: "column LIKE constant", could have
produced incorrect results when the column was not of type CHAR and occurred
as the first column of an index. This has been corrected.
================(Build #3550 - Engineering Case #478059)================
The UltraLite engine would have leaked process handles at a rate of one per
client process per second. The engine was regularly opening a handle to
each client process to determine if they were still running, but these handles
were not being closed. These handles are now closed.
================(Build #3512 - Engineering Case #470315)================
The default name of a primary key constraint is "primary". If a
table was created with a constraint name that was not the default, Sybase
Central would have crashed silently when navigating to the Data tab.
For example, navigating to the Data tab for the following table definition
would have caused Sybase Central to crash:
CREATE TABLE t1
(
c INTEGER NOT NULL,
CONSTRAINT "cn" PRIMARY KEY("c" ASC)
This problem has now been fixed.
================(Build #3503 - Engineering Case #470282)================
An erroneous conversion error could have been raised when executing a query
if it referenced a derived table which was empty on the right side of a left
outer join, and the derived table contained a GROUP BY clause and had a NUMERIC
item in its SELECT list. This has been fixed.
================(Build #3481 - Engineering Case #466202)================
The maximum number of active SQLCA variables (i.e. SQLCAs that have been
initialized and used to call into the runtime, but not finalized) supported
by the UltaLite engine has been increased from 31 to 63.
For .NET applications, the SQLCA limit also represents the database connection
limit, since a new sqlca is used for each connection. Also, an internal
SQLCA is used by each .NET application, so the effective connection limit
for .NET apps is 63 minus the number of running .NET clients.
Note that the runtime's connection limit is 64.
================(Build #3477 - Engineering Case #465388)================
Inserting a row that contained a zero-length binary value for a long binary
column would have caused the UltraLite engine to crash. This has been fixed.
================(Build #3470 - Engineering Case #462796)================
The ABS() function (absolute value of a numeric expression) did not properly
handle integers with more than 30 digits. This has been corrected.
================(Build #3946 - Engineering Case #581830)================
The implementations of CreationParms::AddRef and CreationParms::Release,
contained confusing casting. Both methods cast the POD object to a ConnectionParms
object, which has now been fixed.
================(Build #3890 - Engineering Case #568836)================
Incorrect results could have been obtained when using an index which had
nullable columns In some cases, fewer rows were returned than were required.
This has been fixed..
================(Build #3474 - Engineering Case #462642)================
Queries involving 'long varchar' or 'long binary' columns, containing both
null and non-null values, and a temp table, could have caused a crashed in
UltraLite, signaled an error, or produced incorrect results for the 'long'
columns. This has now been fixed.
================(Build #3897 - Engineering Case #561616)================
Application errors could have occurred after opening and closing more than
255 connections. Each .NET connection allocated two SQLCAs, but only one
was freed when the connection was closed. The other would not have been
freed until the connection was garbage collected. This has been fixed.
A workaround for this problem is to call GC.Collect() regularly.
================(Build #3676 - Engineering Case #497458)================
Undefined errors could have occurred if ULDatabaseManager::CreateDatabase()
was called with a null collation. This has been fixed so that a SQLE_INVALID_PARAMETER
ULException will now be thrown for a null collation.
================(Build #3664 - Engineering Case #495578)================
The method ULDataReader.GetBytes() would have returned null if invoked for
a binary(n), or a long binary, column containing an empty string (ie. a zero
length not null value). This has been fixed. GetBytes() will now returns
a zero length array of bytes.
================(Build #3651 - Engineering Case #492148)================
If the Connection.synchronize() function failed with an exception, the message
in the exception did not contain any relevant details. For example, the
text for a SQLE_PRIMARY_KEY_NOT_UNIQUE( -193) error did not include the
table name ("Primary key for table '-n/a-' is not unique."). This
has now been corrected.
================(Build #3628 - Engineering Case #479829)================
Errors (like sticky I/O errors) reported while closing the connection would
have had incomplete error messages (i.e. I/O failed for '-n/a-'). This has
been fixed.
================(Build #3764 - Engineering Case #540349)================
The UltraLite Initialize Database utility (ulinit) would have reported a
syntax error if the reference database contained a foreign key on a table
with the keyword 'name'. Ulinit was failing to quote the table name in the
foreign key statement generator. This has been fixed.
================(Build #3723 - Engineering Case #535586)================
If an index was defined in the reference database as:
create index idx on t(a asc, b asc, c asc)
The UltraLite Initialize Database utility (ulinit) would have created the
index as:
create index idx on t(c asc, b asc, a asc).
reversing the order of the columns. This has been corrected and ulinit will
now create the index in the same order as the reference database.
================(Build #3629 - Engineering Case #478925)================
When using the UltraLite Unload utility to unload an UltraLite database to
SQL Statements, the owner would have been included in the CREATE PUBLICATION
statement. The statement would not habe been valid syntax for UltraLite.
This has been fixed.
================(Build #3574 - Engineering Case #481965)================
When using the following SQLAnywhere options with the reference database:
default_timestamp_increment = 10000
truncate_timestamp_values = 'On'
the UltraLite database produced when running the UltraLite Initialization
utility ulinit on this database would have caused problems when synchronizing.
MobiLink would have complained about timestamp precision mismatches. Ulinit
was not setting the timestamp_increment from the SA default_timestamp_increment
value.
The workaround is to set the timestamp_increment setting on the ulinit command
line, using
the -o keyword=value option, as follows:
ULINIT <existing options> -o timestamp_increment=1000
================(Build #3558 - Engineering Case #479825)================
A number of problems with the UltraLite Database Initialization utility have
been fixed.
Default values were being wrapped in parentheses (), for example DEFAULT
(0), which lead to sytax errors. Default valuess that start (after skipping
white space) with open parentheses "(" and end with close parentheses
")", are now recognized and are automatically stripped.
Specifying the clause DEFAULT getdate(*) also lead to a syntax error. All
occurrences of "(*)" in DEFAULT strings are now replaced with "()".
Previously, only DEFAULT NEWID(*) was being recognized, this change handles
all such functions.
Ulinit was failing to quote table names with leading underscore characters
"--".
The now(), current_timestamp(), and getdate() functions in DEFAULT strings
are now replaced with the string "current timestamp". This is equivalent
in operation and the only syntax that UltraLite supports.
Added quoting to all uses of table names. Specifically the CREATE INDEX
and ALTER TABLE ... ADD FOREIGN KEY statements were problematic.
Ulinit was making use of NVARCHAR data types. nut UltraLite does not support
this data type.
================(Build #3553 - Engineering Case #479032)================
When the UltraLite Synchronization utility's (ulsync) output was redirected
to a file, and sync progress messages were requested with -v, those messages
would not have been written on some patch levels of Windows Vista. Writes
to standard output for the progress messages were being discarded when standard
output of the owning executable (ulsync.exe) was not connected to a console.
This has been fixed by using a callback function to report messages, rather
than writing messages directly to stdout.
================(Build #3550 - Engineering Case #478022)================
Applying Microsoft's XML security patch KB 936181 (MSXML 4.0 dll version
4.20.9848.0) to Windows Vista systems, would have caused the UltraLite Load
utility to crash. This problem does not show up on Windows XP. A work around
has been implemented to prevent the crash.
================(Build #3512 - Engineering Case #472222)================
If the UltraLite language DLLs were removed from the installation, the UltraLite
ODBC driver may have caused Sybase Central and dbisql to crash. The ODBC
driver now explicitly checks for missing resources and reports an error if
no resources are found.
================(Build #3508 - Engineering Case #471825)================
When unloading UltraLite database to SQL, the UltraLite Unload utility would
have missed any tables where IsNeverSynchronized() would have returned true.
This has been corrected
================(Build #3496 - Engineering Case #469570)================
If the default command file for the Listener utility (dblsn,txt) was used
implicitly, then having the -q option in the command file would have had
no effect on the gui, instead of minimizing it. The desired behavior was
achieved if the same command file was used explicitly (i.e. dblsn.exe @dblsn.txt).
This problem has been fixed.
================(Build #3487 - Engineering Case #467502)================
A warning message output by the UltraLite Database Initialization utility
may have been misleading. When column subsets in a table T that were referenced
in a publication PUB, were used to build an UltraLite database, the following
warning was displayed:
ignoring column subset for publication 'PUB', table 'T' -- all columns
will be added
Actually, the column subset was being used to build the UltraLite table,
it's just that columns not in the subset were being properly excluded from
the UltraLite table schema. The message was intended to warn the user in
regard to synchronization publications, as UltraLite always synchronizes
all of the rows of a table that is specified in a sync publication. Part
of the confusion is due to overloading the concept of a publication as a
set of tables plus columns to be included in the schema, with the concept
of a publication as a set of tables to be synchronized. In order to make
this clearer, the warning has been changed to:
ignoring column subset for synchronization publication 'PUB', table 'T'
-- UltraLite synchronizes entire rows"
================(Build #3474 - Engineering Case #464849)================
When a column for an INSERT statement was bound in a Java application as
follows:
stmt.setTimestamp( pnum, new java.sql.Timestamp(System.currentTimeMillis())
);
executing the INSERT statement would have failed with a SQLE_CONVERSION_ERROR.
The microseconds were not scaled into nanoseconds, and vice versa. This has
been fixed.