Sybase supports and implements all methods from the java.sql.SQLException and java.sql.SQLWarning classes. SQLException provides information on database access errors. SQLWarning extends SQLException and provides information on database access warnings.
Errors raised by Adaptive Server are numbered according to severity. Lower numbers are less severe; higher numbers are more severe. Errors are grouped according to severity:
Warnings (EX_INFO: severity 10) – are converted to SQLWarnings.
Exceptions (severity 11 to18) – are converted to SQLExceptions.
Fatal errors (severity 19 to 24) – are converted to fatal SQLExceptions.
SQLExceptions can be raised through JDBC, Adaptive Server, or the native JDBC driver. Raising a SQLException aborts the JDBC query that caused the error. Subsequent system behavior differs depending on where the error is caught:
If the error is caught in Java – a “try” block and subsequent “catch” block process the error.
Adaptive Server provides several extended JDBC driver-specific SQLException error messages. All are EX_USER (severity 16) and can always be caught. There are no driver-specific SQLWarning messages.
If the error is not caught in Java – the Java VM returns control to Adaptive Server, Adaptive Server catches the error, and an unhandled SQLException error is raised.
The raiserror command is used typically with stored procedures to raise an error and to print a user-defined error message. When a stored procedure that calls the raiserror command is executed via JDBC, the error is treated as an internal error of severity EX_USER, and a nonfatal SQLException is raised.
You cannot access extended error data using the raiserror command;
the with errordata clause is not implemented
for SQLException.
If an error causes a transaction to abort, the outcome depends on the transaction context in which the Java method is invoked:
If the transaction contains multiple statements – the transaction aborts and control returns to the server, which rolls back the entire transaction. The JDBC driver ceases to process queries until control returns from the server.
If the transaction contains a single statement – the transaction aborts, the SQL statement it contains rolls back, and the JDBC driver continues to process queries.
The following scenarios illustrate the different outcomes. Consider a Java method jdbcTests.Errorexample() that contains these statements:
stmt.executeUpdate(“delete from parts where partno = 0”); Q2 stmt.executeQuery(“select 1/0”); Q3 stmt.executeUpdate(“delete from parts where partno = 10”); Q4
A transaction containing multiple statements includes these SQL commands:
begin transaction delete from parts where partno = 8 Q1 select JDBCTests.Errorexample()
In this case, these actions result from an aborted transaction:
A divide-by-zero exception is raised in Q3.
Changes from Q1 and Q2 are rolled back.
The entire transaction aborts.
A transaction containing a single statement includes these SQL commands:
set chained off delete from parts where partno = 8 Q1 select JDBCTests.Errorexample()
In this case:
A divide-by-zero exception is raised in Q3.
Changes from Q1 and Q2 are not rolled back
The exception is caught in “catch” and “try” blocks in JDBCTests.Errorexample.
The deletion specified in Q4 does not execute because it is handled in the same “try” and “catch” blocks as Q3.
JDBC queries outside of the current “try” and “catch” blocks can be executed.
