Sybase数据库技术，数据库恢复专家

1 - Connected to a database,

2 - Disconnected from the database,

3 - Connected to a different database

From then on, attempting to display the source to any stored procedure usually displayed source for a different procedure. This problem is now fixed.

- at least 2 MobiLink users were defined, say U1 and U2

- at least 2 publications are defined, say P1 and P2

- there existed some operation O, that affected both P1 and P2

- only U1 had a subscription to P1

- only U2 had a subscription to P2

Under these circumstances, if the subscription U1/P1 was synchronized, followed by the subscription U2/P2, then O may have been uploaded for U1/P1 but not U2/P2. This problem is now fixed and did not occur if the -u switch was used to specify the MobiLink user on the dbmlsync command-line.

One of two scenarios may have been seen:

1 - the engine may report a message similar to:

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

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

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

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

For example:

CREATE DOMAIN speed_type INT DEFAULT 50 CHECK (@a < 100);

CREATE TABLE speed_violations (

driver char(40)

speed speed_type );

ALTER TABLE speed_violations MODIFY speed DEFAULT NULL;

ALTER TABLE speed_violations MODIFY speed CHECK NULL;

The reload.sql would not have contained the ALTER TABLE statements to change the DEFAULT and the CHECK. This has been fixed.

- the table contained blobs (binary or character)

- one or more of the blobs (but not all) were NULL

This has now been fixed.

- at least 2 MobiLink users were defined, say U1 and U2

- at least 2 publications are defined, say P1 and P2

- U1 is subscribed to P1. U2 is subscribed to P2. No subscription exists between U1 and P2 or between U2 and P1.

- P1 and P2 both contain a table T1, but with different WHERE clauses or one publication has a WHERE clause and the other does not

- there exists a row R in T1 that satisfies the WHERE clause for P1 but not for P2

- an update operation, O occurs on R and the post-image of the update satisfies the where clause for P2

In this case, when P2 is synchronized, the update operation O would not be converted into an insert and so will be ignored by MobiLink.

- Database recovery was performed at startup.

- The table containing the column was referenced in the transaction log during recovery.

- An INSERT into the table with no value specified for the GLOBAL AUTOINCREMENT column was attempted before shutting down the database.

Note, this same problem affected all of the ASA administration tools -- dbisql, Sybase Central, dbconsole, and the Procedure Debugger.

No off-line transaction log file found an on-line transaction log

starts at offset ...

as dbunload did not save the current transaction log and reset the start and relative log offset in the rebuilt database. This has been fixed.

INPUT INTO dba.myTable FROM myData.dbf FORMAT FOXPRO

it would have incorrectly created a table called "dba.myTable" and incorrectly reported the error:

ASA Error -131: Syntax error near ')' on line

This has been fixed, but a workaround was to remove the owner name prefix from the table name.

The problem occured only with the following file formats: DBASEII, DBASEIII, EXCEL, FOXPRO, LOTUS.

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

"At least one of the dbspaces was not calibrated."

and could also have failed to calibrate some dbspaces. This problem is now fixed. The above error is still issued if one of the dbspaces being calibrated is smaller in size than the threshold value of 800 pages.

"Illegal cursor operation attempt"

which was not helpful. This has been fixed, dbunload will now display the error message

"Table 'viewname' not found" in these cases as well.

then modified rows in the Ultralite client would never have been uploaded. In this

case synchronization would have continued and no error was reported. These problems are now fixed.

An Ultralite database may be reset by deleting the persistent store, or by

changing the sync user name.

Example:

rc = SQLDisconnect( hdbc );

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

/* get the error message */

create table case_null( pk int primary key, c1 int, expected char(10) );

insert into case_null values (1,1,'one');

insert into case_null values (2,2,'two');

insert into case_null values (3,3,'other');

insert into case_null values (4,null,'other');

commit;

select

c1,

case c1

when 1 then 'one'

when 2 then 'two'

else 'other'

end as rslt,

expected

from case_null;

"Error in file sybprc50.sql at line 2473 with sqlcode -131

SQL error (-131) -- Syntax error near '' on line 62

This has been fixed

is "Database creation failed Collation "name" not found".

Select * from sales_order where order_date = 19931010

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

- the database was using a multibyte collation

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

- the client application issueed a describe cursor request

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

select *

from R R1

join

( select R2.y, max(R2.x-1)

from R R2 join R R3 on R2.y=R3.y

where R2.x-1>0

group by R2.y ) DT(gb,mx)

on R1.y = DT.gb

where R1.x < 5

SELECT e.emp_id into #temp

FROM dba.employee e

WHERE e.emp_id IN

( SELECT o.sales_rep

FROM dba.sales_order o

WHERE o.sales_rep = 299

);

is rewritten as:

SELECT DISTINCT e.emp_id into #temp

FROM dba.employee e, dba.sales_order o

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

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

Select *

From Product

Where id < 601 or id = 601

would have resulted in the second predicate being dropped from the query altogether; hence the product row with id 601 would not have appeared in the result set. This is now fixed.

Also, the default x86em UltraLite runtime has been changed from emulator to emulator30. The x86em target of CustDB should compile and link without requiring any changes with Pocket PC, but when linking for Windows CE 2.11, the link settings must be manually changed to link against the UltraLite runtime in the emulator directory instead of emulator30.

( x BETWEEN y AND z, 10.0)

where 10.0 was user estimate of the selectivity of the BETWEEN predicate, the server would ignore the supplied estimate and revert to the built-in default. Further, if a query contained a predicate of the form:

(x >= 10, 5.0) AND x <= 11

the user estimate of 5.0 would again be ignored by the server. This has been fixed.

These problems have been fixed.

abs(cast(65535 as unsigned smallint))

returned 1 instead of 65535. The correct value (65535 in this example) is now returned.

Updating a row could have failed, (the row was silently rolled back), if either

a) The table had no primary key and at least one TIME or TIMESTAMP column, or

b) There was a primary key, and one or more of the key columns was a TIME or TIMESTAMP

Deleting under these circumstances is not supported. The user is now notified that the update has failed in these cases.

Updating a row would have failed, (the row was silently rolled back), if the result set contained a TIME or TIMESTAMP column, even if that column was not in the primary key. The row is now correctly updated.

Deleting a row could have failed, (the row was silently rolled back), if either

a) The table had no primary key and at least one TIME or TIMESTAMP column, or

b) There was a primary key, and one or more of the key columns was a TIME or TIMESTAMP

Deleting under these circumstances is not supported. In these cases, the row had been removed from the result table in the "Results" pane even though it had not actually been removed from the database. The row is now left in the "Results" table and the user is notified that the row was not deleted.

Note that if the corresponding file or directory name text field is not empty, then the chooser will attempt to open at the directory contained in the text field.

returned on a fetch.

create trigger trig1 before update on T1

// referencing old as oldname -- missing definition

referencing new as newname

for each row

begin

if oldname.col1 > newname.col1 then

message 'Test'

end if;

end

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

- the prepared statement used to open the cursor was dropped

- the cursor was reopened

- the connection was disconnected

Now this memory is freed immediately on the cursor close.

For example, the following would incorrectly return 0:

create variable v1 java.lang.Object;

create varaible v2 java.math.BigDecimal;

set v1 = new java.math.BigDecimal(12);

set v2 = new java.math.BigDecimal(12);

select count(*) as cnt from sys.dummy where v1=v2

However, the following query would correctly return 1:

select count(*) as cnt from sys.dummy where v2=v1

This error could have caused database recovery to fail if a column declared as java.lang.Object appeared in a table without a primary key. This is now fixed.

- Less-than sign (<)

- Greater-than sign (>)

- Ampersand (&)

- Apostrophe (')

- Quotation mark (")

the SQL Statement field would have contained the XML escape sequence corresponding to these characters, rather than the characters themselves. Here are the escape sequences:

- Less-than sign (<)

- Greater-than sign (>)

- Ampersand (&)

- Apostrophe (')

- Quotation mark (")

Now the SQL Statement field contains what it did when the plan for the statement was created (i.e. the actual characters appear rather than their escape sequences.)

Eg:

CALL sa_eng_properties;

OUTPUT TO props.xls FORMAT EXCEL

This is now fixed.

C API: ul_bool ULGetSynchResult( p_ul_synch_result );

C++ API: bool ULConnection::GetSynchResult( p_ul_synch_result );

A new struct has also been created to store these results:

typedef struct {

an_sql_code sql_code; // synchronization sql code

ul_stream_error stream_error; // communication stream error info

ul_bool upload_ok; // TRUE if upload worked

ul_bool ignored_rows; // TRUE if uploaded rows were ignored

ul_auth_status auth_status; // authentication status

ul_s_long auth_value; // actual value by mobilink

// to determine auth_status

SQLDATETIME timestamp; // timestamp of the last synch

ul_synch_status status; // status info used by observer function

} ul_synch_result, * p_ul_synch_result;

An application must allocate a ul_synch_result object before passing it to ULGetSynchResult, which will fill it with the result of the last synchronization. These results are stored persistently in the database.

SELECT <col-list>

FROM <single table>

WHERE <column> = <constant> [AND ...]

if the constant did not have the same domain as the column, then the engine could have returned an error (could not convert <constant> to ...), returned rows that did not match the search condition, or it could have failed to return rows that would normally be returned.

For example, the following query:

select *

from department

where dept_id=100.1

would have returned the row with dept_id=100. Before the fix, the constant was always converted to the domain of the column, and the comparison was performed in the domain of the column. If the constant could not be converted to the domain of the column (for example, comparing a smallint column to 60000), then a conversion error was generated. If a numeric constant was compared to a string column, the number was converted to a string and compared lexically; the correct behaviour should convert the string column to a numeric type for comparison to the number.

This incorrect behaviour only occurred if the query was simple enough to bypass optimization (see the QueryBypassed property). Queries containing features such as joins, grouping, and complex search conditions would not be affected by this issue.

In cases where the constant can not be converted to the column domain without loss of precision, both the column and constant are now converted to a common comparison domain, and the comparison is now performed in the comparison domain. In this case, an index can not be used to satisfy the search condition.

"ScriptsVersion" or "SENDCOLUMNNAMES".) This problem has been corrected.

Note that since any settings made on the property have always used lowercase option names, this problem would only appear if an option was set by some means other than the property sheet; for example, using the "CREATE SYNCHRONIZATION SUBSCRIPTION" statement.

In addition, the Apply button is no longer displayed when a Column property sheet is opened from inside the Table Editor, since any changes made from a Column property sheet are actually applied when the Table Editor's Save menu item or toolbar button is clicked.

select @var=x

from T

where exists(...)

This is now fixed.

dblibtm.lib(sqlcadat.obj) : fatal error LNK1202: "<path>\vc60.pdb" is missing debugging information for referencing module.

The library dblibtm.lib has been fixed so that the link error no longer occurs.

- the first timestamp was later than the second timestamp

- the microsecond components of the two timestamps were not equal

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

For example:

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

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

Similarly, schedules defined using short-form English day names would not have been understood by a server running with a language other than English. Full-length English day names are recognized regardless of the language used by the server.

NOTE: The iAnywhere branded DataDirect driver for ASE rely on a stored procedure called sp_tables. This stored procedure was not in the GA version of ASE 12.5. Brining ASE up to a SWR of 10242 will reintroduce the sp_tables stored procedure.

1. Some operation (insert,update or delete) was applied to R outside of a trigger.

2. An operation was applied to R from inside a trigger.

3. Another operation was applied to R outside of a trigger.

When dbmlsync encountered one of these unsupported combinations it would abandon synchronization and display a message box with the title "Assertion Failure" and text similar to "file dbtools\.\mergeupd.c at line # ????".

These cases are now correctly handled by dbmlsync and this message should no longer appear.

For example:

select top 1 * from employee order by emp_fname

would have appeared to return no rows in dbisqlc.

select truncnum(1.23,3)

This is now fixed, but a workaround is to cast the first argument to have a higher precision. For example:

select truncnum(cast(1.23 as numeric(5,2)),3)

For example, the following query returned an incorrect answer before this fix:

select if dept_name like dept_name then 1 endif

from department

order by dept_name

for update

(the for update clause is used to force a keyset driven plan).

This problem is now fixed.

create table dateTable(

id int not null primary key,

dateCol date );

create PROCEDURE dba.Test()

BEGIN

select id, dateCol from dateTable;

END;

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

A problem could have appeared any time an alias was defined in one context and used in another (where possible contexts are inside and outside an aggregate function, in the select list, in the WHERE clause, in the HAVING clause, and in the ORDER BY clause).

For example, the query

select max(e), emp_id e from employee

did not return an error, although it should have because emp_id appears in the select list but not the GROUP BY clause. Errors are also not returned in most cases involving views or derived tables. For example, the query

select tname, List(distinct cname)

from sys.syscolumns

where tname = 'systable'

should have returned an error because tname does not appear in the GROUP BY clause.

Problems could also have occurred when an expression was formed from GROUP BY elements without exactly matching one, or when subselects were aliased and used in the WHERE clause of a grouped query. In general, any grouped query using aliases, views or derived tables was suspect. These problems are now resolved

call ul_add_statement( 'custapi', 'Bogus', 'SELECT cust_id, cust_name, bogus_col_name FROM ULCustomer WHERE cust_name LIKE ?' )

would have resulted in the error: invalid expression near 'select ulplan(@statement)', which was not very informative. The message now indicates that the column bogus_col_name does not exist.

The sequence of actions to reproduce the problem were:

1. Display the graphical plan for any query

2. Click on the text field which makes up the right half of the graphical plan viewer.

3. Press the F12 key to disconnect from the database.

4. Press F11 to connect to the database. DBISQL would report an internal error.

create procedure sybprob001() as

begin

declare @error_var int,

@rowcount_var int,

@table_name varchar(256)

select @table_name = table_name

from sys.systable

where table_name like '%blah%'

select @error_var = @@ERROR, @rowcount_var = @@ROWCOUNT

message 'error_var should be 0, is ',@error_var

message 'rowcount_var should be 0, is ',@rowcount_var

end;

call sybprob001();

This problem is now fixed. If only a single variable assignment was made, the value would have been correct.

1. Primary key was a trie-based index

2. Keyset driven cursor was used (possibly because of a DELETE with a self-referencing table)

3. Rows were deleted from the base table after the keyset table was populated

At this point, the server could have attempted to delete rows that are not in the base table.

1) the last log operation in the latest offline transaction log was a "Commit"; and

2) in the online transaction log, there was no actual data to be uploaded or replicated.

This problem is now fixed.

create procedure DBA.test()

result(xlicencas integer)

begin

declare xLicencas integer;

declare xConnection integer;

set xConnection=(select NEXT_CONNECTION(null,null));

set xLicencas=34;

select xLicencas

end

The "set xConnection=(select NEXT_CONNECTION(null,null));" line would have caused the result set of "select xLicencas" to be dropped by the client. This problem has now been fixed.

-727 "The optimizer was unable to construct a valid access plan"

These types of queries can appear when no join conditions are specified between tables. For example, the following query would have given the error as the result of the FROM clause is 10^40 rows:

select * from TBig0 T0, TBig1 T1, TBig2 T2, ...., TBig20 T20 where 1=2

if table TBig<n> had 100 rows or more.

These types of queries are generated by some applications to collect schema information before posing a query with an actual WHERE clause

was never displayed on the Connections page of the object's property sheet. Now, 'use_cookies' and any other advanced connection settings are displayed in an 'Advanced parameters' text field on the Connection page of the object's property sheet, and this value is retained when changes to the object are saved.

SELECT ( SELECT 1 FROM sys.dummy D1 WHERE R.row_num IS NOT NULL ) AS A1

FROM dbo.rowgenerator R

WHERE ( SELECT 2 FROM sys.dummy D2 WHERE A1 IS NOT NULL ) IS NOT NULL

For example:

create table table1(c1 char(6) primary key);

insert into table1 values('Austra');

select * from table1 where c1 = 'Australia';

would have returned 1 row when none should have been returned.

For the problem to have occurred, a column must have been searched for a value 'xxxyyy', where 'xxxyyy' truncated to the width of the column was 'xxx' and 'xxx' appeared in the column, (this could have affected non-string columns as well). Moreover, the index must have been fully hashed. This is now fixed.

If verbosity is turned on, then informational messages will be generated that indicate the number of not found delete's encountered for each table and which rows they were for.

-- START OF SCRIPT

insert into dbo.EXCLUDEOBJECT values ( 'xp_real_stopmail' , 'P' )

go

insert into dbo.EXCLUDEOBJECT values ( 'xp_real_startmail' , 'P' )

go

insert into dbo.EXCLUDEOBJECT values ( 'xp_real_sendmail' , 'P' )

go

CREATE function dbo.xp_real_startmail(

in mail_user char(254) default null,

in mail_password char(254) default null,

in connection_id int )

returns int

external name 'xp_startmail@dbextf.dll'

go

ALTER function dbo.xp_startmail(

in mail_user char(254) default null,

in mail_password char(254) default null )

returns int

begin

declare connection_id int;

select connection_property( 'Number' ) into connection_id from dummy;

return( xp_real_startmail( mail_user, mail_password, connection_id ) )

end

go

CREATE function dbo.xp_real_stopmail( in connection_id int )

returns int

external name 'xp_stopmail@dbextf.dll'

go

ALTER function dbo.xp_stopmail()

returns int

begin

declare connection_id int;

select connection_property( 'Number' ) into connection_id from dummy;

return( xp_real_stopmail( connection_id ) )

end

go

CREATE function dbo.xp_real_sendmail(

in recipient char(254),

in subject char(254) default null,

in cc_recipient char(254) default null,

in bcc_recipient char(254) default null,

in query char(254) default null,

in "message" char(254) default null,

in attachname char(254) default null,

in attach_result int default 0,

in echo_error int default 1,

in include_file char(254) default null,

in no_column_header int default 0,

in no_output int default 0,

in width int default 80,

in separator char(1) default '\t',

in dbuser char(254) default 'guest',

in dbname char(254) default 'master',

in type char(254) default null,

in include_query int default 0,

in connection_id int )

returns int

external name 'xp_sendmail@dbextf'

go

ALTER function dbo.xp_sendmail(

in recipient char(254),

in subject char(254) default null,

in cc_recipient char(254) default null,

in bcc_recipient char(254) default null,

in query char(254) default null,

in "message" char(254) default null,

in attachname char(254) default null,

in attach_result int default 0,

in echo_error int default 1,

in include_file char(254) default null,

in no_column_header int default 0,

in no_output int default 0,

in width int default 80,

in separator char(1) default '\t',

in dbuser char(254) default 'guest',

in dbname char(254) default 'master',

in type char(254) default null,

in include_query int default 0 )

returns int

begin

declare connection_id int;

select connection_property( 'Number' ) into connection_id from dummy;

return( xp_real_sendmail( recipient, subject, cc_recipient, bcc_recipient, query, "message", attachname,

attach_result, echo_error, include_file, no_column_header,

no_output, width, separator, dbuser, dbname, type,

include_query, connection_id ) );

end

-- END OF SCRIPT

-853 "Cursor not in a valid state"

This is now fixed, but a work-around would be to set the database option Max_plans_cached to 0.

select * from systable where table_id > 30 order by table_id desc

The server would have executed this query by performing a backward primary key index scan of systable as desired, but then also would have sorted the result set on table_id. The sort operation was not needed because the result set was already in the proper order due to the index. Now the server will no longer execute this unnecessary sort, resulting in improved performance.

"Invalid option '%1' -- no PUBLIC setting exists"

This was incorrect and confusing. Now the following error occurs:

"Cannot unset PUBLIC option '%1' since user settings exist"

SELECT test.errorfield, test.keyfield

FROM test

WHERE

test.errorfield = '001DUQVPYNM'

AND ( test.field1 <> 'd'

AND test.field1 <> 'D'

AND test.field1 <> 'd'

AND test.field1 <> 'D'

AND (( test.field6 = '1') OR ( test.field6 = ' '))

AND (('2002-07-12' <= test.field5 OR test.field5 = '1800-01-01' )

AND('2002-07-12' >= test.field4 OR test.field4 = '1800-01-01' ))

AND test.field2 = '001'

AND test.field3 = '01')

would be incorrectly simplified to

SELECT test.errorfield, test.keyfield

FROM test

WHERE

(( test.field6 = '1') OR ( test.field6 = ' '))

AND (('2002-07-12' <= test.field5 OR test.field5 = '1800-01-01' )

AND('2002-07-12' >= test.field4 OR test.field4 = '1800-01-01' ))

This has been corrected.

-142 "Correlation name '%1' not found"

For example, the following query demonstrates the behaviour:

select rowid(#temp)

into #temp

from sys.dummy

Error: getFillDictEntrySQL() An input entry has not been set

when a log offset mismatch occurred between the remote and consolidated databases or if an error occurred during the upload phase of synchronization. This was an internal error message and should never be seen by users. The success or failure of synchronization was not affected by this message. This problem is now fixed and the message should no longer appear.

1. Indicator variables used in a fetch on a non-nullable column type were ignored. For all other domain types, UltraLite would always set the indicator variable properly, even if the column was declared as not null.

2. If the destination buffer for a wide character strings was too small and the value needed to be truncated, the resulting string would not be null-terminated. Now the UltraLite runtime will remove one more character to make room for the null character at the end.

Note that UNC addresses are only valid on NetWare if the server matches the name of the server on which dbremote is running.

"Internal database error *** ERROR *** Assertion failed in f:\src\db\engine\language\parser\copytree.c at line 616 (Parser assertion: Subqueries not copied during copy_with_annotation)

The following queries are examples that caused the problem:

CREATE TABLE X( ( table_name varchar(50), publication_name varchar(50));

SELECT table_name

FROM X

WHERE table_name NOT IN (SELECT foreign_tname FROM SYSFOREIGNKEYS)

(Note: SYSFOREIGNKEYS contains a subselect for column 'columns', which is not used)

SELECT table_name

FROM X R1

WHERE table_name NOT IN

( SELECT col1

FROM ( SELECT table_name col1,

( SELECT table_name

FROM X R2 ) col2

FROM X R3

) DT

)

The error would not have appeared if the select list item for the ANY/ALL predicate was a not-null column, nor would it have occurred if the subselect column was used in the ANY/ALL subquery. This has now been fixed.

This problem was most likely to occur when a view was used which contained a number of subqueries.

1 - single-line comments which did not end in a carriage return, line feed, or carriage return/line feed pair would have been corrupted before being sent to the database server.

For example, running:

dbisql -q -d1 "message 'X' -- testing"

would have printed

message 'X' -----------

instead of

message 'X' -- Testing

2 - if the "d1" command line option was specified, and the file started with a comment, that comment was displayed twice on the console. Now the comment is displayed only once.

3 - comments appearing within CREATE PROCEDURE or CREATE FUNCTION statements were being sent to the database server followed by an additional blank line. This extra blank line has now been removed.

( <page-size> - 128 ) / 8

If an expression was built with more arguments than this limit, the assertion:

101515 "Memory allocation size too large"

would fail.

A large number of arguments can be supplied to some built-in functions such as coalesce, ifnull, and so on, or to user functions. Further, when building an IF or CASE expression, the engine builds an expression that has as arguments all of the expressions used in predicates in the IF or CASE condition. If any expression was built with many arguments, the above assertion would fail.

After the fix, we give a syntax error:

-156 "Invalid expression near '%1'"

for an expression with too many arguments. Further, constant expressions are no longer included in the special argument to IF and CASE expressions.

1) Dbmlsync was run so that it completed more than one synchronization of the same publication before it shut down. This could have happened when scheduling options were used or if the restart parameter in the sp_hook_dbmlsync_end hook was used to restart a synchronization.

2) An error occured during the upload phase of synchronization, after which another synchronization attempt was made.

3) Log scan polling was enabled. This is the default, logscan polling can be disabled using the -p command line option or the DisablePolling extended option.

