

SQL Anywhere Bug Fix Readme for Version 8.0.3, build 5574
=========================================================




Contents
========


* Description of download types
  o Express Bug Fixes
  o Maintenance Release


* 8.0.3 Behavior Changes and Critical Bug fixes
  o Adaptive Server Anywhere - Server (6)


* 8.0.3 New Features
  o Adaptive Server Anywhere - JDBC Client Library (1)
  o Adaptive Server Anywhere - Server (1)
  o MobiLink - scripts (1)
  o UltraLite - Runtime Libraries (1)


* 8.0.3 Bug fixes
  o Adaptive Server Anywhere - ADO.Net Managed Provider (28)
  o Adaptive Server Anywhere - DBLIB Client Library (16)
  o Adaptive Server Anywhere - JDBC Client Library (10)
  o Adaptive Server Anywhere - ODBC Client Library (15)
  o Adaptive Server Anywhere - OLEDB Client Library (53)
  o Adaptive Server Anywhere - Other (9)
  o Adaptive Server Anywhere - Server (295)
  o Adaptive Server Anywhere - Sybase Central Plug-in (11)
  o Adaptive Server Anywhere - Utilities (52)
  o MobiLink - Charset Conversion (UNILIB) (1)
  o MobiLink - Java Plugin for Sybase Central (1)
  o MobiLink - Monitor (2)
  o MobiLink - SA Client (27)
  o MobiLink - Synchronization Server (25)
  o MobiLink - Utilities (6)
  o SQL Remote for Adaptive Server Anywhere - Extraction Utility for
    Adaptive Server Anywhere (1)
  o SQL Remote for Adaptive Server Anywhere - File Messaging for Adaptive
    Server Anywhere (3)
  o SQL Remote for Adaptive Server Anywhere - Mapi Messaging for Adaptive
    Server Anywhere (1)
  o SQL Remote for Adaptive Server Anywhere - SQL Remote Message Agent (7)
  o UltraLite - CodeWarrior plugin (1)
  o UltraLite - HotSync Conduit (1)
  o UltraLite - Runtime Libraries (6)
  o UltraLite - UltraLite Schema Painter (3)
  o UltraLite - Utilities (3)


* Some useful links

  o iAnywhere.com Support Page -
    http://www.ianywhere.com/support/support.html
  o EBF downloads page - http://downloads.sybase.com
  o SQL Anywhere newsgroups -
    http://www.ianywhere.com/support/newsgroups.html
  o SQL Anywhere Main Page (links to evaluation software, tech support,
    whitepapers, etc) - http://www.ianywhere.com/products/sql_anywhere.html
  o SQL Anywhere supported platform matrix -
    http://www.ianywhere.com/products/supported_platforms.html


================================================================================



Description of 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:
    Frequently asked Questions




================================================================================



8.0.3 Behavior Changes and Critical Bug fixes
=============================================



