SQL Anywhere
************

Bug Fix Readme for Version 7.0.4
********************************

Description of different download types
=======================================

    Express Bug Fixes
    ===================
    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.

    Maintenance Release
    ===================
    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:
    http://my.sybase.com/detail?id=1019567


********************************************************************************
********************************************************************************
CRITICAL BUG FIXES
********************************************************************************
********************************************************************************
This section contains a description of critical bug fixes made since the release
of version 7.0.4.  If any of these bug fixes appear to affect your installation,
iAnywhere strongly recommends that you install this EBF.



                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **          Server          **                      
                      ******************************                      

=================(Build #3431  - Engineering Case #333024)=================

The server could have failed with the error "Fatal error: Unknown device 
error", or corrupted a table, when updating a large row with a page 
size larger than 4K.  This would only have occurred if the update statement 
was making the row larger than 4K.  As a result of the corruption, rows 
could have gone missing.  This has been fixed.  



Note, this fix does not recover lost or corrupted rows.


=================(Build #3526  - Engineering Case #361509)=================

Servers running on Windows systems, other than Windows 95, could have 
experienced database corruption if the system crashed due to an OS or 
hardware problem (or it was powered off unexpectedly), and write caching 
was enabled on the drive containing the database files. 



A work around would be to disable write caching in the Device Manager, 
via the Disk Properties tab in the Properties dialog, for the drives 
in question.  (This might be necessary in any case for IDE drives).


********************************************************************************
********************************************************************************
END OF CRITICAL BUG FIXES
********************************************************************************
********************************************************************************


BUG FIXES
=============
This section contains a description of bug fixes made since the release
of version 7.0.4.



                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **   DBLIB Client Library   **                      
                      ******************************                      

=================(Build #2669  - Engineering Case #259566)=================

A dblib or ODBC app trying to connect using LINKS=all didn't attempt 
to connect over the shared memory port. This has been fixed; shared 
memory will be tried first.


=================(Build #2695  - Engineering Case #262520)=================

The Timeout parameter wasn't supported on NetWare when using SPX. It 
is now supported. 



=================(Build #2707  - Engineering Case #264435)=================

When fetching more than 65536 rows, with prefetch enabled, extra rows 
could have, (under rare circumstances), appeared in the result set.  
This extra rows no longer appear.



=================(Build #2729  - Engineering Case #266176)=================

The Java version of dbisql, (not dbisqlc), and Sybase Central could 
have disappeared without any error message during a connection attempt.  
There must have been enough connection information for the connection 
to succeed, but the connection must have also been given a warning in 
order for this problem to have occurred.  This problem would not occur 
if the JDBC-ODBC bridge was used. It has been fixed.



=================(Build #2729  - Engineering Case #266215)=================

dblocate and Find Servers (from the connection dialog) would sometimes 
not include all ASA servers, and would sometimes list servers duplicate 
times with the same host name. This also applied to the DBLib db_locate_servers 
function.  Now all ASA servers running TCP/IP (except those started 
with -sb) will be found by dblocate and Find Servers. If a server is 
run on a machine with multiple IP addresses, it may be listed multiple 
times, particularly if dblocate or Find Servers is run on the same machine 
as the server. If a server is listed multiple times, the numerical IP 
addresses will now be listed for that server.




=================(Build #2776  - Engineering Case #269317)=================

If a UNIX application had a dblib or odbc connection environment defined, 
at the time that it did a fork() call, (i.e. created a new process which 
was a "clone" of itself), and the child process did not immediately 
do an exec() call, (i.e. replace the process space), then the parent's 
communications could have  become corrupted and cause it to hang or 
die.  If the parent was connected to a server via tcpip, then the parent 
could have received a SIGPIPE signal, which if not handled would have 
caused the application to terminate.

With this fix, the child of an application that executes a fork() while 
having one or more environments defined will not be allowed to use any 
odbc or dblib, (and hence dbtools), API calls, (i.e. all calls to odbc 
and dblib executed by the child will immediately return the error, COMMUNICATION_ERROR, 
if using ODBC, and SQLCODE -85 if using dblib).

Example 1: Child process is not allowed to talk to server
	Parent Application				Child
	SQLAllocEnv()
	:
	(any sequence)
	:
	fork()   --------------------------------->	:	
	:						:
	(all calls are still allowed)			(all odbc/dblib API calls are disallowed)
In this example, the application creates an ODBC environment, performs 
any number of calls (connections, queries, etc), and then forks a child 
process.  The child process will receive an  error code.  The parent 
process is still allowed to perform operations on its connections.

Example 2: Child process is allowed to open connections to server
	Parent Application				Child
	SQLAllocEnv()
	:
	(any sequence)
	:
	SQLFreeEnv()
	:
	fork()   --------------------------------->	:
	:						:
							SQLAllocEnv()			SQLAllocEnv() - child creates its own ODBC environment
	:						:
	(all calls are allowed)				(all calls are allowed)
In this example, the application creates and uses an ODBC environment.  
Before it forks a child it disconnects any connections and frees the 
ODBC environment.  The child process is then able to create its own 
environment and connect to the server.  Note: a simplification of this 
example would have the parent process simply doing a fork() without 
any prior ODBC calls; in this case, the child is also allowed to communicate 
to a server.

Example 3: Typical method to spawn a new child process - this is OK
	Parent Application				Child
	:
	(any sequence of calls)
	:
	fork()   --------------------------------->	:
	:						:
	(any sequence of calls)				exec()	- child process replaces its address 
space with a new executable
This is the typical sequence that is used when an application want 
to start another process.   This sequence does not cause any communication 
problems with or without this fix.

Example 4: Spawn a daemon process - with this fix, this is OK, but 
before this fix, this would cause the parent to die
	Parent Application		Child			Daemon
	SQLAllocEnv()
	:
	(any sequence of calls)
	:
	fork()   --------------------->	:
	:				:
	(any sequence of calls)		fork() --------------->	:
	:				:			:
	:				:			exec()	- daemon process replaces its address space with a 
new executable
	:				exit() - child terminates
This example illustrates the sequence that is used typically to start 
a daemon process. i.e. a child process that is disassociated with its 
parent.   Prior to this change, this sequence will cause the parent 
to experience communication problems.  A work-around is to not allow 
the first child process to exit - rather it should exec another process, 
as shown in this next example:

Example 5: Spawn a daemon process (work-around communications problems)
	Parent Application		Child			Daemon
	SQLAllocEnv()
	:
	(any sequence of calls)
	:
	fork()   --------------------->	:
	:				:
	(any sequence of calls)		fork() --------------->	:
	:				:			:
	:				:			exec()	- daemon process replaces its address space with a 
new executable
	:				exec( "/bin/true" ) - child replaces its address space and execute 
the "/bin/true" program
In this example, the first child executes a dummy program that does 
nothing.



=================(Build #2780  - Engineering Case #270769)=================

The error "Specified database is invalid" would be displayed when trying 
to connect to an engine with an engine name or database name containing 
a space.
For example,	
dbping -d -c "uid=dba;pwd=sql;eng=space test1;dbn=space test2;dbf=asademo.db;astop=no".
This connection string now works.


=================(Build #2784  - Engineering Case #271280)=================

The dblocate utility, (or components using the connection dialog Find 
Servers), could have crashed or failed to find servers, when run on 
Windows 2000 or Windows XP. This has now been fixed.


=================(Build #2789  - Engineering Case #276250)=================

Calling db_stop_database(...) with a sqlca, that had not been used to 
connect to the database, would have caused the application to crash. 
This is now fixed.


=================(Build #3291  - Engineering Case #242743)=================

If a TCPIP or SPX connection is terminated abnormally, (i.e. without 
a database disconnect), a message is now displayed on the server console, 
(if the -z switch was specified), with the user name and the reason 
that the connection was dropped. Shared memory connections already have 
such a message - "Disconnecting shared memory client, process id not 
found". A message is also displayed if a DBA user drops a connection 
using the DROP CONNECTION statement. This message contains the user 
name of the user who executed the DROP CONNECTION, and the connection 
number and user name of the connection that was dropped.


=================(Build #3298  - Engineering Case #272907)=================

If two or more TCP/IP connections were made from the same application, 
and the first one used the DoBroadcast parameter, any subsequent connections 
that did not, could have crashed the application on shutdown, (or when 
DB_Fini was called). This has been fixed.


=================(Build #3326  - Engineering Case #275477)=================

If dbisql or Sybase Central attempted to use an ODBC DSN containing 
an encrypted password, an "invalid password" error was returned. This 
has been fixed.


=================(Build #3333  - Engineering Case #270319)=================

If a host variable is declared as follows:



EXEC SQL BEGIN DECLARE SECTION;

char * str_host_var;

EXEC SQL END DECLARE SECTION;



sqlpp does not know the length of str_host_var.  When connected to 
a blank padded database with the option ANSI_BLANKS ON, data fetched 
into a host variable with unknown length was not correctly blank padded 
or null terminated.  This has been fixed so that in this case the fetched 
data will be null terminated but not blank padded.



This problem could have caused MobiLink to fail on blank padded database 
with the ANSI_BLANKS option ON.



Note that great care must be taken when using host variables with unknown 
length to avoid over-writing more memory than was allocated for the 
host variable, and using host variables with unknown lengths should 
be avoided where possible.  (This is documented in the "Using host variables" 
section in "The Embedded SQL Interface chapter" in the "Programming 
Interface Guide" book).


=================(Build #3334  - Engineering Case #279074)=================

If the DEBUG=YES;LOGFILE=file connection parameters were used from a 
multithreaded client application, (using different files for each connection), 
there was a chance the application could have crashed.  When using the 
ODBC Administrator, Display debugging information in a log file, on 
the Advanced tab, is equivalent to DEBUG=YES;LOGFILE=file. This is now 
fixed.


=================(Build #3336  - Engineering Case #279463)=================

A Unix client application may have failed to connect to a local server 
via shared memory.



One of two scenarios may have been seen:

1 - the engine may report a message similar to:

	[unixshm] AttachToSharedMem p=18874 e=__SQLAnyCli__18874_1824660827lx 
id=2 n=<NULL> o=0 s=4096 d=1 errno=0 FAILED

2 - If the Unix server's name length was greater or equal to 31 characters 
long, the client may have reported a message similar to:

	[unixshm] AttachToSharedMem p=18874 e=the_name_of_the_local_engine_xx 
id=2 n=<NULL> o=0 s=4096 d=1 errno=0 FAILED



In both cases, the client library would have reported back to the application 
that it could not connect to the server. These problems are now fixed.




=================(Build #3341  - Engineering Case #286696)=================

When a client application using TCP/IP or SPX disconnected from the 
server, an error "[Sybase][ODBC Driver]Disconnect error: Transaction 
rolled back" could have occurred, (error number 01002). By default, 
the timeout for a disconnects was 5 seconds.  On a busy server, it could 
take longer than 5 seconds to hear back from the server and this would 
result in the message described above. There was no provision for a 
user specified timeout, so a new connection parameter has been added 
to specify the disconnect timeout value, (the default is still 5 seconds).The 
new option, "TIMEOUT=n" or "TO=n", is specified in the TCP/IP or SPX 
communications option string.



Example:

rc = SQLDisconnect( hdbc );

if ( (rc == SQL_ERROR) || (rc == SQL_SUCCESS_WITH_INFO) ) {

    /* get the error message */


=================(Build #3359  - Engineering Case #289947)=================

If the file asasrv.ini, (.asasrv.ini on Unix platforms), was large, 
connection attempts could be slow or even fail. This has been fixed.


=================(Build #3366  - Engineering Case #293215)=================

If the asasrv.ini (.asasrv.ini on Unix) file was large, connection attempts 
could have been slow or have even failed. This has now been fixed. The 
asasrv.ini file will now only cache the most recent 100 entries.


=================(Build #3397  - Engineering Case #303124)=================

This change resolves a number of sporatically problems which could have 
been seen:

- failing to connect to the utility_db running on a network server

- failing to connect to a server while using a FILEDSN (or any ODBC 
DSN on UNIX)



For either of the above to have occurred, the file containing the utility_db's 
dba password (util_db.ini) or the FILEDSN, or the UNIX ODBC DSN must 
have had the following properties:

- the DSN being used was the last one in the file

- the last line of the DSN was the last line in the file

- the last line of the file was either not terminated, or terminated 
with a single line-feed char (i.e. not carriage-return/line-feed as 
on Windows platforms)



For example, the client could have failed to connect to the utility_db 
on the first attempt, but be successful if the exact same client connect 
string was specified a second (or third) time.  Then if tried immediately 
again it could have failed again, etc.



This has been fixed, but a work-around is to add a blank line to the 
end of the file.




=================(Build #3398  - Engineering Case #287923)=================

A threaded client application could hang calling db_fini, if using embedded 
SQL or SQLFreeEnv, if using ODBC.  This is now fixed


=================(Build #3490  - Engineering Case #331789)=================

After a multi-threaded windows application called db_fini, SQLFreeEnv, 
etc to finalize the client database interface (dblib, ODBC, etc), there 
could have been unfreed thread handles remaining. This has been fixed 
so that all thread handles created by the client database interface 
are now freed.  



Note the client database interface library will only free all resources 
after it has been finalized the same number of times it has been initialized.


=================(Build #3494  - Engineering Case #333108)=================

It was possible for the disconnect of a shared memory connection to 
the NetWare server to cause the server to crash. This has been fixed.


=================(Build #3508  - Engineering Case #341109)=================

The behaviour of an empty connection parameter was changed inadvertently 
by engineering change 336563.  This fix restores the behaviour to be 
the same as before the change.


=================(Build #3509  - Engineering Case #342519)=================

When attempting to connect over the shared memory link, a rare timing 
dependant situation may have caused the application to hang. This was 
more likely (although still very rare) to have occurred on multiprocessor 
machines. This has been fixed.


=================(Build #3536  - Engineering Case #375971)=================

An application could have hung, received a communication error, or have 
possibly seen other incorrect behaviour, when doing a fetch with prefetch 
enabled, and then immediately doing a commit, rollback, or another fetch 
with an absolute or negative offset. It was rare on multiprocessor machines, 
and would have been even rarer on single processor machines. As well, 
there may have been other timing dependent cases which could have failed. 
This has been fixed.




                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **   ODBC Client Library    **                      
                      ******************************                      

=================(Build #2769  - Engineering Case #270335)=================

If an ODBC application called SQLFetch, after a SQLMoreResults, without 
an intervening SQLBindCol, the SQLFetch call would have caused a client 
crash. This has been fixed.


=================(Build #2787  - Engineering Case #271305)=================

If the option TRUNCATE_TIMESTAMP_VALUES was set to ON, applications 
connecting using TDS may have caused the server to crash with assertion 
failed 103102. This has been fixed


=================(Build #2789  - Engineering Case #272142)=================

Executing a query with Apache and PHP, when connecting to ASA, if the 
query takes too long to execute. it could return no data or an error. 
This has been fixed.


=================(Build #3289  - Engineering Case #271065)=================

When connecting over TCPIP and using the DoBroadcast=NONE parameter 
to skip the UDP broadcast, the client makes a TCP connection, and then 
verifies that the name of the server found is the same as the one requested. 
With this change, the client can specify VerifyServerName=NO, (or Verify=NO), 
to skip verification of the server name. This effectively allows ASA 
clients to connect to an ASA server, if they know ONLY an IP address 
and port. This is not the recommended method of connecting to an ASA 
server, but is now available for customers who need such functionality.

Note that a server name must still be specified in the connect string, 
but it will be ignored. The VerifyServerName parameter is only used 
if DoBroadcast=NONE is specified, and is only supported on the client.


=================(Build #3291  - Engineering Case #272599)=================

An ODBC 2.0 application could have received a communication error when 
fetching into bound columns of type SQL_C_DEFAULT, if the database type 
was TIMESTAMP, TIME or DATE.  This has been fixed.


=================(Build #3296  - Engineering Case #272714)=================

The ODBC function, SQLDescribeCol, was always reporting columns of type 
BIT as non-nullable. This would cause ADO to be confused when a NULL 
value was returned. This has now been corrected.



=================(Build #3328  - Engineering Case #274367)=================

In very rare cases, the client could crash on SQLFreeEnv, (or db_fini), 
if an IPX connection was used.  A handle leak was also fixed for the 
same situation.


=================(Build #3328  - Engineering Case #276169)=================

An ODBC application, running with a database that had the quoted_identifier 
option set 'OFF', could have had some ODBC function calls fail. The 
driver was issuing queries that had identifies quoted, regardless of 
the option setting. The driver now issues queries, respcting the Quoted_identifier 
option setting.



=================(Build #3336  - Engineering Case #277779)=================

The server could have crased after truncating a table.  For this to 
have occurred, the connection doing the truncate must have had a cursor 
open on the table being truncated and the cursor must have remained 
open after a commit or rollback.  If the table had more than 100 pages 
in it 8.x engines could have crashed regardless of cursor orientation.  
For 7.x engines (and 8.x engines on smaller tables) the cursor must 
have been going backwards through the table. This problem is now fixed.




=================(Build #3339  - Engineering Case #278421)=================

When an application had multiple threads, doing simultaneous connections, 
and the connections used the same log file, (ie debug=yes;log=...), 
an "Unable to open client error file" message would have appeared. This 
has now been fixed.


=================(Build #3341  - Engineering Case #278998)=================

The dbisqlc utility returned the error 'invalid user or password', if 
the connect string used DSN=datasource and the datasource had an encrypted 
password. This has been fixed.


=================(Build #3343  - Engineering Case #277160)=================

A client application could have hung for over an hour with 100% CPU 
usage, if an attempt was made to connect to a database file, (DBF), 
which was already running and also specifying a different database name, 
(DBN).  With 8.0.0 or above, this could only happen if connecting to 
a pre 8.0.0 server.  The connection attempt will now return the error 
"Database name not unique" within a few seconds.


=================(Build #3369  - Engineering Case #293163)=================

It was possible that SQLDescribeColW or SQLColAttributeW would have 
attempted to write past the end of the user's buffer, depending on the 
connection's CHARSET and the database's Collation Sequence.  This could 
have caused the ODBC driver to crash or return incorrect results.  This 
problem has been fixed.


=================(Build #3395  - Engineering Case #302554)=================

SQLColAttributes and SQLColAttribute would have returned the type as 
"char" for the following column types:

LONG VARCHAR

BINARY

VARBINARY

LONG VARBINARY

BIGINT

TINYINT

BIT

GUID



The correct type name is now returned.


=================(Build #3396  - Engineering Case #302303)=================

An ODBC application could have crashed, if it called SQLGetDiagRec or 
SQLGetDiagRecW with the record number parameter greater than 2 and there 
were three or more diagnostic records. This has been fixed.


=================(Build #3416  - Engineering Case #308449)=================

The ODBC driver may have occasionally reported the lengths of strings 
incorrectly, when dealing with multibyte character sets.  The data was 
returned correctly, but the length would sometimes be too long. The 
length reported should now be correct.




=================(Build #3420  - Engineering Case #302959)=================

A query with a proxy table and an alias in the select list may have 
caused the server to crash or hang with 100% cpu utilization. This is 
now fixed.


=================(Build #3426  - Engineering Case #310019)=================

The returned value for SQL_DBMS_VER was only displaying the major version 
of the server that the driver was connected to. For example, for ASA 
7.0.4, the string returned was "07.00.0000" and, for Adaptive Server 
IQ 12.4.3, the string "12.00.0000" was returned.



This has been corrected. For Adaptive Server Anywhere version 7.0.4 
the string returned for SQL_DBMS_VER is now "07.00.0004".  For Adaptive 
Server IQ version 12.4.3, the string "12.04.0003" will be returned.


=================(Build #3433  - Engineering Case #312857)=================

A call to SQLMoreResults was returning SQL_NO_DATA_FOUND, instead of 
SQL_ERROR, when a batch contained a statement with an error. According 
to the ODBC specification, if one of the statements in a batch fails, 
and the failed statement was the last statement in the batch, SQLMoreResults 
should return SQL_ERROR. This has been corrected.


=================(Build #3446  - Engineering Case #317600)=================

Fetches from Microsoft Access 2000 to an ASA database could have been 
significantly slower than from Access 97.  The performance difference 
would have been more noticeable when fetching over a LAN or WAN.  This 
has been fixed.




=================(Build #3467  - Engineering Case #323291)=================

If a cursor had both bound columns and used getdata statements, and 
the first column was not bound but accessed using a getdata, then the 
fetch may have returned no error or warning when it should have returned 
SQL_NOTFOUND or SQL_NO_DATA.  This problem was more likely when the 
DisableMultiRowFetch parameter was used.  Attempting to do a getdata 
when past the end of the result set would have failed with a "No current 
row of cursor" error.

Also, if a cursor had both bound columns and used getdata statements, 
and the DisableMultiRowFetch connection parameter is used, poor performance 
could have occurred.

Both of these problems have been fixed.


=================(Build #3524  - Engineering Case #339348)=================

If an application's object destructor made an ODBC call after exit() 
had been called (or the application's main() routine had returned), 
then the application may have crashed,  (i.e. a call was made to the 
ODBC driver after the runtime had called the library's fini routine).



Also, if the application was using ODBC driver on  Unix as a driver 
manager, and made an ODBC call after it has destroyed the ODBC environment 
(i.e. SQLFreeEnv had been called), then the application may have crashed.



This has been fixed, now an error will be returned.






                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **   OLEDB Client Library   **                      
                      ******************************                      

=================(Build #2633  - Engineering Case #233564)=================

This fix resolves several ADO problems:
- Parameterized queries were not working
- Forward-only cursors could only get the first record
- Read-only cursors were not read-only
- Cursor type was changed after the ADO recordset was opened



=================(Build #2645  - Engineering Case #257583)=================

Transaction rollback in ADO had no effect, all operations where being 
autocommitted by the driver.



=================(Build #2645  - Engineering Case #257960)=================

A column string value may have appeared to be empty when retrieved if 
the database used a characters set that was not supported by the host 
OS, (UTF8 databases were not affected). The provider has been changed 
to use the ANSI code page when the NLS code page is unavailable. This 
is compatible with the ASA ODBC driver.


=================(Build #2651  - Engineering Case #242412)=================

ASAProv was not always returning numeric values to ADO bound grid controls 
properly, causing them to not be displayed correctly.This was due to 
ADO not being passed the status and length of field values when calling 
IRowset::GetData. This has now beed fixed.


=================(Build #2654  - Engineering Case #256872)=================

ADO recordsets could not scroll backwards. If the rowset was created 
by a command object, the ASA Provider did not use the rowset properties 
specified by ADO, instead it used the default values, (where the proberty 
DBPROP_CanScrollBackwards is false).


=================(Build #2654  - Engineering Case #258724)=================

The ASA Provider was setting the CHAINED option to OFF, thus each statement 
was being committed individually, causing any rollbacks to fail.The 
default value of CHAINED option is ON which means a transaction is implicitly 
started before any statement. The Provider now does not change this 
option.


=================(Build #2658  - Engineering Case #258716)=================

Saving a long character value into a database field, caused data truncation 
when running on Windows CE


=================(Build #2659  - Engineering Case #255676)=================

Calling the OpenSchema method using the adSchemaProviderTypes option 
resulted in an error stating that the option was not supported


=================(Build #2690  - Engineering Case #262066)=================

Calling stored procedures from Visual Basic, Output parameter were not 
being returned. This has been fixed.


=================(Build #2696  - Engineering Case #262783)=================

An ADO Stored Procedure call would have failed if the parameters were 
created by calling the ADO method Refresh and the CommandType was adCmdStoredProc. 
This has now been fixed.


=================(Build #2697  - Engineering Case #262935)=================

When testing OLE DB IDBProperties::GetPropertyInfo, the MDAC Local Test 
Manager reported failures. Some ASA OLE DB properties had a description 
which was inconsistent with OLE DB spec, other properties were in wrong 
property group.  Fixed by changing the OLE DB properties' description 
and group.


=================(Build #2717  - Engineering Case #265348)=================

The provider was failing to convert BigInt parameters correctly on Windows 
XP, although these conversions worked fine on Windows NT/2000. This 
was due to the MDAC version on Windows XP being 2.7. After upgrading 
to MDAC 2.7, the problem could be seen on Windows NT/2000 as well.The 
provider uses the OLE DB Data Conversion Library to convert different 
OLE DB data types. When initializing the Library, IDCSetInfo::SetInfo 
should be called to furnish the Data Conversion Library with information, 
such as the provider version, that affect how conversions are performed. 
Fixed by calling IDCSetInfo::SetInfo to set the OLE DB version to 2.50.


=================(Build #2724  - Engineering Case #265877)=================

When calling ADO Recordset.Delete, if the current record couldn't be 
deleted for some reason, (ie data integrity constraint violation), the 
application wouln't get the error messages. This has now been fixed.



=================(Build #2724  - Engineering Case #265878)=================

When calling ADOCE Recordset.Delete, to delete the current record, if 
the record couldn't be deleted ( for some reasons, ie. data integrity 
constraint violation ), the app could have crashed. This has now been 
fixed.


=================(Build #2738  - Engineering Case #267279)=================

The ASA provider didn't support ADO client side cursor. Now with this 
fix, the ASA provider supports both client side and server side cursors. 
Although the use of multiple result sets is still not supported with 
client side cursors.


=================(Build #2743  - Engineering Case #265573)=================

An ODBC application which called SQLGetData to retrieve data into a 
fixed-length type, (SQL_C_SLONG for example), but provided a buffer 
length greater than 300, (this buffer length would be ignored by ODBC 
for fixed-length types), would have had poor performance on these SQLGetData 
calls.  Microsoft Access is an example of an application which calls 
SQLGetData in this way.  This performance problem has been fixed.


=================(Build #2748  - Engineering Case #268229)=================

ADO stored procedure parameters were not being passed to the server, 
if the Command.CommandType was
adCmdStoredProc and Command.Prepared was true. This has now been fixed.



=================(Build #2748  - Engineering Case #268304)=================

The ASA provider was not releasing the IAlterTableImpl object, thus 
causing a memory leak. This has now been fixed.


=================(Build #2749  - Engineering Case #268379)=================

The ASA provider did not release the IIndexDefinitionImpl object, causing 
a memory leak. This has now been fixed,


=================(Build #2750  - Engineering Case #268489)=================

The ASA provider was not releasing the IConnectionPointImpl object, 
causing a memory leak. This has now been fixed.


=================(Build #2750  - Engineering Case #268523)=================

The ASA provider was not freeing BSTR after calling SafeArrayPutElement. 
This then resulted in a memory leak. The BSTR is now freed after calling 
SafeArrayPutElement.



=================(Build #2751  - Engineering Case #268623)=================

The ASA provider was not freeing BSTR after the Properties object was 
released. This then resulted in a memory leak. The BSTR is now freed 
when the Properties object is released.



=================(Build #2768  - Engineering Case #270153)=================

The MDAC Data Link Component always chose ASAProv.70, if there were 
multiple versions installed. This was due to all versions of The ASA 
Provider using the same registry key, "Sybase Adaptive Server Anywhere 
Provider". This was fixed by adding the version number to the ASAProv 
registry key.


=================(Build #2773  - Engineering Case #269229)=================

The ASA provider was not releasing the ODBC Environment Handle, which 
resulted in a memory leak. This has now been fixed.


=================(Build #2775  - Engineering Case #270674)=================

Calling MovePrevious, in the ADO DataControl object, would have failed 
on static and dynamic cursors. This has been fixed.


=================(Build #2777  - Engineering Case #270891)=================

The ASAProv implementation of IRowsetLocate::GetRowsAt was incorrect, 
as a result, a call to the  ADO method DataControl.MovePrevious on keyset 
cursor would have failed This has been fixed.



=================(Build #2780  - Engineering Case #270881)=================

The ASA Provider was not allocating enough memory for connection string 
buffer. As result, the run time stack may have become corrupted. When 
using ADO, the error 'catastrophic failure', could have occurred. After 
this fix, the maximum length of the connection string is 1024 bytes.


=================(Build #2785  - Engineering Case #268704)=================

The ASA Provider had a memory leak in it's implementation of the ADO 
rowset object. This has been fixed


=================(Build #2785  - Engineering Case #271551)=================

The ASA Provider was not releasing the ODBC connection handle, if the 
connection failed, thus resulting in a memory leak. This has now been 
fixed.


=================(Build #2786  - Engineering Case #271629)=================

The ASA Provider was not releasing the ODBC statement handle, resulting 
in a memory leak. This has now been fixed.


=================(Build #2789  - Engineering Case #273193)=================

If an applcation set a VARCHAR field to null,  the ASA provider would 
have caused. This is now fixed.


=================(Build #2790  - Engineering Case #271812)=================

Opening an ADOCE 3.0 or 3.1Recordset, with a select statement ,  (ie 
select id, count(line_id)  from DBA.sales_order_items  group by id), 
and moving to the last row by calling MoveLast, would have returned 
an EOF or BOF error incorrectly. This is now fixed


=================(Build #3228  - Engineering Case #275401)=================

The OLEDB provider could have returned incorrect values for the DBCOLUMN_IDNAME 
property. As well, it  could have either crashed or returned incorrect 
information, when the values of other properties were requested. This 
problem caused the generation of XML in a MS.Net webservice application 
to be incorrect and would have caused the OLEDB sample "Rowsetviewer" 
to crash or return incorrect/incomplete results, when asked for property 
lists.
This problem,which is now fixed, could also manifest itself in the 
incorrect behaviour of ADO applications.


=================(Build #3328  - Engineering Case #271435)=================

Preparing a command, executing it and then rexecuting it would have 
failed with the database error "Invalid Cursor state", if the command 
opened a result set.  While the problem is now fixed, removing the call 
to "Prepare" the statement would be a work around.  The problem was 
evident when using the Dataset and OleDBDataAdapter classes in a C# 
project.


=================(Build #3328  - Engineering Case #273545)=================

When fetching character data using the ASAProv provider, an error could 
have occurred, if the character column contained an empty string and 
the iSequentialStream interface was used to fetch it.  Fetching data 
larger than 512 bytes could also have failed, when using the iRowset 
GetNextRows method. Both of these problems were exhibited when trying 
to view data in a long varchar column in the "Server Explorer" of Visual 
Studio.Net This is now fixed.



=================(Build #3328  - Engineering Case #276510)=================

The OLEDB provider would have returned incorrect version string information 
for the DBPROP_DBMSVER property. The version reported would have had 
the correct major version number and build number, but the patch level 
was not included.  For example, the 7.0.3 release provider would have 
reported 07.00.2046.  The provider will now report 07.03.xxxx, where 
xxxx is the build number of the EBF


=================(Build #3330  - Engineering Case #272848)=================

Fetching data from a numeric column could have failed and caused various 
errors, if the precision of the column was less than 19. This is now 
fixed.



=================(Build #3330  - Engineering Case #277858)=================

Using server side cursors with the ASAProv provider and associating 
a recordset with an ADO grid control would not have shown any data in 
the grid control and would not have reported any errors. This is now 
fixed.


=================(Build #3330  - Engineering Case #278035)=================

Applications using the OLEDB provider could have crashed when creating 
and freeing multiple recordset objects. A reference counting issue, 
which led to the freeing of an object twice in some cases, has been 
fixed.




=================(Build #3334  - Engineering Case #278552)=================

Visual Studio.Net applications, using ASA's OLEDB provider through the 
DataTable and DataAdapter classes, were returning errors while trying 
to select a column with a long varchar of unknown length. The error 
message that displayed was: "No error information available: DB_E_ERRORSOCCURRED(0x80040E21)." 
This is now fixed.


=================(Build #3337  - Engineering Case #279849)=================

In an ADO application, a call to MovePrevious after a call to MoveLast 
could have caused an application to crash, if the rows contained large 
text columns. This has now been fixed.


=================(Build #3342  - Engineering Case #287012)=================

Fetching more than 2 records in a result set would have truncated any 
text or blob values at 200 bytes. This is now fixed.




=================(Build #3342  - Engineering Case #287034)=================

Updating a forward only cursor via ADO could have resulted in an error 
stating "An invalid fFetchType value was specified". This is now fixed.




=================(Build #3344  - Engineering Case #273547)=================

Any attempt to update a recordset field value to NULL, would have been 
ignored and the change would not have been sent to the database by the 
provider. This is now fixed, but as a workaround, an update statement 
executed to specifically set the columns to NULL would still work, as 
the provider passes these directly to the server.


=================(Build #3347  - Engineering Case #287296)=================

Character data fetched in a .Net WebService application could have had 
the last character of the data truncated. An off-by-one error was fixed.




=================(Build #3351  - Engineering Case #288424)=================

When fetching string data using the System.Data.OLEDB components, various 
errors could have occurred. These included "Object reference not set 
to an instance of an object", data exceptions, infinte recursion errors 
and application faults. The problem has been fixed.


=================(Build #3351  - Engineering Case #289286)=================

If a client application fetched string data with a length larger than 
199 bytes through the ASA Provider, and conversion of the data was required 
(eg. from ascii to unicode), the data returned to the application would 
have been truncated.  Visual Studio .Net data access components (including 
DataTable and DataAdapter classes) would be subject to this problem. 
It is now fixed.


=================(Build #3355  - Engineering Case #289983)=================

When calling a stored procedure through ASAProv, if an output parameter 
was created in the application with a length of one byte, no data would 
have been returned for that parameter.  While this is now fixed, a workaround 
would be to create the parameter with a length of 2 bytes or more, then 
a one byte output parameter will be returned correctly.


=================(Build #3355  - Engineering Case #290469)=================

If a client application fetched string data with a length larger than 
199 bytes through ASAProv, and conversion of the data was required, 
(eg. from ascii to unicode), the data returned to the application could 
have been missing the last byte.  Visual Studio .Net data access components, 
(including DataTable and DataAdapter classes), would have been subject 
to this problem. The correct data is now returned.


=================(Build #3356  - Engineering Case #286636)=================

If a select statement caused a warning to be generated, (eg. "Null value 
eliminated in aggregate function"), ASAProv would sometimes have returned 
an error, causing applications to stop processing the result set.  As 
a result ADO applications could report errors such as "Invalid operation 
- EOF or BOF has been reached". Now warnings, with the exception of 
a problem that occurs when dealing with a truncation warning, are no 
longer treated as an error.


=================(Build #3357  - Engineering Case #291070)=================

When accessing the database via ASAProv, if a user opened a cursor, 
fetched some rows and then tried to get a row count on the cursor, the 
provider would have returned either 1 or 0, instead of the actual row 
count. Now, the actual rowcount is returned or -1 if it is unable to 
determine the actual rowcount, (in compliance with the OLEDB spec.)




=================(Build #3359  - Engineering Case #291233)=================

Using the same OLEDB command object to execute a command more than 1024 
times, would have caused an out of memory error. This has been fixed.


=================(Build #3369  - Engineering Case #292656)=================

When updating numeric fields in an ADO recordset through ASAProv, several 
problems could have occurred.  The value could have failed to be updated 
at all, it could have been updated with the decimal point in the wrong 
place, or it could have been updated to a value completely different 
from the one specified in the update. These problems have been fixed.


=================(Build #3372  - Engineering Case #280167)=================

When updating variant array data through the ASA provider, the array 
data could have been omitted, have been updated with incorrect values 
or the update could have failed.  This could alsi have happened using 
ADO, if a Variant type was used to insert data into a field in a recordset. 
This problem is now fixed.




=================(Build #3373  - Engineering Case #279048)=================

Rowset data accessors were not always freed when the rowset was deleted.  
This would show up when using datareaders in VStudio.Net.  The ASA provider 
would leak memory each time the reader was opened and closed (usually 
about 80 bytes). This has been fixed.


=================(Build #3374  - Engineering Case #295225)=================

When fetching strings or blobs larger than 200 bytes through the ASA 
provider, the last byte would have been truncated if no data conversion 
took place. This has been fixed.




=================(Build #3376  - Engineering Case #294728)=================

Variable length output parameters returned from stored procedures were 
not always accessible to .Net applications, (ie C#, Visual Basic and 
Visual C Ver. 7), using ADO. This has been fixed.


=================(Build #3377  - Engineering Case #286173)=================

When viewing table data through the Visual Studio .Net Server Explorer, 
character data had an extra byte (usually a square box) appended to 
it. This has been fixed.


=================(Build #3382  - Engineering Case #270447)=================

Updating, inserting or deleting through an ADO client side cursor would 
have failed with the error: "Insufficient base table information for 
updating or refreshing". This is now fixed.


=================(Build #3382  - Engineering Case #298602)=================

Fetching the second row of a result set in an updateable cursor, where 
one of the columns had more than 200 bytes of data, would have resulted 
in an error. This has now been fixed.


=================(Build #3383  - Engineering Case #287854)=================

Using ADO and fetching backward through a cursor (using MovePrevious) 
until hitting the start of the result set (BOF) and then fetching forward 
(using MoveNext) would have incorrectly set EOF on the first MoveNext 
after hitting BOF. This is now fixed.


=================(Build #3388  - Engineering Case #300109)=================

Columns were always being reported as not nullable through the ASA provider. 
This was most noticeable when generating datasets in Visual Studio .NET.  
The AllowDBNull property would always be false, even if a column allowed 
nulls. This has been corrected.


=================(Build #3391  - Engineering Case #299664)=================

Using the ASA oledb provider to access a database from Powerbuilder 
would have failed as of versions 7.0.4.3382, 8.0.1.3062 and 8.0.2.4076. 
This was due to a problem introduced as part of the fix for issue 270447. 
This problem has now been corrected.


=================(Build #3394  - Engineering Case #302381)=================

It was possible that a client application, using the ASA provider, could 
have overwritten memory when updating or inserting a record in an ADO 
recordset or through the irowsetupdate or irowsetinsert interfaces. 
This has been fixed.


=================(Build #3400  - Engineering Case #303608)=================

This change fixes a number of provider problems when used with PowerBuilder.  
Note that a PowerBuilder problem still exists which causes an error 
dialog when creating catalog tables when connecting to a Database Profile 
from PowerBuilder for the first time.



The problems fixed include:

1. IDBInitialize::Initialize no longer requires the Data Source property 
(DBPROP_INIT_DATASOURCE).  Before this fix, all connection properties 
were ignored if there was no Data Source property and the OLE DB driver 
prompted for connection information.

2. IOpenRowset::OpenRowset was not correctly using passed in properties 
to determine cursor type & updatability.  This also affects ITableDefinition::CreateTable 
if ppRowset is not NULL.

3. IColumnInfo::GetColumnInfo now only includes bookmark column info 
if bookmarks are enabled on the rowset.

4. IRowsetUpdate::Update now allows non-NULL pcRows and NULL prgRows.  
This affects 8.0.0 and up only, since the 7.0.4 OLE DB provider did 
not give an error in this case.  (The Microsoft MSDN Documentation states 
that this is an error, but I expect that Microsoft OLE DB drivers actually 
allow this).


=================(Build #3406  - Engineering Case #302936)=================

It was possible that an application could have crashed, or failed to 
insert a row, when calling the rowset update function (or the AddNew 
and Update functions) in ADO. This has now been fixed.


=================(Build #3406  - Engineering Case #304698)=================

If the 8.0 ASAprov oledb provider was used to connect to a database 
running on an ASA 7.0 server or the codepage for the database character 
set was not installed, the connection will fail with the error:

"The system does not support conversion between Unicode and the requested 
character set, substituting the current ansi codepage".  

This is now treated as a warning instead of an error.


=================(Build #3408  - Engineering Case #296415)=================

Using client side cursors to fetch datetime values through the ASA oledb 
provider  (ASAProv), would have failed or returned #ERROR instead of 
the actual value.  This is now fixed, but a work around would be to 
use server side cursors.


=================(Build #3411  - Engineering Case #306023)=================

The ASAProv OLEDB provider could have failed when accessed by multiple 
threads concurrently, with failures more likely to have occurred on 
multi processor machines than single processor machines.  One instance 
of this failure was the error DB_E_BADTYPENAME(0x80040E30) from ICommandWithParameters::SetParameterInfo. 
This is now fixed.




=================(Build #3416  - Engineering Case #305107)=================

When the provider copied column values to its data buffer, a column 
could have been partially overwritten by a subsequent column, if an 
intervening column was the empty string. This has been fixed.


=================(Build #3417  - Engineering Case #308245)=================

When function IRowsetLocate::GetRowAt was called to fetch result set 
rows using bookmarks; for static and keyset cursors, ASAProv may have 
missed a row due to an invalid offset for some bookmark values. This 
is now fixed.




=================(Build #3419  - Engineering Case #306474)=================

If a blob column was updated using the ASA provider,(eg. through ADO 
cursors ), it could have crashed or updated the data incorrectly. This 
has been fixed.


=================(Build #3420  - Engineering Case #309628)=================

When fetching data via ASAProv from a database which used a multibyte 
collation, and charset conversion was requested, the returned length 
of the converted string was not set correctly.  This could have caused 
unintended behaviour in ADO applications. This is now fixed.


=================(Build #3423  - Engineering Case #310101)=================

Trying to disable OLE DB Connection Pooling by adding "OLE DB Services 
= -2" in the connection string of the ASA OLEDB provider, would have 
caused a "R6025 Pure Virtual Function Call" error, when a second query 
was executed. This has now been fixed.


=================(Build #3426  - Engineering Case #310866)=================

ASAProv was returning incorrect string values for database with a UTF8 
collation. The UFT8 string values were converted to the required string 
type(ie  DBTYPE_STR, DBTYPE_WSTR or DBTYPE_BSTR), but the null terminator 
was not being set. This is now fixed by null terminating the string.


=================(Build #3428  - Engineering Case #311234)=================

When connected to a database with a UTF8 collation,ASAProv converts 
from UTF8 to Unicode. This conversion may have used a wrong string length, 
which would have caused the run-time heap to have become corrupted. 
Also, the string buffer was not initialized before converting the UFT8 
strings. These problem lead to various failures using VS.Net, and have 
now been fixed.


=================(Build #3432  - Engineering Case #312905)=================

Fetching more that 200 characters, using the OLEDB provider, into a 
DBTYPE_BSTR could have left garbage data following the valid column 
data.  This has been fixed.


=================(Build #3432  - Engineering Case #312906)=================

The SQL generated by the ASA provider's ITableDefinition and IOpenRowset 
methods was not being correctly quoted.  These methods would have failed 
if the table name was specified as owner.name or if any object name 
was a keyword or not a valid identifier. For 7.0.4 only, if ITableDefinition 
or IAlterTable methods generated SQL that was over 255 characters, these 
methods could fail.  This has been fixed.




=================(Build #3433  - Engineering Case #313309)=================

Calling a stored procedure in Visual Basic .Net could have resulted 
in the error "syntax error or access violation: near '?' " This is now 
fixed.


=================(Build #3434  - Engineering Case #313708)=================

If the fetch of a row from a result set resulted in some sort of error 
(eg. conversion error), this error was suppressed by the provider and 
the rowset was marked as having no more rows.  Now the error is properly 
propogated back to the client.


=================(Build #3435  - Engineering Case #311280)=================

When querying the datatype of TIME, DATE, or TIMESTAMP columns of an 
ASA database, the ASA provider returned different values than Microsoft's 
provider, MSDASQL. This has now been corrected.


=================(Build #3438  - Engineering Case #314977)=================

The OLEDB provider had a number of problems when used it with a Borland 
Delphi built application:

- the provider could have overrun memory when fetching 200 bytes or 
less into a buffer smaller or the same size as the actual data, when 
fetching binary data into DBTYPE_VARIANT or any data into DBTYPE_STR 
or DBTYPE_BYTES.  This could have caused the application to crash as 
well as other problems.

- the provider could have  used an incorrect length when getting data 
from parameters of type DBTYPE_VARIANT containing DBTYPE_ARRAY.  This 
could have caused the wrong length of data to be used and possibly the 
application to crash.

- NULL binary input parameters may have resulted in E_OUTOFMEMORY 

- pessimistic locking was used when optimistic locking should have 
been used, resulting in reduced concurrency and possible application 
blocking.



These problems have now been fixed.  In 7.0.4 and 8.0.2, the locking 
type has not been changed since an 8.0.0 or higher engine is required 
and the change can cause the engine to choose a different cursor type.


=================(Build #3440  - Engineering Case #301502)=================

When an OLE DB schema rowset is opened to retrieve the parameter information, 
the ASA provider executes the stored procedure 'sa_oledb_procedure_parameters' 
which takes four parameters  'inProcedureCatalog', 'inProcedureSchema', 
'inProcedureName' and 'inParameterName'. If the 'inProcedureSchema' 
parameter was not specified by, (such as is done by Delphi applications), 
the default value of 'current user' was used. If this was not the same 
as the user that created the procedure, no records would have been returned. 
This is now fixed by changing the default value of 'inProcedureSchema' 
to the empty string ('').




=================(Build #3445  - Engineering Case #317126)=================

When using an OLE DB RowsetViewer with an OLE DB Tables schema rowset 
( or other schema rowsets ), without setting the TABLE_SCHEMA restriction 
(or other SCHEMA restrictions), the returned rowset only contained entries 
created by the current user, the other entries are missing. This has 
now been fixed.


=================(Build #3446  - Engineering Case #317604)=================

When an ADO recordset which returned multiple resultsets was opened, 
fetching the second resultset would have caused the application to crash. 
This problem, which has now been fixed, was introduced by the change 
for QTS 310101.


=================(Build #3463  - Engineering Case #320668)=================

When an OleDbDataReader was open on a connection to a Japanese database 
(Default collation=932JPN), string values were truncated when fetched. 
The length of the returned strings was taken as the number of characters, 
when it should be the number of bytes. This has now been corrected.


=================(Build #3472  - Engineering Case #323019)=================

When running a query with a prepared command, the ASA Provider created 
an internal rowset which was never freed, causing a memory leak. This 
was fixed by deleting the internal rowset when the owning command object 
is released.




=================(Build #3478  - Engineering Case #327019)=================

When an application using the OLEDB driver was connected to a database 
with the Turkish collation, (1254TRK), some calls to get metadata would 
have failed. This problem has now been fixed.




=================(Build #3478  - Engineering Case #327081)=================

The error 'Count field incorrect' could have occurred when executing 
an UPDATE statement command and setting a binary column to the value 
of a variable. This is nowfixed.


=================(Build #3484  - Engineering Case #323298)=================

THe ASA Provider held locks and kept cursors open after they were closed, 
if it was called from OLEDB.NET provider. The internal ODBC cursor is 
now closed when the OLEDB rowset is closed.


=================(Build #3494  - Engineering Case #326505)=================

A client application could have crashed when preparing and executing 
an oledb command object to open a rowset. This is now fixed.


=================(Build #3495  - Engineering Case #326619)=================

An application using the ASA provider was not able to get DBPROPSET_DATASOURCEINFO 
when using  DataLinks. This problem has been fixed.


=================(Build #3505  - Engineering Case #331652)=================

Output and variant type parameters were not supported by the OLEDB driver. 
The following C++ example contains both variant type parameters and 
output parameters.



class CInP1OutP2Accessor

{

public:

	CComVariant m_varP1;

	CComVariant m_varP2;



BEGIN_PARAM_MAP(CInP1OutP2Accessor)

	// SET_PARAM_TYPE( DBPARAMIO_INPUT ) // Default

	COLUMN_ENTRY_TYPE(1, DBTYPE_VARIANT, m_varP1)

	SET_PARAM_TYPE( DBPARAMIO_OUTPUT )

	COLUMN_ENTRY_TYPE(2, DBTYPE_VARIANT, m_varP2)

END_PARAM_MAP()

};



When variant type parameters were used, the OLEDB driver would have 
failed with an assertion error.  The OLEDB driver would not have returned 
the proper value for an output parameter. These problems have now been 
fixed.


=================(Build #3507  - Engineering Case #339903)=================

When calling a procedure with a output parameter bound as a NUMERIC 
or DECIMAL, 0 may have been returned to the application rather than 
its actual value. This problem would have manifested itself in the ODBC 
driver as well. This problem has been fixed.




                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **          Other           **                      
                      ******************************                      

=================(Build #2647  - Engineering Case #258493)=================

On Windows NT/2000 systems, when the uninstall modified the system path 
to remove Adaptive Server Anywhere entries, it changed the registry 
entry from type REG_EXPAND_SZ to type REG_SZ. If the path string contained 
environment variables, Windows did not substitute their values into 
the path. In particular, the %SYSTEMROOT% environment variable would 
not be substituted. As a result, command lookups could fail if the command 
was not fully qualified with path information. This would occur most 
frequently in MS DOS windows and when using Start/Run.

This fix will prevent this problem, but if an uninstall has already 
corrupted the path, it will need to be modified manually. To do this, 
modify the registry entry: 

	HKLM\System\CurrentControlSet\Control\Session Manager\Environment\Path

to change the data type from REG_SZ to REG_EXPAND_SZ. As an alternative, 
replace the environment variables in the system PATH with their values.
   to change the data type from REG_SZ to REG_EXPAND_SZ.


=================(Build #2648  - Engineering Case #257670)=================

Static SQL, in particular create and alter procedure/trigger statements,  
executed within an ESQL program could fail to compile if certain statements 
were included in the static sql statement.

For example, the following fails to compile using SQLPP
    EXEC SQL CREATE TRIGGER insTrigger AFTER INSERT ON Notification
        BEGIN
            DECLARE tblId INT;
            SELECT table_id into tblId FROM SYSTABLE;
            CALL insertKickProc(tblId);
        END;

The SQL is valid and will execute successfully in DBISQL.
The workaround, and suggested method of executing static SQL in an 
embedded SQL program is to use the EXECUTE statement.


=================(Build #2713  - Engineering Case #264475)=================

Installing 8.0.0 on a Win32 machine that already has 7.0.x installed 
and then uninstalling 7.0.x, will cause the 8.0.0 ASA Sybase Central 
Plugin Utilites to fail to run. This has been fixed for 7.0.4, but to 
prevent the problem in earlier versions, uninstall 7.0.x BEFORE installing 
8.0.0.  If the problem already exists, re-install 8.0.0 Sybase Central.



=================(Build #2722  - Engineering Case #261795)=================

We previously didn't support translation of Hong Kong Supplementary 
Character Set, (HKSCS), characters. Using a 950TWN database with server-side 
translation in effect or having MobiLink synchronising an 950TWN ASA 
remote database or Ultralite database would lose HKSCS characters. 

A new Unilib translation table, that support the HKSCS extensions, 
is now available. The file is installed under <ASA_install_location>\charsets\unicode\big5hk.uct. 
To put it to work, you need to overwrite your existing cp950.uct file 
with the new big5hk.uct file manually. Backing up the old cp950.uct 
file is recommended.

Note: Unilib and Microsoft picked different roundtrips on the following 
four arc drawing characters.
	MS 950/hkscs	Unilib cp950/big5hk
u5341	A2A5	F9E9
u5C22	A2A6	F9EA
u5345	A2A7	F9EB
u9F9C	A2A4	F9F9

Microsoft picked the code points in the Big5 special symbol area, but 
Unilib picked the code points in the Vender Defined Area. In the context 
of MobiLink synchronization, the remote database will always download 
the Unilib code points while the consolidate database will receive code 
points presented by the ODBC driver during the upload. If the ODBC driver 
is using Microsoft's converter (such as ASA's) then the consolidate 
database will get the Microsoft code points. MobiLink will not detect 
data change of this nature.




=================(Build #2731  - Engineering Case #266563)=================

MobiLink logging was writing data to the log in the machine's ANSI codepage.  
When an upload or download row value or script was inflated due to character 
translation, only part of the string was written to the log. This problem 
is now fixed. Note: this problem wouldn't have affected the actual synchronization.


=================(Build #2742  - Engineering Case #266847)=================

An application using the a_sync_db structure in dbtools.h would crash 
if DBSynnchronizeLog was called with verbose=1 and argv=NULL


=================(Build #3312  - Engineering Case #273466)=================

When using "dbunload -ar" to unload/reload a database, the error "syntax 
error near 'go'" could have been reported.The problem was related to 
parsing C-style(/* ... */)comments in stored procedures. It is now fixed.



=================(Build #3367  - Engineering Case #268612)=================

When dbisql was installed using an install created from the JavaTools 
template, it would then have failed to start, as some of the required 
classes were not installed. The template now includes the appropriate 
jar files.


=================(Build #3462  - Engineering Case #321541)=================

The messages installed for the Windows Performance Monitor for ASA Database, 
Server and Connection counters were in English only, even if a localized 
version of SAS was installed. This problem is now fixed.


=================(Build #3484  - Engineering Case #329001)=================

An embedded SQL application may have crashed with SIGBUS on 64-bit UNIX 
platforms or received the error  "SQL ERROR (-758) SQLDA data type invalid". 
The SQL preprocessor was generating the sqldabc field in the SQLDA structure 
incorrectly for 64-bit platforms. This has now been fixed. 



Workaround: use the flag -DLONG_IS_64BITS when compiling 64-bit  embedded 
SQL application.






                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **          Server          **                      
                      ******************************                      

=================(Build #1968  - Engineering Case #262856)=================

Foreign keys referencing a table are dropped when the primary table 
is dropped.  If there was a cursor open that used one of these foreign 
keys it was likely that the engine would crash. Fixed by closing all 
cursors that reference any foreign tables when we drop the primary table.


=================(Build #2607  - Engineering Case #242932)=================

Attempting to get the substring of a long varchar, where the result 
should be longer than 32767 bytes, would return only 32767 bytes. For 
example:

create variable txt long varchar;
set txt = repeat('abcdefghij', 12000);
select substr(txt,1001);
select length(substr(txt,1001));

The expected result should be 119000, not 32767.  

This problem also showed up when calling some system procedure, such 
as sp_helptext on  a stored procedure that was longer than 32767 bytes.


=================(Build #2624  - Engineering Case #256282)=================

If two connections executed a procedure simultaneously, the engine could 
report various errors, the most likely being assertion failure 200706. 
The problem would generally only show up on SMP machines.


=================(Build #2624  - Engineering Case #256627)=================

The "active requests" counter could return negative values if the server 
received many simultaneous requests. If an event was defined to activate 
when the server was idle, it might be run when other requests were still 
active or it might not run at all.



=================(Build #2626  - Engineering Case #257086)=================

Attempting to retrive a smalldatetime column via TDS, would have truncated 
the time portion. For example,
	select convert(smalldatetime, '2001-01-01 11:15')
returns 2001-01-01 00:00 with 7.0.1 and above, but would have returned 
the expected value 2001-01-01 11:15
previously. The problem has now been fixed.


=================(Build #2636  - Engineering Case #257385)=================

The system procedure, xp_stopmail, was not initializing the return value 
structure properly.



=================(Build #2636  - Engineering Case #257386)=================

When connecting over tcpip to a server running on Solaris 8 machines, 
started with the -z switch, the server would have crashed. This has 
been fixed.


=================(Build #2638  - Engineering Case #242043)=================

A complex nested query that contained a subquery that in turn contained 
an IN predicate that referenced an outer subselect would cause the server 
to loop during rewrite optimization, causing cache to grow until the 
error "Fatal error: memory exhausted". 
For example:

drop view vmember;
drop table gift;
drop table basic;

commit;

CREATE TABLE "basic"
(
 "id" integer NOT NULL,
 "added" date NOT NULL,
 PRIMARY KEY ("id")
)
;
commit;

CREATE TABLE "gift"
(
 "id" integer NOT NULL,
 "sequence" integer NOT NULL,
 "giftdate" date NOT NULL,
 "giftamount" numeric(10,2) NOT NULL,
 "ismembership" char(1) , 
 "membership_level_id" integer NULL,
 PRIMARY KEY ("id", "sequence")
)
;
commit;

create view  vmember as 
 select basic.id,
    0 as sequence,
    (select max(sequence) from gift where gift.id = basic.id and ismembership 
= 'Y' ) as lastseq,
    (select membership_level_id from gift where gift.id = basic.id 
and gift.sequence = lastseq) as lastlevel 
 from
    basic 
where
    lastseq is not null
;
commit;

and the failing query is

select id
from basic
where exists (select id from vmember where vmember.id = basic.id and 
vmember.lastlevel in (4))


=================(Build #2639  - Engineering Case #256742)=================

The datediff() function would not work in a CHECK constraint. For example, 
the following statement would give the error 'Column 'hour' not found':

CREATE TABLE date_diff_test(
	col1 int primary key,
	start_time timestamp not null,
	end_time timestamp not null,
	CHECK(datediff( hour, start_time, end_time ) < 2)


=================(Build #2640  - Engineering Case #240922)=================

The definition for the following function would be stored in SYSPROCEDURE 
as a procedure, rather than as a function. The function would behave 
correctly until the database was unloaded and rebuilt, at which point 
it would no longer be recognized as a function. 

CREATE function _t (@Z varchar(10))
returns VARCHAR(40)
BEGIN
   SELECT @Z='A';
   RETURN(@Z);
END

This function now causes a syntax error, since it attempts to mix Watcom-SQL 
and Transact-SQL dialects. Functions must be defined using the Watcom-SQL 
dialect.


=================(Build #2640  - Engineering Case #256764)=================

Attempting to create a foreign key reference between numeric and decimal 
columns would have caused an error.
For example:
	CREATE TABLE pt( c1 numeric(10) primary key);
	CREATE TABLE ft( c1 decimal(10) references pt);

This worked in 5.5.x but in versions 6.0.x and later, it would have 
given the error:
	Column 'c1' in foreign key has a different definition than primary 
key



=================(Build #2640  - Engineering Case #258119)=================

The database engine would GPF if you tried to create a foreign key relationship 
with referential integrity actions and the SYSTRIGGER table was full.


=================(Build #2640  - Engineering Case #258287)=================

If the following sequence was executed:
	create procedure A
	drop procedure A
	checkpoint
	create procedure B
	call B(...)    // replicated
the procedure id used for B would be that used for A plus 1. If the 
server was forced to recover from the checkpoint, it would assign the 
same id to B as had been used for A. The id recorded in the transaction 
log for the replicated CALL would not match, causing recovery to fail. 
The id's are now assigned so as to be consistent with the values used 
during recovery.


=================(Build #2647  - Engineering Case #257318)=================

Calling the system procedure sa_locks, could have crashed the server. 
The crash would only occur if one or more of the connections were using 
keyset cursors or a MobiLink connection had called sa_start_recording_commits.


=================(Build #2647  - Engineering Case #258440)=================

If a user accidentally prepares a procedure call specifying a host variable 
argument twice, the engine will crash if an attempt is made to describe 
the INPUT variables for the procedure.


=================(Build #2650  - Engineering Case #255785)=================

Timestamps that were used to detect committed updated rows were not 
being purged.  This would have  lead to spurious dbmlsync synchronization 
failures, that would have appeared to go away when the remote server 
was restarted.


=================(Build #2651  - Engineering Case #241001)=================

Setting a breakpoint inside a procedure with a Polish name would cause 
the debugger to display an exception dialog when the breakpoint was 
reached. The exception was: 	java.io.UTFDataFormatException



=================(Build #2658  - Engineering Case #256870)=================

The server could crash on Win95/98/ME.  This has been fixed.


=================(Build #2658  - Engineering Case #257317)=================

If an event accessed a remote table, then the connection to the remote 
server wopuld have remained open even after the event completed. This 
connection now gets dropped at the end of the event.



=================(Build #2658  - Engineering Case #259258)=================

If a DBA user was attempting to connect again as another user, and the 
connection was dropped at exactly the same time, (because of idle timeout, 
liveness, a network error, or with DROP CONNECTION), the server could 
have crashed. This has now been fixed.


=================(Build #2658  - Engineering Case #259382)=================

For queries containing large star joins, the optimizer may have either 
aggressively pruned valid strategies, when it was unnecessary, or not 
pruned aggressively enough, resulting in extended optimization times, 
(and hence an extended elapsed time).



=================(Build #2659  - Engineering Case #258728)=================

If a UNION query requiring multiple servers had a subquery in it, then 
there was a very good chance that the
query wwould have failed with a table or column not found error. An 
example is as follows:

     SELECT 'a' FROM remote_table, local_table WHERE local_table.c1 
IN
        ( SELECT remote_table.c1_r FROM remote_table)
UNION
    SELECT 'b' FROM any_table

The above query requires two servers, the local server, (local_table, 
any_table) and one remote server, (remote_table). Now, because of the 
subquery in the first select, the above query should be executed in 
no passthrough mode, but would have been executed in partial passthrough 
mode instead, causing the query to fail.


=================(Build #2659  - Engineering Case #259460)=================

The OS field of the AppInfo property contained "Windows 2001" when the 
client was running on Windows XP. It now contains "Windows XP".



=================(Build #2668  - Engineering Case #239652)=================

When a stored procedure is created which has a result set but no result 
set clause is specified in the procedure definition, the engine will 
dynamically build one.  However, if the engine crashes before the next 
checkpoint, when it recovers the procedure creation the result set is 
not rebuilt.


=================(Build #2675  - Engineering Case #260832)=================

If a procedure contained a RAISERROR statement with no format string 
in the statement, or in SYSUSERMESSAGES, and the ON_TSQL_ERROR option 
was set to 'STOP', the statement would not halt execution of the procedure. 
This has been fixed, but a workaround would be to create an empty string 
for the error number with CREATE MESSAGE.



=================(Build #2676  - Engineering Case #257859)=================

Creating a view and then removing a column from the underlying table 
that the view was based on would cause the engine to crash when the 
view was selected from.


=================(Build #2681  - Engineering Case #256551)=================

Attempting to prepare or execute immediate a tds dynamic statement, 
with an existing statement name, would have  crashed the server. When 
preparing or executing immediate a tds dynamic statement, a new unique 
statement name must always be used; hence, an error will now be generated 
in this case.


=================(Build #2682  - Engineering Case #259949)=================

If the BCPIN utility was used on a proxy table, the server would have 
crashed. Like LOAD TABLE, BCPIN is not allowed on a proxy table. Using 
BCPIN on a proxy table will now result in an error message.


=================(Build #2682  - Engineering Case #260578)=================

The error "Fatal Error: Disk Full" could be displayed when disk space 
was still available.  A failed operating system write function call 
was being interpreted as a disk full error.  In this particular situation 
the cause for the write failure is unknown.  The problem only occured 
on Windows 2000 and only after the operating system issued a 'low virtual 
memory' warning to the desktop.  The operating system has not set an 
error state it only informs the server that the entire write did not 
succeed.  The server will now display the message 'Disk write failure 
- transactin rolled back'.


=================(Build #2683  - Engineering Case #259014)=================

The server could have crashed when creating a foreign key that referenced 
a global temporary table. This would only happen if the foreign key 
referenced a unique constraint, rather than a primary key.


=================(Build #2686  - Engineering Case #261473)=================

When dbmlsync was connected to a database with a user id with only remote 
dba authority, calls to sp_hook_dbmlsync_com_error or sp_hook_dbmlsync_fatal_sql_error 
would have failed.  When the failure occured the following message was 
written to the dbmlsync log:

SQL statement failed: (-121) Permission denied: you do not have permission 
to execute the procedure "sp_hook_dbmlsync_download_fatal_sql_error"

This has been fixed.


=================(Build #2686  - Engineering Case #261812)=================

When a stored procedure is created which contains a cursor declared 
with the FOR UPDATE clause, this clause is not preserved when rebuilding 
the database.  This can cause problems if the cursor is not updateable 
by default (see the ansi_update_constraints option for details)


=================(Build #2687  - Engineering Case #260073)=================

A statement like:
	set identity_insert owner.table on
inside a stored procedure would fail when the procedure was executed. 
The statement in the procedure definition stored in the catalog did 
not include the table name or its owner.


=================(Build #2688  - Engineering Case #259123)=================

A query containing IN conjuncts inside a GROUP BY clause may return 
a syntax error or incorrect result set.

An example:

....
GROUP BY   
  T.X,
 case
  when T.Y   IN( 102,132,253,254 ) then 1
  when T.Y  IN( 300,301,302,303,304,305 ) then 3
  when T.Y > 399 then 4 else 5
  end


=================(Build #2688  - Engineering Case #261633)=================

If a scheduled event attempted to run while the database was still starting, 
it would not be re-scheduled and would not run again. This would be 
more likely to happen for events scheduled to run very frequently (e.g. 
every second).



=================(Build #2688  - Engineering Case #261923)=================

If an Adaptive Server Anywhere server running on NetWare dropped an 
SPX connection due to a liveness timeout, it would hang when shutting 
down the database to which the connection was made. This has now been 
fixed.


=================(Build #2689  - Engineering Case #262122)=================

If an event handler was executing when another connection attempted 
an operation which required exclusive access to the database (e.g. ALTER 
DBSPACE, call sa_table_page_usage() ), the server would crash when attempting 
to report an error.




=================(Build #2689  - Engineering Case #262221)=================

The Java VM could cause the server to crash when in low memory situations.


=================(Build #2694  - Engineering Case #261652)=================

Executing the following statements would result in "correlation name 
'stations' not found":

create table foo (
	col1 int,
	col2 char(1) compute (ascii(col1))
);
delete foo from foo  A where col2 = 'a';

Executing the DELETE with a single table expression would not cause 
the error.


=================(Build #2694  - Engineering Case #262558)=================

If the Wait_for_commit option was set to ON and an attempt was made 
to create a foreign key for which there were missing primary key values, 
the creation of the foreign key was not properly prevented. The catalog 
entries for the foreign key would be created, and a subsequent attempt 
to delete the foreign key would crash.



=================(Build #2696  - Engineering Case #261212)=================

After a while, a server running on Windows 2000 may stop accepting TCP 
connections. Windows 2000 seems to generate an ERROR_NETNAME_DELETED 
error now and again when it doesn't make sense, (i.e. in the AcceptEx 
function). We now ignore that error message.


=================(Build #2696  - Engineering Case #262707)=================

An aliased CAST or CONVERT expression could crash server. For example:
	SELECT 
	    CAST((NULL) as char(10)) as c1,   
	    CAST((NULL) as char(6)) as c2,   
	    1 as c3
	FROM DUMMY
	GROUP BY c1,c2,c3

This problem was introduced 2001/10/16 as part of a fix for issue 259123 
and has now been fixed.


=================(Build #2696  - Engineering Case #262789)=================

A statement like:
	SELECT @var = 1 WHERE @@error = 0
would be treated as if the WHERE clause was not present. If contained 
within a stored procedure, the WHERE clause would not appear in the 
procedure definition stored in SYSPROCEDURE.

Use of this type of conditional assignment statement is not recommended. 
Instead, use an IF statement to control the assignment. This will perform 
better, be more readable, and is the more commonly-accepted practice.


=================(Build #2700  - Engineering Case #258910)=================

A nested outer join query containing at least one derived table or view 
that involved aggregation, DISTINCT, or UNION could result in the error 
"cannot optimize query", SQLCODE -727 and SQLSTATE WI010.



=================(Build #2701  - Engineering Case #263124)=================

Using BCP IN to load data into a table would usually have caused a server 
hang. This problem has now been fixed.


=================(Build #2703  - Engineering Case #262499)=================

If an "if exists" on a proxy table failed, (i.e. the exists query yielded 
no rows), then the server would give an error "cannot handle expressions 
involving remote tables inside stored procedures" and then fail to execute 
the rest of the stored procedure.


=================(Build #2707  - Engineering Case #262673)=================

A single server should run up to 255 databases, but attempting to start 
the 201st database would result in the error "Unable to start specified 
database". This has now beed fixed.


=================(Build #2707  - Engineering Case #263507)=================

When creating a foreign key, if the list of referencing columns was 
null, the list of referenced columns was ignored. The foreign key would 
then have been defined to reference the primary key.
For example, given the following table definitions
:
create table ptab (
	k1c1 int,
	 k1c2 int,
	 k3 int unique,
           primary key (k1c1, k1c2) );
         
create table ftab(
	k1c1 int,
	k1c2 int,
	k3 int,
	foreign key FK1 references ptab,
	foreign key FK2 references ptab (k3) );
         
both FK1 and FK2 would reference the primary key of ptab, but FK2 should 
reference ptab.k3. In fact, the list of referenced columns for FK2 could 
include non-existent columns or the wrong number of columns. None of 
these problems exists if a list of referencing columns was supplied, 
as in:
	// . . .
	foreign key FK2 (k3) references ptab (k3) );
Now, if there are no referencing columns, a list equal to the referenced 
columns is used.



=================(Build #2707  - Engineering Case #264126)=================

When attempting to get a connection property for a connection which 
had just disconnected, the server could have crashed.  This could show 
up when dbconsol or Sybase Central's All Connected Users was used to 
display the current connections while a connection was disconnected.  
The crash was more likely when the server was running on a multi-processor 
machine.  The server now no longer crashes.



=================(Build #2709  - Engineering Case #254825)=================

The database file could have grown extremely large during the recovery 
phase of startup.  If there was insufficient disk space available a 
disk full error would have been generated.


=================(Build #2714  - Engineering Case #264473)=================

Queries that involved host variables may have taken longer to optimize 
and resulted in less efficient  plans, than queries using constants.


=================(Build #2716  - Engineering Case #231751)=================

Attempting to execute a query like:
	select * from employee where (emp_id=1234,'1234')
where employee is a local table results in an "Illegal user selectivity 
estimate specified" warning; however,
executing the same query when employee is a remote table would end 
up crashing the engine. You
now get the same warning but the query will NOT be executed.


=================(Build #2717  - Engineering Case #256621)=================

If the STRING_RTRUNCATION option was 'ON' and an alter table statement 
was executed resulting in right truncation of column data then the engine 
could generate 'Assertion 200601' or a 'Fatal Error: Unknown Device 
Error'.


=================(Build #2717  - Engineering Case #265342)=================

When server-side translation was used and the translated string was 
inflated in size, the server was truncating the translated string to 
the original size before sending it to the application and no truncation 
warning was issued. The problem is now fixed. The engine will now send 
the entire translated string, as long as the bound buffer is big enough.

Note 1: The truncation warning remains incorrect in the following way:

Let 	b :	bound buffer size 
	t :	translated string length 
	p:	pre-translated string length
	send_len 	: min( b, t )
	true_len 	: p	// for the case without blank padding

For the inflation case where we expect a truncation warning, that is 
p < t and b < t, the server is behaving as followings:

1. When b < p < t
	=> send_len = b, true_len = p
	=> Truncation warning issued with indicator set to p.
2. When b = p < t
	=> send_len = b = p = true_len
	=> No truncation warning
3. When p < b < t
	=> send_len = b, true_len = p
	=> No truncation warning

In all the above cases, the correct behavior is to send truncation 
warning with indicator set to t. 

For the deflation case where we expect a truncation warning, that is 
b < t < p, the engine is behaving in the following way
When b < t < p
	=> send_len = b, true_len = p
	=> Truncation warning issued with indicator set to p

In this case, the correct behavior is to send truncation warning with 
indicator set to t.

Note 2: Currently the engine does not decribe column sizes correctly, 
when inflation/deflation occurs during translation.


=================(Build #2717  - Engineering Case #265465)=================

When server-side translation was used, if the string was inflated or 
deflated in size by the translation, the engine either give a truncation 
warning, with an incorrect length indicator, or didn't give a warning 
when it should have.

The truncation warning was incorrect in the following way:

Let 	b :	bound buffer size 
	t :	translated string length 
	p:	pre-translated string length
	send_len 	: min( b, t )
	true_len 	: p	// for the case without blank padding

For the inflation case, where we expect a truncation warning, that 
is p < t and b < t, the engine was behaving in the following ways:

1. When b < p < t
	=> send_len = b, true_len = p
	=> Truncation warning issued with indicator set to p.
2. When b = p < t
	=> send_len = b = p = true_len
	=> No truncation warning
3. When p < b < t
	=> send_len = b, true_len = p
	=> No truncation warning

In all the above cases, the correct behavior was to send truncation 
warnings with indicator set to t. 

For the deflation case where we expect a truncation warning, that is 
b < t < p, the engine was behaving in the following way
When b < t < p
	=> send_len = b, true_len = p
	=> Truncation warning issued with indicator set to p

In this case, the correct behavior was to send a truncation warning 
with indicator set to t.

This change fixes the above problems.


=================(Build #2721  - Engineering Case #263487)=================

An external function that had parameters defined with unsupported data 
types, (e.g. VARCHAR), may have caused the server to crash. This has 
now been fixed.


=================(Build #2722  - Engineering Case #264438)=================

A client connection could hang if a prefetch deadlock error occurred.  
If the connection was hung due to this problem, Sybase Central's All 
Connected Users folder would have reported the current request as "CURSOR_USE_PREFETCH" 
or "ROW_DESCRIPTOR".  A prefetch deadlock occurs when a prefetch request, 
(used to improve fetch performance), receives a deadlock error.  The 
next request after the prefetch should receive the error "Rollback occurred 
due to deadlock during prefetch" (-684) when this occurs and this error 
indicates that the current transaction has already been rolled back.  
The hang has been fixed.


=================(Build #2722  - Engineering Case #265770)=================

The server could have hung when dbunload -a was run.  The hang was more 
likely on multiprocessor machines.



=================(Build #2723  - Engineering Case #265783)=================

In some cases, the "Rollback occurred due to deadlock during prefetch" 
error was not returned when it should have been.  If this occurred, 
a rollback has implicitly been done without the client application ever 
receiving any indication of the rollback.  Now this error is always 
generated on the next request after a deadlock occurs during a prefetch. 
Before this fix, the request which receives the "Rollback occurred due 
to deadlock during prefetch" may or may not have been executed.  Now 
if a request receives this error, it was not executed.  The only exception 
to this is closing a cursor, where the cursor has been closed even if 
the close cursor request receives the "Rollback occurred due to deadlock 
during prefetch" error. It was possible for the DBLib function db_start_database, 
db_stop_database and db_stop_engine get a communication error if the 
previous request on the connection was a fetch with prefetch enabled.  
Now these functions no longer hang.



=================(Build #2727  - Engineering Case #265441)=================

The following script would result in the wrong procedure being called. 
The problem would exist only temporarily, either until the database 
was restarted or until the procedure owned by userA was called using 
a qualified procedure name (i.e. userA.proc1()).

message user to client;           -- expect DBA
grant connect to userA identified by pwdA;
grant connect to group1 identified by pwd1;
grant group to group1;
grant membership in group group1 to UserA;
grant DBA,resource to group1;
grant DBA,resource to userA;

setuser group1;

create procedure proc1()
begin
	message 'This is the proc owned by group1' to client;
end;

setuser;
setuser UserA;

create procedure userA.proc1()
begin
	message 'This is the proc owned by userA' to client;
end;

call proc1();      		--- group1 proc would be called (incorrect)
call userA.proc1(); 	--- userA proc would be called
call proc1();     		--- userA proc would be called


=================(Build #2727  - Engineering Case #265937)=================

Executing an ALTER TABLE statement that renamed and modified a column, 
did not perform all the actions. For example, the following statement 
gave no error, but did not add the check constraint:
alter table product
	rename quantity to stock_quantity,
	modify stock_quantity check( stock_quantity >= 0 )
The statement will now result in an "ALTER clause conflict" error. 
The requested changes should be executed as two separate ALTER TABLE 
statements.



=================(Build #2730  - Engineering Case #266093)=================

Assertion 101104, "Unexpected error occurred while fetching from a temporary 
table" could have occurred on the first fetch from a cursor that used 
a temporary table for sorting or duplicate elimination, if there were 
concurrent deletes which deleted the first row of the cursor. This situation 
would be more likely to occur on SMP machines.



=================(Build #2730  - Engineering Case #266471)=================

By default, the ASA server for NetWare can only accept a maximum of 
108 connections. The "connections" TCP parameter can be used to change 
this limit. Once the server reached this limit, the next connection 
attempt would have caused an abend.


=================(Build #2734  - Engineering Case #259169)=================

If a stored procedure opened a cursor on another stored procedure and 
then returned a result set, the result set
returned was incorrect. Consider the following example:

create procedure main()
begin
    declare tid int;
    declare tname char(128);
    declare err_notfound exception for sqlstate value '02000';
    declare curs cursor for call sub();
    declare local temporary table outtab( t_id int, t_name char(128) 
) on commit preserve rows;
    
    open curs with hold;
  fetchloop: loop
    fetch next curs into tid, tname;
    if sqlstate = err_notfound then
      leave fetchloop
    end if;
    insert into outtab values(tid, tname);
    commit work;
  end loop fetchloop;
  close curs;
  
  select * from outtab;
end
;

create procedure sub()
begin
    select table_id, table_name from systable;
end
;

When the procedure main() was executed from dbisqlc (i.e. a non-TDS 
app), the result set returned had column headings t_id and t_name and 
there were several rows in the result set as expected. When the procedure 
main() was executed from dbisql (i.e. a TDS app) then the result set 
had column headings table_id, table_name and there were no rows in the 
result set. This problem has now been fixed.



=================(Build #2735  - Engineering Case #266725)=================

A valid authentication signature may sometimes not have worked or in 
some cases caused a server hang.
This problem has now been fixed.


=================(Build #2736  - Engineering Case #265722)=================

The -sb command line parameter on the server did not work on Unix platforms.  
The usage text was always displayed.  This parameter now works as expected.



=================(Build #2737  - Engineering Case #259188)=================

For complex queries with an ORDER BY clause, an opportunity to avoid 
a sort may be  missed, due to the fact that the table referenced in 
the ORDER BY clause may never be considered as the first table in an 
access plan. Choosing  the first table in  the enumerated access plans 
is based on heuristics, involving table sizes, number of join conjuncts 
referencing a table,  etc.  With this change, the table referenced in 
the ORDER BY clause will be always  considered for the first position 
of an access plan,  making it more likely to find a  best plan for which 
a sort is not required.
This new feature may improve a query execution time if:
(1) the query has a high join degree for which the optimizer governor 
is more likely to quit before  enumerating  all the possible access 
plans;
(2) the query has  an ORDER BY clause  referencing only one table.


=================(Build #2737  - Engineering Case #265461)=================

Disconnecting all client connections simultaneously from an autostarted 
database could cause the server to go to 100% CPU usage, while refusing 
any new client connections.


=================(Build #2737  - Engineering Case #265831)=================

The engine could hang while building indexes.  No other users would 
be able to connect and the engine would need to be restarted.



=================(Build #2740  - Engineering Case #266550)=================

Given the following table definintion:

	create table test (d decimal(15,2), i integer )

the following statement:

	insert into test(d, i) values (3.4365265432643E+141, 4)

would have caused the server to insert an invalid value into the table, 
instead of raising a conversion error. The inserted rows with invalid 
values can be detected by executing the following statement:

	select * from test where cast( d to long varchar ) = '?'

The problem only took place when the value being inserted wa larger 
than the largest decimal value that can be stored in the database. The 
server will now correctly raise a conversion error.



=================(Build #2740  - Engineering Case #267461)=================

If a procedure was created for another user, (eg. dba creating a procedure 
for dbo), and it contained "create table" and "drop table" statements 
that did not have qualified table owners, assertion 100904 could have 
occurred when trying to apply a log containing calls to the procedure.


=================(Build #2742  - Engineering Case #260711)=================

If a script file, (such as custmap.sql), did not end with a CR, then 
the last set of statements in the file would not
have been executed. This problem has now been fixed.



=================(Build #2743  - Engineering Case #265341)=================

Under some circumstances, it is possible that an application that either
- positions to the beginning of the cursor, and then attempts to scroll 
forward again or
- positions to the end of the cursor, and then attempts to scroll backward

would, (incorrectly), get a "row not found" error (SQLCODE 100). This 
error can only occur if a table is being accessed through an index that 
has at least two columns, and the query contains at least two matching 
predicates (with equality conditions) that are utilized for indexed 
retrieval via that index. The problem is much more likely to occur if 
the first table in the access plan is accessed via such an index. This 
is a follow up issue to QTS 267049.


=================(Build #2743  - Engineering Case #267528)=================

If an attempt was made to insert into a cursor and get back the resulting 
row, (eg. to get the value of an autoincrement column), it could have 
crashed the server if the select statement on which the cursor was based 
referenced multiple tables in the FROM and WHERE clauses.



=================(Build #2744  - Engineering Case #266395)=================

The query optimizer's index selection algorithm may have failed to choose 
the best index. This change may improve query execution time if:
1 - there is at least one base table for which there are at least two 
equality or inequality predicates on the same index column; or
2 - the join predicates have selectivities set to default 5%, due to 
lack of column statistics.

The index selection algorithm may not have chosen the best index for 
a base table if more than one predicate referenced the same index column. 
Now, the optimizer will choose the best matching predicate among the 
ones available. 

Also, if column statistics were missing, the join selectivity for a 
predicate of the form "T.column1 = R.column2" was always set to 5%.  
A better estimate is now set for this type of predicate.


=================(Build #2745  - Engineering Case #268160)=================

Using the tcpip parameter, broadcast=255.255.255.255, would have given 
an "invalid IP address" error and no broadcast would have been done, 
althoughthe tcpip link would have started.  Now this IP address is allowed 
with the broadcast parameter.


=================(Build #2748  - Engineering Case #268264)=================

When a table was dropped or altered, the server would have closed all 
open cursors that referred to that table. The server could have crashed 
if one of the open cursors being closed was in the same connection as 
the one dropping or altering the table. The following example illustrates 
the problem:

	create table T(x int);
	insert into "T" values (1);
	commit;

	create function F(x int) returns int
	 begin
         		drop table T;
          		return x;
       	end;
	
	SELECT F(x) from T

The server will now disallow the execution of  "drop table T" in F() 
with a "table in use" error.



=================(Build #2749  - Engineering Case #266739)=================

Public database options could have been dropped, even though a user 
option still existed. Now, the same error is displayed as would be  
if an attempt was made to add a user option, when no public option exists 
:

"ASA error -200: Invalid option 'the new option'-- no PUBLIC setting 
exists"


=================(Build #2749  - Engineering Case #268413)=================

If a TCPIP or SPX connection was forcibly shut down, (eg. the server 
is stopped, DROP CONNECTION, etc.), the client application could have 
crashed. Such apps will now return a communication error.



=================(Build #2750  - Engineering Case #268088)=================

The server may have crashed while executing a query, if the query contained 
operations on numeric data of varying lengths. This has now been fixed.


=================(Build #2750  - Engineering Case #268641)=================

The server was ignoring the settings for the database options ALLOW_SYNC_PKEY_UPDATE 
and ALLOW_REPLICATION_PKEY_UPDATE, assuming the value for both options 
to be 'ON'. The server now takes the settings for these options into 
account when determining the elligibility of updates. Also, the default 
value for the option ALLOW_SYNC_PKEY_UPDATE has been changed from 'off' 
to 'on'. The default value for ALLOW_REPLICATION_PKEY_UPDATE was already 
'on'.


=================(Build #2751  - Engineering Case #268693)=================

UNIX shared memory connections would have failed if the name of the 
server was greater than 31 characters. This problem has been fixed by 
truncating all server names to 31 characters in length.



=================(Build #2753  - Engineering Case #268925)=================

The server could have crashed if a shared memory connection disconnected 
abnormally, (for example, by "drop connection").  Also, the personal 
server could have crashed if about 100 shared memory attempts to connect 
to the engine failed before a database connection was attempted, (for 
example, the client application process was killed during a connection 
attempt).  The server will no longer crash.


=================(Build #2756  - Engineering Case #267720)=================

Clients without the fix for issue # 241854 would hang when attempting 
to connect with an invalid user id or password to servers with the fix.  
The fix for issue # 241854 was made to the EBF versions, 7.0.2.1510, 
7.0.3.2048 and the release version 8.0.0.   For example, clients with 
the original 7.0.2 or 7.0.3 maintenance releases would hang if an incorrect 
password was specified and the server was a current 7.0.2 or 7.0.3 EBF. 
This server fix now allows older clients to be used with newer servers 
without hanging on invalid user ids or passwords.



=================(Build #2758  - Engineering Case #267640)=================

If an exception handler in a stored procedure or trigger was executed 
many times within a single request to the server, it would consume memory, 
although the memory would be freed on the next request made by that 
connection.. This might happen in a procedure that is called repeatedly 
from another procedure, or within a trigger that is called many times 
during a mass insert, update or delete. The result could be a "dynamic 
memory exhausted" or "procedures or triggers nested too deeply" error. 
This has now been fixed.


=================(Build #2758  - Engineering Case #269437)=================

The BACKUP DATABASE statement checks if there is enough free space in 
the specified path before doing the backup. To get the path name from 
a fully qualified file name, it was using the strrchr C function to 
search for the delimiter between file name and path name. On Windows, 
the delimiter is '\', (or 0x5c hex), so when a multi-byte character 
file name contained a character which had 0x5c as the second byte, strrchr 
would point to that byte, instead of the real delimiter. This problem 
has been fixed.


=================(Build #2766  - Engineering Case #267530)=================

If  LOAD TABLE was used with a data file that did not end with a newline 
character, the last row loaded into the table  could have contained 
invalid data. This has been fixed.


=================(Build #2766  - Engineering Case #268787)=================

Nested queries containing one or more IN-lists, (or disjunctive equality 
conditions), referencing a column could have returned wrong results. 
For this to occur, the nested query must have been "flattened" into 
a join requiring duplicate rows to be eliminated, and the optimizer 
must have chosen a plan that did not require a temporary table. This 
has now been fixed.



=================(Build #2774  - Engineering Case #269694)=================

A corrupted database could result from using LOAD TABLE with a data 
file containing invalid data.  Most likely the invalid data would be 
for a DATE, DATETIME or TIMESTAMP column.  The column definition would 
also need to be NOT NULL and the CONVERSION_ERROR option would need 
to be set to 'OFF' for this problem to occur.  When inserting invalid 
data into a column the engine converts the data to NULL.  If the column 
does not allow NULL then an error "Column 'x' in table 'y' cannot be 
NULL" will now be generated.



=================(Build #2775  - Engineering Case #270626)=================

If an external function, (or a set of external functions), was called 
many many times using the new external
function interface, and the external function was incorrectly declared, 
then there was a chance that the server would have crashed with a stack 
fault. This problem has been worked around within the server.



=================(Build #2776  - Engineering Case #270742)=================

If the total length of an error message exceeded 60 bytes, the characters 
after the 60th byte may have been garbled. The message will now be truncated 
at 120 characters.


=================(Build #2780  - Engineering Case #267538)=================

The HEXTOINT function could give an error when it should have been successful.
HEXTOINT('0x80000000') gives Error: "Value 0x80000000 out of range 
of destination."
The correct value  -2147483648 is now returned.


=================(Build #2780  - Engineering Case #268433)=================

A query containing nested derived tables on proxy tables, could have 
caused a server crash. This problem has now been fixed.


=================(Build #2780  - Engineering Case #270675)=================

Modifying a foreign key in a combined index could have resulted in an 
engine crash, (or incorrect results, if another connection was doing 
an isolation level 3 scan on the associated primary index.) This was 
unlikely to be observed in practice, as for this to occur, a foreign 
key that had no matching primary key must have been inserted or deleted 
and the key value must have been after the last primary key value.  
A crash would have occurred only if the foreign index page was physically 
the last page in the cache.


=================(Build #2781  - Engineering Case #269436)=================

Offsets in embedded SQL Getdata requests were interpreted incorrectly 
by the server. This was a consequence of  the  incorrect recalculation 
of getdata offsets, when string expansion/contraction occurred, due 
to server-side character translation. This problem has been fixed.


=================(Build #2785  - Engineering Case #270467)=================

When multiple sargable predicates were defined for the same table column, 
and only one of these was used as a matching predicate for an index 
scan, the best access plan found may be less than optimal, due to an 
underestimated number of rows expected. 

Example:
The table T has an index on <T.X, T.Y> which is chosen in the best 
plan.  The column T.X  is referenced by  two sargable predicates, "T.X 
= R.X" and "T.X = 20".   
select * from T, R, S
where T.X =R.X and T.X = 20 and T.Y > 10 and R.Z = S.Z


=================(Build #2786  - Engineering Case #271069)=================

Creating a view that included a date/time/timestamp column, using a 
TDS connection, (like dbisql), would have defined the view column for 
that date/time/timestamp column as a char datatype instead of the appropriate 
date/time/timestamp datatype. This problem has now been fixed.


=================(Build #2786  - Engineering Case #271079)=================

Calling the system procedure, sa_locks, could have deadlocked the server, 
causing it to appear hung.  For the deadlock to have happened, a checkpoint, 
(or some ddl statement), and some other activity that required locks 
to be obtained, must have occurred concurrently. This is now fixed.


=================(Build #2786  - Engineering Case #271401)=================

Creating a primary or unique constraint index in a 6.x or earlier database 
could have failed with a variety of assertions or even crashed the server, 
possibly leaving the index corrupt.  This problem was more likely to 
show up on large fully hashed indexes. It has now been fixed.


=================(Build #2786  - Engineering Case #271640)=================

Calling a procedure from the select list, using a TDS connection, that 
executed a print statement and then subsequently returned a value without 
returning a result set, would have caused a server crash.
For example:

	create procedure junk()
	begin
	    print 'a test message';
	    return 1;
	end

If SELECT junk() was executed using dbisqlc, all would have been well, 
but executing the same select using dbisql would have crashed the server. 
This problem has now been fixed.


=================(Build #2786  - Engineering Case #271867)=================

This change fixes the following problems:
1 - Attempting to connect to a server over SPX, with a server name 
greater than 26 bytes, could have caused Windows clients to crash or 
fail to connect.
2 - The Network Server for Windows would not have detected that a server 
with the same name was running over SPX using the bindery.


=================(Build #2789  - Engineering Case #272774)=================

If a CREATE VARIABLE statement was executed inside a stored procedure 
and the variable being created already existed, an error was not reported. 
A new variable was created, hiding the previous instance. This has been 
fixed, an error is now reported.



=================(Build #2789  - Engineering Case #272995)=================

The server could have stopped responding to new connections, (existing 
connections still worked). if it received a TCP error on the listener 
socket. The server message log would have shown an error similar to: 
"TCP/IP link, error on TCP listener, rc=4, er=X, s=... ", where X is 
the integer value of EWOULDBLOCK on that platform. This is now fixed.



=================(Build #2789  - Engineering Case #273199)=================

Servers running on AIX, could have used all available file descriptors, 
causing the O/S to run out. This has been fixed.


=================(Build #2789  - Engineering Case #273301)=================

The server would not have started, or would have reported a cache warning, 
on AIX machines which had 4GB or more of memory installed.The messages 
displayed were:
	Memory not available - cache size set to 0K
	Not enough memory
or:
	A cache size of 262016K exceeds the available physical memory of 0K. 
A performance penalty may result.

A side-effect of this fix is that a server running on Unix cannot have 
a cache size larger than 4GB, and a starting cache greater than 4GB 
should not be specified.


=================(Build #2790  - Engineering Case #275514)=================

The Linux database server would not have started on systems using 2.4.x 
kernel, when the available memory was greater than 2GB. This is now 
fixed.


=================(Build #2790  - Engineering Case #275597)=================

Dynamic cache sizing on AIX would have failed, (the cache would never 
change size), when more than 50 processes were active on the system. 
This has been fixed.



=================(Build #2790  - Engineering Case #278773)=================

Server-side character translation, (ie -ct server command line option),  
from single-byte to single-byte character sets, may have failed, if 
one of the following character sets was involved:

CP852, CP855, CP856, CP857, CP860, CP861, CP862, CP863, CP864, CP865, 
CP866, CP869, CP874MS, CP1250, CP1251, CP1252, CP1253, CP1254, CP1255, 
CP1256, CP1257, CP1258.



While this is now fixed, a simple work around would be to delete the 
file asa.cvf. The server would then generate the correct mapping on 
demand at runtime.


=================(Build #3063  - Engineering Case #273362)=================

The LINKS parameter was being ignored by dbisql, if specified as a connection 
parameter, and act as if "LINKS=tcpip" was specified. Now it is parsed 
and any TCP parameters specified are used to find the engine. For example,

dbisql -c eng=foo;links=tcpip(host=172.31.143.60)

will now attempt to connect directly to 172.31.143.60:2638. If that 
doesn't work, the standard streams connection mechanism is used.

Note that you could always have used "dbisql -c eng=foo -host 172.31.143.60 
-port 2638" to do the same thing, but now with this change, dbisql allows 
th use of DSNs containing TCP parameters.


=================(Build #3259  - Engineering Case #269714)=================

If the CHAINED option was set to OFF and a cursor, not declared WITH 
HOLD, was opened on a stored procedure in which a temporary table and 
another cursor were both declared, closing the application's cursor 
could have caused a server crash. This has now been fixed.



=================(Build #3271  - Engineering Case #270472)=================

Executing a LOAD TABLE statement with the DEFAULTS ON clause would have 
corrupted the table, if no value was supplied for a column that did 
not have a default specified.  (Note: LOAD TABLE defaults to DEFAULTS 
OFF.)


=================(Build #3285  - Engineering Case #272050)=================

Converting a Java value to a string would have crashed the server, if 
there was a SQL error during the construction of the Java value.  For 
example, if the subselect in the following query:
SELECT name, jProd>>description, jProd>>quantity
FROM product
WHERE jProd>>quantity <  2 * (
   SELECT jItem>>quantity
   FROM sales_order_items)
returned more than one row, the server would have crashed, (since the 
Java value was converted to a string and then to a number). This is 
now fixed.


=================(Build #3290  - Engineering Case #271172)=================

A statement like:

	INSERT INTO t1 SELECT c1 FROM r_t1 WHERE c1 NOT IN (SELECT c1 FROM 
t1)

would have either crashed the server or given misleading error messages, 
if t1 was a local table that was part of a publication involving several 
tables and r_t1 was a proxy table. This problem has now been fixed.


=================(Build #3291  - Engineering Case #272492)=================

If a TCP or SPX connection is terminated abnormally, (i.e. without a 
database disconnect), a message is now displayed on the server console, 
(if the -z switch was specified). The message contains the user name 
and the reason that the connection was dropped. Shared memory connections 
already have such a message - "Disconnecting shared memory client, process 
id not found".

A message is also displayed if a DBA drops a connection using the DROP 
CONNECTION statement. This message contains the user name of the user 
who executed the DROP CONNECTION, and the connection number and user 
name of the connection that was dropped.


=================(Build #3292  - Engineering Case #332693)=================

The server could have become deadlocked when dropping tables, users 
or groups. This was most likely to occur on multiprocessor Unix machines.  
For the server to have become deadlocked, another transaction must have 
been concurrently accessing some database object (such as a table, procedure, 
view) for the first time. This has now been fixed.




=================(Build #3296  - Engineering Case #271860)=================

If an primary key or unique index had a different maximum hash size 
than any foreign keys referencing it, then a cascading delete or update 
would have incorrectly returned the error:  "Primary key for row in 
Table 'T1' is referenced in another table". This problem has been fixed.


=================(Build #3296  - Engineering Case #272550)=================

If an alias was defined on a complex expression in the select list of 
a grouped query and the alias was used in the group  by clause as well, 
the query would have failed with the error, "Function or column reference 
to ' ... ' in the select list must also appear in a GROUP BY".  The 
alias is now allowed to  be used in the group by clause as well.  

Examples of such queries are:

Example 1:
SELECT  x+1 as alias1, y, count(*)
FROM T
GROUP BY alias1, y

Example 2:
select  (select S.Y  from S where S.X = T.X) as A, count(*)
from T
group by A


=================(Build #3298  - Engineering Case #272776)=================

A column or expression name that was greater than 30 characters in length, 
would have been truncated to 30 characters for all TDS connections. 
The reason for the truncation was due to an Open Client limitation, 
not a general TDS limitation. Now, column or expression names get truncated 
to 30 characters for Open Client connections only, not for jConnect 
connections.



=================(Build #3299  - Engineering Case #270534)=================

The server could have consumed 100% CPU utilization for an extended 
period of time, usually immediately following a checkpoint. The duration 
of the CPU usage spike could have been several seconds to several minutes. 
During that time, new connection attempts may have failed, existing 
connections may have been dropped, and the
server would have been generally unresponsive. This is now fixed.


=================(Build #3299  - Engineering Case #272829)=================

IN-list predicates, (not to be confused with quantified subquery predicates 
using the IN, rather than ANY, keyword), containing a single element 
were being treated as IN predicates throughout rewrite optimization. 
This change converts such predicates to simple equality conditions, 
permitting the exploitation of these conditions for other rewrite optimizations, 
in particular for predicate normalization and inference.

Examples:

(1) With this change the query

select count(*) 
from customer
where ( state in ('nj') and lname <> 'foo' ) or
             ( state in ( (('nj')) ) and fname <> 'bar'

will be rewritten as

select count(*) 
from customer
where state = 'nj' and ( lname <> 'foo'  or fname <> 'bar' ).

(2) The query

Select count(*) 
from customer
where state not in ('NJ')

will be rewritten as

Select count(*)
from customer
where state <> 'NJ'



=================(Build #3299  - Engineering Case #272834)=================

The optimizer could have chosen a query plan that was less than optimal, 
if it used unique indexes, for which one or two columns had no matching 
predicates This was due to an incorrect computation of the estimated 
number of rows for an intermediate result. This has now been fixed.


=================(Build #3303  - Engineering Case #265081)=================

A query which generated an ASA warning, would have surpressed the warning, 
if the connection was from an Open Client  application. Now, these warnings 
will get sent back to an Open Client application. Note that the warning 
will still be suppressed, if the client is a jConnect application.


=================(Build #3305  - Engineering Case #272390)=================

The server would have suppressed ASA warnings, if the connection was 
from an Open Client application. These warnings will now be sent back 
to Open Client applications. Note that the warning will still be suppressed 
if the application connects using jConnect.


=================(Build #3306  - Engineering Case #273101)=================

Variables used in predicates in the WHERE or ON clauses, were not treated 
as constants by the optimizer when their values were known. The consequences 
included poor performance,  because such predicates were not  used, 
for example,  for  partial index scans.  This has been fixed.



=================(Build #3306  - Engineering Case #273389)=================

A number of connection-related messages displayed by the server in debug 
mode, (ie using the -z switch), have been changed to include a "connection 
ID". This id, which is a number assigned to each connection, is a monotonically 
increasing number, starting at 1, and is unrelated to the connection 
handle, which is displayed by Sybase Central, and used in the DROP CONNECTION 
statement.

Note that if a streams connection is made, but no database connection 
is made (eg. a dbping without the -d switch), then a connection ID will 
be used up but no messages are displayed (other than TCP connections 
on Win32).

The changes to these messages make it possible to correlate messages 
to particular connections. The first message displayed when a database 
connection is successfully completed contains both the connection ID 
and the connection handle, as well as the user name.



=================(Build #3309  - Engineering Case #273658)=================

For queries on tables flagged with HOLDLOCK, it was possible for phantom 
rows to have occurred. For example, repeatedly running the query, "select 
count(*) from t holdlock", in the same transaction, could have returned 
different values. This is now fixed.


=================(Build #3315  - Engineering Case #273410)=================

If a user loged into a Win 95/98 machine with an invalid domain name 
and then attempted to perform an integrated login to an ASA server running 
on an NT machine, the ASA server would have crashed. This problem has 
now been fixed and a proper error message now gets sent to the client.



=================(Build #3318  - Engineering Case #274339)=================

Revoking connect permission from the dbo user, also removed access to 
several database features, which cannot be restored without rebuilding 
the database.  Revoking connect permission from dbo is no longer permitted.



=================(Build #3319  - Engineering Case #274521)=================

If a database hads no transaction log file, or was running in read-only 
mode, the following DB properties returned meaningless values: CurrentRedoPos, 
LTMTrunc, RemoteTrunc and SyncTrunc. In this case, the properties now 
return 0.


=================(Build #3323  - Engineering Case #274857)=================

The NetWare server could have abended if the following occured in this 
order:
1 - a non-ESQL/non-ODBC application attempted to connect over TCP/IP 
to an ASA server running on NetWare but the connection failed (eg. database 
didn't exist)
2 - the application didn't close the TCP socket when the connection 
failed
3 - server shutdown was initiated, (i.e. hit 'q' on console - it will 
hang for 10 seconds)
4. the application closeed the TCP socket during the 10 second hang

If the TCP socket was closed at exactly the right moment, the server 
would have crashed. This has been fixed.


=================(Build #3324  - Engineering Case #274999)=================

If the following statements were executed, the SELECT statement would 
cause the error "Column 'm' in table '#temp' cannot be NULL". The column 
in the temporary table was defined to disallow nulls, even though the 
string() function can return a null result.

create table test (v1 int NULL);
insert into test values(NULL);
insert into test values(50);

select string(v1) m into #temp from test;

This is now fixed.


=================(Build #3326  - Engineering Case #275461)=================

Calling connection_property('diskreadtable') would always have returned 
0. This has been fixed. Note that db_property('diskreadtable') works 
as documented.



=================(Build #3327  - Engineering Case #275949)=================

The number of rows returned by a partial index scan for multi-column 
Foreign Key, Unique and Primary Key indexes may have been overestimated, 
resulting in poor performance for some queries which then miss the opportunity 
to use such indexes. This has now been fixed.


=================(Build #3328  - Engineering Case #273812)=================

A LOAD TABLE statement may have loaded data that violated a column constraint, 
due to  CHECK CONSTRAINTS
being OFF when the LOAD TABLE statement was executed. A dbunload -an, 
-ar or -ac reloads the database and verifies all constraints. If a constraint 
failed, the server may have crashed. This problem has been fixed.


=================(Build #3328  - Engineering Case #275488)=================

If the server was started without a database, but the cache page size 
was set  larger than the default page size of 1024, (via the -gp switch), 
then the message: "Note: database page size is smaller than the cache 
page size, resulting in inefficient use of memory" was incorrectly displayed. 
This problem has been fixed.


=================(Build #3328  - Engineering Case #276947)=================

Variables used in IF .. THEN ... statements may have caused the server 
to crash. This was due a bug introduced by the fix for issue 273101, 
( Variables used in predicates in WHERE or ON clauses were not treated 
as constants) and affected only 7.0.2 from build 1584) and 703 from 
build 2119). This is now fixed.

Example:
begin
  declare foo date;
  if  Month(foo) = 1 then      //  CRASH here
    ...
  end if;
  ...
end;


=================(Build #3332  - Engineering Case #277047)=================

The rebuild of a case-sensitive database with dbunload, using the command 
line options, -ar or -an, may have failed with the message: "Table ul_file 
not found". This was due to the JAVA option always being OFF for case 
sensitive databases. This has now been fixed.


=================(Build #3332  - Engineering Case #278207)=================

The dbcollat, dbinfo, and dbtsinfo tools were displaying blank-padded 
strings when connected to a blank-padded database. This has been fixed.


=================(Build #3333  - Engineering Case #277492)=================

If two adjacent index leaf pages were deleted concurrently, it was possible 
that the index would have become corrupt. This is now fixed.


=================(Build #3334  - Engineering Case #260400)=================

Core files, from servers or clients on Linux, now have more useful stack 
trace information on the thread that caused the fault. In the cleanup 
signal handlers,  pthread_kill_other_threads_np() is now called to force 
all other threads to exit before calling abort(). This change allows 
core dumps to contain the stack trace information of 

the thread running the signal handler, (usually the one that caused 
the violation), rather than the stack trace of the last thread that 
terminates in the process.


=================(Build #3334  - Engineering Case #273083)=================

Subquery flattening is now always done for subqueries of the form "select 
expr from DUMMY" or its equivalent form  "select expr".  
For example:

select * 
from product p, sales_order_items s
where p.id = ( select DISTINCT 301) and s.prod_id = p.id

is rewritten into:

select * 
from product p, sales_order_items s
where p.id = 301 and s.prod_id = p.id and s.prod_id = 301
 
There are three rewrite optimizations done in this example: 
1 - DISTINCT is eliminated from "(select DISTINCT 301)"
2 - subquery "(select 301)" is flattened and  "p.id = ( select DISTINCT 
301)" is rewritten to "p.id = 301"
3 -  "s.prod_id = 301" is inferred from  "p.id = 301" and "p.id = s.prod_id".

IQ: The subquery flattening is now always done for  IQ, for any subquery 
of the form "(select expr from DUMMY)" regardless if the subquery is 
correlated or not.


=================(Build #3334  - Engineering Case #274125)=================

The Personal Server would have started, even if the protocols specified 
by the -x command-line option could not be started. In these cases the 
Network Server always stopped with an error. Now the Personal Server 
will also stop, if a requested protocol cannot be started.


=================(Build #3334  - Engineering Case #278790)=================

If a WITH HOLD cursor was open on a table, and a publication involving 
that table was altered or dropped, subsequent updates or deletes through 
the cursor could have caused assertion 100905. If a new publication 
was created on a table while a WITH HOLD cursor was open on it, no assertion 
would be generated, but invalid information would be

written to the transaction log. This has been fixed; all cursors on 
a table will now be closed if a publication involving the table is created, 
altered or dropped.






=================(Build #3334  - Engineering Case #278904)=================

If a server was started with the -b switch, (bulk operations mode), 
a DROP DATABASE statement would have failed to delete the transaction 
log for the dropped database. This has been fixed.


=================(Build #3335  - Engineering Case #279243)=================

FULL OUTER JOINs may be rewritten as LEFT OUTER, RIGHT OUTER or COMMA 
joins, if the WHERE clause contains NULL rejecting predicates for left 
hand side,  right hand side or both left and right hand side tables 
respectively.  The transformation into RIGHT OUTER JOIN was incorrectly 
done.  In the example below, a NULL rejecting predicate, ("p2.id > 0") 
is defined on the right hand side of the FULL OUTER JOIN, (i.e., "product 
p2"), so the FULL OUTER JOIN should have been transformed into RIGHT 
OUTER JOIN, but instead was transformed into a COMMA JOIN. This has 
now been fixed.



EXAMPLE:

select p2.* from

product p1 FULL OUTER JOIN product p2 on( p1.quantity > p2.quantity)

where p2.id > 0


=================(Build #3337  - Engineering Case #265354)=================

The Sybase Adaptive Server Enterprise server does not allow any Transact-SQL 
assignments, (ie @variable = expression), in an IF EXISTS statement 
or in subqueries. The Adaptive Server Anywhere server did allow it, 
but did not set the variable in these cases. Now Transact-SQL assignments 
in IF EXISTS or in a subquery cause a syntax error.


=================(Build #3337  - Engineering Case #279576)=================

If a query involved more than 40 proxy tables on multiple remote servers, 
there was a very good chance the query would have crashed the server. 
This problem has now been fixed.


=================(Build #3337  - Engineering Case #290169)=================

The fix for issue 265354 introduced a problem where a valid statement 
such as that shown below would receive "Syntax error near "="":

	select @var=x

	from T

	where exists(...)

This is now fixed.




=================(Build #3338  - Engineering Case #277185)=================

Attempting to fetch a string that was 254 bytes in length, from a remote 
table using an ODBC based remote server, would have resulted in the 
last byte of the string being corrupted. This problem has now been fixed.


=================(Build #3339  - Engineering Case #280201)=================

If a database table with a timestamp column contained any rows at the 
time that the TRUNCATE_TIMESTAMP_VALUES option was set to 'ON', and 
the DEFAULT_TIMESTAMP_INCREMENT option was not set to 1, then updating 
a row in this table without simultaneously updating the timestamp value(s) 
in the row could cause assertion 103102 to be raised, if the row's width 
was increased.  This has been fixed.



Note that turning on the TRUNCATE_TIMESTAMP_VALUES option or increasing 
the DEFAULT_TIMESTAMP_INCREMENT when there is timestamp data in the 
database will not guarentee that the pre-existing timestamp values will 
be truncated appropriately.  This may lead to unexpected behaviour, 
particularly in replicating environments.   If you need to change either 
of these options, it is highly recommended that you unload your data, 
dbinit a new database, set the options appropriately, then reload your 
data.  These steps will ensure that all timestamp values in the new 
database are truncated correctly.




=================(Build #3340  - Engineering Case #286165)=================

A LOAD TABLE statement, not using any of the STRIP ON, ESCAPES ON or 
QUOTES ON clauses, would have inserted incorrect data for the last value 
in the data file, if the last row of the data file did not end in a 
newline character. This is now fixed.




=================(Build #3340  - Engineering Case #286180)=================

When run on AIX 5, the server could have taken an unusually long time 
to start. This has been resolved.


=================(Build #3342  - Engineering Case #287103)=================

If a server was extremely busy, connection attempts over links other 
than shared memory may fail with the error "Database cannot be started 
-- ???".  This has been fixed.


=================(Build #3343  - Engineering Case #287352)=================

Predicates that compared a date column to an integer constant, (or variable), 
were not treated as sargable by the optimizer, hence the optimizer would 
not have considered the use of an index for such predicates. For example, 
in the query



Select * from sales_order where order_date = 19931010



the comparison predicate would not be treated as sargable, so if an 
index existed on column order_date, it would not be utilized. This problem 
has been corrected.


=================(Build #3343  - Engineering Case #287488)=================

A race condition existed, when loading user group definitions, that 
could have caused the server to crash. Group definitions are only loaded 
once for each user, the first time it is referenced at startup or after 
a DDL statement changes user or group definitions, so the likelihood 
of the problem occurring was very small, and would not have occurred 
on single-CPU Win32 platforms. This problem is now fixed.


=================(Build #3344  - Engineering Case #287447)=================

The server could have sent back a column description with an invalid 
MBCS character, or filled the server's temp file, (and eventually assert), 
when all of these following conditions existed:



- the database was using a multibyte collation

- the select list contained an expression using multi-byte characters 
which was greater than 255 bytes long, and was not aliased

- the client application issueed a describe cursor request



This has been fixed, but a work-around is to provide an alias to the 
long expression.


=================(Build #3345  - Engineering Case #280050)=================

If a prepared statement caused an error when executed, (e.g. Update 
attempted on non-updatable query), a second attempt to execute the same 
prepared statement could have crashed the server. This could also have 
happened when attempting to execute an update or delete on a non-updatable 
view.




=================(Build #3346  - Engineering Case #288046)=================

A SQL statement like the following:



SELECT e.emp_id into #temp

	FROM dba.employee e

	WHERE e.emp_id IN

		(	SELECT  o.sales_rep

			FROM dba.sales_order o

			WHERE o.sales_rep = 299

		);

is rewritten as:



 SELECT DISTINCT e.emp_id into #temp

	FROM dba.employee e, dba.sales_order o

			WHERE o.sales_rep = 299 and e.emp_id = dba.sales_order

	

but the generated DISTINCT was being ignored. This could have caused 
more rows to be inserted into #temp than there should have been. The 
DISTINCT is no longer ignored


=================(Build #3347  - Engineering Case #288455)=================

When the procedure debugger is at a breakpoint, View/Other/Query allows 
a query to be executed and the result set displayed. If the query was 
longer than 255 bytes, it would have caused the server to crash. This 
problem has been corrected.


=================(Build #3348  - Engineering Case #278356)=================

Two servers from different major versions could not have been loaded 
on a NetWare server at the same time, due to of exported name collisions. 
This limitation has now been removed. Note that it is not possible to 
load two servers of the SAME major version at the same time (i.e. loading 
dbsrv8.nlm twice). There is a restriction however, SPX can only be used 
by one server at a time.

When attempting to connect over shared memory, dblib.nlm will first 
look for exported functions with the same version number (i.e. 7.x clients 
look for a 7.x server). If that export is not found, it will look for 
exports with DIFFERENT

version numbers, starting at 6 and going up to the current version 
plus 3. This means that 6.x clients will be able to connect over shared 
memory to version 6, 7, 8, and 9 servers, version 7.x client will be 
able to connect to version 6, 7, 8, 9, and 10 servers, and so on.



Note that because the version with the same number is searched for 
first, a version X client will connect to a version X server if more 
than one server is running and no engine name is specified by the client.


=================(Build #3348  - Engineering Case #278392)=================

If a connection had a WITH HOLD cursor, open at an isolation level greater 
than 0, positioned on a row, then deleted the row, (via this or another 
cursor/statement), and  did a COMMIT, the connection would have had 
a short-term read lock on a non-existent row (since cursor stability 
locks for with hold cursors persist across commit/rollback).  This could 
prevent another transaction from inserting a row into the table in question 
(if it decides to insert the row at the vacant slot left by the delete). 
The Cursor Stability lock is now removed in this case.


=================(Build #3348  - Engineering Case #288633)=================

If a stored procedure exception handler called another procedure to 
deal with the error, and the called procedure executed a RESIGNAL, the 
RESIGNAL would have been ignored. This is now fixed.


=================(Build #3349  - Engineering Case #289130)=================

If a DISCONNECT event handler was defined, a disconnect which caused 
an auto-shutdown of the database may not have caused the event handler 
to be executed. This problem would have happened on single-processor 
servers, but was unlikely to happen on multi-processor servers, unless 
the database server was started with the "-gt 1" command-line option 
to limit the number of OS threads used. The DISCONNECT event handler 
will now execute correctly.


=================(Build #3350  - Engineering Case #288664)=================

If a trigger used alias to reference the old and new row values and 
if one of the two alias names was not defined, for example:



create trigger trig1 before update on T1

   // referencing old as oldname  -- missing definition

   referencing new as newname

   for each row

     begin

        if oldname.col1 > newname.col1 then

            message 'Test'

        end if;

     end



then no error was detected during execution of the trigger. The above 
IF condition was always false. This has been fixed. Now the error "Correlation 
name 'oldname' not found" is returned as expected.


=================(Build #3355  - Engineering Case #290430)=================

If the datediff() function was used to compute the difference in seconds 
between two timestamps, the result would be incorrect if all of the 
following conditions were true:

	- the first timestamp was later than the second timestamp

	- the microsecond components of the two timestamps were not equal

	- the value of seconds plus microseconds for the first timestamp was 
greater than that for the second timestamp



For example:

	select datediff(second,'2002/06/23 12:00:00.100','2002/06/23 12:00:00.000')

would return -1 instead of 0. The correct value of 0 is now returned.




=================(Build #3357  - Engineering Case #266094)=================

Join elimination, based on a foreign key defined on a unique constraint, 
may have been done incorrectly, resulting in wrong result sets or syntax 
errors. The conditions under which this may have occurred were:
1 - There were at least two unique constraints, (one may have been 
a Primary Key constraint ), defined on a table, (P in example)
2 - The query referenced only  the columns on one of the unique constraints.
3 - The query had equijoin predicates with a foreign key table, (F 
in example), where the foreign key was defined on the other unique constraint

Example:
 
CREATE TABLE P(
	one	CHAR(4) NOT NULL  
	two	INTEGER NOT NULL PRIMARY KEY,
	UNIQUE(one,two)
);
CREATE TABLE F(
	two INTEGER NOT NULL REFERENCES two(two)
);

SELECT * FROM  P  KEY JOIN F;   

This problem has now been fixed.



=================(Build #3357  - Engineering Case #290957)=================

If the Return_date_time_as_string option was 'ON' (as it is for DBISQL), 
creating a procedure which returned a date/time column in its result 
set and which did not declare the result set explicitly, would have 
caused the result set column to be recorded as CHAR rather than DATE 
in the catalog. For example:

	create table dateTable(

	    id int not null primary key,

	    dateCol date );

	create PROCEDURE dba.Test()

 	  BEGIN

	    select id, dateCol from dateTable;

	  END;

In the above example, the second result set column for the procedure 
would have been defined as CHAR rather than DATE. This has now been 
corrected.


=================(Build #3358  - Engineering Case #291232)=================

This fix corrects a problem where the server would quietly terminate.


=================(Build #3361  - Engineering Case #291318)=================

Selecting data from a long varchar column in a proxy table, via ODBC, 
would have caused the last byte of every 255 byte chunk to go missing. 
This has now been fixed.




=================(Build #3361  - Engineering Case #291803)=================

If the confirm_received column of SYSREMOTEUSER contained NULL, the 
dbunload utility would have generated an incorrect sa_setremoteuser 
procedure call in reload.sql. The wrong call to sa_setremoteuser contained 
unprintable characters, no value for confirm_recieved or the confirm_received 
value of the previous sa_setremoteuser call. This has been fixed.


=================(Build #3361  - Engineering Case #291978)=================

Repeatedly dropping another connection could have caused the server 
to fail, usually with a streams protocol error.  For this to have happened, 
a number of drop connection requests (greater than four) must have been 
issued before the first one took effect.  Further, the connection being 
dropped must have been working on a request, possibly blocked and the 
time taken to cancel the request must have been greater than the time 
to receive the drop requests.  This is now fixed.


=================(Build #3364  - Engineering Case #289515)=================

When making a connection via jConnect, if the remote password login 
parameter was set to a large value, (for example when using the technique 
of adding database filename to the remote password and the database 
file path was large) then there was a very good chance that the connection 
would have failed with a message like "invalid user_id". This problem 
has been fixed.


=================(Build #3365  - Engineering Case #290788)=================

If a JDBC request was cancelled, then there was a chance the JDBC application 
would have failed with an unexpected exception. This problem was most 
likely to occur when closing a JDBC cursor. The problem has now been 
resolved.


=================(Build #3366  - Engineering Case #293186)=================

Assertion 201119 could have been generated when using a write file with 
a compressed database file.  This has been fixed.


=================(Build #3367  - Engineering Case #277744)=================

The str() function was returning an incorrect result as shown below.  
The SQL statement



	select str(22222222202222222220.222222222, 30,9 );



should return the string "22222222202222222220.222222222" like ,but 
it was actually returning "22222222202222223360.0000000000".



This was due to the fact that the number 22222222202222222220.222222222 
was being converted internally to a floating-point value and, as such, 
was restricted in the amount of precision that could be maintained.  
For 64-bit IEEE floating-point representation, this amounts to about 
18 digits of accuracy. The result is also dependent on the run-time 
system/computer system in, (a Win32 result may differ from a Unix result). 
The fix was to limit the values for the second and third arguments to 
128 and set the maximum value for the floating-point value to a number 
less than 1E127.




=================(Build #3368  - Engineering Case #293317)=================

If a subquery contained an outer reference to a subselect, then the 
results of the referencing subquery could have been incorrect. For example, 
the following query showed the problem:



SELECT  ( SELECT 1 FROM sys.dummy D1 WHERE R.row_num IS NOT NULL ) 
AS A1

FROM    dbo.rowgenerator R

WHERE   ( SELECT 2 FROM sys.dummy D2 WHERE A1 IS NOT NULL ) IS NOT 
NULL






=================(Build #3369  - Engineering Case #293782)=================

A failed autocommited statement could have caused the server to assert 
( 102300 - File associated with given page id is invalid or not open 
), if the ANSI_CLOSE_CURSORS_ON_ROLLBACK option was set and the autocommited 
statement that was being executed was part of an open cursor. This has 
now been fixed.


=================(Build #3369  - Engineering Case #293998)=================

If an archive backup to a tape drive was attempted on a NetWare server 
and libsybbr.nlm was NOT loaded, the backup would have failed with error 
-692, "Could not execute backup/restore DLL (syb_open) entry point." 
This has been fixed. As a workaround, load libsybbr.nlm on the server 
before attempting the backup.


=================(Build #3369  - Engineering Case #294145)=================

Specifying a long filename when using LOAD TABLE on a NetWare server 
may have resulted in error -602 "Cannot access file". This has been 
fixed.


=================(Build #3369  - Engineering Case #294162)=================

If a query referenced the ROWID() function with a parameter being the 
name of a declared temporary table created in the select, the server 
would have crashed. Now, the server gives the error:

	 -142 "Correlation name '%1' not found"



For example, the following query demonstrates the behaviour:



	select	rowid(#temp)

	into	#temp

	from	sys.dummy


=================(Build #3372  - Engineering Case #294800)=================

If a request was cancelled and the application was terminated before 
the cancel completed, it was possible in rare cases for the connection 
to remain until the server was shut down.  The connection which remained 
would keep any existing locks, use an engine "thread" (-gn parameter), 
and could not be dropped by DROP CONNECTION.  For this problem to have 
occurred, the request which was cancelled must have returned more data 
than the communication buffer size. This problem is now fixed.


=================(Build #3372  - Engineering Case #294817)=================

If the server was started with -z command line option, it would have 
displayed "liveness packet received" for each liveness packet it received 
from a client. This could have resulted in a large server output log. 
These messages have been removed.




=================(Build #3374  - Engineering Case #295500)=================

If xp_cmdshell was called when the server was running on a Windows .NET 
Operating System (eg Windows .NET Server), the server could have crashed.  
This has been fixed.


=================(Build #3374  - Engineering Case #296711)=================

The locate() function takes an optional third parameter which specifies 
the starting offset for the search. As of this change, if the starting 
offset is negative, locate() will return the last matching string offset 
rather than the first. A negative offset indicates how much of the end 
of the string is to be excluded from the search. The number of bytes 
excluded is calculated as (-1 * offset) - 1.


=================(Build #3375  - Engineering Case #295979)=================

If a checkpoint occurred during an undo operation, the database could 
have been left in an unrecoverable state until the next checkpoint occurs. 
An undo operation is performed in the following situations:

- a rollback of a subtransaction

- a rollback to a savepoint

- a failed DML statement

- a cancelled statement (the undo actually occurs just before the next 
statement on that connection is executed).

 

A rollback of a full transaction was not affected by this problem. 
Checkpoints are now prevented during undo operations.


=================(Build #3377  - Engineering Case #296129)=================

A remote query containing a CAST or CONVERT over a User Defined Function 
would incorrectly pass the funtion to the remote server, instead of 
processing it locally. For example:



    select cast( rolf(c1) as float) into #temp from t1; 



The function rolf, that returns a double, would have been processed 
in full passthrough mode, instead of no passthrough. This problem has 
now been fixed.


=================(Build #3380  - Engineering Case #296935)=================

Passing a subquery expression as a procedure argument could have crashed 
the server. The subquery must have been part of another expression for 
the crash to have occurred; simple subquery arguments result in a syntax 
error.

For example:

	call myproc(coalesce(null,(select 1)))

A syntax error will now be generated for all subqueries used as any 
part of a procedure argument. To pass a subquery to a procedure, assign 
the subquery result to a variable and pass the variable to the procedure.


=================(Build #3384  - Engineering Case #297863)=================

It was possible to define multiple consolidated users on the same remote 
database with a SQL command similar to :

GRANT CONSOLIDATED TO u1,u2 TYPE FILE ADDRESS 'u1','u2';

This command now returns an error.




=================(Build #3384  - Engineering Case #299561)=================

Calling the system procedure sa_locks() multiple times, while the server 
was busy, may have caused the server to crash. This is now fixed.




=================(Build #3386  - Engineering Case #293788)=================

Calling xp_sendmail functions simultaneously, from different connections, 
could have caused unexpected behaviour, up to and including a server 
crash.  This has been fixed, but in order to take advantage of it, several 
system procedures need to change. Databases created, or rebuilt, after 
this change will have these new procedures, but for existing databases, 
the following script will make the necessary changes:



-- START OF SCRIPT



insert into dbo.EXCLUDEOBJECT values ( 'xp_real_stopmail' , 'P' )

go

insert into dbo.EXCLUDEOBJECT values ( 'xp_real_startmail' , 'P' )

go

insert into dbo.EXCLUDEOBJECT values ( 'xp_real_sendmail' , 'P' )

go



CREATE function dbo.xp_real_startmail( 

		in mail_user     char(254) default null, 

		in mail_password char(254) default null,

		in connection_id int ) 

	returns int 

	external name 'xp_startmail@dbextf.dll' 

go

	

ALTER function dbo.xp_startmail(

		in mail_user     char(254) default null, 

		in mail_password char(254) default null ) 

	returns int 

begin

	declare connection_id int;

	select connection_property( 'Number' ) into connection_id from dummy;

	return( xp_real_startmail( mail_user, mail_password, connection_id 
) )

end

go

CREATE function dbo.xp_real_stopmail( in connection_id int ) 

	returns int 

	external name 'xp_stopmail@dbextf.dll' 

go

ALTER function dbo.xp_stopmail() 

	returns int 

begin

	declare connection_id int;

	select connection_property( 'Number' ) into connection_id from dummy;

	return( xp_real_stopmail( connection_id ) )

end

go

CREATE function dbo.xp_real_sendmail( 	

		in recipient           char(254), 

		in subject             char(254)   default null, 

		in cc_recipient        char(254)   default null, 

		in bcc_recipient       char(254)   default null, 

		in query               char(254)   default null, 

		in "message"           char(254)   default null, 

		in attachname          char(254)   default null, 

		in attach_result       int         default 0, 

		in echo_error          int         default 1, 

		in include_file        char(254)   default null, 

		in no_column_header    int         default 0, 

		in no_output           int         default 0, 

		in width               int         default 80, 

		in separator           char(1)     default '\t', 

		in dbuser              char(254)   default 'guest', 

		in dbname              char(254)   default 'master', 

		in type                char(254)   default null, 

		in include_query       int         default 0,

		in connection_id       int ) 

	returns int 

	external name 'xp_sendmail@dbextf' 

go

ALTER function dbo.xp_sendmail( 	

		in recipient           char(254), 

		in subject             char(254)   default null, 

		in cc_recipient        char(254)   default null, 

		in bcc_recipient       char(254)   default null, 

		in query               char(254)   default null, 

		in "message"           char(254)   default null, 

		in attachname          char(254)   default null, 

		in attach_result       int         default 0, 

		in echo_error          int         default 1, 

		in include_file        char(254)   default null, 

		in no_column_header    int         default 0, 

		in no_output           int         default 0, 

		in width               int         default 80, 

		in separator           char(1)     default '\t', 

		in dbuser              char(254)   default 'guest', 

		in dbname              char(254)   default 'master', 

		in type                char(254)   default null, 

		in include_query       int         default 0 ) 

	returns int 

begin

	declare connection_id int;

	select connection_property( 'Number' ) into connection_id from dummy;

	return( xp_real_sendmail( recipient, subject, cc_recipient, bcc_recipient, 
query, "message", attachname,

		attach_result, echo_error, include_file, no_column_header,

		no_output, width, separator, dbuser, dbname, type,

		include_query, connection_id ) );

end



-- END OF SCRIPT










=================(Build #3386  - Engineering Case #299066)=================

If an UPDATE statement used an index on a column defined with DEFAULT 
TIMESTAMP, it could have looped infinitely. This is now fixed.


=================(Build #3386  - Engineering Case #299721)=================

The VALIDATE TABLE statement, or the dbvalid utility, could have  spuriously 
reported missing index entries. When checking a foreign combined index, 
(ie 5.x format), with the FULL CHECK option, entries containing some, 
but not all, nulls would have generated a spurious report of a missing 
index entry. This is now fixed.


=================(Build #3386  - Engineering Case #300402)=================

Executing the system procedure, xp_startmail, would have returned either 
0 (success) or 2 (failure), which maked diagnosing xp_starmail failures 
difficult.

Now xp_startmail, (as well as xp_sendmail and xp_stopmail), returns 
one of

the following:



  Value    Description 

  0        Success

  2        xp_startmail failed

  3        xp_stopmail failed 

  5        xp_sendmail failed

  11       Ambiguous recipients

  12       Attachment not found

  13       Disk full

  14       Failure

  15       Invalid session

  16       Text too large

  17       Too many files

  18       Too many recipients

  19       Unknown recipient

  20       Login failure

  21       Too many sessions

  22       User abort

  23       No MAPI

  24       xp_startmail not called (xp_sendmail and xp_stopmail only)


=================(Build #3388  - Engineering Case #300401)=================

Running the dbexpand utility on Unix platforms, was taking a long time 
to expand a compressed database file. This has now been greatly improved.


=================(Build #3390  - Engineering Case #300847)=================

If the path to a database file contained brace characters (eg.

"E:\test\{test}\sample.db"), applications using dblib or odbc could 
not have autostarted it. This has been fixed. Note that starting a server 
directly on the file (eg. dbeng8 E:\test\{test}\sample.db) was not a 
problem.


=================(Build #3392  - Engineering Case #301575)=================

When there were approximately one hundred idle connections with liveness 
enabled, liveness packets would have been sent out in large bursts.  
These bursts could potentially have caused performance problems or dropped 
connections.  This fix attempts to avoid sending liveness packets in 
large bursts.


=================(Build #3393  - Engineering Case #298372)=================

The server would have crashed on shutdown, when running on Windows CE 
.NET. This is now fixed.


=================(Build #3393  - Engineering Case #301116)=================

The server could have crashed when executing the MESSAGE statement. 
This is now fixed.


=================(Build #3394  - Engineering Case #299297)=================

The database server could have reported a fatal error or assertion failure 
due to a failed IO operation. The error message displayed may have been 
"Fatal error: Unknown device error", "Fatal error: no error", "A write 
failed with error code: (1453)", "A write failed with error code: (1450)", 
or some other form of fatal error or assertion failure message. 

 

Certain errors such as 1450 and 1453 can (apparently) be reported by 
NT during "normal" operation. The server now retries IOs that fail with 
one of these particular error codes up to 100 times. If the IO does 
not succeed after 100 attempts, the server will now report the error 
as a fatal error (same message as before). It is impossible to know 
whether 100 attempts will give the OS sufficient time to remedy whatever 
problems it is having. 



It is believed that the OS reports these errors when available memory 
is low. A work around may be to ensure that the system is not low on 
memory.




=================(Build #3395  - Engineering Case #300903)=================

Entering an invalid query like the following, (note missing table alias 
B):

	DELETE FROM t1 A FROM t2 WHERE A.c1 = B.c1

where both t1 and t2 were remote tables, would have caused the statement 
to be passed  to the remote server, instead of being rejected immediately. 
This problem has now been fixed.


=================(Build #3397  - Engineering Case #303048)=================

A FOR statement in a stored procedure would have created string variables 
for date, time or timestamp expressions in the SELECT list of the FOR 
query, if the Return_date_time_as_string option was ON. Now, the variables 
are created with the same data types as the expressions.




=================(Build #3399  - Engineering Case #301012)=================

If a server was started on the same machine as another server of the 
same name, which was was in the process of shutting down, the server 
could have hung. Also, if a client attempted to connect via shared memory 
to the newly started server, while the previous server with the same 
name was still shutting down, the client could have hung. This problem 
has been fixed.


=================(Build #3400  - Engineering Case #303563)=================

If the SUBSTR function was used to obtain a substring of a LONG VARCHAR 
column and the third argument was not provided, a value of 32767 was 
used. The function worked correctly if the first argument was a variable. 
Now a value of 2147483647 is used. For expressions such as variables, 
where the string length is known when the expression is built, the actual 
string length will continue to be used as the third argument.


=================(Build #3400  - Engineering Case #303602)=================

When attempting a BACKUP DATABASE operation on Windows CE, the process 
would have failed with the error message:

IO Error 5 doing 'fstat' on file '<backup file name>'.

Ensure that all PC cards are inserted and that storage space is available.

Retry/Cancel.



This has been corrected.


=================(Build #3400  - Engineering Case #303784)=================

The system procedure xp_stopmail would always have had a returncode 
of 16 (invalid session handle), even if the previous calls to xp_startmail 
and xp_sendmail succeeded. While this problem is now fixed, it would 
only have appeared on databases created by ASA 7.0.4 build 3386 or later.  
Databases created by earlier versions of ASA should not exhibit this 
problem.


=================(Build #3408  - Engineering Case #304960)=================

When making a connection to an ASA remote server, via ODBC, the Remote 
Data Access layer now names the remote connection ASACIS_? where "?" 
gets replaced with the connection id of the local connection. This feature 
is useful if a customer needs to drop the remote connection in order 
to cancel a remote request.


=================(Build #3409  - Engineering Case #303576)=================

The MobiLink server memory usage would have increased over time as synchronizations 
occurred, even if the synchronization did no processing.  This has been 
corrected.




=================(Build #3410  - Engineering Case #305412)=================

If a blob column was updated using oledb (eg. through ADO cursors ), 
the ASA provider could have crashed. This is now fixed.


=================(Build #3410  - Engineering Case #305902)=================

It was possible that any of the following commands could have written 
the OPTION clause incorrectly to the database:

CREATE SYNCHRONIZATION USER, ALTER SYNCHRONIZATION USER, CREATE

SYNCHRONIZATION SUBSCRIPTION, ALTER SYNCHRONIZATION SUBSCRIPTION, CREATE

SYNCHRONIZATION SITE, ALTER SYNCHRONIZATION SITE, CREATE SYNCHRONIZATION

DEFINITION, ALTER SYNCHRONIZATION DEFINITION, CREATE SYNCHRONIZATION

TEMPLATE, ALTER SYNCHRONIZATION TEMPLATE.

This has now been fixed.


=================(Build #3412  - Engineering Case #306125)=================

With ANSI_INTEGER_OVERFLOW set to 'on', select 470488670*16 would have 
returned -1062115872 on Unix platforms. This has been corrected so that 
the behaviour is to return an overflow error.


=================(Build #3414  - Engineering Case #303384)=================

If a remote table A had two separate foreign key columns c1 and c2, 
both referencing table B. the sa_migrate system procedure would have 
attempted to import both foreign keys as a single foreign key relationship; 
ie (c1, c2) references B(p1,p1),  resulting in the error "foreign key 
p1 already referenced". This problem has now been fixed.


=================(Build #3414  - Engineering Case #303402)=================

The sa_migrate system procedure would have migrated indexes incorrectly. 
For example, given a table T with columns c1,c2,c3,c4,c5 with index 
i1 on column c1, and index i2 on columns c2 and c5. The generated indexes 
for the local table would have had two separate but identical indexes, 
i1 on columns c1,c2 and c5 and i2 on columns c1,c2 and c5. This problem 
has now been corrected.


=================(Build #3414  - Engineering Case #306336)=================

If a function had a badly defined return statement as in the following 
case:



    create function f() returns varchar(10)

    begin 

      return systable.table_id; 

    end



then using the function would have resulted in a server crash. This 
problem has now been fixed and server will now return an appropriate 
error message.


=================(Build #3414  - Engineering Case #307415)=================

When using the Remote Data Access feature to attempt to create a proxy 
table to a Microsoft Access database, the server may have failed with 
a "table not found message". This problem occurred when the file path 
of the Access database was longer than 63 characters. The problem has 
now been fixed.


=================(Build #3415  - Engineering Case #296243)=================

When the server was running on NetWare, and clients had connected and 
disconnected many times in a short period (a few minutes), the NetWare 
server could have abended with a "CPU Hog" message. This was more likely 
if the server was very busy and one or more connections were sending 
or receiving large amounts of data. This has been fixed.


=================(Build #3416  - Engineering Case #306467)=================

Calling sa_get_eng_properties on a operating system platform with a 
large amount of memory, would have displayed properties like "MainHeapBytes" 
as a negative number.  This can also be demonstrated by calling the 
property() function directly.

Example:

select property( 'MainHeapBytes' );



This has been fixed.


=================(Build #3416  - Engineering Case #306470)=================

Databases created with a 7.0.4.3407 server would have failed to start 
with any newer release of the server, (e.g., any  8.x server), with 
a "capability 27 missing" error. 

This problem has now been fixed.


=================(Build #3416  - Engineering Case #306580)=================

Queries with LIKE predicates containing a NULL escape character were 
being evaluated as if there was no escape character. Now LIKE predicates 
containing a NULL escape character evaluate to NULL. This new behaviour 
matches the ANSI standard.


=================(Build #3417  - Engineering Case #295384)=================

Indexes and foreign keys explicitly created by a user can now be renamed 
with an ALTER INDEX statement:  



ALTER INDEX  indexname rename-spec

ALTER [INDEX] FOREIGN KEY rolename rename-spec



rename-spec:

	ON [ owner.]tablename RENAME [ AS | TO ] newname




=================(Build #3417  - Engineering Case #308663)=================

If the option wait_for_commit was on, it was possible to commit a transaction 
that had inserted a foreign key with no matching primary key.  For this 
to have happened, all of the following conditions must hold:

- the foreign key in question must have been larger than any existing 
primary key,

- another transaction (also with the wait_for_commit option on) must 
have inserted the same foreign key before the first transaction commited, 
and must have done so while the foreign key was greater than any existing 
primary key,

- between the two foreign key insertions, enough primary keys must 
have been added to fill the last leaf page and at least one of these 
keys must be subsequently deleted (before the second foreign key insertion).

- the index used to enforce the constraint must have been a uncombined 
(split) comparision-based index.

This has now been fixed.


=================(Build #3419  - Engineering Case #309296)=================

In the presence of concurrent DDL or LOCK TABLE operations, it was possible 
to commit a transaction that had inserted a foreign key with no matching 
primary key.  For this to have occurred, all of the following conditions 
must have been true:

- the committing transaction must have deleted a primary row for which 
there were foreign references

- another transaction must have had the foreign table's schema locked 
exclusively (via DDL or LOCK TABLE)

- the DDL or LOCK TABLE operation must have been the first use of the 
foreign table since it was loaded

- the committing transaction must have had blocking off (or possibly 
be involved in a deadlock)

- the index used to enforce the constraint must have been an uncombined 
(split) index.



This problem, which could also have resulted in a server crash, is 
now fixed.


=================(Build #3421  - Engineering Case #309658)=================

Database validation would fail to recognize missing entries in a PK 
with respect to a FK.  Validation was not finding missing entries in 
a primary key when checking a foreign key.  As a result, it was possible 
to get referential integrity violations while rebuilding a database 
or index even though validation showed the database was fine.  The validation 
now occurs as documented.  That is, for foreign key indexes, validation 
ensures that the corresponding row exists in the primary table.  As 
a result of this change, database validation may now take longer.




=================(Build #3425  - Engineering Case #310638)=================

A table containing an indexed numeric column could have become corrupt 
if the value of the precision option was changed to a value smaller 
than that of some of the values that existed in the table, and rows 
containing such values were subsequently modified. This has been fixed.


=================(Build #3426  - Engineering Case #310658)=================

If a database server was started as an NT service, using the LocalSystem 
account, non-administrative users would still have been able to kill 
the database server process using the task manager or a command-line 
based kill program. With this fix, non-administrative users no longer 
have the ability to kill the database server process.




=================(Build #3429  - Engineering Case #310881)=================

When altering a table involved adding a column with a computed or default 
value, row locks were obtained which, if table was large, could have 
caused the operation to fail. The row locks were redundant, since there 
already was an exclusive schema lock. The row locks are no longer obtained.


=================(Build #3429  - Engineering Case #312221)=================

A permissions problem with derived tables has been fixed.


=================(Build #3431  - Engineering Case #312345)=================

If an EXECUTE IMMEDIATE expression in a stored procedure contained a 
reference to an undefined variable, the server would have crashed.

For example:

CREATE procedure foo( IN tablename varchar(256) )

BEGIN

     EXECUTE IMMEDIATE  'SELECT * FROM ' ||  table_name;

END ;



call foo('DBA.sales_order_items');



The problem has been fixed and a "Column not found" error is now generated.


=================(Build #3432  - Engineering Case #311850)=================

When creating a stored procedure which returned a result set and the 
result set datatypes were not explicitly specified, if one of the result 
set columns was NUMERIC and the precision of the column was calculated 
as greater than 128, a server crash would have resulted. This has been 
fixed. A workaround is to explicitly specify the result set datatypes.


=================(Build #3436  - Engineering Case #310700)=================

When purging locks from the lock table, the lock table entries could 
have become misordered.  It was unlikely that this would have caused 
problems other than assertions 200300, 200301 or 200302.  For this problem 
to have occurred, there must have been active keyset cursors and the 
database either must have had more than 1 dbspace, or more than  1,000,000 
pages in the system dbspace. This is now fixed.


=================(Build #3436  - Engineering Case #314159)=================

Adding columns between creating and selecting from a view caused the 
server to fail.


=================(Build #3437  - Engineering Case #294229)=================

If a LOAD TABLE statement resulted in an error (e.g. a conversion error), 
a subsequent call to a stored procedure which referenced the table could 
have caused the server to crash. The procedure must have been called 
at least once prior to executing the LOAD TABLE statement. This problem 
is now fixed.




=================(Build #3437  - Engineering Case #311195)=================

In versions of ASA earlier than 8.0.0, assertions 101201, 104802 and 
104803 could have occurred while defragmenting a database log file, 
if it was in use by a server running with the -m command line option 
to truncate the log file at a checkpoint. In versions 8.0.0 and later, 
assertions 100908, 100909 and 104802 could have occurred in this same 
situation.  

When running with the -m option, the log file is truncated at each 
checkpoint, but this truncation could not have occurred if the file 
was being defragmented concurrently.  This has now been fixed. 



Note: Use of the -m switch is not advised, please read the documentation 
before using this server command line switch.  To avoid database file 
fragmentation, it is recommended that where this option is used, the 
transaction log be placed on a separate device or partition from the 
database itself.  

It is also not recommended to defragment any database files while they 
are in use.


=================(Build #3438  - Engineering Case #240450)=================

If a user was using a view or executing a procedure owned by a different 
user, and then the permission to use the view or procedure was revoked, 
the user could still have used the view or procedure until the server 
was restarted. This has been fixed - the revocation now takes place 
immediately.


=================(Build #3438  - Engineering Case #311888)=================

A query with a GROUP BY clause that involved concatenation, could have 
caused a server crash.

Far example:

create table B( city char(20), state char(20));



select city || state 

from B 

where city || state not in

		(select city || state from B

		group by city || state);



For the crash to have occurred, the table B must have contained a combination 
of empty and non-empty strings. This has been fixed.


=================(Build #3438  - Engineering Case #314828)=================

Error strings returned from the server through a TDS connection, could 
have had garbage characters preceding the message.  This has been fixed


=================(Build #3440  - Engineering Case #308876)=================

If CHAINED was set to off (as is the default with TDS connections) and 
a statement was closed, then all locks were not released even though 
they should have been. This problem has now been fixed.


=================(Build #3446  - Engineering Case #315364)=================

If an application executed a single SQL statement that ended with a 
semicolon, the server would have interpreted this as batch and did not 
allow output parameters. In the following ODBC example the prepare of 
a procedure call has a semicolon at the end which causes an error during 
execution:     

   SQLPrepare( "Call sp1( ?, ? );" )

   SQLBindParam( parameter 1, of type SQL_PARAM_OUTPUT)

   SQLBindParam( parameter 2, of type SQL_PARAM_INPUT)

   SQLExecute;  --> HY105 error (invalid parameter type)

This problem has now been fixed


=================(Build #3446  - Engineering Case #316104)=================

If an event handler was running when an attempt was made to upgrade 
a database, the upgrade would have failed to start, since another connection 
was active. Now the upgrade will wait for the event handler to complete 
before proceeding.


=================(Build #3449  - Engineering Case #318798)=================

ASA Servers running on Windows 2003 Server would not have been found 
by the dblocate utility.  Now they are found.


=================(Build #3451  - Engineering Case #317082)=================

After an application connected to a local engine or server via the shared 
memory, the local application could not be killed using the 'End Task' 
action in the task manager -- even if the user was an Administrator. 
The problem was introduced by the change for QTS 310658 (Non-administrative 
user could kill database server started as LocalSystem NT service). 
The problem was reproduced on Windows 2000 Professional SP3 but could 
not be reproduced on Windows 2000 Server SP3. This has now been corrected.




=================(Build #3451  - Engineering Case #319085)=================

If the first query referencing a table after a database was started 
contained an error in the WHERE clause, subsequent queries would return 
the error:

	Cannot find an index for field '<column name>'.  

	Every field must have at least one index.  Current IndexCount = 0.

The database would have needed to be restarted to correct the problem. 
This has been fixed.


=================(Build #3451  - Engineering Case #319282)=================

Calling the system function "property( 'platform' )", incorrectly returned 
'Windows 2000' on Windows XP and Windows 2003.  Now it returns 'Windows 
XP' and 'Windows 2003' respectively.




=================(Build #3452  - Engineering Case #332364)=================

A successfully executed ALTER PROCEDURE (or FUNCTION) statement could 
have been written to the transaction log with an incorrect owner name 
if the owner name was not specified in the ALTER statement and the procedure 
or function was owned by a user other than the one executing the ALTER 
statement. This error would have resulted in failure during recovery 
if the logged statement needed to be replayed.



As an example, assume that a procedure USER1.TEST already existed in 
the database and the procedure USER2.TEST did not exist. Further, assume 
that USER2 was able to see and modify the procedure owned by USER1. 
Now, if USER2 executed an "ALTER PROCEDURE TEST" statement, then the 
server would have resolved the procedure name as "USER1.TEST" and correctly 
modified that procedure. However, the statement put in the transaction 
log would have incorrectly referred to procedure "USER2.TEST".



This problem has now been fixed. Note that the problem has an impact 
only when the logged statement needs to be replayed for any reason.


=================(Build #3461  - Engineering Case #277876)=================

The server would have crashed if an column from a proxy table was used 
as an argument to a java function. For example the following statement 
would have crashed the server:



	select new java.math.BigDecimal(c1) from p_table



Where c1 was an int column in the proxy table p_table. This problem 
has now been fixed.


=================(Build #3464  - Engineering Case #322005)=================

After installing Service Pack 6 for NetWare 5.1, or Service Pack 3 for 
NetWare 6.0, the server would no longer detect if other servers are 
running with the same name. If -z was specified, messages would have 
appeared in the console saying "Could not enable broadcasting" and "Broadcast 
send failed". This was due to a bug in BSDSOCK.NLM shipped with these 
two service packs. The ASA server will now detect this bug and work 
around it, and will display a message on the ASA console to that effect. 
We recommend that a newer version of BSDSOCK.NLM be downloaded from 
Novell when it is available.


=================(Build #3464  - Engineering Case #322348)=================

A procedure containing a comparison of a variable with a subquery involving 
proxy tables would have resulted in the error:

	OMNI cannot handle expressions involving remote tables inside stored 
procedures



An example of this situation is:

create procedure p()

begin

    declare myvar int;

    set myvar = 1;

    if myvar = (select col from remote_table where pk = 45) then

        message 'found'

    else

        message 'not found'

    end if;

end



This statement will now execute correctly.


=================(Build #3466  - Engineering Case #305153)=================

If an integrated logon was invalid (ie the logon request was coming 
from a machine on a different domain and cannot be properly verified) 
then the connection would seem to have succeeded even though the client 
would eventually time out. The problem has been resolved and a proper 
error message is now returned immediately.


=================(Build #3466  - Engineering Case #322888)=================

The dbbackup utility (dbbackup -x) could have hung (even if there were 
no outstanding transactions), until any connection did a commit, rollback 
or disconnect.  In order for this to occur, the backup had to take (or 
be blocked) for longer than half of the checkpoint time.  This has been 
fixed.




=================(Build #3466  - Engineering Case #323070)=================

If a user made a Remote Procedure Call that involved numeric parameters, 
then the call may have failed (if connected to ASE or any other Data 
Direct ODBC datasource) or the parameters would not have been passed 
correctly. The precision and scale would also not have been passed correctly 
to the ODBC driver. This problem has now been fixed.


=================(Build #3466  - Engineering Case #323109)=================

If the debugger in Sybase Central was used to debug some database object, 
the server would have crashed when Sybase Central disconnected. This 
has been fixed.


=================(Build #3467  - Engineering Case #322770)=================

Some single-byte to single-byte translations would have done an incorrect 
substitution of the character 0x1A. For example, if a client using the 
cp1252 character set connected to a server using the ISO_1 collation 
and character set, extended chars common to ISO_1 and cp1252 would have 
been mapped to 0x1A. This problem is now fixed.


=================(Build #3468  - Engineering Case #324035)=================

A CREATE VIEW statement executed inside a stored procedure could have 
failed after the first execution. The statement will now execute correctly. 
A workaround is to create the view using EXECUTE IMMEDIATE.


=================(Build #3469  - Engineering Case #323973)=================

A server crash at an inopportune moment could have resulted in a corrupt 
database. This was more likely to have occurred with 9.x servers, and 
with 8.x servers running 8.x databases. It was unlikely to have occurred 
with 8.x and earlier servers when running against 7.x or earlier databases. 
This has been fixed.


=================(Build #3470  - Engineering Case #322453)=================

When a server with the Quiet Mode command line option (-q) was started 
as a Windows service that was allowed to interact with the desktop, 
any MESSAGE statemnts executed by the server caused the server window 
to be enabled.


=================(Build #3470  - Engineering Case #324348)=================

If a stored procedure contained remote queries, and the server encountered 
an error while building a cursor on those remote queries, then the server 
would have leaked memory. This has now been fixed.




=================(Build #3474  - Engineering Case #322442)=================

After a system reboot, user login or Explorer restart, the system tray 
icon of the database engine did not appear immediately. The first checkpoint 
or message to the server window would have caused the system tray icon 
to be displayed. This has been fixed, now the system tray icon is visible 
immediately.


=================(Build #3476  - Engineering Case #325741)=================

When the server was running on NetWare, if a string containing the '%' 
character was displayed on the server console (through the MESSAGE statement 
or request-level logging), the server could have displayed garbage or 
crashed. This has been fixed.


=================(Build #3477  - Engineering Case #308123)=================

If a view contained a UNION and was defined with a SELECT *, which was 
no longer valid as columns had been added to the tables referenced in 
the view, a query referencing that view could have caused a server hang. 
This has been fixed.




=================(Build #3478  - Engineering Case #309290)=================

An UPDATE statement of the form:

	update Employee  e 

	set e.emp_fname ('x')

where: 

	- the column to be updated was qualified with a correlation name

	- the "=" was missing

	- the expression being assigned was enclosed in parentheses

would result in a server crash. An error (Set clause for column 'a' 
used incorrectly) will now be reported.


=================(Build #3478  - Engineering Case #327225)=================

A query containing a UNION with a very large number of branches would 
have caused an assertion failure: "101505 - Memory allocation size too 
large". Now, the server no longer asserts, but instead the statement 
fails with an error indicating that a syntactic limit has been reached.


=================(Build #3479  - Engineering Case #327304)=================

If a user's password was changed to something containing a semi-colon 
(';'), connecting as that user was no longer possible, except from a 
another connection by a user with dba authority and not specifying a 
password. This has been fixed - the GRANT statement will now fail if 
the password contains a semi-colon.




=================(Build #3484  - Engineering Case #328354)=================

Prior to this fix, if the server added an index entry to an upgraded 
version 4 database, the index could have become corrupted.  For this 
corruption to occur, the value being inserted must not have been fully 
hashed (i.e. was longer than ~9 bytes). The symptom of the corruption 
was that querying the index for entries with a particular value returned 
an incorrect (usually fewer) number of rows. Range searches would have 
produced the expected number of rows. While the server has been fixed 
and the database will no longer be corrupted, Validate Table/Index will 
not catch any existing corruption. A work around would be to unload/reload 
to a later format database.


=================(Build #3484  - Engineering Case #328482)=================

If a table had a self-referencing foreign key and a LOAD TABLE operation 
on the table failed, the server would have failed with assertion 104002. 
This has been fixed


=================(Build #3484  - Engineering Case #328881)=================

If a DTC transaction was unenlisted while another DTC action was running, 
the server may have crashed. This would have been seen if an application 
ran concurrent DTC actions from multiple threads against the same connection. 
This problem has been fixed.


=================(Build #3484  - Engineering Case #329327)=================

If a server running on a Unix platform, was started as a daemon (i.e. 
with -ud), then making remote ODBC connections would have failed with 
error -656. This problem has been fixed.


=================(Build #3484  - Engineering Case #329521)=================

Attempting to insert a NULL value into a NUMERIC or DECIMAL column with 
"default autoincrement" could have led to a server crash.  The NULL 
value must have been cast to NUMERIC.  The following statement would 
have caused the crash:

      INSERT INTO T( x ) SELECT CAST( NULL AS NUMERIC )

For other column types, there was a possibility that the value returned 
from @@identity would be incorrect after inserting a NULL value. The 
correct value should be 0. This problem is now fixed.


=================(Build #3484  - Engineering Case #330127)=================

If a TDS (jConnect or Open Client) application made a request which 
returned a large amount of data (several Kb or more), and then sent 
a cancel request, the server could have gone to 100% CPU usage, attempting 
to send the cancel response.  While the server was attempting to send 
the cancel response, checkpoints or DDL would have caused all connections 
to hang.  Fetching a large result set with older versions of jConnect, 
could hang after running out of memory and sending a cancel request, 
causing the engine to hang indefinitely.  (Current JConnect EBFs may 
get an java.lang.ArrayIndexOutOfBoundsException instead of hanging.)



Now the server will no longer go to 100% CPU usage or cause all connections 
to hang when processing a TDS cancel.  If the server is unable to send 
the TDS cancel response for 60 seconds, it will drop the connection.




=================(Build #3486  - Engineering Case #325453)=================

It was possible for the round() function to have returned an incorrect 
result. The number returned may have been truncated, instead of rounded, 
if the digit to be rounded was a 5.  For example, 69.345 may have been 
'rounded' to 69.34. This has been fixed.




=================(Build #3489  - Engineering Case #331462)=================

Attempting to insert a long string in a multi-byte character set into 
a proxy table, could have resulted in the data being corrupted. This 
problem has been fixed.


=================(Build #3490  - Engineering Case #329570)=================

If a database's collation was 1254TRK , built-in functions could not 
be referenced if the function name was in upper case. This has been 
fixed.


=================(Build #3490  - Engineering Case #331147)=================

If a table had a computed column with an expression that referenced 
a user defined function, and had a foreign key defined, then an unload/reload 
operation would have failed. The failure would have occurred during 
the reload phase, creating the foreign key. This was due to the values 
of the computed column being recalculated during the creation of the 
foreign key, but at this stage of the reload, the user defined function 
had not yet been defined. This has been fixed by not recalculating computer 
column values when creating foreign keys.


=================(Build #3496  - Engineering Case #333142)=================

If a statement encountered an error (e.g. row locked, foreign key violation) 
while running with the Chained option set to 'OFF' (i.e. INSERTs, UPDATEs 
and DELETEs are automatically commited), then any locks acquired by 
that statement would not have been released when the statement completed. 
This could result in other connections being blocked unnecessarily. 
This has been fixed.


=================(Build #3498  - Engineering Case #323180)=================

A query with a large number of UNIONs or one that referenced a large 
number of distinct tables could have crashed the server. These types 
of queries will now return -890 "Statement size or complexity exceeds 
server limits".


=================(Build #3502  - Engineering Case #316870)=================

When a commit was done by a transaction while it is in the middle of 
a page level backup, it could have caused database corruption if a subsequent 
operation that required a page level undo (ie ALTER TABLE or LOAD TABLE 
on a table with existing data) failed and a checkpoint was done while 
the operation was in progress. This is now fixed.



Note that this is not likely to affect most users, since the existing 
backup tools do not exhibit this behaviour, but it may have occurred 
with a user written backup tool using the page level backup api.


=================(Build #3503  - Engineering Case #338425)=================

When determining an optimal cache size, the size chosen never exceeded 
the sum of the sizes of all open database and temporary files. Now, 
it will not exceed the sum of the sizes of all open database and temporary 
files, plus the size of the main heap.


=================(Build #3503  - Engineering Case #338456)=================

If an initial cache size is set (with "-c"), but no minimum cache size 
was set (with "-cl"), then the minimum cache size will now be set equal 
to the initial cache size.


=================(Build #3507  - Engineering Case #340916)=================

Dynamic cache resizing did not work on AIX 5.x platforms.  This has 
been corrected.




=================(Build #3508  - Engineering Case #279739)=================

Under the following conditions, the next available value for a column 
having a GLOBAL AUTOINCREMENT default value would not have been set 
correctly:

- Database recovery was performed at startup.

- The table containing the column was referenced in the transaction 
log during recovery.

- An INSERT into the table with no value specified for the GLOBAL AUTOINCREMENT 
column was attempted before shutting down the database.




=================(Build #3509  - Engineering Case #341814)=================

Creating a foreign key with a different hash size than the primary key 
it referenced, may have returned the error "No primary key for foreign 
key..." if the foreign key table already contained rows. This has been 
fixed


=================(Build #3510  - Engineering Case #338114)=================

Attempting to create a proxy table to a SQL Server remote server, would 
have failed with a "cannot obtain column information" error, if the 
database on the remote server had a space in it's name. This problem 
has now been fixed, but to make use of existing remote servers, the 
capability list must be rebuilt. The easiest method of rebuilding the 
capability list is to change the remote server class, then change it 
back. The following two statements will rebuild the capability list 
for this situation:



ALTER SERVER "name of mss remote server" CLASS 'ODBC';

ALTER SERVER "name of mss remote server" CLASS 'MSSODBC';


=================(Build #3510  - Engineering Case #340815)=================

Remote Data Access could have caused a server crash, if a large data 
value was provided. This has been fixed.


=================(Build #3510  - Engineering Case #340966)=================

An error in common code dealing with string parameters to built-in functions 
could have caused a server crash. This has now been corrected.


=================(Build #3510  - Engineering Case #341082)=================

Creating a proxy table may have caused a server crash, if the server 
name in the location clause was very long. This has now been corrected.


=================(Build #3510  - Engineering Case #341100)=================

If a FORWARD TO statement was executed, and the server name specified 
in the statement was very long, there was a possibility it would have 
caused a server crash. This is now fixed.




=================(Build #3510  - Engineering Case #343155)=================

A LOAD TABLE statement, executed as part of a stored procedure or an 
event, could have crashed the server when run a second time. This has 
been fixed.


=================(Build #3511  - Engineering Case #344761)=================

A java class, running in the server's VM, that attempted to read more 
columns from a resultset than were available, would fail with an exception. 
This is expected, but when the class terminated, the server would fail 
with the assertion "Cursor not being unlocked". This is now fixed, the 
assertion will no longer occur.


=================(Build #3513  - Engineering Case #344838)=================

Performance of the 8.0.2 server when run on Solaris 9 or 10 machines, 
was poor compared to the server running on Solaris 6, 7 or 8, especially

with large databases.  The problem was due to dynamic cache sizing 
not being enabled for servers running on  Solaris 9 or 10, thus the 
server never grew the cache to accomodate large databases. This has 
now been fixed, dynamic cache sizing is now enabled when the server 
is run on Solaris 9 or 10. A work around is to start the server with 
a sufficiently large cache.


=================(Build #3513  - Engineering Case #346145)=================

The server allowed, in rare circumstances, a database user with limited 
permissions to manage to exceed those permissions. This is now fixed.


=================(Build #3513  - Engineering Case #346149)=================

By default, the maximun number of connections to a server running on 
NetWare is approximately 108. The actual number depends on the number 
of network cards in the machine, and the number of IP addresses the 
ASA server is listening on. The "connections" TCP parameter can be used 
to change this limit. Once the server reached this limit, the next connection 
attempt would have caused the NetWare server to abend. This has been 
fixed, a connection attempt exceeding the limit will now fail with an 
error.


=================(Build #3513  - Engineering Case #346604)=================

Calling the system procedure sa_locks, could have caused a deadlock 
in the server. This problem was more likely to occur on multiprocessor 
and unix systems.


=================(Build #3513  - Engineering Case #348488)=================

When running on Windoes 9x/ME, the server would pause each tcpip connection 
for 1 second before succeeding. This has been fixed.


=================(Build #3514  - Engineering Case #346886)=================

If a query contained an expression in the select list using the built-in 
finction NUMBER(*), (such as NUMBER(*)+1000) or a non-deterministic 
function, then a wrong answer could have been returned if the query 
also contained an EXISTS style predicate (or ANY, ALL or IN), where 
the predicate was re-written as a join with a DISTINCT operation. The 
wrong answer could have contained more rows than expected or an incorrect 
value for the expression derived from the NUMBER(*) or a non-deterministic 
function.



For example, the following query demonstrates the problem, depending 
on the plan selected by the query optimizer:



	select R1.row_num, rand(), number(*)+100

	from   rowgenerator R1

	where exists (	select * from rowgenerator R2 

			where R2.row_num <> R1.row_num 

			and R2.row_num <= 2)



This problem has been fixed.




=================(Build #3514  - Engineering Case #347503)=================

Calling the  LEFT() function on a MultiByte Character Set string, could 
have caused a server hang. This has been fixed.




=================(Build #3515  - Engineering Case #348670)=================

When server-side translation was enabled (i.e. server command line option 
-ct), the server could have hung when the string sent by the client 
application did not conform to the connection character set. For example, 
reading a SJIS file into dbisqlc, running on a machine with ANSI codepage 
1252, without specifying client charset to be SJIS. This is now fixed.


=================(Build #3517  - Engineering Case #352032)=================

On Linux platforms, the server's UDP Listener (used by clients to connect 
to the server and by dblocate) could have stopped with the following 
-z output:



TCP/IP Link, error on UDP Listener rc=4, er=111, ...



The UDP listener will no longer stop if it receives this error (111 
is ECONNREFUSED). The -z message will continue to be displayed though.


=================(Build #3517  - Engineering Case #352129)=================

If a Remote Server did not support correlation names, then there was 
a chance the Remote Server would have encountered a syntax when an UPDATE 
statement involving remote tables was executed. This problem has now 
been fixed.


=================(Build #3518  - Engineering Case #288657)=================

When run on Windows platforms, the server could have hung during start 
up, if multiple servers were starting at the same time, with the same 
name. The server will no longer hang, only one engine with the same 
name will start successfully.


=================(Build #3518  - Engineering Case #352434)=================

If a user defined function was referenced in a SELECT statement and 
the function contained a call to the STUFF() function that returned 
an empty string, the server would have crashed. This has been fixed.


=================(Build #3520  - Engineering Case #353567)=================

If a connection (or several connections) made multiple requests to a 
remote server which ran simultaneously, then it was possible that the 
local server would have crashed. This problem has now been fixed.



Note, that the remote requests must be simultaneous. A connection (or 
several connections) that make multiple remote requests that are serialized, 
will not cause a crash.


=================(Build #3524  - Engineering Case #356216)=================

The creation or execution of a stored procedure may have caused a server 
crash if the parameter list contained the special values SQLCODE or 
SQLSTATE, and in the procedure body a Transact-SQL variable was declared 
(ie variables that start with @). This has nowbeen fixed.


=================(Build #3527  - Engineering Case #360694)=================

The server could have deadlocked, and appear to be hung, if a transaction 
yielded to a checkpoint (by context switching, waiting for a lock or 
waiting for network I/O) after rolling back to a savepoint. This has 
been fixed.


=================(Build #3528  - Engineering Case #362220)=================

If another transaction attempted to query or modify a table while a 
the fast form of TRUNCATE TABLE was executing on the same table, the 
server could have failed an assertion, and in some cases, possibly corrupted 
the database.  This was not likely to occur on single processor Windows 
platforms. This problem has been corrected.


=================(Build #3529  - Engineering Case #357683)=================

When an application closed a cursor, the server was not freeing the 
cursor's resources before dropping the associated prepared statement 
or when the connection ended. This caused problems for applications 
that open many cursors on the same prepared statement. These applications 
would get errors when attempting to open a cursor, such as "Resource 
governor for 'cursors' exceeded", if the option MAX_CURSOR_COUNT was 
not set, or "Cursor not open". Now the cursor's resources are freed 
when a cursor is closed.




=================(Build #3529  - Engineering Case #363708)=================

The fix for Engineering Case 338114 was meant to handle creation of 
proxy tables to non-ASA remotes when the database name contained a space, 
or any other character that required quoting. Unfortunately, that fix 
introduced a bug which resulted in proxy tables not being created with 
certain remotes, under certain conditions, which vary significantly. 
This problem has been corrected.


=================(Build #3532  - Engineering Case #365147)=================

When using the -m command line option (truncate transaction log after 
checkpoint), if a transaction log file was being actively defragmented 
or virus scanned at the time a checkpoint occurred, then the server 
could have failed with assertion 101201. The operating system will not 
allow the file to be recreated until the virus scan or defragmentation 
has completed. As a result, the server will now wait and retry the operation 
several times. A workaround would be to remove the transaction log file 
from the list of files that are actively scanned or defragmented.


=================(Build #3533  - Engineering Case #368127)=================

If a remote server was created using one of the Remote Data Access ODBC 
classes, opening a cursor on a proxy tables from that server would have 
leaked about 8 bytes of memory for each remote column. Memory allocated 
at cursor open time, to hold the indicator for each column, is now freed 
when the cursor is closed.




=================(Build #3534  - Engineering Case #368616)=================

Complex grouped queries, using aliases in subqueries, may have returned 
incorrect results. This has been fixed.




=================(Build #3534  - Engineering Case #370049)=================

If for a query, the  publications or constraints were built for a table 
whose correlation name was different than the table name, the error 
"-142 - Correlation name ... not found" was incorrectly reported. This 
has been fixed.



For example:



CREATE TABLE P(

	one	CHAR(4) NOT NULL,

	two	INTEGER NOT NULL PRIMARY KEY

);



CREATE TABLE F(

	two INTEGER NOT NULL REFERENCES P(two),

);



CREATE TABLE R(

	X INTEGER NOT NULL,

	Y integer not NULL

);



CREATE PUBLICATION "Pub_F"

(

	TABLE F WHERE two = any(select R.X from  R where R.Y >  9999 )

);





SELECT PP.two  FROM  P as PP  KEY JOIN F as FF where PP.two < 100



Would have reported Error -142:  "Correlation name FF' not found"


=================(Build #3535  - Engineering Case #373462)=================

If a CREATE TABLE statement failed, for example because of duplicate 
column names, and no commit or rollback was executed so far, the next 
attempt to execute a CREATE TABLE statement, on any connection, would 
have crashed the server or cause an assertion failure 102801. This has 
now been fixed.




                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **  Sybase Central Plug-in  **                      
                      ******************************                      

=================(Build #2050  - Engineering Case #254866)=================

The dropdown combobox in the datatype column of the Table Editor, did 
not have the current item selected in it.  As a consequence, selecting 
the first item would have been ignored, as the combobox already thinks 
item one is selected even if it differs from the item in the textfield.  
This has been fixed.


=================(Build #2613  - Engineering Case #255902)=================

The Unload and Extract wizards would have always failed, if the server 
was running on a different machine.


=================(Build #2624  - Engineering Case #256552)=================

Trigger deletions and comment changes are not specifying the owner when 
making the change.


=================(Build #2636  - Engineering Case #235145)=================

When calculating the number of rows in a table for the properties dialog, 
the table name was not prefixed with the creator, thereby possibly causing 
it to calculate the wrong number of rows.



=================(Build #2669  - Engineering Case #259564)=================

When closing the procedure editor after making changes that were not 
saved, the editor would prompt the user to save their changes.  If the 
save did not occur because the procedure contained a syntax error, no 
save was made and the editor closed.  Now the user is prompted and the 
edior remains open.


=================(Build #2749  - Engineering Case #262430)=================

Adding a statement to an Ultralite project in Sybase Central would have 
generated an error, if parameters and quotes were used in the statement. 
For example, the statement:

select * from "Transaction" where TransactionTypeIndicator=?

would case the error: "ASA Error -143: Column '?' not found". This 
has now been fixed.




=================(Build #3333  - Engineering Case #268909)=================

When using the Table Copy feature to create an new table, the column 
order of the new table may have been different than that of the original 
table. This ahs been fixed.


=================(Build #3338  - Engineering Case #276545)=================

In the database creation wizard, if a database was created with a non-existant 
collation label, an error dialog opened and could not be dismissed with 
the 'Ok' button.  This has been fixed.


=================(Build #3475  - Engineering Case #304262)=================

If more than about 200 characters were specified in the parameters text 
area of a service's property sheet, then the next time the property 
sheet was opened, the parameters would be empty. This has been fixed.


=================(Build #3497  - Engineering Case #320022)=================

Breakpoints could not be set in procedures or triggers owned by the 
user dbo.  This has now been fixed so that dbo procedures and triggers 
created by the user are now debuggable. System procedures and triggers 
owned by dbo are still not available.




                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **        Utilities         **                      
                      ******************************                      

=================(Build #2606  - Engineering Case #255508)=================

Previously, dbisql would report a syntax error if the SET CONNECTION 
statement had the connection name as a single quoted string, e.g.

        SET CONNECTION 'con3'

Now, ISQL accepts the above statement for backwards compatibility with 
DBISQL 6.0.4

Also: If DBISQL was started with the '-x' command line switch (meaning 
"check syntax"), the SET CONNECTION statement had been executed anyway. 
Now, the syntax of the statement is checked without the statement being 
executed. 



=================(Build #2607  - Engineering Case #242065)=================

When running dbunload, (or UNLOAD TABLE in isql), an error would have 
occurred when the unloading data file reached 2GB. Also, attempting 
to reloaded a database with a data file of 2GB or more, would also have 
failed.



=================(Build #2607  - Engineering Case #255438)=================

If both the -c and name parameters were used with dbstop, the name parameter 
was ignored. It now overrides any engine name specified by the -c parameter.


=================(Build #2623  - Engineering Case #240834)=================

If the old logs directory specified for dbunload -ar was the same as 
the current log location, a user would receive the error "Can't use 
log file since the database file has been used more recently".
The problem is fixed by renaming the log file in the old logs directory 
so that a new one is created when the engine is run.  DO NOT delete 
the old log file, as this will break replication.



=================(Build #2624  - Engineering Case #238058)=================

If a customer has added custom options to the database, a rebuild would 
fail with the error "Invalid option <blah> - no PUBLIC setting exists" 
since the user options are set before the PUBLIC options in the reload.sql 
file.
To fix the problem, editing of the reload.sql is required.


=================(Build #2624  - Engineering Case #256771)=================

dbstop using the old-style connection parameters, (ie. "dbstop -c dba,sql") 
would have failed.


=================(Build #2624  - Engineering Case #257013)=================

Using dbunload -an on a Java-disabled database would create a Java-enabled 
database.


=================(Build #2626  - Engineering Case #256867)=================

Upgrading from 6.0.x to 7.0.x or from 7.0.0 to a later 7.0 version made 
the UltraLite stored procedures, (to add/remove projects and statements), 
unusable. This has now been fixed.



=================(Build #2631  - Engineering Case #257398)=================

Java dbisql was displaying DOUBLE values with 3, (or fewer), fractional 
digits. Now all of the digits are displayed. 
DOUBLE values had been read from the result set using the wrong API 
and were being truncated as a result.



=================(Build #2632  - Engineering Case #257405)=================

When backing up a database created with version 7.0.x or earlier, if 
the transaction log is required to be truncated or renamed, the backup 
will wait until there are no uncommitted transactions before truncating 
or renaming the log. This is the expected behavior, however, after the 
server returned a message to dbbackup that there were still uncommitted 
transactions, dbbackup would immediately issue another request to the 
engine. This would be repeated again and again and causing both the 
engine and the backup utility to be very busy. Now a 100 millisec wait 
has been added between requests. Note that this problem doesn't exist 
on a database created with version 8.0 or later of Adaptive Server Anywhere 
because if the backup instruction requires the transaction log to be 
truncated or renamed, uncommitted transactions are carried forward to 
the new transaction log.


=================(Build #2638  - Engineering Case #257989)=================

Running dbunload with one of the -an/ar/ac switch could fail when used 
in conjunction with dbsrv7.  The error received would be "Request to 
start/stop database denied" unless the server was started with the -gd 
all switch.


=================(Build #2639  - Engineering Case #242783)=================

Reloading a database, unloaded using dbunload,  that had a dbspace with 
a name that required double-quotes, (ie  contained blanks or special 
characters), would fail. This has now been fixed.


=================(Build #2640  - Engineering Case #240554)=================

dbunload -ar/an/ac could sometimes cause both the engine and dbunload 
to hang during the reload phase if a cache resize occurred.  Disabling 
cache autosizing would avoid the problem



=================(Build #2640  - Engineering Case #257660)=================

The "Lookup Procedure Name" dialog now includes a "Show owner names" 
check box. When checked, the dialog prefixes procedure names with the 
name of the database user that owns it.




=================(Build #2641  - Engineering Case #258329)=================

When executing a START DATABASE statement with the ON clause, if the 
engine named in the ON clause was the same as the engine to which you 
were currently connected, the statement would fail with a message complaining 
that the "login failed". The same fix has been made to the STOP DATABASE 
statement.


=================(Build #2645  - Engineering Case #239522)=================

Running a select stmt using dbisql with -nogui switch would cause a 
core dump on Solaris. One work around was to execute the batch file 
generated by using the -batch switch.


=================(Build #2645  - Engineering Case #258002)=================

The -d command line option to set the command delimiter was missing 
from the usage text. It had been accidentally omitted, even though the 
option has been there all along. Also, the usage text could appear, 
in some circumstances, without an explanation beside the various options.


=================(Build #2659  - Engineering Case #257967)=================

If the -q command line switch was used, errors in script files were 
not being reported. Now they are.



=================(Build #2663  - Engineering Case #258947)=================

An attempt to display a text value which started with the string "<html>" 
would be processed as HTML instead of being displayed as-is. For example,
	
        SELECT '<html>Hello</html>'
	
would appear as "Hello" instead of "<html>Hello</html>". Now the value 
is displayed as-is, without being interpreted as HTML. If the HTML was 
poorly formed or incomplete, an internal exception would be thrown. 
This has now been fixed.


=================(Build #2666  - Engineering Case #256869)=================

ISQL would have throw an exception if it had to display a message that 
started with a newline, (\n), character. For example, the following 
statement would cause a crash:

            MESSAGE '\nHello' TO CLIENT

A workaround is to insert any character (e.g. a blank) before the newline 
character.


=================(Build #2668  - Engineering Case #239686)=================

Java dbisql sets a number of connection options for backwards compatibility 
with dbisqlc. It was doing so in a way that ignored the settings in 
the database, (it was using the default values only). For example, every 
time you started dbisqlL, the DATE_ORDER option was being reset to "YMD", 
regardless of a per-user or PUBLIC override. Now the option value stored 
in the database, (if one exists), is used.



=================(Build #2668  - Engineering Case #259043)=================

Cancelling an OUTPUT statement that was exporting a very large result 
set would appear to cancel the statement, but the database server and 
client would continue to be very busy for a length of time. This problem 
has been fixed; the OUTPUT statement can now be interrupted without 
issue.



=================(Build #2671  - Engineering Case #260159)=================

A command such as:
dbspawn dbsrv7  -n ABCD  "D:\Program files\ABCD6\server\data\abcd.db" 

would return dbspawn error -84 'invalid database'.  This would only 
occur when any of the command line arguments contained spaces. The length 
of the command line was not an issue. The code that allocated space 
for a buffer in which to build the command line, accounted for the intervening 
spaces, but not for the addition of extra quotes.


=================(Build #2675  - Engineering Case #259196)=================

If a procedure, similar to the following, was called it could not have 
been interrupted.
	create table t(pk int primary key default autoincrement, c1 int);
	create procedure testproc() as
	while 1=1
	    insert into t (c1) values(100)
This was due to the procedure useing the Transact-SQL dialect and the 
assumption that it would handle errors itself, which included the SQLSTATE_INTERRUPTED 
error. This error will now cause the procedure to be cancelled.

A workaround is to write the procedure using the Watcom-SQL dialect:
	create procedure testproc() 
	begin
	    while 1=1 loop
	        insert into t (c1) values(100)
	    end loop
	end



=================(Build #2681  - Engineering Case #256875)=================

Errors encountered while executing an INPUT INTO ... PROMPT statement 
were suppressed. Now they are reported to the user.
Note, a previous fix for this problem introduced a bug that prevented 
ISQL from functioning correctly if the default JDBC environment was 
configured to set the QUOTED_IDENTIFIER option to OFF. The code in ISQL 
which sets the option ON had been broken by this earlier fix. You can 
tell if you're being affected by the problem by starting ISQL, and issuing 
the SET command. If you see only 20 options, you have the bug. This 
bug affects only connections made with jConnect, and only those EBFs 
created between August 15, 2001 and October 9, 



=================(Build #2687  - Engineering Case #260843)=================

DBISQL would block during an OUTPUT statement if the results being exported 
included a table which was locked by another connection. The OUTPUT 
statement would execute once the other connection had executed a COMMIT. 
Now the OUTPUT statement completes, regardless of whether a COMMIT is 
done in the other connection or not.



=================(Build #2695  - Engineering Case #259083)=================

If a file processed by the READ command did not end with a newline ('\n'), 
the last character in the file would be ignored, which would often have 
caused a syntax error. Now the file is read in full.


=================(Build #2701  - Engineering Case #260058)=================

When attempting to execute some poorly formed SQL statement, ISQL would 
not report an error, causing subsequent valid SQL statements to fail 
with a syntax error. The error message would be prefixed by the bogus 
SQL statement executed previously. This has now been fixed.
	
"Poorly formed SQL statements" include the following:
--  A number
--  A sequence of identifiers that did not start with a word
--  Some punctuation


=================(Build #2701  - Engineering Case #262979)=================

DBISQL would throw an exception when importing an Excel spreadsheet, 
if the first row, (assumed to be column names), includes a cell type 
other than a string, (an integer, for example). This has been fixed.


=================(Build #2710  - Engineering Case #264277)=================

Comments in database objects containing the "go" statement would not 
be ignored when running dbunload -an, -ar or -ac.  This would have resulted 
in a syntax error during the rebuild phase. 
Eg.  The following stored procedure would generate the error:
create procedure /*
Here is a comment
go
*/
DBA.TProc()
begin
  select * from employee
end


=================(Build #2713  - Engineering Case #263113)=================

A version 3.2 or 4.0 database that had been previously upgraded, that 
had more than the default users, would get the following error if upgraded 
again to version 6 or 7: "SQL error (-110) -- Item 'sp_password' already 
exists"
This has been fixed.


=================(Build #2716  - Engineering Case #263123)=================

The upgrade of a version 5.5.x database would have failed if the database 
did not have the remote message type FTP in table SYSREMOTETYPE and 
a user had added a remote message type other than FTP that was assigned 
type id 4. The upgrade error was:
"SQL error (-193) -- Primary key for table 'SYSREMOTETYPE' is not unique"
This has been fixed.


=================(Build #2716  - Engineering Case #264516)=================

When importing a delimited ASCII file using a field delimiter whose 
ASCII code was between 0x09 and 0x0D, or between 0x1C and 0x1F (inclusive), 
if the file contained occurrences of consecutive separators (indicating 
an empty or null value), DBISQL would ignore the null value and would 
shift the remaining column values left one column. This could prevent 
the data from being imported at all, or could store inappropriate values 
in the table.

This problem has been fixed, but a workaround is to change the delimiter 
to a character which is not in the range 0x09-0x0D or 0x1C-0x1F.


=================(Build #2722  - Engineering Case #265726)=================

The classic version of dbisql was ignoring the DBS connection parameter. 
The DBS parameter is now respected.


=================(Build #2728  - Engineering Case #265985)=================

In the "Lookup Table Name" dialog, unchecking the "Tables", "System 
Tables" and "Views" boxes would not have cleared the list of tables. 
Now it is.



=================(Build #2728  - Engineering Case #266081)=================

If a database had no user called "dba", when the schema for the database 
was unloaded using dbunload, a revoke connect from "DBA" was added to 
the end of the reload.sql. Before this statement, a connect to the actual 
dba user of the database was done using a deprecated connect call which 
is no longer supported in DBISQL. Now dbunload will unload proper connect 
statements in order to be able to revoke connect privileges from the 
dba user.



=================(Build #2729  - Engineering Case #257098)=================

If a command line tool, like dblog, could not load or initialize the 
store dll dbwtspX.dll, then it the following incorrect error message 
was displayed:
   "database file created with a newer version of the software"
Now it correctly displays the message:
   "Could not find or load the physical store DLL."   or
   "Could not find or execute the physical store DLL entry point."


=================(Build #2735  - Engineering Case #266723)=================

An INPUT statement which contained one or more quoted column names would 
have failed with an error message similar to:

            The data on line 1 could not be imported.
            ASA Error -131: Syntax error near 'name' on line 1

This has been fixed.


=================(Build #2736  - Engineering Case #266881)=================

Braces in .SQL files, (ie {} ), are used to delimit parameters, but 
they may also be literal brace characters. DBISQL was not substituting 
parameter values if they were themselves enclosed in braces. For example, 
suppose the value of the parameter "myParm" was the word "Hello". DBISQL 
had not been expanding "{myParm}" in the following statement. Now it 
does.

	MESSAGE '{-{myParm}-}'

The output from this statement should be "{-Hello-}" rather than "{-{myParm}-}".


=================(Build #2749  - Engineering Case #268390)=================

If many ODBC Data Sources, (DSNs), exist on a machine, dbdsn -l may 
not have listed them all. The number of DSNs that were listed depended 
on the length of the names -- if the total length of all the names was 
greater than about 1000 characters, truncation may have occurred. With 
this fix, all DSNs will be listed. (Note that for 8.0, only ASA DSNs 
are listed.)



=================(Build #2777  - Engineering Case #270651)=================

If a database did not contain a user called "DBA" and was a replicating 
database, it was possible to get a primary key violation on the SYS.SYSUSERPERM 
table, when rebuilding the database from a reload.sql generated by dbxtract 
or dbunload. This has been fixed.


=================(Build #2785  - Engineering Case #255548)=================

The utility dbdsn will now suppress the data source and connect keyword 
titles when the -qq option is added to the -l and -cl command lines 
(respectively).

Example: "dbdsn -l -qq" will list just the user DSNs without any banner 
or titles.  This can be useful when using this tool as part of a script 
to get a list of user or system DSNs (i.e. the script does not need 
to detect and strip titles).


=================(Build #2785  - Engineering Case #266079)=================

The dbunload utility, when used with the -an or -ar switches, on databases 
created with versions 5.0.x or 5.5.0, would fail with the error: "SQL 
error: Invalid option 'ESCAPE_CHARACTER' -- no PUBLIC setting exists". 
This has been fixed.


=================(Build #2785  - Engineering Case #266220)=================

Starting DBISQL with a command line that included a filename that started 
with a forward slash, would have displayed the command line usage text 
for ISQL, and the file would not have been executed. If the file name 
did not start with a forward slash, it would have been executed by ISQL. 
This behavior was incorrect and now the file is always executed, even 
if it starts with a forward slash. This problem was most serious on 
non-Windows platforms such as Solaris and Linux where the forward slash 
is used as the directory separator character.


=================(Build #2785  - Engineering Case #268271)=================

ISQL was reporting a "Lexical error", when statements which contained 
unquoted Korean letters were executed. Now,  Korean characters are processed 
properly. A workaround for this problem was to enclose the text containing 
the Korean characters in quotation marks.


=================(Build #2785  - Engineering Case #270558)=================

The utility dbvalid,l and the DBValidate function, always returned the 
error  "N objects(s) were not validated because, e.g., validation for 
remote objects is not implemented.", if there was a proxy table in the 
database.
This has been corrected. Now they return the error  only if there was 
a table list specified containing a proxy table.


=================(Build #2786  - Engineering Case #271661)=================

Characters typed, after clicking on the "Advanced" tab of the "Connect" 
dialog,  would go into the "User" field on the "Identification" page. 
Now, the characters correctly go into the first field on the "Advanced" 
page.



=================(Build #2789  - Engineering Case #274993)=================

The following problems with using variants of the SET OPTION statement 
to change the command delimiter have been fixed:
 
1 - Using the TEMPORARY keyword and qualifing the option with a userid, 
that did not match what was expected by the database, would have caused 
the error "You cannot set a temporary option for another user." For  
example, if you logged in as "dba", the following statement would cause 
an error:

               SET TEMPORARY OPTION dba.command_delimiter=';'

 but the following would not:

               SET TEMPORARY OPTION DBA.command_delimiter=';'


2 - Setting the command delimiter to two semi-colons caused an erroneous 
syntax error if the statement itself was terminated by a semicolon. 

               SET TEMPORARY OPTION command_delimiter=';;';
               MESSAGE 'Working' TO CLIENT



=================(Build #2789  - Engineering Case #275143)=================

Running dbunload -ar could have given  an error "Table rs_lastcommit 
already exists", causing the unload/reload to fail. This problem, which 
is now fixed, should only have affected databases that were involved 
in replication.


=================(Build #2789  - Engineering Case #277733)=================

If Japanese double-width @, $, #, or _ characters were used in an unquoted 
identifier, DBISQL would have reported a "Lexical error". Now, DBISQL 
accepts these characters as valid parts of an identifier. The Unicode 
values for these characters are as follows:

Character        Unicode Value
---------------  -------------	
Double-width #   \uFF03
Double-width $   \uFF04
Double-width @   \uFF20
Double-width _   \uFF3F



=================(Build #3270  - Engineering Case #269440)=================

Leading and trailing blanks were being inadvertently stripped from character 
values in files created using the OUTPUT statement. Now, they are preserved.



=================(Build #3293  - Engineering Case #269810)=================

If a failure occured when attempting to rename the active transaction 
log during a backup, a partial log file in the backup directory would 
not be erased after the failure. With this change the partial log is 
now erased.


=================(Build #3295  - Engineering Case #272498)=================

Attempting to execute a statement which contained mismatched "/* ... 
*/" style comments, would have caused the statement to fail to execute, 
even after the mismatch was corrected. The problem corrected itself 
if the comments were removed or another ISQL window was opened. This 
problem has now been fixed.


=================(Build #3305  - Engineering Case #273486)=================

If dbbackup -x was run from a client machine and a mirror log existed 
for the database being backed up, then the renamed mirror log was not 
being removed. This is now fixed.


=================(Build #3317  - Engineering Case #258645)=================

If the full path to the active transaction log, including the file name, 
exceeded 70 characters, then there were two
problems.  First, dbbackup -x would have failed to delete the renamed 
transaction log. Second, dbbackup -r -n would have used the wrong filename 
in the backup directory when renaming the recently backed up transaction 
log to match the renamed log.


=================(Build #3333  - Engineering Case #264111)=================

The ability to specify destination sets to be included in the output 
of the dbtran utility, (-id label,... command-line option), was never 
implemented, so the option has been removed from the usage message.


=================(Build #3335  - Engineering Case #279139)=================

The ASA administration tools, (Sybase Central, dbisql, etc.) had problems 
connecting to UTF8 databases which contained extended (non-ASCII) characters 
in the database name. In version 7.0.2 and later, the name of the database 
was not being displayed in the dbisql title bar. For version 8.0.0 and 
later, it was not possible to connect to the database at all. These 
problems occurred only if connected to the database using jConnect. 
While these problems are now fixed, a work around would be using the 
JDBC-ODBC bridge.




=================(Build #3336  - Engineering Case #279112)=================

The dbversion utility, included with ASA for Unix platforms, when used 
with the -i command-line option, will search the current ASA installation 
directory, (defined by setting $ASANY), and will generate a report on 
all of the installed ASA files, including any version mismatches that 
may be found. If all the ASA files were copied into a single directory, 
(such as when ASA is embedded in an application), the "dbversion -i" 
command would not report the version of the ASA executables and libraries.  
This change fixes this problem.


=================(Build #3336  - Engineering Case #279629)=================

When importing data from a Lotus 1-2-3 spreadsheet, DBISQL was misinterpreting 
INTEGER records if the values they contained were negative. In that 
case, the imported value was always 32767 or 65535. This has been fixed.


=================(Build #3338  - Engineering Case #278696)=================

Escape sequences in quoted strings used in ISQL statements (e.g. INPUT, 
OUTPUT, START DATABASE ON), were not being supported. Since DBISQL, 
(prior to 7.0.0), supported escape sequences, it is possible that old 
script files would not be forward-compatible. Here are the details:

	

1. The START DATABASE ... ON statement did not allow escape sequences 
in the file name.  Now it does. This problem came to light because of 
a script which had doubled up the backslashes in the database filename. 
The double backslash was not being converted to a single backslash. 
This was OK on Windows NT, which coalesced the backslashes automatically, 
but when the script was run on Win9x, the START DATABASE statement failed 
due to the operating system not handling a file name containing two 
consecutive backslashes. Double backslahes are now converted to a single 
backslash.

	   

2. Incomplete hexadecimal escape sequences caused a syntax error. Now 
they are left as-is. For example, the string "\x41" is converted to 
"A", but "\x4K" is now interpreted as is (a 4 character sequence).

	   

3. If an escape character preceded a character other than a "n", "x", 
or "u", the escape character was silently ignored. Now it is left as 
is. 	


=================(Build #3339  - Engineering Case #279252)=================

The dbisqlc utility may have crashed if the connect string specified 
by the -c command-line option or entered in the connection dialog exceeded 
256 bytes. This has been fixed. Dbisqlc now uses buffers of 2048 bytes 
to store the connect string.


=================(Build #3340  - Engineering Case #279517)=================

The dbunload utility would have created an incorrect reload.sql file, 
if a column with a user defined datatype modified the DEFAULT value 
or CHECK constraint.

For example:



   CREATE DOMAIN speed_type  INT DEFAULT 50 CHECK (@a < 100);



   CREATE TABLE speed_violations (

          driver    char(40)

          speed     speed_type  );



   ALTER TABLE speed_violations MODIFY speed DEFAULT NULL;



   ALTER TABLE speed_violations MODIFY speed CHECK NULL;



The reload.sql would not have contained the ALTER TABLE statements 
to change the DEFAULT and the CHECK. This has been fixed.


=================(Build #3343  - Engineering Case #286167)=================

To correctly create views based on other views, the dbunload utility 
allows for specifying an iteration count, (-j option), for view creation 
statements. When using -j  the reload script checks to ensure that all 
views have been created. If a views has not been created the error message 
"Table 'viewname' not found" is displayed. When using dbunload -j with 
-ar, -ac or -an, the error message was:

     "Illegal cursor operation attempt"

which was not helpful. This has been fixed, dbunload will now display 
the error message

"Table 'viewname' not found" in these cases as well.


=================(Build #3344  - Engineering Case #287206)=================

when a custom collation was not in the script custom.sql, running dbinit 
-z or dbunload -ac/-an, only printed the message "Database creation 
failed" . Now the error message

is "Database creation failed Collation "name" not found".


=================(Build #3345  - Engineering Case #287939)=================

Using the INPUT command with INPUT_FORMATs of dBaseIII or FoxPro, would 
have failed if the files had extra padding bytes in their headers. These 
files can now be read.


=================(Build #3347  - Engineering Case #288325)=================

Running the dbunload utility with either of the -an or -ar options could 
have generated a syntax error. This would have occurred very rarely, 
only if "go" appeared as the last two characters in its 32K buffer.  
This is now fixed.




=================(Build #3351  - Engineering Case #289051)=================

Files created by the OUTPUT statement in FIXED format, were always terminated 
by "\n", even if the convention for the host operating system was "\r\n" 
(e.g. on Windows). This has been fixed.


=================(Build #3353  - Engineering Case #288362)=================

Overwriting an existing NT service may fail with the error messages:
     The specified service has been marked for deletion
     Error creating service "servicename".
This has been fixed.


=================(Build #3368  - Engineering Case #291409)=================

The dbisql option, Command_delimiter, could not be set to be a backslash 
("\"). When it was, dbisql would have reported a "Lexical error". This 
has been corrected and now a backslash can be used as a command delimiter 
without any error.


=================(Build #3373  - Engineering Case #294677)=================

This fix corrects a number of problems related to the handling of single-line 
comments by DBISQL:



1 - single-line comments which did not end in a carriage return, line 
feed, or carriage return/line feed pair would have been corrupted before 
being sent to the database server.



For example, running:

                dbisql -q -d1 "message 'X' -- testing"

would have printed

                message 'X' -----------

instead of 

                message 'X' -- Testing



2 - if the "d1" command line option was specified, and the file started 
with a comment, that comment was displayed twice on the console. Now 
the comment is displayed only once.



3 - comments appearing within CREATE PROCEDURE or CREATE FUNCTION statements 
were being sent to the database server followed by an additional blank 
line. This extra blank line has now been removed.


=================(Build #3374  - Engineering Case #295673)=================

Code in the reload.sql file to check if the maximum user_id in SYS.SYSTABLE 
in

the new database matched the maximum user_id in the old database (and 
executed a

RAISERROR 17001 if they were different) has been removed.


=================(Build #3376  - Engineering Case #295218)=================

Executing a SQL statement which contained double-width punctuation symbols 
could have caused DBISQL to report a "Lexical error". A common occurrence 
would have been when running the resulting RELOAD.SQL script after unloading 
a database with a multi-byte character set. The problem would have shown 
up if the database contained column names which contained double-width 
punctuation characters, (such as parentheses). This is now fixed so 
that such scripts can now be run without error.


=================(Build #3376  - Engineering Case #296282)=================

When run on Unix platforms, "dbunload -an" would have created a database 
whose log file had a name like "foo.db.log". This has been corrected.


=================(Build #3382  - Engineering Case #298383)=================

The Import Wizard could have reported an internal error if, on the second 
page, the "Use an existing table" radio button was selected and the 
name of a nonexistent table was entered, and then went on to the import 
the file. Now, users are not allowed to leave the second page if the 
table does not exist.




=================(Build #3382  - Engineering Case #298423)=================

The configured caret color used by the syntax highlighting editor in 
DBISQL was being ignored. This meant that the caret color would remain 
the system default caret color (the color you'd see used for the caret 
in Notepad, for example). Now the configured color is used.


=================(Build #3383  - Engineering Case #279969)=================

After rebuilding a Mobilink remote database using dbunload -ar, the 
DBMLSync utility would have returned the error:

     No off-line transaction log file found an on-line transaction 
log

     starts at offset ...

as dbunload did not save the current transaction log and reset the 
start and relative log offset in the rebuilt database. This has been 
fixed.


=================(Build #3383  - Engineering Case #299058)=================

Tilde (~) characters were not allowed in unquoted file names. Attempting 
to use them caused the error "Lexical error". This problem has been 
fixed.


=================(Build #3388  - Engineering Case #299030)=================

After rebuilding an ASA primary database using dbunload -ar,  running 
the Replication Agent would fail with the following error:

      Unable to find log offset ...

      Error processing log due to missing log(s)

Dbunload did not save the current transaction log and reset the start 
and relative log offset in the rebuilt database. This has been fixed.


=================(Build #3388  - Engineering Case #299754)=================

Executing a statement which contained two consecutive comments, and 
the first comment contained an unmatched quotation mark, and the second 
comment contained a question mark, would have caused dbisql to report 
the error: "JZ0SA: Prepared Statement: Input parameter not set, index: 
0".



For example, the statement below would not have executed:



    CREATE PROCEDURE test AS

    BEGIN

        -- "a 

        -- ?

    END

            

This problem, which is related to issue 217915, has been fixed.


=================(Build #3394  - Engineering Case #300125)=================

When reading a script file which contained an EOF character, (0x1A), 
DBISQL would have reported a "Lexical Error" rather than interpreting 
the character as an end-of-file marker. Now the end-of-file character 
is recognized correctly.

 

 Note that the end-of-file character is optional in script (.SQL) files.


=================(Build #3394  - Engineering Case #302368)=================

DBISQL would have reported an internal error, if an INPUT statement 
was executed which read a FIXED format file and all of the following 
were true:

- The table contained more than one column

- The INPUT statement contained a COLUMN WIDTHS clause

- Fewer column widths were given in the COLUMN WIDTHS clause than there 
are columns in the table

- The INPUT statement did not explicitly list the table columns




=================(Build #3414  - Engineering Case #307381)=================

Selecting the "Insert spaces" option in the editor's "Customize" dialog, 
would have been ignored, and would have been set back to "Keep tabs". 
This has been fixed.


=================(Build #3415  - Engineering Case #307751)=================

If when executing a .SQL file using the READ statement, the file contained 
a CONNECT statement where the user name was a parameter to the .SQL 
file, and it was enclosed in double-quotation marks, the CONNECT statement 
would have failed.



For example, if the following statements were in a file called TEST.SQL:



     PARAMETERS user_name;

     GRANT CONNECT TO "{user_name}" IDENTIFIED BY "{user_name}";

     GRANT DBA TO "{user_name}";

     CONNECT USER "{user_name}";

          

and were executed by:



     READ TEST.SQL [test]



an error would have occurred that the user "USER" did not exist. This 
has been fixed.



A workaround for the problem is to remove the quotation marks from 
the CONNECT statement.


=================(Build #3416  - Engineering Case #308507)=================

When connected to a database via the JDBC-ODBC bridge, the "Auto commit" 
option was implicitly on all the time, so that a commit was being done 
after every statement. This has been fixed so that commits are now implicitly 
done only if the "Auto_commit" option is "On".



This problem did not affect connections that used jConnect.




=================(Build #3432  - Engineering Case #311508)=================

Binary data imported from an ASCII formatted file would not have been 
loaded correctly if the data appeared as an unquoted sequence of hex 
digits, prefixed by "0x". (This is the format generated by DBUNLOAD 
and DBISQL's OUTPUT statment.) This has now been fixed.


=================(Build #3456  - Engineering Case #320929)=================

An internal error would have been reported if:        



- dbisql was running on a Windows operating system which was configured 
to use a multi-byte character set (MBCS), such as Japanese or Chinese, 
and



- an OUTPUT TO ... FORMAT EXCEL statement was executed, and



- an exported string, which was less than 255 characters, had a MBCS 
encoding which was greater than 255 bytes.



This problem has been fixed.


=================(Build #3463  - Engineering Case #321834)=================

When a START ENGINE statement was executed in dbisql, the quotation 
marks from the engine name parameter was not stripped off. For example, 
the following statement would start an engine called 'Test' rather than 
Test.



	START ENGINE AS 'Test'



Now, the quotation marks do not appear as part of the started engine's 
name. 




=================(Build #3464  - Engineering Case #322326)=================

When connected to a database which used  the Turkish (1254TRK) collation, 
DBISQL exhibited a number of problems. These have been fixed, and are 
listed below:



- If the server was started with the "-z" option, and the connection 
was via jConnect, debugging information from DBISQL was displayed in 
the server window. (It shouldn't be.)

- Connecting to an authenticated 1254TRK database was not possible.

- If connecting via jConnect, DATE, TIME, and TIMESTAMP column types 
were all displayed as TIMESTAMP and were not in the appropriate format.

- The list of options listed by the SET command was incomplete


=================(Build #3467  - Engineering Case #323206)=================

When an off-line transaction log directory was not specified, log scanning 
tools on CE would have failed to find the off-line logs if they were 
in the root directory. This problem has been fixed.


=================(Build #3469  - Engineering Case #324235)=================

If a database which had no user DBA (i.e. a REVOKE CONNECT FROM DBA 
had been done) was unloaded and reloaded using dbunload with the -ar 
or -an command line option, or the Sybase Central Unload wizard with 
a new database file specified, then the new database would have had 
a user DBA and the user that had been used to do the unload would have 
had the password SQL. This is now fixed.




=================(Build #3475  - Engineering Case #326072)=================

If a database which had no user DBA (i.e. a REVOKE CONNECT FROM DBA 
had been done) was unloaded and reloaded on Unix using:

- dbunload -ar or -an or

- the Sybase Central Unload wizard and a new database file was specified



then the new database would have had a user DBA and the userid used 
to do the unload would have had the password SQL.



With builds 7.0.4.3469, 8.0.1.3121 or 8.0.2.4279 higher, the error 
"Invalid user ID or password" would be displayed.  Earlier builds did 
not display any error.



This has now been fixed.


=================(Build #3484  - Engineering Case #326388)=================

If the command delimiter option was set to something other than the 
default, and the delimiter appeared in a quoted filename, the filename 
would have been truncated. Quoted filenames are used in the following 
statements: INPUT, OUTPUT, READ, START DATABASE, START LOGGING, and 
STOP DATABASE. This has been fixed.

 

 The workaround for this problem is to not change the command delimiter 
option.


=================(Build #3490  - Engineering Case #331826)=================

Attempting to execute an INPUT statement with a "FORMAT SQL" clause, 
without having previously executed a statement which returned a result 
set, would have caused dbisql to have reported an internal error. This 
has been fixed to now report an error message.



In a related problem, if an INPUT statement did not include a table 
name, and the file format was not "SQL", an error message should have 
been displayed but was not. Now, the error message is properly displayed.


=================(Build #3495  - Engineering Case #333869)=================

Running dbunload -ar could have failed to replace user dbspaces when 
creating the replacement database.  This would only have occurred if 
the path stored in the SYSFILE table for the location of the dbspace 
was not hard-coded, (ie 'dbspace1.db' instead of 'c:\database\dbspace1.db') 
and dbunload was started in a directory other than the one where the 
database was located.  This isnow fixed and dbunload -ar can be run 
from any directory on the local machine when using dbspaces.


=================(Build #3498  - Engineering Case #332139)=================

The INPUT statement would have failed to import any data if the FORMAT 
ASCII clause was specified, the input file did not contain values for 
all of the columns listed in the INPUT statement, and one of the omitted 
columns was of type BINARY, VARBINARY, or LONG BINARY. This has been 
fixed.




=================(Build #3501  - Engineering Case #336563)=================

If the parameters DBF, DBN, DBS or ENG were set in the SQLCONNECT environment 
variable, dbspawn could have failed unexpectedly to start the server. 
These parameters were added to the command line of the spawned server.  
For example, if SQLCONNECT was set to DBF=asademo.db and "dbspawn dbeng8 
asademo.db" was run, an error would occur.



This has been fixed so that the SQLCONNECT environment variable no 
longer affects dbspawn.


=================(Build #3501  - Engineering Case #336573)=================

The dbunload utility was checking the validity of dbmlsync extended 
option names and option values, while the server was not. This made 
it problematic when unloading a database that contained invalid options 
names or option values. The fix was to relax the unload process to not 
check for valid option name and values.


=================(Build #3502  - Engineering Case #334893)=================

ISQL and Sybase Central could not display Turkish characters properly. 
This has been fixed. A work-around is to edit the JRE font.properties 
file and change the exclusion ranges starting values from 0100 to 0500.



This problem could also occur for characters from other languages. 
Affected characters include those from Greek and Coptic, Cyrillic, Latin 
Extended A and B, and IPA extensions (characters in the Unicode range 
U+100 through U+4FF.)


=================(Build #3502  - Engineering Case #337764)=================

When running dbunload, if the client's charset on the unloading connection 
did not match the code page of the machine, the unload may have generated 
invalid SQL for the dbmlsync extended options. THis hasnow been fixed.


=================(Build #3506  - Engineering Case #340797)=================

Some connection parameter values from the dbisqlc connection dialog 
were being missed, including the CommLinks parameter.  This would have 
caused connections to a remote server initiated via the connection dialog 
to fail.  No -c command line option connection parameter were ignored, 
nor were those from the CONNECT USING statement.



Connection parameters other than the following were ignored by the 
connection dialog: UID, PWD, CON, DBN, DBF, DBS, ENG, START, AUTOSTOP, 
INTEGRATED, DSN.



This problem has been fixed.


=================(Build #3509  - Engineering Case #341718)=================

If the INPUT INTO statement is run with a FORMAT clause and the table 
does not exist, for some formats a table is created prior to loading 
the date. When executed via DBISQLC, the CREATE TABLE statement generated 
would have failed with a syntax error, if the language setting for ASA 
was anything other than EN (english). This has been fixed.



Note, this problem did not happen with DBISQL.




                             ****************                             
                             **  MobiLink  **                             
                             **            ** 
                             ** ASA Client **                             
                             ****************                             

=================(Build #2111  - Engineering Case #272610)=================

Dbmlsync could have reported an error like the following:

SQL Statment failed: (-130) Invalid Statment

when it was run so that more than one synchronization was completed 
before the program shut down.  This could have been achieved by specifying 
the -n switch more than once on the command line or by using scheduling 
options. This problem is now fixed.



=================(Build #2344  - Engineering Case #295144)=================

The dbmlsync start dialog on CE was  not able to handle command line 
switches with quotes. Common symptoms were failing to connect to a running 
database or an error reporting an invalid option value when quotes are 
involved in the Command switches field. The problem is now fixed.


=================(Build #2651  - Engineering Case #256873)=================

DBMLSync verbose logging was giving the following message when a upload 
row operation had a packed size greated than 4k: "This row operation 
is too large to be displayed completely" This 4k limitation is removed. 
The following situation may also have a very slight chance to cause 
dbmlsync to crash. That is when a string is lying across the 4k point 
in the packing. This unlikely problem is also fixed.


=================(Build #2674  - Engineering Case #256874)=================

Non-English data would be mangled during synchronization on a Windows 
CE device. This would occur if the native ANSI charset differed from 
the database charset. There was no setup that could avoid it.


=================(Build #2703  - Engineering Case #263804)=================

When the -i comand line switch was used to execute post-sync sql scripts 
and the script was not found, dbmlsync would only log an informational 
message, but not error. This has been fixed to log an error instead 
and dbmlsync will exit with an error code.


=================(Build #2707  - Engineering Case #262615)=================

Using any dbmlsync hook procedure with the -i switch to specify an end 
script, would have caused dbmlsync to always report the following error:
	SQL statement failed: (-265) Procedure 'immediate' not found
This has now been fixed.


=================(Build #2722  - Engineering Case #265828)=================

When running Dbmlsync on Windows CE, the -a switch was not being recognized. 
This is now fixed.


=================(Build #2723  - Engineering Case #265834)=================

If the output log did not already exist, using the -o switch wouldn't 
create one for you. All output would go to the console window only. 
This problem is now fixed.


=================(Build #2744  - Engineering Case #267635)=================

When the MobiLink clint for ASA received a 32767 byte varchar value 
in the upload stream, it would have raised one of the following warnings, 
depending on the nullability of the column:
	1. "Invalid character data encountered in upload -- using empty string."; 
or
	2. "Invalid character data encountered in upload -- using NULL."

The consequence was that the original remote data and the consolidated 
data would have been destroyed. MobiLink 7.0.x may even have overrun 
the value buffer and caused further corruption. This problem have been 
fixed of MobiLink.


=================(Build #2753  - Engineering Case #268995)=================

Pressing the CANCEL button in the DBMLSync dialog, would have caused 
dbmlsync to exit, but the system tray icon would have remained remained 
until the cursor was moved over it. This has now been fixed.


=================(Build #2757  - Engineering Case #269319)=================

In an ASA consolidated database, if the database option "Chained" was 
set to "Off" and a failure happened in the middle of the upload transaction, 
the first part of this transaction could have been automatically committed 
and Mobilink server would not have been able to rollback the upload 
transaction. In a remote ASA database, if the database option "Chained" 
was set to "Off" and a failure occured in the middle of the download 
stream, the first part of the transaction could have been automatically 
committed and DBMLSync would not have been able to rollback the download 
transaction. The Mobilink  synchronization server, and DBMLSync, now 
temporarily set the "Chained" to 'On'.


=================(Build #2790  - Engineering Case #275482)=================

When running on the CE emulator, DBMLSync would have failed to load 
shared stream libraries. This problem is now fixed.


=================(Build #3282  - Engineering Case #270994)=================

Dbmlsync would have uploaded rows that had been updated, even when no 
column in the publication changed. This problem occurred when a table, 
say T1, was included in a publication and column subsetting was used 
to exclude some columns from the publication.
For example:

Create publication P1 (
	Table	T1( pk, c1)
)

In this case, if an update was applied to a row in T1 and the update 
only changed columns that were not included in the publication, the 
update would have been uploaded anyway.  The pre-image and post-image 
for the update would have been the same when it was uploaded and Mobilink 
would have generated a warning and ignored the operation

This was only a performance issue, it should never have lead to other 
problems.



=================(Build #3295  - Engineering Case #272610)=================

Dbmlsync could have reported an error like the following:

SQL Statment failed: (-130) Invalid Statment

when it was run so that more than one synchronization was completed 
before the program shut down.  This could have been achieved by specifying 
the -n switch more than once on the command line or by using scheduling 
options. This problem is now fixed.



=================(Build #3305  - Engineering Case #259161)=================

During synchronization, dbmlsync would crash if there was a sychronization 
template defined in the remote database and the template's sync_id in 
the syssynch table was less than the sync_id of the synchronization 
definition being synchronized. This is now fixed.



=================(Build #3328  - Engineering Case #277856)=================

When processing a download stream, dbmlsync will delete any rows that 
fail to satisfy referential integrity constraints on the remote database.  
Now, when verbosity is turned on, the delete commands executed and the 
number of rows deleted, will be printed to the log.


=================(Build #3345  - Engineering Case #286276)=================

Both the MobiLink Server and the MobiLink ASA Client may have reported 
the error  "Protocol error" or the MobiLink Server alone may have reported 
the error "A network read failed. Unable to read data from the remote 
client", during ynchronization.  The client would then have stopped 
and not have been able to synchronize any more. Both of these problems 
have been fixed.


=================(Build #3364  - Engineering Case #292540)=================

The MobiLink ASA Client, (and SQL Remote for ASA), may have complained 
that "Log operation at offset X has bad data at offset X + x" for versions 
less than 8.0.0 or "No log operation at offset X in the current transaction 
log" for versions greater than or equal to 8.0.0".  The problem was 
that DBMLSync or DBRemote had already updated their systable with a 
wrong log offset in the previous run.  This could have happened if

1) the last log operation in the latest offline transaction log was 
a "Commit"; and

2) in the online transaction log, there was no actual data to be uploaded 
or replicated.

This problem is now fixed.


=================(Build #3378  - Engineering Case #297000)=================

DBMLSync would not have reported an error, even if the requested starting 
log offset was beyond the end of the active transaction log (this can 
happen if the remote database is restored from a backup. Then it could 
have stopped working once the transaction log of this remote database 
has grown beyond this requested starting log offset. This is now fixed.


=================(Build #3382  - Engineering Case #298851)=================

If primary keys for uploaded data contains string columns, dbmlsync 
running on CE may have produced an incorrect upload stream, if non-UTF8 
characters were involved. This problem is now fixed.


=================(Build #3382  - Engineering Case #298858)=================

Dbmlsync may have crashed, due to a buffer overrun, if it encountered 
non-blob strings longer that 32759 bytes (the ASA limit is 32767). The 
problem is now fixed.


=================(Build #3411  - Engineering Case #305093)=================

Dbmlsync would have incorrectly deleted rows from the download stream 
which had NULL foreign key values, if all of the following were true: 


- table T contained a foreign key and one or more of the columns of 
row R involved in the FK was NULL.

- another row, R2, existed in the download stream that dbmlsync had 
to delete, due to a legitimate RI violation, involving the same foreign 
key in which R had a NULL value.



This behaviour has been corrected.


=================(Build #3431  - Engineering Case #312536)=================

The next available value for a GLOBAL AUTOINCREMENT column could have 
been set incorrectly in the following situation:

- an INSERT into the table was executed using a value for the column 
outside the range for the current setting of Global_database_id. This 
could happen if rows from other databases were downloaded as part of 
a synchronization.

- the server was shutdown abnormally (e.g. by powering off) before 
a checkpoint occurred.



The next time the database was started, the next available value for 
the column would have been set incorrectly. If an INSERT was then attempted 
with no value provided for the column, the error "Column '<col>' in 
table '<table>' cannot be NULL" would have been reported. If the database 
was again shut down and restarted, an INSERT into the table would have 
attempted to use the first available value in the range for the current 
setting of Global_database_id. Note that if rows had been deleted from 
the table, this could result in a value being generated which had previously 
been used and which might still exist in another database. Resetting 
the value using sa_reset_identity() would correct the problem, assuming 
an appropriate value to use can be determined. This problem has now 
been fixed.


=================(Build #3434  - Engineering Case #313603)=================

If a sitename contained characters from a Multi-Byte Character Set, 
dbmlsync would have failed to find the subscription or perhaps crashed. 
This problem is now fixed.


=================(Build #3444  - Engineering Case #310577)=================

If dbremote was running in hover mode or if dbmlsync was running on 
a schedule, and either process was running with the -x switch to rename 
and restart the transaction log, then after the log was renamed for 
the first time, neither dbremote nor dbmlsync would have sent changes 
to the consolidated database until the process was restarted. Now, if 
the online log is renamed when in hover-mode, the data in the last page 
is processed and then the log-scanning process is shutdown and restarted.


=================(Build #3451  - Engineering Case #319111)=================

Dbmlsync would sometimes have failed to identify ALTER TABLE operations 
that applied to tables being synchronized.  This prevented dbmlsync 
from generating the error message "Table 'tablename' has been altered 
outside of synchronization.." when a table with operations that needed 
to be uploaded was altered.  This has now been fixed and the error message 
will now be generated when needed.


=================(Build #3510  - Engineering Case #342990)=================

If two tables had primary keys that included a signed bigint column 
and dbmlsync scanned operations in a single run on these two tables, 
where the values for the primary key were identical, it was then possible, 
(although rare), to lose or mangle operations. When this situation occurred, 
the two operations would have been interpreted as occuring on the same 
table, instead of different tables, thus causing the two operations 
to be merged into a single operation.  This has now been fixed.




                     *********************************                     
                     **          MobiLink           **                     
                     **                             ** 
                     ** Charset Conversion (UNILIB) **                     
                     *********************************                     

=================(Build #2666  - Engineering Case #258534)=================

Using dbmlsync to synchronize UTF8 data from a database on a Windows 
CE device to the consolidated database would incorrectly translate the 
data, causing it to be inserted incorrectly into the consolidated database..





                           *********************                           
                           **    MobiLink     **                           
                           **                 ** 
                           ** HotSync Conduit **                           
                           *********************                           

=================(Build #2626  - Engineering Case #256866)=================

Doing Multiple DMC synchronizations may have caused HotSync to crash.


=================(Build #2738  - Engineering Case #261282)=================

Certain user authentication passwords would not work.  The user authentication 
password was RC4 encrypted before being passed as part of a client parameters 
string to the conduit.  If, after RC4 encrypting the password, the string 
contained a '{' or '}' brace, then the parsing algorithm could not correctly 
parse the string and would have failed, causing the 'Cannot create stream' 
error. They would have prevented the synchronization from happening 
at all. This has now been fixed.


=================(Build #2789  - Engineering Case #272872)=================

An application, using the regular non-dmc conduit, would have received 
-85 errors on exit of the application and would not have synchronized. 
This problem was introduced in 7.0.3 build 2107 and is now fixed.



=================(Build #2789  - Engineering Case #277491)=================

When synchronizing a Palm device using the DMC conduit, the synchronization 
would have hung and never finished, if the Palm store and the conduit 
were of different versions. Now, if the store and conduit are of different 
versions, the synchronization will fail and a message will be output 
to the log:
"FAIL Adaptive Server Anywhere Conduit (SQLCODE = -82)"




                  **************************************                  
                  **             MobiLink             **                  
                  **                                  ** 
                  ** Java Provider for Sybase Central **                  
                  **************************************                  

=================(Build #2695  - Engineering Case #255904)=================

In a Merant Oracle8 connection, although all MobiLink system tables 
are correctly installed, the MobiLink plugin for Sybase Central misidentified 
the non-existence of the MobiLink system tables. This has now been fixed.



=================(Build #2699  - Engineering Case #262422)=================

Some connection scripts, (eg. authenticate_user, authenticate_user_hashed), 
and table scripts (eg. time_statistics, download_statistics), were not 
being correctly tested in the plugin. The plugin now sets the correct 
number of parameters for those scripts.



=================(Build #2730  - Engineering Case #266226)=================

When using the MobiLink Plugin with the iAnywhere Solutions Oracle8 
ODBC driver, a MobiLink user name could not have been added or updated 
without adding a password. This has been fixed.


=================(Build #2730  - Engineering Case #266331)=================

When adding a new version with a description or adding a new connection/table 
script for a MS SQL Server connection, spaces were appended to the end 
of the version comments, connection or table scripts. This has now been 
fixed.


=================(Build #2730  - Engineering Case #266370)=================

The MobiLink plugin would show only one connection script at a time 
with an iAnywhere Solutions 8 ASE connection, although there was more 
than one row in the ml_connection_script table. This has now been fixed.


=================(Build #2756  - Engineering Case #269217)=================

From the Add Connection/Table Script wizard, no scripts could have been 
added for a newly created script version if the event list of one of 
the script versions was empty. This is now fixed.


=================(Build #2789  - Engineering Case #274774)=================

The MobiLink Plugin was not able to delete synchronized tables from 
a DB2 consolidated, due to a problem where object names were being truncated 
to 18 characters. This problem is now fixed.




                              **************                              
                              ** MobiLink **                              
                              **          ** 
                              ** Streams  **                              
                              **************                              

=================(Build #2720  - Engineering Case #262988)=================

When the -vr command-line option was used, MobiLink would only log TIME 
and TIMESTAMP values with millisecond precision. This has been changed 
to full microsecond precision.


=================(Build #3337  - Engineering Case #279781)=================

It was possible for either end of a synchronization, (UltraLite, dbmlsync 
or a MobiLink Server worker thread), to consume 100% CPU in the TCP/IP 
layer. This problem could also have affected HTTP clients, since HTTP 
is built upon TCP/IP as well. It is now fixed.


=================(Build #3396  - Engineering Case #302923)=================

When the stream connection string contained an invalid value for the 
"version" option (ie. anything other than "1.0" or "1.1"), or an invalid 
value for the "content_type" option (ie. anything other than "fixed" 
or "chunked"), the stream would have leaked a few bytes of memory. It 
was possible for synchronizations to succeed, even though the options 
are specified incorrectly. Both the HTTP and HTTPS streams were affected 
and are now fixed.




                       ****************************                       
                       **        MobiLink        **                       
                       **                        ** 
                       ** Synchronization Server **                       
                       ****************************                       

=================(Build #2625  - Engineering Case #241978)=================

The mobilink server would fail to start when the connection was to a 
database with the collation WIN_LATIN5.  Any Turkish collation would 
be affected.  Other database tools may exhibit strange errors.
The error returned is usually "Invalid option 'CONNECTION_AUTHENTICATION' 
-- no PUBLIC setting exists"



=================(Build #2631  - Engineering Case #257339)=================

The Merant 3.5 ODBC driver for ASE's upload performance can degrade 
significantly when there are many download_cursor and download_delete_cursor 
scripts that contain many columns. Using the switch -hwC+ works around 
this problem by disabling the ODBC prepared-statement cache


=================(Build #2636  - Engineering Case #240256)=================

Several numeric command-line switches always evaluated to zero (0) or 
the default value for that option. The following options were affected:

	-bc
	-bn
	-cn
	-cr
	-rd


=================(Build #2687  - Engineering Case #261496)=================

Uploading a NULL or zero-length blob to a table with more than one BLOB 
column could have generated an ODBC function sequence error, if it is 
the first such BLOB.



=================(Build #2690  - Engineering Case #262257)=================

Using the @argfile feature would not work with multi-line files. Also, 
files longer than 500 bytes could would cause truncation of the command 
line options from that file. As a workaround, put all options on the 
first line of the file. If more than 500 bytes are required, use multiple 
files, each with less than 500 bytes.
Note: this problem also occurred with the SQL Remote and Rep Server 
Agent executables.



=================(Build #2699  - Engineering Case #262549)=================

Mismatched final bracket for  MobiLink's -x opition with security options 
specified could crash the MMobiLink server on startup. For example, 
the following command would cause a crash:
dbmlsrv7 -c "dsn=asa70sample;uid=dba;pwd=sql" -x tcpip{security=certicom_tls{certificate=mobilink.crt;certificate_password=tJ1#m6+W})



=================(Build #2707  - Engineering Case #262555)=================

In the same session of synchronization, BLOBs that just have been uploaded 
may not have been filtered out in the download if the BLOB length was 
greater than 255 bytes long.



=================(Build #2709  - Engineering Case #264315)=================

DBMLSync may not have detected and resolved conflicts properly during 
the download process, even if the extended option, -cr,  was set with 
N greater than 0. This has now been fixed.



=================(Build #2714  - Engineering Case #264973)=================

Connecting to a database using a non-Merant driver may have generated 
warnings about option values changed or invalid options.  These messages 
are now suppressed.  We don't know if the driver is one of our branded 
drivers until after we connect and send the "unlocking" parameters, 
which may generate warnings for non-Merant drivers.


=================(Build #2715  - Engineering Case #265147)=================

When using an ASE consolidated database, some table/connection scripts 
could have failed with the following ODBC error: 
	Unclosed quote before the character string 'x'
where x was the first character of a user_name or table_name.

This would probably only occur if the script was a call to a stored 
procedure.



=================(Build #2744  - Engineering Case #267539)=================

When dbmlsync encountered a packed row of size greater than 64k, (excluding 
clob/blob), during upload log scanning, it would have given the following 
error.
	"An oversized upload row was encountered at offset XXXX"
DBMLSync would then have aborted the synchronization. This limit has 
now been removed.


=================(Build #2753  - Engineering Case #268997)=================

When dbmlsync was first launched, the cursor was placed in the password 
field of the connect dialog. This behavior has been changed so that 
when first launched, the cursor will be placed in the user id field. 
Subsequent launches remains context sensitive, (e.g. ml password problem 
will cause the cursor to be in the password field).


=================(Build #2786  - Engineering Case #262965)=================

With Unicode binding, MobiLink would have crashed when doing clob conflict 
resolves or delete synchronizations against Oracle or ASE. This has 
been fixed.



=================(Build #2786  - Engineering Case #271544)=================

On a Palm device, if the connection was cut after the upload completed, 
but before the device received the upload acknowledgement, the uploaded 
rows were left in a maybe_uploaded state.  After reconnecting when in 
this state, the upload would be restarted, causing MobiLink to issue 
a -300 error.  This has now been fixed


=================(Build #2787  - Engineering Case #267969)=================

When using Adaptive Server Enterprise as the cosolidated DBMS, BLOBs, 
(ie TEXT, IMAGE), would have been silently truncated to 4K when being 
downloaded. Uploading BLOBs larger than 4K were not affected by this 
problem. A workaround would have been to set a hidden switch, StaticCursorLongColBuffLen, 
in the DSN for the ASE ODBC driver.   This is no longer required.


=================(Build #2789  - Engineering Case #270988)=================

Under certain conditions, some UltraLite updates would never be uploaded. 
The requirements were as follows:
1) The UltraLite application synchronized in one of the following two 
ways:
a) A normal synchronization with a download transaction committed, 
but with the download acknowledgement successfully sent by the remote, 
and the MobiLink server does not get a chance to commit the download 
transaction. This was most likely to happen if the server machine suddenly 
lost power.
b) A successful upload-only synchronization.
The key point is that afterwards, in the consolidated database, the 
ml_user.commit_state is 2 for the MobiLink user in question.

2) The UltraLite application performed and commited some updates (ie. 
INSERTs, UPDATEs, and/or DELETEs).

3) The UltraLite application attempted to synchronize, but the upload 
was lost on the wire, and MobiLink never applied it. At this point, 
the UltraLite runtime did not know whether or not the MobiLink server 
applied the upload or not.

4) The UltraLite application attempted to synchronize again. When in 
the uncertain state resulting from (3), the UltraLite runtime asks the 
MobiLink server whether or not the upload was applied. The MobiLink 
server would have  said "yes", even though the upload was never applied. 
Thus, the UltraLite operations from (2) were never uploaded.

NOTES:
1) A workaround policy is to make sure UltraLite users postpone remote 
changes until AFTER they synchronize successfully after a failed synchronization.
2) If UltraLite clients with this EBF fix connect to a MobiLink server 
without the EBF fix, then the MobiLink server will report a "Protocol 
version mismatch", and the UltraLite remote will get a SQLCODE of -85 
(SQLE_COMMUNICATION_ERROR). It is always best to upgrade your MobiLink 
server before you upgrade your remotes.


=================(Build #2789  - Engineering Case #273776)=================

Starting the MobiLink server with a Certicom-based stream may caused 
it to crash when shutting down. This has been fixed


=================(Build #2789  - Engineering Case #274407)=================

When connections in the MobiLink Server connection pool went bad, (as 
can happen when the network goes down or the consolidated database is 
shut down and restarted), some subsequent synchronizations could have 
failed with database connection errors. The failures may not have occurred 
immediately following the loss of database connections, since the bad 
connections could have sat in the pool for a long time before being 
chosen for a synchronization, (usually as the number of concurrent synchronizations 
increases). There was only one failure per bad connection.

The MobiLink Server now checks each connection before removing it from 
the connection pool. If a connection is bad, a new one is created.


=================(Build #3310  - Engineering Case #273723)=================

If there were DML statements in the authenticate_user and/or authenticate_user_hashed 
scripts, the Mobilink server may have shown incorrect behavior, such 
as thread-blocking.  This was due to the Mobilink server not issue a 
commit or rollback after authenticating the user. This has been fixed.


=================(Build #3341  - Engineering Case #266949)=================

If a table with a NULL-able BLOB column (ie. LONG VARCHAR or LONG BINARY) 
was uploaded, the MobiLink server could have started to  misinterpreting 
the upload stream, most likely resulting in a failed upload, but possibly 
resulting in bad data being synchronized. The problem only occurred 
when the remote table's primary-key columns were NOT the first columns 
in the CREATE TABLE statement. For example, the following remote table 
would not show the problem:

create table ok_table (
	pk		integer primary key not null,
	blob_col	long varchar
)

while the following table would have shown the problem:

create table problem_table (
	blob_col	long varchar,
	pk		integer primary key not null
)


=================(Build #3411  - Engineering Case #306131)=================

When a table is added to a Mobilink consolidated database, it is assigned 
a unique tableid.   Scripts created to work on this table will use this 
tableid when loaded from the database.  If the tableid had a value greater 
than 65535, it was possible that the script would not have loaded, or 
the wrong script would have been loaded. This has been corrected.


=================(Build #3438  - Engineering Case #314861)=================

The MobiLink server may have crashed when executing an ODBC statement 
that had been previously executed.  This would only have occurred if 
the script happened to be identical for two different tables. This was 
most likely to have occurred when using download_delete_cursor and the 
truncate table feature, where the script was typically "select NULL".  
One workaround is to add some comment text to the script to make it 
unique. This problem has now been fixed.


=================(Build #3475  - Engineering Case #326150)=================

The MobiLink server may have crashed when using cursored uploads.  This 
is now fixed, but a workaround is to disable the statement cache (-hwC+) 
in versions 8.0.0 and later. No workaround is available for earlier 
versions.


=================(Build #3486  - Engineering Case #330441)=================

The -zt command line option for dbmlsrv was mistakenly shown in the 
usage displayed on Unix platforms. This switch is only available on 
Windows and now is only shown when usage is displayed when running on 
Windows.




=================(Build #3498  - Engineering Case #335092)=================

Under forced conflict mode, uploaded deletes would have been applied 
in the wrong order. Consider the following sequence uploaded into tables 
Parent and Child, where table Child has a foreign key to table Parent:



(At the remote)

DELETE FROM Child WHERE foreign_key = 1;

DELETE FROM Parent WHERE primary_key = 1;

COMMIT;

(synchronize)



The second delete from the remote (ie. from Parent) would have been 
applied before the first delete, causing a referential integrity violation 
in the consolidated during upload. Prior to this  change, the behaviour 
was to generally delete from Parent before deleting from Child. Now, 
the behaviour is to delete from Child before deleting from Parent.


=================(Build #3536  - Engineering Case #376133)=================

The MobiLink server could have behaved incorrectly, (invoked the begin_synchronization 
scripts, for instance), or even crashed, if there were network or client 
problems before the server received the full upload stream. This problem 
is now fixed.




                              ***************                              
                              ** MobiLink  **                              
                              **           ** 
                              ** Utilities **                              
                              ***************                              

=================(Build #2547  - Engineering Case #240512)=================

DBMlstop would core dump on UNIX platforms.




                              **************                              
                              ** MobiLink **                              
                              **          ** 
                              ** scripts  **                              
                              **************                              

=================(Build #2727  - Engineering Case #265921)=================

The readme.txt files in the MobiLink upgrade directories referred to 
ASA instead of ASE.


=================(Build #3295  - Engineering Case #272738)=================

On Microsoft SQL Server the Mobilink system tables could have been created 
with ANSI_PADDING set ON. This would have caused all string values in 
these tables to appear with extra spaces. The setup script now turns 
ANSI_PADDING OFF before creating any tables.





               *********************************************               
               ** SQL Remote for Adaptive Server Anywhere **               
               **                                         ** 
               **        Database Tools Interface         **               
               *********************************************               

=================(Build #3336  - Engineering Case #279208)=================

When a remote user is extracted, but the consolidated database has not 
yet received any messages from that user, the consolidated database 
sends "ping" messages to the remote. These messages start out being 
sent with the user's send frequency, then back off to once a day. This 
logic could have stopped working after a number of days, depending on 
the users send frequency, a message would then have been sent every 
send poll. This has been fixed.


=================(Build #3411  - Engineering Case #304766)=================

If the connection that was used for processing incoming messages was 
dropped, SQL Remote

for ASA would have gone into an infinite loop display the error:  "SQL 
statement failed: (-101) Not connected to a database". The errors SQLE_CONNECTION_TERMINATED 
and SQLE_NOT_CONNECTED were not handled properly. This problem is now 
fixed.


=================(Build #3511  - Engineering Case #344321)=================

If an online transaction log was truncated, just when dbremote started 
scanning the online log, dbremote may have resent transactions that 
had been sent in previous messages.  This problem is now fixed.




           *****************************************************           
           **     SQL Remote for Adaptive Server Anywhere     **           
           **                                                 ** 
           ** Extraction Utility for Adaptive Server Anywhere **           
           *****************************************************           

=================(Build #3260  - Engineering Case #237758)=================

When executing dbxtract on an active database using isolation  level 
3 (-l 3 switch), it was possible that the resulting remote database 
might fail to build, giving a foreign key violation  when loading data 
into a child table.  This only happened if an internal unload was used, 
which was the default.  The problem did not exist when an external unload 
was used.




               *********************************************               
               ** SQL Remote for Adaptive Server Anywhere **               
               **                                         ** 
               **        SQL Remote Message Agent         **               
               *********************************************               

=================(Build #3332  - Engineering Case #278232)=================

The text in the dbremote title bar, was not correctly reflecting the 
status of dbremote upon completion. This has now been fixed.


=================(Build #3365  - Engineering Case #293122)=================

In rare cases a consolidated dbremote could have sent messages that 
would cause errors the remote database involving undeclared and redeclared 
variables. The remote could also have missed data operations. This would 
have been most likely to happen when the consolidated was sending large 
messages to many remotes with a small or unset memory value (the -m 
command line flag). This problem is now fixed.


=================(Build #3484  - Engineering Case #328956)=================

If the minimum log_sent value in the SYSREMOTEUSER table pointed to 
the middle of an operation in the transaction log, then dbremote would 
still have sent data starting at the beginning of the transaction pointed 
to by the bad offset.  Now, dbremote will return an error (No log operation 
at offset X) in this situation.




                        ***************************                        
                        **       UltraLite       **                        
                        **                       ** 
                        ** Analyser Java Classes **                        
                        ***************************                        

=================(Build #2612  - Engineering Case #235303)=================

There were cases when the UL analyzer did not generate an expected GetXXX() 
function.  This would have happened if a TIMESTAMP datatype was retrieved 
from a query that was fetching results into a temporary table.  The 
function is now generated with a DECL_DATETIME parameter that receives 
the value.


=================(Build #2708  - Engineering Case #264455)=================

The size of large temporaries could have been incorrect in Java files 
generated by the Ultralite Analyzer.


=================(Build #2738  - Engineering Case #266446)=================

The UltraLite analyzer had a problem processing some queries.  In particular, 
a query with a search condition that did not depend on the rows of that 
query would cause the analyzer to throw an unhandled exception. This 
has now been fixed.


=================(Build #3323  - Engineering Case #273415)=================

The analyzer was generating incorrect code when a GROUP BY was used 
in a SELECT statement that was not opened as part of a cursor (for example 
SELECT ... INTO ...).  This has been fixed.


=================(Build #3326  - Engineering Case #274983)=================

The analyzer would return an empty string when concatenating null arguments, 
(like SELECT STRING(c1, c2) where c1 and c2 were both null).  The correct 
result is to return null.  NULL should be returned from the STRING()
function if all arguments are null.  This is now the behaviour.


=================(Build #3374  - Engineering Case #295700)=================

The code generated by the UltraLite analyzer was wrong for CASE expressions 
where the arguments could have been null. This has been fixed.


=================(Build #3389  - Engineering Case #299351)=================

The UltraLite analyzer was generating a C++ function prototype for the 
Open method of a ULResultSet object with duplicate variable names.  
This would happen if a host variable was used more than twice to represent 
a value for the same column in a query.  For example:  SELECT * from 
T where x > ? OR x < ? OR x = ?.

 

This has been fixed, the parameter names are now unique.




                           ********************                           
                           **   UltraLite    **                           
                           **                ** 
                           ** Code Generator **                           
                           ********************                           

=================(Build #2658  - Engineering Case #257049)=================

UlGen would generate a fatal error if the sign(double) function was 
used with option -t java.  A work-around would be to program the same 
functionality using IFs.


=================(Build #2674  - Engineering Case #259691)=================

The code generated for a C++ ULResultSet class, that represented a query 
with a DISTINCT on a non-indexed column, would return the wrong results.  
The result returned was always the last row of the table.  This is because 
a temporary table was used, however, the results were pointing to the 
base table instead of the temporary table columns.  This is now fixed.


=================(Build #2721  - Engineering Case #263018)=================

Palm application using Certicom encyrption with the DMC conduit would 
fail with error: "Records left locked in closed unprotected DB". This 
has been fixed.


=================(Build #2736  - Engineering Case #262714)=================

The UltraLite analyzer could generate more code than could fit in a 
Palm segment.  Since UltraLite doesn't know the size of the code it 
generates, it's not clear how to divide the code into segments less 
than 64K. Previously, a new segment was created for every 8 statements.  
This has been changed so that it's now generated for every 5 statements.

Note the following:
1.  There is a limit to the number of segments an application can have, 
and there is a performance penalty for using too many segments, (thus, 
we don't put each statement into its own segment).  If too many segments 
are
generated, a script can be written to merge segments, reducing their 
number.
2.  This change doesn't guarantee the problem will go away ... it only 
makes it less likely.
3.  With Version 8, the user can decide  which segment each statement 
should be put into.

See also issues 241706 and 241176.


=================(Build #2757  - Engineering Case #269053)=================

When generating C++ code, the header file containing the Table/Database 
data started with the following code:
#ifndef _ul_db_H_INCLUDED
#define _ul_db_H_INCLUDED
The endif for this code was placed before the end of the file, so if 
the file was directly included, the compiler could have complained about 
redefinition of structures.  Now, it is at the end of the file.


=================(Build #2782  - Engineering Case #271181)=================

The UltraLite analyzer would have generated the constant value -2147483648, 
if a statement referenced that value, (for example SELECT hextoint('80000000' 
)).  Some compilers generate a warning about this.  For example, the 
Watcom compiler generates: Warning! W887: col(64) unary '-' of unsigned 
operand produces unsigned
result  The UL analyzer now generates (-2147483647-1), which is the 
way the Watcom compiler handles this value.




                        **************************                        
                        **      UltraLite       **                        
                        **                      ** 
                        ** MobileBuilder plugin **                        
                        **************************                        

=================(Build #2713  - Engineering Case #264830)=================

Calls to inline C++ methods such as ULData::Open( SQLCA * ) could have 
failed in Palm GNU applications, if the application was compiled with 
the -O compiler switch.




                          ***********************                          
                          **     UltraLite     **                          
                          **                   ** 
                          ** Runtime Libraries **                          
                          ***********************                          

=================(Build #2119  - Engineering Case #255185)=================

If multibye characters were used in a LIKE clause, the statement could 
not find any matching multibyte data. This problem only existed on big 
endian platforms such Palm devices. Now this problem has now been fixed.


=================(Build #2611  - Engineering Case #235299)=================

If a generated ::execute() method of the Statement class failed with 
a sql error, then the return value of that call would still return ul_true 
indicating success.


=================(Build #2624  - Engineering Case #255903)=================

When calling Delete() on a row referenced by a foreign key, ULCursor::Delete() 
would have correctly not performed the delete, but would have incorrectly 
cleared the sql error and return true (ok).



=================(Build #2625  - Engineering Case #256876)=================

ULResultSet::BeforeFirst() would have incorrectly returned false even 
when true.  ULResultSet::AfterLast() failed to return false on an error.


=================(Build #2632  - Engineering Case #257200)=================

The creation of a temporary table during query processing could overwrite 
other data in the persistent store, causing the persistent store to 
become corrupt.


=================(Build #2651  - Engineering Case #258604)=================

Java Ultralite would consume excessive amounts of memory when Timestamp 
objects were used in rows or temporaries.


=================(Build #2675  - Engineering Case #260710)=================

Excessive memory was used to perform operations such as COMMIT or SYNCHRONIZE 
and was noit released until the associated connection was closed.


=================(Build #2716  - Engineering Case #265207)=================

The persistent storage would become corrupt if a temporary table was 
used and there is no subsequent commit, rollback, or explicit close 
of the database..


=================(Build #2750  - Engineering Case #268703)=================

If a memory allocation failed while parsing the synchronization parameters, 
or if incorrectly formatted parameters were supplied, the synchronization 
would proceed, with possibly unpredicable results. Now an error is returned 
and no synchronization is performed.


=================(Build #2782  - Engineering Case #271134)=================

The C/C++ Ultralite runtime might have copied fewer characters than 
required when copying Unicode character strings,as the target string 
was not being calculated correctly. This has been fixed.


=================(Build #2790  - Engineering Case #273036)=================

When synchronizing a Palm device, with TCP/IP via RAS, if the end_upload 
event took more than 60 seconds, the device was disconnected. A hardcoded 
timeout for of 60 seconds was implemented to avoid excess battery drain 
during synchronization. Now the parameter "timeout" can be specified 
in the stream_parms of the ul_synch_info to set the number of seconds 
before timeout.  A default of 60 seconds will still be used if the timeout 
parameter is not specified.


=================(Build #3323  - Engineering Case #255185)=================

If multibye characters were used in a LIKE clause, the statement could 
not find any matching multibyte data. This problem only existed on big 
endian platforms such Palm devices. Now this problem has now been fixed.


=================(Build #3328  - Engineering Case #274803)=================

Under Java Ultralite, blob and clob assignment would not have worked. 
When the input was specified as a Java Stream, a null pointer exception 
could have been thrown. This has now been fixed.


=================(Build #3328  - Engineering Case #276694)=================

The default value for the timeout option in the string parameters passed 
to the Java communications layer, (ie "...;timeout=NNNN"), has been 
set to 60000. Previously, it had no default, so no timeout would occur. 
Now, when communication with a MobiLink server is interrupted for the 
timeout time, a communication error is reported by the Java client. 
The value of the option is the number of milliseconds before a network 
call will time out. Thus the new default timeout is now 60 seconds.



This option should only be set if the default timeout of 60 seconds 
is too short. For example, if it is expected that the time between sending 
the upload and receiving the download can reasonably be expected to 
take up to two minutes, then the timeout should be set to 120,000.



Caution: larger timeout values mean potentially longer waits for end 
users before they are notified of a communication error.


=================(Build #3344  - Engineering Case #287725)=================

Supplying a string value to insert into a binary column, where the string 
required truncation to fit, could have caused incorrect values to be 
inserted into the row.




=================(Build #3345  - Engineering Case #288136)=================

Calling ULData::PalmExit() would have closed the UltraLite store, but 
would not have remembered that it was closed.  If the database was deleted 
after this time, a call to ULData::PalmLaunch would still have believed 
that the database was still open and would not have recreated it. Multiple 
consecutive calls to either PalmLaunch or PalmExit did  not check to 
see if the database was open or closed. Now, both PalmLaunch and PalmExit 
check the status of the database and correctly set the flag to remember 
if it's open or closed.




=================(Build #3350  - Engineering Case #289188)=================

When running UltraLite Java and trying to synchronize, if an out-of-memory 
error occurred, especially after uploading data, UltraLite would have 
lost information about the uploaded data and tried to upload the same 
data over and over again, causing non-unique index errors on the MobiLink 
server. In some cases, the .udb file was corrupted and the database 
file had to be rebuilt. Now if a memory error occurs, a fatal error 
is set and the synchronization stops.


=================(Build #3424  - Engineering Case #310304)=================

The documentation incorrectly states that when using the C++ API, storage 
parameters can be passed to the UltraLite runtime either by using the 
UL_STORE_PARMS macro or by passing them directly to the ULData::Open 
method.  Actually, using the ULData::Open method is the only way parameters 
can be passed.




                          **********************                          
                          **    UltraLite     **                          
                          **                  ** 
                          ** SQL Preprocessor **                          
                          **********************                          

=================(Build #2665  - Engineering Case #259330)=================

When running SQLPP to generate UltraLite code for a database with a 
user table called SYSINFO, the collation for the database could not 
properly be retrieved.  This is now fixed.




                         ************************                         
                         **     UltraLite      **                         
                         **                    ** 
                         ** Sample Application **                         
                         ************************                         

=================(Build #2713  - Engineering Case #264831)=================

Calls to inline C++ methods could fail in Palm GNU applications if compiling 
with the -O compiler switch, (see QTS 264830).  The "-fno-inline" compile 
option is now used by default in the MobileBuilder custdb sample for 
Palm.