4) The -n command line option had only been used once on the command line.

5) There was no publication not specified with the -n switch that included part of a table that was also included in a publication specified with the -n switch.

This problem has been corrected.

1 - Column statistics (i.e., histogram) could have contained inaccurate selectivities after a frequency value was added in the middle of an existing range,

2 - Column statistics generated by LOAD TABLE could have contained inaccurate selectivity estimates in some situations,

3 - The server will now do a much better job of estimating join selectivities where the join attributes include columns that contain nearly unique data values, but are not declared as UNIQUE

4 - The server will now generate better selectivity estimates for columns that have no histograms, e.g., because the number of rows in the table is too small.

ALTER INDEX indexname rename-spec

ALTER [INDEX] FOREIGN KEY rolename rename-spec

rename-spec:

ON [ owner.]tablename RENAME [ AS | TO ] newname

the new database matched the maximum user_id in the old database (and executed a

RAISERROR 17001 if they were different) has been removed.

1) the maximum number of open file descriptors allowed by the OS, and

2) the available memory on the machine

As a side affect, threaded client libraries no longer uses SIGIO for event notification. Non-threaded UNIX clients still depend on SIGIO for TCP/IP I/O event notification.

If the number of connections is expected to exceed 1024, then it's

recommended to increase the liveness period from the default value of 120.

- a rollback of a subtransaction

- a rollback to a savepoint

- a failed DML statement

- a cancelled statement (the undo actually occurs just before the next statement on that connection is executed).

A rollback of a full transaction was not affected by this problem. Checkpoints are now prevented during undo operations.

select cast( rolf(c1) as float) into #temp from t1;

The function rolf, that returns a double, would have been processed in full passthrough mode, instead of no passthrough. This problem has now been fixed.

- The query contains an ORDER BY clause of the form col1, col2, ...., expr1, expr2

- There exists an index IDX matching (col1, col2, ... ) (i.e., only a prefix of the ORDER BY clause is matched by an index)

- There exists a WHERE equality predicate on at least one of the IDX columns

- The best plan chooses the index IDX as an access method

Example:

SELECT T.Y, R.Z

FROM T, R

WHERE T.X = 1 AND R.Z = T.Z

ORDER BY T.Y, R.Z

where the table T has an index IDX on (T.X, T.Y )

This is now fixed.

The usage text for "-d" on Netware has been changed to "use POSIX I/O". The usage text for "-d" on Windows has been removed, but the option is still allowed on the command line and will continue to be ignored.

For example:

call myproc(coalesce(null,(select 1)))

A syntax error will now be generated for all subqueries used as any part of a procedure argument. To pass a subquery to a procedure, assign the subquery result to a variable and pass the variable to the procedure.

For example, after running the following SQL code:

create table foo ( c1 int primary key );

insert into foo values (1);

insert into foo values (3);

create statistics foo;

delete from foo where c1 < 2;

the foo.c1 histogram ( displayed by "call sa_get_histogram( 'c1', 'foo' )" ) would have incorrectly reported the selectivity of values between 1 and 3 to be 0.7. This issue has now been fixed.

f( g( R.x ) ) = T.x

could have caused the server to crash or give wrong results, if the value g( R.x ) was used above the join.

For example, the following query caused the problem:

select right( left( R1.z, 10 ), 1 ), 1

from R R1, R R2

where left( left( R1.z, 10 ), 6 ) = R2.z

and (R1.x+1 > 0, 0 )

for read only

This is now fixed.

For example :

SET REMOTE file OPTION "public"."unlink_delay" = '10';

Dbremote will pause 10 seconds before attempting to delete the message again. The number of attempts made to delete the file (five) has not changed.