If any of these bug fixes apply to your installation, iAnywhere strongly recommends
that you install this fix.  Specific testing of behavior changes is recommended.




  Adaptive Server Anywhere - Server



    ================(Build #5512  - Engineering Case #454858)================

	The server could have crashed when performing a LOAD TABLE into a temporary 
	table. Certain requirements are now properly enforced when loading into temporary 
	tables. A commit is now performed prior to the load, and after a successful 
	load, for any table except a LOCAL TEMPORARY TABLE with ON COMMIT DELETE 
	ROWS.  A partial LOAD TABLE into a temporary table due to a failure will 
	result in the entire contents of the table being removed, including rows 
	in the temporary table which were present prior to the load.  Previously, 
	a partial load would have resulted in the rows loaded to that point being 
	left in the table, while others were missing.  Since rows are removed from 
	a temporary table on error, it is now also required that there be no foreign 
	rows already referencing rows in the table being loaded.  As a result, loading 
	into a temporary table already containing rows with foreign key references 
	from another table will result in an error.

    ================(Build #5502  - Engineering Case #452911)================

	A database that had gone down dirty, could have become corrupted during recovery. 
	This would only have occurred if the database contained a very large checkpoint 
	log (greater than 32512 pages for a database with 4Kb pages), which means 
	that at least this many pages would have been altered in the database file 
	since the last checkpoint.  The symptoms of the corruption could be many 
	different assertions including assertion 202101 - "Invalid bitmap links on 
	page {page_num}". Also, validation errors could have resulted due to this 
	corruption as well.  This problem is now fixed.
	
	It's possible that this corruption could be prevented by increasing the 
	server checkpoint urgency.  The more often checkpoints occur the less likely 
	one is to get a database with a very large checkpoint log.
	
	As always it is important to maintain a tested backup and recovery strategy.  
	Having a valid backup database in this case allows one to apply the current 
	transaction log to that backup to recover all transactions.

    ================(Build #5307  - Engineering Case #405103)================

	An outer hash join could have failed to return rows that should have been 
	generated from a preserved row that had no matching row from the null-supplied 
	table. In order for this problem to occur, the following conditions must 
	have been met:
	
	- An outer hash join operator was used in the query execution plan
	- The build input to the hash join was larger than would fit into memory
	- Further, the order of rows had to match a particular set of conditions, 
	and memory usage in the rest of the query plan had to match a particular 
	state
	
	When the problem appeared, the set of missed rows would vary depending on 
	current server state. This problem has been fixed.
	

    ================(Build #5178  - Engineering Case #370998)================

	The problem addressed by changes for Engineering Case 323973, was reintroduced 
	by the changes for Case 369727. 
	
	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 now been fixed.

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

    ================(Build #5117  - Engineering Case #351733)================

	If a transaction deleted rows from a table concurrently with another transaction 
	inserting rows, there was a chance of database corruption. While this was 
	more likely to occur on multiprocessor and Unix systems, it was still possible 
	for it to have occurred on single processor and Windows systems.  Corruption 
	was also possible solely with concurrent deletes, but only in very rare circumstances. 
	This has been corrected.




================================================================================



8.0.3 New Features
==================



This section contains a description of new features added since the release
of version 8.0.3.




  Adaptive Server Anywhere - JDBC Client Library



    ================(Build #5299  - Engineering Case #403934)================

	The iAnywhere JDBC driver has been enhanced so that it supports the Sun JDBCODBC 
	subprotocol for the URL definition in addition to the current definition. 
	As a result, applications can now use URLs of the form:
	
		jdbc:odbc:&ltdata-source-name&gt[;&ltattribute-name&gt=&ltattribute-value&gt]*



  Adaptive Server Anywhere - Server



    ================(Build #5311  - Engineering Case #406845)================

	A new character set conversion mapping table has been added to provide Microsoft-compatible 
	conversion to and from CP932 (Japanese). In the existing mapping table, &ltinstall&gt\charsets\unicode\cp932ms.uct, 
	certain characters that appear more than once in CP932 map differently from 
	Microsoft conversion functions. By copying the new file, cp932ms3.uct, over 
	cp932ms.uct, mappings will be 100% compatible with the Microsoft mappings. 
	The affected characters in CP932 are 81CA, 8754-875D, 8782, 8784, 878A, EEF9, 
	FA4A-FA54, FA58-FA5A. As noted, for these characters, the same Japanese characters 
	occur as two different character codes in the character set.
	
	It is important that this file be copied over cp932ms.uct before any use 
	of a database in the environment. In particular, it is recommended that this 
	file copy occur immediately after deploying Adaptive Server Anywhere and 
	a database and prior to running an application against the database. If the 
	file copy occurs after the database has been in use, the altered character 
	mappings may cause data values to change, even though the appearance of the 
	characters remains unchanged. In a synchronization environment, these data 
	changes may cause unexpected errors.



  MobiLink - scripts



    ================(Build #5337  - Engineering Case #416088)================

	The MobiLink server's .Net scripting only supported version 1 .NET CLR. The 
	MobiLink server would have failed to start if it attempted to load version 
	2 .NET CLR. The error reported in the log was: " [-10192] Could not create 
	domain 'DefaultMobiLinkDNetScriptingDomain' ". The -clrVersion option could 
	have been used to force the loading of a version 1 .NET CLR, if the fix for 
	Engineering case 409377 had been included in the version of the software, 
	(i.e. -sl dnet(-clrVersion=v1.0.3705 ... ).  Now support has been added for 
	.NET CLR version 2 as well. 
	



  UltraLite - Runtime Libraries



    ================(Build #5292  - Engineering Case #379836)================

	UltraLite can now be run on Palm NVFS devices, and supports both the record-based 
	and file-based data stores. 
	
	This is a summary of UltraLite clarifications for the Palm OS platform.
	
	A. Database
	An internal file volume may also be present on some NVFS devices, such as 
	Tungsten T5 handhelds, which can be accessed and used similar to an SD slot. 
	Therefore, ULEnableFileDB is called to store UltraLite databases on either 
	an internal drive (built-in storage card) or external slot (expansion card). 
	Furthermore, the existing connection parameter palm_db=CRID:n is used to 
	specify the data store on either an internal drive or external slot, where 
	n is the volume ordinal from enumerating the mounted volumes, and the default 
	value of n is 0. Tungsten T5, for example, has two volumes, the internal 
	file volume and the SD slot volume. If the device cannot locate a volume 
	with the user-specified volume ordinal, the SQLCODE -82 is reported when 
	opening the database.  ULEnablePalmRecordDB is called to store record-based 
	UltraLite databases.
	
	B. Synchronization Conduit
	The conduit synchronizes the first UltraLite database which is found on 
	the device. The database lookup sequence is first the record storage, then 
	the file system including internal drive and external slot. The UltraLite 
	database which is intended to be synchronize should be made available as 
	the first one found in that sequence. The conduit has been designed to work 
	like this, since the file-based data store support was first added to the 
	Palm platform. 





================================================================================



8.0.3 Bug fixes
===============

(see also Critical Bug Fixes) (see also New Features)

This section contains a description of bug fixes made since the release
of version 8.0.3.



  Adaptive Server Anywhere - ADO.Net Managed Provider



    ================(Build #5304  - Engineering Case #405060)================

	When Connection Lifetime was specified in a connection, the connection duration 
	would have been incorrect. This has been fixed so that the behaviour is as 
	follows:
	- If the time span exceeds the value specified by Connection Lifetime, the 
	connection will be destroyed when it is closed.
	- If the time span does not exceed the value specified by Connection Lifetime, 
	the connect will be returned to the pool when it is closed.
	

    ================(Build #5299  - Engineering Case #403057)================

	Calling the ChangeDatabase method would have resulted in the provider looking 
	for name of the DSN, instead of the database name. The ChangeDatabase method 
	has been corrected to now use the DatabaseName(DBN) connection parameter 
	to change the current database.
	

    ================(Build #5289  - Engineering Case #400563)================

	It was not possible to call a stored procedure via ADO.Net and have it to 
	use the default values for the stored procedure parameters, unless the parameters 
	were at the end of the list. This has been resolved by adding a new class 
	ASADefault/SADefault to the .NET provider. If the value of a parameter is 
	set to AsaDefault/SADefault.Value, the server will use the default value 
	to execute the procedure.
	
	For example:
	
	create procedure DBA.myproc( in arg1 int default 1, in arg2 int default 
	2, in arg3 int default 3)
	begin
	        select arg1 + arg2 + arg3 from dummy;
	end
	
	To use the default values, set the parameters' value to SADefault.Value:
	
	SAConnection conn = new SAConnection( "DSN=SQL Anywhere 10 Demo" );
	conn.Open();
	        
	SACommand cmd = new SACommand( "DBA.myproc", conn );
	cmd.CommandType = CommandType.StoredProcedure;
	
	cmd.Parameters.Add( new SAParameter( "arg1", SADefault.Value ) );
	cmd.Parameters.Add( new SAParameter( "arg2", SADefault.Value ) );
	cmd.Parameters.Add( new SAParameter( "arg3", SADefault.Value ) );
	
	int val = ( int ) cmd.ExecuteScalar();
	

    ================(Build #5260  - Engineering Case #392294)================

	If the server was already stopped, the AsaClient would have thrown an exception 
	when closing the connection. The AsaClient was checking the error code when 
	closing the connection and threw the exception if the error code is not -85 
	Communication error. The AsaClient now ignores error whem closing the connection.

    ================(Build #5258  - Engineering Case #391887)================

	Calling the method AsaDataReader.GetSchema() could have generated the exception: 
	"ASA .NET Data Provider: Column 'table_name' not found (-143)", if the database 
	also had a user table named systable. This has now been fixed by qualifying 
	references to system tables with the SYS owner name. 

    ================(Build #5242  - Engineering Case #387070)================

	The the method AsaDataAdapter.Fill may have caused an InvalidCastException 
	if the query returned columns which had the same name and different data 
	types. This problem has been fixed, but it is not recommanded to use duplicate 
	column names when filling a DataSet.

    ================(Build #5239  - Engineering Case #386109)================

	The AsaDataAdapter object was very slow when filling a DataSet or a DataTable 
	which had primary key. This problem has been fixed.

    ================(Build #5236  - Engineering Case #385349)================

	When inserting Multi-byte Character Set strings, by passing them as parameters 
	to the AsaCommand method, the strings were not saved. This has ben fixed.
	

    ================(Build #5217  - Engineering Case #379532)================

	The same command object could have been deleted twice when running in a multi-threaded 
	environment. This could potentially have caused a crash. The problem has 
	been fixed.

    ================(Build #5212  - Engineering Case #378360)================

	The Data Adapter did not set IsKey property to true when filling a DataTable 
	if the source tables had unique indexes. This problem has been fixed.

    ================(Build #5195  - Engineering Case #374580)================

	An InvalidCastException would have been thrown when filling a DataTable using  
	AsaDataAdapter, if a returned TIME column was mapped to a STRING column in 
	the DataTable. 
	This problem has been fixed.

    ================(Build #5180  - Engineering Case #371411)================

	The isolation level for a transaction was being set to 1 when the connection 
	was opened. Now, the isolation level is no longer set to any specific value. 
	The server default is the value defined for the connection by the database 
	option Isolation_level.
	
	Note, this problem was introduced in the following builds:
		8.0.3 5128
		8.0.2 4442
		9.0.2 2528
		9.0.0 1333
		9.0.1 1887
	The old behavior is now restored

    ================(Build #5176  - Engineering Case #370326)================

	The method AsaDataReader.GetSchemaTable() may have caused an InvalidCastException 
	when the data reader had some unique columns and computed columns. This problem 
	has been fixed.

    ================(Build #5173  - Engineering Case #369704)================

	When filling a DataSet using the ASADataAdapter object, the AutoIncrement 
	property of DataColumn was not set properly.  This has now been fixed.

    ================(Build #5162  - Engineering Case #367464)================

	The ASACommandBuilder class could not derive parameters if the stored procedure 
	name was quoted. Fixed by parsing the command text and using an unquoted 
	procedure name for deriving parameters.
	

    ================(Build #5162  - Engineering Case #363211)================

	A FillError exception was not thrown when an error occurred during a fill 
	operation of the ASADataAdapter object. Now, when an error occurs during 
	a fill operation, the adapter will call the FillError delegate. If Continue 
	was set to true, the adapter will continue the fill operation. Otherwise, 
	it will throw the exception.

    ================(Build #5158  - Engineering Case #366428)================

	The AsaCommandBuilder class could not have generated INSERT, UPDATE or DELETE 
	statements for parameterized queries if the parameters were not provided. 
	Now, if the command is a stored procedure, the AsaClient will call AsaCommandBuilder.DeriveParameters 
	to add parameters for the SELECT command. If the command is text, the AsaClient 
	will add some dummy parameters.

    ================(Build #5148  - Engineering Case #364573)================

	It was not possible to assign an enum value to AsaParameter.Value without 
	an explicit cast. Now when AsaParameter.Value is set to an enum value, the 
	AsaParameter.AsaDbType is set to the underllying type of the enum value (Byte, 
	Int16, UInt16, Int32, UInt32, Int64 or UInt64) and the value is converted 
	to the underlying type.

    ================(Build #5143  - Engineering Case #363177)================

	An application that created multiple threads, and opened and closed pooled 
	connections on each thread, could possibly have had the threads become deadlocked, 
	causing come connections to fail, if the 'Max Pool Size' was smaller than 
	the number of threads. This problem has been fixed.

    ================(Build #5130  - Engineering Case #360761)================

	Calling the AsaDataAdapter.Fill method multiple times on the same DataTable 
	that had a primary key, woulkd have caused a 'System.Data.ConstrainException' 
	exception on the second call. Now, if a primary key exists, incoming rows 
	are merged with matching rows that already exist. If no primary key exists, 
	incoming rows are appended to the DataTable. If primary key information is 
	present, any duplicate rows are reconciled and only appear once in the DataTable.
	

    ================(Build #5129  - Engineering Case #360591)================

	A data reader opened with a select statement would have held a lock on the 
	table, even after the data reader had been closed. This has now been fixed.

    ================(Build #5123  - Engineering Case #359136)================

	UltraLite.NET has a simpler error system and thus does not have the ADO Errors 
	collection. In order to make it easier to move from UltraLite to ASA, two 
	new properties have been added, AsaException.NativeError and AsaInfoMessageEventArgs.

    ================(Build #5120  - Engineering Case #358333)================

	A NullReferenceException could have occurred when fetching long varchar or 
	long binary date using the DataReader object. This problem has been fixed.

    ================(Build #5120  - Engineering Case #353442)================

	Calling stored procedures with long varchar or long binary output parameters, 
	would have resulted in the data being corrupted after 32K. The AsaClient 
	was always using a default maximum length of 32K. This problem has been fixed.

    ================(Build #5119  - Engineering Case #355145)================

	A .NET  application, using multiple database connections through separate 
	threads, could have hung when updating the same table in different threads. 
	When this situation occurred, one thread would have been blocked in the server 
	(which is expected, as it is blocked against the other connection which is 
	holding a lock on the table as a result of its update), and the other thread 
	would appear to be hang as well, but it would not have been blocked in the 
	server. What was happening was that  the first thread had entered a critical 
	section and was waiting for the server's response, while the second thread 
	was waiting to enter the same critical section, thus caused the application 
	hang. This has been fixed.

    ================(Build #5117  - Engineering Case #355929)================

	The ASA provider could have loaded the wrong unmanaged dll, (dbdata8.dll 
	or dbdata9.dll), if multiple version of ASA were installed. Now, the ASA 
	provider will search for the unmanaged dll and will continue searching until 
	it finds and loads the right one. If a matching version can not be found, 
	the latest version will be loaded with a warning message.

    ================(Build #5117  - Engineering Case #355474)================

	When a query with multiple result sets was opened with ExecuteReader(CommandBehavior.SingleRow), 
	calling NextResult would always have returned false. Only the a single row 
	from the first result set could have been fetched. This problem has been 
	fixed so that a single row is now fetched from each result set, which matches 
	the .Net specifications.

    ================(Build #5003  - Engineering Case #355587)================

	On dual cpu machines, after creating an new prepared AsaCommand and inserting 
	new rows in a loop, a communication error would have occurred after some 
	iterations.
	
	For example, (VB.NET code):
	
	Imports iAnywhere.Data.AsaClient
	
	Module Module1
	
	    Sub Main()
	        Dim conn As AsaConnection
	        Dim cmd As AsaCommand
	        Dim i As Int32
	
	        Try
	            conn = New AsaConnection("uid=dba;pwd=sql;eng=asatest")
	            conn.Open()
	
	            for i = 1 to 2000
	            	cmd = New AsaCommand("insert into ian values( 1 )", conn)
		cmd.Prepared()
	            	cmd.ExecuteNonQuery()
	            Next
	            Console.WriteLine("Inserted {0} rows", i)
	            conn.Close()
	        Catch e As Exception
	            Console.WriteLine(e.ToString())
	        End Try
	    End Sub
	
	End Module
	
	This problem has been fixed.



  Adaptive Server Anywhere - DBLIB Client Library



    ================(Build #5437  - Engineering Case #441275)================

	Attempting to make a connection to the database server at midnight, could 
	have resulted in the error "Connection error: Found server but communication 
	error occurred". The client software did not handle a date roll-over if a 
	timeout was specified. This has been fixed.

    ================(Build #5427  - Engineering Case #437815)================

	A client application would have crashed when a connection attempt was made 
	using a connect string that used the hash char '#' in place of the equal 
	sign '=' for the CommLinks option VerifyServerName (e.g. "Verify#No"). This 
	has been fixed.

    ================(Build #5394  - Engineering Case #429262)================

	If an ODBC application called SQLSetConnectAttr() to set the isolation level 
	while there were concurrent requests using the same connection on other threads, 
	the application could have hung, crashed, or the call could have failed with 
	an error.  This problem does not occur on Windows systems when using the 
	Microsoft ODBC Driver Manager. This problem has been fixed.
	
	Note, similar problems with SQLConnect, SQLBrowseConnect, SQLDriverConnect, 
	SQLAllocStmt/SQLAllocHandle and SQLFreeStmt/SQLFreeHandle have also been 
	corrected.

    ================(Build #5272  - Engineering Case #395662)================

	An Embedded SQL or ODBC application, which used wide fetches or ODBC multi-row 
	rowset fetches on a cursor which had prefetched enabled, could have returned 
	a row with invalid data or data from a previous row when an error should 
	have been returned instead. An example of a row error which could have caused 
	this type of behaviour is the "Subquery cannot return more than one row" 
	error. Also, for Embedded SQL applications, SQLCOUNT was not being set correctly 
	to the number of rows fetched on an error. These problems have been fixed 
	so that the error is correctly returned, and SQLCOUNT is set correctly on 
	errors.

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

    ================(Build #5191  - Engineering Case #373482)================

	If a connection string included the TCP parameter VerifyServerName=NO, and 
	contained an incorrect server name, the connection would have failed, essentially, 
	the VerifyServerName parameter was ignored. This has been fixed.

    ================(Build #5191  - Engineering Case #373480)================

	If a server was started with a server name containing non-7-bit ASCII characters, 
	and the client machine's character set did not match the server machine's 
	character set, applications may not have been able to connect when specifying 
	the server name, (ie ENG parameter). This has been fixed.

    ================(Build #5187  - Engineering Case #372175)================

	The server could have leaked memory, eventually resulting in an 'Out of Memory' 
	error. This could have occurred while executing INSERT or LOAD TABLE statements 
	for tables which the server maintains statistics. This has been fixed

    ================(Build #5153  - Engineering Case #365460)================

	An application that used GetData to retrieve an unbound column on the first 
	row, could have had poor performance, if prefetch was enabled and some, but 
	not all columns, were bound before the first fetch. This poor performance 
	would have been particularly noticeable if the first few rows of the query 
	were expensive to evaluate. Applications which used the iAnywhere JDBC driver, 
	on queries which had columns with type LONG VARCHAR or LONG BINARY, were 
	also affected by this poor performance. This has been fixed.
	

    ================(Build #5148  - Engineering Case #364378)================

	If an error occurred when positioning a cursor, future fetches would have 
	failed with the error -853 "Cursor not in a valid state".  When prefetch 
	was enabled (the default) the specific error when positioning a cursor may 
	not have been returned to the application, with "Cursor not in a valid state" 
	being returned instead.
	
	For example, if a query had a WHERE clause which caused a conversion error, 
	the application may never have received an error stating a conversion error 
	occurred, but would have received the error "Cursor not in a valid state" 
	instead.
	
	This has been fixed so that the initial error, which put the cursor in an 
	invalid state, is now returned to the application.

    ================(Build #5145  - Engineering Case #336902)================

	In rare instances, NetWare or Unix client applications, using ecc_tls or 
	rsa_tls encryption, would have had connection attempts fail. The debug log 
	would have shown a message that the Certicom handshake had failed. This has 
	been fixed.

    ================(Build #5137  - Engineering Case #362197)================

	If a multi-threaded client application had more than one connection (on more 
	than one thread) logging to the same log file, the logged entries from the 
	connections could have been mixed up. Specifically, several timestamps may 
	have appeared together, followed by the text of the messages. Also, in 9.x 
	clients, the date stamp at the top of the file would always have used lowercase 
	English strings. This has been fixed.

    ================(Build #5129  - Engineering Case #360597)================

	Applications attempting Shared memory connections may have hung if the server 
	was forcibly shut down during the connection attempt. This has been fixed.

    ================(Build #5117  - Engineering Case #354838)================

	If an error occurred on an embedded SQL EXECUTE statement, and there were 
	bound columns with all NULL data pointers, a communication error could have 
	occurred and the connection would have been dropped.
	
	An example of bound columns will all NULL data pointers from ESQL is:
	SQLDA *sqlda = alloc_sqlda( 1 );
	sqlda-&gtsqld = 1;
	sqlda-&gtsqlvar[0].sqltype = DT_INT;
	sqlda-&gtsqlvar[0].sqldata = NULL;
	EXEC SQL EXECUTE stmt into descriptor into_sqlda;
	
	This has been fixed so that an error is returned and the connection is not 
	dropped.

    ================(Build #5117  - Engineering Case #352159)================

	It was possible for an application to have hung after attempting to cancel 
	a request.  This problem would only have occurred very rarely on multiprocessor 
	systems, and was even less likely to have occurred on single processor systems. 
	This has been fixed.

    ================(Build #5004  - Engineering Case #367691)================

	On AIX systems running version 4.3.1, applications, including the ASA utilities 
	such as dblocate, would have failed to find any network servers over TCP/IP, 
	if the host=xxx parameter was not specified. Code specific to AIX 4.3.1 to 
	find the broadcast mask was incorrect. This has now been fixed.



  Adaptive Server Anywhere - JDBC Client Library



    ================(Build #5277  - Engineering Case #396873)================

	Changes for Engineering Case 392484 ensured that data exceptions that occurred 
	during a wide fetch were not lost, but the changes introducing an error such 
	that warnings were lost instead. This has been corrected so that both data 
	exceptions and warnings are properly reported to the client.
	

    ================(Build #5269  - Engineering Case #394722)================

	If an application retrieved the ResultSetMetaData and then queried the datatype 
	of an unsigned smallint, unsigned int or unsigned bigint column, the datatype 
	returned would have been incorrect. This problem has now been fixed so that 
	an application can properly determine the unsigned column type using the 
	ResultSet.getColumnType() and ResultSet.isSigned() methods.
	

    ================(Build #5267  - Engineering Case #393604)================

	If an application used ResultSet.relative(0) to attempt to refresh a row, 
	then the iAnywhere JDBC Driver would usually have given an "Invalid cursor 
	position" or a "Not on row" error. It should be noted that the "Invalid cursor 
	position" error is valid since that error is usually given by the underlying 
	ODBC driver when the Statement or PreparedStatement that generated the ResultSet 
	is of type TYPE_FORWARD_ONLY. However, when the Statement or PreparedStatment 
	is scrollable, then the iAnywhere JDBC Driver should refresh the row rather 
	than give the "Not on row" error. This problem has been fixed.

    ================(Build #5246  - Engineering Case #388573)================

	If a result set had a DECIMAL column with a value that has more than 10 digits, 
	but less than 19 digits, and was an integer, then calling ResultSet.getLong() 
	should have returned the entire value but did not. This problem has been 
	fixed.

    ================(Build #5209  - Engineering Case #377885)================

	If an application used the PreparedStatement.setTimestamp() method to set 
	a timestamp parameter, then the millisecond portion of the timestamp would 
	not have been set. This problem has been fixed.

    ================(Build #5196  - Engineering Case #374840)================

	Calling the Connection.getCatalog() method, when using the iAnywhere JDBC 
	Driver, would have yielded a string with extra characters. Note that this 
	problem only existed if the JDBC Driver was used to connect to a server other 
	than an ASA server. The problem has been fixed.

    ================(Build #5194  - Engineering Case #374451)================

	An application using the iAnywhere JDBC Driver would have leaked memory if 
	it called Connection.getMetaData() repeatedly. This problem has been fixed.
	

    ================(Build #5189  - Engineering Case #373086)================

	If a JDBC cursor was positioned on a row with a LONG VARCHAR column, then 
	calling ResultSet.getString() on the column would have returned the proper 
	value for the first call, but each subsequent call would have returned NULL 
	if the cursor had not been repositioned. This problem has now been fixed.

    ================(Build #5138  - Engineering Case #362356)================

	While connected to a multi-byte character set database with the iAnywhere 
	JDBC Driver, executing a procedure whose result set was defined to have a 
	varchar column, but the size of the column in the definition was too small, 
	could have resulted in an "Out of memory" exception.  This problem has now 
	been fixed.
	
	For example:
	
	CREATE PROCEDURE test()
	result( c1 varchar(254) )
	begin
	  select repeat( 'abcdef', 1000 )
	end
	
	Notice that a varchar( 254 ) column is much too small to hold the result 
	of repeat( 'abcdef', 1000 ). In this case, executing the procedure test would 
	have resulted in an "Out of memory" exception.

    ================(Build #5117  - Engineering Case #350688)================

	If an application called ResultSet.last(), to scroll to the last row in the 
	result set, and then called ResultSet.isLast(), to check to see if the cursor 
	was positioned on the last row, the iAnywhere JDBC Driver would have incorrectly 
	returned false, rather than true. This problem has now been fixed.



  Adaptive Server Anywhere - ODBC Client Library



    ================(Build #5343  - Engineering Case #417500)================

	When an array of parameters was used as input to an ODBC execute (for example, 
	to insert more than one row with one SQLExecute), some of the parameter values 
	could have be sent to the server incorrectly. It was possible for this to 
	have occurred if CHARACTER or BINARY data was used, and the data size for 
	a particular column was slightly larger in subsequent rows than previous 
	rows within a single array of parameters (for example, if the first row in 
	the array had a value of length 1000, and the second row in the array had 
	a value of length 1050 for the same column). This has now been fixed so that 
	the data is correctly sent to the server in this situation.

    ================(Build #5314  - Engineering Case #407012)================

	The following ODBC driver problems have been fixed:
	
	1) Fetching multiple rows into a bound WCHAR column, which was too small 
	for the column (thus truncating the data), could have copied the data into 
	the wrong user buffer location.  Data was filled correctly on the first fetch, 
	but incorrectly on subsequent fetches, likely overrunning memory and possibly 
	crashing the application.
	
	2) Using SQLGetData to put data into a WCHAR buffer, where the client or 
	database charset was multibyte, may have caused a subsequent SQLGetData on 
	the same column to contain incorrect data.  Also, indicator values may have 
	been set incorrectly for SQLGetData or SQLFetch calls to fill WCHAR buffers 
	when using multibyte character sets.
	
	3) Using SQLGetData to put data into a WCHAR buffer with more than 64K WCHARs 
	could have returned the wrong indicator, when there is no truncation.
	
	4) Using SQLPutData to put more than 64K of data of ANY TYPE in one SQLPutData 
	call, may have put incorrect data.
	
	5) Calling SQLPutData with CHAR (not WCHAR) data and SQL_NTS length, only 
	appended the first 256K of data.  Appended data greater than 256K was lost.
	
	6) Calling SQLPutData with WCHAR data and using odd lengths (i.e. partial 
	characters), may have put incorrect data if the client or database charset 
	was multibyte.

    ================(Build #5286  - Engineering Case #400466)================

	If an ODBC application described a signed bigint column, the precision would 
	have been returned as 20 when it should really have been 19. This problem 
	has been fixed. 
	
	Note that the precision of unsigned bigint columns is still returned as 
	20, which is the correct value.

    ================(Build #5272  - Engineering Case #392484)================

	If an application using either the ASA ODBC driver, or the iAnywhere JDBC 
	driver, fetched a set of rows in which one of the rows encountered a data 
	exception, then it was likely that the error would not have been reported. 
	Note that Prefetch must have been on for the problem to occur. This problem 
	has now been fixed, but in addition to this change, the changes to the server 
	for Engineering Case 395662 are also required

    ================(Build #5266  - Engineering Case #393587)================

	The ODBC driver was not returning some reserved words for SQLGetInfo( SQL_KEYWORDS 
	). The mssing reserved words were:
	
	character
	dec
	options
	proc
	reference
	subtrans
	
	These words are synonyms for other reserved words, and have now been added 
	to the list returned by SQLGetInfo( SQL_KEYWORDS ).

    ================(Build #5204  - Engineering Case #355595)================

	Calling the ODBC function SQLGetData() with a length of 0 would have failed 
	for SQL_WCHAR.
	
	   SQLRETURN SQLGetData(
		SQLHSTMT	StatementHandle,
		SQLUSMALLINT	ColumnNumber,
		SQLSMALLINT	TargetType,
		SQLPOINTER	TargetValuePtr,
		SQLINTEGER	BufferLength,
		SQLINTEGER * 	IndPtr);
	
	SQLGetData can be used to obtain the amount of data available by passing 
	0 for the BufferLength argument. The amount of data available is returned 
	in the location pointed to by IndPtr. If the amount available cannot be determined, 
	SQL_NO_TOTAL is returned. When the TargetType was SQL_C_WCHAR, the amount 
	of available data was incorrect (a character count rather than byte count 
	was returned).  This has been fixed.  
	
	There were also some problems returning correct indicator values for databases 
	using the UTF8 collation.  This has also been fixed.

    ================(Build #5186  - Engineering Case #370604)================

	In ODBC, changing the option for a cursor's scrollability, could have caused 
	the driver to change the cursor type as well.  For instance if the cursor 
	type was forward-only, changing the scrollability to scrollable would have 
	changed the cursor type to dynamic.  The problem was that the driver was 
	always changing the cursor type to dynamic regardless of the existing cursor 
	type. This has been corrected.

    ================(Build #5182  - Engineering Case #370905)================

	An ODBC application that allocated both an ODBC 2.0 style environment handle 
	and an ODBC 3.0 style environment handle, could have have returned ODBC 3.0 
	result codes when functions were called in the ODBC 2,0 environment, or vice 
	versa. This could have lead to subsequent function calls failing with erroneous 
	error messages, including 'function sequence error'. Now, the driver will 
	always allocate a separate environment handle each time SQLAllocEnv or SQLAllocHandle 
	is called.

    ================(Build #5160  - Engineering Case #367232)================

	If a database created with the UTF8 collation, had a column that contained 
	a 5 or 6 byte Chinese character sequence, ODBC client applications would 
	likely have crashed fetching the column.  This has been fixed.
	
	This problem was introduced by the changes for Engineering Case 364608.
	

    ================(Build #5148  - Engineering Case #364608)================

	If an ODBC application running on a Windows system fetched a string with 
	embedded null characters, the resulting string would have been truncated 
	at the first null character. This problem has been fixed.
	
	Note that a similar problem exists for applications running on Unix platforms 
	as well. However this problem exists in the iAnywhere JDBC Driver and is 
	addressed by Engineering Case 364379.

    ================(Build #5147  - Engineering Case #364278)================

	Support for message callbacks has now been added to the ODBC driver. The 
	message handler is installed by calling the SQLSetConnectAttr() function.
	
	For example:
	
	static char     mybuff[80];
	static int      mytype;
	
	// callback for messages
	
	void SQL_CALLBACK my_msgproc(
	    void *              sqlca,
	    unsigned char       msg_type,
	    long                code,
	    unsigned short      len,
	    char *              msg )
	{
	    memcpy( mybuff, msg, len );
	    mybuff[ len ] = '\0';
	    mytype = msg_type;
	}
	
	// install the message handler for this connection
	rc = SQLSetConnectAttr( dbc,
		ASA_REGISTER_MESSAGE_CALLBACK,
		(SQLPOINTER) &my_msgproc, SQL_IS_POINTER );
	
	Then a SQL statement such as: 
	
		Message 'after' type status to client;
	
	will invoke the ODBC client application's message handler.

    ================(Build #5128  - Engineering Case #360479)================

	The ODBC SQLDisconnect() function could have returned a failing error code 
	if the server dropped the client's connection (e.g. for idle time-out reasons), 
	while the connection had a dirty transaction to be committed or rolled back 
	(i.e. SQLExecute, SQLExecDirect or SQLSetPos was called), and SQL_AUTOCOMMIT_OFF 
	option was set ON for the connection. 
	
	Now, SQLDisconnect() returns SQL_SUCCESS_WITH_INFO and sets the SQLSTATE 
	to 01002 (Disconnect error).

    ================(Build #5124  - Engineering Case #359428)================

	A memory leak can have occurred in the ODBC driver if the database server 
	closed the connection for any reason, for example  an idle time-out. A pointer 
	to the driver's connection object was being set to null, but the object was 
	not freed. This has now been corrected.

    ================(Build #5117  - Engineering Case #352572)================

	An application that used multiple threads to access the same connection through 
	ODBC could have hung.  This has been fixed.

    ================(Build #5117  - Engineering Case #349975)================

	Blob data, written to a database by an ODBC application using SQLPutData, 
	would have been corrupted if the following conditions were true:
	 - the application used a different charset than the database
	 - the server had character set translation enabled 
	 - the length parameter passed to SQLPutData was larger than SQL_ATTR_MAX_LENGTH
	In this case the data is send as VARCHAR and the server does character set 
	translation. This has now been fixed.



  Adaptive Server Anywhere - OLEDB Client Library



    ================(Build #5496  - Engineering Case #454481)================

	The SQL Anywhere OLE DB provider was returning E_FAIL from IOpenRowset::OpenRowset 
	for database errors. Since E_FAIL was returned, the client would have reported 
	the message "Unspecified error". On a "table not found" error for example, 
	it should have returned DB_E_NOTABLE , "The specified table does not exist 
	in the data store". This problem has been fixed. 

    ================(Build #5476  - Engineering Case #449590)================

	If a date parameter value (a value of type adDate) was inserted into a column, 
	only the year and month were inserted correctly. The day was always 1.
	
	A Visual Basic example:
			cmd.CommandText = "INSERT INTO DateTable(cDate) values (?)"
			cmd.CommandType = ADODB.CommandTypeEnum.adCmdUnknown
			parm = cmd.CreateParameter("inDate", ADODB.DataTypeEnum.adDate, ADODB.ParameterDirectionEnum.adParamInput)
			cmd.Parameters.Append(parm)
			parm.Value = "2006-12-15"
			cmd.Execute()
	
	The value inserted would have been "2006-12-01".
	
	This problem has been corrected, so that the correct date is now inserted.

    ================(Build #5468  - Engineering Case #447585)================

	When using Microsoft's Query Analyzer with Microsoft SQL Server, if a SELECT 
	statement that used the OPENDATASOURCE procedure and specified the SQL Anywhere 
	OLE DB provider was executed, it would have failed with the error: "Could 
	not perform a Windows NT authenticated login because delegation is not available.". 
	
	For example:
	SELECT * FROM  OPENDATASOURCE('ASAProv.90','Data Source=dba_sql_90;User 
	ID=dba;Password=sql')..dba.my_table
	
	This has been fixed so that the OPENDATASOURCE procedure now works correctly.

    ================(Build #5450  - Engineering Case #443845)================

	When using ADO and the SQL Anywhere OLE DB provider, a stored procedure reference 
	like "SProc" is correctly parsed in a CommandText string as a procedure name. 
	However, a stored procedure reference like "DBA.SProc" was incorrectly parsed 
	as a schema owner, followed by a catalog name, and no procedure name. The 
	following Visual Basic example fragment illustrates the problem:
	
	objCmd.ActiveConnection = objConn
	' Set CommandText equal to the stored procedure name.
	objCmd.CommandText = "DBA.SProc"
	objCmd.CommandType = adCmdStoredProc
	' Automatically fill in parameter info for the stored procedure.
	objCmd.Parameters.Refresh()
	' Set the parameter values.
	objCmd("@user_id") = "ianywhere"
	objCmd("@password") = "test"
	objCmd("@first") = "Iam"
	objCmd("@last") = "Anywhere"
	objCmd("@phone") = "5558836300"
	objCmd("@extension") = "6300"
	
	When ADO executeed the Refresh() method, the provider was asked to provide 
	parameter information on the "SProc" stored procedure. A catalog name ("SProc") 
	and schema owner name ("DBA") were passed in. Since catalog names are not 
	supported and ignored, information on all stored procedures owned by DBA 
	were returned to ADO. 
	
	This problem has been fixed.  An incorrectly set property, DBPROP_CATALOGLOCATION,  
	resulted in the parsing error. The property value has been corrected.

    ================(Build #5450  - Engineering Case #443473)================

	When a stored procedure call with a return value was prepared, the provider 
	would have generated a call with an incorrect number of parameters. The following 
	Visual Basic code demostrates the problem:
	       
	objCmd = CreateObject("ADODB.Command")
	objCmd.CommandText = "Add_User"
	objCmd.CommandType = adCmdStoredProc
	objCmd.ActiveConnection = objConn
	objCmd.Prepared = True
	objCmd.Parameters.Append(objCmd.CreateParameter("Add_User", 3, 4))
	objCmd.Parameters.Append(objCmd.CreateParameter("@userid", 200, 1, 25, "jbjones"))
	objCmd.Parameters.Append(objCmd.CreateParameter("@first", 200, 1, 25, "John"))
	objCmd.Parameters.Append(objCmd.CreateParameter("@last", 200, 1, 35, "Jones"))
	objCmd.Parameters.Append(objCmd.CreateParameter("@phone", 200, 1, 18, "5558836300"))
	objCmd.Parameters.Append(objCmd.CreateParameter("@extension", 200, 1, 6, 
	"6300"))
	
	An erroneous SQL statement like the following is generated.
	
	?=call Add_User(?,?,?,?) 
	
	If the objCmd.Prepared = True statement was not included , or the Prepared 
	property was set to False, then the problem did not appear. This has now 
	been fixed. 

    ================(Build #5435  - Engineering Case #440709)================

	When using the OLEDB provider to read values from a varchar( n ) column, 
	using the .NET DataReader, the last character was truncated if the column 
	contained exactly n characters. This problem has been fixed.

    ================(Build #5434  - Engineering Case #440215)================

	The changes made for Engineering case 433717 caused the provider to return 
	'Object or provider is not capable of  performing requested operation', when 
	executing a simple query.  This has now been fixed.

    ================(Build #5430  - Engineering Case #439710)================

	Trying to use the TableData adapter wizard with a Dataset, would have failed 
	with the message "Generated SELECT statement: 'ASAProv.90' failed with no 
	error message available, result code: DB_E_DELETEDROW(0x80040E23)". This 
	problem has been fixed.

    ================(Build #5412  - Engineering Case #432537)================

	The OLE DB provider did not properly support 4-part queries when used with 
	the SQL Server 2005 Linked Server feature. For example, attempting the following 
	SQL statement in Microsoft SQL Server 2005 Management Studio:
	
		SELECT * FROM ASASERVER..dba.customer
	
	would have caused the error:
	
	Msg 7320, Level 16, State 2, Line 1 Cannot execute the query
	
	However, the OPENQUERY form of SELECT works fine: 
	
		SELECT * FROM OPENQUERY(  ASASERVER, 'SELECT * FROM customer')
	
	This problem has now been fixed. Note, this problem does not appear with 
	SQL Server 2000. 

    ================(Build #5401  - Engineering Case #433726)================

	The Windows CE version of the OLE DB Provider could have failed when attempting 
	conversions to and from Variant types. Also, some properties were not supported 
	properly under Windows CE and would have incorrectly returned errors. These 
	problems have now been fixed.

    ================(Build #5395  - Engineering Case #429527)================

	The changes for Engineering case 404908, introduced a problem where obtaining 
	parameter information on a stored procedure that was owned by a different 
	user could have resulted in a crash. 
	
	The following Delphi code demostrates the problem:
	
	procedure TForm1.Button1Click(Sender: TObject);
	var
	  adoParams: Parameters;
	  nCnt: integer;
	begin
	  mmoParams.Clear;
	  FAdoCommand.Set_ActiveConnection(ADOConnection1.ConnectionObject);
	  FAdoCommand.Set_CommandText("sp_test");
	  FAdoCommand.Set_CommandTimeout(30);
	  FAdoCommand.Set_CommandType(adCmdStoredProc);
	  adoParams := FAdoCommand.Get_Parameters();
	  adoParams.Refresh;
	  for nCnt := 0 to adoParams.Count - 1 do begin
	    mmoParams.Lines.Add(adoParams.Item[nCnt].Name);
	  end;
	end;
	
	This problem has been fixed.

    ================(Build #5381  - Engineering Case #426364)================

	When scrolling backwards or forwards through a cursor, the OLEDB provider 
	would have refetched deleted rows. This problem has been fixed.

    ================(Build #5381  - Engineering Case #426361)================

	The OLEDB provider was not converting columns of type BIT to DBTYPE_BOOL 
	correctly. A true value 1 should map to a 16-bit integer value equal to -1 
	rather than to the value 1, as it was. This problem has now been fixed.

    ================(Build #5381  - Engineering Case #424931)================

	When the OLEDB provider was used with ADO, wide character strings (UTF16/OLECHAR) 
	were written correctly to a database that used the UTF8 collation. However, 
	when fetching the inserted values back from the database, the UTF8 strings 
	were not correctly converted back into UTF16. This has been fixed. The OLEDB 
	provider now does proper conversion from UTF8 strings to UTF16 strings.

    ================(Build #5375  - Engineering Case #424217)================

	The iAnywhere OLEDB provider was not correctly executing multi-row fetches 
	as a result of calling the GetRowsAt() method.  For example, when using GetRowsAt() 
	to fetch rows 1 through 50 of a result set and then fetching rows 26 through 
	75, the provider would have incorrectly returned rows 51 through 75 on the 
	second fetch. This problem has been fixed.

    ================(Build #5373  - Engineering Case #423911)================

	Insertion of rows into a UTF8 database, using ADO and the OLEDB provider, 
	would sometimes have failed. The following Visual Basic script is an example 
	that reproduces the problem.
	
	recordset.Open "Employees", connection, , , adCmdTable
	recordset.AddNew
	recordset.Fields.Item("EmployeeID") = 1000
	recordset.Fields.Item("GivenName") = "Munroe"
	recordset.Fields.Item("Surname") = "Marvin"
	recordset.Fields.Item("DepartmentID") = 201
	recordset.Fields.Item("Street") = "No fixed Street"
	recordset.Fields.Item("City") = "No City"
	recordset.Fields.Item("Salary") = 12000.00
	recordset.Fields.Item("StartDate") = "2006-01-03"
	recordset.Update
	
	This has now been fixed.
	

    ================(Build #5373  - Engineering Case #423901)================

	The OLEDB GetRowsByBookmark method, as implemented by the iAnywhere provider, 
	did not work correctly. It was possible to return invalid row handle values. 
	As well, incorrect row status array values were being returned. This has 
	now been fixed.
	

    ================(Build #5373  - Engineering Case #423508)================

	The provider calls the ADO CreateParameter method using the adBSTR datatype. 
	Each time the Execute method was called, memory would have been leaked.  
	The following is a C++ example of the code.
	
	        std::wstring strParam1( 84, L'\x9F5F' );
	
	        // Create the parameters.
	        _ParameterPtr param1;
	        _variant_t val1( strParam1.c_str() );
	        param1 = cmd-&gtCreateParameter( L"", adBSTR, adParamInput, (long)strParam1.length(), 
	val1 );
	        cmd-&gtParameters-&gtAppend( param1 );
	
	        // Run the command.
	        _variant_t vtEmpty1( DISP_E_PARAMNOTFOUND, VT_ERROR );
	        _variant_t vtEmpty2( DISP_E_PARAMNOTFOUND, VT_ERROR );
	        cmd-&gtExecute( &vtEmpty1, &vtEmpty2, adCmdStoredProc | adExecuteNoRecords 
	);
	
	When a variant BSTR object (val1) was converted to a BSTR object (the bound 
	parameter), a new object was created and the memory for that object was lost. 
	This problem has now been corrected.

    ================(Build #5348  - Engineering Case #417837)================

	When the ADO methods AddNew() or Update() were called, a memory leak would 
	have occurred in the OLE DB provider. This problem has been fixed by appropriately 
	freeing the allocated memory.

    ================(Build #5343  - Engineering Case #417622)================

	The OLE DB schema rowsets (e.g., INDEXES) are supported by stored procedures 
	like sa_oledb_indexes (and others). They return result sets that allow for 
	table names and other identifiers up to 128 characters in length. However, 
	the input parameters to these stored procedrues only allowed for identifiers 
	of up to 80 characters in length. This problem has been fixed so that parameters 
	can now be up to 128 characters in length.

    ================(Build #5322  - Engineering Case #409320)================

	When retrieving long varchar fields using a client side ADO recordset, a 
	null character was appended to the end of the data by the OLEDB provider.  
	This problem has been fixed.

    ================(Build #5304  - Engineering Case #405321)================

	An attempt to insert a value into a SQL TINYINT column declared as adTinyInt, 
	that was greater than 128, would have failed with the error "Count field 
	incorrect". Unfortunately, this message did not clearly indicate where the 
	problem occurred. The ADO adTinyInt type (DBTYPE_I1) includes numbers in 
	the range -128 to 127. A value like 255, which is outside of this range, 
	cannot be converted to an adTinyInt. The ASA TINYINT type corresponds to 
	an unsigned 1-byte integer, which matches the ADO adUnsignedTinyInt type 
	(DBTYPE_UI1). This type accepts values in the range 0 to 255. The conversion 
	error that  results from trying to convert a value like 255 to an adTinyInt 
	type is now properly reported as "Cannot convert parameter X to a DBTYPE_I1" 
	where X is the index of the parameter to the INSERT statement.

    ================(Build #5303  - Engineering Case #404908)================

	A memory leak in the OLE DB provider associated with calling stored procedures 
	has been fixed.

    ================(Build #5303  - Engineering Case #404290)================

	A stored procedure call that included the owner name would have failed when 
	using ADO and the SQL Anywhere OLE DB provider.  The following is an example 
	using Visual Basic:
	
	' Set CommandText equal to the stored procedure name.
	objCmd.CommandText = "fred.ShowSalesOrderDetail"
	objCmd.CommandType = adCmdStoredProc
	objCmd.ActiveConnection = objConnection
	
	A couple of problems arose when using this form of the stored procedure 
	call. Internally, the OLE DB provider uses a SQL query to obtain information 
	on the number of parameters to the stored procedure. It asked for information 
	on a procedure name called "fred.ShowSalesOrderDetail" and there was no such 
	procedure name since the owner name had not been separated from the procedure 
	name.  This problem has been fixed.
	
	The second problem involved using the ADO parameter "Refresh" method as 
	shown below in a Visual Basic example:
	
	' Automatically fill in parameter info from stored procedure.
	' This avoids having to do CreateParameter calls.
	objCmd.Parameters.Refresh
	
	The problem is related to the way ADO interprets the components of the stored 
	procedure name.  There are three basic forms recognized by ADO.
	
	1. ProcedureName
	2. Owner.Catalog
	3. Owner.ProcedureName.Catalog
	
	Here is how ADO interprets these forms.
	
	The first form is what is most often used.  When only a name appears (no 
	qualifiers), it is interpreted to be the procedure name. This form poses 
	no problems.
	
	When the second form is used (two names separated by a period), the first 
	name is assumed to be the owner name and the second name is assumed to be 
	the catalog name.  SQL Anywhere doesn't support the notion of catalogs.  
	When the Refresh method is called, the OLE DB provider is presented with 
	the following query by ADO.
	
		EXECUTE sa_oledb_procedure_parameters inProcedureCatalog='Catalog',inProcedureSchema='Owner'
	
	This query from ADO is meaningless to the SQL Anywhere OLE DB provider, 
	as the procedure name is missing. ADO has interpreted the two components 
	as a schema name (the owner) and  a catalog name. The query returns information 
	on all procedures owned by "Owner" which is of no use.
	
	When the third form is used, the first name is assumed to be the owner name, 
	the second name is assumed to be the procedure name. and the third name is 
	assumed to be the catalog name. When the Refresh method is called, the OLE 
	DB provider is presented with the following query by ADO.
	
		EXECUTE sa_oledb_procedure_parameters inProcedureCatalog='Catalog',inProcedureSchema='Owner',inProcedureName='ProcedureName'
	
	Since the procedure name and owner are present and since the catalog name 
	is ignored by the OLE DB provider, this query will return the correct information 
	about the procedure parameters. However, the actual procedure call will result 
	is a syntax error since "call Owner.ProcedureName.Catalog" is not an acceptable 
	form for a stored procedure call.
	
	These problems can be avoided by not using the ADO "Refresh" method and, 
	also, by avoiding the use of the three-part syntax. The best solution is 
	to avoid the use of an owner qualification entirely since the "X.Y" form 
	is misinterpreted by ADO.

    ================(Build #5298  - Engineering Case #403026)================

	For FORWARD-ONLY cursors, the iAnywhere OLEDB provider was returning the 
	error "HY109" when fetching rowsets with more than 1 row, and contained a 
	column with more than 200 bytes. This problem has been fixed. 

    ================(Build #5298  - Engineering Case #403014)================

	The iAnywhere OLEDB Provider's default ('PUBLIC') for the GRANTEE restriction 
	column for the COLUMN_PRIVILEGES and TABLE_PRIVILEGES rowsets was incorrect. 
	The default should be the empty string (''). Also, the Provider did not enforce 
	the GRANTOR and GRANTEE restriction columns for the COLUMN_PRIVILEGES rowset. 
	These problems have been fixed.   
	
	To install new versions of the OLEDB provider schema rowsets into a database, 
	load and rerun scripts\oleschem.sql.

    ================(Build #5298  - Engineering Case #403010)================

	The iAnywhere OLEDB Provider could have reported a "Table not found" error 
	for any of the following rowsets:
	
	   COLUMN_PRIVILEGES
	   TABLE_PRIVILEGES
	   FOREIGN_KEYS
	
	The SQL scripts that implement these schema rowsets did not qualify the 
	SYSGROUP or SYSTRIGGER tables with "SYS.". This has been corrected.
	
	To install new versions of the OLEDB provider schema rowsets into a database, 
	load and rerun scripts\oleschem.sql.
	

    ================(Build #5293  - Engineering Case #402278)================

	The Microsoft Query Analyzer uses the iAnywhere OLEDB provider to process 
	queries from (ASA) Linked Servers.   The Query Analyzer can call ASA stored 
	procedures provided that Remote Procedure Calls have been enabled. The Linked 
	Server properties RPC and RPC Out must be selected; otherwise a message like 
	"Server 'asatest9' is not configured for RPC" will be issued.
	
	The Query Analyzer forms a query that is syntactically incorrect for ASA 
	and this results in a syntax error message.
	
	For example, the following query will result in the error messages shown 
	below.
	
		asatest9..dba.sp_customer_list
	
		Could not execute procedure 'sp_customer_list' on remote server 'asatest9'.
		[OLE/DB provider returned message: Syntax error near '1' on line 1]
	
	The Query Analyzer issues the SQL statement "{?=call "dba"."sp_customer_list";1}".  
	The ";1" results in a syntax error.
	
	This has been fixed. The iAnywhere OLEDB provider will now remove the ";1" 
	from the statement as a work-around.

    ================(Build #5293  - Engineering Case #402276)================

	The iAnywhere OLEDB Provider was reporting inconsistent type information 
	for NUMERIC/DECIMAL columns. In some cases it would have reported DBTYPE_DECIMAL 
	for NUMERIC/DECIMAL columns, in other cases it reported DBTYPE_NUMERIC. It 
	would also have inconsistently reported precision for NUMERIC/DECIMAL columns, 
	changing it between compile time and runtime. These problems have now been 
	fixed. The changes have been made to the provider, as well as the supporting 
	stored procedures. To install new versions of the OLEDB provider schema rowsets 
	into a database, scripts\oleschem.sql must be rerun against the database.
	

    ================(Build #5293  - Engineering Case #401990)================

	When adding a new row into a table using the OLEDB provider, if the value 
	for a column was the empty string, Visual Basic would have reported reports 
	a run-time error. The conversion functions assumed that a result length of 
	0 indicated an error, which is true if the input length is non-zero, but 
	if the input length is 0 then a result length of 0 is expected. This problem 
	has been fixed. 
	

    ================(Build #5293  - Engineering Case #401989)================

	A Visual Basic application, using the OLEDB provider to add a new row to 
	a table that contained an unitiialized (NULL) column value , would have crashed 
	with a null pointer exception. This problem has been fixed. 
	

    ================(Build #5293  - Engineering Case #401987)================

	When adding a row to a table that contained a BIT column using the OLEDB 
	provider, the BIT column value was always recorded as FALSE. This problem 
	has been fixed. 

    ================(Build #5285  - Engineering Case #400186)================

	Insertion of multibyte strings (Chinese, Japanese, Korean, etc.) into a database 
	using the UTF8 collation would have failed. The following C# code illustrates 
	the problem.
	
		System.Data.OleDb.OleDbDataAdapter Ada=new System.Data.OleDb.OleDbDataAdapter 
	("select * from  test",conn);
		System.Data.OleDb.OleDbCommandBuilder CommandBuilder=new System.Data.OleDb.OleDbCommandBuilder 
	(Ada);
	
		System.Data.DataTable dt=new DataTable ();
		Ada.FillSchema (dt,System.Data.SchemaType .Mapped );
		System.Data.DataRow dr=dt.NewRow ();
		dr["Col01"]=textBox1.Text ;
		dt.Rows.Add (dr);
		Ada.Update (dt);
	
	If the text entered into "textBox1" was a multibyte character, it would 
	not have been inserted correctly into column "Col01" of the "test" table 
	when the database was using the UTF8 collation. This problem has now been 
	fixed.

    ================(Build #5283  - Engineering Case #399872)================

	When using FoxPro to display a result set, the first record was missing. 
	The following code sample illustrates the problem.
	
	conn = CREATEOBJECT( 'ADODB.Connection' )
	conn.ConnectionString = [Provider=ASAProv.90;uid=dba;pwd=sql;]
	conn.Open
	rs = CREATEOBJECT( 'ADODB.RecordSet' )
	rs.ActiveConnection = conn
	curs = CREATEOBJECT( 'CursorAdapter' )
	curs.datasourcetype = 'ADO'
	curs.datasource = rs
	curs.SelectCmd = 'SELECT * FROM SYS.SYSTABLE WHERE table_id = 2'
	curs.alias = 'ADO Test'
	curs.cursorfill
	BROWSE
	
	FoxPro obtained the first row in the result set and then issued a RestartPosition() 
	call to reposition to the first row in the result set. The cursor type for 
	the query in the above example was FORWARD ONLY.  With this type of cursor, 
	the RestartPosition() procedure failed to reposition to the start of the 
	result set.  This problem has been fixed.  RestartPosition() will now re-execute 
	the query to position to the start of the result set when the cursor type 
	is FORWARD ONLY.

    ================(Build #5281  - Engineering Case #397798)================

	If a Visual Basic application attempted to open a record set using a STATIC 
	cursor with a PESSIMISTIC locking mechanism, the OLEDB provider would have 
	selected a DYNAMIC cursor instead. This was done by the provider to ensure 
	that updating of the records was possible, usually by locking records at 
	the data source immediately before editing. Of course, this also meant that 
	the records were unavailable to other users once editing had begun, until 
	the lock was released by calling Update. This type of lock is used in a system 
	where you can't afford to have concurrent changes to data, such as in a reservation 
	system. If the application then tried to obtain the current bookmark value, 
	an error would have occurred. This made it appear that STATIC cursors didn't 
	support bookmarks, whereas the real problem was that DYNAMIC cursors do not 
	support bookmarks. If the application specifies a STATIC cursor with a READ-ONLY 
	locking mechanism, then a STATIC cursor will be used and bookmarks are supported. 
	The OLEDB provider has been changed so that a KEYSET cursor will be selected 
	instead of a DYNAMIC cursor when PESSIMISTIC locking is requested. This will 
	allow the use of bookmarks.

    ================(Build #5249  - Engineering Case #389502)================

	The OLEDB PROVIDER_TYPES rowset did not implement the DATA_TYPE and BEST_MATCH 
	restrictions. It implemented a restriction on TYPE_NAME instead and ignored 
	BEST_MATCH. This problem has been fixed so that the PROVIDER_TYPES rowset 
	now implements the DATA_TYPE and BEST_MATCH restrictions. To install a new 
	version of the PROVIDER_TYPES rowset into your database, load and run scripts\oleschem.sql 
	against the database.
	
	As well, not all type names are included in the rowset, and some data types 
	that could be included were not. This has also been corrected. 

    ================(Build #5217  - Engineering Case #379901)================

	The OLEDB provider was failing to close the result set cursor between prepared 
	command executions. Enigeering Case 351298 reintroduced this bug, which was 
	originally described by Case 271435. This fix addresses both issues, an open 
	cursor is now closed before a SQLExecute, when the command has been previously 
	prepared.

    ================(Build #5211  - Engineering Case #376453)================

	An ADO .Net application that attempted to obtain the primary keys from a 
	query on a table using the OLEDB provider, may have been returned incorrect 
	results when the table had more than one primary key column and/or columns 
	with unique constraints or unique indexes. 
	
	A sample code fragment follows:
	
	      DataTable Table = new DataTable(textTableName.Text);
	      OleDbDataAdapter adapter;
	      OleDbConnection connection = new OleDbConnection(textConnectionString.Text);
	      using (connection) 
	      { 
	        try
	        {
	          connection.Open();
	
	          adapter = new OleDbDataAdapter("select * from dba." + textTableName.Text 
	+ " where 1=0", connection);
	          adapter.MissingSchemaAction = MissingSchemaAction.AddWithKey;
	          adapter.Fill(Table);
	
	          listBox1.Items.Clear();
	          foreach(DataColumn col in Table.PrimaryKey)
	          {
	            listBox1.Items.Add(col.ColumnName);
	          }
	        }
	        catch (Exception ex)
	        {
	          MessageBox.Show(ex.Message);
	        }
	      }
	
	The DataTable PrimaryKey property is an array of columns that function as 
	primary keys for the data table.  This problem has been fixed.
	
	One of the elements that ADO.Net uses in deciding whether a column belongs 
	in this set is the column metadata rowset. 
	
	IColumnsRowset::GetColumnsRowset - Returns a rowset containing metadata 
	about each column in the current rowset. This rowset is known as the column 
	metadata rowset and is read-only. The optional Metadata Column DBCOLUMN_KEYCOLUMN 
	is described to contain one of the values VARIANT_TRUE or VARIANT_FALSE or 
	NULL.
	
	VARIANT_TRUE  The column is one of a set of columns in the rowset that, 
	taken together, uniquely identify the row. The set of columns with DBCOLUMN_KEYCOLUMN 
	set to VARIANT_TRUE must uniquely identify a row in the rowset. There is 
	no requirement that this set of columns is a minimal set of columns. This 
	set of columns may be generated from a base table primary key, a unique constraint 
	or a unique index. 
	
	VARIANT_FALSE  The column is not required to uniquely identify the row.
	
	This column used to contain VARIANT_TRUE  or VARIANT_FALSE.  It now contains 
	NULL since OLEDB cannot correctly set the value. As a result, ADO.Net uses 
	other means for determining which columns belong in the PrimaryKey columns 
	property.

    ================(Build #5172  - Engineering Case #369521)================

	If the GetCurrentCommand method of the ICommandPersist interface was called, 
	the memory heap could have been corrupted. This problem has been fixed.

    ================(Build #5172  - Engineering Case #369072)================

	When using the OLEDB provider ASAProv, String parameters may not have been 
	passed correctly to stored procedures. This problem has been fixed.
	
	The following Visual Basic example calls a stored procedure with a String 
	parameter.
	
	        Dim sendParam1 As String
	        sendParam1 = "20040927120000"
	        Dim cmd As ADODB.Command
	        cmd = New ADODB.Command
	        With cmd
	            .CommandText = "testproc1"
	            .CommandType = ADODB.CommandTypeEnum.adCmdStoredProc
	            .ActiveConnection = myConn
	            .Prepared = True
	            .Parameters(0).Value = sendParam1
	
	            Call .Execute()
	        End With
	
	An example of a stored procedure follows.
	
	ALTER PROCEDURE "DBA"."testproc1" (in param1 varchar(30))
	BEGIN
		message 'in Parameter [' + param1 + ']';
	END
	
	

    ================(Build #5171  - Engineering Case #369272)================

	A call to IRowsetChange::InsertRow() in the OLEDB provider, ASAProv, results 
	in a crash.  This call can be made from C++ using a simple table insert:
	
		CTable&ltCAccessor&ltCSimpleAccessor&gt &gt dbSimple;
		hr = dbSimple.Insert(1);
	
	This problem has been fixed.

    ================(Build #5171  - Engineering Case #368574)================

	The execution of a SELECT statement containing JOINs of several tables by 
	applications using the OLEDB provider ASAProv, would have resulted in a memory 
	leak.  This has been fixed.

    ================(Build #5169  - Engineering Case #369016)================

	When an application using the OLEDB driver provided a DBTYPE_DECIMAL parameter 
	with over 15 digits, the most significant digits would have been lost. For 
	example, if the value 1234567890.123456 was provided as a DBTYPE_DECIMAL 
	parameter, this would have been incorrectly interpreted as 234567890.123456 
	(the leading 1 would be lost). In particular, this could affect Visual Basic 
	applications using an OleDbDataAdapter on a query with a numeric or decimal 
	typed column, and a generated DataSet. The problem has now been fixed.

    ================(Build #5138  - Engineering Case #362011)================

	The OLEDB provider ASAProv assumed that DBTYPE_BOOL values were 1 byte long. 
	So for database columns of type BIT, it would indicate that only 1 byte needed 
	to be allocated for a DBTYPE_BOOL column. This was incorrect, since DBTYPE_BOOL 
	values are actually 2 bytes long.  Any consumer application that fetched 
	2 bytes for a DBTYPE_BOOL column, (such as applications based on Borland's 
	Delphi), and examined both bytes, would have obtained an incorrect result. 
	Also columns adjacent to DBTYPE_BOOL columns will overlap in memory. This 
	has been fixed.

    ================(Build #5137  - Engineering Case #362207)================

	In the FOREIGN_KEYS rowset (implemented by the sa_oledb_foreign_keys stored 
	procedure), the DEFERRABILITY column contained the values 5 or 6. This column 
	should contain one of the following:
	
	DBPROPVAL_DF_INITIALLY_DEFERRED      0x01
	DBPROPVAL_DF_INITIALLY_IMMEDIATE     0x02
	DBPROPVAL_DF_NOT_DEFERRABLE          0x03
	
	These corrections will appear in the "oleschema.sql" file located in the 
	"scripts" folder once the EBF has been applied. To implement the corrections 
	to an existing database, connect to the database with Interactive SQL and 
	load and run the contents of "oleschema.sql".

    ================(Build #5137  - Engineering Case #362198)================

	In the COLUMNS, PROCEDURE_PARAMETERS and PROCEDURE_COLUMNS rowsets, the CHARACTER_MAXIMUM_LENGTH 
	column contained incorrect values for BIT and LONG VARCHAR/LONG VARBINARY 
	columns and parameters. This column should contain the maximum possible length 
	of a value in the column. For character, binary, or bit columns, this is 
	one of the following: 
	1) The maximum length of the column in characters, bytes, or bits, respectively, 
	if one is defined. For example, a CHAR(5) column in an SQL table has a maximum 
	length of five (5). 
	2) The maximum length of the data type in characters, bytes, or bits, respectively, 
	if the column does not have a defined length. 
	3) Zero (0) if neither the column nor the data type has a defined maximum 
	length. 
	4) NULL for all other types of columns.
	As well, the CHARACTER_OCTET_LENGTH column contained incorrect values for 
	LONG VARCHAR/LONG VARBINARY columns and parameters. The CHARACTER_OCTET_LENGTH 
	column should contain the maximum length in bytes of the parameter if the 
	type of the parameter is character or binary. A value of zero means the parameter 
	has no maximum length. NULL for all other types of parameters.
	
	In the PROCEDURE_COLUMNS and PROCEDURE_PARAMETERS rowsets, the column name 
	should have been CHARACTER_OCTET_LENGTH rather than CHAR_OCTET_LENGTH.
	
	In the PROVIDER_TYPES rowset, the COLUMN_SIZE column contained incorrect 
	values for LONG VARCHAR/LONG VARBINARY types.
	
	These problems have been corrected and will appear in the "oleschema.sql" 
	file located in the "scripts" folder once the EBF has been applied. To implement 
	the corrections to an existing database, connect to the database with Interactive 
	SQL (dbisql) and run the contents of "oleschema.sql".

    ================(Build #5135  - Engineering Case #361464)================

	This change fixes several problems with the DBSCHEMA_INDEXES rowset, implemented 
	by the sa_oledb_indexes stored procedure.
	
	The COLLATION column was always empty. It now contains a 1 for ASCENDING 
	ordering and a 2 for DESCENDING ordering.  
	
	The CLUSTERED column was always TRUE, even for a non-clustered index.  This 
	column now contain 0 unless the index is clustered, in which case it will 
	contain a 1.
	
	The INDEX_NAME column contained the additional string "(primary key)" when 
	the index was based on a primary key.  In the DBSCHEMA_PRIMARY_KEYS rowset 
	(implemented by the sa_oledb_primary_keys stored procedure), the PK_NAME 
	column does not contain this string.
	Since the names were different, it was difficult to join the information 
	in these two tables. Elsewhere the index name is reported using only the 
	table name (in access plans for example). For these reasons, the INDEX_NAME 
	column will no longer contain the string "(primary key)".
	
	The following column names have been corrected:
	
	FKTABLE_CAT is now FK_TABLE_CATALOG
	FKTABLE_SCHEMA is now FK_TABLE_SCHEMA
	PKTABLE_CAT is now PK_TABLE_CATALOG
	PKTABLE_SCHEMA is now PK_TABLE_SCHEMA
	
	These corrections are to the "oleschema.sql" file located in the "scripts" 
	folder, which will be in effect for newly created databases. To implement 
	the corrections to an existing database, connect to the database with Interactive 
	SQL dbisql and run the contents of "oleschema.sql".

    ================(Build #5130  - Engineering Case #360678)================

	ADO applications using the ASA OLEDB provider, ASAProv, could have failed 
	with an "invalid rowset accessor" error.
	
	The following Visual Basic code example demonstrates the problem:
	
	        Dim conn As new OleDbConnection()
	        Dim cmd As OleDbCommand
	        Dim reader As OleDbDataReader
	        Try
	            conn.ConnectionString = "Provider=ASAProv;uid=dba;pwd=sql;eng=asademo"
	            conn.Open()
	            cmd = New OleDbCommand("SELECT * FROM DEPARTMENT", conn)
	            reader = cmd.ExecuteReader()
	            While reader.Read()
	                Console.WriteLine(reader.GetInt32(0).ToString() + ", " _
	                   + reader.GetString(1) + ", " + reader.GetInt32(2).ToString())
	            End While
	            reader.Close()
	            reader = Nothing
	            conn.Close()
	            conn = Nothing
	        Catch ex As Exception
	            MessageBox.Show(ex.Message)
	        End Try
	
	This problem has been fixed, the rgStatus array passed to the IAccessor::CreateAccessor 
	method is now correctly initialized. 

    ================(Build #5127  - Engineering Case #360196)================

	The ASA OLEDB provider ASAProv did not return the correct error codes as 
	documented by Microsoft. For example, the ICommand::Execute method should 
	have returned DB_E_INTEGRITYVIOLATION when a literal value in the command 
	text violated the integrity constraints for a column, but was returning E_FAIL. 
	This has been corrected.
	
	The following additional error codes are also now returned:
	
	 DB_E_NOTABLE
	 DB_E_PARAMNOTOPTIONAL
	 DB_E_DATAOVERFLOW
	 DB_E_CANTCONVERTVALUE
	 DB_E_TABLEINUSE
	 DB_E_ERRORSINCOMMAND
	 DB_SEC_E_PERMISSIONDENIED

    ================(Build #5124  - Engineering Case #359675)================

	When a binary array of bytes was inserted into a binary column using the 
	OLEDB provider "ASAProv", the data was converted to a hexadecimal string 
	and stored into the binary column. For example:
	
		BYTE m_lParm1[2]={0x10,0x5f);
	
	would have been stored as the binary value 0x31303566 which is the original 
	binary value stored as a hexadecimal string of characters. This has been 
	fixed so that parameters are not converted from the user's type to a string. 
	Instead, bound parameters are converted to the type specified by the application.

    ================(Build #5123  - Engineering Case #358843)================

	A memory leak occurred in the OLEDB provider, ASAProv, when a repeated sequence 
	of calls to SetCommandText(), Prepare(), and GetColumnInfo() was executed.  
	These calls could be generated by an ADO Open() call with a SELECT statement 
	containing a number of table JOINs.  This problem has now been fixed.

    ================(Build #5117  - Engineering Case #350319)================

	When using the Microsoft Query Analyzer with Microsoft SQL Server 2000 to 
	issue a query on a Linked Server definition that referenced an ASA server, 
	an error such as the following would have been reported:
	
		Server: Msg 7317, Level 16, State 1, Line 1
		OLE DB provider 'ASAProv.80' returned an invalid schema definition.
	
	For example:
	
		select * from ASA8.asademo.dba.customer
	
	where "ASA8" is the name of the Linked Server, "asademo" is the catalog 
	name, "dba" is the schema name and "customer" is the table name. This problem 
	has been fixed, but the following must also be done in order to support a 
	Linked Server query:
	
	- When the Linked Server is defined, "Provider Options" must be selected.  
	(this button is greyed out and unusable once the Linked Server has been defined). 
	In the Provider Options dialog, the "Allow InProcess" option must be selected.
	
	- ASA does not support catalogs, so the four part table reference must omit 
	the catalog name (two consecutive periods with no intervening characters, 
	ie select * from ASA8..dba.customer). Including a catalog name will result 
	in the error: "Invalid schema or catalog specified for provider 'ASAProv.80'" 
	
	- The database must be updated to include the revised stored procedures 
	found in the scripts\oleschem.sql directory. This file includes a new stored 
	procedure dbo.sa_oledb_tables_info that is required for Linked Server support.

    ================(Build #5003  - Engineering Case #357700)================

	When using a database with the UTF8 collation, statements containing non-English 
	characters could fail with the error "Syntax error or access violation", 
	and Unicode bound data stored in the database could be corrupted.
	
	This problem would affect any application using ODBC or OLEDB, including 
	Java-based applications using the JDBC-ODBC bridge (8.0) or iAnywhere JDBC 
	Driver (9.0), including DBISQL and Sybase Central. 
	
	dbmlsync was also affected.
	
	The bug was introduced in the following versions and builds:
	    8.0.2 build 4409
	    9.0.0 build 1302
	    9.0.1 build 1852
	
	This problem has been fixed.



  Adaptive Server Anywhere - Other



    ================(Build #5500  - Engineering Case #461999)================

	The United State has extended Daylight Saving Time (DST) by 4 weeks in the 
	U.S. time zones that recognize DST. Starting in 2007, Daylight Saving Time 
	will begin the second Sunday in March (2am, March 11, 3 weeks earlier than 
	previous years) and will end the first Sunday in November (November 14, 2am, 
	1 week later than previous years). SQL Anywhere software is not directly 
	vulnerable to issues related to this change, but users of Java logic may 
	need to update their run-time environments. 
	
	For more details, see:
	  http://www.ianywhere.com/developer/technotes/sa_daylight_savings_time_change.html

    ================(Build #5453  - Engineering Case #443642)================

	If an application sent a timestamp structure host parameter which contained 
	an invalid year, the server would not have generated an error if the database 
	option Conversion_error was On. Timestamp structures are used for example, 
	with the embedded 
	SQL type DT_TIMESTAMP_STRUCT, and the ODBC type SQL_TIMESTAMP. If a stored 
	timestamp value with an invalid year was converted to a string, the year 
	component of the string would have contained asterisks (e.g. ****-02-28 ). 
	This has now been fixed so that the server correctly generates the error 
	SQLE_CONVERSION_ERROR (-157) for invalis timestamp structures, even when 
	the option Conversion_error is On.

    ================(Build #5447  - Engineering Case #442574)================

	Applications which did not use ODBC (for example, dbisql and other utilities) 
	would not find a file DSN file if the file was in the default ODBC File DSN 
	directory.  The FILEDSN connection parameter can be used to specify a file 
	DSN.  The default ODBC File DSN directory is the directory where File DSNs 
	are created by default by the Microsoft ODBC Data Source Administrator. This 
	has been fixed.

    ================(Build #5350  - Engineering Case #417977)================

	If an ASA process (such as dbremote, dbmlsync or dbmlsrv8) had been started 
	as a service, it was possible for the process to hang when the service was 
	shut down. This has been corrected so that these services now shutdown correctly.

    ================(Build #5272  - Engineering Case #395071)================

	After installing the 8.0.3 build 5260 EBF for CE, it did not deploy to the 
	device at the end of the install, even if that option is selected. This has 
	been corrected.
	
	A workaround is to select:
	"Deploy SQL Anywhere for Windows CE" from the Start Menu under: SQL Anywhere 
	8

    ================(Build #5269  - Engineering Case #384130)================

	If the length of an indexed table column was increased on a big endian machine, 
	using the index may have caused the server to crash due to an unaligned memory 
	reference. This has been fixed.

    ================(Build #5219  - Engineering Case #380746)================

	Playback of a silent install recording may have failed if the recording included 
	the ADO.NET feature, but the machine being installed to did not have the 
	.NET Framework installed. This has been fixed.

    ================(Build #5219  - Engineering Case #379106)================

	A multithreaded Embedded SQL application could, depending on timing, have 
	failed with the error "Invalid statement" (SQLCODE -130). For this to have 
	occurred, the application had to use the syntax "EXEC SQL DECLARE ... CURSOR 
	FOR SELECT ..." in code which could be run by multiple threads concurrently. 
	This has been fixed so that the SQL Preprocessor generates code for the syntax 
	"EXEC SQL DECLARE ... CURSOR FOR SELECT ..." that is thread safe.
	
	Note the syntax "EXEC SQL DECLARE ... CURSOR FOR :stmt_num" is thread safe 
	(and is not affected by this problem), while the syntax "EXEC SQL DECLARE 
	... CURSOR FOR statement_name" is not thread safe (and cannot be made thread 
	safe).

    ================(Build #5170  - Engineering Case #369278)================

	The stored procedure sp_jdbc_stored_procedures is used by jConnect to retrieve 
	stored proc metadata. Unfortunately the definition of the stored procedure 
	was incorrect and the PROCEDURE_TYPE column of the metadata result set was 
	returning whether or not the particular stored proc returned a result set. 
	In actuality, the PROCEDURE_TYPE column should return whether or not the 
	particular stored proc returns a return value. This procedure has now been 
	corrected.
	
	Note, new databases will have the corrected procedure, but to update existing 
	databases, run the Upgrade utility dbupgrad.



  Adaptive Server Anywhere - Server



    ================(Build #5573  - Engineering Case #474289)================

	If an application maked use of external function calls, the server may have 
	crashed if the application disconnected while a call to an external function 
	was being executed; or if enough connections called external functions such 
	that the server's worker thread limit was exceeded and a deadlock condition 
	arose. This problem has been fixed. When a deadlock condition arises, the 
	error "All threads are blocked" will result for one or more connections executing 
	an external function call.  To avoid this error, the server option -gn can 
	be used to increase the number of worker threads.
	
	When a client disconnects during execution of an external function call, 
	the server will no longer crash.

    ================(Build #5566  - Engineering Case #473827)================

	The server could have failed during database recovery with assertion failures 
	202101 - "Invalid Bitmap Links on Page ..." or 202100 "Invalid bitmap page 
	at page ... -- transaction rolled back" under some circumstances where it 
	was not warranted.  This has been fixed.

    ================(Build #5531  - Engineering Case #466491)================

	The server could have failed with various assertion failure errors when rebuilding 
	a database with an invalid foreign key definition.  For example, if the foreign 
	key trigger action had the column being set to NULL, based on some event 
	and the column definition did not allow NULLs, then this could have occurred. 
	A database could have gotten into this state if at the time the foreign key 
	was created the definition was valid but the column definition changed at 
	a later date.  The proper error is now returned indicating the reason the 
	key is now invalid.
	

    ================(Build #5527  - Engineering Case #465814)================

	Performing a LOAD TABLE into a temporary table that already contained rows 
	could have crashed, if the table had no primary key.  This has been fixed.

    ================(Build #5476  - Engineering Case #449506)================

	Attempting to execute an INSERT ... SELECT, that did not fill columns defined 
	with default timestamp, may have caused the assertion failure "Attempting 
	to store invalid timestamp value in table ...". This occurred when the database 
	option Truncate_timestamp_values was set to ON, and the value for the database 
	option Default_timestamp_increment was greater then 1. This has been fixed.

    ================(Build #5476  - Engineering Case #449193)================

	Duplicate variable declarations in Transact-SQL procedures were not detected 
	as syntax errors when the procedure was created. They would then have caused 
	spurious syntax errors during procedure execution. This has been fixed.

    ================(Build #5473  - Engineering Case #448489)================

	A DESCRIBE of a statement may have returned a syntax error if the SELECT 
	statement contained tables that had CHECK constraints, or articles with WHERE/SUBSCRIBE 
	BY clauses. For this to have occurred the very next operation after PREPARE 
	was an OPEN of a read-only cursor, and the statement described was executed 
	after opening the cursor. This has been fixed.

    ================(Build #5467  - Engineering Case #440209)================

	A WRITETEXT statement would have returned the incorrect SQL error "Subquery 
	cannot return more than one row" if the table had a publication with a "subscribe 
	by (subselect)" condition and the subselect returned more than one row. This 
	has been corrected.

    ================(Build #5465  - Engineering Case #343627)================

	The server could have failed with assertion 100904 during recovery on a database 
	involved in Mobilink synchronization.  This is more likely to occur on a 
	blank padded database.  This fix will now allow recovery to complete.

    ================(Build #5448  - Engineering Case #443285)================

	The utilities dbunload, dbbackup and dbinfo, would not have operated correctly 
	when connected to a SQL Anywhere database that had the SQL_flagger_error_level 
	or SQL_flagger_warning_level options set to anything other than 'W'. Typical 
	behavior included getting the error message Disallowed language extension 
	detected..." when connecting. This has been fixed.
	

    ================(Build #5445  - Engineering Case #442791)================

	Creating a user defined domain with a long default value or CHECK condition 
	(greater than ~258 characters) would have caused a memory leak.  This has 
	been fixed.

    ================(Build #5444  - Engineering Case #442761)================

	The server could have failed with a 'Fatal error: disk full' error when writing 
	to the temporary file, even with TEMP_SPACE_LIMIT_CHECK turned on.  This 
	has been fixed.

    ================(Build #5434  - Engineering Case #439707)================

	It was possible for the server to have crashed if the system procedure sa_server_option( 
	'RequestLogFile', ... ) was called while requests were running. This was 
	less likely on single processor machines. This has been fixed.

    ================(Build #5433  - Engineering Case #434469)================

	The server may have crashed if a trigger on a table that had multiple triggers 
	for the same event (ie. foreign keys with CASCADE referential actions), was 
	currently executing and another connection's operation (e.g. create publication, 
	alter table/view/publication, drop table/view/publication/domain, revoke) 
	marked all the triggers for reload. This has been fixed.

    ================(Build #5431  - Engineering Case #440029)================

	Database corruption, and server crashes and assertions, could have occurred 
	if a database was modifed while in the process of being backed up. This could 
	only have happened on systems with multi-core processors. In 9.x and earlier 
	servers, this could also have happened if many thousands of locks had been 
	obtained.
	
	Note that if a server was running multiple databases, databases other than 
	the one being backed up could have been affected.

    ================(Build #5427  - Engineering Case #438231)================

	Attempting to execute a statement using the Open Client isql utility, that 
	failed with a conversion error, and which referenced to a proxy table, would 
	have leaked cache memory. If such statements were executed many, many times, 
	the server would have eventually failed with a "Fatal Error: Memory Exhausted". 
	This has now been fixed.

    ================(Build #5427  - Engineering Case #437700)================

	When the database option Temp_space_limit_check was set to 'on', the temporary 
	file space used by user temporary tables, such as those created with DECLARE 
	LOCAL TEMPORARY TABLE, was not included in the temporary space limit checking. 
	This has now been fixed.

    ================(Build #5426  - Engineering Case #437306)================

	It was possible, although extremely rare, for a database to get into an inconsistent 
	state, where some rolled back transactions would appeared to have been committed. 
	The chances of this happening were moret likely when performing several large 
	operations without doing any commits, and the operations also spanned checkpoints. 
	The connection doing the operations would have needed to be disconnected 
	before committing, and then the server must have gone down dirty at the appropriate 
	time. It also would have been more likely when 'savepoints' and 'rollback 
	to savepoint' were used.  This has now been fixed.
	

    ================(Build #5416  - Engineering Case #433741)================

	Although rare, the server may have crashed if at that moment a shared memory 
	connection was being established, the client process disappeared. For the 
	same reason a client application may have crashed if the server disappear 
	at the moment the application was about to establish a shared memory connection. 
	This has been fixed.

    ================(Build #5414  - Engineering Case #433047)================

	The LOAD TABLE statement could have incorrectly loaded multi-byte character 
	data, due to incorrect accounting for a split character in a buffer. The 
	loaded data would appear to have characters or bytes within it that were 
	not part of the original data. This has been fixed.

    ================(Build #5414  - Engineering Case #431369)================

	An INSERT statement with the ON EXISTING UPDATE clause could have failed 
	with an incorrect referential integrity error. This would only have occurred 
	if the table had a single column primary key, and there existed a row where 
	value of this column was the same as another column value in the VALUES clause.  
	This has been fixed, but a workaround would be to use an UPDATE statement 
	when the primary key value already exists.

    ================(Build #5413  - Engineering Case #430576)================

	It was possible, although rare, for the server to hang while doing an ALTER 
	TABLE. A deadlock problem updating histograms has been fixed.

    ================(Build #5411  - Engineering Case #432886)================

	Attempting to reference a hexadecimal literal with an odd number of characters 
	between 9 and 15 characters long inclusive, would have caused a syntax error. 
	For example:
	    select cast( 0xF1234ABCD as bigint ); 
	This has been fixed, as now an extra zero is added to the front of odd length 
	hexadecimal strings. Note, hexadecimal strings that are odd in length, and 
	too large to fit into a BIGINT, will still generate a syntax error.

    ================(Build #5404  - Engineering Case #431810)================

	The server may have crashed, rather than return the error "OMNI cannot handle 
	expressions involving remote tables inside stored procedures" (SQLCODE -823 
	: SQLE_OMNI_REMOTE_ERROR).
	
	For example (x is a remote table)
	
	     declare @x int
	     declare @y int
	     select @x =1
	     select @y  =1
	     if (select x from x where y = @y) = @x + 1
	          print 'yes'
	     else
	          print 'no'
	
	This has been fixed.

    ================(Build #5404  - Engineering Case #409006)================

	The server could have deadlocked at the end of an on-line backup if at least 
	two other concurrent transactions performed various unsafe actions. This 
	has been fixed.

    ================(Build #5395  - Engineering Case #426799)================

	The server could have become deadlocked (it would have appeared to be hung), 
	if non-temporary database pages were updated, then freed, in quick succession. 
	This has been fixed.
	

    ================(Build #5394  - Engineering Case #429438)================

	When the return value of a user-defined function was truncated, the server 
	created a temporary string that was not freed until the cursor was closed. 
	This problem only occurred with multibyte character set databases. This has 
	been corrected.
	

    ================(Build #5393  - Engineering Case #429029)================

	The changes for Engineering case 406765 could have caused a server crash. 
	The circumstances where this occurred were rare, and would have required 
	that the CONNECT or REMOTE permissions for a user be dropped, while dbremote 
	was actively replicating transactions for the user. This has been fixed.

    ================(Build #5391  - Engineering Case #428879)================

	When using the Windows Service Manager to start and stop ASA services, the 
	option to pause
	running services was available. This option has been removed for all services, 
	except for
	dbltm.

    ================(Build #5391  - Engineering Case #428685)================

	If the NUMBER(*) function was used in a subquery of an expression, and the 
	expression referenced a proxy table, the server may have crashed. This has 
	been fixed.

    ================(Build #5384  - Engineering Case #426984)================

	When upgrading a database, either by executing the ALTER DATABASE UPGRADE 
	statement, or running the Upgrade utility, the upgrade did not run the oleschem.sql. 
	This has now been corrected

    ================(Build #5381  - Engineering Case #426056)================

	Attempting to execute a "SELECT INTO #temporary-table-name" statement, may 
	have caused a server crash in cases where it should have returned the error 
	"Statement size or complexity exceeds server limits". This has been fixed.

    ================(Build #5381  - Engineering Case #407422)================

	It was possible for the server to fail with Assertion 200602: 'Incorrect 
	page count after deleting pages from table {table_name} in database {database_name}', 
	when dropping or truncating a table for which a LOAD TABLE had failed. It 
	was also possible for a failed LOAD TABLE to leak table pages, or temporary 
	file pages. A failed ALTER TABLE could have resulted in many other assertions 
	or strange behaviours. These problems would only have occurred if there where 
	other transactions actively committing and rolling back transactions at the 
	time of the LOAD TABLE or the ALTER TABLE.  These problems have now been 
	fixed.

    ================(Build #5376  - Engineering Case #423681)================

	The server may have crashed during the second or subsequent executions of 
	a procedure, 
	if after its first execution, one of the referenced objects (table, view, 
	proxy table, etc) had been dropped and recreated with a changed type. For 
	example, a referenced table was dropped and a view with the same name was 
	recreated. This has been fixed

    ================(Build #5376  - Engineering Case #423578)================

	Attempting to OPEN a cursor on a procedure call that returned the SQL warning 
	"Procedure has completed", would not have opened a cursor. The server still 
	created a cursor handle though, which was not freed until database shutdown. 
	This has been fixed so that the server will now return a NULL handle if the 
	cursor has not been opened.

    ================(Build #5373  - Engineering Case #423858)================

	Applicatons connected via the CmdSeq protocol, could have crashed if a connection 
	request resulted in a warning. This has been fixed.

    ================(Build #5373  - Engineering Case #423129)================

	It was possible, although very rare, for all connections to the server appear 
	to be hung (deadlocked) in the presence of DDL statements, checkpoints, backups, 
	or other operations, if a connection that was executing Java was cancelled. 
	This has now been fixed. 

    ================(Build #5371  - Engineering Case #422487)================

	If a cursor was opened on a stored procedure call, and the procedure executed 
	a RAISERROR statement, the error was not reported on the OPEN. The value 
	of @@error would have been set to the integer value given in the RAISERROR 
	statement and would have remained set to that value even after other statements 
	were executed, until another RAISERROR was executed or the connection was 
	dropped.  This has been fixed so that an error will now be reported to the 
	application on the OPEN.

    ================(Build #5369  - Engineering Case #408903)================

	Running the Validation utility would have cause the server's temporary file 
	to grow on each execution if validation with express check (-fx) was chosen. 
	This is the default mode in 9.0.2. The amount of growth would depend on the 
	number of tables in the database and the size of those tables. This has now 
	been fixed. A workaround is to validate using -fn rather than -fx. Validation 
	performance should improve with this fix as well.

    ================(Build #5364  - Engineering Case #420171)================

	A failed UPDATE statement, for example due to a deadlock error, could have 
	resulted in a corrupted index. It is likely that only databases involved 
	in replication would have been affected by this problem. A database validation 
	with 'full check' would have detected that the index had missing values. 
	This has been fixed, but dropping and re-creating an index in such a state 
	will fix the corruption.

    ================(Build #5361  - Engineering Case #420042)================

	An INSERT, UPDATE or DELETE statement may have incorrectly returned the error 
	"Invalid statement", if the execution of the statement caused a trigger to 
	fire, or an RI action was executed, and a subsequent statement then failed 
	with a deadlock error. This has been fixed.

    ================(Build #5360  - Engineering Case #420864)================

	While a database upgrade is in progress, event execution is not allowed. 
	If a scheduled
	event did fire during a database upgrade it was correctly not executed, 
	but it was also incorrectly not scheduled for its next execution. This meant 
	that the event would not have been executed again until the database was 
	restarted. This has been fixed, so that now the event is rescheduled for 
	the next execution.
	

    ================(Build #5359  - Engineering Case #419782)================

	If a query contained an alias in the SELECT list, with the aliased expression 
	containing an IF or CASE expression, where the predicate in the IF or CASE 
	contained an EXISTS, ANY, or ALL predicate, and the aliased expression was 
	used as an outer reference in another subquery, and the execution plan contained 
	a materializing operator such as Hash Join, then incorrect results could 
	have been returned for the IF/CASE expression and the referencing subquery.
	
	The following query demonstrates the problem using the demo database:
	
	select	T2.dept_id,
			( if  exists ( select  1 from sys.dummy T4  where  T2.dept_head_id &lt&gt 
	-1 ) then 1 endif ) as S2,
	  		( select 1 from sys.dummy T5 where S2 &gt 0 ) as S3
	from
	    rowgenerator T0  with ( no index )
	      join department as T2 with ( no index )
	            on  T0.row_num*100 = T2.dept_id
	
	This has been fixed.

    ================(Build #5359  - Engineering Case #419708)================

	Subqueries with an ANY or ALL condition, that also contained both a DISTINCT 
	and a TOP n clause (where n &gt 1), could have returned incorrect results. 
	The server was incorrectly eliminating the DISTINCT, which meant that some 
	rows could have been missed from the subquery. This has now been fixed.
	

    ================(Build #5357  - Engineering Case #420137)================

	On Unix systems, if an application autostarted a server, used ASA's embedded 
	SQL function db_start_engine(), or used the Spawn utility to start a server, 
	and the application was terminated abnormally by SIGINT, SIGQUIT, SIGTERM 
	or some other unhandled signal (SEGV, etc), the server that had been started 
	would shutdown unexpectedly, although cleanly. This has been fixed.
	
	A work-around is to specify -ud on the server command line, although this 
	has the side effect that the controlling application (e.g. dbspawn) will 
	return/continue immediately before the server has fully started all of its 
	databases, etc.

    ================(Build #5350  - Engineering Case #418346)================

	If two or more users with DBA authority granted the same column update permission 
	to a user, these column permissions could then only have been revoked by 
	revoking the table update permission. Any attempt to revoke the column update 
	permission would have failed with the error "You do not have permission to 
	revoke permissions on &lttable&gt". This has been fixed.

    ================(Build #5347  - Engineering Case #404396)================

	The server could have gone into an infinite loop while performing operations 
	on a database corrupted in a certain way. Validation of the database may 
	or may not have experienced the same behaviour. The server will now fail 
	with "Assertion 202101: Invalid bitmap links on page 0x%x" when such a condition 
	is encountered.

    ================(Build #5337  - Engineering Case #409861)================

	The server could have failed with the error - "Assertion failed : 101412 
	Page Number on page does not match the page requested" or possibly crashed.  
	This has been fixed.

    ================(Build #5336  - Engineering Case #415979)================

	When the server was using a database file that was located on another machine 
	via Windows file sharing, or was located on the local machine but referenced 
	using a UNC name (such as \\mymachine\myshare\mydb.db), it could have failed 
	with one of the following errors (and possibly other assertion failures and 
	fatal errors, including OS error 58):
	  I/O Fatal error: Unknown device error
	  Assertion failed: 201125 Read Error with OS error code: 64
	 
	The problem only occurs on certain machines with certain patches and/or 
	hardware and/or drivers, the specifics of which have not been completely 
	identified. The problem is related to scattered reads (aka "group reads") 
	-- see the documentation to determine when the server may use scattered reads. 
	The server now works around this OS problem by disabling scattered reads 
	for files accessed by remote file sharing, or by UNC reference.

    ================(Build #5326  - Engineering Case #407565)================

	When run on some Windows CE devices, after the server had grown a file, the 
	OS would start to ignore the FILE_FLAG_WRITE_THROUGH flag, as well as the 
	FlushFileBuffers() call. On Windows CE, the server uses FlushFileBuffers() 
	to guarantee IO ordering for recoverability. In an attempt to work around 
	this problem, the server has been changed to close and reopen files after 
	the first call to FlushFileBuffers() after a file grows. It is not known 
	exactly which versions of Windows CE contain this problem.

    ================(Build #5325  - Engineering Case #409772)================

	The server may have crashed when executing a query with a subselect, if the 
	subselect caused an error when describing the result set. This has been fixed.

    ================(Build #5323  - Engineering Case #409773)================

	If an error occurred while executing a subquery, then there is a chance that 
	the server would have left heap unfreed. This has now been fixed.

    ================(Build #5322  - Engineering Case #408655)================

	Executing a very large query could have caused the server to crash. This 
	has been fixed.

    ================(Build #5321  - Engineering Case #409283)================

	If an SMTP email was sent using the xp_sendmail procedure, and the engine 
	received a socket timeout error for a socket receive, the next xp_sendmail 
	or xp_stopsmtp call would have caused the server to crash. This has been 
	fixed.

    ================(Build #5320  - Engineering Case #402416)================

	The performance of a Java stored procedure may have degraded the longer it 
	ran. This would occur if a JDBC Statement object that remained open for a 
	long time caused muliple warnings. Eventually, the buildup of SQLWarning 
	objects would have exhusted the Java heap, causing the Java garbage collector 
	to run continuously. These SQLWarning objects would have been garbage collected 
	when the JDBC Statement was closed, or when the clearWarnings function was 
	called by the Java procedure. This problem has been fixed by clearing the 
	Statement's SQLWarning objects whenever the Statement's associated ResultSet 
	is closed.
	
	Note that the default heap size may be to small for some applications, but 
	can be increase with the Java_heap_size database option.

    ================(Build #5319  - Engineering Case #408745)================

	Image backups produced by a server when running on a multi-processor machine 
	could have been corrupt. This would have occurred if there was more than 
	one transaction concurrently modifying the database. This has now been corrected.
	

    ================(Build #5319  - Engineering Case #402417)================

	A memory leak in the Java VM would have caused poor performance of a Java 
	stored procedure if it was called hundreds of times. The cause of the performance 
	drop was exhaustion of the Java heap, forcing the Java garbage collector 
	to run continuously. This has been fixed. 
	
	Note that the default heap size may be to small for some applications, but 
	can be increase with the Java_heap_size database option.

    ================(Build #5318  - Engineering Case #407670)================

	Subqueries with an EXISTS predicate may no longer be flattened if the subquery 
	contains two or more tables in the FROM clause, and it is not known if the 
	subquery returns at most one row. The main issue with flattening subqueries 
	with more than one table in the FROM clause is that a Distinct on rowids 
	is always needed for the plan of the main query block. 

    ================(Build #5317  - Engineering Case #408062)================

	If a query referencing a proxy table was to be executed in "No passthru" 
	mode and the proxy table contained a varchar column, then any trailing blanks 
	in the varchar column would have been incorrectly stripped. This problem 
	has been fixed.

    ================(Build #5315  - Engineering Case #408097)================

	On Unix systems, calling the ODBC function SQLDataSources() would have caused 
	the server to crash with a SegFault, if no Driver Manager was being used. 
	This has been fixed.

    ================(Build #5311  - Engineering Case #406857)================

	If a query like "SELECT TOP 5 * FROM T" was executed without an ORDER BY 
	clause, the server would normally return a warning stating that "the result 
	returned is non-deterministic." For Open Client applications, this warning 
	is now nonger returned.

    ================(Build #5311  - Engineering Case #406765)================

	Database recovery could have failed with assertion 201501 "Page for requested 
	record not a table page or record not present on page". The problem would 
	only have occurred in the event of the database server not shutting down 
	cleanly while dbremote replication was taking place. It would also have been 
	required that another connection revoked CONNECT or REMOTE from the remote 
	user for which the transactions were being replicated. This has been fixed 
	so that connections attempting to revoke permissions from the user for which 
	replication is currently occurring will now receive an error indicating that 
	the operation is "Not allowed while user 'user_name' is actively replicating 
	transactions".  The connection attempting to REVOKE permissions will need 
	to wait until replication completes (commit/rollback) before being able to 
	revoke the permissions.

    ================(Build #5311  - Engineering Case #400091)================

	When a multi-byte character string was truncated in the middle of a character 
	by being but into a column that was not wide enough to for the whole string, 
	subseqent selects would have return a NULL at the end of the data. This could 
	have caused MobiLink synchronizations to fail, as the NULL was misinterpreted. 
	This has been fixed by truncating the string at the last full character.

    ================(Build #5311  - Engineering Case #393270)================

	If a server was running with a ServerName longer than 32 bytes, attempts 
	to connect to it using SPX would have failed. This has now been fixed so 
	that only the first 32 bytes are relevant for SPX.
	

    ================(Build #5309  - Engineering Case #406030)================

	The server could have crashed when referencing a variable declared as a VARBINARY 
	of unspecified length.  This has been fixed.
	

    ================(Build #5309  - Engineering Case #405397)================

	When run on Windows CE devices, the server was not have recognising the registry 
	setting to change the location of the temporary folder. This has been fixed, 
	so that temporary files may now be moved to a storage card.

    ================(Build #5303  - Engineering Case #404767)================

	If an INSERT...SELECT was executed, such that the table being inserted into 
	was in a publication and the table being selected from was a proxy table, 
	then it was possible that the statement would have failed with unnexpected 
	errors. The most likely error was a "conversion error", but any number of 
	errors could have been returned. The problem has now been fixed.

    ================(Build #5302  - Engineering Case #393093)================

	If executing an SQL Remote PASSTHROUGH statement caused a trigger to fire, 
	the statement would not have been send to the remote server. The problem 
	did not occur for PASSTHROUGH ONLY statements, since the statement did not 
	execute locally, no triggers were fired. This has been fixed. 

    ================(Build #5301  - Engineering Case #404151)================

	Calling a procedure owned by another user with the result of a function owned 
	by a third user would have resulted in a 'permission denied' error. This 
	has now been fixed.
	
	For example, the following this sequence would have generated the 'permission 
	denied' error:
	
		create procedure userA.hello( in name char(10) )
		begin
			message 'Hello ' || name;
		end;
		grant execute on userA.hello to userC;
	
		create function userB.world()
		returns char(10)
		begin
			select 'world';
		end;
		grant execute on userB.world to userC;
	
		create procedure userC.say_hello( )
		begin
			call userA.hello( userB.world() );
		end;
		call userC.say_hello();

    ================(Build #5301  - Engineering Case #394297)================

	Attempting to execute a statement like INSERT INTO v SELECT ..., where v 
	is a view on a proxy table, would have caused the server to crash. The problem 
	has now been fixed.

    ================(Build #5299  - Engineering Case #403355)================

	Executing a REORGANIZE TABLE statement without the PRIMARY KEY, FOREIGN KEY 
	or INDEX clauses could have caused the server to become deadlocked and appear 
	to hang. This problem has now been fixed.

    ================(Build #5299  - Engineering Case #403151)================

	The database server could have crashed when connecting to the utility_db 
	from an ODBC application. This would only have occurred if the ODBC driver 
	was a newer version than the server. This has been fixed.

    ================(Build #5298  - Engineering Case #402727)================

	Issuing a START DATABASE request for a database with a mismatched transaction 
	log could have failed with the error message "Cannot open transaction log: 
	'???' belongs to a different database".  The error message now correctly 
	specifies the transaction log file name in place of the string '???'.

    ================(Build #5293  - Engineering Case #402038)================

	Executing an INSERT statement that specified a very long list of columns 
	(approx 1/4 of the database page size in bytes), could have caused a server 
	crash. This problem has been resolved. A temporary (inefficient) work around 
	would be to start the server with a larger cache page size.

    ================(Build #5292  - Engineering Case #401645)================

	The server gathers and updates column statistics as part of the query execution 
	process. In the case of NOT predicates, the server could have incorrectly 
	changed the stored selectivity of these predicates to 100%. This problem 
	has been resolved.

    ================(Build #5290  - Engineering Case #400924)================

	Setting the system clock back to an earlier time (either manually or by a 
	system daemon) on non Windows platforms (i.e. NetWare, Unix) could have caused 
	any of the following symtoms:
	- timestamps reported in the request level log could jump ahead approximately 
	25 days
	- client applications could be incorrectly disconnected
	
	This has been fixed.
	

    ================(Build #5289  - Engineering Case #399488)================

	Multiple errors were defined with SQLSTATE 28000. As a result, an incorrect 
	error message could have been returned. This has been corrected with the 
	following changes: 
	
	SQLSTATE_PARM_TOO_LONG changed from 28000 to 53W06
	SQLSTATE_PASSWORD_TOO_SHORT changed from 28000 to 54W07
	SQLSTATE_PASSWORD_TOO_LONG changed from 28000 to 54W08
	SQLSTATE_INVALID_LOGON and SQLSTATE_INVALID_PASSWORD continue to return 
	28000
	

    ================(Build #5289  - Engineering Case #399155)================

	The server would have crashed under the following conditions:
	- A BEGIN END block contained a nested BEGIN END block
	- Inside the nesting block a local temporary table was declared (e.g. using 
	execute immediate)
	- The outer block declared a cursor on the temporary table and was opened 
	inside the nested block but not closed in the nested block
	- The cursor used an index on the temporary table
	This has been fixed.

    ================(Build #5286  - Engineering Case #400467)================

	Additional changes have been made to ensure that proper metadata is provided 
	for newer versions of jConnect. If a new version of jConnect is to be used, 
	then it is recommended that the new version of JCATALOG.SQL is run against 
	the database.

    ================(Build #5282  - Engineering Case #398122)================

	While initializing the in-memory free list on start up, the server could 
	have run out of memory if the database was corrupt. The server will now generate 
	assertion 202100 - "Invalid bitmap page at page (page number)" when encountering 
	such corruption.
	

    ================(Build #5281  - Engineering Case #398604)================

	It was possible for the server to loop infinitely while going through automatic 
	database recovery if the database file was corrupted.  This could have occurred 
	when deleting an entry from a corrupted index.  "Assertion 200901: Corrupted 
	page link found on page (0x%x) while deleting from index %s"  will now be 
	generated for this situation.
	
	

    ================(Build #5279  - Engineering Case #397772)================

	If a LOAD TABLE command failed, for example with a primary key violation, 
	then it was possible that the server would leak table pages and index pages 
	in the database.  These leaked pages would not have belonged to any database 
	object and would also not have been marked as free.  As a result, the database 
	file could have been larger than necessary.  The only way to recover the 
	lost space is to rebuild the database.
	

    ================(Build #5277  - Engineering Case #398132)================

	If a backup of the database was being performed and the transaction log was 
	either being renamed or truncated, if the database engine was unable to open 
	a new transaction log (or mirror log), an error would have been returned 
	to the backup process, but the server could have continued to apply operations 
	without logging them to the transaction log.  The server will now faile an 
	assertion when it cannot open a new transaction log or mirror after the truncation 
	or rename, as this should be a fatal error.

    ================(Build #5275  - Engineering Case #397635)================

	The server could have crashed while executing a stored procedure, if it was 
	executed often enough to enable caching. This has been fixed.

    ================(Build #5274  - Engineering Case #396584)================

	If a query referenced a proxy table and contained an ORDER BY clause, and 
	an ON condition in the FROM clause, it may have returned incorrect results 
	or an error. This has been fixed.

    ================(Build #5273  - Engineering Case #397134)================

	A query that referenced proxy tables and contained a row limitation in the 
	SELECT clause (ie. FIRST n or TOP n) may have incorrectly returned the warning 
	"The result returned is n
	non-deterministic.", even if the query had an ORDER BY clause. This has 
	been fixed.
	
	Note, this will not have happened if the complete query was forwarded to 
	the remote
	server, (ie. Full Pass-thru mode). 

    ================(Build #5272  - Engineering Case #396813)================

	Changes for Engineering Case 395908 introduced a bug such that long binary 
	and long varchar columns were truncated for Open Client and jConnect applications. 
	This problem has been fixed.

    ================(Build #5272  - Engineering Case #396058)================

	Inserting a string longer than 64K bytes into a column of a proxy table, 
	would have caused the local server to crash. This has been fixed.

    ================(Build #5272  - Engineering Case #395908)================

	If an Open Client or jConnect application described a column that was of 
	type Varchar(n) or Varbinary(n), the size reported for the column would have 
	been 32768 instead of n, if n was greater than 255. This problem has now 
	been fixed.

    ================(Build #5272  - Engineering Case #395054)================

	If the database option Wait_for_commit was set to ON while executing a LOAD 
	TABLE statement, and it failed with a referential integrity error, then the 
	database could have been left in an inconsistent or corrupt state. This has 
	been fixed.
	
	Some of the errors that might be characteristic of this problem are:
	- Assertion 200602 - Incorrect page count after deleting pages from table 
	'table_name' in database 'database_name' - could occur during TRUNCATE TABLE 
	or DROP TABLE.
	- Database validation could report that an index has inaccurate leaf page 
	count statistics.
	- Database validation could report that a foreign key is invalid and that 
	some primary key values are missing.
	- Database validation could report that the rowcount in SYSTABLE is incorrect.
	- Inconsistent row counts might be observed when querying the table sequentially 
	versus via an index.
	
	

    ================(Build #5270  - Engineering Case #393745)================

	When running the reload.sql generated by the Unload utility, executing LOAD 
	STATISTICS statements may have failed. This would have occurred if the column 
	was of type binary or long binary, and the source database and the target 
	database had different collations
	     (e.g. one had a single byte collation and the other one a multi-byte 
	collation).
	This has been fixed so that now the statistics of binary columns are only 
	loaded if both databases have the same collation.

    ================(Build #5269  - Engineering Case #394668)================

	The ON EXISTING UPDATE clause of the INSERT statement can be used to update 
	rows that already exist in the database. By default, columns with default 
	values in existing rows should be left unmodified unless their values are 
	explicitly changed by the INSERT statement. Under some circumstances, the 
	server could have modified these columns incorrectly. This problem has been 
	resolved.
	
	As a simplified example consider the following:
	
	drop table a;
	
	CREATE TABLE a ( 
	   a1 INTEGER NOT NULL,
	   a2 INTEGER NOT NULL,
	   a3 INTEGER NOT NULL DEFAULT AUTOINCREMENT,
	   a4 INTEGER NOT NULL,
	   PRIMARY KEY ( a1, a2 ) );
	
	INSERT INTO a VALUES( 1, 1, 1, 1);
	INSERT INTO a VALUES( 2, 1, 2, 2);
	commit;
	
	INSERT a ON EXISTING UPDATE WITH AUTO NAME
	  SELECT 1 AS a1, 99 AS a2, 11 AS a4
	  union all
	  SELECT 2 AS a1, 1 AS a2, 88 AS a4;
	
	
	The INSERT statement should
	
	1. Insert a new rows into table a with PKEY &lt1,99&gt, and
	2. Update the value of a.a4 to 88 in the row with PKEY &lt2,1&gt. The default 
	column a.a3 in this row should now remain unchanged.

    ================(Build #5267  - Engineering Case #387997)================

	A database file may have grown, even when free pages existed in the dbspace, 
	if the free space was fragmented such that no 8-page cluster aligned on an 
	8-page boundary existed within the dbspace, and pages for a large table (one 
	with bitmaps) were being allocated. When growing a large table prior to this 
	change, the server always allocated table pages in clusters of eight pages 
	so that group-reads could be performed on a sequential scan. If no clusters 
	were found, the dbspace was grown to create one. Now, if no free cluster 
	is found, the server will attempt to allocate pages from a cluster that has 
	both free pages as well as pages allocated to the table that is being grown. 
	If no free pages are found by this method, the server will use any free page 
	in the dbspace. So now te dbspace will not grow until there are no free pages 
	left in the dbspace.
	 
	As a work-around, periodically running REORGANIZE TABLE on all tables will 
	generally avoid the problem
	 

    ================(Build #5267  - Engineering Case #384959)================

	Changes made for Engineering Case #363767 could have caused the database 
	file to grow unnecessarily. A page that was in use as of the last checkpoint 
	is allowed to be reused before the next checkpoint, provided its preimage 
	has been saved in the checkpoint log. Prior to the changes for case 363767, 
	the preimage for a freed page was forced to disk and the page was allowed 
	to be reused immediately. After the changes for case 363767, the freed page 
	was not allowed to be reused until after the next checkpoint, because the 
	server no longer forced the preimage to disk for performance reasons. If 
	an application freed and reused pages frequently (for example, repeatedly 
	deleting all rows from a table then inserting rows back into the table), 
	the server would not have allowed many of the free pages to be used until 
	after the next checkpoint. The problem has been fixed by keeping track of 
	the set of free pages that would normally be allowed to be reused if only 
	the preimages were committed to disk.
	 
	Note that this growth was not unbounded and was not a 'leak', as the pages 
	are freed as of the next checkpoint. This problem only affected databases 
	created with 8.0.0 or later.
	 

    ================(Build #5266  - Engineering Case #393746)================

	If a space did not follow the method name in the EXTERNAL NAME clause of 
	the wrapper function to a Java method, calls to the function would have resulted 
	in a procedure not found error.
	
	For example:
	a wrapper function definition of
	CREATE FUNCTION MyMeth (IN arg1 INT, IN arg2 varchar(255),IN arg3 INT )
	   RETURNS Int
	   EXTERNAL NAME 'TestClass.MyMethod(ILjava/lang/String;I)I'
	   LANGUAGE JAVA;
	
	would have resulted in the error
		Procedure 'TestClass.MyMethod(ILjava/lang/stringI)I' not found.
	
	where as
	   EXTERNAL NAME 'TestClass.MyMethod (ILjava/lang/String;I)I'
	
	would have worked. This has been fixed so that a space is no longer required 
	between the method name and the left parenthesis.

    ================(Build #5263  - Engineering Case #393022)================

	If an expression contained a reference to a proxy table, the server would 
	have crashed if the expression was used: 
	 - in a MESSAGE or PRINT statement
	 - in a RETURN statement of a function or procedure
	 - in a time/delay expression in a WAITFOR statement
	 - in an offset expression of a FETCH statement
	This has been fixed so that the server now correctly returns the error "OMNI 
	cannot handle expressions involving remote tables inside stored procedures"

    ================(Build #5262  - Engineering Case #392668)================

	If an application used the Remote Data Access feature to perform an INSERT 
	from SELECT in 'no passthru' mode, and the insert received an error, it was 
	possible for the server to have crashed. This problem has now been fixed.
	

    ================(Build #5262  - Engineering Case #392216)================

	If a proxy table contained a column declared with DEFAULT AUTOINCREMENT, 
	and an insert into that table did not contain a value for that column, the 
	server may have crashed. For this to have happened, one of the column values 
	in the insert statement had to be an expression or function call that needed 
	to be evaluated. This has been fixed.

    ================(Build #5261  - Engineering Case #392502)================

	If a Java application closed an SAConnection object, and then subsequently 
	called the 'isClosed' method on the same object, an exception would have 
	been thrown erroneously. This has been fixed.

    ================(Build #5259  - Engineering Case #392068)================

	When backing up a database to multiple tapes, after the first tape had been 
	written, the request for the next tape would have failed. This problem has 
	been fixed.
	

    ================(Build #5258  - Engineering Case #391751)================

	Numerous changes have been made to the system procedures used by jConnect 
	when connected to ASA servers. Newly created databases will have these changes, 
	but to update existing databases run the script jcatalog.sql, which is in 
	the scripts directory.

    ================(Build #5257  - Engineering Case #391357)================

	If the text of a stored procedure, view or trigger was made unreadable using 
	the HIDDEN keyword, and the definition string was invalid, the server may 
	have crashed. This has been fixed.
	

    ================(Build #5257  - Engineering Case #391182)================

	If the text of a stored procedure was made unreadable with the HIDDEN clause, 
	and it contained a call to itself with at least one parameter, then any call 
	to this procedure will have failed with the error "Wrong number of parameters 
	to function 'proc_name'". The error would have disappeared after restarting 
	the database or reloading the procedures due to the execution of a DDL statement. 
	This has now been fixed.

    ================(Build #5255  - Engineering Case #390765)================

	If an Open Client dblib application attempted to fetch a tinyint value using 
	the dbdata() function, instead of dbbind(), then the application would always 
	get the value 0, instead of the actual tinyint value. Note that this problem 
	only occurred if the tinyint value was nullable. This problem has now been 
	fixed.

    ================(Build #5251  - Engineering Case #389796)================

	When performing an UPDATE (or possibly a DELETE) using a keyset cursor, over 
	a table that was joined to itself (i.e. appears multiple times in the UPDATE 
	or FROM clause), the server could have failed to obtain write locks on rows 
	it modified.  This could have resulted in lost updates, or a corrupted index, 
	if an update was made to an indexed column. This has been fixed.

    ================(Build #5250  - Engineering Case #389598)================

	If an Open Client application used unsigned datatypes in an Remote Procedure 
	Call, there was a good chance the application would hang. This problem has 
	now been fixed.
	

    ================(Build #5249  - Engineering Case #388498)================

	The server automatically gathers and maintains column statistics as queries 
	are executed. If multiple connections concurrently updated column statistics 
	as a result of query execution, there was a potential for some column statistics 
	to become inaccurate. This problem has been resolved.
	

    ================(Build #5249  - Engineering Case #382839)================

	When using the Microsoft SQL Server "Import and Export Data" tool to move 
	tables from a Microsoft SQL Server database to an ASA database, and the connection 
	to the ASA server used the OLEDB provider, column data was truncated to 200 
	bytes. This has now been fixed.

    ================(Build #5248  - Engineering Case #389230)================

	While running multiple connections that fetched from different proxy tables, 
	and different remote servers using ASEJDBC, if one connection was killed 
	then the server's Java Virtual Machine can no longer be started. This has 
	now been fixed.

    ================(Build #5248  - Engineering Case #388838)================

	If a proxy table was created with a column that contained a DEFAULT clause, 
	then an insert into that table would have failed if the insert explicitly 
	specify the column, but with a different case for the column name. The returned 
	error would have been "Duplicate insert column". For example:
	
		create table T1 ( col1 int  default 10, col2 int ) at '....';
		insert into T1 ( COL1, col2 ) values ( 1, 1 );
	
	This has been fixed.

    ================(Build #5248  - Engineering Case #388752)================

	If a column's COMPUTE clause contained a string constant, or a string constant 
	expression, the server would have crashed each time the compute expression 
	was evaluated. This has been fixed.
	

    ================(Build #5241  - Engineering Case #387061)================

	The locked_heap_pages and main_heap_pages statistics were being reported 
	incorrectly if the performance monitor was left running during server restarts.  
	Further, these counters were not being reported as accurately as they could 
	have been. These problems have been corrected.

    ================(Build #5240  - Engineering Case #386918)================

	When an error occurred in a subselect  that was part of a procedural statement 
	(for example, SET, MESSAGE, IF/WHILE conditions, etc.), the server would 
	have failed to release part of the cache that was used by that subselect. 
	Subselects that are part of queries that return results sets, explicitly 
	opened cursors, insert...select, or select...into statements, are not affected. 
	This would not cause any immediate problems, however if a large number of 
	calls were made to such procedures, an increasing portion of the database 
	server cache would have become unavailable to the server for normal use. 
	This would then have caused the cache to grow larger than necessary, and 
	eventually, given enough such calls, have failed with a 'Dynamic Memory Exhausted' 
	error. This may also have shown up as steadily decreasing server performance.  
	This problem was more likely to appear if stored procedures were written 
	with exception handlers or ON EXCEPTION RESUME. This has now been fixed. 
	A workaround is to restart the server whenever performance drops below an 
	acceptable level, or at shorter intervals than the memory exhaustion error 
	is reported.

    ================(Build #5236  - Engineering Case #377749)================

	A REMOVE JAVA CLASS ... statement would sometimes have failed to remove the 
	Java class, as an obsolete version of the class had a foreign key reference 
	to the current version. This problem was been fixed by deleting all obsolete 
	versions of a Java class first, and then deleting the current version.

    ================(Build #5235  - Engineering Case #385530)================

	If an ALTER VIEW statement was executed by the creater of the view, but that 
	user no longer has RESOURCE authority, a "permission denied" error would 
	have been reported. The view definition in SYSTABLE.view_def would still 
	have been updated, but the preserved source for the view in SYSTABLE.source 
	would not have been updated. This has been fixed, now no error will be reported 
	in this situation, and the preserved source will be updated.

    ================(Build #5235  - Engineering Case #385494)================

	The IsNumeric() function would have returned an error when the parameter 
	was too long. It now returns FALSE, since the parameter can't be numeric.

    ================(Build #5234  - Engineering Case #385158)================

	When the schema of a database object was modified by a DDL statement, any 
	existing views that refered to the modified object could potentially have 
	become invalid. However, the server did not detect any problems until the 
	view was subsequently referenced. In order to avoid such problems from happening, 
	it was necessary to recompile the affected views via the "ALTER VIEW ... 
	RECOMPILE" statement. If such recompilation was not done after dropping a 
	column that is referenced by a view for example, then the server could have 
	crashed in certain situations when the affected view was referenced. This 
	has been fixed, the server will now generate an error without crashing.
	
	The server will now generate an error without crashing.

    ================(Build #5233  - Engineering Case #381771)================

	When performing a backup to a tape device on Windows systems, the server 
	would have asked for a tape switch after 1.5 GB of data had been backed up, 
	even if the tape capacity was larger. This problem has been fixed. The server 
	will now use the entire capacity remaining on the tape.
	
	As a workaround, the desired capacity can be specified using the "capacity=" 
	option in the device string.  
	
	For example:
	
		BACKUP DATABASE TO '\\.\tape0;capacity=20064829' ATTENDED ON etc.
	
	The value specified is in K and is calculated by dividing 20,546,384,896 
	(which is the capacity in bytes reported by Windows for a 20 GB tape) by 
	1024. 

    ================(Build #5230  - Engineering Case #382307)================

	When run on Sun Solaris systems, the server could, in rare circumstances, 
	have crashed executing a CREATE DOMAIN statement. This has been fixed.

    ================(Build #5229  - Engineering Case #382022)================

	A memory leak in the Java Heap would have caused poor performance for Java 
	stored procedures, that used internal JDBC to access the database, if it 
	was called repeatedly. When a procedure like this was called repeatedly without 
	disconnection, the Java Heap would slowly grow until it reached its maximum, 
	at which time the Java Garbage Collector would run every time a memory allocation 
	request was made, causing poor performance. The memory leak has been fixed.

    ================(Build #5227  - Engineering Case #381486)================

	If a large number of statements was being used concurrently by applications 
	connected to a database, a "SQL Statement error" could be issued. The maximum 
	number of concurrent statements that can be handled by the server per database, 
	was limited to 20 * (number of connections to the database) + 16384. This 
	limit has now been changed to be approximately 20 * (number of connections 
	to the database) + 65534. The exact number is dependent on the page size 
	of the database cache.

    ================(Build #5227  - Engineering Case #377911)================

	Using AWE on Windows 2003 would very likely have caused some or all of the 
	following:
	1) a blue screen error 76 with text "Process has locked pages",
	2) event log messages indicating that a "driver is leaking locked pages",
	3) ASA fatal errors indicating the reads or writes were failing with the 
	error code 1453 (ERROR_WORKING_SET_QUOTA), and/or
	4) other generic fatal read/write errors
	
	Microsoft has fixed this problem in Service Pack 1 of Windows 2003. It is 
	our understanding that no fix will be made by Microsoft prior to the release 
	of Service Pack 1.
	
	In order to prevent these serious consequences the database server can no 
	longer be started on Windows 2003 pre-SP1 while using AWE.  Any attempt to 
	do so will result in a startup error "Windows 2003 does not properly support 
	AWE caching before Service Pack 1"
	
	At the time this description was written there was no existing Microsoft 
	Knowledge Base (KB) article describing this issue.

    ================(Build #5226  - Engineering Case #382345)================

	Attempting to autostart a database with an invalid DatabaseSwitches connection 
	parameter could have caused the server to hang.  If the server was also being 
	autostarted, the connection attempt could have hung.  If the server was already 
	running, the connection attempt would not hang, but the server may have hung 
	when shutting down. These problems have now been fixed.

    ================(Build #5226  - Engineering Case #381438)================

	It was possible for column statistics to become incorrect, which could have 
	potentially resulted in poor access plans. The situaltion was rare, and was 
	likely to have no other visible symptoms. This problem has been fixed.

    ================(Build #5226  - Engineering Case #381264)================

	When running on NetWare in a low-memory situation, if the server was unloaded 
	using the NetWare console, and there were active connections to the server, 
	it was possible that the server would abend. This has been fixed.

    ================(Build #5225  - Engineering Case #379077)================

	When the LOAD TABLE statement is used with the CHECK CONSTRAINTS OFF clause, 
	it does not validate any check constraints on the table. However, the check 
	constraints were built and annotated as part of the LOAD TABLE and failure 
	to do so resulted in the statement being rejected. The server will now ignore 
	the check constraints completely, by not attempting to build them at all.
	
	As an example the following returns a "table not found error" when the table 
	CT1 referenced in the check constraint is not visible to the user executing 
	the LOAD TABLE statement:
	
	grant dba,resource to dbowner
	CREATE TABLE dbowner.CT1 ( c1 integer NOT NULL )
	CREATE TABLE dbowner.T2 ( c1 integer NOT NULL, check(not c1 = any(select 
	c1 from CT1) ) )
	LOAD TABLE dbowner.T2 ... CHECK CONSTRAINTS OFF ...

    ================(Build #5223  - Engineering Case #381001)================

	An ASA remote database which had been synchronized, and then forcefully shutdown, 
	may not have recovered properly. Further synchronization attempts may fail 
	with the error "Missing transaction log(s) ... ". This problem has now been 
	fixed.

    ================(Build #5222  - Engineering Case #381217)================

	If a BACKUP DATABASE statement specified a long directory name for the target 
	directory and also included TRANSACTION LOG RENAME MATCH, the server could 
	have subsequently crashed. This has been fixed. A workaround is to use a 
	shorter directory name in the BACKUP statement.

    ================(Build #5220  - Engineering Case #381112)================

	The Datadd() and Datediff() functions would sometimes have produced incorrect 
	results when the time unit was Hours, Days, Weeks, Months or Years. 
	
	For example,
		select dateadd(month, 119987, '0001/1/1'), dateadd(week,521722,'0001-01-01'), 
	datediff(month,'0001-01-01','9999-12-31')
	
	produced the result:
		****-04-01 00:00:00.000		1833-11-10 19:44:00.000		-11085
	
	This has been fixed. Now, the result will be:
		9999-12-01 00:00:00.000		9999-12-27 00:00:00.000		119987

    ================(Build #5220  - Engineering Case #380970)================

	A CREATE PROCEDURE statement that did not qualify the procedure name with 
	a userid, would have failed with the error "Item 'procedurename' already 
	exists", even if the user did not own a procedure with the same name, but 
	there existed a procedure with the same name in the user's namespace, (ie 
	owned by a group the user was a member). This has been corrected.

    ================(Build #5220  - Engineering Case #380491)================

	When adding days to a date using the Dateadd() function, it may have overflowed 
	without an error, returning an incorrect date value.
	For example:
	select dateadd(day,  2250318 , '2005-02-16') would have returned 0000-01-00'
	
	This has been fixed, an error message will now be returned.

    ================(Build #5220  - Engineering Case #379951)================

	On some new versions of the Windows CE operating system, it was possible 
	to get a 'Fatal Error: No such file or directory' message from the server, 
	when bringing the device out of STANDBY mode. This has been fixed.

    ================(Build #5219  - Engineering Case #380351)================

	The server will no longer display command-line options in the console window 
	when any part of the command line is derived from an obfuscated file. It 
	will now display a command-line syntax error message with asterisks, instead 
	of the text that caused the syntax error when obfuscation is used, (ie Error 
	in command near "***" )

    ================(Build #5217  - Engineering Case #380378)================

	Malformed GRANT statements could have resulted in incorrect behaviour. This 
	has now been fixed.

    ================(Build #5217  - Engineering Case #379892)================

	If a variable was assigned a long string value (&gt254 character) from a table, 
	and the table was subsequently dropped or truncated, the server would likely 
	have crashed on the next use of the variable.  
	
	For example:
	
	begin
	    declare local temporary table t(c varchar(32767));
	    declare rv varchar(32767);
	    insert into t values(repeat('*',5000));
	    select c into rv from t;
	    truncate table t;
	    select lcase(rv) from dummy;
	end;
	
	A work around is to concatenate a zero-length string to column value, i.e. 
	use "select c || '' into rv from t" in the example above.
	

    ================(Build #5216  - Engineering Case #380206)================

	The server could have left connections hanging indefinitely, when receiving 
	multi-piece strings on a heavily loaded system. There was a chance that this 
	problem could also have occurred under other conditions, such as when the 
	network connection between client and server introduced long delays. This 
	was more likely to occur when the number of active requests was larger than 
	the number of tasks that were servicing requests (ie -gn). This has been 
	fixed.

    ================(Build #5216  - Engineering Case #380084)================

	The Dateadd() function could have produced incorrect results when the time 
	unit was milliseconds, minutes, hours, days, or weeks. 
	
	For example:
	
		select dateadd(hour,365*24*7923,'0001-01-01 21:45:37.027'),dateadd(hour,69399300,'0001-01-01 
	21:45:37.027')
	
	would have resulted in:
	
		'****-09-18 00:00:37.027'		'9998-07-01 00:00:37.027'
	
	This has been fixed. Now, the results are:
	
		'7918-09-29 00:00:37.027'		'7918-01-15 00:00:37.027'
	
	Similarily, the Datediff() function produced incorrect results when the 
	time unit was milliseconds, minutes, hours, days, or weeks. 
	
	For example,
	
		select datediff(minute,'2005-02-03 21:45:37.027','6088-02-26 23:52:37.027')
	
	resulted in a range error. This has been fixed.  Now, the result is
	
		2147483647
	
	

    ================(Build #5216  - Engineering Case #379896)================

	Dropping a column from a table could have caused any UPDATE OF {column} triggers 
	on that table to fire incorrectly. This has been fixed.

    ================(Build #5215  - Engineering Case #379916)================

	Attempting to insert into a local table, selected rows from a proxy table 
	when the remote server was down or not available, would likely have caused 
	the server to crash. Note that the crash will only occur if this INSERT-SELECT 
	performs the first connection attempt to the remote server. This problem 
	is now fixed and a proper error message will now get displayed.

    ================(Build #5213  - Engineering Case #379688)================

	If an application was using Java in the database, or was using Remote Data 
	Access with a JDBC class, then there was a possibility that the server may 
	have lost a SQL error. This was most likely to occur if the SQL error was 
	set, but the SQL error did not get reported to the client prior to the VM 
	Garbage Collector running. Due to the asynchronous nature of the VM Garbage 
	Collector, this problem is highly unreproducible. The problem has been fixed.

    ================(Build #5213  - Engineering Case #379414)================

	The Dateadd() function would have produced incorrect results when the value 
	to be added was close to the maximum or minimum 32-bit signed integer values 
	and the time unit was milliseconds. For example:
	
		select dateadd(ms,2147483647,'2005-02-03 21:45:37.027')
	
	would have resulted in:
	
		2005-01-10 01:15:**.***
	
	This has been fixed, now, the result is:
	
		2005-02-28 18:17:00.674
	
	The Datediff() function also produced incorrect results when the difference 
	was close to the maximum or minimum 32-bit signed integer values and the 
	time unit was milliseconds. For example:
	
		select datediff(ms,'2005-02-28 18:17:00.675','2005-02-03 21:45:37.027')
	
	would have resulted in a range error. This has also been fixed, the result 
	is now:
	
		-2147483648

    ================(Build #5213  - Engineering Case #379371)================

	If a CREATE TABLE statement was executed, and the table had a multi-column 
	primary key, the statistics of the first primary key column would not have 
	been used until the database had been restarted. This has been fixed

    ================(Build #5213  - Engineering Case #379190)================

	The Dateadd() function would have produced incorrect results when the value 
	to be added was close to the maximum or minimum 32-bit signed integer values 
	and the time unit was seconds. For example:
	
		select dateadd(ss,2147483647,'2005-02-03 11:45:37.027')
	
	would have resulted in:
	
		1937-01-16 08:32:**.***
	
	This has been fixed, now, the result is:
	
		2073-02-21 14:59:44.027
	
	The Datediff() function also produced incorrect results when the difference 
	was close to the maximum or minimum 32-bit signed integer values and the 
	time unit was second. For example:
	
		select datediff(ss,'2073-02-21 14:59:45.027','2005-02-03 11:45:37.027')
	
	would have resulted in a range error. This has also been fixed, the result 
	is now:
	
		-2147483648

    ================(Build #5213  - Engineering Case #378835)================

	The INSERT ... ON EXISTING UPDATE statement updates an existing row with 
	the new column values. If a column list had been specified, then in addition 
	to modifying the specified columns, the statement also modified columns with 
	their default values. Now, the server will no longer update default columns 
	unless explicitly asked to. 
	
	The following describes the new server behaviour:
	
	1. When the row does not exist, the new row is inserted as per the
	 usual rules of the INSERT statement.
	2. If the row exists, and ON EXISTING SKIP is specified, no changes
	 are made to the row.
	3. If the row exists, and ON EXISTING UPDATE is specified, the row is
	 updated as par the following rules:
	 (a) All columns that have been explicitly specified in the
	 INSERT statement are updated with the specified values.
	 (b) Columns with defaults that are meant to be changed on an
	 UPDATE are modified accordingly. These special defaults include
	 "DEFAULT TIMESTAMP", "DEFAULT UTC TIMESTAMP", and
	 "DEFAULT LAST USER".
	 (c) Columns with other defaults are not modified unless some
	 of these are explicitly mentioned with a non default
	 value in the INSERT statement, in which case these columns
	 are modified as par rule 3(a) above.
	 (d) Computed columns are re-evaluated and modified using the new row.
	 (e) Any other columns are left unchanged.

    ================(Build #5213  - Engineering Case #378742)================

	If an item in the GROUP BY clause was an alias reference, that appeared more 
	than once, then the statement would have failed with the eror "Function or 
	column reference to '???' must also appear in a GROUP BY".  This has been 
	fixed.
	
	The workaround is to remove the repeated item.

    ================(Build #5210  - Engineering Case #378243)================

	Repeatedly calling a stored procedure that performed an INSERT, UPDATE or 
	DELETE into a proxy table, would likely have caused a server crash. This 
	problem has been fixed.

    ================(Build #5210  - Engineering Case #378242)================

	If a batch containing a call to an external procedure was executed, and the 
	external procedure was subsequently canceled, the batch would have continued 
	execution, instead of being canceled as well. This problem has been fixed.
	

    ================(Build #5210  - Engineering Case #378026)================

	Executing a query involving a column for which the server estimate for NULL 
	selectivity had become invalid (ie greater than 100%), could have caused 
	the server to crash. The server will now deal with this situation without 
	crashing. The problem can be rectified by recreating the affected column 
	statistics using the CREATE STATISTICS statement.

    ================(Build #5209  - Engineering Case #377433)================

	If a jConnect or Open Client application made several requests to the server 
	using many host variables, but didn't open any cursors, and then attempted 
	to use a jConnect or Open Client cursor with host variables, then the server 
	would likely have crashed. This problem has been fixed.

    ================(Build #5207  - Engineering Case #377566)================

	Under rare circumstances, when executing an UPDATE statement, the server 
	could have created empty histograms, and/or corrupted the selectivity of 
	IS NULL predicates. This problem has now been resolved.

    ================(Build #5206  - Engineering Case #370899)================

	Several race conditions in the server while starting and stopping databases 
	have now been fixed:
	
	- The server could have autostopped a database when it should not have, 
	or not autostopped a database when it should have.  
	
	- In rare timing dependent cases, the server could have deadlocked, asserted 
	or possibly crashed, when a database was starting up or shutting down.  
	
	Also in rare timing dependent cases, the server could have asserted or possibly 
	crashed if HTTP or HTTPS requests were made to a database that was starting 
	up or shutting down.

    ================(Build #5205  - Engineering Case #376977)================

	If an application's operating system used a multibyte character set, which 
	was different from the character set of the database being unload by the 
	Unload utility dbunload, then dbunload could have generated an invalid reload.sql 
	script, and dbunload -an could have failed with a syntax error. Note that 
	dbunload -an turns off character set translation so the character set used 
	by dbunload in that case is the same as the database character set. For example, 
	running dbunload -an on a Chinese (cp936) machine to unload and recreate 
	a UTF8 database could have failed with a syntax error, or could have crashed. 
	This has been fixed.

    ================(Build #5204  - Engineering Case #376742)================

	If the sybase_sql_ASAUtils_retrieveClassDescription() function was called 
	with a very long class name, a server crash could have occurred. This has 
	been fixed.

    ================(Build #5204  - Engineering Case #376699)================

	On Windows 95, 98 or ME, the build number of the operating system was displayed 
	incorrectly. 
	
	For example:
	 
	"Running on Win98 build 67766222"
	 
	The correct OS build number is now displayed.
	 

    ================(Build #5203  - Engineering Case #376608)================

	If an Open Client application opened a cursor which cuased the warning: "cursor 
	options changed", the application would have failed to open the cursor. This 
	problem has now been fixed. There are situations where Open Client applications 
	are not expecting warnings, so certain warnings that are known to not be 
	handled are suppressed, while other warnings are sent as the client actually 
	expects them. The "cursor options changed" warning has been added to this 
	list of warnings not to be returned to an Open Client applications.
	

    ================(Build #5203  - Engineering Case #376606)================

	Creating a COMMENT on a local temporary table would have caused the server 
	to fail with assertion 201501 - "Page for requested record not a table page 
	or record not present on page". 
	
	Example:
	declare local temporary table temp1(c1 int);
	comment on table temp1 is 'my comment';
	
	Now an error is returned when attempting to add a comment to a local temporary 
	table.
	
	

    ================(Build #5203  - Engineering Case #368540)================

	When used in Java Stored Procedures, cursors and prepared statements were 
	left open until the connection disconnected. If called repeatedly, they could 
	accumulate until a "resource governor exceeded error" occured. This has been 
	fixed.

    ================(Build #5201  - Engineering Case #376019)================

	Executing queries containing the GROUP BY clause could have caused the server 
	to crash. The changes for Engineering Case 332010, and a related change for 
	case 363861, introduced the problem, which has now been fixed.

    ================(Build #5200  - Engineering Case #375757)================

	If a BACKUP or RESTORE statement was executed from the Open Client Isql utility, 
	while the backup.syb file was marked as read-only, the server could have 
	crashed. This has been fixed.

    ================(Build #5198  - Engineering Case #375236)================

	Under rare situations, calls to functions that took string parameters, could 
	have crashed the server. This was only a problem on Unix systems, and has 
	now been fixed.
	

    ================(Build #5197  - Engineering Case #375084)================

	If a request-level log contained host variable information for a TDS connection, 
	the system procedure sa_get_request_times would not have recorded the host 
	variable information in the satmp_request_hostvar table. This has been fixed.

    ================(Build #5197  - Engineering Case #374988)================

	An INSERT statement, using the ON EXISTING clause to insert the result set 
	of a query involving a remote table, into a local table, would have failed 
	with a syntax error. The server will now execute these statements correctly.
	
	For example, instead of generating a syntax error, the following will cause 
	table 'bar' to contain one row:
	
	CREATE SERVER asademo CLASS 'asaodbc' USING 'driver=Adaptive Server Anywhere 
	9.0;dbn=asademo';
	CREATE TABLE foo(c1 int) AT 'asademo...';
	create table bar( c1 int primary key );
	insert into foo values(1);
	insert into foo values(1);
	insert into foo values(1);
	commit;
	insert into bar on existing skip select * from foo;
	select * from bar

    ================(Build #5197  - Engineering Case #374976)================

	The debugger would have shown all connections on the server, instead of only 
	showing those connections to the database that the debugger was connected 
	to.  This has been fixed.  

    ================(Build #5194  - Engineering Case #374452)================

	If a proxy table to a DB2 table with a CLOB column, was used in a query, 
	then selecting that CLOB column would have failed with an unsupported datatype 
	error. This problem has been fixed.
	

    ================(Build #5191  - Engineering Case #373613)================

	An obsolete Java class could have caused the error "-110 - 'Item ... already 
	exists'",
	when attempting to install a new version of a Java class previously removed. 
	This has been fixed.

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

    ================(Build #5190  - Engineering Case #372882)================

	If a view was created with an owner like: "create view dba.V1 as select c1 
	from T1" the preserved source of this view (column SOURCE in SYSTABLE) would 
	have contained an space character following the owner; e.g "create view dba 
	.V1 as select c1 from T1".
	
	As well, if a view was created with a "select * ...", the view definition 
	(column VIEW_DEF in SYSTABLE) was unparsed without the space between the 
	"select" and "*"; e.g. "select* ...".
	
	Neither of these errors caused problems in ASA, but did cause problems for 
	Powerdesigner. Both issues have been fixed. 

    ================(Build #5189  - Engineering Case #373028)================

	Stopping a server while a database was in the process of either starting 
	or stopping, could have caused incorrect behaviour, such as the database 
	requiring recovery the next time it is started, or the server asserting, 
	crashing or hanging. Now, server shutdown waits for databases which are not 
	active, to finish starting or stopping before shutting down, and ensures 
	that a database is not stopped twice.

    ================(Build #5188  - Engineering Case #373039)================

	An attempt to create two user-defined types, whose names were the same except 
	for case, in a case sensitive database was permitted. This now results in 
	an error, since these names should always be case insensitive. 
	
	Also, dropping a user-defined type required the name to have matching case, 
	in a case sensitive database. This is no longer required.
	

    ================(Build #5186  - Engineering Case #372605)================

	If an application, connected to a server via jConnect, cancelled a request 
	or closed a JDBC statement, the cancel or close could have failed and/or 
	dropped the connection entirely. This problem has been fixed.

    ================(Build #5185  - Engineering Case #372481)================

	The estimate of the rate at which pages are being dirtied has been made less 
	pessemistic (a smoothed version of the estimates used in 7.x).  Also, on 
	32 bit Windows systems, the server now measures the random write times rather 
	than using the cost model estimates, as this caused the estimates to be off 
	by a factor of 50 in some cases.
	
	This is a further performance improvement to the issue originally addressed 
	by Engineering Case 355123.

    ================(Build #5185  - Engineering Case #372122)================

	Engineering Case 304975 added support for handling UUID/GUID columns in proxy 
	tables to remote servers. Unfortunately, that change had the side effect 
	of disallowing creation of existing proxy tables with smalldatetime columns. 
	The problem with the smalldatetime column has now been fixed.
	

    ================(Build #5184  - Engineering Case #355123)================

	The server could have performed poorly relative to 7.x servers when doing 
	a long sequence of database inserts, updates or deletes. The server was spending 
	longer than necessary cleaning up the cache in preparation for a checkpoint. 
	This time has now been reduced. Also, current servers now estimate the recovery 
	time better. Thus the Recovery_time database option may need to be set to 
	a larger value in order to have the server more closely match the value the 
	7.x server would have used.

    ================(Build #5181  - Engineering Case #370421)================

	If the ROUND() function rounded a numeric value, the resulting value may 
	not have fit into the original NUMERIC data types percision. For example: 
	The constant 9.995 is of type NUMERIC(4,3). The result of ROUND(9.995,1) 
	is 10.000 which does not fit into numeric(4,3). As a result the numeric value 
	generated by the ROUND() function could have been invalid and a conversion 
	of this numeric value to a string could have returned '?'. 
	This problem has been fixed. If the numeric value passed to ROUND() is a 
	constant, the resulting data types percision is increased by one, (numeric(5,3) 
	in the above example). If it is not a constant and the resulting value does 
	not fit, then a SQLE_OVERFLOW_ERROR is generated if the option Convertion_error 
	is set, otherwise NULL is returned. 

    ================(Build #5180  - Engineering Case #343581)================

	When a row was inserted into a table with a COMPUTE or CHECK clause that 
	contained a correlated subselect, where the outer references was to a column 
	of the base table, the server may have crashed. This has been fixed.
	
	
	In the example below, the outer reference T.a is used in a subselect of 
	the COMPUTE clause for the column T.b:
	
	create table T(
	    a int,
	    b char(10) not null COMPUTE (left( '0001',                      			(select 
	max(row_num) from rowgenerator  where  row_num = T.a  )) ))
	
	
	insert into T values (1, '1') 

    ================(Build #5179  - Engineering Case #371032)================

	If a query referenced both proxy and local tables, or proxy tables from different 
	servers, then it will have to be executed in 'no passthru' or 'partial passthru' 
	mode. If such a query also contained column references of the form 'user.table.column', 
	then the query would have failed with error -845 "Owner '&ltowner name&gt' used 
	in qualified column reference does not match correlation name '&lttable name&gt'". 
	This problem has now been fixed.

    ================(Build #5179  - Engineering Case #370456)================

	Executing a VALIDATE TABLE statement, and using the WITH EXPRESS clause, 
	(or dbvalid -fx), would have failed with the error "Not enough memory to 
	start", if the currently available cache space was not large enough. If cache 
	resizing is possible, the server will now try to increase the cache size 
	to the amount required.

    ================(Build #5179  - Engineering Case #370071)================

	When the BACKUP DATABASE TO statement failed and returned an error, (for 
	example if the location for the achive file was not writable), then subsequent 
	BACKUP DATABASE TO statements that failed would have caused the server to 
	fail with assertion 104400 (a stack overflow) on Solaris 8 or 9 systems.  
	This has been fixed.

    ================(Build #5176  - Engineering Case #370312)================

	A query in a procedure or batch, with an expression that involved remote 
	tables and a unary minus or simple cast operator, would have failed with 
	the error:
	
		ASA Error -823: OMNI cannot handle expressions involving remote tables 
	inside stored procedures.
	
	This problem has now been fixed so that these operators do now work in expressions 
	involving remote tables.

    ================(Build #5175  - Engineering Case #370045)================

	Insert performance on systems with three or more processors would have been 
	much poorer than on single processor systems. The drop in performance would 
	have been more noticable as the number of processors increased (and was likely 
	even more noticeable on Unix systems). This problem has now been corrected.

    ================(Build #5171  - Engineering Case #369410)================

	If a stored procedure was dropped and then another stored procedure with 
	the same name was immediately created, users who had permission to access 
	the first procedure, and had already called it, will still have been able 
	to access the second procedure, even if they have not explicitly been given 
	permission, until the next time the database was stopped. This has been fixed.
	

    ================(Build #5170  - Engineering Case #369234)================

	The server may have occasionally appeared to temporarily hang with CPU usage 
	at 100%. This would have occurred when there were only a few pages of the 
	server's cache available for reuse. The server would have continually reused 
	these few pages rather than immediately grow the cache. This problem has 
	been corrected.

    ================(Build #5170  - Engineering Case #369122)================

	The server may have exhibited poor performance if many connections try to 
	concurrently truncate a global temporary table. This was due to each connection 
	attempting to acquire an exclusive lock on the global temporary table definition. 
	Since each connection
	already has a pointer to the table definition, acquiring an exclusive lock 
	is no longer done.

    ================(Build #5170  - Engineering Case #368236)================

	In rare circumstances, if a database which required recovery was autostarted, 
	the server could hang with the server window still minimized.  One situation 
	where this could have occurred was when the database had a "disconnect" event.  
	A workaround is to start the database manually first to allow the database 
	to recover, and then shutdown this engine.
	
	This issue has been fixed.

    ================(Build #5168  - Engineering Case #368251)================

	The server would have failed to return the result set under certain circumstances. 
	One such situation was when the option Row_counts was set to 'ON' and the 
	query access plan had an indexed sort node at the top. This problem has now 
	been fixed.

    ================(Build #5167  - Engineering Case #368551)================

	The server could have crashed when executing Java code. This has been fixed.

    ================(Build #5167  - Engineering Case #366682)================

	A query that satisfied the following conditions would have incorrectly failed 
	with the error "Invalid use of an aggregate function":
	- it used an ANY, ALL, IN, or NOT IN subquery
	- the subquery used a grouped derived table or view
	- the derived table or view aliased an aggregate function
	- the alias was used in another column of the derived table or view
	
	For example:
	
	select 1 
	where 1 not in ( select b from (select sum(1) as b, b + 1 as c) dt )
	
	This problem has now been fixed.

    ================(Build #5165  - 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 #5165  - Engineering Case #368053)================

	If a client application terminated while the last connection to the server 
	was in the process of being disconnected, the server may not have autostopped 
	when it should. In these cases, the server icon and window would still have 
	been active, and the database would have been stopped, but no connections 
	could have been made to the server. Pressing shutdown would have stopped 
	the server though. This problem has now been corrected.
	
	Note, this scenario could have occurred in a multithreaded application if 
	all of the following conditions were true:
	- the server was autostarted by a multithreaded application
	- the main thread of the application signaled a child thread to shut down
	- the child thread did a disconnect as part of shutting down
	- the main thread did not wait for the child thread to complete before ending
	
	This has been fixed so that the server will correctly autostop.

    ================(Build #5164  - Engineering Case #367935)================

	When run on Unix systems, the server could have crashed when a non-DBA user 
	was connected, if auditing was enabled. This has been fixed.

    ================(Build #5164  - Engineering Case #367688)================

	Support for textual options to the Transact-SQL statement SET TRANSACTION 
	ISOLATION LEVEL, have been added for compatibility with Sybase ASE and Microsoft 
	SQL Server. Applications can now issue the following variants:
	
	SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
	SET TRANSACTION ISOLATION LEVEL READ COMMITTED
	SET TRANSACTION ISOLATION LEVEL REPEATABLE READ 
	SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
	
	which correspond to setting the isolation level of the connection to 0, 
	1, 2, or 3 respectively.

    ================(Build #5164  - Engineering Case #366401)================

	Rebuilding databases on Unix systems, using the Unload utility dbunload with 
	the -ar or -an command line options, would have failed during the rebuild 
	operation, if the source database had table or row constraints that specified 
	stored procedures. This has been fixed.

    ================(Build #5163  - Engineering Case #367716)================

	The userid 'dbo' was unable to use EXECUTE IMMEDIATE to execute a string 
	containing a multi-statement batch. This restriction has now been removed.

    ================(Build #5162  - Engineering Case #367689)================

	When running on NetWare systems, executing complex queries could have caused 
	the server to abend with CPU Hog Timeout. This has been fixed by adding more 
	yields, and checks for stack overflows, in the optimizer.

    ================(Build #5162  - Engineering Case #367663)================

	The server could have failed to drop a temporary table on a database opened 
	read-only.  This would only have occurred if the temporary table was declared 
	using Transact-SQL syntax, (ie "#table_name").  This has been fixed.

    ================(Build #5162  - Engineering Case #367661)================

	Executing an INSERT ... ON EXISTING UPDATE statement could have caused a 
	deadlock in the server, if another transaction was updating the table that 
	was being modified, and a checkpoint (or DDL statement) was pending. This 
	has been fixed.

    ================(Build #5162  - Engineering Case #363767)================

	Deleting or updating a large number of rows could have taken longer than 
	a comparable operation done with a server from version 8.0.1 or earlier. 
	This would only have been observed when using a database created with version 
	8.0.0 or later. This has been corrected.

    ================(Build #5161  - Engineering Case #367342)================

	If the first byte of the DELIMITED BY string for a LOAD TABLE statement was 
	greater than or equal to 0x80, the LOAD TABLE statement would not have recognized 
	any delimiters in the input file. This is now fixed.
	 

    ================(Build #5160  - Engineering Case #367252)================

	If the get_identity() function was used to allocate an identity value for 
	a table, but the table itself was not modified by the current connection, 
	or any other connection, then the value of the SYSCOLUMN.max_identity column 
	was not updated at the next checkpoint. If the database was shutdown and 
	restarted, get_identity() would then have re-used values previously generated. 
	This has been fixed.
	
	Note that the use of an empty table having an autoincrement column, together 
	with get_identity(), may still have resulted in values being re-used if the 
	database was not shut down cleanly and values were allocated since the last 
	checkpoint. Depending on how the values were used, it may have been possible 
	to correct the starting value in a DatabaseStart event by calling sa_reset_identity() 
	with the next value to use. For example:
		declare maxval unsigned bigint;
		set maxval = (select max(othercol) from othertab);
		call sa_reset_identity('IDGenTab', 'DBA', maxval);

    ================(Build #5160  - Engineering Case #365953)================

	If a user-defined function contained a COMMIT, calling the function in a 
	SELECT statement within a batch or procedure would have caused the cursor 
	for the batch or procedure to be closed if the cursor was not declared WITH 
	HOLD. This may have resulted in unexpected error messages like "Column '@var' 
	not found". Now these cursors will not be closed.

    ================(Build #5159  - Engineering Case #367116)================

	Executing a LOCK TABLE ... IN EXCLUSIVE MODE statement on a table did not 
	prevent other transactions from subsequently obtaining exclusive locks on 
	rows in the table when executing INSERT ... ON EXISTING UPDATE statements. 
	Although it would have prevented explicit UPDATE statements from subsequently 
	updating rows. This could have resulted in applications deadlocking unexpectedly. 
	This has been fixed.
	

    ================(Build #5159  - Engineering Case #366920)================

	Calling the DATEPART() function, with the date-part CalWeekOfYear, would 
	have returned the wrong week number if the year started with a Friday, Saturday 
	or Sunday and the day of the date-expression passed was a Sunday, but not 
	the very first one. For example: DATEPART( cwk, '2005/01/09' ) would have 
	incorrectly returned 2 instead 1. This has now been fixed.
	

    ================(Build #5159  - Engineering Case #366552)================

	When making a remote procedure call to a remote server whose class was either 
	ASAJDBC or ASEJDBC, if the remote procedure was a Transact-SQL procedure, 
	with either an INOUT or OUT argument that returned a result set, then it 
	was likely that the rows in the result set will not have been returned. The 
	INOUT or OUT parameters were incorrectly being fetched first, prior to fetching 
	the result set. In JDBC, fetching the value of an OUT or INOUT parameter 
	will close all result sets. Now the values of OUT or INOUT parameters are 
	fetched only when the procedure has completed execution.

    ================(Build #5159  - Engineering Case #365603)================

	Making an RPC call, or executing a FORWARD TO statement, may have failed 
	to return a result set, even though one was returned by the remote server. 
	Note that this problem only happened when the Remote Data Access class was 
	either ASAJDBC or ASEJDBC. This has been corrected.

    ================(Build #5158  - Engineering Case #366562)================

	If the subsume_row_locks option is on and a table T is locked exclusively, 
	the server should not obtain row locks for the individual rows in T when 
	executing an UPDATE. This was not the case if T was updated through a join 
	(or if T had triggers, computed columns, etc.), or if T was modified via 
	a keyset cursor. Now, no locks are aquired in this situation.

    ================(Build #5158  - Engineering Case #366233)================

	If a stored procedure contained a statement that performed a sequential scan 
	of a global temporary table, executing the statement could have caused the 
	server to crash. This problem would have occurred if the following conditions 
	held:
	- The statement plan was cached
	- The table was declared as "ON COMMIT DELETE ROWS"
	- The table had more than 100 pages when the plan was cached
	- COMMIT was called before the statement was executed
	
	This problem has been fixed. The crash could be avoided by setting the option 
	'Max_plans_cached' to 0.
	
	

    ================(Build #5158  - Engineering Case #365453)================

	Calling a wrapper procedure for a Java class which returned a result set 
	would have leaked memory and could have crashed the server. This has now 
	been fixed.

    ================(Build #5157  - Engineering Case #366532)================

	Computed columns with JAVA expressions may have be incorrectly parsed, causing 
	the  error: "ASA Error -94: Invalid type or field reference". This problem 
	occurred if the computed column belonged to a table B, and there existed 
	another table A, used in the same statement, having a column with the same 
	name as the JAVA class name. This has been fixed.
	
	For example:
	
	The following query returned the error "ASA Error -94: Invalid type or field 
	reference":
	
	  select * FROM A WHERE A.ID  NOT IN ( SELECT B.ID FROM B ); 
	 
	Table B has the computed column "EntityAddressId" referencing the JAVA class 
	"Address", and table A has a base table column named "Address". Note that 
	the computed column doesn't have to be referenced in the query. 
	
	CREATE TABLE A 
	( 
	 ID int,
	"Address" varchar (10)
	); 
	
	
	CREATE TABLE B 
	( 
	 ID int,
	"EntityAddressId" numeric(10,0) NULL COMPUTE (Address &gt&gt FindAddress(0, 
	'/', 0)), 
	); 
	

    ================(Build #5157  - Engineering Case #366364)================

	Database validation, using either the Validation utility dbvalid, or executinmg 
	the VALIDATE DATABASE statement, could have failed to detect some corrupted 
	LONG VARCHAR columns. Assertion 202000 is now generated when a corrupted 
	LONG VARCHAR is encountered.

    ================(Build #5157  - Engineering Case #366282)================

	The CREATE SCHEMA statement was not being logged correctly in the transaction 
	log if it contained at least one CREATE VIEW statement. The statement logged 
	was the last CREATE VIEW statement, instead of the entire CREATE SCHEMA statement. 
	As a consequence, the CREATE SCHEMA statement was not recoverable. Also, 
	recovery could have failed with a "Failed to redo an operation" assertion, 
	if the logged CREATE VIEW statement could not have been executed, e.g., because 
	it referred to a table created within the original CREATE SCHEMA statement. 
	This problem has been resolved.
	

    ================(Build #5157  - Engineering Case #366167)================

	Database recovery could have failed when mixing Transact-SQL and Watcom SQL 
	dialects for Create/Drop table statements. This has been fixed. The following 
	example could have caused database recovery to fail if the server crashed 
	before the next checkpoint. 
	
	create global temporary table #test (col1 int, col2 int);  
	drop table #test;  
	create global temporary table #test (col1 int, col2 int);  
	drop table #test;  
	
	A workaround is to only use #table_name for creation of local temporary 
	tables.
	
	

    ================(Build #5156  - Engineering Case #366150)================

	The server could have become deadlocked when executing the system procedure 
	sa_locks. For this to have occurred, two connections must have been issuing 
	sa_locks calls concurrently, or the user definition for the owning connection 
	was not in cache, which is not a likely occurence. This problem has been 
	fixed.

    ================(Build #5156  - 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 #5156  - Engineering Case #358350)================

	If a table was part of a publication, altering a trigger on that table could 
	have caused the server to fail with assertion 100905 on a subsequent INSERT, 
	UPDATE or DELETE. For this to have occurred, the table must have been referenced 
	in a stored procedure and the procedure must have been called at least once 
	before the ALTER and once after. This has been fixed.

    ================(Build #5154  - Engineering Case #365730)================

	If a server attempted to start what appeared to be a valid database file, 
	and the database failed to start for any reason, then unexpected behavior 
	could have occurred on future requests to the same server. The unexpected 
	behavior could have included server crashes, assertions, and possibly database 
	corruption. This has been fixed.

    ================(Build #5153  - Engineering Case #365480)================

	When running on NetWare systems, if the ASA server failed with a fatal error, 
	the NetWare server would have abended. This has been fixed.

    ================(Build #5153  - Engineering Case #365188)================

	If a view was defined with the "WITH CHECK OPTION" clause and had predicates 
	using subqueries, then opening an updatable cursor or executing an UPDATE 
	statement might have caused a server crash. This has been fixed.
	
	For example:
	
	create view products
	  as select p.* from
	    prod as p
	    where p.id = 
	    any(select soi.prod_id from sales_order_items soi KEY JOIN sales_order 
	so
		where so.order_date &gt current date )
		with check option
	
	
	The following INSERT statement would have crashed the server:
	
	insert into products (id) values ( 1001 ) 

    ================(Build #5151  - Engineering Case #365038)================

	If a statement that modified a remote table was executed within a savepoint, 
	no error was given, even though remote savepoints are not supported. Now, 
	if an UPDATE, DELETE or INSERT statement attempts to modify a remote table 
	while inside a savepoint, it will fail with the error "remote savepoints 
	are not supported". Note that remote procedure calls within a savepoint will 
	also fail with this error, as there is a chance the remote procedure will 
	modify tables on the remote database.

    ================(Build #5149  - Engineering Case #362895)================

	In some cases, the selectivity estimate for a predicate '&ltcolumn&gt IS NULL' 
	could have been set incorrectly to 0. This could have lead the query optimizer 
	to select poor execution plans, for example, selecting an index to satisfy 
	an IS NULL predicate instead of another, more selective predicate.
	
	For this problem to have occurred, a query must have contained a predicate 
	of the form:
		T.col = &ltexpr&gt
	The expression &ltexpr&gt must have been an expression whose value was not known 
	at query open time. For example, &ltexpr&gt could have been a column of another 
	table, or it could have been a function or expression that was not evaluated 
	at optimization time. The predicate must have been the first predicate evaluated 
	for the associated table scan, and the table T must have been scanned once 
	with the value of &ltexpr&gt being NULL. In these circumstances, the selectivity 
	of 'T.col IS NULL' would be incorrectly set to 0. This has been fixed.
	
	If an application opened a cursor over a query that contained an index scan 
	with a single column in the index being searched for equality, the selectivity 
	estimate could have been lowered incorrectly if the application scrolled 
	the cursor using absolute fetches and did not visit all of the rows of the 
	result set but ended the scan after the last row of the result set. This 
	problem would have resulted in selectivity values being stored that were 
	lower than expected, and could have lead the query optimizer to select poor 
	execution plans by picking an index on this column instead of a better index. 
	This problem has also been fixed.
	

    ================(Build #5148  - Engineering Case #365508)================

	When used with multiple Java Threads, and Synchronized Java Methods, Java 
	Stored Procedures could have produced unexpected results. This has niw been 
	fixed.
	

    ================(Build #5147  - Engineering Case #364246)================

	A reference to a column not in the GROUP BY list, when made from an IN condition, 
	was not being reportrd as an error.
	
	For example:
	
		select if emp_id in (1) then 0 else 1 endif
		from employee 
		group by state
	
	This problem is now fixed.

    ================(Build #5145  - Engineering Case #363861)================

	A query such as the following:
	
		select 'a', 'a' from employee group by 'a', 'a'
	
	where a constant string appears in both the select list and the GROUP BY 
	clause, could have caused the server to crash. This has been fixed.

    ================(Build #5143  - Engineering Case #363251)================

	When using the FORWARD TO statement in interactive mode (i.e. issuing a "FORWARD 
	TO &ltserver&gt" statement first and then issuing individual statements, all 
	of which are to be executed on the remote server), there was a pobbibility 
	that one, or all, of the statements would have been executed locally instead 
	of remotely. There was also a pobbibility that the statements will not have 
	been executed at all. This problem was most likely to have occurred when 
	connected via jConnect, or if the remote server name had a space in it, or 
	any character that would required quoting. This problem has now been fixed.

    ================(Build #5143  - Engineering Case #362311)================

	When estimating the selectivity of a predicate of the form "column = (correlated 
	subselects)", the server was treating the predicate as "column = (single 
	value)". This assumption could have lead to overly low selectivity estimates 
	resulting in poor plans. In reality, the correlated subselect can cause a 
	large number of values to be compared with the column, resulting in many 
	rows.
	
	Now, the server will use a "guess" estimate of 50% for the selectivity of 
	these predicates.

    ================(Build #5142  - Engineering Case #363397)================

	The server could possibly have crashed on shutdown, if the Java VM had been 
	used. This would occurred if the VM needed to load additional classes during 
	shutdown. Now, failure to load a new class during shutdown is handled by 
	the Java's exception mechanism and the VM will still shutdown.
	

    ================(Build #5140  - Engineering Case #361512)================

	If a stored procedure contained a CREATE VIEW statement, the second execution 
	of the CREATE VIEW statement may have failed with a "column not found". This 
	has been fixed.
	
	A workaround is to use EXECUTE IMMEDIATE to create the view.

    ================(Build #5140  - Engineering Case #359745)================

	If a stored procedure declared a temporary table and returnd a result set, 
	opening a cursor on the procedure would have made the temporary table visible 
	outside the procedure. This has been fixed.

    ================(Build #5139  - Engineering Case #362585)================

	Queries that used a multi-column index could have returned incorrect results. 
	For this to have occurred, all of the following must have been true:
	- The index must have been comparison-based.
	- One of the first few columns being indexed must have been a short character 
	(or binary) column [the column must have been fully hashed]. This column 
	must not have been the last column being indexed.
	- The query must have contained a comparison involving this column [say 
	with domain char(n)] and a string s with length &gt n whose n-byte prefix appeared 
	as a value in the column.
	
	This problemhas now been corrected.

    ================(Build #5139  - 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 #5139  - Engineering Case #360885)================

	Using variable assignments in a positioned update, (e.g  update T1 set id 
	= @V1, @V1 = @V1 + 1 where current of curs), would have caused a server crash. 
	Now, variable assignments in a positioned update are supported.
	

    ================(Build #5138  - Engineering Case #362312)================

	The restructuring of column statistics in the server could have caused memory 
	corruption, which can result in various symptoms, including server crashs 
	and assertions. The chances of this problem happening was remote. It could 
	only have occurred if the memory allocator returned the same memory as that 
	used in a previous invocation of the restructuring of the same histogram. 
	This problem has now been resolved.

    ================(Build #5138  - Engineering Case #354157)================

	When starting a database "read-only" using the "-r" command line option, 
	the server could have failed with assertion 201851, if the database had been 
	created by ASA 8.0.0 or newer. This has now been fixed.

    ================(Build #5136  - Engineering Case #361999)================

	Index statistics for SYSATTRIBUTE could have become out of date, resulting 
	in errors being found when running the Database Validation utility dbvalid. 
	This problem has now been resolved.

    ================(Build #5136  - Engineering Case #360237)================

	Memory-intensive operations, such as a sort, hash join, hash group-by, or 
	hash distinct, could have caused the server to fail with a fatal memory exhausted 
	error, if they were executed in an environment where the operation could 
	not be completed completely in the available memory. This issue affected 
	all platforms, and has now been fixed.

    ================(Build #5135  - 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 #5133  - Engineering Case #361184)================

	A query with a large WHERE clause containing the conjunction and disjunction 
	of many literals could have caused the server to hang with 100% cpu usage 
	and eventually run out of memory and fail with a "Dynamic Memory Exhausted" 
	message.  This has been fixed.
	

    ================(Build #5132  - Engineering Case #360311)================

	A query with a large number of OR'ed predicates (about 20,000 on Windows 
	systems) may have caused the server to crash.
	
	For example:
	
		select 	T2_N.b
		from	T1, T2, T2_N
		where	T1.a = T2.b  and  T2.b = T2_N.b   and
			( T1.a = 1  or  T1.a = 2  or  T1.a = 3  or .... or T1.a = 20000)
	
	The number of OR conditions to cause the crash depended on the available 
	stack size. This problem has been fixed. Now these queries return an error 
	"Statement size or complexity exceeds server limits".

    ================(Build #5132  - Engineering Case #359741)================

	If a synchronization was performed prior to changing the database options 
	Truncate_timestamp_values to ON and Default_timestamp_increment to a value 
	which would disallow timestamp values with extra digits of precision, the 
	next synchronization would have caused a server crash. The server will now 
	display an assertion indicating that an attempt to store an invalid timestamp 
	value in a temporary table was made. The options must be changed before the 
	first synchronization is performed.

    ================(Build #5130  - Engineering Case #356739)================

	If a trigger on table T referred to a column of T that had been dropped or 
	renamed, then the server could have crashed when processing a query referring 
	to T after the server was restarted. For the crash to have occurred, the 
	referencing query must have been sufficiently complicated to allow predicates 
	to be inferred. The cause of the crash has been fixed, and other changes 
	have already made it impossible to rename or drop columns referenced by triggers.

    ================(Build #5129  - Engineering Case #366267)================

	When the database option Ansi_close_cursors_on_rollback was set to 'ON', 
	the Validation utility dbvalid would have failed to validate all the tables 
	in the database. The error 'cursor not open' would have been displayed. This 
	has been fixed.

    ================(Build #5129  - Engineering Case #360455)================

	During unloading or rebuilding a database a non-clustered index may have 
	been recreated as a clustered index. This would have happened if there was 
	at least one table with a clustered index and subsequent unloaded table definitions 
	had a non-clustered index with the same index id as the clustered index. 
	This has now been fixed.

    ================(Build #5128  - Engineering Case #360464)================

	If a grouped query had a base table's column T.A in its select list, and 
	the table T qualified to be eliminated by the join elimination algorithm, 
	then T.A might have been incorrectly renamed. This has been fixed.
	
	For example: 
	The query below returned a result set which had the first column renamed 
	"A2":
	
	create table T1 ( A1 int primary key);
	create table T2 ( A2  int, 
			foreign key (A2 ) references T1(A1) );
	
	select  A1
	from T1 key join T2
	group by A1 
	
	Note that the  query was rewritten by the join elimination algorithm into:
	
	select  A2 
	from T2
	group by A2
	
	Now, the query is rewritten into:
	 
	select  A2 as A1
	from T2
	group by A2
	
	
	A work around for this problem is to alias all the columns referenced in 
	the SELECT list with their own names. 
	
	For example, the query Q' below is not affected by this bug:
	Q':
	select  A1 as A1
	from T1 key join T2
	group by A1 
	

    ================(Build #5128  - Engineering Case #357965)================

	Under certain conditions, SELECT DISTINCT queries with complex ORDER BY expressions 
	may have received an erroneous syntax error.
	
	For example, the following query would have failed with SQLCODE -149:
	
	Select distinct e.emp_lname + space(50) + '/' + e.emp_fname
	from employee e, employee e2
	where e.emp_id = e2.emp_id and e2.dept_id = 100 and (e.city = 'Needham' 
	or e2.city = 'Burlington' )
	order by  e.emp_lname + space(50) + '/' + e.emp_fname
	
	This problem has been corrected.

    ================(Build #5124  - Engineering Case #359212)================

	The debug server log, (output generated bu -z command line option), could 
	have contained extraneous "Communication function &ltfunction name&gt code &ltnumber&gt" 
	diagnostic messages. For example after stopping a database using dbstop. 
	Similarly there could have been extraneous instances of this diagnostic message 
	in the client LogFile.
	
	These extraneous diagnostic messages have been removed. Please note that 
	this diagnostic message can still validly occur under some circumstances 
	and may be useful to help Technical Support diagnose other problems.
	
	This change also prevents some spurious "connection ... terminated abnormally" 
	messages.

    ================(Build #5123  - Engineering Case #359242)================

	The server could have crashed when attempting to get a db_property for a 
	database which is in the process of being started. When a database is being 
	started, a "stub" database object is added to the server's list of databases, 
	which has NULL pointers for a number of fields, including the statistics 
	counter array.  Calling the db_property() function would have attempted to 
	get statistics for the stub database. Fixed by only getting properties for 
	active databases.

    ================(Build #5123  - Engineering Case #355292)================

	Updating the version of jConnect to a newer version than the one shipped 
	with ASA (ie newer than 5.5), would have likely have resulted in postioned 
	updates failing with an exception. Versions of jConnect newer than 5.5 support 
	the new status byte that was added to allow distinguishing between a NULL 
	string and an empty string. When performing positioned updates, jConnect 
	sends the KEY column values so that the row being updated can be uniquely 
	identified. This status byte was not supported for KEY columns, but the server 
	was still expecting it, resulting in a protocol error. This has been fixed. 

    ================(Build #5120  - 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 #5119  - Engineering Case #358497)================

	If a database with auditing enabled required recovery, the server may have 
	indicated during recovery that the log file was invalid. If an audit record 
	in the transaction log was only partially written, the audit record would 
	have appeared corrupt. This is now ignored if the partial audit record is 
	at the end of the log.

    ================(Build #5119  - 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 #5117  - Engineering Case #358040)================

	In rare low-memory situations, the server could have crashed or quietly ended. 
	This has been fixed. 

    ================(Build #5117  - Engineering Case #357689)================

	A row limit (ie 'FIRST' or 'TOP nnn') could have been ignored on DELETE and 
	UPDATE statements. This was most likely to occur on smaller tables and for 
	very simple statements. 
	
	Example:
	create table temp1 (nID int not null);
	insert into temp1 (nID, nid2) values (1);
	insert into temp1 (nID, nid2) values (1);
	commit;
	delete first from temp1;		//deletes both rows
	
	This problem has been corrected. A workaround is to attach a redundant ORDER 
	BY clause to the statement.
	
	delete first from temp1 order by 1+1;	//deletes just one row

    ================(Build #5117  - Engineering Case #357306)================

	The server could have chosen an inefficient execution plan for a query, even 
	after freshly creating statistics for all tables involved in the query. The 
	poor plan was usually caused by poor join selectivity estimation. Now, the 
	server will have more information available after a CREATE STSTISTICS is 
	executed, which should improve the quality of plans chosen.

    ================(Build #5117  - Engineering Case #356795)================

	On Windows 95, 98 or ME, if a network server had both TCP/IP and SPX connections, 
	the server could have hung with 100% CPU usage. This has been fixed.
	
	Note if using a network server, Windows NT, 2000, XP or 2003 are recommended 
	over Windows 95, 98 or ME, to ensure better performance and reliability.

    ================(Build #5117  - Engineering Case #356762)================

	A non-fatal assertion failure: 105200 "Unexpected error locking row during 
	fetch" could have been reported when executing an outer join with a temporary 
	table on the null-supplying side of an outer join. This would have appeared 
	to an application as error -300 "Run time SQL error" or -853 "Cursor not 
	in a valid state". This has now been fixed.

    ================(Build #5117  - Engineering Case #356595)================

	If a RAISERROR or PRINT statement containted a subselect in the format string 
	or in a PRINT expresstion, the server may have crashed or returned an error. 
	This has been fixed.

    ================(Build #5117  - Engineering Case #355965)================

	When run on SMP systems using processors from Intel's P6 family, (as well 
	as Pentium 4 and XEON), the server could have hung when receiving multi-piece 
	strings via shared memory connections. This problem also affected ODBC, OLEDB 
	and Embedded SQL clients as well. It has been fixed.
	
	

    ================(Build #5117  - Engineering Case #355831)================

	Executing an ALTER TABLE statement which attempted to modify a column and 
	then drop the column in the same statement would have caused the server to 
	crash. Attempting to modify and drop a column in the same ALTER TABLE statement 
	will now generate the error "ALTER clause conflict". These changes must be 
	made with separate ALTER TABLE statements.
	

    ================(Build #5117  - Engineering Case #355527)================

	If a server goes down dirty (eg. due to a power failure), there can be a 
	partial operation at the end of the log. If such a log was applied to a database 
	by using the -a (apply named transaction log file) server command line option, 
	restarting the server using that database and log file (without -a) could 
	have caused the server to fail to start with the message "not expecting any 
	operations in transaction log". The problem would only have occurred if the 
	incomplete operation was the first operation of a new transaction and there 
	were no other transactions active after all complete operations had been 
	applied. The problem has been fixed by removing the partial operation from 
	the log after the log is applied (or recovery is completed).

    ================(Build #5117  - Engineering Case #355459)================

	When sending or receiving multi-piece strings on a heavily loaded system, 
	the server could have deadlocked, causing a hang. This has been fixed. A 
	work around would be to increase the number of tasks available to service 
	requests (-gn). Alternatively, a dba user could use a pre-existing connection 
	with the DEDICATED_TASK option set, to manually break the deadlock by cancelling 
	one or more executing requests.

    ================(Build #5117  - Engineering Case #355299)================

	When the server ran databases created with ASA versions 4.x and earlier (or 
	databases upgraded from ASA versions 4.x and earlier), queries that made 
	use of index scans over fully hashed indexes could have returned incorrect 
	results. An optimization for index scans in older databases was incorrect.  
	This optimization has now been removed, so a drop in performance when using 
	older databases will likely be noticed. An unload/reload is recommended if 
	the resulting performance is not acceptable.

    ================(Build #5117  - Engineering Case #355098)================

	An ALTER TABLE statement that added, modified or deleted a table's CHECK 
	constraint, a column's CHECK constraint or renamed a column, had no effect 
	on INSERT, UPDATE or DELETE statements inside stored procedures and triggers, 
	if the procedure or trigger was executed at least once prior to the ALTER 
	TABLE statement. This problem has been fixed.

    ================(Build #5117  - Engineering Case #355012)================

	Calling any of the external mail routines (such as xp_sendmail or xp_startmail) 
	could have caused the server to crash. A problem with passing NULL parameters 
	has been fixed.

    ================(Build #5117  - Engineering Case #354381)================

	When running on Windows 2003, the server could have crashed on startup, if 
	the machine had no TCP/IP address, or was unplugged from the network. This 
	has been fixed.

    ================(Build #5117  - Engineering Case #354096)================

	The server would go into an infinite loop, with nearly 100 percent cpu usage, 
	when executing a query like the following:
	
	    select (select systable.first_page from systable where systable.table_id 
	= 1) as id0,
	      id0 as id1 
	    from syscolumn 
	    group by id1
	
	The problem occurred under the following conditions:
	- the query had a subselect in the select list or in the WHERE clause
	- the subquery had an alias name ("id0" in the above query) and the alias 
	name was aliased   by a second alias name ("id0 as id1" see above), so that 
	both alias names were syntaxtically identical
	- the second alias name was part of a GROUP BY element
	
	This problem has been fixed

    ================(Build #5117  - Engineering Case #353753)================

	Running the Validation utility dbvalid to validate a read-only database would 
	have caused the error:
	           A write failed with error code: (5), Access is denied.
	           Fatal error: Unknown device error
	This has been fixed.

    ================(Build #5117  - Engineering Case #353336)================

	If connections were being made concurrently which required a server to be 
	autostarted, in rare timing dependent cases, the server could have crashed. 
	This has now been fixed.

    ================(Build #5117  - Engineering Case #353334)================

	Calling the system extended procedures xp_scanf, xp_sprintf or xp_startsmtp 
	could, in very rare circumstances, have caused the server to crash. These 
	procedures have now been fixed.

    ================(Build #5117  - Engineering Case #353026)================

	Calling the system procedure "sa_get_request_times", could have caused a 
	server crash. This has now been fixed.
	

    ================(Build #5117  - Engineering Case #352793)================

	If the database option Truncate_date_values was set to OFF before populating 
	a row containing a DATE column with a value including both date and time, 
	and the Truncate_date_values option was subsequently set back to its default 
	of ON, updating the row in any way which caused the row to be moved to another 
	page, would have resulted in an assertion failure 105400. This has been fixed. 
	
	A workaround is to set the option to OFF, manually update any DATE values 
	to eliminate the time component, then set the option to ON. A statement such 
	as the following could be used:
		update t set datecol = date(datecol)
		where datepart(hour,datecol)&lt&gt0 
		or datepart(minute,datecol)&lt&gt0
	
	Normally this option should be left at its default setting.

    ================(Build #5117  - Engineering Case #352471)================

	When the server was run on multi-processor Windows plarforms, tasks for connections 
	where the database option Background_priority was set to 'On', would have 
	been scheduled by the OS such that only one was running at a time, even if 
	other processors were idle. This has been corrected.

    ================(Build #5117  - Engineering Case #351001)================

	On CE devoces, queries could have failed with the error "Dynamic memory exhausted", 
	if a Join Hash operator was used in an access plan and the server cache size 
	was too small. This has been fixed by disabling the Join Hash operator for 
	CE devices during optimization if the available cache has less than 2000 
	pages. Thus resulting in access plans that do not contain such joins.    

    ================(Build #5117  - Engineering Case #350058)================

	When run on Windows 95, 98, ME or NetWare, the server could have crashed 
	when receiving BLOBs over TCP/IP or SPX connections. The probability of this 
	crash was a very slight and timing dependent. This has now been fixed.
	

    ================(Build #5117  - Engineering Case #349954)================

	A new connection could have been refused, in very rare timing dependent cases, 
	when it should have been allowed.  In order for this to have occurred the 
	network server must have been at its maximum number of licensed clients (Note, 
	each unique client address from a remote machine counts as one license), 
	and the last connection from a client machine must have been disconnecting 
	at the same time a new connection was being made at the same client machine
	
	This has been fixed so that the server calculates licenses used accurately.

    ================(Build #5117  - Engineering Case #349901)================

	The server would have crashed during execution of a query that used an index, 
	if all of the  following conditions were true:
	- the index was a compressed B-tree index
	- the index contained a character or binary key column
	- the length of the search value for this key column was almost the page 
	size, or was longer
	- the search value for this key column was not a constant
	
	This has now been fixed.

    ================(Build #5117  - Engineering Case #349450)================

	After recovering a database which used no transaction log file, shutting 
	down the server before modifying the database could have caused assertion 
	failures 201810 "Checkpoint log: the database is not clean during truncate" 
	or 201117 "Attempt to close a file marked as dirty". If the server was killed 
	or the machine or server crashed before the database was modified, then subsequently 
	checkpointed, the database could have been corrupt. Only databases created 
	with 8.0.0 or later are affected. This problem has now been corrected.

    ================(Build #5117  - Engineering Case #348751)================

	If the server had multiple, memory intensive transactions running concurrently, 
	it may have erroneously failed with an 'out of memory' error'.  This would 
	only have occurred on multiprocessor systems. This has been fixed.

    ================(Build #5117  - Engineering Case #348610)================

	Committing a transaction that deleted rows containing blobs, whose aggregate 
	size was larger than the current cache size, could have taken a very long 
	time. The time to do these deletes has been reducedsignificantly. As well, 
	blob columns created by servers containing this change, can be deleted even 
	more efficiently.  

    ================(Build #5117  - Engineering Case #348512)================

	When connected to the utility database, (utility_db), executing a SET OPTION 
	statement would have caused the next statement to fail with a "Connection 
	error". This has been fixed. SET OPTION statements will now return an error, 
	as they are not supported when connected to the utility_db. Subsequent statements 
	will work as expected.

    ================(Build #5117  - Engineering Case #347493)================

	The server could have crashed on startup, if a large number of tasks were 
	specified, and they could not all be created due to lack of memory.  This 
	problem was more likely to occur on Windows platforms using AWE, with 8.0.2 
	build 4076, or later.  This has been fixed in the Windows server, (a fix 
	for NetWare and Unix servers to follow), now it will fail with an error indicative 
	of excessive memory usage.

    ================(Build #5117  - Engineering Case #346991)================

	Assigning the result of a string concatenation to a variable could have caused 
	the size limit of the variable to be exceeded. This would only have occurred 
	with the bar ( || ) operator. This is now fixed, the concatenated string 
	is truncated to the maximum size.

    ================(Build #5117  - 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 &lt&gt R1.row_num 
				and R2.row_num &lt= 2)
	
	This problem has been fixed.
	

    ================(Build #5117  - Engineering Case #346766)================

	The server could have faulted with an integer divide by zero error, when 
	executing a memory intensive query that causes the cache to grow dynamically 
	to the maximum allowed.  This is now fixed, but a work around would be to 
	disable dynamic cache sizing (i.e. specifying -ca 0 on the command line).
	

    ================(Build #5117  - Engineering Case #346715)================

	If a Watcom-SQL stored procedure or trigger containes a statement like:
		execute var;
	a syntax error should be reported, but was not. Instead, when the procedure 
	or trigger was executed, the message "Invalid prepared statement type" was 
	reported. A syntax error will now be given when the procedure or trigger 
	is created. If the intent of the original statement was to treat the contents 
	of the string variable "var" as a statement to be executed, EXECUTE IMMEDIATE 
	must be used instead.

    ================(Build #5117  - 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 #5117  - Engineering Case #346507)================

	In databases using 1253ELL (Greek) collation, identifiers containing Greek 
	letters required double-quotes because the Greek letters were not properly 
	identified as alphabetic. This has been corrected, so that Greek letters 
	can now be used without quotes.

    ================(Build #5117  - Engineering Case #346245)================

	Selecting blob data from a variable could have caused the server to stop 
	with an assertion failure. This has been resolved.

    ================(Build #5117  - Engineering Case #345734)================

	If a predicate qualified to be pushed into a view, then the process of inferring 
	new predicates in the view query block, might not have used this pushed predicate. 
	This may have resulted in less than optimal access plans, due to the fact 
	that useful sargable predicates were not inferred. This has been fixed. 
	
	The following conditions must have been met for a query to have exhibited 
	this problem:
	(1) the main query block was a grouped query on a view V1
	(2) the main query block contained a local view predicate on V1 (e.g., "V1.col1 
	= constant")
	(3) the view V1 contained other predicates that, with the help of the pushed 
	predicate, could have been used to infer sargable predicates on base tables 
	(e.g., "col1 = T.x")
	(4) the view V1 was grouped as well
	
	
	Example:
	select V1.col2, count(*)
	from   V1
	where V1.col1 = c
	group by V1.col2
	
	V1: select  V2.col3, count(*)
	       from V2, T
	       where V2.col1 =  T.x
	        group by V2.col3
	
	V2: select *
	form R1
	UNION ALL
	select * 
	from R2

    ================(Build #5004  - Engineering Case #386569)================

	The index corruption caused as a result of Engineering Case 383145 could 
	not have been detected by database validation. Validation of an index with 
	this type of corruption will now generate an assertion failure, (such as 
	100305, 102300, or 201601). Dropping and recreating the index will solve 
	the problem.
	

    ================(Build #5003  - Engineering Case #361188)================

	The collation 1250LATIN2 was missing case conversions for "Letter O with 
	double acute" and "Letter U with double acute". As a result, the functions 
	UPPER() and LOWER() would have failed to convert these letters to their corresponding 
	case, and comparisons would also have failed to match these characters with 
	other O and U characters when the case was different. This has now been fixed, 
	but existing databases will need to be rebuilt to get the new conversions.

    ================(Build #5003  - Engineering Case #356798)================

	Messages sent from the server to the client application would have been corrupted 
	if the database character set was different from the client's connection 
	character set. This problem would most likely have occurred on multi-byte 
	character set systems with utf8 databases. This has been fixed.

    ================(Build #5003  - Engineering Case #355245)================

	Attempting to unload a database created prior to SQL Anywhere version 5 would 
	have resulted in an error that user "dbo" did not exist. If the dbo user 
	was created, a different error would have been given, since the view dbo.sysusers 
	would not have existed. This has been fixed. A workaround is to run the Upgrade 
	utility dbupgrad before unloading the database.

    ================(Build #5003  - Engineering Case #354948)================

	When the database option Optimization_goal was set to 'First-row', the optimizer 
	did not always respect it for queries with equijoins. This has been fixed.

    ================(Build #5003  - Engineering Case #354773)================

	If an external procedure attempted to return a string longer than 65535 bytes, 
	via a single call to the set_value callback function, the string would have 
	been truncated. This has been fixed. A workaround is to call set_value multiple 
	times to build up the result in pieces, each being shorter than 65535.

    ================(Build #5003  - Engineering Case #353893)================

	If an event was scheduled to execute only once, and the event completed at 
	the same time as the database was shut down, a server crash could have resulted. 
	This has been fixed.

    ================(Build #5003  - Engineering Case #353678)================

	If either of the -ar or -an command line options was used with Unload utility 
	DBUNLOAD, column statistics from the unloaded database would not have been 
	preserved in the new database. This could have resulted in different query 
	execution plans being chosen when using the new database. This has been fixed.



  Adaptive Server Anywhere - Sybase Central Plug-in



    ================(Build #5440  - Engineering Case #441754)================

	The keyword "REAL" was not supported in the Data Type column of the table 
	editor. The workaround was to use the keyword "FLOAT" instead. This has been 
	fixed.

    ================(Build #5393  - Engineering Case #429117)================

	In the Details panel of a table's result set, if a row was selected and the 
	Delete key pressed, the row would have been successfully deleted. If the 
	Delete key was pressed again, an error would have been displayed. This has 
	been fixed.

    ================(Build #5391  - Engineering Case #428363)================

	Both the SQL Anywhere and MobiLink plug-ins permitted pausing, and continuing 
	Windows services for dbsrv8 and dbsrv9, dbeng8 and dbeng9, dbremote, dbmlsync 
	and dbmlsrv8 and dbmlsrv9. This ability has been removed, as none of these 
	executables actually support pausing. Pause and continue operations are now 
	only permitted on dbltm Windows services.

    ================(Build #5219  - Engineering Case #380793)================

	The background color of explanatory text was being set incorrectly in wizards 
	when Sybase CEntral was run on Linux. This has been fixed so that the wizard 
	backgrounds are now transparent.
	

    ================(Build #5189  - Engineering Case #373172)================

	In the Translate Log File wizard, selecting 'Include trigger generated transactions' 
	and 'Include as comments only', would have included the trigger generated 
	transactions as statements rather than as comments. This has been fixed.

    ================(Build #5140  - Engineering Case #362803)================

	If the help window was opened and closed, and then Sybase Central was minimized, 
	the help window would have been reopened when Sybase Central was then maximized. 
	Note, this same problem affected Interactive SQL dbisql, as well. This has 
	been fixed.
	
	
	

    ================(Build #5139  - Engineering Case #362728)================

	Turning on or off warnings in the Preferences dialog from Tools menu, (Tools-&gtAdaptive 
	Server Anywhere 9-&gtPreferences - 'Confirm deletions when editing table') 
	would have had no effect when table data was being edited. This has been 
	fixed.

    ================(Build #5137  - Engineering Case #362226)================

	On Linux systems, getting information about a table's primary key, by clicking 
	the 'Details' button on the Property dialog, would have caused a ClassCastException.  
	This is now fixed.

    ================(Build #5117  - Engineering Case #351546)================

	When in the Code Editor, if Auto indent was set to Default or Smart, pressing 
	enter with text selected would have added a new line to the selection, rather 
	than replacing the selection with a new line. The problem does not occur 
	when tab Auto indent is set to none. This problem has now been fixed.

    ================(Build #5003  - Engineering Case #356390)================

	The "do not ask again" checkbox, that is shown when deleting a table record, 
	could have been selected and then the "No" button clicked.  This would have 
	resulted in the dialog never being shown again. In 8.x versions, "Yes" would 
	always have been assumed, and in 9.x versions, "No" would always have been 
	assumed. This has been changed so that the buttons now say "Ok" and "Cancel", 
	and the checkbox is ignored when "Cancel" is pressed.
	

    ================(Build #5003  - Engineering Case #355830)================

	A NullPointerException could have occurred in the following situation:
	- Open a second window, like when editing a stored procedure
	- Make a change to the procedure, close the window, when it prompts to save 
	changes, respond NO
	- The window closes, but the Sybase Central window does not have focus
	- pressing TAB or CTRL-TAB will caused the exception
	
	This has now ben corrected
	



  Adaptive Server Anywhere - Utilities



    ================(Build #5504  - Engineering Case #455668)================

	It was possible for the database server to crash when attempting to run a 
	corrupted database file.  Assertion 201418 'Row (page:index) has an invalid 
	offset' has now been added to detect this corruption.  

    ================(Build #5477  - Engineering Case #449874)================

	The dbisqlc utility may have terminated abnormally immediately on startup.   
	This problem occurs occasionally. A problem in the GUI initialization code 
	has been fixed.

    ================(Build #5455  - Engineering Case #444472)================

	Using Interactive SQL with the -q command line option ("Suppress non-critical 
	messages"), would have caused all messages to be suppressed. This was not 
	correct, and has been fixed. Now, error messages are displayed regardless 
	of whether -q is used or not.

    ================(Build #5446  - Engineering Case #443027)================

	The Interactive SQL utility, as well as Sybase Central and DBConsole, would 
	not have operated correctly when connected to a SQL Anywhere database that 
	had the SQL_flagger_error_level or SQL_flagger_warning_level options set 
	to anything other than 'W'. Typical behavior included getting the error message 
	Disallowed language extension detected..." when connecting. This has been 
	fixed.
	

    ================(Build #5431  - Engineering Case #440140)================

	Calling the DBTools DBUnload function twice in an application would have 
	resulted in the second call hanging if the unload was attempting to load 
	into a new database. This problem did not affect dbunload.exe, but could 
	be seen using Sybase Central. This has been fixed. 
	

    ================(Build #5413  - Engineering Case #430586)================

	The Interactive SQL utility was failing to execute a ROLLBACK following a 
	failed statement if the Auto_commit option was ON. The behaviour has been 
	changed so that a ROLLBACK is now executed in this situation. Note, this 
	is now the same behavior as DBISQLC.

    ================(Build #5411  - Engineering Case #431876)================

	The Interactive SQL utility could have reported a spurious table missing 
	error if a connection executed a SELECT statement, disconnected, then connected 
	to a different database and executed an INSERT statement. The problem was 
	due to the "Auto_refetch" option being on. This option was not sensitive 
	to the connection being closed, which has now has been fixed.

    ================(Build #5405  - Engineering Case #432032)================

	When run on Unix systems with the -q "silent mode" command line option, dbisqlc 
	would have crashed if a MESSAGE statement was executed with a TYPE ACTION 
	TO CLIENT or a TYPE WARNING TO CLIENT clause. This has been fixed.

    ================(Build #5391  - Engineering Case #428508)================

	The Interactive SQL utility could have reexecuted more than the last SELECT 
	statement if the "Auto_refetch" option was on. For this to have occurred, 
	DBISQL would also have to have been run in windowed mode, with multiple statements 
	executed at once, starting with a SELECT statement. e.g.
		       SELECT * FROM myTable;
		       OUTPUT TO 'c:\\test.txt';
	Then an INSERT, UPDATE, or DELETE statement was executed, which would have 
	caused the statements following the SELECT statement (in this case, the OUTPUT 
	statement) to have been reexecuted. This has been fixed.

    ================(Build #5314  - Engineering Case #407408)================

	If the full path to the active transaction log was greater than 57 characters, 
	calling the Backup utility with command line option -xo "delete and restart 
	the transaction log without backup", would have failed to erase the renamed 
	transaction log.  The renamed transaction log file is now properly deleted.
	 
	

    ================(Build #5311  - Engineering Case #406904)================

	If the Translation utility was used with the command line option -it "specify 
	table names to include in output", it would have crashed when the transaction 
	log file contained transactions that continue from the previous transaction 
	log file. This has now been
	fixed.

    ================(Build #5302  - Engineering Case #401948)================

	The corruption caused by the problem fixed in Engineering Case 383145 could 
	have been undetectable by database validation. Engineering Case 386569 attempted 
	to address this, but the change may have caused validation of non-corrupted 
	indexes to fail. This has been fixed. Validation of a database affected by 
	the corruption in Engineering Case 383145 is now detected properly and results 
	in the error "Index 'index_name' on table 'table_name' has an invalid right 
	spine". This type of corruption should be fixed by rebuilding the index.

    ================(Build #5286  - Engineering Case #400332)================

	Changes for  Engineering Case 394722 to the iAnywhere JDBC Driver prevented 
	Interactive SQL from displaying, importing, or exporting unsigned numeric 
	types correctly. For example, when displaying unsigned values, an error dialog 
	could have been displayed saying that the value would not fit in an "n" byte 
	value, where "n" was a small whole number. This has now been fixed.

    ================(Build #5281  - Engineering Case #369150)================

	If the server command line passed to the Spawn utility dbspawn contained 
	the @filename option, dbspawn would have expanded the contents of the file 
	and then spawned the server. This meant that the server command line would 
	have included the contents of the file. If the file contained certificate 
	passwords or database encryption keys, they would then be visible through 
	the 'ps' command or equivalent. This has been changed, dbspawn will no longer 
	expand the @filename parameter.

    ================(Build #5270  - Engineering Case #394136)================

	If a table had been created with the PCTFREE clause (table page percent free), 
	the unload or reload of that table would not have used this PCTFREE in the 
	CREATE TABLE statement for the new database. This has been fixed.
	

    ================(Build #5270  - Engineering Case #391900)================

	Intreactive SQL could have reported an 'internal error' if the Import Wizard 
	was used to read data from an ASCII file into an existing table, and there 
	were fewer columns in the file than columns in the table. This has been fixed.

    ================(Build #5258  - Engineering Case #391577)================

	The global variables @@fetch_status, @@sqlstate, @@error, and @@rowcount 
	may have been set with incorrect values if a cursor's select statement contained 
	a user-defined function that itself used a cursor. This has been fixed.
	

    ================(Build #5256  - Engineering Case #386025)================

	When attempting to rebuild a strongly encrypted database with the Unload 
	utility with the 'rebuild and replace database'command line option (-ar), 
	if the database was involved in replication or synchronization, the current 
	transaction log offset of the newly rebuilt database would not have been 
	set correctly. When rebuilding databases of this type, the Unload utility 
	will now assume that the encryption key specified with the -ek or -ep switch 
	is the encryption key for both the database being rebuilt, and the newly 
	rebuilt database. In addition, using the -ar option will now return an error 
	in the following situations, where previously the database would have been 
	rebuilt but the log offset would not have been set correctly :
	
	1) The database is involved in replication or synchronization, but the encryption 
	key provided with the -ek or -ep switch is not a valid encryption key of 
	the database being rebuilt.
	2) The database is involved in replication or synchronization, the database 
	being rebuilt is strongly encrypted, but the -ek or -ep switch was not provided 
	on the dbunload command line.
	

    ================(Build #5252  - Engineering Case #388837)================

	When building a remote database from a reload file generated by extracting 
	from a consolidated database there could have been a failure.  This would 
	only have occurred if there existed a publication on a subset of columns 
	in a table and there were also statistics on some columns in the table that 
	were not part of the publication.  This has been fixed.
	
	A workaround would have been to drop the statistics on the table or column 
	before extracting the user database.

    ================(Build #5239  - Engineering Case #383145)================

	After deleting rows from the end of a large trie-based index, attempting 
	to insert or search for a value larger than any indexed value could have 
	resulted in fatal I/O errors (such as reading past the end of the file), 
	or assertions such as 102300, or 201601.  For this to have occurred, the 
	index had to contain at least 3 levels (more than 50,000 rows with a 2k page 
	size), the value being deleted had to be the last value in the index, and 
	the leaf page containing the entry, (as well as the leaf's parent), must 
	have contained only a single entry.  Rebuilding (or reorganizing) the index 
	would have fixed the problem.
	Note, dbvalid would not have couaght this problem

    ================(Build #5221  - Engineering Case #381327)================

	Some utilities, (ie dbltm.exe, ssremote.exe, dbremote.exe and ssqueue.exe) 
	would have crashed if they had been given a non-existent configuration file 
	on their command lines.  The utilities now return the usage screen.

    ================(Build #5212  - Engineering Case #378613)================

	The following problems related to the Import Wizard have been fixed:
	
	1.  When importing ASCII or FIXED files into an existing table, the column 
	data types were always being displayed as "VARCHAR" on the last page. Now, 
	the actual column types are displayed.
	
	2.  When importing FIXED data in an existing table, if fewer column breaks 
	were placed so that fewer columns were defined than appeared in the actual 
	table, the preview would still have shown columns for all of the columns 
	in the database table. This was incorrect, and clicking on these extra columns 
	would have caused Interactive SQL to crash. These extra columns are now no 
	long displayed.
	
	3.  If the Import Wizard was closed by clicking the close box, it could 
	still attempt to import the data. Now, clicking the close box is synonymous 
	with clicking the "Cancel" button.

    ================(Build #5204  - Engineering Case #377116)================

	The reload.sql file created by the Reload utility did not double-quote the 
	login name for CREATE EXTERNLOGIN statements. This may have caused a syntax 
	error during reload. This has been fixed, the login name is now double-quoted.

    ================(Build #5196  - Engineering Case #374705)================

	When the Unload utility dbunload, was run with the command line option -ar 
	(rebuild and replace database), the old transaction log file may not have 
	been deleted after the database was successfully rebuilt, even if there was 
	no replication/synchronization involved in the original database. This problem 
	has been fixed.

    ================(Build #5191  - Engineering Case #373477)================

	Running the Unload utility dbunload, with both the -ar (rebuild and replace 
	database) and -ek (specify encryption key for new database) command line 
	options, would have failed when attempting to connect to the new database 
	with the error "Unable to open database file "&ltfile&gt" -- Missing database 
	encryption key." The last step of dbunload -ar is to rename the log file, 
	but the encryption key was not specified when it should have been. This is 
	now fixed, te encryption key is now specified correctly.

    ================(Build #5189  - Engineering Case #373179)================

	If two instances of the SQL preprocessor, sqlpp run at the same time, the 
	generated code may be invalid. The concurrently running preprocesor's could 
	attempt to use the other's temporary file, and silently generate invalid 
	code. This problem has been fixed by including the process pid in the temporary 
	file.

    ================(Build #5188  - Engineering Case #372897)================

	If a database consisted of more dbspaces other than just the SYSTEM dbspace, 
	and an attempt was made to unload the data from this database to another 
	database with the same structure using the Unload utility dbunload:
		DBUNLOAD -d -ac &ltconnection-parameters-to-new-database&gt 
	The Unload utility would have attempted to create a dbspace for the new 
	database and would have reported an error if the dbspace already existed. 
	Now, dbunload will not attempt to create dbspaces when reloading into another 
	database if the -d command-line option is used.

    ================(Build #5178  - Engineering Case #370724)================

	The Unload utility dbunload, would have silently placed old transaction log 
	files into the root directory, when the command line option -ar (rebuild 
	and replace database) was used and no log directory was specified, for databases 
	that were involved in synchronization/replication using RepAgent. Now, if 
	this situation occurs, the old transaction log file will be placed in the 
	log directory of the database.

    ================(Build #5177  - Engineering Case #370567)================

	The Unload utility dbunload, may have crashed if the command line option 
	-ar (rebuild and replace database) was used with a database that had no online 
	transaction log. This problem has been fixed.

    ================(Build #5172  - Engineering Case #369491)================

	When running on Unix systems, the Interactive SQL utility dbisql, would have 
	displayed the usage message when a full path to a SQL script file was given. 
	The leading '/' was was being interpreted as a command line switch on. This 
	has been fixed.

    ================(Build #5169  - Engineering Case #368825)================

	If a datasource name was specified on the command line that contained an 
	encrypted password, dbisql would not have immediately connected to the database, 
	but would have first displayed the "Connect" dialog. Now an attempt is made 
	to connect immediately, without first displaying the "Connect" dialog.

    ================(Build #5167  - Engineering Case #368475)================

	Very occasionally, dbisql could have reported an internal error (NullPointerException) 
	when scrolling down in the "Results" pane. This has been fixed.

    ================(Build #5156  - Engineering Case #365940)================

	If the trantest sample application (PerformanceTransaction), was executed 
	with -a odbc -n &ltthreadcount&gt and the thread count was higher than one it 
	may have crashed in NTDLL.DLL. This has been fixed.
	

    ================(Build #5150  - Engineering Case #364921)================

	Interactive SQL dbisql could failed with an internal error when rows of a 
	table were selected and then the DELETE key was pressed to delete them. The 
	following conditions had to be true for the error to have occured:
	- There must have been more than about 125 rows in the table
	- The rows had to have been selected using the keyboard
	- The table was scrolled while selecting, past the initial 125 rows
	- The "Show multiple result sets" option was OFF.
	
	This problem has been fixed. 
	
	In a related issue, if rows were selected, then CTRL+C was pressed to copy 
	them, extra lines of empty values would have been select after the last row. 
	All the table data would have been copied correctly; the error was the addition 
	of the blank rows. This has also been fixed.
	

    ================(Build #5139  - Engineering Case #362497)================

	The OUTPUT statement could have failed to write any rows to a file, even 
	if there were rows to write, if the "Output_format" option was set to an 
	invalid value. Now, it is impossible to set the "Output_format" option to 
	an invalid value. When connecting to a database in which the option has been 
	set to a bad value, the bad value is ignored and the default (ASCII) is assumed. 

    ================(Build #5134  - Engineering Case #361599)================

	Executing a STOP DATABASE statement which attempted to stop a database running 
	on a server to which you were not currently connected, would have resulted 
	in dbisql failing with an internal error. This has been fixed.

    ================(Build #5132  - Engineering Case #361206)================

	When run on Unix systems, the Data Source utility dbdsn, required write permission 
	on the .odbc.ini file, even if just listing or reading the DSNs. This has 
	been
	fixed, now only read permission is required, unless the -d or -w options 
	are used.

    ================(Build #5126  - Engineering Case #360001)================

	The context menu for Results tables could have appeared far from the mouse 
	pointer if the whitespace to the right or below the actual table data was 
	clicked on. This has been fixed so that the context menu always appears where 
	the mouse was clicked.

    ================(Build #5126  - Engineering Case #359828)================

	When the Histogram utility dbhist, was run on non-English systems, mangled 
	characters would have been shown in the title, legend, etc, of the generated 
	Excel chart. This problem has now been corrected.

    ================(Build #5120  - Engineering Case #358151)================

	The Interactive SQL utility dbisqlc, did not display help when the "Help 
	Topics" menu was selected. This has been fixed.

    ================(Build #5117  - Engineering Case #355787)================

	An internal error could have been reported in response to pressing the DELETE 
	key when an uneditable result set was displayed in the "Results" panel and 
	the results table had the focus. This has been fixed.

    ================(Build #5117  - Engineering Case #354822)================

	If the Histogram utility dbhist was not provided with connection arguments 
	(ie -c options), it would have assumed a default connection string of UID=DBA;PWD=SQL. 
	Now, dbhist will no longer assume any default connection arguments, which 
	is consistent with the behaviour of other ASA utilities.

    ================(Build #5117  - Engineering Case #354617)================

	If dbisql reported an internal error, the password used in the current connection 
	(if any) was shown in clear text in the error details. It has now been replaced 
	by three asterisks. Note that passwords given as part of a "-c" command line 
	option are still displayed in clear text in the error details.

    ================(Build #5117  - Engineering Case #354337)================

	An internal error (IllegalArgumentException) could have been reported by 
	dbisql, when an attempt was made to edit the result set of a stored procedure. 
	The result set should not have been editable in the first place. This has 
	now been corrected.
	   
	This problem would only have occurred when connecting using the iAnywhere 
	JDBC Driver.

    ================(Build #5117  - Engineering Case #351394)================

	If a query had duplicate ORDER BY items, opening it in the Query Editor would 
	have caused its parser to generate an error. 
	
	For example:
	SELECT emp_fname, emp_lname
	FROM employee
	ORDER BY emp_fname, emp_fname
	
	SELECT emp_fname, emp_lname
	FROM employee
	ORDER BY 1, 1
	
	This has now been fixed, the duplicate ORDER BY item will be ignored by 
	the Query Editor's parser.

    ================(Build #5117  - Engineering Case #349930)================

	If incorrect options were used with the Unload Database utility dbunload, 
	it could have crashed after displaying the usage. This has been fixed.

    ================(Build #5117  - Engineering Case #348793)================

	It was possible to edit the result set of a query, even though some, or all, 
	of the primary keys were not included in the result set. Now, the result 
	set can only be edited if all of the primary key columns are included, or 
	the table has no primary key. These conditions have been added in addition 
	to the existing conditions; that columns must all come from one table, and 
	no Java columns are included.
	
	Updating rows without the entire primary key being in the result set, could 
	have inadvertently modified or deleted more than one row.
	
	Some examples, using the sample database (ASADemo):
	
	    1.  SELECT * FROM customer
	
	            The query include all primary key columns from the 
	            "customer" table, so the results are editable.
	
	    2. SELECT year, quarter FROM fin_data
	
	           The query does not include all of the primary key columns
	           ("code" is missing), so the results are not editable.
	

    ================(Build #5117  - Engineering Case #347779)================

	The Unload utility dbunload, or Sybase Central's Unload Database wizard, 
	could have failed with a syntax error if a comment on an integrated login 
	id contained a double quote character. Unlike other types of comments, double 
	quotes are used to enclose the comment string, but any double quotes in the 
	string where not being doubled. Now the comment will be enclosed in single 
	quotes and any single quotee or escape characters will be doubled. 

    ================(Build #5117  - Engineering Case #346263)================

	The following problems could have been seen when launching or running the 
	graphical administration tools (ie, Sybase Central, DBISQL, DBConsole, MobiLink 
	Monitor)
	
	1. A crash on startup -- The Java VM may have reported that an exception 
	occurred in the video card driver.
	
	2. Painting problems -- On Windows XP, the task switcher that comes with 
	Windows XP Powertoys caused the administration tools to paint incorrectly 
	when switching through the list of tasks.
	
	These problems have been fixed, but a workaround is to disable the computer's 
	use of DirectDraw and Direct3D acceleration.

    ================(Build #5117  - Engineering Case #345634)================

	If the server issued an error message in response to committing changes, 
	the error message would not be displayed if the commit was a side-effect 
	of shutting down DBISQL. This situation could occur if the dbisql option 
	Wait_for_commit was 'On'. Now the message is always displayed.

    ================(Build #5117  - Engineering Case #313786)================

	The Database Initialization utility dbinit, could have failed if the SQLCONNECT 
	environment variable specified a database file name (DBN). This has been 
	fixed so that the SQLCONNECT environment variable does not affect dbinit.
	

    ================(Build #5003  - Engineering Case #356790)================

	An error would have been reported if an UNLOAD TABLE statement was executed 
	that included an APPEND clause. This has been fixed.



  MobiLink - Charset Conversion (UNILIB)



    ================(Build #5117  - Engineering Case #345236)================

	Microsoft Windows, for Asian (multi-byte) languages, allows a user to define 
	their own characters, including the glyph that is displayed. As part of defining 
	a character, the user picks an unused code point in the character set. MobiLink 
	and ASA were not aware of this new code point, and character set conversion 
	would substitute the "invalid character" for any user-defined characters. 
	
	Now, the mappings for user-defined characters in cp950 (Traditional Chinese) 
	are included.



  MobiLink - Java Plugin for Sybase Central



    ================(Build #5117  - Engineering Case #358138)================

	Connecting to a database in the MobiLink plug-in by opening the Connect dialog 
	and specifying the connection information, would have caused the information 
	specified (excluding the password) to be saved in the user's .scUserPreferences 
	file under the default connection key "DefConn". The information was saved 
	so that the next
	time the Connect dialog was opened, it would contain the previous connection 
	information. For security reasons, this feature has been removed. Now, this 
	information is no longer implicitly saved in the user's .scUserPreferences 
	file. Instead, it is persisted in memory for the current Sybase Central session 
	only. Note that the user can still use
	connection profiles to explicitly persist connection information in the 
	.scUserPreferences file.
	
	This change also fixes a problem which could have caused the password to 
	be incorrectly persisted as "***".



  MobiLink - Monitor



    ================(Build #5154  - Engineering Case #365731)================

	When a dialog was opened from another dialog (rather than from the main window), 
	closing the topmost dialog would have returned focus to the main window, 
	instead of the initial dialog. This has been corrected.

    ================(Build #5136  - Engineering Case #362053)================

	The MobiLink Monitor was reporting the wrong number of uploaded bytes. The 
	Monitor would most often have reported the actual value plus one, but it 
	could also have reported even larger values. This has been corrected.



  MobiLink - SA Client



    ================(Build #5570  - Engineering Case #477367)================

	When download acknowledgement was enabled, the MobiLink client would have 
	incorrectly failed to send a download ack for a synchronization if a previous 
	synchronization during the same run had encountered a server side download 
	error.  As a result the server would report the following error:
	
	   Error: Unable to read from the 'tcpip' network connection. Unable to 
	read 2 bytes.
	   Error: [-10034] No download confirmation from remote database
	
	This problem has been fixed

    ================(Build #5481  - Engineering Case #450353)================

	The MobiLink client would gradually have consumed more and more memory when 
	synchronizing tables that contained foreign keys that refer to other tables 
	that were not being synchronized. This has been corrected.

    ================(Build #5381  - Engineering Case #426153)================

	If the MobiLink client was shutdown by clicking the shutdown button on the 
	window, using the stop method on the integrations component or sending a 
	WM_CLOSE message to the dbmlsync window, then it could have hung with 100% 
	CPU utilization.  The behaviour would have occurred intermittently, and would 
	have been more likely on machines with multiple processors. This has now 
	been fixed
	

    ================(Build #5369  - Engineering Case #422828)================

	If an sp_hook_dbmlsync_process_exit_code hook was defined and an invalid 
	dbmlsync extended option was specified, then the synchronization client would 
	have crashed. This has been fixed.

    ================(Build #5335  - Engineering Case #415767)================

	If the MobiLink client was running on a schedule, and had successfully synchronized, 
	in very rare circumstances, it was possible for a failed synchronization 
	to result in the section of transaction log that was scanned during the failed 
	synchronization to not be scanned again in the next synchronization. This 
	has now been fixed.
	

    ================(Build #5322  - Engineering Case #400188)================

	If a MobiLink client connected to a database where SQL Remote was already 
	running, it was possible for the MobiLink client to report "Cannot convert 
	scanner to a unsigned int".  When this error was reported, the current synchronization 
	would fail.  This has been fixed so that the error is no longer reported.

    ================(Build #5304  - Engineering Case #405360)================

	If a value longer than 255 bytes was passed to a MobiLink client hook procedure, 
	through the #hook_dict table, then the MobiLink client could have become 
	unstable. This may have occurred when a communications address longer than 
	255 bytes was specified, there was a failure connecting to the Mobilink server, 
	and there was an sp_hook_dbmlsync_ml_connect_failed hook defined.  This has 
	now been fixed.
	

    ================(Build #5292  - Engineering Case #400604)================

	At the end of each synchronization dbmlsync reports a line like the following:
	
	End synchronizing 'template_P1' for MobiLink user 'template_U1'
	
	If more than one publication was specified on the MobiLink Client commandline 
	(either together as -n P1,P2 or separately as -n P1 -n P2), then the publication 
	reported in this message may have been incorrect, although processing of 
	the synchronization would have continued correctly.  Only the message was 
	wrong. The message now reports the correct publication name or names.

    ================(Build #5236  - Engineering Case #385179)================

	The MobiLink client may not have detected that a table had been altered, 
	and would have sent an invalid upload stream to the consolidated database. 
	The following operations in a log file demonstrate the problem, when the 
	client scanned the log during a single synchronization :
	1) Data on table t1 is changed.
	2) Table t1 is removed from the only publication it belongs to.
	3) Data on table t1 is changed again.
	4) Table t1 is altered.
	5) Table t1 is added back to the publication it was removed from.
	
	Now, the MobiLink client will report the error "Table 't1' has been altered 
	outside of synchronization at log offset X" when this situation arises.

    ================(Build #5234  - Engineering Case #385171)================

	If an sp_hook_dbmlsync_logscan_begin hook was defined that modified a table 
	being synchronized, and the extended option Locktables was set to 'off', 
	then actions performed by the hook would not have been uploaded during the 
	current synchronization. Actions would have been uploaded correctly though 
	during the next synchronization. This has been changed so that any changes 
	made to synchronization tables by the sp_hook_dbmlsync_logscan_begin hook 
	will now be uploaded during the current synchronization regardless of the 
	setting of the Locktables option.

    ================(Build #5233  - Engineering Case #372331)================

	During synchronization it was possible for a Windows CE device to go into 
	sleep mode. Now the MobiLink client makes system calls to ensure that this 
	does not happen. It is still possible for a device to go into sleep mode 
	during a delay caused by the sp_hook_dbmlsync_delay hook or during the pause 
	between scheduled synchronizations.

    ================(Build #5230  - Engineering Case #384141)================

	When using the Database Tools interface to run the MobiLink synchronization 
	client, if the a_sync_db version field was set to a value that was 8000 or 
	greater, and less than the version supported by the dbtools library, then 
	the upload_defs field would have been ignored. If the database had more than 
	one subscription, then this would have caused the synchronization to report 
	the following error message:
	
	Multiple synchronization subscriptions found in the database. Please specify 
	a publication and/or MobiLink user on the command line.
	
	This behaviour could also be seen if the MobiLink client was used with a 
	later version of the dbtools library. This has been corrected.

    ================(Build #5225  - Engineering Case #382167)================

	If event hooks were defined, the MobiLink client would not have recognized 
	and executed them if their procedure name was not entered entirely in lower 
	case.  The case of the procedure name is now ignored.
	
	Note, a similar problem with the Extraction utility and SQL Remote has also 
	been fixed.

    ================(Build #5225  - Engineering Case #382166)================

	When the MobiLink client extended option TableOrder was specified, the synchronization 
	would have failed if the tables, or their owners, were specified in a different 
	case from the one in which they were defined in the database.  This problem 
	occurred whether the database was case sensitive or not. The tables and owners 
	specified by this option are now always treated as case insensitive.

    ================(Build #5212  - Engineering Case #378115)================

	The MobiLink ASA client may not have shut down gracefully when it was running 
	as a Windows service.  This may have caused resources such as temporary files, 
	not to have been cleaned up before shutting down.  This problem has now been 
	fixed.
	
	Note, this problem applied to the MobiLink synchronization server and SQL 
	Remote for ASA as well, and have also been fixed. 

    ================(Build #5209  - Engineering Case #377878)================

	The MobiLink client could have crashed, or behaved irratically, when when 
	the value of the 'charset' database property for the remote database was 
	longer than 29 bytes. In particular, this was the case for databases with 
	the EUC_JAPAN collation, although there may be other such collations. This 
	issue has been fixed.

    ================(Build #5206  - Engineering Case #377036)================

	If the MobiLink client was run with the -vn option, ('show upload/download 
	row counts'), but not the -vr option, ('show upload/download row values'), 
	or the -v+ option, ('show all messages'), then the upload row counts reported 
	for each table would be cummulative, that is each rows count would include 
	not just the rows uploaded from that table, but also those uploaded for all 
	previous tables.

    ================(Build #5194  - Engineering Case #374490)================

	If the environment variables TMP or TEMP were not set, the MobiLink client 
	dbmlsync, would have given the error:
		"Unable to open temporary file "MLSY\xxxx" -- No such file or directory"
	and refused to start. This problem is now fixed.
	

    ================(Build #5193  - Engineering Case #374070)================

	The ASA client dbmlsync, could have crashed, either while creating the upload, 
	or  at the end of the synchronization. This was more likely to occur with 
	very large uploads. This behaviour has been corrected.

    ================(Build #5184  - Engineering Case #372085)================

	When the Synchronization Client dbmlsync crashed it would have left behind 
	a temporary file, which would never have been deleted. Now, a check is made 
	at startup for any temporary files left from previous runs and deletes them 
	if they exist.

    ================(Build #5178  - Engineering Case #370609)================

	The MobiLink Client dbmlsync, would have complained of an "invalid option 
	...", if it was started with a configuration file, @filename, and filename 
	contained any extended options specified as
		-e opt1="val1";opt2=val2;...
	even if all the extended options were valid. This problem is fixed now.

    ================(Build #5172  - Engineering Case #369238)================

	If the schema of a table outside of a publication was altered (for example, 
	table "t1"), and a synchronizing table existed, whose name started with this 
	table's name (for example, table "t1_synch"), that had outstanding changes 
	to synchronize, then dbmlsync would incorrectly report that the schema of 
	the synchronizing table had been altered outside of synchronization.  This 
	has now been fixed.
	

    ================(Build #5161  - Engineering Case #367528)================

	Autodial was not responding, even when the network_name parameter was specified. 
	Autodial functionality has now been restored.

    ================(Build #5128  - Engineering Case #360258)================

	The total accumulated delay caused by the sp_hook_dbmlsync_delay hook was 
	being calculated incorrectly when a synchronization was restarted using the 
	sp_hook_dbmlsync_end hook.  As a result the sp_hook_dbmlsync_delay hook might 
	not be called or the delay produced by the hook might be shorter than specified.
	
	Following are the specific conditions required to see this problem:
	- Both an sp_hook_dbmlsync_end hook and an sp_hook_dbmlsync_delay hook have 
	been coded.
	- During a synchronization the delay hook was called one or more times. 
	Those calls resulted in a total delay D and the maximum accumulated delay 
	parameter was set to some value M.
	- When the end hook is called it sets the 'restart' parameter to 'sync' 
	or 'true' to restart the synchronization.
	
	When the above conditions are met, the sum of delays caused by the delay 
	hook was not being reset before the synchronization was restarted.  As a 
	result, on the restarted synchronization, the delay hook would not be called 
	if D &gt= M.  If D &lt M then the maximum delay that would be allowed before 
	the synchronization occurred would be M - D when it should have been M.
	
	The sum of delays is now reset before the synchronization is restarted so 
	that the delay hook will have the same behavior on a restarted synchronization 
	as it does on a first synchronization.

    ================(Build #5119  - Engineering Case #358388)================

	When the ADDRESS specified for the ASA client dbmlsync, to connect to a Mobilink 
	server, contained the 'security' parameter and the cipher specified was not 
	recognized, dbmlsync would have reported an error indicating that it could 
	not load a DLL (usually dbsock?.dll or dbhttp?.dll).  A more meaningful error 
	message is now displayed.

    ================(Build #5117  - Engineering Case #346769)================

	If the Synchronization client dbmlsync was set to synchronize on a schedule, 
	and the MobiLink server was shut down when the upload stream was being sent 
	and then started up
	again, dbmlsync could have ontinuously failed to synchronize until it was 
	shut down and restarted.  The MobiLink server would simple have reported 
	"Synchronization Failed", with no more information. This has now been fixed.

    ================(Build #5003  - Engineering Case #357701)================

	Synchronizing to an ASA remote database using the UTF8 collation could fail 
	with errors or put corrupted data into the database.
	
	The same problem would affect any application using ODBC or OLEDB, including 
	Java-based applications using the JDBC-ODBC bridge (8.0) or iAnywhere JDBC 
	Driver (9.0), including DBISQL and Sybase Central. 
	
	The bug was introduced in the following versions and builds:
	    8.0.2 build 4409
	    9.0.0 build 1302
	    9.0.1 build 1852
	
	This problem has been fixed.



  MobiLink - Synchronization Server



    ================(Build #5444  - Engineering Case #442684)================

	The MobiLink server was not able to upload data from an ASA char/varchar 
	column to a Microsoft SQL Server nchar/nvarchar column, if the column width 
	defined in the remote database was greater than 2000 bytes.  The Microsoft 
	ODBC driver would have given the error "Invalid precision value", when the 
	MobiLink client tried to upload data to a table that contained such columns. 
	This problem is fixed now.
	

    ================(Build #5427  - Engineering Case #435217)================

	If the upload_update synchronization event had been defined to accept both 
	the new and old row values being synchronized, the table contained blob columns, 
	and a new row value for one of the blob columns was of zero length, then 
	the MobiLink Server would have returned the error : "Error: INTERNAL ERROR: 
	occurred while retrieving a BLOB -- zero length".  This problem has now been 
	fixed.
	

    ================(Build #5397  - Engineering Case #430086)================

	After a deadlock occurred, the upload data for the tables prior the current 
	table that caused the deadlock may not have been applied to the consolidated 
	database by the MobiLink synchronization server if the following situations 
	applied:
	1) the MobiLink synchronization was running with the rowset size greater 
	than 1: the command line option -s X (X &gt 1) was used or the command line 
	contained no -s option;
	2) the deadlock occurred when the MobiLink synchronization server was applying 
	the upload operations in multi-row mode and there was no deadlock when the 
	server was retrying to apply the same operations for the current table in 
	single-row mode.
	This problem is now fixed.

    ================(Build #5339  - Engineering Case #415985)================

	The documented order of events in the prepare_for_download transaction has 
	been incorrect since the feature first appeared in 7.0.1. The correct order 
	is:
	
	------------------------------------------------------
	prepare_for_download
	------------------------------------------------------
	
	modify_last_download_timestamp
	prepare_for_download
	if( modify_last_download_timestamp script is defined
	    or prepare_for_download script is defined ) {
	    COMMIT
	}
	
	Previous documentation had the order of the scripts reversed. The above 
	order was chosen because the last-download timestamp (LDT) affects the content 
	of the download. If the LDT is being modified, it must be modified before 
	the download logic kicks in (ie. in the prepare_for_download script or in 
	the download scripts).

    ================(Build #5321  - Engineering Case #409377)================

	If the -clrVersion or -clrFlavor .NET command line options were specified 
	when starting the MobiLink server, the MobiLink server would have reported 
	that the options were invalid, or not specified correctly. The MobiLink server 
	will now properly parse and accept these two .NET options.
	

    ================(Build #5303  - Engineering Case #402359)================

	The MobiLink Synchronization Server was not able to synchronize multi-byte 
	characters (e.g. Chinese characters) between ASA with the UTF8 collation 
	and Microsoft SQL server, if the columns were defined as CHAR (varchar, char, 
	or long varchar) in ASA and NVARCHAR in Microsoft SQL server. A new command 
	line option, -hwH+, has been added to the MobiLink server. By default, it 
	is on for Microsoft SQL server and off for all other consolidated databases.  
	When it is on, the MobiLink server will call SQLDescribeParam (this function 
	may not be supported by all ODBC drivers, but it is available in the driver 
	for the Microsoft SQL Server) to find out the data types of the parameters 
	in the consolidated database and binds the parameters with the consolidated 
	data types for all the columns with a CHAR datatype.

    ================(Build #5302  - Engineering Case #404448)================

	When connected to an Adaptive Server Enterprise server whose version was 
	greater than or equal to 12.5.1, the MobiLink Synchronization Server could 
	have uploaded incorrect data from ASA TIME columns into ASE DATETIME columns 
	when a cursor-based upload was used.  The date part of the uploaded rows 
	in the ASE database would have been the current date, instead of '1900-01-01'. 
	This problem is now fixed.

    ================(Build #5299  - Engineering Case #403187)================

	When synchronizing against DB2, the synchronization could have been blocked. 
	MobiLink uses the table sysibm.systables to select current timestamp, thus 
	would have been blocked if another application was updating sysibm.systables 
	at the same time. To solve this problem, the table sysibm.sysdummy1, which 
	only has one row and is used for compatibility, is now used instead.

    ================(Build #5272  - Engineering Case #394331)================

	When scanning the transaction log to determine which changes need to be uploaded, 
	if dbmlsync first found a DML statement on a table (for example, an insert), 
	and then later found a DDL statement on the same table (for example, an ALTER 
	TABLE), dbmlsync should have failed and reported an error similar to "Table 
	't1' has been altered outside of synchronization at log offset X".  If the 
	table in question (or it's owner) had a name that required double quotes 
	around it in the log file (such as reserved words or numeric names such as 
	"42"), then dbmlsync would not have detected that the schema of the table 
	had changed and would not have reported the error.  Also, if the ALTER TABLE 
	statement that was executed included a comment either before the ALTER TABLE 
	statement or between "ALTER TABLE" and the table name, dbmlsync would also 
	have failed to detect that the schema of the table had changed and would 
	not have reported the error.  Dbmlsync will now report the error "Table 't1' 
	has been altered outside of synchronization at log offset X" when either 
	of these situations arise.

    ================(Build #5249  - Engineering Case #388904)================

	The MobiLink server could have failed to gather the synchronization scripts 
	for a given table and reported the error "Error fetching table script t1.begin_synchronization", 
	even though table t1 did not have a begin_synchronization script.  This problem 
	was more likely to have occured when using an Oracle consolidated database 
	and the "iAnywhere Solution 9 - Oracle Wire Protocol" ODBC driver.  This 
	problem has now been fixed.
	

    ================(Build #5249  - Engineering Case #388858)================

	When synchronizing an ASA MobiLink Client that had multiple publications, 
	MobiLink would have allocated new memory to store the publication information 
	on each synchronization. Now, the memory is freed after the synchronization 
	completes.
	

    ================(Build #5225  - Engineering Case #381111)================

	When used with a case-sensitive database, the MobiLink client could have 
	behaved incorrectly if MobiLink user and publication names were not specified 
	in the same case as they were defined in the database.  These identifiers 
	might have been specified in any of the following places:
	- the CREATE/ALTER SYNCHRONIZATION USER statement
	- the CREATE/ALTER SYNCHRONIZATION SUBSCRIPTION statement
	- the dbmlsync command line
	- the CREATE/ALTER PUBLICATION statement
	
	The incorrect behaviour could take one of the following forms:
	- MobiLink client could have crashed
	- synchronizations could have failed inappropriately
	- if a MobiLink user was subscribed to more than one overlapping publication, 
	operations that belonged to both publications might have been uploaded more 
	than once, resulting in server side errors during synchronization.
	
	MobiLink user and publication names are now treated case-insensitively
	

    ================(Build #5212  - Engineering Case #376840)================

	The MobiLink Server could have crashed when using the HTTP link for synchronization, 
	if the remote stopped communicating with the server at a specific point in 
	the synchronization. The crash actually occurred when the server timed out 
	the connection. This has been fixed.

    ================(Build #5209  - Engineering Case #377471)================

	Attemps to synchronize proxy tables would have failed with the error message 
	"Feature 'remote savepoints' not implemented".  This has been fixed.
	

    ================(Build #5191  - Engineering Case #367198)================

	In some very rare cases, an UltraLite application may have marked a column 
	as a primary key, as well as an index column, thus causing the MobiLink server 
	to crash when the application synchronized. This problem has been fixed. 
	Now, the MobiLink server will give a protocol error when this situation is 
	detected. To avoid the protocol error, the table will need to be dropped 
	and recreated.

    ================(Build #5188  - Engineering Case #372262)================

	Connecting to the MobiLink server immediately after a successful autodial 
	could have failed with error WSAEHOSTUNREACH (10065). The fix is to repeatedly 
	attempt to open the session until it is successful, or the network_connect_timeout 
	expires, default 2 minutes.

    ================(Build #5188  - Engineering Case #372098)================

	In rare circumstances, an upload could have failed with the error "Unknown 
	Client Error n", where n was some random large number. This error was usually 
	followed by another error reporting that "A protocol error occurred when 
	attempting to retrieve the remote client's synchronization log". Although 
	there are circumstances where this is a valid error to report, an instance 
	where this error was incorrectly reported has now been fixed.

    ================(Build #5172  - Engineering Case #369479)================

	The MobiLink server could have crashed if all the following had occured on 
	the same worker thread:
	- an error was handled on upload on the last table
	- a download cursor was opened for the first time on any table
	- a subsequent sync used the download table script without having an upload 
	error handled, and there were multiple rows to download
	
	This is now fixed.
	

    ================(Build #5163  - Engineering Case #367764)================

	If the consolidated and remote databases had different collations, the MobiLink 
	Synchronization server may not have respected the column width defined in 
	the remote database for columns defined with char or varchar datatypes. This 
	may have caused the ASA client to crash. Now, the MobiLink server will display 
	an error, and abort the synchronization, if the length of the column value 
	is greater than the column width defined in the remote database.

    ================(Build #5138  - Engineering Case #362597)================

	It was possible for the MobiLink server to have crashed while doing secure 
	synchronizations.  This has been fixed.
	

    ================(Build #5136  - Engineering Case #362015)================

	The MobiLink Server would not have detected update conflicts, if the server 
	was running with the command line option -s n (where n was greater than 1) 
	or without -s at all, and the consolidated database was a Microsoft SQL Server 
	or Oracle database. Also, the synchronization had to have been a statement-based 
	upload, with no upload_fetch script, and an upload stream had to have contained 
	updates that had an unsatisfied WHERE clause in the consolidated database. 
	These updates would have failed due to the unsatisfied WHERE clause, but 
	the MobiLink server would have ignored these failures without giving any 
	error or trying to resolve these conflicts. Now if the batch contains updates 
	and the number of affected rows doesn't match the number of rows applied, 
	the server will roll back the operations and try them again using single-row 
	mode.

    ================(Build #5122  - Engineering Case #359575)================

	When using the iAnywhere Solutions 8 Oracle WP driver for Win32 to connect 
	to Oracle 9i, NCHAR data was not correctly returned from the server. This 
	problem is fixed in version 4.20.0081 of this driver.  To update the driver, 
	the following files need to be updated:
	
	   wqora1919.dll
	   wqora19r.dll
	   wqora19s.dll
	   wqbas19.dll
	   wqbas19r.dll
	   wqicu19.dll
	   wqutl19.dll
	   wqutl19r.dll
	

    ================(Build #5122  - Engineering Case #359568)================

	When using the iAnywhere Solutions ODBC driver for DB2 on Windows systems, 
	(wqdb219.dll), and fetching BLOB data back in chunks, the trailing byte of 
	the buffer would have been set to 0x00. This problem has been corrected.

    ================(Build #5119  - Engineering Case #343460)================

	If a combination of inserts and updates existed in the upload stream for 
	a given table, and an error occurred when MobiLink was applying these operations, 
	it was possible for the wrong script contents to be written to the MobiLink 
	log when the error context information was being written.  The correct script 
	contents are now written to the log.

    ================(Build #5117  - Engineering Case #357506)================

	Using statement-based scripting, uploaded updates can be ignored by not providing 
	the upload_update script. When an actual update row was encountered on the 
	upload, an error would have been generated indicating the missing script, 
	and the synchronization would have been aborted. This has now been corrected. 
	A workaround would be to provide any of the conflict resolution scripts (resolve_conflict, 
	upload_insert_new_row, or upload_insert_old_row).



  MobiLink - Utilities



    ================(Build #5414  - Engineering Case #433281)================

	If a transaction log was renamed and a new one started, and there were transactions 
	that spanned the old and new transaction logs, then it was possible for any 
	of the log scanning tools (dbmlsync, dbremote, dbltm or dbtran) to crash 
	while processing the two transaction logs in sequence. This problem has now 
	beem fixed.

    ================(Build #5343  - Engineering Case #416772)================

	The Unload utility may not have properly unloaded a remote database that 
	was involved in synchronization, causing the reload file generated to contain 
	syntax errors. This would have occurred if any of the options for synchronization 
	users or synchronization subscriptions in the remote database had been completely 
	dropped with:
		ALTER SYNCHRONIZATION USER ml_username DELETE ALL OPTION
	or
		ALTER SYNCHRONIZATION SUBSCRIPTION
		TO publication-name
		[ FOR ml_username, ...  ]
		DELETE ALL OPTION
	This problem has now been fixed.

    ================(Build #5139  - Engineering Case #362725)================

	Some SSL clients could have rejected certificates generated with the Certificate 
	Generation utility gencert.  Beginning with version 8.0.2, gencert added 
	an extended key usage field to certificates it generated.  Since this does 
	not seem to be accepted universally, it has been removed.

    ================(Build #5133  - Engineering Case #363625)================

	A situation where a client request could have potentially crashed the ISAPI 
	redirector as been fixed.

    ================(Build #5117  - Engineering Case #348166)================

	An application using the DBSynchronizeLog function of the Database Tools 
	interface could have crashed, if the msgqueuertn function pointer in the 
	a_sync_db structure was set to NULL. Now, if the pointer is set to NULL, 
	the function default implementation is to sleep for the requested time period.	

    ================(Build #5117  - Engineering Case #344018)================

	The MobiLink user authentication utility dbmluser would have crashed if it 
	couldn't determine the default collation from the locale setting. The documentation 
	is incorrect, the default collation does not fall back to 1252LATIN1 on single-byte 
	machines and 932JPN on multi-byte machines. The default collation actually 
	would have become 'unknown', (or in some cases 'ISO_BINENG'), which was a 
	collation that dbmluser did not expect. 
	Now the problem in determining the default collation has been corrected, 
	as well as the cause of the crash.



  SQL Remote for Adaptive Server Anywhere - Extraction Utility for Adaptive Server Anywhere



    ================(Build #5530  - Engineering Case #462482)================

	It was possible for stored procedures to be unloaded in the wrong order when 
	using the Unload or Extraction utilities. In situation where an outer procedure 
	called an inner procedure, and the inner procedure returned a result set, 
	if the outer procedure was created first, then calling the outer procedure 
	would have resulted in the error 'Result set not permitted in InnerProcedure'.  
	The problem has now been fixed.  It's important to note that this fix only 
	addresses situations where calling the outer procedure does not result in 
	an error on the original database, but an error is returned when called on 
	the newly rebuilt or extracted database.  If the error is occurring on the 
	original database, then dropping and recreating the outer procedure should 
	fix the problem.



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



    ================(Build #5369  - Engineering Case #421399)================

	It was possible for dbremote to fail to send or receive messages, but no 
	line was written to the SQL Remote log that started with "E", indicating 
	that an error had occurred. This has been corrected so that an error line 
	is now always written to the log after the send or receive of a message fails.
	

    ================(Build #5319  - Engineering Case #397776)================

	When using the FILE based messaging system for SQL Remote, there is a maximum 
	of 47,988 possible file names that SQL Remote will use to generate messages. 
	If all of these file names were already in use, then SQL Remote would have 
	looped forever trying to find a file name to generate a message. SQL Remote 
	will now detect that it has tried every single file name and break out of 
	the loop, reporting that "The maximum number of messages in the messaging 
	system has been reached".  Note that although SQL Remote will now no longer 
	loop infinitely in this situation, to allow for the creation of new messages 
	for this remote user, all the files in the user's inbox may need to be manually 
	deleted, and possibly, the maximum message size increased using the -l switch 
	on the SQL Remote command line.

    ================(Build #5117  - Engineering Case #355574)================

	The SQL Remote Message Agents dbremote and ssremote, the SQL Remote Open 
	Server ssqueue, the Log Transfer Manager dbltm, and MobiLink Client dbmlsync, 
	could have hung when attempting to write a message to the output log that 
	was greater than 64Kb in size. This has now been fixed.



  SQL Remote for Adaptive Server Anywhere - Mapi Messaging for Adaptive Server Anywhere



    ================(Build #5486  - Engineering Case #447602)================

	It was possible for SQL Remote to have generated MAPI messages which were 
	visible in the account's inbox, even if the SQL Remote message link option 
	for IPM_Send had been properly set to FALSE.  The IPM_Send variable was not 
	being properly initialized. This has now been fixed.



  SQL Remote for Adaptive Server Anywhere - SQL Remote Message Agent



    ================(Build #5400  - Engineering Case #430594)================

	If a passthrough session contained "create variable" or "drop variable" statements, 
	it was possible for SQL Remote to crash when applying the passthrough session 
	at the remote database. A case sensitive string comparison for "VARIABLE" 
	was being done, but if a  create or drop variable command was executed in 
	lower case during a passthrough session, the receiving side would fail to 
	find the name of the variable, leading to the crash. The string is now converted 
	to upper case before doing the comparison.

    ================(Build #5311  - Engineering Case #404450)================

	If dbremote were forced to retry an operation that involved a long varchar 
	or long binary, then dbremote would have reported an error in the dbremote 
	log similar to "There is already a variable named 'n1'".  Dbremote will no 
	longer report this error.
	

    ================(Build #5307  - Engineering Case #406125)================

	If the sending and receiving phases of dbremote were being run in separate 
	dbremote processes, and the sending phase was processing a SYNCHRONIZE SUBSCRIPTION 
	request, it was possible for the two phases of dbremote to deadlock, resulting 
	in the sending phase being rolled back. The sending phase of dbremote will 
	now lock all the tables that are about to be synchronized if it detects that 
	the receiving phase of dbremote is also active. If the sending phase fails 
	to acquire the table locks, it will attempt to get the locks 5 times, with 
	a increasing delay between each attempt ( 100ms, 200ms, 400ms, 800ms). If 
	all five attempts to acquire the locks fail, the sending phase will attempt 
	to process the SYNCHRONIZE SUBSCRIPTION without acquiring the locks, which 
	could still result in a deadlock. To further reduce the possibility of deadlock, 
	the receiving phase of dbremote should run with "-g 1" to prevent the grouping 
	of transactions.
	

    ================(Build #5304  - Engineering Case #405375)================

	If the sending phase of the SQL Remote Message Agent was the victim of a 
	deadlock, it could have crashed.  Note that in order for the sending phase 
	of dbremote to have been the victim of deadlock, it would have to have been 
	in the process of satisfying multiple SYNCHRONIZE SUBSCRIPTION commands, 
	and the send and receive phases of would have had to be running on separate 
	dbremote processes.  The Message Agent will no longer crash in this situation, 
	but will now report that the sending of messages has failed and will shut 
	down as expected.
	

    ================(Build #5206  - Engineering Case #376895)================

	When the database option "Delete_old_logs" was set to "on", SQL Remote, (as 
	well as MobiLink, and the ASA RepAgent), may reported "missing transaction 
	log(s)...". This would have occurred in the following situation:
	1) the online transaction that contains the last replication/synchronization 
	offset, had been renamed, say to X;
	2) the offline log X contained transactions that started from an early log, 
	say Y; and
	3) the log Y contained transactions started from an earlier log, say Z.
	Transaction log Z may have already been deleted. This problem is fixed now.

    ================(Build #5166  - Engineering Case #354147)================

	When the log scanning tools were looking for the log file with the desired 
	starting log offset, if that log file had a transaction in it which began 
	in an earlier log file, but the log file that contained the start of the 
	transaction could not be found, an error would have been reported similar 
	to "Missing transaction log(s) in between file AC.log (ending at offset X) 
	and file AD.log (starting at offset Y)".  The offsets reported would have 
	been incorrect, and upon inspection, the ending log offset of AC.log would 
	have likely been the same as the starting log offset of AD.log. The correct 
	error is now reported, "Missing transaction log(s) before file AA.log".
	

    ================(Build #5127  - Engineering Case #360190)================

	SQL Remote (dbremote) may have hung when scanning transaction logs if the 
	server logged a checkpoint that has a previous checkpoint pointing to itself. 
	This problem has been fixed.
	
	Note, this problem also affected Mobilink's Synchroniztion Client and the 
	ASA Replication Agent 



  UltraLite - CodeWarrior plugin



    ================(Build #5423  - Engineering Case #403525)================

	When large databases were synchronized, UltraLite on Palm with the file-based 
	data store, could have become very slow and would eventually time out on 
	conduit synchronization. This has been fixed by allowing users to specify 
	a larger default cache size, which  significantly improves the synchronization 
	time by cutting down file I/Os. 
	
	Now, when the UltraLite conduit is loaded by the HotSync Manager (on the 
	desktop), it attempts to set the cache size using the value "CacheSize" if 
	it is specified in the following registry key: 
	
	Software\Sybase\Adaptive Server Anywhere\&ltversion&gt\Conduit\&ltCRID&gt
	
	where &ltCRID&gt is the creator ID used in an UltraLite Palm application on 
	remote. The size of "CacheSize" is in bytes, or the suffix k or K to indicate 
	kilobytes or m or M to indicate megabytes, can be used. If this value is 
	invalid, it is ignored and the old default cache size of 128KB is used. If 
	the "CacheSize" value is not set, the UltraLite conduit will use the new 
	default cache size of 4MB. 



  UltraLite - HotSync Conduit



    ================(Build #5324  - Engineering Case #409958)================

	When synchronizing with the Palm HotSync conduit, the HotSync connection 
	could have been timed out if the UltraLite application (with record-based 
	data store) required a long synchronization. The error: -309 - 'Memory error 
	-- transaction rolled back' would then be signalled. This has been fixed. 
	Now the worker thread handles all communication between HotSync and MobiLink, 
	which prevents any device timeouts due to the long communication between 
	HotSync and the MobiLink server. 
	
	In addition, the HotSync dialog is now properly updated - the "Exchange" 
	arrows indicator is kept progressing while the connection is kept alive. 



  UltraLite - Runtime Libraries



    ================(Build #5471  - Engineering Case #448760)================

	Several improvements have been made for Palm HotSync reliability and VFS 
	performance as follows:
	 
	- Devices with a sufficiently large heap (RAM) now use a RAM-based cache 
	for VFS file access instead of a storage heap-based cache.
	 
	- A fix has been made to prevent a progress mismatch with MobiLink, if a 
	reset was done at the right moment during a HotSync.
	 
	- A fix has also been made to resolve the problem where the HotSync conduit 
	could have referenced freed memory (likely causing a crash), if the record 
	database on the device was corrupt (missing pages), but caused no I/O errors.

    ================(Build #5363  - Engineering Case #420496)================

	On Palm T|X devices running the latest Palm OS v5.4.9, the OS can leave the 
	record busy bit turned on when the device is reset. This could have caused 
	UltraLite applications to fail on startup in the call ULAppLaunch(). A work 
	around has now been implemented.

    ================(Build #5301  - Engineering Case #401161)================

	UltraLite can now be run on Palm NVFS devices, and it supports both the record-based 
	and file-based data stores. 
	
	The following is a summary of UltraLite clarifications for the Palm OS platform.
	
	A. Database
	An internal file volume may also be present on some NVFS devices, such as 
	Tungsten T5 handhelds, which you can access and use similar to an SD slot. 
	Therefore, call ULEnableFileDB to store UltraLite databases on either an 
	internal drive (built-in storage card) or external slot (expansion card). 
	Furthermore, use the existing connection parameter palm_db=CRID:n to specify 
	the data store on either an internal drive or external slot. n is the volume 
	ordinal from enumerating the mounted volumes, and the default value of n 
	is 0. Tungsten T5, for example, has two volumes, the internal file volume 
	and the SD slot volume. If the device cannot locate a volume with the user-specified 
	volume ordinal, the SQLCODE -82 is reported when opening the database.
	
	B. Synchronization Conduit
	The conduit synchronizes the UltraLite database which is first found on 
	the device. The database lookup sequence is first the record storage, then 
	the file system including internal drive and external slot. Make the UltraLite 
	database which you intend to synchronize available as the first one found 
	in that sequence.

    ================(Build #5198  - Engineering Case #373035)================

	Performing a synchronization that downloaded rows to a table on which a cursor 
	had been opened, could have resulted in the cursor being positioned on an 
	incorrect row following an ABSOLUTE fetch.
	
	UltraLite tries to optimize ABSOLUTE fetches by replacing them with RELATIVE 
	ones (if it thinks it will be more efficient). The algorithm first verifies 
	that no tables in the cursor have been modified, otherwise it does not attempt 
	the optimization. The problem occurred due to the synchronization code not 
	marking the tables as modified.  Now they are.

    ================(Build #5125  - Engineering Case #359409)================

	When a java.sql.Timestamp type value was inserted into a column of type TIMESTAMP, 
	the conversion of the nanosecond portion of the java timestamp to the microsecond 
	portion of the UlDateTime was incorrect. Thus timestamps like 01:20:60 were 
	possible. This has now been corrected.

    ================(Build #5117  - Engineering Case #349254)================

	If a download conflict error occurred during synchronization, the UltraLite 
	application could possibly have crashed at some point in the future.  This 
	has been fixed



  UltraLite - UltraLite Schema Painter



    ================(Build #5189  - Engineering Case #373248)================

	When creating a foreign key with the UltraLite Schema Painter, the table 
	for which the foreign key is being created (the table doing the referencing) 
	was not listed as a table that could be referenced.  This has been fixed, 
	self-referencing foreign keys can now be created.

    ================(Build #5186  - Engineering Case #372513)================

	The UltraLite Schema painter could have crashed when creating a foreign key. 
	This has been fixed.

    ================(Build #5127  - Engineering Case #360361)================

	In some circumstances, the UltraLite Schema Painter would have crashed when 
	browsing the File menu. This has been fixed.
	
	
	The following could have caused this behaviour:
	- Start the UltraLite Schema painter and create a new schema
	- Right click on the schema in the left pane but do not choose any menu 
	items
	- Select the File menu and choose Close (when asked to save, click No)
	- Select the File menu again and move over the items in the menu