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

Bug Fix Readme for Version 6.0.4
********************************

Description of available downloads
==================================

    Emergency Bug Fixes
    ===================
    A subset of the software with one or more bug fixes. The bug fixes are 
    listed in the "readme" file for the update. A Bug Fix update may only be
    applied to installed software with the same version number.

    Some testing has been performed on the software, but full testing has not
    been performed. Customers are discouraged from distributing these files
    with their application unless they verify the suitability of the software
    themselves.

    Verified Bug Fixes
    ==================
    A complete set of the software with one or more bug fixes. The bug fixes are 
    listed in the "readme" file for the update. A Bug Fix update may only be
    applied to installed software with the same version number.

    Full testing has been performed on the software.

    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.

    After the maintenance release upgrade has been applied, the latest
    Verified or Emergency Bug Fixes update should be applied, if available.

Bug Fixes
=============
The following is a list of bugs fixed in this collection of software,
as compared to the 6.0.4 Maintenance Release.



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

=================(Build #3691  - Engineering Case #220205)=================

A valid connection attempt to a database which was already running could 
have resulted in the error -105  "Database cannot be started -- ???".  
This would only have occurred using a communication protocol other than 
shared memory.


=================(Build #3691  - Engineering Case #224647)=================

Poor performance may have been experienced when prefetch was enabled 
and an application did a commit or rollback after every, (or most), 
fetches in a result set.  Note that many operations (including any SQLExecute) 
will cause an implicit commit if ODBC auto commit is enabled (the default).


=================(Build #3691  - Engineering Case #226335)=================

A threaded client connection running on Solaris using TCP/IP could become 
slow. The slowness is due to Solaris OS/RT failing to dispatch SIGIO 
signals to the client application, ( Sun case #62181499 ). A work around 
has been implemented.




=================(Build #3691  - Engineering Case #226840)=================

If a server was started with a name that was already in use on the network, 
then the NETBIOS port could sometimes have failed to detect it and would 
start up anyway. Once started the server would then utilize the cpu 
at 100%.


=================(Build #3700  - Engineering Case #228841)=================

If a client application running on Windows NT or 2000 shutdown, (eg 
call db_fini or SQLFreeEnv), with an active TCP/IP connection, the application 
would hang with 100% CPU usage.  This problem would also occur on Windows 
98 or Me, if Winsock 2.0 was installed. This problem exists in version 
6.0.3 builds 3037 and later, 6.0.4 build 3594 and later, and 7.0.1 build 
1101 and later


=================(Build #3713  - Engineering Case #233840)=================

Client applications running on CE, using TCP, may have crashed or given 
unpredictable results.


=================(Build #3714  - Engineering Case #234270)=================

If two different 16-bit applications on the same machine attempted to 
connect over TCP at the same time, unpredictable things could have happened. 
They both may have succeeded, (most likely), or one or both may have 
crashed or, (if they were using different port options), one or both 
may have connected to the wrong server.


=================(Build #3717  - Engineering Case #234874)=================

When using SQLGetData or ESQL SQL GET DATA to fetch all columns in a 
result set, and at least one of the GetData's was attempting to fetch 
300 bytes or more or prefetch was disabled, then using GetData to retrieve 
the columns less than 300 bytes would be slow, especially over a network 
connection.



=================(Build #3720  - Engineering Case #235756)=================

Numeric connection parameters would accept negative values, causing 
various problems. The parameters affected were:
LivenessTimeout
CommBufferSize
PrefetchRows (6.0.3.3031+, 7.0.0.450+, 7.0.1.1101+, 7.0.2 and up)
PrefetchBuffers (6.0.3.3031+, 7.0.0.450+, 7.0.1.1101+, 7.0.2 and up)

If negative values are entered for any of these parameters, a parser 
error is now displayed.

Also, the engine switches -ti and -tl would accept negative values. 
This will now display the usage screen.


=================(Build #3732  - Engineering Case #238953)=================

The embedded SQL function db_find_engine could fail if using a 6.x dblib 
but trying to find a 7.0.1 or higher engine.


=================(Build #3736  - Engineering Case #238285)=================

A Unix client, connecting through either ESQL or ODBC, would experience 
a memory leak if it executed multiple calls to db_init()...db_fini(), 
or SQLAllocEnv()...SQLFreeEnv().  The client could also have hung.	



=================(Build #3763  - Engineering Case #261443)=================

A client application running on a Win32 platform could hang during db_fini() 
if a connection was made using IPX. This has been fixed.


=================(Build #3799  - 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.




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

=================(Build #3691  - Engineering Case #226542)=================

It was possible to initiate another database request while one was already 
in progress on 16bit windows, which would result in a double request 
error.  Now, unless a callback is registered from the application to 
process other messages, only messages essential to the system and to 
communication between the application and the database are processed.


=================(Build #3692  - Engineering Case #225587)=================

Opening a cursor using a parameter, fetching some rows, closing the 
cursor and reopening it using a different parameter would not yield 
the correct result set after the second open.
A workaround to the problem is to disable prefetch.


=================(Build #3693  - Engineering Case #226954)=================

The ODBC driver would always override the user's ConnectionName parameter 
with a unique value of its own.  It was requested that we not do this, 
since the connection name is what is displayed on the server screen, 
and it was difficult to determine who was connected.


=================(Build #3712  - Engineering Case #232802)=================

Some memory was leaked in dblib / odbc for each TCP connection made.


=================(Build #3724  - Engineering Case #236630)=================

When attempting to translate or count the length of a UTF8 character 
whose leading byte indicated it was a 4,5, or 6-byte multi-byte character, 
the ODBC driver could go into an infinite loop.


=================(Build #3729  - Engineering Case #237882)=================

A threaded ODBC application calling SQLDisconnect could hang. The hang 
only occured if SQLFreeHandle was not called for statement handles allocated 
on the connection objects. This was only a problem on Unix platforms.


=================(Build #3731  - Engineering Case #238243)=================

If a UNIX application loaded the ODBC driver library, created an environment, 
connected, (or at least attempted to connect) at least once, and then 
unloaded the odbc library without destroying the environment, the application 
could seg fault.

A work-around is to ensure that all ODBC environments are destroyed 
prior to unloading the ODBC driver.


=================(Build #3779  - 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 #3790  - 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 #3796  - 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.





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

=================(Build #3711  - Engineering Case #232741)=================

Two tools, dbping and sstran, were accidentally left off of the Unix 
6.0 installs.  They have been added to the latest Unix EBFs.


=================(Build #3720  - Engineering Case #235757)=================

When using a SELECT statement to fetch data from a proxy table, which 
refers to a Visual Foxpro stand-alone free table, the message: 'Error 
- Command contains unrecognized phrase/keyword.' would be thrown by 
the engine. Now the engine can process these kinds of proxy tables correctly.





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

=================(Build #3595  - Engineering Case #223409)=================

Index corruption could *sometimes* occur if ALL of the follow were true:

- A table has two foreign keys to the same primary key
- The database was initialized with version 6.x or earlier (combined 
PK/FK indexes were used)
- The WAIT_FOR_COMMIT option was used and either foreign rows were 
inserted before the associated primary row was inserted or the primary 
row was deleted before the foreign rows referring to it were deleted 
(ie. the WAIT_FOR_COMMIT OPTION was necessary).

The corruption could cause assertion 200601: "Page for requested record 
not a table page or record not present on page".


=================(Build #3691  - Engineering Case #197950)=================

Starting the UNIX engine/server and requesting a cache size larger than 
the physical memory size, could have caused a crash.  Cache size is 
now limited to 90% of physical memory.



=================(Build #3691  - Engineering Case #214581)=================

The install of a java class may have lead to a database engine crash 
if all of the following conditions were satisfied:
1 - There was already a java class of the same name installed in the 
same database
2 - There were one or more database connections, other than the installing 
connection, that were using the java support, i.e. started a java vm
3 - None of those java-using database connections had yet referenced 
the older version of the installed class
4 - The installing connection disconnected
5 - One of those connections attempted to reference the installed class 
-- crash occured


=================(Build #3691  - Engineering Case #217808)=================

The collation 819SVE did not properly recognize certain Swedish characters 
as alphabetic.


=================(Build #3691  - Engineering Case #224008)=================

When the alter server command was used to change the server class of 
a remote server, the capablities list was not being dropped at the same 
time. The server class usually does nothing more than define the capabilities 
of the remote server hence altering the server class should also alter 
the capabilities for that server. The capability list now gets dropped 
when the server class is altered to allow OMNI to recreate the list 
the next time a connection is made to the remote server.


=================(Build #3691  - Engineering Case #224106)=================

When attempting to update a base table joined with a proxy table as 
follows:
	update a,p_a set a.c1 = p_a.c1 where a.c2 = p_a.c2
where p_a is a proxy table and a is a base table the engine would end 
up setting all of the affected c1 columns to null.  Now you get an attempted 
to update a non-updatable remote query error, which is the correct error 
message since the above update requires a temporary table to be involved 
and we do not handle temp tables with proxy tables.


=================(Build #3691  - Engineering Case #224493)=================

Fetching and then retrieving column data using GetData, with a data 
size of greater than 300 bytes, would give poor performance.



=================(Build #3691  - Engineering Case #224645)=================

When the ASA database java support was used, the ASA server may have 
crashed in the java vm while loading a java class if the server did 
not have enough free cache available to load the class.  The work-around 
was to ensure there was enough cache when loading a class.  With the 
new dynamic cache resizing, this problem will not occur unless the cache 
cannot be resized any larger.



=================(Build #3691  - Engineering Case #225013)=================

The assertions 105201 and 105202 were not very useful, as each was used 
to indicate two different events.  Assertion 105201 could have either 
indicated "Unexpected invalid java native handle" or "CE corruption 
check failed on page 1 write".  Assertion 105202 could have either indicated 
"Java native handle exhausted" or "CE corruption check failed on page 
0 write".  In the fixed versions,  both assertions were removed and 
replaced such that the java handle problem assertions have been replaced 
by 105500 and 105501, and the ce problem assertions have been replaced 
by 105204 and 105205.


=================(Build #3691  - Engineering Case #225425)=================

When executing queries containing a LIKE predicate in the ON condition 
of an outer join, the server could crash if the LIKE predicate only 
referenced the null-supplying side of the outer join.  The crash was 
more likely to occur on 64 bit platforms.



=================(Build #3691  - Engineering Case #225583)=================

A corrupt index could have been generated or incorrect result sets returned 
if all of the following conditions applied:

1. A row in the table required a row extension other than a stub for 
a relocated row. (i.e. the row is longer than one page in length, excluding 
string extensions)
2. An index was defined to refer to a column in a row extension
3. The indexed column was NOT hashed in the index
4. All columns in the row extension preceding the indexed column were 
fixed-length columns, (or the indexed column was the first column in 
the row extension).


=================(Build #3691  - Engineering Case #225635)=================

New server capabilities have been added to allow queries involving proxy 
tables, with either the char_length or replace function, to be passed 
on to the remote server instead of being handled in no passthrough mode. 
Note that the replace function capability is only available in 7.0.0 
and up.


=================(Build #3691  - Engineering Case #226189)=================

If a TDS client connected with the packet size parameter set to a value 
greater than the default value of 512 bytes, then subsequent requests 
to get data could result in protocol errors. The packet size is now 
restricted to 512 bytes (or lower).


=================(Build #3691  - Engineering Case #226197)=================

If a java app running in the database server consisted of two of more 
threads on the same connection, then there was a possibility for problems 
to occur.  One possible problem was that java classes would not load 
properly while two or more threads were active.  An exception like ClassNotFoundError, 
VerifyError, or ClassFormatError may have occurred.  Another more serious 
problem would have been a database engine crash if two or more threads 
were using the server-side jdbc driver.


=================(Build #3691  - Engineering Case #226248)=================

The Dateformat() function could not handle Japanese days-of-week.


=================(Build #3691  - Engineering Case #226443)=================

When a fatal error occured in the ASA server running on Netware, it 
may not have been able to shutdown the ASA server. The Netware server 
would then needed to have been rebooted.Now when a fatal error occurs, 
the ASA server is forcibly shut down. Nothing is cleaned up (i.e. databases, 
memory, sockets, event handlers, etc.), so databases will require recovery, 
and lots of "Module did not release n resources" messages will appear, 
but Netware will not abend.


=================(Build #3691  - Engineering Case #226472)=================

A JDBC connection to a remote server, (via Remote Data Access), may 
have hung on a command that caused a sql error. Other connections to 
the engine were not affected.



=================(Build #3692  - Engineering Case #226044)=================

If a TDS 4.2 client attempted a connection to the server, the server 
may have crashed while processing the login request.


=================(Build #3692  - Engineering Case #226529)=================

It the statement - print 'var1 = %1!, var2 = %2!', var1, var2 - was 
executed over a TDS connection, then the resulting print statement was: 
var1 = %1!, var2 = %2!. The %nn! placeholders were being replaced with 
the appropriate value for non-TDS connections only.


=================(Build #3693  - Engineering Case #220745)=================

If a large blob, (10000 bytes or so), was inserted into a table via 
TDS, the server would more than likely crash.


=================(Build #3693  - Engineering Case #224848)=================

After a wide fetch returned a partial rowset because it was at the end 
of the rowset, a 'fetch relative 0'
operation was advancing off the end of the cursor, instead of returning 
the previous rowset again.



=================(Build #3693  - Engineering Case #224927)=================

If the query generating the result set for a stored procedure contained 
an alias in the SELECT list, and the procedure was called simultaneously 
by several connections, the wrong name could be returned for the aliased 
column. The name returned would be the expression associated with the 
alias. Once this problem happened, it would continue to happen until 
the database was shut down or the procedure was recompiled. The problem 
would be more likely to occur on multi-processor machines. It is fixedby 
this change, but a possible workaround may be to ensure that the ODBC 
datasource describe cursor behavior is defined as "if required" or "never".


=================(Build #3693  - Engineering Case #225693)=================

If a Win32 server was licensed for a certain number of concurrent connections, 
that limit could be exceeded if the connection were by IPX connections.


=================(Build #3693  - Engineering Case #226121)=================

Queries on views for which check options/articles are defined for tables 
used in the views may generate a syntax error. 



=================(Build #3693  - Engineering Case #226728)=================

When upgrading a database, the jcatalog.sql script was only being run 
if an upgrade was actually required; however, some of the changes in 
the script need to be made to current databases as well. As a result, 
jcatalog.sql will now always be run regardless of an upgrade being necessary 
or not. Note that if the jconnect off option is selected for the upgrade, 
then the jcatalog.sql script will not be run as expected.


=================(Build #3693  - Engineering Case #227143)=================

If an index was defined with duplicated columns, a query over the corresponding 
table could result in the server reaching 100% CPU.



=================(Build #3695  - Engineering Case #226950)=================

The 1.1.6 JRE would core dump after loading the odbc driver. Client 
applications that install signal handlers and relay on signal context 
information may core dump on a signal.This was a problem on Unix platforms 
only



=================(Build #3696  - Engineering Case #227697)=================

The engine/server would not start on Unix machines which had 4GB RAM 
installed.  The message:
	Memory not available - cache size set to 0K
	Not enough memory
would be displayed.  A side-effect of this fix is that an engine/server 
running on Unix cannot have a cache size larger than 4GB.


=================(Build #3697  - Engineering Case #227986)=================

The engine could seem to hang and CPU utilization would go to 100%.


=================(Build #3698  - Engineering Case #223813)=================

When the DELAYED_COMMITS option was enabled and a COMMIT operation was 
performed, the commit would not be written to the transaction log immediately 
(as expected); however, the commit was not written within the DELAYED_COMMIT_TIMEOUT 
setting either. The commit would only be written during a checkpoint, 
when the current log page was filled by subsequent
operations being appended to the log, or if a subsequent non-delayed 
commit was performed.


=================(Build #3698  - Engineering Case #226942)=================

The -u switch was silently ignored in 6.0.02 - 6.0.04  on all platforms, 
and in 7.0 - 8.0 on Unix.  By default [on platforms that support it], 
the engine avoids using the file system cache:  all I/Os go directly 
to disk.  The -u switch disables this feature.

If the database is much larger than physical memory, using direct I/O 
almost always gives better performance [cf. QTS 213193].  However, on 
some Unix platforms for small [relative to physical memory] databases, 
using buffered I/O will give better performance.  This is especially 
true for 6.0.x Unix engines where dynamic cache growth is not very aggressive.



=================(Build #3699  - Engineering Case #228359)=================

An expected JDBC SQLException may not have been thrown when using server 
side JDBC.


=================(Build #3699  - Engineering Case #228527)=================

If the update statement was used to update a java-typed column's field's 
field, a conversion error may have been reported.  For example: "update 
myTable set myJavaColumn.javaField.javaField = 123", may have failed.  
The problem would not have  occurred if the class of the javaField was 
the same class or super class of the class of myJavaColumn.


=================(Build #3700  - Engineering Case #228343)=================

The server might have crashed or sent a garbage message if charset conversion 
tables could not be found because: 
	-- .uct files in charset\unicode have been removed or corrupted, or
	--  the full path names of these .uct files contain multibyte characters
These tables are needed if the character set of the database is different 
from the character set of the server's language resource, (which is 
determined by the language setting on from the operating system). For 
example, a Japanese NT4.0 system with a SJIS or SJIS2 database. ( Both 
SJIS and SJIS2 are subsets of the default CP932 character set). The 
server would crash if you have NT Service Pack 4, (crashes occur less 
frequently with Service Pack 5).



=================(Build #3700  - Engineering Case #229250)=================

The property('Platform') function would return "WindowsNT" or "Windows95", 
when the server was running on Windows 2000 or Windows ME respectively. 
On 6.x, a server running on Windows98 would return "Windows95".



=================(Build #3701  - Engineering Case #226929)=================

After a while, a server running on Windows 2000 may stop accepting TCP 
connections.



=================(Build #3701  - Engineering Case #229108)=================

When returning a java object, the send length is always set to 32K since 
we do not know the actual length
of the object until after we serialize it. Once serialized the send 
length was being used to send the large
object rather than the true length.


=================(Build #3701  - Engineering Case #229301)=================

 UPDATE .. PUBLICATION stmts might generate an erronenous syntax error 
or might gpf the asa engine if the subscribe by expressions contain 
subqueries.


=================(Build #3701  - Engineering Case #229432)=================

Using the -gs or -gss switches on the server would set the same value 
for the -gm switch. For example, using -gs 4096 would also implicitly 
add -gm 4096.



=================(Build #3701  - Engineering Case #229876)=================

This change fixes the following two problems:

1 - If the JDBCStatement.setCursorName() was used, the second execution 
of the statement would give a WJ004 exception. Explicitly closing the 
statement, as well removing all references to the statement, did not 
guarantee the cursor name would become available again. The name was 
not freed until the next garbage collection.

2 - The automatically generated cursor name is a hex string. If it 
began with a numeric character, then referring to the cursor name in 
another statement, (say a positioned delete statement), would have resulted 
in a syntax error.



=================(Build #3702  - Engineering Case #228055)=================

If database name contained spaces, dbspawn would complain:
DBSPAWN ERROR: -84 -- Specified database is invalid.

For example, prior to this fix you could not run:
	dbspawn dbeng6 "c:\Program Files\Sybase\Adaptive Server Anywhere 6.0\asademo.db"
	or:
	dbspawn dbeng6 "%ASANY6%\asademo.db"


=================(Build #3702  - Engineering Case #228974)=================

Grouped queries over view containing subselects in the select could 
have generated an erroneous syntax error.
For example:
    Create view V2 (vempid) as select emp_id from employee;
    Create view V1 (orderdate) as select (select first order_date from 
sales_order where sales_rep = vempid) from V2;

Query (A):
    Select orderdate from V1 group by orderdate
would execute correctly, but:
    Select V1.orderdate from V1 group by V1.orderdate 
would not. Utilizing a select list alias, as in

Query (B):
    Select V1.orderdate as foo from V1 group by foo
was a useful workaround.


=================(Build #3703  - Engineering Case #227868)=================

User tables created by the DBO user were not being populated with data 
when
being unloaded or extracted using the -an or -ac switch.



=================(Build #3703  - Engineering Case #228832)=================

A server executable, processing concurrent requests on Windows NT/2000, 
could have GPFed when a tcp/ip connection disconnected or when was disconnect 
due to an idle timeout.  The first problem was rare on multiprocessor 
machines, and even less likely on single processor machines, but the 
idle timeout problem occured on both single and multiprocessor machines.


=================(Build #3704  - Engineering Case #230024)=================

The TCP Broadcast parameter was being ignored. This was also a client 
problem, so a new dblib[6/7].dll or dbodbc[6/7].dll would be required.


=================(Build #3706  - Engineering Case #230423)=================

On a CHECKPOINT or shutdown, the ASA server would erroneously delete 
all join selectivity estimates on all tables currently loaded, including 
system tables. Subsequent queries could suffer from poor performance 
due to poor plan choices using the default values, until enough queries 
were run to repopulate the statistics registry. However, with a default 
checkpoint frequency of 30 minutes, it was quite likely that users would 
see performance problems throughout the period that the server was running.



=================(Build #3707  - Engineering Case #230919)=================

A database server would hang on startup if it was started as a service 
that was not allowed to interact with the desktop, with a command line 
containing no parameters. Now, the server will fail to start.


=================(Build #3707  - Engineering Case #231031)=================

The database server could hang and stop responding to requests while 
a backup was in progress


=================(Build #3708  - Engineering Case #229868)=================

Concatenation in a subquery could cause a crash. For example, the following 
query on asademo.db would crash:
	SELECT  emp_lname,
 	       (select max( distinct dept_name || ' ')
		 from Department
		 where  Department.dept_id = Employee.dept_id
		 and	Department.dept_id=100 )
	FROM Employee



=================(Build #3709  - Engineering Case #231868)=================

The statement:
	comment on java jar 'jar-name' is 'comment-string'
was being logged as:
	comment on java class 'jar-name' is 'comment-string'
This would cause recovery to fail.


=================(Build #3710  - Engineering Case #230348)=================

Assertion failure 50102, in 5.x, or 101504, in 6.x and 7.x, "Memory 
allocation size too large", could be reported when the engine was dealing 
with value sets of certain particular sizes. Wide inserts to a 5.x server 
could be affected by this bug but not wide inserts to a 6.x or 7.x server.


=================(Build #3712  - Engineering Case #213376)=================

Engine may have crashed when stopping a database


=================(Build #3713  - Engineering Case #232226)=================

Windows CE will report IO errors to an application if it accesses files 
on a removable storage card, (eg. Compact Flash), during a short period 
after the CE device is powered on or if the card is ejected. When the 
IO error was reported to the engine/server, an assertion would fail 
and the engine would shut down with a fatal error. In other words, turning 
a CE device off and back on could cause an assertion failure in the 
engine if the database was located on a storage card.

Now when certain IO errors related to removable media occur on CE, 
a message is displayed in the server  window and the operation is retried 
for some duration and, if not successful, a message box is displayed 
to  prompt the user to re-insert the storage card and to ensure that 
storage space is available. The user has the option to retry the operation 
or cancel. Canceling the operation will likely cause an assertion failure 
in the engine.

The engine will now also display a message in the server window whenever 
a PC card has been inserted or removed. Note that these messages will 
also appear when the power is turned off and back on since CE effectively 
ejects and reinserts each PC card when the device is turned on.

This change also corrects a problem where a number of writes could 
be performed by other threads after an assertion failure or a fatal 
error. In rare circumstances, writes occurring after an assertion failure 
or fatal error could conceivably cause database corruption.


=================(Build #3713  - Engineering Case #233905)=================

When starting the network server from the command line or windows without 
specifiying any additional parameters a GUI would pop up where the parameters 
could be specified.  When a server name was specified the resulting 
command line that was generated would be incorrect.  The server name 
would also be used as the database name.  As a result, a user would 
be unable to connect to their database unless they specifed the new 
database name explicitly.  This would only occur when the server name 
specified is different from the default server name.


=================(Build #3714  - Engineering Case #234411)=================

The Win32s engine,dbengw.exe,  would give the following message on startup: 
"The Win32s engine does not run under Windows 9x / NT." and would not 
start. This has been fixed.


=================(Build #3715  - Engineering Case #234443)=================

In the following SQL statement, the "g:" causes a problem. The error 
is "Mismatch between external function platform specifier and current 
operating system [-618] ['WW004']".

	CREATE function gpfTest()
	returns char(50)
	external name 'GPFTEST@g:\src\db\test\tst\extproc.dll'

The work around is to write the external name string as:

	external name 'WindowsNT:GPFTEST@g:\src\db\test\tst\extproc.dll;Windows95:GPFTEST@g:\src\db\test\tst\extproc.dll'

Note that both platforms must be specified if you want it to work under 
both WindowsNT/2K and Windows95/98/ME.



=================(Build #3716  - Engineering Case #213595)=================

Calling the java method System.currentTimeMillis() when running on a 
NetWare server would always return 0 for fractions of a second. On NetWare 
4.x and 5.x, it now returns the correct number of milliseconds. NetWare 
3.x does not support this capability.


=================(Build #3717  - Engineering Case #232779)=================

Queries or view definitions containing GROUP BY with an alias to a subselect 
in the GROUP BY clause could return a syntax error (SQLCODE -149).


=================(Build #3717  - Engineering Case #234829)=================

dateadd( dw, ...) was not supported by ASA.  The workaround is to use 
dateadd( dd, ...) instead.


=================(Build #3717  - Engineering Case #234869)=================

If a permission denied error was received on VALIDATE INDEX, the message 
displayed was "you do not have permission to validate the table 'index_name'". 
It is now  "you do not have permission to validate the index 'index_name'".


=================(Build #3720  - Engineering Case #235450)=================

Starting and stopping the server a few times in quick succession, could 
have caused an assertion error or corruption to the database file. This 
only happened on fast SMP machines running the Linux SMP kernel with 
a version less than 2.2.17. The 2.2.17 kernel seems to have this problem 
fixed. A work around has been implemented, but will only take effect 
if the kernal is less than 2.2.17


=================(Build #3722  - Engineering Case #236228)=================

If streams received data over TCP/IP that it didn't recognize as a valid 
packet, the packet was discarded and the connection was dropped. However, 
depending on the data received, it's possible that the engine would 
have crashed.


=================(Build #3722  - Engineering Case #236318)=================

When the server was busy with multiple concurrent client requests, it 
may have locked up and stopped responding to new or existing connections. 
The only way to unlock it,was to kill and restart the database server. 
This has been fixed


=================(Build #3724  - Engineering Case #236533)=================

On CE devices, if the database character set was different from what 
the client requested, char type data would be mangled. For example, 
with a utf8 database on a Japanese CE device, the ODBC driver would 
return mangled Japanese data. A related problem was that 'select connection_property('charset')' 
would return 'cp932' instead of 'utf8' in this example. This was wrong 
because the ASA Server for CE would only send data to the ODBC driver 
for CE, in the database's character set. Please note that there is no 
way to turn on character set translation for ASA Server for CE even 
with -ct switch.


=================(Build #3724  - Engineering Case #236797)=================

When the server was running on a big endian machine, (e.g. Sparc Solaris, 
AIX, HP UX), any attempt to insert a double value into the database 
would result in a "Value <number> out of range for destination" error, 
when it should not have.


=================(Build #3725  - Engineering Case #216134)=================

If an index has missing entries, the command VALIDATE TABLE would either 
cause the engine to crash or would display the wrong index name in the 
error message.



=================(Build #3726  - Engineering Case #221603)=================

The engine schedules checkpoints based on the checkpoint and recovery 
urgencies.  These scheduled checkpoints should take at most a few seconds 
(usually under 1s) as the engine has time to flush the cache before 
hand.  If many pages are updated (e.g. as a result of inserting many 
rows into an indexed table) these checkpoints could take much longer 
than expected [the time taken being proportional to the number of dirty 
pages] or (7.0 only) stop occuring altogether until a checkpoint was 
manually issued (or the engine was restarted.)


=================(Build #3726  - Engineering Case #237063)=================

Assertions 101412 and 200601 could have been generated while deleting 
rows from a table.  The problem was that table pages where being deleted 
even if a temporary table existed that referenced the table page.  This 
could occur if a scroll cursor was opened on a table and then the rows 
were deleted from the cursor.  Under some circumstances the removed 
page could be requested resulting in the assertions.


=================(Build #3728  - Engineering Case #237522)=================

If a connection was terminated due to the idle or liveness timeout expiring, 
the server could have crashed. The problem was more likely to occur 
on SMP systems and UNIX systems. It is unlikely to occur on single-CPU 
NT systems.


=================(Build #3729  - Engineering Case #237789)=================

The database could become corrupted while attempting to create a foreign 
key between temporary tables.   Assertion 101412 would be generated 
at the time of the database corruption.  When attempting to restart 
the database the error "<database name> is not a valid database file" 
would be generated.


=================(Build #3730  - Engineering Case #238300)=================

When a new connection was made to the server, the message "TCP Listener 
shutting down (2:10038)" could have been displayed, after which no new 
TCP connections would be accepted by the server.



=================(Build #3730  - Engineering Case #238442)=================

Queries with an IN list, where the data values had to be converted to 
the same data type as the column, could suffer a performance penalty.


=================(Build #3733  - Engineering Case #238632)=================

When the OS ran out of memory, and a new client application attempted 
to connect, the application may have hung during the connect.

Generally, allowing the OS to run out of memory may cause many different 
effects ranging from a hung server or client, to many different server 
assertions (including an "out of memory" error).  Most of the server 
allocations come out of the configured memory cache, (designated by 
the -c switch), but some of the server's allocations, including the 
communication buffers, use system memory.  Normally this is not an issue 
since the server will do an initial set of allocations during the first 
few client sessions, and then reuse this memory.

Periodically under heavier loads, the server will need to do more allocations 
from system memory, and thus hit a newer "high water" mark.  If at the 
time that the server needed to increase this "high water" mark, due 
to an increase load, the server cannot allocate any more memory, (or 
extend its size of shared communication memory), due to a system wide 
out-of-memory, (or out-of-address space), problem, the server would 
assert or possibly hang.

This fix now causes the server to issue a fatal assertion error when 
such an internal fatal error occurs (#105600), or runs out of memory 
(# 105601).


=================(Build #3737  - Engineering Case #239551)=================

Attempting to start a database via TDS, (ie jConnect), could have crashed 
the server, if the path/filename of the database was greater than 30 
bytes in length.


=================(Build #3737  - Engineering Case #240254)=================

If a UNIX server received a corrupted packet, the server could get into 
a state where:
a) it would use 100% of the CPU, and
b) new connections, (tcp/ip or shared-memory), would hang.
Existing connections would appear to work normally. Now, a "Spurious 
packet" message will be issued, and the erroneous connection will be 
dropped.


=================(Build #3738  - Engineering Case #235876)=================

Inserting an invalid date value with year greater then 9999 through 
TDS would succeed.  For example, a Java application using jConnect could 
insert the value '20000, 01,01'.  Fetching the value from the database 
without going through TDS would display the date as '****-01-01'.  

The error message 'The specified date is invalid' is now returned when 
attempting to insert the invalid date.


=================(Build #3741  - Engineering Case #240440)=================

If a trigger was executing, dropping or altering a view may have caused 
the engine to crash. The same problem could occur when doing a grant 
or revoke, if the server was running in C2 mode (i.e. with the -sc switch).


=================(Build #3742  - Engineering Case #240563)=================

Dropping a view would leave a shared lock on each table in the database 
that has a foreign key containing 'on update' or 'on delete' constraints. 
Attempting to perform DDL on these tables would block until the connection 
that dropped the view does a commit or rollback, performs some other 
DDL, or disconnects. This shared lock is now released.


=================(Build #3743  - Engineering Case #241089)=================

The database server could go to 100% utilization when attempting to 
insert a string into a proxy table.  This problem would only occur with 
a database using a multi-byte character set and a remote server that 
was defined to use one of the JDBC-based server classes



=================(Build #3744  - Engineering Case #241534)=================

All threaded UNIX clients and UNIX servers would not properly perform 
liveness checks on TCP/IP connections to ensure that the other side 
was still alive.
Note that non-threaded UNIX clients do not perform liveness checks 
by design since the application may execute for a prolonged period of 
time without calling into the ASA libraries.

This problem would have affected any client, on any platform, if it 
were connected to a server running on UNIX, (e.g. an NT client connected 
to a UNIX server would not have the appropriate liveness checks performed). 
It also affected any threaded UNIX client that was connected to a server 
running on any platform, (e.g. a threaded UNIX client connected to a 
server running on NT, would not have any liveness checks).

Note that this problem would not be an issue when engine/client would 
die since the other side would be notified when the socket was closed.
This is an issue if either side were to hang in such a way that the 
liveness packets were not processed properly (e.g. the client or engine 
was suspended, or the threads were somehow corrupted).



=================(Build #3744  - Engineering Case #241827)=================

The jdk class java.util.Locale's class initializer causes the jdk class 
java.lang.System's method arraycopy() to be called, which in turn causes 
the System class initializer to be called.  In the System class initialization, 
a method on Locale is called that returns a value that be initialized 
in the Locale class, but because Locale's class initializer has not 
been completed, a null value is returned.  This causes the NullPointerException.  
The work-around is to cause the System class to be loaded, for example: 
System.gc().  The fix was to load the System class during VM initialization.



=================(Build #3747  - Engineering Case #242660)=================

Creating a view that references a non-existent procedure could have 
caused the engine to crash.   The following script is an example of 
the behaviour.

Create table test (col1 int);
Create View view_test as select * from test where col1 < dba.Does_Not_Exist(1);

An error message is now returned that indicates that the procedure 
cannot be found.


=================(Build #3749  - Engineering Case #242860)=================

An attempt to create a primary key/foreign key/index could succeed when 
the statement should fail with one of the following error messages:

1)  No primary key value for foreign key 'foreign_key_name' in 'table_name'
2)  Index 'index_name' for the table 'table_name' would not be unique
3)  Primary key for table 'table_name' is not unique

The resulting database would appear to be corrupt when using the version 
7.0.x DBVALID utility using the WITH INDEX CHECK (-fi) option.
Any such corrupt index should be dropped and re-created.

After this fix, any attempt to create invalid indexes will fail with 
the appropriate error message listed above.


=================(Build #3749  - Engineering Case #254922)=================

The server could crash while executing the CREATE EXTERNLOGIN statement 
if the 'IDENTIFIED BY remote_password' is clause is used with a password 
longer than 28 bytes.


=================(Build #3750  - 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 #3753  - Engineering Case #256623)=================

Engine could GPF during database recovery phase after a dirty shutdown.


=================(Build #3756  - 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 #3756  - 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 #3757  - Engineering Case #238498)=================

Dropping a large number of dummy_pub publications (over 1000)  from 
a reload.sql generated by dbunload or dbxtract was extremely time consuming.



=================(Build #3758  - Engineering Case #255945)=================

Large SQL statements could have caused the server to report a SQL Statement 
error while parsing them. Using the -gss switch, to increase the thread 
stack size, would work around this.


=================(Build #3765  - 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 #3768  - 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 #3772  - 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 #3772  - 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 #3772  - 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 #3772  - 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 #3774  - Engineering Case #267049)=================

A fetch could have failed unexpectedly when changing direction in a 
dynamic cursor over a query that useed a combined, (6.0 and earlier 
format), index to satisfy an equality search condition.

  For example:

strcpy(stmnt, "SELECT credential_id FROM table_acs_patron where credential_id
'00000000000000000066' and Facility_code = '0000003120'");

EXEC SQL PREPARE :stat FROM :stmnt;
EXEC SQL DECLARE :cursname DYNAMIC SCROLL CURSOR FOR :stat FOR READ 
ONLY;
EXEC SQL OPEN :cursname;

EXEC SQL FETCH ABSOLUTE 1 :cursname INTO :cred_id;
EXEC SQL FETCH RELATIVE -1 :cursname INTO :cred_id;
EXEC SQL FETCH RELATIVE 1 :cursname INTO :cred_id;

the third fetch could have failed with SQLSTATE=100, even if the first 
fetch succeeded.

Note that this does not affect applications running against 7.0 and 
newer databases.


=================(Build #3774  - 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 #3776  - 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 #3777  - Engineering Case #215312)=================

If an application, running with CHAINED mode set to OFF, closed a cursor, 
locks were not being released because ASA releases locks upon commit/rollback 
only. The server now performs an implicit commit while a closing a cursor, 
if the following conditons are satisfied:
a) the value of the database option CHAINED is set to OFF, and
b) the application does not have a pending transaction started via 
BEGIN TRANSACTION


=================(Build #3781  - 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 #3781  - 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 #3783  - 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 #3784  - 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 #3786  - 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 #3787  - 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 #3787  - 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 #3787  - 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 #3788  - 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 #3790  - 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 #3794  - 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 #3794  - 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 #3799  - 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 #3799  - 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.




                      ******************************                      
                      ** Adaptive Server Anywhere **                      
                      **                          ** 
                      **  Sybase Central Plug-in  **                      
                      ******************************                      

=================(Build #3691  - Engineering Case #223790)=================

If a null java object was returned from the engine, the TDS layer would 
not send out the 0 length for the object
and would end up causing a TDS protocol error.



=================(Build #3701  - Engineering Case #225641)=================

dbxtract was only adding 'CREATE DBSPACE' entries to the reload.sql 
file for thse dbspaces which had tables that were being unloaded as 
part of the extract.  It did not add 'CREATE DBSPACE' statements for 
any indices that were extracted.


=================(Build #3711  - Engineering Case #227120)=================

When creating a publication with a large number of tables using "Add 
Publication", a syntax error could result when the Finish button was 
clicked. This problem appeared under Windows 95/98 only.


=================(Build #3742  - Engineering Case #239902)=================

Adding a foreign key using Sybase Central, (3.2 version only), would 
fail with a syntax error. Logging the SQL statements would show that 
the statement trying to be executed was garbled. This has been fixed.


=================(Build #3799  - 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.




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

=================(Build #3691  - Engineering Case #224930)=================

If DBStop failed to stop a running engine/server, it still would sometimes 
return SUCCESS.


=================(Build #3692  - Engineering Case #226757)=================

When Using DBUnload with the -t switch to only unload specific tables, 
data for the ml* and ul* tables were always unloaded regardless of whether 
or not they were specified in the table list.


=================(Build #3698  - Engineering Case #228225)=================

If the database unload utility, dbunload, was given an option that conflicted 
with -ar, as well as the option -ar, (eg. dbunload -an foo -ar), rather 
than reporting an error and the usage, it would crash.


=================(Build #3698  - Engineering Case #228346)=================

Upgrades on databases created with SQL Anywhere version 5.5.05 and earlier 
may have had problems when then using Java in the database features. 
When the upgraded database was used by an ASA server on unix, the java 
vm would not start, i.e. the java support will not work. The java support 
would work with a server on Windows, (95, 98, NT, ME, 2000), Netware, 
Linux, and Intel Solaris, but would have had a limitation on the total 
number of classes installed.  The database would be limited to a maximum 
of about 32,000 classes installed.  Any class installed after this would 
get the error  - primary key for table 'SYSJAVACLASS' is not unique'.

The problem has been fixed.  Any upgrades on 5.5.05 and earlier will 
upgrade to support the java support properly.  Databases already upgraded 
prior to this fix will support Java in the database correctly by upgrading 
again. with this fix.


=================(Build #3721  - Engineering Case #234723)=================

Running dblog on a database file larger than 2GB would give the following 
error message:
Unable to open database file "{database name}"-- Unknown error (79). 
This has now been fixed.



=================(Build #3725  - Engineering Case #235229)=================

 If an index has missing entries, VALIDATE TABLE would either cause 
the engine to crash or would display the wrong index name in the error 
message.



=================(Build #3746  - 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 #3750  - 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 #3753  - Engineering Case #256771)=================

dbstop using the old-style connection parameters, (ie. "dbstop -c dba,sql") 
would have failed.


=================(Build #3753  - Engineering Case #256959)=================

UPGRADE DATABASE would fail on a database that was created with ASE 
compatibility. If a database did not contain the view SYS.SYSCOLUMNS 
(as a result of ASE compatibility) then the UPGRADE would fail with 
a table not found error.  After the failure the database is no longer 
recognized as a valid database file.  The problem would only occur on 
databases that did not need to be upgraded.  For example, upgrading 
a 5..5.0.x databases to 7.0.3 would succeed the first time UPGRADE DATABASE 
was executed but would fail the second time.  Upgrading a 7.0.x database 
would have the problem the first time UPGRADE DATABASE was executed.



=================(Build #3754  - 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 #3767  - 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 #3768  - 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 #3769  - Engineering Case #265726)=================

The classic version of dbisql was ignoring the DBS connection parameter. 
The DBS parameter is now respected.


=================(Build #3771  - 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."




               *********************************************               
               ** SQL Remote for Adaptive Server Anywhere **               
               **                                         ** 
               **        Database Tools Interface         **               
               *********************************************               

=================(Build #3691  - Engineering Case #224224)=================

If the engine was killed or the SQL Remote connections were dropped 
when SQL Remote was running, SQL Remote would generate lots of messages. 
SQL Remote now generates a proper error message and avoids printing 
misleading messages.



=================(Build #3691  - Engineering Case #226024)=================

When an article contained a "subscribe by" and a "where clause", SQL 
Remote may not have replicated deletes back to
the remote site if the rows were initially inserted by this remote 
user, but they don't satisfy the subscription value.



=================(Build #3701  - Engineering Case #230858)=================

The receiving phase of SQL Remote may have become much slower, if errors 
occured when it was applying
incoming messages.


=================(Build #3701  - Engineering Case #231199)=================

In verbose mode, SQL Remote may have shown the same transaction multiple 
times.  For instance, if an error (deadlock, conflict update, etc.) 
occurred when it was applying the third transaction from an incoming 
message, it would re-apply transaction without grouping or buffering 
the operations.  But in the retry, SQL Remote would show the first and 
second transactions as well.  This behaviour was confusing, so now SQL 
Remote will only display the SQL statements that will be applied or 
re-applied.



=================(Build #3711  - Engineering Case #232829)=================

Upgrading the Adapive Server Anywhere software from version 5.5.0x to 
6.0.x or 7.0.x, or from version 6.0.x to 7.0.x, without upgrading the 
databases as well, would cause SQL Remote to complain and refuse to 
run. This restriction has been removed.



=================(Build #3718  - Engineering Case #233841)=================

If a 5.5.x remote database was upgraded to 6.0.x or 7.0.x, but SQL Remote 
had never been run against it before being upgraded, 6.0.x or 7.0.x 
SQL Remote may not have sent out any messages to the consolidated database. 
This is now fixed.


=================(Build #3728  - Engineering Case #237220)=================

DBRemote could delete old logs on databases initialized with -b, (blank 
padding of strings for comparisons), even if the value set for delete_old_logs 
was 'Off'.




             *************************************************             
             **   SQL Remote for Adaptive Server Anywhere   **             
             **                                             ** 
             ** File Messaging for Adaptive Server Anywhere **             
             *************************************************             

=================(Build #3724  - Engineering Case #234715)=================

SQL Remote will now pause between unsuccessful delete attempts when 
using the FILE messaging system.





             ************************************************             
             **  SQL Remote for Adaptive Server Anywhere   **             
             **                                            ** 
             ** Ftp Messaging for Adaptive Server Anywhere **             
             ************************************************             

=================(Build #3732  - Engineering Case #238873)=================

After rejecting an incoming message and printing an error such as: "Not 
applying operations that have already been applied", dbremote could 
have crashed if it failed to delete the message.




                           *********************                           
                           **    UltraLite    **                           
                           **                 ** 
                           ** MobiLink Server **                           
                           *********************                           

=================(Build #3698  - Engineering Case #217910)=================

In some circumstances, the MobiLink Synchronization Server worker threads 
became unavailable when TCP/IP-based connections disappeared during 
synchronization. The worker threads were stuck waiting for replies from 
the remote that never come. If all worker threads reached this state, 
MobiLink could not process synchronizations. Similarly, MobiLink clients 
could have become blocked if the connection disappeared in such a way 
that the OS could not detect the loss.

The TCP/IP-based streams that are used during MobiLink synchronization 
now accept a new parameter, both on the client and server side:

	keep_alive=[0|1]

To enable liveness checking in 7.0.0 MobiLink, for example, your command 
line would contain the following:

	dbmlsrv7 -x tcpip{keep_alive=1} ....
	
keep_alive=0 turns off TCP/IP  liveness checking, and 1 enables it. 
The default is 1 (liveness detection enabled). If the OS network layer 
doesn't support TCP/IP liveness checking, this parameter is ignored.

NOTE: The initial default for keep_alive on was 0 (OFF), for "backward 
compatibility". We have found that many customers expect the option 
to be ON by default, and we now agree. The builds that have 0 (OFF) 
as a default are as follows

	6.0.03  3040 - 3092
	6.0.04  0000 - 3697
	7.0.0      455 - 496
	7.0.1    1103 - 1148

Subsequent builds have 1 (ON) as the default keep_alive value.

Consult the documentation for your OS to determine how to configure 
liveness checking (eg. how often to check, how long to delay between 
checks, etc.). In particular, look for whether or not the TCP/IP socket 
option called SO_KEEPALIVE is implemented for your OS and/or network 
layer, and how to configure its behaviour. For Windows 95 and NT, for 
example, see the MSDN article Q140325 "How to Determine Loss of Client/Server 
Connection".



=================(Build #3720  - Engineering Case #215270)=================

When the consolidated database was Sybase ASE 11.5, and the default 
ODBC drivers were used, MobiLink reported a "String data, right truncated" 
error for every varchar value containing thirty-one (31) characters 
or more.
This problem only affected 6.0.3 (and earlier) clients connecting to 
6.0.3 or 7.0.0 MobiLink servers. 