out (via the database's "Filter Objects by Owner..." menu item) are not displayed, nor are their tables.

The wizard can now be used to unload and reload into an existing database as well. Sybase Central must be connected to both databases to use this feature. A connection to another database can be made from within the wizard, in the event that the wizard was started before establishing a second connection.

In addition, several changes have been made to streamline the unload process. The wizard now only asks for a reload file if needed (as opposed to unloading and reloading into a new or existing database), and only asks for a unload directory if table data is also being unloaded. The wizard only asks whether to use an internal or external unload and reload if it is unloading into a reload file. If reloading into a new database, internal unload and reload are used. If reloading into an existing database, internal unload and reload are used if both databases are running on the same server and have the same character sets; otherwise, external unload and reload are used.

Finally, the Extract Database wizard has also been extended to support the above features, with the exception of extracting a subset of tables, since normally all tables referenced in publications belonging to a particular remote user will be extracted.

For example, the following update would have caused the issue:

create table compute_test (

id char(10),

name char(40),

compute_name char(40) compute(name)

);

insert into compute_test(id,name)

select 'dba', 'test2'

from compute_test T

where 0 = ( select count(*) from sys.dummy where T.id=current publisher );

In addition to having the subquery appear explicitly in the update or insert statement, the problem could also have occurred if a publication referenced a column of the table.

This has now been fixed.

GRANT CONSOLIDATED TO u1,u2 TYPE FILE ADDRESS 'u1','u2';

This command now returns an error.

In some Java UL applications like CustDB, the program obtains a JDBC connection to the local database through JDBC URL and database driver. No instance of JdbcDatabase will be created inside the scope of application program (it is automatically created in the scope of runtime code). In situation like this, many methods defined in JdbcDatabase cannot be called. Methods most likely to be called include user authentication methods 揼rant()�, 搑evoke()�, and synchronization status methods 揼etLastDownloadTimeLong()�, 揼etLastDownloadTimeDate()�, 揷ountUploadRows�. These methods should be defined in the JdbcConnection class as well.

揼etLastDownloadTimeCalendar()� should be dropped because Calendar is an abstract class in Java. The correct way for users to access a timestamp is through the Date class.

For example, the following should both return 1000.000:

SELECT round(1232.955,-3)

SELECT round(953.343,-3)

The second returned an error since it required a larger precision.

Now, the precision of the result is adjusted. A workaround is to cast the first argument to have a larger precision:

select round( cast(953.343 as numeric(7,3)),-3)

In normal usage, the first argument would be a column or variable with a sufficiently large precision.

Added: property( 'LicensesInUse' )- determines the numbers of "seats" or "concurrent users" currently connected to the network server. Each "seat" or "concurrent user" is determined by the number of unique client network addresses connected to the server, not the number of connections. For example, if three client machines are connected to a server, and each client machine has two connections, select property( 'LicensesInUse' ) is '3'.

Corrected: property('ProcessCPU') - now correctly returns the total process time in seconds. It was incorrectly returning two times the property('ProcessCPUUser') on Windows platforms.

Corrected: db_property('IdleCheck'),db_property('IdleChkpt') and statistics "Idle Actives/sec" and "Idle Checkpoints/sec" - now return correct values (before they always had values of 0)

- there was a local predicate referencing only the view in the WHERE clause of the main query block and this predicate was not null-rejecting (for example, "View.column is null").

- the view or derived table could not have been flattened (e.g., it is a grouped view, or it contains an UNION)

- the OUTER join could not have been transformed into an inner join

Example:

SELECT * FROM employee a

LEFT OUTER JOIN

(

SELECT * FROM employee

UNION

SELECT * FROM employee

) b

ON (a.emp_id = b.emp_id)

WHERE b.emp_id IS NULL

This is now fixed.

1. the "-odbc" option was used, and

2. connection was to the default local server, and

3. no data source was specified a in the connection parameters

This is now fixed.

.

In this case, DBISQL would open the "Connect" dialog from which you could successfully log in.

the -gm switch, and has nothing to do with licensing.

This response time has been improved (although a delay is still noticeable) and the performance no longer degrades with repeated selections.

Unable to find log offset ...

Error processing log due to missing log(s)

Dbunload did not save the current transaction log and reset the start and relative log offset in the rebuilt database. This has been fixed.

Also with this change, the minimum AWE cache size has changed from (3GB-256MB) to 2MB. It is recommended, however, that a traditional cache be used if a traditional cache of the desired size can be allocated. Recall that AWE caches do not support dynamic cache sizing and that AWE cache page images are locked in memory and therefore they cannot be swapped out if memory is needed by other processes in the system.

"Feature 'remote savepoints' not implemented"

and failed the synchronization. This case is now detected and silently worked around.

To address this issue, the sys.dummy table is now implemented in a manner that bypasses the latch on the table page. This is only possible because the dummy table has known contents which can not be modified. Further, the sys.dummy table no longer appears in Lock nodes in the graphical plan, and if only the sys.dummy table is present, a Lock node may now be omitted where it was previously required.

emp_lname like 'SI%'

then the optimizer will add additional predicates:

emp_lname >= 'SI' AND emp_lname < 'SJ'

Note that the last character, 'I', has been incremented to the next character in the collation; in this case, 'J'.

For prefix strings that consisted only of the last character of the collation sequence (for example, 'Z'), the server did not form the incremented prefix, did not form the upper bound for the column and the lower bound was not included. Because of this, an index would not be used for the column. Now, for conditions of the form:

emp_lname like 'ZZ%'

the lower bound will be added by the optimizer as follows:

emp_lname >= 'ZZ'.

An index will be selected for this column, if it would have been used for the added range predicate.

Note that conditions such as "emp_lname LIKE 'SZ%'" are treated by adding:

emp_lname >= 'SZ' AND emp_lname < 'T'

and can use an index before and after this change.

This situation can be detected by higher-than expected running times combined with a larger than expected CacheReadIndLeaf property (the 'Cache Reads: Index Leaf' performance counter).

Example:

select DISTINCT T.y

from T

where T.x > 100

order by T.x

If an index scan was used for the table T (the index on T.x) and DistinctHash was used, the result may not have been sorted. This is now fixed.

SELECT *

FROM T

WHERE T.x = ?

would not have used an index on T.x, if the value of the host variable was NULL. In order for this issue to appear, the query must have been sufficiently simple to bypass optimization. For example, it must have contained only one table with no aggregates nor disjuncts.

The predicate T.x = ? will match no rows if the host variable is NULL. While no rows were returned before this change, a complete sequential scan of the table was performed. This scan is not longer done. Further, the graphical plan would not have shown the sequential scan in this case, as the graphical plan does not use the optimizer bypass.

SELECT CASE dummy_col WHEN 0 THEN 'Q1' WHEN 1 THEN 'Q2' END from dummy

GROUP BY CASE dummy_col WHEN 0 THEN 'Q1' WHEN 1 THEN 'Q2' END;

This has been corrected.

Certain errors such as 1450 and 1453 can (apparently) be reported by NT during "normal" operation. The server now retries IOs that fail with one of these particular error codes up to 100 times. If the IO does not succeed after 100 attempts, the server will now report the error as a fatal error (same message as before). It is impossible to know whether 100 attempts will give the OS sufficient time to remedy whatever problems it is having.

It is believed that the OS reports these errors when available memory is low. A work around may be to ensure that the system is not low on memory.

This has been fixed, the parameter names are now unique.

in the following example:

create table dbtran_T1(

pk integer not null,

c1 varchar(100) null,

primary key(pk)

)

INSERT INTO dbtran_T1

VALUES (1,'rm1')

INSERT INTO dbtran_T1

VALUES (2,'rm2')

COMMIT WORK

would very likely have caused dbisql to crash or silently exit. This problem has now been fixed.

There was an error reading the results of the SQL statement.

The displayed results maybe incorrect or incomplete

The same result set does not give an error in dbisqlc.

turns the netwark server into a personal server, without the personal server limitations(i.e. no connection limit, no two CPU limit, etc.)

create table table1 (col1 int, col2 int, col3 int );

create view v1 as

select col1, col2, col3 from table1;

alter view v1 (col1) as

select col1, col2, col3 from table1;

The ALTER VIEW statement included a column list for the view which did not match the SELECT list. An error is now reported.

This is now fixed with the 8.0.2 patch, but a work around would be:

In the maintenance install directory, copy the file 'encryption_ml' in the 'files' directory to 'encryption' and rerun the install. This will ensure that the encryption libraries get updated. A regular 8.0.1 EBF can be applied to the updated 8.0.0

install.

For example, the statement below would not have executed:

CREATE PROCEDURE test AS

BEGIN

-- "a

-- ?

END

This problem, which is related to issue 217915, has been fixed.

A workaround is to add the macro:

#define UL_STR_CHAR_DOUBLE( l, dst, s1 ) \

ULStr( UL_STRING(dst), s1, (ul_s_long)10, (ul_s_long)0 )

to the user抯 ulprotos.h file. This workaround only works if both optional parameters to the function are omitted.

This property can be used in combination with QueryCachePages, QueryOptimized, QueryBypassed, and QueryReused to help determine the best setting for the MAX_PLANS_CACHED option.

For example:

select 0-1; ---> gives 1 incorrectly

select 0.0-1.0; ---> gives 1 incorrectly

Now the correct answer is returned.

Code, such as the following, can be used to explicitly set the floating point control word:

const

MCW_EM = DWord($133f);

begin

Set8087CW(MCW_EM);

end;

MESSAGE ... TYPE WARNING TO CLIENT

statements, dbisql may not have displayed the messages in the correct order. For example, when executing the following compound statement:

begin

message 'one' type warning to client;

message 'two' type warning to client;

end

message "two" would have displayed before the message "one". This problem has been fixed.

Note that the end-of-file character is optional in script (.SQL) files.

Assuming that no -cl parameter was specified when starting a server:

1) Prior to this change, if -c was specified, a Windows server would set the min cache size to be the same value as the -c value (i.e. the same as the initial value) whereas a UNIX server would make the min cache size 2MB. This change makes all platforms use the Windows behaviour in this situation: min cache size is the same as the initial cache size.

2) Prior to this change, if _no_ -c was specified, the initial cache size is computed by the server to be an appropriate size based on the size of the database(s) being started. A Windows server would use this initial cache size value as the minimum cache size, whereas a UNIX server would make the min cache size 2MB. This change makes all platforms set the minimum cache size to a platform-specific minimum value as follows: CE: 600K, all other Windows platforms: 2M, all UNIX platforms: 8M

forward to SOME_REMOTE_SERVER;

select * from systable; ===> CRASH

Whereas the following:

forward to SOME_REMOTE_SERVER {select * from systable}

was not a problem. This has now been fixed.

For example, the following query would not have updated the selectivity of column T.x nor T.y.

SELECT *

FROM T

WHERE T.x = 1 OR T.y = 2

Note that only the first predicate that is evaluated for a given table can be used to reduce the selectivity estimate for a condition, but any predicate can raise the estimate.

Now xp_startmail, (as well as xp_sendmail and xp_stopmail), returns one of

the following:

Value Description

0 Success

2 xp_startmail failed

3 xp_stopmail failed

5 xp_sendmail failed

11 Ambiguous recipients

12 Attachment not found

13 Disk full

14 Failure

15 Invalid session

16 Text too large

17 Too many files

18 Too many recipients

19 Unknown recipient

20 Login failure

21 Too many sessions

22 User abort

23 No MAPI

24 xp_startmail not called (xp_sendmail and xp_stopmail only)

The new statistics will persist in SYSATTRIBUTE in the form of one row for each statistics for an index. The rows in SYSATTRIBUTE will only be created when required, e.g., a row for index depth will be created only when the index depth increases to 2. The statistics will be maintained for all indexes including those on catalog tables. Also, the VALIDATE statement will now verify that the statistics on the specified index(es) are accurate and will generate an error otherwise.

102300 (8.0.1.3067) File associated with given page id is invalid or not open

select DT.TID

from sys.syscolumn C,

( select T.table_name, max( table_id ) TID

from sys.systable T

group by T.table_name

) DT

where C.column_name = DT.table_name

group by DT.TID

In order for the problem to have occurred, an intervening work table must have appeared between the first GROUP BY clause and the second. THis has now been fixed.

"E:\test\{test}\sample.db"), applications using dblib or odbc could not have autostarted it. This has been fixed. Note that starting a server directly on the file (eg. dbeng8 E:\test\{test}\sample.db) was not a problem.

extern void SQL_CALLBACK MessageDBRequest(

SQLCA * sqlca,

unsigned char msg_type,

an_SQL_code code,

unsigned short length,

char * msg );

DELETE FROM t1 A FROM t2 WHERE A.c1 = B.c1

where both t1 and t2 were remote tables, would have caused the statement to be passed to the remote server, instead of being rejected immediately. This problem has now been fixed.

DBBACKUP -r -n

or

BACKUP DATABASE DIRECTORY 'bkup_dir'

TRANSACTION LOG RENAME MATCH

the current transaction log is renamed and the log copy is also renamed using a matching name in the form YYMMDDnn.log. Previously, there was no way to cause the log copy to be renamed if the active log was truncated.

As of this change, the following methods can be used to rename the log copy:

DBBACKUP -x -n

or

BACKUP DATABASE DIRECTORY 'bkup_dir'

TRANSACTION LOG RENAME

TRANSACTION LOG TRUNCATE

- The Watch Manager, New Watch and Edit Watch dialogs did not have default buttons.

- OK, Cancel and Help buttons had mnemonics. Windows applications do not use mnemonics for these buttons because there are standard keyboard shortcuts (Enter for OK, Esc for Cancel and F1 for Help).

- Due to a JDK 1.3 bug (fixed in JDK 1.4), the default button would be the last button to have the focus.

These problemhave been corrected.

DECLARE CURSOR c USING variable-name

could have caused an error or returned incorrect results. The problem would have occurred after the procedure had been called more than 11 times. While this is now fixed, a workaround is to set the value of the Max_plans_cached option to 0.

1) The table into which the data was loaded was empty

2) The table into which the data was loaded contained more than one database page

3) The resulting table after the 'LOAD TABLE' statement contained at least 100 database pages

Databases experiencing this problem should be rebuilt. Unload the database using DBUNLOAD and make sure to unload the data 'ordered'. CAUTION: If you do an 'unordered' unload of the database the missing rows will be permanently lost.

Suppose table T1 contains a foreign key to table T2 with the 'ON DELETE CASCADE' option. T1 ad T2 are defined identically on the remote and consolidated databases. The following operations occur:

1. Insert R2 into T2

2. Insert R1 into T1 (R1 contains a foreign key reference to R2)

3. Delete R2 for T2

4. Step 3 results in a cascaded delete which results in R1 being deleted from T1

If a synchronization occurs after steps 2 and 4, then the consolidated and remote databases end up in the same state. On the first synchronization dbmlsynce uploads:

Insert R2 into T2

Insert R1 into T1

On the second synchronization dbmlsync uploads:

Delete R2 from T2

On the consolidated database, R1 will be deleted from T1 by a cascaded delete. Thus, neither R1 nor R2 is left in either database.

However if a synchronization only occurred after step 4, then a synchronization error occurs. In this case, dbmlsync will coalesce the insert and delete of R2 into a no op and upload no operation on T2. However, it will still upload the insert of R1 into T1. When this insert is applied on the consolidated database a referential integrity violation occurs because R1 has a foreign key that refers to R2 and R2 has never been uploaded.

To resolve this situation, dbmlsync now treats cascaded deletes and deletes that occur in a trigger specially. When it encounters a trigger/cascaded delete, dbmlsync now checks if there is a previous operation on the same row already included in the upload stream. If an operation exists the delete will be coalesced with that operation and uploaded. Otherwise the delete will be ignored.

In the example above this new behaviour prevents the error when a synchronization occurred after step 4, by preventing the insert of R1 from being uploaded.

New syntax:

START燚ATABASE燿atabase-file

[燗S燿atabase-name燷

[燨N爀ngine-name燷

[燗UTOSTOP爗燨N爘燨FF爙燷

[ WITH TRUNCATE AT CHECKPOINT ]

[ FOR READ ONLY ]

[燢EY爇ey燷

SQL statement failed: (-210) User '<username>' has the row in '<tablename>' locked

In this situation dbmlsync now tries for longer than it did in the past so failures of this type should be much more infrequent.

For example:

CREATE TABLE T (

PKEY INTEGER NOT NULL DEFAULT AUTOINCREMENT,

DATA1 INTEGER NOT NULL,

PRIMARY KEY ( PKEY ) );

CREATE PROCEDURE P()

BEGIN

INSERT T WITH AUTO NAME SELECT 1 AS DATA1;

END;

CALL P(); -- ASA Error -207: Wrong number of values for INSERT

Using WITH AUTO NAME on an INSERT statement on its own (outside of a procedure context) would work have worked correctly. This is now fixed.

event_parameter('ScheduleName')

will be the name of the schedule which fired the event. If the event was fired manually using TRIGGER EVENT or as a system event, the result will be an empty string. If the schedule was not assigned a name explicitly when it was created, its name will be the name of the event.

These problems have been fixed. The MobiLink Monitor now saves to the expected directory for both Windows and Unix. Trying to save to a directory without write permission on Unix, now gives a "file ... could not be accessed" message. For both Windows and Unix, the Monitor now adds the extension chosen in the Save dialog, if it is not already at the end of the file name.

Workaround:

Instead of looping on table.FindNext, check for table EOF

Instead of:

While table.FindNext

' process match

Wend

Use:

Do

table.FindNext

If table.EOF Then Exit Do

' process match

Loop

1 - The join condition was an equality predicate, (call this predicate P1).

2 - There was a non-equality predicate referring to columns from both tables, (call this predicate P2).

3 - At least one row from the left hand table, joined to multiple rows from the right hand table.

4 - P2 rejected at least one row that would be in the result, if P1 was the only predicate in the query.

4) Merge join is chosen by the optimizer.

This has been corrected.

In addition, an error is now returned if an empty string is passed to ULChangeEncryptionKey. The motivation for this is that an empty key cannot be specified in the storage parameters string. There would be no way to decrypt such an encrypted database (that is, specifying an empty key would not do it).

This error message only seemed to occur after applying a specific Microsoft Hotfix (Q299444).

As of this fix, when an error occurs the dbisqlc window will be restored and the error dialog will appear

- The table contained more than one column

- The INPUT statement contained a COLUMN WIDTHS clause

- Fewer column widths were given in the COLUMN WIDTHS clause than there are columns in the table

- The INPUT statement did not explicitly list the table columns

We now correctly set the row status array in many more situations.

We now correctly select which row status array to update; either the one passed in SQLExtendedFetch or the one specified by SQLSetStmtAttr(SQL_ATTR_ROW_STATUS_PTR).

We now correctly set the rows processed counter specified by SQLSetStmtAttr(SQL_ATTR_ROWS_FETCHED_PTR) in many more situations.

We now correctly set the row count value returned by SQLRowCount in many more situations.

Please note that bookmark values are not supported, at present, when adding rows using keyset driven cursors in SQLBulkOperations(SQL_ADD).

When the SQL_ATTR_CONCURRENCY setting is SQL_CONCUR_READ_ONLY, then SQLBulkOperations(SQL_ADD, SQL_UPDATE_BY_BOOKMARK, or SQL_DELETE_BY_BOOKMARK) returns an error (HY092). This is the setting for static cursors so, beginning with version 8.0, they can no longer be used to obtain bookmark values for SQL_ADD.

We now diagnose cases when SQLSetPos is called after SQLBulkOperations is called and before SQLFetchScroll or SQLFetch is called.

We no longer insert empty rows, in SQLSetPos(SQL_ADD), for those rows marked SQL_ROW_IGNORE using the row operation array.

We no longer ignore rows where the corresponding row status array value was SQL_ROW_NOROW.

We now set the row status array value to SQL_ROW_NOROW when a "row not found" erorr occurs in SQLBulkOperations(SQL_DELETE_BY_BOOKMARKS, SQL_UPDATE_BY_BOOKMARKS, SQL_FETCH_BY_BOOKMARKS). We no longer try to access bound column data in SQLBulkOperations(SQL_FETCH_BY_BOOKMARKS) when a "row not found" error occurs.

We fixed a problem when updating more than 1 row using SQLBulkOperations(SQL_UPDATE_BY_BOOKMARKS).

We fixed a problem when fetching more than 1 row using SQLBulkOperations(SQL_FETCH_BY_BOOKMARKS).

We no longer inspect the row operation array for SQL_ROW_IGNORE in SQLBulkOperations(SQL_ADD).

1) Crashes

2) Hanging

3) failure to add messages to the message log

EXEC proc1;

EXEC proc2;

Message 'some message';

- An index is selected on the table to satisfy the IN predicate

