Programming interfaces

Web services performance enhancements HTTP services now support automatic connection pooling to maximize the effect of plan caching and benefit from the potential performance improvement. See Developing web service applications in an HTTP web server.

Support for customized ODBC driver names To facilitate the installation and registration of multiple independent copies of the SQL Anywhere ODBC driver on a client system, you can now assign a customized name to the ODBC driver. See Configuring the ODBC driver.

ANSI-only ODBC driver for Unix Versions of Unix ODBC driver managers that define SQLWCHAR as 32-bit (UTF-32) quantities cannot be used with the SQL Anywhere ODBC driver that supports wide calls since this driver is built for 16-bit SQLWCHAR. For these cases, an ANSI-only version of the SQL Anywhere ODBC driver is provided. This version of the ODBC driver does not support the wide call interface (SQLConnectW for example). See Using a UTF-32 ODBC driver manager on Unix.

DBTools: no_reload_status bit field added to an_unload_db structure A new bit field, no_reload_status, has been added to the an_unload_db structure. You can use no_reload_status to suppress table and index progress messages on reload. See an_unload_db structure.

New SQL Anywhere TYPE-2 JDBC driver A new TYPE-2 JDBC driver is now available for JDBC applications to use when connecting to SQL Anywhere. Unlike the iAnywhere JDBC driver, which sits on top of ODBC and can be used to connect to a variety of servers via ODBC, the SQL Anywhere JDBC driver connects to SQL Anywhere only and does not require the SQL Anywhere ODBC driver to be installed or registered.

The SQL Anywhere JDBC driver comes with a JDBC 3.0 driver and a JDBC 4.0 driver.

Note

If you currently use the iAnywhere JDBC driver, it is strongly recommended that you change to the new SQL Anywhere JDBC driver.

The JDBC 4.0 driver automatically loads and registers itself.

To use the version 3.0 SQL Anywhere JDBC driver, you must load the sybase.jdbc.sqlanywhere.IDriver class that implements the java.sql.Driver interface and registers the SQL Anywhere JDBC driver with the JDBC driver manager. Once loaded, connections using the SQL Anywhere JDBC driver can be made by using the URL jdbc:sqlanywhere:connection-string-parameters. The connection-string-parameters are the standard connection parameters required to connect to SQL Anywhere. Note that the application no longer needs to specify DRIVER= or DSN= in connection-string-parameters when using the SQL Anywhere JDBC driver. See JDBC support.

New support for JDBC Statement class methods Previously, the JDBC drivers only supported the addBatch and executeBatch methods of the PreparedStatement class. The JDBC drivers now also support the addBatch, clearBatch, and executeBatch methods of the Statement class. Due to the fact that the JDBC specification is unclear on the behavior of the executeBatch method of the Statement class, the following notes should be considered when using this method with the SQL Anywhere JDBC drivers:

Processing of the batch stops immediately upon encountering a SQL exception or result set. If processing of the batch stops, then a BatchUpdateException will be thrown by the executeBatch method. Calling the getUpdateCounts method on the BatchUpdateException will return an integer array of row counts where the set of counts prior to the batch failure will contain a valid non-negative update count; while all counts at the point of the batch failure and beyond will contain a -1 value. Casting the BatchUpdateCount to a SQLException provides additional details as to why batch processing was stopped.
The batch is only cleared when the clearBatch method is explicitly called. As a result, calling the executeBatch method repeatedly will re-execute the batch over and over again. In addition, calling execute( sql_query ) or executeQuery( sql_query ) correctly executes the specified SQL query, but does not clear the underlying batch. Hence, calling the executeBatch method followed by execute( sql_query ) followed by the executeBatch method again will execute the set of batched statements, then execute the specified SQL query, and then execute the set of batched statements again.

See JDBC support.

RESUME statement returns row counts or the row estimate The RESUME statement now returns the number of rows in the result set or the row estimate for the next result set in a procedure call. In previous versions, this row count was not available after the RESUME statement. To get the RESUME row count, both the client application and the database server must be SQL Anywhere 12.

This change affects the following client APIs:

API	Function call or statement affected	Row count returned by
Embedded SQL	RESUME statement	SQLCOUNT field
ODBC	SQLMoreResults function	SQLRowCount function
OLE DB	IMultipleResults::GetResult method	pcRowsAffected output parameter
PHP	sasql_next_result function	sasql_num_rows function
PHP	sasql_stmt_next_result function	sasql_stmt_num_rows function
SQL Anywhere C API	sqlany_get_next_result function	sqlany_num_rows function
SQL Anywhere Ruby API	sqlany_get_next_result function	sqlany_num_rows function
SQL Anywhere Python API	nextset method	rowcount attribute

PHP $_SERVER variable now contains all variables required by CGI/1.1 The $_SERVER variable in PHP now contains all variables required by CGI/1.1 when executing an HTTP request. See The PHP external environment.

For more information on the variables required by CGI/1.1, see Section 4 of RFC3875: [external link] http://www.ietf.org/rfc/rfc3875

Fine control over Python data type mapping added to sqlanydb To control how database types are mapped into Python objects when results are fetched from the database server, conversion callbacks can be registered. See Database type conversion.

New DBLib fill_sqlda_ex function The fill_sqlda_ex function provides additional functionality over fill_sqlda. In particular, a flag can be provided to preserve the DT_LONGVARCHAR, DT_LONGNVARCHAR and DT_LONGBINARY types when filling the descriptor. See fill_sqlda_ex function.

Silent install feature selection now possible On Windows, SQL Anywhere components or features may be selected or omitted for install from the command line. For example, specify AT32=1 to select the 32-bit administration tools. See Using a silent install for deployment.

TDS now supports 6 digit precision for time and datetime data Applications that connect to SQL Anywhere using jConnect 7 and later, or Open Client 15.5 and later, can now retrieve 6 digits of precision when querying time or datetime data.