Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (Français) » SQL Anywhere 11 - Changes and Upgrading » What's new in version 10.0.0 » SQL Anywhere » Behavior changes

 

SQL statements

  • 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.