By default, the SQL Anywhere dbinit utility creates a case-insensitive database for the CHAR collation. This can be changed through the use of the -c command line switch on dbinit, and the setting may differ for the NCHAR collation for national character sets. Whether or not a database supports case-sensitive comparisons can be determined via the DB_Extended_property() function, for example SELECT DB_EXTENDED_PROPERTY( 'Collation', 'CaseSensitivity');

Completely optional cascading drop clause

SQL Anywhere supports both double quotes or '[' (Microsoft syntax) for quoted identifiers. Note that quoted identifiers are controlled through the QUOTED_IDENTIFIER connection option.

Slight variation on CreateTableString. The command used to create a multiset table.

Command used to create a table.

Assume that temporary table rows should be preserved across COMMITs.

In SQL Anywhere, the syntax, DECLARE LOCAL TEMPORARY TABLE ..., can also be used, which creates a temporary table with procedure scope, which may be important for stored procedures.

Retrieve a set of default Hibernate properties for this database.

Only needed if the Dialect does not have SupportsForeignKeyConstraintInAlterTable.

We assume that applications using this dialect are NOT using SQL Anywhere's snapshot isolation modes.

We assume that applications using this dialect are NOT using SQL Anywhere's snapshot isolation modes.

SQL Anywhere does not require dropping a constraint before dropping a table, and the DROP statement syntax used by Hibernate to drop a constraint is not compatible with SQL Anywhere, so disable it.

Only needed if the Dialect does not have SupportsForeignKeyConstraintInAlterTable.

Enforce the condition that this query is read-only. This ensure that certain query rewrite optimizations, such as join elimination, can be used.

Lock rows in the cursor explicitly using INTENT row locks.

SQL Anywhere does not support FOR UPDATE NOWAIT. However, the intent is to acquire pessimistic locks on the underlying rows; with NHibernate one can accomplish this through setting the BLOCKING connection option. Hence, with this API we lock rows in the cursor explicitly using INTENT row locks.

SQL Anywhere does support FOR UPDATE OF syntax. However, in SQL Anywhere one cannot specify both FOR UPDATE OF syntax and FOR UPDATE BY LOCK in the same statement. To achieve INTENT locking when using FOR UPDATE OF syntax one must use a table hint in the query's FROM clause, ie. SELECT * FROM FOO WITH( UPDLOCK ) FOR UPDATE OF ( column-list ). In this dialect, we avoid this issue by supporting only FOR UPDATE BY LOCK.

Lock rows in the cursor explicitly using INTENT row locks.

Aggregate SQL functions as defined in general. This is a case-insensitive hashtable!

Set this to false if no table-level primary key constraint should be generated when an identity column has been specified for the table. This is used as a work-around for SQLite so it doesn't tell us we have "more than one primary key".

Whether this dialect has an identity clause added to the data type or a completely separate identity data type.

SQL Anywhere uses DEFAULT AUTOINCREMENT to identify an IDENTITY column in a CREATE TABLE statement.

The keyword used to insert a generated value into an identity column (or null). Need if the dialect does not support inserts that specify no column values.

The class (which implements IIdentifierGenerator) which acts as this dialects identity-style generation strategy.

The name of the SQL function that transforms a string to lowercase

The class (which implements IIdentifierGenerator) which acts as this dialects native generation strategy.

SQL Anywhere currently supports only "VALUES (DEFAULT)", not the ANSI standard "DEFAULT VALUES". This latter syntax will be supported in the SQL Anywhere 11.0.1 release. For the moment, "VALUES (DEFAULT)" works only for a single-column table.

For limit clauses, indicates whether to use 0 or 1 as the offset that returns the first row. Should be true if the first row is at offset 1.

SQL Anywhere supports both double quotes or '[' (Microsoft syntax) for quoted identifiers.

The keyword used to create a primary key constraint

Get the select command used retrieve the names of all sequences.

Does this dialect support using a JDBC bind parameter as an argument to a function or procedure call?

Does this dialect support definition of cascade delete constraints which can cause circular chains?

Does this dialect support column-level check constraints?