- The IN predicate appears in the index before the column in the ORDER BY

For example, the following query could exhibit the problem if an index on T(a,b) was selected:

SELECT * FROM T WHERE T.a IN (1,2) AND T.b>3 ORDER BY T.b

This is now fixed.

LONG VARCHAR

BINARY

VARBINARY

LONG VARBINARY

BIGINT

TINYINT

BIT

GUID

The correct type name is now returned.

- compiling dbtools.h failed

- the dbtools and dblib import libraries (dbtlstb.lib and dblibtb.lib) were missing

- samples\asa\c\makeall.bat failed to build using the Borland compiler.

This has been fixed. Note that due to a limitation of newer Borland linkers, Borland compiler built Embedded SQL applications must now compile and link src\sqlcadat.c (in the Adaptive Server Anywhere install directory) into each Embedded SQL application. This is in addition to linking against dblibtb.lib.

0x8160 Wave Dash

0x8161 Double Vertical Line

0x817c Minus Sign

The has been fixed.

Msg 13829, Level 12, State 0:

ASA Error -823: OMNI cannot handle expressions involving remote tables inside

stored procedures

if exists( select 1 from test where id=1)and exists( select 1 from test where id=1)

print "toto"

go

select * from SYS.SYSTABLE where substr(source,length(source),1) = ';'

select * from SYS.SYSPROCEDURE where substr(source,length(source),1) = ';'

select * from SYS.SYSTRIGGER where substr(source,length(source),1) = ';'

select * from SYS.SYSEVENT where substr(source,length(source),1) = ';'

-t<n> the desktop provider should wait n seconds for a

response from the client before timing out; the

default is 30

dbasinst stores the timeout value in the registry under "HKEY_LOCAL_MACHINE\SOFTWARE\Sybase\MobiLink\ActiveSync Synchronization\Connection Timeout".

SQLTransact(henv, SQL_NULL_HDBC, type);

where type = SQL_COMMIT or SQL_ROLLBACK and a NULL statement handle, would have failed to commit or roll back the transactions on all open connections associated with the enviroment handle. Similarly, calling the 3.0 ODBC function:

SQLEndTran(SQL_HANDLE_ENV, henv, type);

where type = SQL_COMMIT or SQL_ROLLBACK would also have failed to commit or roll back the transactions on all open connections associated with the enviroment handle. This is now fixed.

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

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

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

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

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

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

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

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

-pd dbsock8.dll

-pd dbsock8.dll;dbhttp8.dll

To resolve the problem identify the communication protocols to be used by dbmlsync during this synchronization then use the -pd switch to preload the DLL's used for those protocols as follows

tcpip dbsock8.dll

http dbhttp8.dll

https dbhttps8.dll

We STRONGLY encourage everyone using dbmlsync on CE to use this switch even if they have not encountered the error.

102300: File associated with given page id is invalid or not open.

could have occurred when processing a query that skipped a string column that appeared on a continuation page. A continuation page is used for a row when a row does not fit entirely on one page. For example, this can occur if a column is added to an existing table.

- optimization logging was enabled

- the option LOG_DETAILED_PLANS was set to ON

- the query being logged was a complex statement

- the optimization strategy for the query was *not* being logged through the use of one of the PLAN() functions.

This is now fixed.

IO Error 5 doing 'fstat' on file '<backup file name>'.

Ensure that all PC cards are inserted and that storage space is available.

Retry/Cancel.

This has been corrected.

The problems fixed include:

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

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

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

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

fixed.

- The operation is on a table in the publication

- The where clause in the publication excludes this operation from being sent

- No further operation in the log file on this row caused this operation to be ynchronized

then in rare circumstances, it was possible for dbmlsync to have generated an invalid upload stream. This would most likely be seen as a "Protocol Error" in the Mobilink server. This has been fixed.

error, ignore the synchronization request and abort the synchronization. Then the MobiLink server would generate the error "Unable to read from the 'tcpip' (or 'http') network connection". Now if DBMLsync cannot find the requested offset, it sends the MobiLink server an empty upload stream (an upload without any actually user data), plus an error message. The MobiLink server will display this error message and abort the synchronization.

"For Hotsync and Scoutsync, the stream parameters need to be specified in the stream parameters in much the same way as for Adaptive Server Anywhere MobiLink clients. The format is:

security=cipher{ keyword=value;... }

where cipher must be certicom_tls... "

This should have read as:

"where cipher must be ecc_tls..."

For backwards compatibility, ecc_tls can also be specified as certicom_tls.

- IStatement.getColStrAttr

- IResultSetMetaData.getCatalogName

- IResultSetMetaData.getColumnLabel

- IResultSetMetaData.getColumnName

- IResultSetMetaData.getColumnTypeName

- IResultSetMetaData.getSchemaName

- IResultSetMetaData.getTableName

This could have resulted in wrong results or crashes. The problem is now fixed

begin

select 1,2;

select 3

end

This problem has now been fixed.

This problem could have happened in DBMLSync and DBLTM as well. The problem has been fixed.

For example:

dbmlsrv8 -c ... -x http {port=22222} -x http {port=88888}

This problem has been corrected.

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

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

log files were still available. However, if "Delete_old_logs" was on in the remote database, the previous transaction log files may have been deleted, and then DBMLsync would have complained with "missing transaction log(s) before file log_file_name". These problems are now fixed.

for ASA would have gone into an infinite loop display the error: "SQL statement failed: (-101) Not connected to a database". The errors SQLE_CONNECTION_TERMINATED and SQLE_NOT_CONNECTED were not handled properly. This problem is now fixed.

- table T contained a foreign key and one or more of the columns of row R involved in the FK was NULL.

- another row, R2, existed in the download stream that dbmlsync had to delete, due to a legitimate RI violation, involving the same foreign key in which R had a NULL value.

This behaviour has been corrected.

The problem has been fixed.

- data was being imported into a new table (i.e. the table did not exist before running the Import Wizard),

- the file being imported was ASCII, FIXED, or SQL,

- the name of a column was changed from the defaults ("Column1", "Column2", etc.)

The wizard would have failed with a message saying that Column1 (or whatever the original column name was) could not be found. This problem has now been corrected.

The dbtool8 DLL for CE will continue to be shipped, as it is required by dbremote and can be used through the dbtools interface to programatically access dbmlsync's functionality

The sequences that could have caused this problem were, (although it might not reproduce consistently):

- insert a row R, stop synchronization delete, delete row R, start synchronization delete, insert a row with the same primary key as R

- if the dbmlsync extended option "SendTriggers" was off, insert a row R, delete row R inside of a trigger, insert a row with the same primary key as R

- if the dbmlsync extended option "SendTriggers" was off, insert a row R, update row R inside trigger so that it belonged to no publication, update row R so that it again belongs to the publication

This is now fixed.

displayed until the main viewer window is active again.

CREATE SYNCHRONIZATION USER, ALTER SYNCHRONIZATION USER, CREATE

SYNCHRONIZATION SUBSCRIPTION, ALTER SYNCHRONIZATION SUBSCRIPTION, CREATE

SYNCHRONIZATION SITE, ALTER SYNCHRONIZATION SITE, CREATE SYNCHRONIZATION

DEFINITION, ALTER SYNCHRONIZATION DEFINITION, CREATE SYNCHRONIZATION

TEMPLATE, ALTER SYNCHRONIZATION TEMPLATE.

This has now been fixed.

create procedure mytest() as

select 1

go

Note that the procedure ends with a SELECT statement having no FROM clause. The server treats the "go" as an alias for the last SELECT list item; otherwise, a syntax error would be given when trying to save the procedure definition in Sybase Central. The "go" is included in the preserved-source string and causes a syntax error on rebuild.This problem is similar to issue 302757. The trailing "go" is now removed when saving the procedure definition.

.

- the dialog which reports errors in SQL statements

- the data prompt dialog used for the INPUT ... PROMPT statement.

This has been fixed now so that the dialogs close.

- Negative numbers (e.g. "-123")

- Real numbers that began with a decimal point (e.g. ".123")

- Numbers in exponential notation (e.g. "1.23e2")

For example, typing the number -123, would have caused a beep when the "-" was typed and would not have allowed it to be entered in the editing box for the table data. A workaround for this was to type the number without the minus signt, then add the minus sign after. This bug affects ASA plug-in for Sybase Central as well. This is now fixed in both dbisql and Sybase Central.

For example:

- Edit an existing table

- Alter the primary key by adding a column to it

- Cancel the editing of the table

Refreshing the application would make it appear as though the column that was added to the primary key (but should have been discarded) was in fact in the primary key. This has been fixed.

For example:

- Load a schema file

- Make a change to the schema file (add a column to a table for instance)

- Choose to create a new schema file and provide a filename

- When a message box informs that the previous schema must be closed choose OK.

- When a message box informs that the previous schema has changes that should be saved, click Cancel.

The error message indicated that a file already exists. It no longer displays that message but returns the user to the new schema file dialog.

For example:

create event MyEvent

schedule MySchedule start time '10:00PM' on ('Thu','Fri')

handler

begin

backup database directory 'd:\\backup'

wait after end

transaction log truncate

end

This has now been fixed.

create function f() returns varchar(10)

begin

return systable.table_id;

end

then using the function would have resulted in a server crash. This problem has now been fixed and server will now return an appropriate error message.

Example:

select property( 'MainHeapBytes' );

This has been fixed.

This problem has now been fixed.

The example below illustrates this issue: the subquery is a grouped query and the aggregate function "min(p.quantity)" is an aggregation that must be computed in the main query block:

select id

from product p

where quantity < 28

group by id

having ( select COUNT(*)

from product p1

where 28 >= min(p.quantity) ) > 0

Previously, specifying no synchronization stream parameters required setting ul_synch_info.stream_parms to NULL. Now, a setting of NULL or an empty string will cause the registry to be checked for parameters to use. If an application needs to force default parameters (overriding the registry), it should set ul_synch_info.stream_parms = "stream=tcpip;host=localhost";

- the -x switch was specified on the dbmlsync command line

- the progress value on the remote was behind the progress value on the consolidated

- the LockTables extended option was set to 'off'

then dbmlsync would have failed to generate an upload and report the following error :

"No log operation at offset of n in the current transaction log" The number n would be the ending log offset of the current transaction log. This has been fixed.

create table #temp1 (X int);

insert into #temp1

select * from

( select X=0 from

product p1, product p2

where p1.id = p2.quantity ) AS DT(X)

where DT.X = 2

;

This problem affected the ASA plug-in for Sybase Central as well.

For example, if a user installed 8.0.1 GA followed by 8.0.1.3080 EBF, then upgraded to 8.0.2 GA, the installation may fail because 8.0.1.3080 EBF is newer than 8.0.2GA.

This is now fixed, but the problem may be worked around by deleting the dbctrs8.ini and sqlactnm.h files in the win32 directory before installing 8.0.2 GA.

For example, if the following statements were in a file called TEST.SQL:

PARAMETERS user_name;

GRANT CONNECT TO "{user_name}" IDENTIFIED BY "{user_name}";

GRANT DBA TO "{user_name}";

CONNECT USER "{user_name}";

and were executed by:

READ TEST.SQL [test]

an error would have occurred that the user "USER" did not exist. This has been fixed.

A workaround for the problem is to remove the quotation marks from the CONNECT statement.

Note: if an ODBC data source only had the shared memory link selected, then no CommLinks parameter was specified on the connection.

SELECT FIRST *

FROM base_table

WHERE <condition>

ORDER BY <indexed column>

In this case, the <condition> in the WHERE clause was highly selective, and could be used as a sargable predicate (that is, the engine could use an index on base_table). However, because of a costing error, the optimizer instead chose a plan utilizing the index on the column specified in the ORDER BY clause, a much more expensive choice in real terms.

This has now been fixed, but as a workaround, one could replace SELECT FIRST with SELECT TOP 1.

A workaround would be to shut down the Schema Painter after saving an XML file and start it up again to load another file.

-187 "Illegal cursor operation attempt" 09W02

could have been returned. For example, this error would be returned when re-fetching the current row. This has now been fixed.

For example:

SELECT "m"."emp_lname", "e"."emp_lname"

FROM "DBA"."employee" AS m JOIN "DBA"."employee" AS e

ON "m"."emp_id" = "e"."manager_id"

ORDER BY "m"."emp_lname" ASC , "e"."emp_lname" ASC

Note: when this feature is enabled, the following features are not available and must not be used:

- send_column_names synchronization parameter

- schema upgrades (applies to 8.0.2 and later)

The analyzer now outputs optional segment divisions within ULSEGDB code which are enabled individually by defining a corresponding preprocessor symbol. There is an optional segment division at each table. The segments are named ULSTn where n is an integer (the table number), and each is activated by defining UL_ENABLE_SEGMENT_ULSTn.

For example, suppose an application has 5 tables. The generated code will resemble:

start ULSEGDB segment

start ULST1 segment (if UL_ENABLE_SEGMENT_ULST1 defined)

<code for first table>

start ULST2 segment (if UL_ENABLE_SEGMENT_ULST2 defined)

<code for second table>

...

start ULST5 segment (if UL_ENABLE_SEGMENT_ULST5 defined)

<code for fifth table>

Defining only UL_ENABLE_SEGMENT_ULST4 will leave tables 1 through 3 in ULSEGDB but put tables 4 and 5 into ULST4.

Extra segments should be enabled as required to avoid exceeding the segment maximum size. Note also this assumes generated code segments have been enabled by defining UL_ENABLE_SEGMENTS (and UL_ENABLE_GNU_SEGMENTS if applicable). In CodeWarrior, these #defines should be added to the prefix file; for PRCTools, use the -D option.

This problem did not affect connections that used jConnect.

- the foreign key in question must have been larger than any existing primary key,

- another transaction (also with the wait_for_commit option on) must have inserted the same foreign key before the first transaction commited, and must have done so while the foreign key was greater than any existing primary key,

- between the two foreign key insertions, enough primary keys must have been added to fill the last leaf page and at least one of these keys must be subsequently deleted (before the second foreign key insertion).

- the index used to enforce the constraint must have been a uncombined (split) comparision-based index.

This has now been fixed.

This has been fixed.

This problem also affected the ASA plug-in for Sybase Central, the Stored Procedure Debugger, and DBConsole.

- no locks are placed on primary key rows when adding an orphan (fk row with no matching pk row)

- if a transaction adds a primary row, it will be allowed to commit only if the transaction has exclusive locks on all foreign rows that reference the primary row at the time the primary row is added.

This option is meant to mimic 5.x locking behaviour when transactions add foreign rows before primary rows (with the proviso that no two transactions concurrently add foreign rows with the same key value). Note that this option is not recommended for general use as there are a number of scenarios in which transactions will (counterintuitively) not be allowed to commit, including:

- if transactions concurrently add foreign rows with the same key value when the primary row does not exist, at most 1 of the transactions will be allowed to commit (the one that adds the corresponding primary row).

- if a transaction deletes a primary row and then adds it back, it likely will not be allowed to commit (unless it has somehow obtained exclusive locks on all of the matching foreign rows).

- if the BIT value had a default of "1", and

- if the BIT value was not explicitly set by the user, and

- connected using jConnect.

This has been fixed. This bug affected the table "Data" panel in the Adaptive Server Anywhere plug-in for Sybase Central as well.

update Employee e

set e.emp_fname ('x')

where:

- the column to be updated was qualified with a correlation name

- the "=" was missing

- the expression being assigned was enclosed in parentheses

would result in a server crash. An error (Set clause for column 'a' used incorrectly) will now be reported.

Example:

LINKS=TCPIP;ENC=ECC-TLS(trusted_certificates=sample.crt)

would have displayed the following message:

Parse error: Bad value near ''

This has been fixed. The following message is now displayed:

Parse error: Bad value near 'ECC-TLS(trusted_certificates=sample.crt)'

- the committing transaction must have deleted a primary row for which there were foreign references

- another transaction must have had the foreign table's schema locked exclusively (via DDL or LOCK TABLE)

- the DDL or LOCK TABLE operation must have been the first use of the foreign table since it was loaded

- the committing transaction must have had blocking off (or possibly be involved in a deadlock)

