REVOKE CONNECT statement When the REVOKE CONNECT statement is executed to drop a user, all objects owned by the specified user are dropped along with the user. The REVOKE CONNECT statement now returns an error if the database contains an active view, owned by another user, that is dependent upon an object owned by the user being dropped. See REVOKE statement.
Restrictions on key joins for derived tables Key joins are not allowed for derived tables containing TOP N, START AT, FIRST, ORDER BY, window functions, FOR XML, or recursive tables. See Key joins of views and derived tables.
ALTER SERVER and CREATE SERVER statements The ASAJDBC and ASAODBC server classes have been renamed to SAJDBC and SAODBC, respectively. See ALTER SERVER statement and CREATE SERVER statement.
ALTER statements All ALTER statements now use ALTER as a subclause, instead of MODIFY. If your applications use a MODIFY subclause, you should change them to use the ALTER subclause instead. The MODIFY syntax is still supported but deprecated. This impacts the following statements:
BACKUP statement In previous releases, you could specify the DBFILE ONLY clause with either the TRANSACTION LOG RENAME or TRANSACTION LOG TRUNCATE clause. Specifying DBFILE ONLY with either of these TRANSACTION LOG clauses now results in an error because these are two mutually exclusive types of backup. See BACKUP statement.
COMMENT statement The syntax COMMENT ON LOGIN is no longer supported. Use the syntax COMMENT ON INTEGRATED LOGIN instead. See COMMENT statement.
INSERT statement In SQL Anywhere 10, when using the ON EXISTING SKIP and ON EXISTING ERROR clauses, if the table contains default columns, the server computes the default values even for rows that already exist. As a consequence, default values such as AUTOINCREMENT cause side effects even for skipped rows. In this case of AUTOINCREMENT, this results in skipped values in the AUTOINCREMENT sequence. In previous versions, these computations were not performed on default columns for skipped rows. See INSERT statement.
VALIDATE statements All validation activities, such as executing VALIDATE statements, or running the Validation utility (dbvalid), now require VALIDATE authority; REMOTE DBA permission is no longer accepted for performing validation activities.
The VALIDATE TABLE statement (and VALIDATE MATERIALIZED VIEW) checks for orphaned BLOBs.
The syntax for VALIDATE INDEX has changed to be consistent with the ALTER INDEX statement syntax. The old syntax is still supported, although deprecated. If your applications currently use the VALIDATE INDEX statement, you should change to the new syntax.
For more information on these changes, see VALIDATE statement.
Discuss this page in DocCommentXchange. Send feedback about this page using email. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |