1.1.1

java type (for example, if a procedure uses java.util.Date instead of java.sql.Date) then the invocation from the
client side fails.
RENAME
SQLFire does not support the RENAME statement as specified by the SQL-92 standard. A SQLException with
state "0A000" is thrown, although the statement is not treated as a syntactical error.
Updatable Result Sets
SQLFire supports updatable result sets only when the result set is obtained from a JDBC peer client connection
using a SQL query that includes the FOR UPDATE clause. For example, you cannot use the following JDBC
commands to work with an updatable result set:
Statement s = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_UPDATABLE);
String sql = "select * from trade.networth where cid > " + lowCid + " and
cid <= " + highCid;
ResultSet updatableRs = s.executeQuery(sql);
SQLFire does not support the WHERE CURRENT OF clause with an UPDATE or DELETE statement to
perform positioned updates with updatable cursors.
SELECT … FOR UPDATE does not provide updatable result sets for thin client connections. Any attempt to
use the result set to update rows results in an exception or undefined behavior. However the SELECT will obtain
appropriate locks on the affected rows, and afterward an explicit update statement can be executed to update the
rows. Use the JDBC peer client driver instead.
The SELECT … FOR UPDATE statement does not lock any rows if the statement is not part of a transaction.
If you use this statement outside of a transactional context (isolation level Connection.TRANSACTION_NONE)
then a SQLWarning is raised and logged. This occurs because in a non-transactional context, appropriate row
locks are not obtained during the select phase, and the update phase might see a modified row.
In a transaction, SQLFire locks all rows returned in a SELECT ... FOR UPDATE statement. It releases them
only after the result set is closed (with ResultSet.close() or because of a transaction commit or rollback).
SQLFire does not support holdable result sets (ResultSet.HOLD_CURSORS_OVER_COMMIT).
Transaction Isolation Levels
This release of SQLFire supports the READ_COMMITTED, READ_UNCOMMITTED, and
REPEATABLE_READ transaction isolation levels. Any transaction that uses the READ_UNCOMMITTED
level is implicitly upgraded to be READ_COMMITTED. When nothing is specified, then JDBC operations use
TRANSACTION_NONE isolation which denotes the absence of a transaction. However, SQLFire still offers
certain data consistency and atomicity guarantees as described in Understanding the Data Consistency Model
on page 149.
Using Distributed Transactions in Your Applications on page 151 provides an overview of the distributed
transaction implementation and semantics.
Trigger Limitations
This release of SQLFire does not support statement triggers.
UNION, INTERSECT, and EXCEPT Operators
SQLFire does not support any query that has either nested set operators or a set operator with either a join,
function expression, SQL procedure, view, or sub-query. There is no explicit support provided for ORDER BY,
709
vFabric SQLFire Limitations