- the index used to enforce the constraint must have been an uncombined (split) index.

This problem, which could also have resulted in a server crash, is now fixed.

This has been fixed; the toolbar buttons and menu items in the context menu are now properly enabled.

upload_statistics

download_statistics

synchronization_statistics

could have been wrong. The most likely wrong value was one that was non-zero when it should have been zero. Less likely, the counts could have been smaller than expected. Similarly, the error and warning counts displayed by the MobiLink Monitor could also have been wrong. This has ben fixed.

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

select * from employee left outer join (select 102) dt(x) on (emp_id=x)

would have had 102 in the x column of every row. Now, the value 102 appears only for rows where emp_id is 102, and NULL in every other row. The same error occurred for subqueries in the select list. For example:

select * from employee left outer join (select (select first emp_id from employee)) dt(x) on (emp_id=x)

This problem is now fixed.

Examples of where "Connection error" is now returned where "Server not found" was previously returned include:

dbping -c "links=tcpip" - missing server name

dbping -c "links=tcpip{dobroad=none};eng=myengine" - missing host parameter

dbping -c "links=tcpip{clientport=7777};eng=myengine" - if TCP/IP port 7777 is already in use (eg from a previous connection)

dbping -c "links=tcpip;eng=myengine" - if the machine is out of available TCP/IP ports etc.

The behaviour of links=all was also changed to always attempt the shared memory connection before other links are attempted (to be consistent with links=tcpip,shmem, for example). Previously, if an application had used the connection string including "links=tcpip" and then one including "links=all", the second connection would attempt to connect over TCP/IP before shared memory, but now attempts to connect over shared memory first.

For example:

select (select count(*) from R) as A

from T

where 1 <> ALL (select A from S )

This has now been corrected.

For example:

CREATE VARIABLE value INT;

SET value = 1;

EXIT value

It did not matter what the statements did, just that there were more than one, and that the last one was an EXIT.

This problem has been fixed.

For example, using DBISQL connected via the JDBC-ODBC bridge, executing the following:

set temporary option ansinull = 'on';

select count(NULL) from dummy;

will cause an warning dialog "null value eliminated in aggregate function". Executing the following statement:

select top 10 * from rowgenerator;

would have return no. This problem has now been fixed.

For example, the following table definition would have caused the problem:

create table T(

x integer check( 2*x >= 0 ),

y integer COMPUTE (2+x)

)

An UPDATE statement that modified 'x' (to a non-NULL value) would have left 'y' set incorrectly to NULL. This problem has now been fixed.

When running with the -m option, the log file is truncated at each checkpoint, but this truncation could not have occurred if the file was being defragmented concurrently. This has now been fixed.

Note: Use of the -m switch is not advised, please read the documentation before using this server command line switch. To avoid database file fragmentation, it is recommended that where this option is used, the transaction log be placed on a separate device or partition from the database itself.

It is also not recommended to defragment any database files while they are in use.

- the "Connect" dialog was being used

- the JDBC-ODBC bridge was being used

- a value in the "Start line" field contained a blank.

The exact error message varied, depending on what other connection parameters were specified and whether the database server was already running or not. This problem has been fixed. A workaround is to connect using the jConnect driver instead of the JDBC-ODBC bridge. Note, this was a problem in the administration tools, not the JDBC-ODBC bridge per-se.

and then a different row was selected by clicking with the mouse or by pressing the UP or DOWN keys. An error message about the invalid data would have ben displayed, and the row selection would change. Attempting to go back to the row with the bad data and correct it would then have caused an internal error. This problem has been fixed. Note, this problem also applied to the ASA plug-in for Sybase Central.

Far example:

create table B( city char(20), state char(20));

select city || state

from B

where city || state not in

(select city || state from B

group by city || state);

For the crash to have occurred, the table B must have contained a combination of empty and non-empty strings. This has been fixed.

For example, if a few tables were added to the 'Synchronized Table Order' list, OK was clicked in the Options dialog and then the Options dialog was opened again, the selected tables would all applear in the 'Synchronization Tables' list and the tables that were previously in 'Synchronizaton Tables' would have disappared.

This problem has been fixed.

For xample:

select *

from R, S

where R.X IN ( select T.X

from T

where T.X = T.Y )

and S.Z = R.Z

For example:

CREATE procedure foo( IN tablename varchar(256) )

BEGIN

EXECUTE IMMEDIATE 'SELECT * FROM ' || table_name;

END ;

call foo('DBA.sales_order_items');

The problem has been fixed and a "Column not found" error is now generated.

- an INSERT into the table was executed using a value for the column outside the range for the current setting of Global_database_id. This could happen if rows from other databases were downloaded as part of a synchronization.

- the server was shutdown abnormally (e.g. by powering off) before a checkpoint occurred.

The next time the database was started, the next available value for the column would have been set incorrectly. If an INSERT was then attempted with no value provided for the column, the error "Column '<col>' in table '<table>' cannot be NULL" would have been reported. If the database was again shut down and restarted, an INSERT into the table would have attempted to use the first available value in the range for the current setting of Global_database_id. Note that if rows had been deleted from the table, this could result in a value being generated which had previously been used and which might still exist in another database. Resetting the value using sa_reset_identity() would correct the problem, assuming an appropriate value to use can be determined. This problem has now been fixed.

- DBKEY values which contained number sign ('#') characters were being mangled. This would have prevented connecting to an encrypted database.

- if the DBKEY parameter was specified on the DBISQL command line, but there was not enough information to connect, the Connect dialog was opened, but the Encryption Key field was not filled in. Instead, the DBKEY value appeared in the Advanced Parameters field.

Example:

Q1:

select *

from T

where (T.X = c1 and T.Y = c2) or

(T.X =c3 and T.Y = c4) or

(T.X = c5 and T.Y = c6) or

(T.X =c7 and T.Y = c8) or

(T.X = c9 and T.Y = c10) or

(T.X =c11 and T.Y = c12)

Q2:

select *

from T

where T.X IN ( c1, c3, c5, c7, c9, c11) and T.Y IN (c2, c4, c6, c8, c10, c12)

and ((T.X = c1 and T.Y = c2) or

(T.X =c3 and T.Y = c4) or

(T.X = c5 and T.Y = c6) or

(T.X =c7 and T.Y = c8) or

(T.X = c9 and T.Y = c10) or

(T.X =c11 and T.Y = c12))

had more than 4 tables. This has been fixed.

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

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

- NULL binary input parameters may have resulted in E_OUTOFMEMORY

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

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

UL_DEBUG_CONDUIT: When this variable is set, a message box will pop up on conduit loading/unloading to confirm entry into the conduit. Requires user intervention to proceed.

UL_DEBUG_CONDUIT_LOG: When set to 1, basic logging will be written to the log, possibly including synch parametrs, registry locations and attempts to load libraries. When set to 2, basic logging as well as more detailed IO logging will be written to the log

the Schema Painter failed, returning an error indicating that the publication could not be created because a table did not exist. The table name displayed in the error sometimes contained a full table name, but always contained various garbage characters. This is now fixed.

SQLPrepare( "Call sp1( ?, ? );" )

SQLBindParam( parameter 1, of type SQL_PARAM_OUTPUT)

SQLBindParam( parameter 2, of type SQL_PARAM_INPUT)

SQLExecute; --> HY105 error (invalid parameter type)

This problem has now been fixed

SELECT CAST( POWER( 2, T.exp ) as UNSIGNED INTEGER) FROM T

would have failed to compile. This has been fixed, the macros are now defined.

DB_EXTENDED_PROPERTY ( { property_id | property_name },

[, property-specific_argument

[, { database_id | database_name } ] ] )

This new function, db_extended_property(), is similar to db_property(), but it allows an optional property-specific string parameter to be specified. The interpretation of the property-specific argument depends on the property id or name specified in the first argument. Calling db_extended_property( x ) is equivalent to calling db_property( x ).

Two new properties have been added: FileSize and FreePages. Each of these properties can take an optional argument which specifies the dbspace for which the property is being requested.

The dbspace can be specified as any of the following:

- the name of the dbspace

- the file_id of the dbspace

- 'translog' to refer to the transaction log file

- 'temp' to refer to the temp file

- 'writefile' to refer to the write file

If the dbspace does not exist, the property function will return null. If the name of a dbspace is specified and an id or name of a database which is not the database of the current connection is also specified, the function will also return null (since it is not possible to query the system tables across databases) except that the well-known name 'system' will still be accepted.

FileSize returns the length of the specified database file in pages. For the system dbspace on databases created with 8.0.0 or later, FileSize includes the size of the checkpoint log which is located at the end of the database file.

FreePages returns the number of free pages in the specified file. FreePages is only supported on databases created with 8.0.0 or later. For the transaction log, FreePages returns the number of completely empty, unused pages between the current logical end of the log and the physical end of the log file. When using a write file, FreePages on a dbspace will return the number of free pages in the virtual dbspace represented by writefile. FreePages on the writefile itself returns the number of pages free in the writefile that can be used to create new mapped versions of database pages. That is, pages may appear free to a dbspace but, from the point of view of the write file itself, they are actually allocated and in use inside the write file as images of pages.

If no property-specific argument is provided for either of these properties, the system dbspace is assumed.

UltraLite sequence numbers (ie. ml_user.commit_state on the consolidated side) are also shown.

exec sp_procxmode 'ml_add_user', 'anymode'

exec sp_procxmode 'ml_add_table_script', 'anymode'

exec sp_procxmode 'ml_add_lang_table_script', 'anymode'

exec sp_procxmode 'ml_add_java_table_script', 'anymode'

exec sp_procxmode 'ml_add_dnet_table_script', 'anymode'

exec sp_procxmode 'ml_add_connection_script', 'anymode'

exec sp_procxmode 'ml_add_lang_connection_script', 'anymode'

exec sp_procxmode 'ml_add_java_connection_script', 'anymode'

exec sp_procxmode 'ml_add_dnet_connection_script', 'anymode'

go

For example, if a table T has a primary key on the columns (T.A, T.B) and, in a complex query, the predicates "T.A = constant" and "T.B IN ( constant1, constant2, ..)" are used to create a partial index scan on (T.A, T.B), the number of rows returned by the partial index scan may have been underestimated. This has been corrected so that the optimizer now calculates a reasonable estimate.

A negative side effect of this change is that keyset cursors over a table locked in this fashion will not work as expected (they will return row changed warnings for every row in the cursor if any row in the database has been modified). This is most likely to affect updateable cursor with an ORDER BY (in which case the engine could turn it into a keyset cursor).

This behaviour can be disabled by setting the SUBSUME_ROW_LOCKS option 'off' ('on' by default for 9.x and up). While this feature has been added to 8.0, it has been left 'off' by default.

For example:

create variable d java.math.BigDecimal;

set d = new java.math.BigDecimal(1000);

select d;

This problem has now been fixed.

Note that this is not likely to affect most users, since the existing backup tools do not exhibit this behaviour, but it may have occurred with a user written backup tool using the page level backup api.

For example, the following query would have caused the problem to occur:

select e.emp_id ee, isnull( d.dept_head_id, 999 )de

from employee e left outer join department d on ee=de

order by emp_fname

Errors include the following: "Unknown Device Error", although other fatal errors or assertion failures were possible. This has now been fixed.

For example:

declare x integer;

set x = 888;

set x = x || 888;

This is now fixed.

SELECT *

FROM a join b,

(c join d ) join e

The parser was not processing the comma properly when it was followed by a bracket. This has now been fixed.

For example, if a client application:

1) made a shared memory connection

2) disconnected

3) unloaded dbodbc8.dll

4) reloaded dbodbc8.dll again

5) attempted another shared memory connection within a few seconds of the previous disconnect

Then the second connection attempt could fail. A debug log (generated using the LOGFILE connection parameter) would indicate that shared memory could not be started. This has been fixed.

Code of the following form could have caused the problem:

declare x long varchar;

select a into x from test where id = 1;

set x = x || ', this should fail with an error';