SQL Anywhere supports COMMENT ON statements for a wide variety of database objects. When the COMMENT statement is executed an implicit COMMIT is performed. However, COMMENT syntax for CREATE TABLE, as expected by NHibernate (see Table.cs), is not supported.

Expected LOB usage pattern is such that I can perform an insert via prepared statement with a parameter binding for a LOB value without crazy casting to JDBC driver implementation-specific classes...

Part of the trickiness here is the fact that this is largely driver dependent. For example, Oracle (which is notoriously bad with LOB support in their drivers historically) actually does a pretty good job with LOB support as of the 10.2.x versions of their drivers...

Does this dialect support adding foreign key constraints via alter table? If not, it's assumed they can only be added through create table.

Does the dialect support the syntax 'drop table NAME if exists'

Does the dialect support the syntax 'drop table if exists NAME'

Does the dialect support propagating changes to LOB values back to the database? Talking about mutating the internal value of the locator as opposed to supplying a new locator instance...

For BLOBs, the internal value might be changed by: {@link java.sql.Blob#setBinaryStream}, {@link java.sql.Blob#setBytes(long, byte[])}, {@link java.sql.Blob#setBytes(long, byte[], int, int)}, or {@link java.sql.Blob#truncate(long)}.

For CLOBs, the internal value might be changed by: {@link java.sql.Clob#setAsciiStream(long)}, {@link java.sql.Clob#setCharacterStream(long)}, {@link java.sql.Clob#setString(long, String)}, {@link java.sql.Clob#setString(long, String, int, int)}, or {@link java.sql.Clob#truncate(long)}.

NOTE : I do not know the correct answer currently for databases which (1) are not part of the cruise control process or (2) do not {@link #supportsExpectedLobUsagePattern}.

SQL Anywhere supports FOR UPDATE over cursors containing outer joins.

Does this dialect support parameters within the select clause of INSERT ... SELECT ... statements?

Does this dialect support "pooled" sequences. Not aware of a better name for this. Essentially can we specify the initial and increment values?

SQL Anywhere's implementation of KEYSET-DRIVEN cursors does not permit absolute postioning. With jConnect as the driver, this support will succeed because jConnect FETCHes the entire result set to the client first; it will fail with the iAnywhere JDBC driver. Because the server may decide to use a KEYSET cursor even if the cursor is declared as FORWARD ONLY, this support is disabled.

Is this dialect known to support what ANSI-SQL terms "row value constructor" syntax; sometimes called tuple syntax.

Basically, does it support syntax like "... where (FIRST_NAME, LAST_NAME) = ('Steve', 'Ebersole') ...".

If the dialect supports {@link #supportsRowValueConstructorSyntax() row values}, does it offer such support in IN lists as well?

For example, "... where (FIRST_NAME, LAST_NAME) IN ( (?, ?), (?, ?) ) ..."

Does this dialect support sequences?

Supports splitting batches using GO T-SQL command

Does this dialect support referencing the table being mutated in a subquery. The "table being mutated" is the table referenced in an UPDATE or a DELETE query. And so can that table then be referenced in a subquery of said UPDATE/DELETE query.

For example, would the following two syntaxes be supported:

• delete from TABLE_A where ID not in ( select ID from TABLE_A )
• update TABLE_A set NON_ID = 'something' where ID in ( select ID from TABLE_A)

Are subselects supported as the left-hand-side (LHS) of IN-predicates.

In other words, is syntax like "... {subquery} IN (1, 2, 3) ..." supported?

Does this dialect support subselects?

Does this dialect support table-level check constraints?

Is it supported to materialize a LOB locator outside the transaction in which it was created?

Again, part of the trickiness here is the fact that this is largely driver dependent.

NOTE: all database I have tested which {@link #supportsExpectedLobUsagePattern()} also support the ability to materialize a LOB outside the owning transaction...

Does this dialect support the UNIQUE column syntax?

Does this dialect support adding Unique constraints via create and alter table ?

Gives the best resolution that the database can use for storing date/time values, in ticks.

Should LOBs (both BLOB and CLOB) be bound using stream operations (i.e. {@link java.sql.PreparedStatement#setBinaryStream}).

Does the LIMIT clause take a "maximum" row number instead of a total number of returned rows?