--- In IB-Java@y..., rrokytskyy@y... wrote:

> > Sure, just as soon as i get back on the right machine.
> > Unfortunately, in the *production* system it fails, but if i
> > extract the code into a ttest, it succeeds:( I need to find out
> > what else is failing...
>
> Ok, let's wait.

Finally gone through the exception bug. Caused by attempting to
insert too much data into a record (in my case a string). Stack dump
below:

java.sql.SQLException: GDS exception: new record size of bytes is
too big at org.firebirdsql.jdbc.FBPreparedStatement.execute
(FBPreparedStatement.java:833) at
org.firebirdsql.jdbc.FBPreparedStatement.execute
(FBPreparedStatement.java:823) at
org.firebirdsql.jdbc.FBPreparedStatement.executeUpdate
(FBPreparedStatement.java:131) at jdbctest.jdbctest.main
(jdbctest.java:153)

Seems that inserting too long a string has been fixed recently by
adding a data truncation exception to setString... therefore above
stack dump forcibly made to generate record too big error)

However, i think the main problem is with the error handling. If you
look at where the exception is thrown (in writeSQLDatum, GDS_Impl.java
, line 1573)

case SQL_VARYING:
if (((byte[])sqldata).length > xsqlvar.sqllen) {
throw new GDSException(isc_rec_size_err);
}

it only adds the error message to the exception chain, the parameter
isn't added. (presumably caused by the changeover to the new
exception stuff and not changing all the old code? - unless i've
missed something)

Anyway, changed my version to allow (a limited number of )parameters
to be passed to GDSException constructor. Could also change setNext
to return the current exception object to allow chaining in the throw
clause.

Thoughts

JOHN