as a workaround use (it's actually more efficient):

declare x long varchar;

select a || ', this shouldn't fail' into x from test where id = 1;

This is now fixed.

For example:

Set t = Conn.GetTable(揟�)

Set idx = t.Schema.GetIndex(搃dx�)

MsgBox 揘ame = � & CStr(idx.Name) � this is OK

t.Open

t.Close

MsgBox 揘ame = � & CStr(idx.Name) � this would fail

A similar problem existed with column objects (instead of index objects). This has been fixed, so now the last line of example will succeed.

DB_EXTENDED_PROPERTY ( { property_id | property_name },

[, property-specific_argument

[, { database_id | database_name } ] ] )

For the properties FileSize and FreePages, the property-specific_argument 'temp' has been changed to 'temporary', so that there is consistent usage for the temporary file across different statements. The orginal value 'temp' is still allowed for existing usage.

Launch the SimpleCE project by clicking on the "Samples\ASA\ADO.NET\SimpleCE\Simple.sln" or whatever is appropriate for your PC. Accept the Visual Studio conversion message if you see one.

If you see the message "The .net assembly 'iAnywhere.Data.Asaclient' could not be found" then perform step 1, otherwise go to step 2.

Step 1. Right-click on "Simple" in the Solution Explorer pane (in the top right part of the Visual Studio display). Select "Properties".

In the Simple Property Pages window, select "References Path" (as shown below). If you are running Visual Studio.NET, change the "C:\Program Files\Sybase\SQL Anywhere 8\ce\" to your ASA 8.0.2 "ce" directory. If you are running .NET.2003, point to the "ce\VSNet2003" folder instead of "ce" since there is an iAnywhere.Data.AsaClient.dll there for Visual Studio .Net 2003.

Get rid of any other paths (such as "E:\src80\db\...") that you might see since they do not apply.

Step 2. Try building the application.

If you see a "Resource transformation" error message about Form1.resx, then perform step 3, otherwise you should have an error-free build.

Step 3. Double-click on Form1.cs in the Solution Explorer window to open the form designer (or click on Form1.cs and select the "View Designer" button in the Solution Explorer window). Move the button on the form and this will cause a new and correct resx file to be generated. Try rebuilding now and there should be no more error messages.

Cannot find an index for field '<column name>'.

Every field must have at least one index. Current IndexCount = 0.

The database would have needed to be restarted to correct the problem. This has been fixed.

SYS.SYSSYNC.server_connect

SYS.SYSSYNC."option"

SYS.SYSREMOTEOPTION."setting"

This has been fixed by revoking SELECT permission on the SYSSYNC and SYSREMOTEOPTION tables from SYS and only DBA is now granted SELECT permission. The following new views have been created for the PUBLIC group:

SYS.SYSSYNC2

SYS.SYSREMOTEOPTION2

These views select the same columns of the original table, except they hide sensitive columns dynamically based on whether the user is a DBA or not. When the value is hidden, a string equal '<hidden>' is returned.

The following views are also updated to perform the same dynamic hiding on the sensitive columns.

SYSSYNCS

SYSSYNCDEFINITIONS

SYSSYNCTEMPLATES

SYSSYNCSITES

SYSSYNCUSERS

SYSSYNCPUBLICATIONDEFAULTS

SYSSYNCSUBSCRIPTIONS

SYSREMOTEOPTIONS

The Sybase Central plugin has also been updated to use the views instead of selecting from the tables directly.

- the ANY or ALL subquery contained a table T1 that was flattened;

- there existed at least three tables, including T1, joining on the same column, (ie "T1.X = T2.X and T2.X = T3.X and T3.X = T1.X" )

This is now fixed.

call sa_server_option('request_level_log_size',nnn)

where nnn is the size limit for the file in bytes.

1> create table otto (a int)

2> go

1> create proc otto as begin select 1 end

2> go

Msg 2008, Level 16, State 1:

Procedure 'otto', Line 1:

The object 'otto' is not a procedure so you cannot create another procedure under that group name.

shut down". This has been fixed. Note that the upgrade would be completed successfully; it was only the shut down that would have failed.

For example:

SELECT (SELECT c1 FROM t3 WHERE t3.akey='xyz') AS foo

FROM t1,t2

WHERE t1.c2=t2.c2

AND t1.pk NOT IN (SELECT t4.pk FROM t4 WHERE c4=foo)

This has now been fixed.

EXEC SQL GET DESCRIPTOR sqlda :hostvar = DATA

or

EXEC SQL SET DESCRIPTOR sqlda DATA = :hostvar

could have failed to copy the correct amount of data if the host variable type was DECL_DATETIME, DT_TIMESTAMP_STRUCT, DECL_LONGVARCHAR, DT_LONGVARCHAR, DECL_LONGBINARY or DT_LONGBINARY. The SQLDATETIME structure used by the TIMESTAMP_STRUCT structure is 14 bytes on platforms which do not require alignment, and 16 bytes on those that do. Code with the length of the structure appropriate for the current machine was being generated by sqlpp. Now sizeof(SQLDATETIME) is used in the generated code instead.

For example:

select * from T1 where T1.X = ';' order by T1.X;

Aditionally, the error message displayed in this case referred to the statement in the "SQL Comments" window, when it meant the "SQL Statements" window. Both of these problems have now been fixed.

When using SQLGetData to convert binary data to a SQL_WCHAR column, the resultant indicator value was incorrect.

For binary to wide character conversions, if the data was fetched in chunks, the pieces would be placed in the wrong location in memory. The terminating NULL wide character was placed in the wrong location in memory.

For binary to wide character conversions, the call to the translation DLL passed the wrong type, SQL_CHAR instead of SQL_WCHAR, for wide characters. In some cases, it passed the wrong length as well.

These problems have been corrected.

- dbisql was running on a Windows operating system which was configured to use a multi-byte character set (MBCS), such as Japanese or Chinese, and

- an OUTPUT TO ... FORMAT EXCEL statement was executed, and

- an exported string, which was less than 255 characters, had a MBCS encoding which was greater than 255 bytes.

This problem has been fixed.

The same loaded class file works fine on Windows. The database hwas created with jdk 1.3.

and the java file has been compiled with target 1.1.

For example:

create table T1(pk int not null primary key ,csc int null compute (pk+0));

insert into T1 (pk) Values(3);

commit;

insert into T1 (pk) on existing update values(3);

This has now been fixed.

Win64 for AMD64 supports both AWE and scattered reads for 32-bit executables.

Running the 32-bit engine on Win64 is not recommended. Running the native 64-bit executable is preferred.

1. Connect to database in Sybase Central 4.2

2. Create a new table

3. Add a column and define its datatype

4. Select the table name in the table tree view (left pane)

5. Right mouse click Delete

6. Verify the Save changes request

If using "fast launcher", the stack trace remains until the "fast launcher" is restarted or stopped.

Note, the file fragment count is available through the system functions db_property('DBFileFragments') and db_property( 'LogFileFragments' ), and can be displayed in a warning at startup if the fragment count is high.

GRANT CONNECT TO ... IDENTIFIED BY ...

GRANT REMOTE DBA TO ... IDENTIFIED BY ...

CONNECT ... IDENTIFIED BY ...

CONNECT USING ... (where a password is given)

CREATE EXTERNLOGIN ... IDENTIFIED BY ...

The password is replaced by an ellipsis. The rest of the statement is left as-is, though comments are removed and white space is coalesced. If the statement does not contain a password, it is not obfuscated in any way; any comments it contains are left as-is.

For example, the following values are returned:

For the 32-bit (X86) Windows NT engine running on Win64 for Itanium

Property( 'NativeProcessorArchitecture' ) returns 'IA64'

Property( 'ProcessorArchitecture' ) returns 'X86'

For the 32-bit (X86) Windows NT engine running on Win64 for AMD64

Property( 'NativeProcessorArchitecture' ) returns 'AMD64'

Property( 'ProcessorArchitecture' ) returns 'X86'

In all other cases, property( 'NativeProcessorArchitecture' ) returns the same value as property( 'ProcessorArchitecture' )

columns. The Ctrl-X, Ctrl-C and Ctrl-V accelerators can still be used while editing within a text field in the Table Editor to cut, copy and paste text. Since the Delete menu item and toolbar button can now be used to delete columns, the Delete Column menu item (in the File menu) and toolbar button (on the plug-in's toolbar) have been removed.

START ENGINE AS 'Test'

Now, the quotation marks do not appear as part of the started engine's name.

If the server were to start a large number of databases that have been initialized with a large page size, the server's address space may have been exhausted or become fragmented and therefore fail to allocated one or more of these buffers. In this situation, the server would have failed with assertion 101413.

The server will now attempt to reduce its memory usage (i.e. to not allocate as many buffers) when a database is started read-only.

However, if a saved analysis is revisited at a later time from within Sybase Central, the context under which the original analysis was run is not saved; hence, the Index Consultant will still recommend dropping unused indexes at this time. The user can remove these lines before they run the script if they wish.

A workaround for customers is to manually edit captured queries of these types to add the quote characters.

Another problem was that the server may have failed to report the list of non-daemon threads being stopped due to a shutdown. Now the complete list is reported as an error so that user may implement their shutdown code correctly.

ASA error -200: Invalid option 'AUTOMATIC_TIMESTAMP' -- no PUBLIC setting exists

This has been fixed.

GROUP BY [ group-by-list | ROLLUP ( group-by-list ) ]

Queries such as:

SELECT COUNT(*)

FROM department

GROUP BY ROLLUP dept_name, dept_head_id

are now rejected with "syntax error near 'rollup' on line 3" (these queries were accepted in the beta software)

The following query gives the desired answer:

SELECT COUNT(*)

FROM department

GROUP BY ROLLUP (dept_name, dept_head_id)

- If the server was started with the "-z" option, and the connection was via jConnect, debugging information from DBISQL was displayed in the server window. (It shouldn't be.)

- Connecting to an authenticated 1254TRK database was not possible.

- If connecting via jConnect, DATE, TIME, and TIMESTAMP column types were all displayed as TIMESTAMP and were not in the appropriate format.

- The list of options listed by the SET command was incomplete

OMNI cannot handle expressions involving remote tables inside stored procedures

An example of this situation is:

create procedure p()

begin

declare myvar int;

set myvar = 1;

if myvar = (select col from remote_table where pk = 45) then

message 'found'

else

message 'not found'

end if;

end

This statement will now execute correctly.

The affected lists were:

- The list of tables in the "Lookup Table Name" dialog

- The list of columns in the "Select Column" dialog

- The list of procedures in the "Lookup Procedure Name" dialog.

- The list of options displayed by the SET command

- The combo box which contained the list of columns in the Import wizard

- The list of database servers in the "Find Servers" window (opened from the "Connect" dialog)

- The list of ODBC data sources in "Data Source Names" window (opened from the "Connect" dialog)

For example, when created by USER1

create view V1 as select * from A join B,

A join C

this view was stored as

create view V1 as select * from USER1.A join USER1.B,

A join USER1.C

As a result other users could not execute the view and a database rebuild would have failed because table "A" could not be found. This has been fixed.

select exprtype('select current publisher',1)

would have been different depending on whether or not a Publisher was defined. The data type will now be varchar(128) consistently.

select * from (select c from employee) dt(c)

that referenced one of its own columns would have caused a crash. A crash would also have occurred if a procedure call was inlined as a derived table that referenced one of its own columns. For example:

CREATE PROCEDURE p()

RESULT ( c1 int )

BEGIN

SELECT c1 FROM customer

END;

SELECT * FROM p();

This problem has been fixed.

Restricted data type attribute violation: Cannot convert ? to a numeric(1,0)

(ODBC State = 07006, Native error code = -157)

Error: Unable to insert into table "obztable" using upload_cursor

The data showed in the mobilink verbose output look corrupted. For the failing the failing columns it shows "*** cannot display ***"

For example, the following would have caused the problem:

create table T(

pk int primary key,

c1 char(20) not null default 'charfield',

c2 char(20) not null default 'charfield',

c3 char(20) not null default 'charfield',

c4 char(20) not null default 'charfield',

c5 char(20) not null default 'charfield',

c6 char(20) not null default 'charfield',

c7 char(20) not null default 'charfield',

c8 char(20) not null default 'charfield',

c9 char(20) not null default 'charfield',

c10 char(20) not null default 'charfield',

c11 char(20) not null default 'charfield',

c12 char(20) not null default 'charfield',

c13 char(20) not null default 'charfield',

c14 char(20) not null default 'charfield',

c15 char(20) not null default 'charfield',

c16 char(20) not null default 'charfield',

i1 int null,

)

select * from test_row_buffer where i1 is null

This possible crash has been fixed.

This has been fixed so that the last fetch of a widefetch is now as quick as the last row of a single row fetch.

Note if the cursor type is ESQL SENSITIVE or ODBC DYNAMIC, and isolation level 1 is used, the widefetch of the last row may still be slower than a single row fetch, due to the cursor stability requirement.

For example:

select 1 a group by (a)

This is now fixed.

drop table test;

create table test( c long varchar );

insert into test values ('test');

BEGIN

select 123;

SELECT c from test;

END

This problem has now been fixed.

A second problem with multiple result sets was also fixed. If the previous result set was closed, then the call to determine if there were additional result sets would have failed, making it seem like there were no more result sets for the statement. This problem has also been fixed.

Now, if the second cursor does a delete or update on a row that another cursor has just deleted, the operation will fail and SQLE_NOTFOUND will be returned.

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

Both of these problems have been fixed.

For example:

SELECT id, CAST(id AS CHAR(10)) AS charId FROM T

This should generate a GetId() method and a GetCharId() method. However, the latter was not being generated. This is now fixed.

Also note that the SQL type reported for a CAST expression will be the SQL type of the column, not the CAST type. (In the example above, if id was of type integer, the type for the 揷harId� column will be reported as SQL_S_LONG ).

After the first phase of analysis (the task bar had already reached 100% at least once), the Index Consultant could have displayed an error dialog reporting that 'Table %1 not found' if the user currently running the Index Consultant did not own the table. Subsequent phases of the analysis would not have contained any indexes over the table on which the error was reported. This has been fixed.

As well, when a user was examining the results of a completed analysis, displaying the 'With Virtual Indexes' plan, would have caused the error 'Table %1 not found', if the user did not own the table on which the virtual index was created. The plans could not be viewed if the user did not own all tables over which the query ranges AND the tables in the original query were not fully qualified (can happen for statements captured inside procedures). This has been fixed.

A third issue was that the script generated by the Index Consultant did not have fully qualified table names. This has been fixed. The work around is to add the creator to the table names in the script edit window.

None of these problems would have appeared when the user running the Index Consultant was also the creator of all the tables on which indexes had been recommended.

Note that specifying 'PCTFREE 0' on the ALTER TABLE statement works correctly and can be used after CREATE TABLE to achieve the desired specification.

SQL statement failed: (-194) No primary key value for foreign key '<role name>' in table '<fk table name>'

if the remote database was blank padded and the download stream contained one or more rows that violated foreign key constraints on tables in the publication being synchronized. Now dbmlsync will go through its normal RI cleanup procedures in this case. These procedures generally result in the rows that violate the foreign key constraints being deleted.

Example:

create procedure GetTest1( ) as

begin

select c0 from ( select testA0 as c0 from TEST_A

union

select testA0 as c0 from TEST_A ) as ALLTEST( c0 )

end

call GetTest1() ;

'\xhh\xhh...', where h is a hexadecimal digit.

Repro:

run BUG4272.sql

-> gpf

Select causing gpf:

SELECT

ps.jahrnummer,

ps.perinummer

FROM

op, fvp,

fvs,

ps

WHERE ps.Perinummer=fvs.perinummer

and ps.Jahrnummer=fvs.Jahrnummer

and fvp.FiBuV_Id=op.FiBuV_Id

and fvp.FiBuV_PosZaehler=op.FiBuV_PosZaehler

AND fvs.FiBuV_Id=op.FiBuV_Id

and

(

( ps.JahrNummer = 2000

and ps.PeriNummer >= 1

or ps.JahrNummer > 2000 and ps.JahrNummer < 2002

or ps.JahrNummer = 2002 and ps.PeriNummer <= 12

)

or

(

ps.Jahrnummer >= 2000 and ps.JahrNummer <= 2002)

)

For example, the following query showed the problem.

SELECT 1

FROM ((tab1 T7 , tab1 T9)

FULL OUTER JOIN tab2 T10 ON T9.col3 = T10.col2)

LEFT JOIN tab2 T11 ON T10.col2 = T11.col3

WHERE T7.col1 = T9.col1

For example, the following query

SELECT T4.col3 a1,T1.col2 a2,avg(DISTINCT T3.col2) a3,max(T4.col2) a4,

min(T2.col3) a5,count(T4.col2) a6,list(T2.col2) a7,

sum(T4.col3) a8,sum(T2.col1) a9,sum(T3.col3) a10,max(T4.col3) a11,

count(T2.col3) a12

FROM tab5 T1

JOIN tab4 T2 ON T1.col1 = T2.col2

RIGHT OUTER JOIN tab5 T3 ON T2.col3 = T3.col3

JOIN view5 T4 ON T3.col2 = T4.col3

WHERE ( T4.col1 + T3.col1 >= ALL

( SELECT T3.col3 - T1.col3 - T2.col2 - T3.col3 + T1.col2

+ T3.col3 + T2.col2 + 0 FROM tab5 T1

JOIN view4 T2 ON T1.col3 = T2.col3

JOIN tab3 T3 ON T2.col1 = T3.col2 WHERE T3.col2 <= 398 ))

OR (T1.col2 + 0 >= ALL

( SELECT T2.col3 - T1.col2 * 0 FROM tab3 T1

JOIN view5 T2 ON T1.col2 = T2.col3 WHERE ( T2.col3 - T1.col3

+ 1 = ANY

( SELECT T1.col2 * 0 FROM tab5 T1

JOIN tab1 T2 ON T1.col1 = T2.col3 ))

OR (T2.col3 <= 350 ) ) )

GROUP BY T4.col3, T1.col2

HAVING T4.col3 >= T4.col3

INTERSECT

SELECT T2.col2 + T1.col2 * 0 a1, T3.col2 + T1.col2 + 0 a2, T2.col2 * 0

a3, T1.col3 - T3.col1 a4, T1.col3 * T2.col3 a5, T1.col3 + T2.col3 -

T3.col3 - T1.col3 + 1 a6, T3.col1 + T1.col1 + T2.col1 * T3.col3 a7,

T2.col2 + T3.col1 a8, T1.col2 + 1 a9, T3.col2 + T1.col2 + 1 a10,

T2.col3 + 1 a11, T1.col3 - T2.col1 - T3.col3 + T2.col1 + T3.col2

+ T1.col3 + T2.col3 * 0 a12

FROM view3 T1

JOIN tab1 T2 ON T1.col2 = T2.col2

JOIN view3 T3 ON T2.col3 = T3.col2

WHERE T1.col2 <> 240

could have crashed the server; the rewrite optimization is the transformation of the HAVING predicate T4.col3 >= T4.col3 into T4.col3 IS NOT NULL.

Two examples:

SELECT T2.col3 a2

FROM qts324622 T2

RIGHT OUTER JOIN qts324622 T3 ON T2.col3 = T3.col3

WHERE T2.col2 = ALL

( SELECT col4 from qts324622 where col1 > col2 and col2 > col1 )

SELECT *

FROM qts324622 T1

LEFT OUTER JOIN qts324622 T2 ON T1.col1 = T2.col2

WHERE T1.col1 IN ( T1.col1, T2.col1 )

In both cases, the outer joins were rewritten as regular joins, causing some rows to be missed.

The IN() problem has been fixed in versions 8.0.2 and up, while the ALL() problem has been fixed in versions 9.0.0 and up.

\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay

For example, given a table T with not-null column X, a CHECK constraint of the form

CHECK( T.x is NULL)

would have caused a server on the insertion or update of any row in table T.

In order to fix an invalid schema, use the (fixed) ulxml tool or Schema Painter to write the schema out to as an XML file, then reload it back in. The process of reloading it will correct the table order.

An Example:

select * from systable T key join syscolumn C key join sysuserperm U

Note, any executable that used the Unicode translation library, (dbunic9.dll on 9.0.0 or libunic.dll otherwise), and which also loaded and unloaded the DBLIB or ODBC client libraries could have encountered this problem.

(1) the WHERE clause must have contained a tautology (found in the original WHERE clause or generated by a rewrite optimization)

(2) there were at least two equijoin predicates referring to the same column. (ie, there were at least two predicates of the form "T.col1 = R.col1 AND T.col1 = S.col1").

For example:

T.col1 = R.col1

and

T.col1 = S.col1

and

( (T.col2 >=100000

and T.col2 < 2000000

and expr1 >= 1000)

or (T.col2 >=2000000

and expr1 >= 10000)

)

In this case a tautology was generated by one of the rewrite optimizations, namely "T.col2 < 2000000 OR T.col2 >= 2000000".

Workaround: The bindprocessor command can be used to bind both the client and the server to the same CPU.

These objects included:

- The splash window

- Context menus

- Property sheets, dialogs, wizards

- the editor window for stored procedures and dialogs opened from the editor

The problem was especially noticeable if the taskbar was docked to the left or top edge of the screen. This has been fixed.

There are two work around options:

1)

Install ASA 8.0.2 for Windows CE on the desktop machine, but choose _NOT_ to

deploy to the device.

Then install an EBF for ASA for Windows CE, build 4122 or later, which will allow the install to the device toc work correctly.

2)

Edit <ASA_DIR>\ce\asa_ce.inf with a text editor

In each of the following sections, change "VersionMax" to something larger than

4.1 ( for example, 5.0 )

---------------------------------------------------------------------

[CEDevice.MIPS.30] ; for MIPS processor

ProcessorType = 4000 ; processor value for MIPS R3900

VersionMin = 3.0

VersionMax = 4.0 <-- change this to 5.0

[CEDevice.ARM.30] ; for StrongARM processor

ProcessorType = %ArmProcessor% ; processor value for ARM

VersionMin = 3.0

VersionMax = 4.0 <-- change this to 5.0

[CEDevice.X86.30] ; for X86 processor

ProcessorType = x86 ;

VersionMin = 3.0

VersionMax = 4.0 <-- change this to 5.0

---------------------------------------------------------------------

Also, if a usage error now occurs, a message is appended to the -oe error log file on all platforms.

For example:

select * from t0 where t0.c2 in (select t1.c2 from t1 where t1.c2 in (select t2.c2 from t2 where t2.c2 in

(select t3.c2 from t3 where t3.c2 in (select t4.c2 from t4 where t4.c2 in (select t5.c2 from t5 where t5.c2 in

(select t6.c2 from t6 where t6.c2 in (select t7.c2 from t7 where t7.c2 in (select t8.c2 from t8 where t8.c2 in

(select t9.c2 from t9 where t9.c2 in (select t10.c2 from t10 where t10.c2 in (select t11.c2 from t11 where t11.c2 in

(select t12.c2 from t12 where t12.c2 in (select t13.c2 from t13 where t13.c2 in (select t14.c2 from t14 where t14.c2 in

(select t15.c2 from t15 where t15.c2 in (select t16.c2 from t16 where t16.c2 = 30))))))))))))))))

Cannot generate UltraLite collation sequence for <name of collation>

would be displayed. This was corrected.

Note that this bug affected the table "Data" tab in the ASA plug-in for Sybase Central as well. Both are now fixed.

1. The default size for a CHAR field is now 1. It was zero, which was not valid.

2. The up/down buttons for the spin boxes used to edit the size, scale, and precision fields are now enabled properly. Previously, clicking on a disabled button would still have done something.

3. Typing or pasting an invalid value into a spin box, then saving the table, would have saved a value which was loosely based on the invalid value. Now the last valid value for the spin box is saved.

A workaround for this problem is to restart the server after running the capturing phase of the Index Consultant.

SQL Type Excel Type

TINYINT, SMALLINT Integer

INTEGER, BIGINT Numeric

FLOAT, REAL, DOUBLE, DECIMAL, NUMERIC Numeric

BIT BoolErr

(everything else) Label

Fetching an ESQL DT_STRING with length zero on a blank padded database could have caused dblib to crash. This case was only possible when using an SQLDA, and has been fixed so that no data is copied (not even the null character).

- dbunload -ar or -an or

- the Sybase Central Unload wizard and a new database file was specified

then the new database would have had a user DBA and the userid used to do the unload would have had the password SQL.

With builds 7.0.4.3469, 8.0.1.3121 or 8.0.2.4279 higher, the error "Invalid user ID or password" would be displayed. Earlier builds did not display any error.

This has now been fixed.

directory will only be affected if the "delete_old_logs" database option is set to 'ON' or 'DELAY'.

select unit_price from product

union all

select NULL from dummy

Previously, the data type of the result would have been desribed as a NUMERIC(30,6) (with default precision and scale settings). Now, it is described as NUMERIC(15,2), the data type of the unit_price column. Explicit conversions to NUMERIC will use (1,0), if the conversion does not provide a precision and scale.

For example:

SELECT cast( NULL as numeric ) A, cast( NULL as numeric(15,2) ) B

will be described as:

A NUMERIC(1,0)

B NUMERIC(15,2)

Now, the behaviour of NULL constants is more consistent with that of other constants, where the precision and scale is selected to be as small as possible.

The workaround for this problem is to not change the command delimiter option.

This has been corrected. The following types are now considered signed.

SQL_C_NUMERIC or SQL_NUMERIC

SQL_DECIMAL

SQL_C_FLOAT or SQL_REAL

SQL_C_DOUBLE or SQL_DOUBLE

SQL_BIGINT

SQL_C_SBIGINT

SQL_C_LONG or SQL_INTEGER

SQL_C_SLONG

SQL_C_SHORT or SQL_SMALLINT

SQL_C_SSHORT

The rest are unsigned types including SQL_C_TINYINT or SQL_TINYINT and SQL_C_STINYINT since ASA does not support a signed tinyint.

The call db_start_database was returning 0 and setting the SQLCODE to SQLE_ALIAS_CLASH (-77) if the database was already running. Non-zero is now returned and the SQLCODE is now set to 0 since this also is a successful condition.

This has been fixed so that available cache memory is not reduced by unsupported utility_db statements.

These included the following types and sample values:

tinyint 255

bigint 9223372036854775807

unsigned bigint 18446744073709551615

unsigned int 4294967295

unsigned smallint 65535

A tinyint type was treated as a signed value when it is not. A bigint type was treated as a 32-bit value when it is not. An unsigned bigint type was treated as a signed, 32-bit value when it is not. An unsigned int type was treated as a signed value when it is not.

An unsigned smallint type was treated as a signed value when it is not. These datatypes are now handled correctly.

The syntax for image backups is now:

BACKUP燚ATABASE

DIRECTORY燽ackup-directory

[燱AIT燘EFORE燬TART燷

[燱AIT燗FTER燛ND燷

[燚BFILE燨NLY燷

[燭RANSACTION燣OG燨NLY燷

[燭RANSACTION燣OG燫ENAME燵燤ATCH燷燷

[燭RANSACTION燣OG燭RUNCATE燷

[ ON EXISTING ERROR ]

If the -s command line option for DBBACKUP is used to cause a BACKUP DATABASE statement to be executed, the ON EXISTING ERROR clause will be included by default. If the -y option is specified for DBBACKUP, this clause is not added. When -y is not specified, any attempt to overwrite an existing file will cause an error to be returned. No prompting to replace files will be done when -s is specified.

This would only have occurred if:

- the table had a nullable column before the blob column

- an index column followed the blob column

- the data for the column before the blob column was NULL

This has been fixed, but a workaround is to make sure there are no index columns following any blob columns.

- the called procedure was called in a FROM clause

- the called procedure used a WITH clause to specify the schema

- the calling procedure was called more than once with no intervening event that would have caused the procedure definition to be unloaded

would have caused a server crash. This has been fixed.

Example:

Q1:

select *

from T

where (T.X = c1 and T.Y = c2) or

(T.X =c3 and T.Y = c4) or

(T.X = c5 and T.Y = c6) or

(T.X =c7 and T.Y = c8) or

(T.X = c9 and T.Y = c10) or

(T.X =c11 and T.Y = c12)

Q2:

select *

from T

where T.X IN ( c1, c3, c5, c7, c9, c11) and T.Y IN (c2, c4, c6, c8, c10, c12)

and T.X IN ( (c1, c2), (c3, c4), (c5, c6), (c7,c8), (c9,c10), (c11,c12) )

For example:

t.findBegin();

<specify search criteria using t.set*(...)>

t.findFirst();

t.delete();

while( t.findNext() ) {

t.delete();

}

would have skipped some rows because delete() modified the search criteria. If there were an odd number of rows matching the search criteria, this approach would have deleted rows that did not match the search criteria.

Table.delete(), Table.truncate(), and Table.deleteAllRows() have now been changed so as to cancel all edit and search modes.

This has now been fixed so that communication errors no longer occur.

For example:

t.findBegin();

<specify search criteria using t.set*(...)>

t.findFirst();

t.delete();

while( t.findNext() ) {

t.delete();

}

would have skipped some rows because delete() modified the search criteria. If there were an odd number of rows matching the search criteria, this approach would have deleted rows that did not match the search criteria.

Table.delete(), Table.truncate(), and Table.deleteAllRows() have now been changed so as to cancel all edit and search modes.

For example:

t.findBegin();

<specify search criteria using t.set*(...)>

t.findFirst();

t.delete();

while( t.findNext() ) {

t.delete();

}

would have skipped some rows because delete() modified the search criteria. If there were an odd number of rows matching the search criteria, this approach would have deleted rows that did not match the search criteria.

Table.delete(), Table.truncate(), and Table.deleteAllRows() have now been changed so as to cancel all edit and search modes.

Attempting to use connection strings such as "...;dbf=\\server\share\dir\my.db;..." would have succeeded only if the server myengine was already running (even if the database my.db wasn't running), but would have failed if myengine was not running, due to this problem.

This has been fixed so that quoted command line arguments of the form "\\server\share\etc" no longer removes the first back slash.

Note that running a database from a file server can corrupt the database and is generally not recommended.

(1) rewrite SELECT .. INTO statement as an EXECUTE IMMEDIATE statement

(2) rewrite SELECT .. INTO statement as an INSERT statement (the table inserted into must be created first in this case)

For example:

create table T (c varchar(100) NOT NULL,

b int NOT NULL,

PRIMARY KEY (c, b) );

select ulplan( 'SELECT * from T WHERE T.c = ? and T.b = ? ');

The plan for the above query wouldn't contained an index scan, when in fact the primary key index would have been appropriate to be used here. This is now fixed.

(1) the duplicate IN list must have been on a base or view column (e.g., T.X IN (2,3))

(2) the duplicate IN list must have appeared in a disjunct with another IN list on the same column (e.g., "(T.X IN (4, 5) OR T.X IN (2,3))" )

(3) the WHERE clause was in Conjuctive Normal Form

This is now fixed.

This was not a requirement if the subquery appeared inside an argument to an aggregate function as in the following:

select manager_id, max( (select emp_id from employee where salary=e.salary) ) from employee e

group by manager_id

This has now been fixed.

driver=Adaptive Server Anywhere ...;links=tcpip{port=...;host=...}

would have succeeded, but attempting to use a connection string with round braces:

driver=Adaptive Server Anywhere ...;links=tcpip(port=...;host=...)

would have failed. The problem has now been corrected

Error in file upgrad60.sql at line 3134 with sqlcode -116

SQL error (-116) -- Table must be empty

Upgrade failed

The upgrade fails on attempting to add a NOT NULL column with a default value to a non-empty table in a single alter table statement. The fix was to make the column NOT NULL later using a second alter statement.

A work around is to synchronize all publications, delete all subscriptions and synchronization users, upgrade to 9.0.0 and then recreate the users and subscriptions.

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

host variable, there was a chance the server would have crashed. This problem

has been fixed.

CREATE VIRTUAL INDEX testidx ON USER1.tab1(col1)

CREATE VIRTUAL INDEX testidx ON USER2.tab1(col1)

However, they were incorrectly both resolving to the same table and hence the second statement failed with an error that the index already exists. This has now been fixed.

For example, the following queries would have returned a column described as length 32767:

SELECT CAST( NULL AS CHAR )

--> now CHAR(0)

SELECT 'abc' UNION ALL SELECT NULL

--> now CHAR(3)

SELECT '' UNION ALL SELECT NULL

--> now CHAR(0)

SELECT IF 1=1 THEN 'abc' ELSE NULL ENDIF

--> now CHAR(3)

operations occur.

reversed; that is, the utilities are always sorted by similar functionality.

N = (page_size - 112) / 8

union branches were permitted with 32-bit engines, and at most:

N = (page_size - 112) / 16

were allowed with 64-bit engines.

For 2K pages and 32-bit engine, this was about 242 branches of a union. This assertion failure no longer occurs for unions with a large number of branches.

list of owners.

INSERT INTO T( x ) SELECT CAST( NULL AS NUMERIC )

For other column types, there was a possibility that the value returned from @@identity would be incorrect after inserting a NULL value. The correct value should be 0. This problem is now fixed.

The START AT clause does not accept 0 as a valid value, and should have given an error message. After this change, the following error message is given:

INVALID_CURSOR_RANGE 09W07 -674L

"statement's size limit is invalid."

For example:

select R.x, R.y, DT.y dty

from R,

( select top 20 y from T order by 1 ) dt

This crash has now been fixed.

For example, a query of the form:

SELECT min( R.y )

FROM R

WHERE R.x = ?

should be converted to:

SELECT MIN( R.y)

FROM ( SELECT FIRST R.y

FROM R

WHERE R.x = ? and R.y IS NOT NULL

ORDER BY R.x ASC, R.y ASC ) as R(y)

(assuming that an index exists on R(x,y) ).

Further, a query in a stored procedure that used SQL variables (CREATE VARIABLE or DECLARE) or procedure/function parameters, would not have allowed the optimization when a query was optimized for plan caching. A symptom of this is that a stored procedure would execute more slowly after a few initial iterations, and a query in the procedure met the conditions for this optimization. A work-around would be to set MAX_PLANS_CACHED=0 to prevent plan caching.

Both these problems have now been fixed.

Now the server will no longer go to 100% CPU usage or cause all connections to hang when processing a TDS cancel. If the server is unable to send the TDS cancel response for 60 seconds, it will drop the connection.

This change also fixes the case where the server could have crashed if a connection queried another connection's last request time at the instant that the other connection was being created.

- plans generated during the so-called "training period", when the values of any variables are evaluated prior to optimization (and can be considered known constants), and

- a plan generated without knowledge of the values of those variables, hence representing a "generic" plan.

Unfortunately, estimated costs from the optimizer alone were insufficient criteria with which to base this decision. Now, strict plan equivalence is necessary prior to marking a plan as reuseable for subsequent invocations of the procedure.

As a workaround, users may turn plan caching off entirely by setting the option MAX_PLANS_CACHED to 0.

Note: The file ".isqlSettings9" should be deleted after applying this fix (this is the file in which the initial file dialog directories are saved). The location of this file varies, depending on the operating system used.

Note, unlike Windows, this type of drive information may not be readily available on some Unix versions Therefore, depending on the flavour of Unix and the type of drive, it may not be possible to determine the drive type and "UNKNOWN" will be returned.

For example, in the following, the predicate N1.N_NAME = 'GERMANY' appears in two conjuncts and the second appearance is changed to N1.N_NAME IN ('GERMANY', 'FRANCE') by IN-list merging.

(N1.N_NAME = 'GERMANY' or N2.N_NAME = 'GERMANY')

and (N1.N_NAME = 'FRANCE' or N2.N_NAME = 'FRANCE')

and (N1.N_NAME = 'GERMANY' or N1.N_NAME = 'FRANCE')

and (N2.N_NAME = 'FRANCE' or N2.N_NAME = 'GERMANY')

This has been fixed. Note that this is the same problem that was partially fixed for 328387.

This has been fixed so that Sybase Central now reports the error and no longer crashes.

ALTER TABLE t1 RENAME t2

the statement would fail the second time the procedure was called, with the error:

Table 't2' not found

This has been fixed.

A workaround is to execute the statement using EXECUTE IMMEDIATE.

are retained in the .scUserPreferences42 file, in the same way that column widths are retained for other items.

class CInP1OutP2Accessor

{

public:

CComVariant m_varP1;

CComVariant m_varP2;

BEGIN_PARAM_MAP(CInP1OutP2Accessor)

// SET_PARAM_TYPE( DBPARAMIO_INPUT ) // Default

COLUMN_ENTRY_TYPE(1, DBTYPE_VARIANT, m_varP1)

SET_PARAM_TYPE( DBPARAMIO_OUTPUT )

COLUMN_ENTRY_TYPE(2, DBTYPE_VARIANT, m_varP2)

END_PARAM_MAP()

};

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

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

In a related problem, if an INPUT statement did not include a table name, and the file format was not "SQL", an error message should have been displayed but was not. Now, the error message is properly displayed.

Setting the environment variable LD_ASSUME_KERNEL:

export LD_ASSUME_KERNEL=2.4.1

can be used as a work around to resolve the hanging problem. Please see the RedHat 9.0 RELEASE-NOTES for further details.

Servers from version 8.0.2 and above, do not experience this issue and therefore the setting of LD_ASSUME_KERNEL should not be necessary to run these servers on RedHat 9.0.

For example:

create table t (c1 int);

alter table t add c2 int compute( (select c1+1) )

This problem has now been resolved.

A work-around is to edit the .odbc.ini file directly and add the appropriate information into the [ODBC Data Sources] section, or to use a third party driver manager tool for maintaining the file.

Set table = Connection.Open("MultiIndex_Table")

table.Open("Non_Primary_Index")

table.Columns("non_primary_index_column").Value = value

This error was caused by only checking the primary index for allowable column sets. This has now been fixed to check the index that was used to open the table.

As an example, assume that a procedure USER1.TEST already existed in the database and the procedure USER2.TEST did not exist. Further, assume that USER2 was able to see and modify the procedure owned by USER1. Now, if USER2 executed an "ALTER PROCEDURE TEST" statement, then the server would have resolved the procedure name as "USER1.TEST" and correctly modified that procedure. However, the statement put in the transaction log would have incorrectly referred to procedure "USER2.TEST".

This problem has now been fixed. Note that the problem has an impact only when the logged statement needs to be replayed for any reason.

START DATABASE 'mydb.db' AS "-myName"

This was a specific instance of the way quoted identifiers were handled by dbisql in general. Dbisql had required that all characters in any quoted identifier had to be alphabetic or numeric. This was an incorrect requirement (any character should valid) and has been fixed.

In a related issue, the STOP DATABASE statement did not work if the database name contained a hyphen. This has also been fixed.

select * from Table_1 where

not exists(select * from Table_2 where

Table_2.X = Table_1.X )

The cached expression had to satisfy one of the following conditions:

- the expression referenced tables which changed from one call of the procedure to another (e.g., new rows are being added to those tables)

(2) the expression referenced the stored procedure's parameters, which changed from one call of the procedure to another. This is now fixed.

buttons' text. Now, no ampersands are displayed in the buttons' text and the Alt key can be used to make a selection by typing the desired button's keyboard shortcut.

As a workaround, use Regional Settings control panel to select English as the current language or in the application set the culture to any english-based (en-??) country specific culture: Thread.CurrentThread.CurrentUICulture = new CultureInfo( "en-US" )

Unfortunately, applying the logs incorrectly might have actually worked. For example, if instead of applying the backup log to the backup database first, the current log file was applied to the backup database, it would have applied successfully. Again this is because the log offsets were not correctly updated. This was unfortunate, since all of the transactions that were in the backup log at the time the backup would have been lost.

This has now been fixed, the log offset of the current log file is now updated properly when using the BACKUP DATABASE statement with the TRANSACTION LOG TRUNCATE option. This problem would not have occurred when using dbbackup.exe.

- Creating an environment

- Connecting through TCP/IP

- Disconnecting

- Destroying the environment

THis problem is now fixed.

State information (the current row in the result set) is maintained if a persistent name is provided for the ULConnection.PrepareStatement call, and Close is not called on the ULResultSet, or if it is called after the ULPreparedStatement.Close method has been called.

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

the cost of disk I/O for the proxy tables. This has been fixed.

create table stats(c1 int, c2 char(10))

create index stats on stats(c1, c2 )

insert into stats select row_num, 'Bogus' from rowgenerator

create statistics stats

The important things to note are:

1. Column c2 is a character column with size greater than 7 bytes

2. The database is case insensitive

3. There is an index with c2 as a trailing column

4. The relative number of rows that have the same value for C2 is quite large ( 100% for 'Bogus')

5. Statistics have been explicitly generated, so they are presumably in a good state

6. The number of rows in the table that have the same value for C2 for any single value of C1 is relatively small (1 row for each value of C1).

Now, consider a predicate "c2 = 'bogus'" which will return 100% of the rows. Note that the value used in the predicate has a capitalization that is different from the actual values in the table. The statement

select first estimate( c2, 'bogus' ) est from stats

will return 100 which is the correct selectivity of the predicate and the optimizer will likely be able to come up with an efficient plan for executing a query with that predicate. Now assume that a query is executed that looks for rows with specified values for C1 and C2. An example of such a query is:

select count(*) from stats where c1 = 5 and c2 = 'bogus'

Since the number of rows returned is very small (1 row mentioned in (6) above), the server will likely use an index on C1, C2. If that happens, then after executing the above query, the server will update the statistics for C2 in such a manner that the resulting selectivity of C2 = 'bogus' will now be grossly inaccurate. In our example

select first estimate( c2, 'bogus' ) est from stats

will now return 0.39% instead of the correct value of 100%. This degradation in the statistics for C2 can now result in poor plans for queries involving the predicate.

This problem has now been fixed.

Note, existing database objects with the LATERAL keyword must be recreated.

"Ultralite Database deletion attempt on ul_udb_xxxx.pdb generated error code 10509"

would still have been displayed. This is now fixed.

Many ODBC functions, such as SQLDescribeCol, SQLGetTypeInfo, and SQLBindCol, are affected by this change. Uniqueidentifier columns can be bound as SQL_C_CHAR or SQL_C_WCHAR. When this is done, binary uniqueidentiers (SQL_C_GUID) are converted from binary to the uniqueidentifier string form with hyphens. For example, the 16-byte binary value 0x41dfe9efdb9111d28c43006008d26a6f is converted to and from the 36-byte character string "41dfe9ef-db91-11d2-8c43-006008d26a6f". If the bind type is SQL_C_WCHAR, the resulting string is 72 bytes in length.

Also, SQLGetInfo() with SQL_CONVERT_GUID is now supported, and SQLGetInfo() with SQL_CONVERT_xxx now reports all the conversions permissable with the CONVERT function. Previously, only a small subset of the permissable conversions was reported.

DATE columns were written as character records rather than date records. This would typically have prevented importing data from a .DBF file into an existing table, if the table contained any DATE columns and the .DBF file had been created by DBISQL.

Importing .DBF file into a database, and having DBISQL create the table automatically, would have created a TIMESTAMP column for DATE fields, rather than a DATE column.

When attempting to import a NULL value for a DATE, DBISQL would report that it "Cannot convert to a timestamp" SQLCODE=-157, SQLState="07006".

These problem are now fixed when connecting using the iAnywhere JDBC Driver.

The second and third problems are fixed for connections using jConnect.

SELECT *

FROM T WITH table-hint

while the following syntax with brackets would have caused a syntax error:

SELECT *

FROM T WITH ( table-hint )

Both syntaxes are now supported.

In addition, if both the userid and password were specified, but either contained a semicolon, then the userid and password would also both have been ignored. This has also been fixed.

Attempting to apply a second EBF to an 8.x NetWare install, would also have failed to upgrade the server executable if the filesystem was on a NetWare server mounted using the Windows Client for NetWare. This was due to a problem in the install script, and has been fixed.

For example, the following query expression:

Select quantity from product

Union

Select quantity from product

Order by 1

can now be written as:

Select quantity from product

Union

Select quantity from product

Order by quantity

The first query specification of the UNION is used to determine the names to be matched with the ORDER BY clause:

Select quantity as qq from product

Union

Select quantity from product

Order by qq

The collations affected were:

856HEB

932JPN

936ZHO

949KOR

950TWN

EUC_CHINA

EUC_KOREA

For example:

SET OPTION PUBLIC.USER_DEFINED_OPTION = 'ON'

SET OPTION "DBA".USER_DEFINED_OPTION = 'OFF';

SET TEMPORARY OPTION "DBA".USER_DEFINED_OPTION = 'ON'; <- this would have failed silently

An attempt to temporarily set a user-defined option now results in SQLSTATE 42W45 (TEMPORARY_NOT_ALLOWED).

dbltm.exe and has been fixed.

This problem could also occur for characters from other languages. Affected characters include those from Greek and Coptic, Cyrillic, Latin Extended A and B, and IPA extensions (characters in the Unicode range U+100 through U+4FF.)

- an ASCII file was being imported. and

- the wizard was to create a new table for the data, and

- the file started with an empty line.

This has been fixed.

For example:

CONNECT USING "dsn = ASA 9.0 Sample"

would not have succeeded because of the spaces around the equals sign. This problem is now fixed.

(At the remote)

DELETE FROM Child WHERE foreign_key = 1;

DELETE FROM Parent WHERE primary_key = 1;

COMMIT;

(synchronize)

The second delete from the remote (ie. from Parent) would have been applied before the first delete, causing a referential integrity violation in the consolidated during upload. Prior to this change, the behaviour was to generally delete from Parent before deleting from Child. Now, the behaviour is to delete from Child before deleting from Parent.

Note that these clauses cannont be used if the ON ENGINE clause is also specified.

For example, the HTML output from the service:

CREATE SERVICE qts335115demo TYPE 'HTML' AUTHORIZATION OFF USER DBA

AS SELECT 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32;

would have been incorrect.

- an ASCII file was being imported. and

- the wizard was to create a new table for the data, and

- the data on the first line of the file ended with a NULL value.

The symptoms of this problem were that the "Preview" table in the Import wizard did not display all of the columns in the file, and after clicking the "Finish" button, the new table would contain all but the last column. This is now fixed.

<column> LIKE <pattern>

where <pattern> is a constant that contains no wild-cards is equivalent to:

CAST( <column> AS LONG VARCHAR) = CAST( <pattern> AS LONG VARCHAR )

In the case that <column> has a character domain, this comparison permits an index to be used. It is also possible to use an index if <column> is an exact numeric domain if we infer an additional predicate:

<column> = CAST( CAST( <pattern> AS LONG VARCHAR ) AS <column domain> )

Previous to this change, the ASA optimizer did not infer this new predicate, and an index could not be used for a query such as the following:

SELECT *

FROM SYS.SYSTABLE

WHERE table_id LIKE '1'

After this change, the additional sargable predicate is inferred, and an index can be used. Note that the original string-comparison predicate must be retained. The following query returns 0 rows:

SELECT *

FROM SYS.SYSTABLE

WHERE table_id LIKE '1.0'

while the related query:

SELECT *

FROM SYS.SYSTABLE

WHERE table_id = '1.0'

does return a row. Because of this, the predicate " table_id LIKE '1.0' " is treated as:

table_id = CAST( '1.0' AS INT ) AND CAST( table_id AS LONG VARCHAR ) = '1.0'

"Can't start HTTP listener on address 0.0.0.0:x"

This has been fixed.

For example:

CREATE PROCEDURE p ()

BEGIN

CREATE VARIABLE i INT;

SET i = 1;

SELECT i;

END

CREATE VIEW v AS SELECT * FROM p() WITH (c1 INT);

This has now been fixed.

On Unix, this resulted in a crash, as the overflow caused the cache size to be set to zero.

Now the cache size is both stored and interpreted in terms of kilobytes only.

only contained null values. The has been fixed.

This has been fixed so that the SQLCONNECT environment variable no longer affects dbspawn.

For example:

create procedure test_proc()

begin

-- Binky's simple test procedure

select * from customer;

end

This has been fixed. A workaround for this problem is to turn off scanning statements:

SQLSetStmtAttr( stmt, SQL_NOSCAN, SQL_NOSCAN_ON );

SELECT cast(null as long varchar) as c1 INTO #temp

then attempting to insert a string longer than 1 byte would have caused the string to be truncated. This has been fixed.

table = conn->OpenTableWithIndex( "X", "c1_index" );

table->FindBegin();

table->Set( "c1", 2 );

if( table->Find() ){

table->Delete();

while( table->FindNext() ) {

table->Delete();

}

}

The incorrect behaviour of the table->Delete() function would have caused the table->Find() call to have failed. This problem has been fixed by changing the behaviour of the table->Delete() function so that the cursor remains pointing at the deleted row until the next fetch. So the above code now behaves as expected.

A workaround is to change the WHERE condition to explicitly rule out the unwanted rows. In the example above, it would involve changing the WHERE condition to be as follows:

WHERE emp_id = 1 AND emp_id IS NOT NULL

code "200 OK" rather than "400 bad request". This has been corrected.

For example:

select

R.row_num,

( select coalesce( sum( D.dummy_col ), 999 )

from sys.dummy D

where D.dummy_col = R.row_num

) as subselect

from rowgenerator R

where R.row_num < subselect

This has been fixed. Subquery optimization is now not applied in cases where the aggregates are used in expressions handling NULL arguments.

For example:

SELECT *

FROM R FULL OUTER JOIN T

ON R.X = T.X and R.Y = 10

This has been fixed.

- The -n or -u options were specified on the dbmlsync commandline.

- The remote database was running on CE.

- Either the database collation or the operating system code page was not CP1252. Not all operating system code pages or database collations were affected by this problem, but most multibyte character sets and some single byte character sets were affected.

When the synchronization failed, the dbmlysnc log would have look like the following:

I. 12/18 16:05:34. Connecting to remote database

I. 12/18 16:05:34. Loading synchronization information

I. 12/18 16:06:00. Disconnecting from remote database

In most cases, this problem occurred when the function csconvert() was unable to convert strings between the operating system charset and the database charset.

Now, when the csconvert function fails dbmlsync will try several other methods to convert strings between the operating system and database charsets. If all these methods fail, a warning message will be issued and dbmlsync will attempt to continue with the synchronization based on the assumption that the publication name and user name specified on the commandline are specified in the database charset. In some cases this will be true, otherwise the synchronization will fail later, when dbmlsync is unable to find the MobiLink user, publication or subscription in the database.

This problem cannot be entirely resolved, but the above changes should reduce its frequency. If synchronizations do fails with the new warning, there are some work arounds that can be tried:

- Choose publication and user names so that they consist only of 7-bit ASCII characters (ASCII values 0-127)

- Have the database and operating system use the same charset. The synchronization is unlikely to fail, although the warning may be issued.

- In some cases the problem can be resolved by using UTF8 as the collation for the remote database.

This has been corrected. The maximum permissable value for -ti is 32767 (which is approximately 22 3/4 days). If any larger value is specified, an error message is displayed (Error in command near "ti") along with the usage message.

process will only migrate non-system tables.

An additional fix was made to the Migrate Database wizard, so that the drop-down list of users on the Tables page, now contains only users which have at least one non-system table.

Connection ID <num>: "<user>" connected to database "<db name>" over <protocol>

where protocol can be "HTTP" or "HTTPS". Another message is also displayed containing the character set conversion status, which will be one of the two formats:

Connection ID <num>: Server character translation is enabled, but not required

using client character set "<client charset>"

or

Connection ID <num>: Server character translation will occur

database character set is "<db charset>"

using client character set "<client charset>"

This ordering problem has been corrected.

--(*vendor(vendor-name), product(product-name) extension *)--

In addition to this syntax, there was a shorthand syntax of the form:

{extension}

For example:

select --(*vendor(iAnywhere), product(SQL Anywhere) d 1999-11-04 *)-- from dummy;

or

select {d 1999-11-04} from dummy;

The standard syntax, now deprecated in ODBC 3.x, was to allow for keyboards that do not support the curly braces characters, (such as the IBM 029 keypunch).

The extension syntax was supported, but the standard syntax was not supported correctly. This has been fixed.