com.sybase.jdbcx
Interface SybPreparedStatement

All Known Subinterfaces:

SybCallableStatement

public abstract interface SybPreparedStatement

extends PreparedStatement, SybStatement

Sybase extensions to the PreparedStatement interface.

See Also:

PreparedStatement, Connection.prepareStatement(java.lang.String)

Method Summary

void	setBigDecimal(int parameterIndex, BigDecimal x, int precision, int scale) The NUMERIC datatype for Sybase has explicit declarations for the precision (total number of digits) and scale (digits after the decimal).

Methods inherited from interface java.sql.PreparedStatement

addBatch, clearParameters, execute, executeQuery, executeUpdate, getMetaData, setArray, setAsciiStream, setBigDecimal, setBinaryStream, setBlob, setBoolean, setByte, setBytes, setCharacterStream, setClob, setDate, setDate, setDouble, setFloat, setInt, setLong, setNull, setNull, setObject, setObject, setObject, setRef, setShort, setString, setTime, setTime, setTimestamp, setTimestamp, setUnicodeStream

Methods inherited from interface com.sybase.jdbcx.SybStatement

getConnection, getFetchSize, getResultSetConcurrency, getSybMessageHandler, setCursorName, setFetchSize, setSybMessageHandler

Method Detail

setBigDecimal

public void setBigDecimal(int parameterIndex,
                          BigDecimal x,
                          int precision,
                          int scale)
                   throws SQLException

The NUMERIC datatype for Sybase has explicit declarations for the precision (total number of digits) and scale (digits after the decimal). The java.math.BigDecimal just implicitly figures out what the scale is, and has no limit on precision. When jConnect converts a 'setBigDecimal' parameter from BigDecimal to NUMERIC is has to guess on precision and scale.

Unfortunately, if the parameter is being used for an in/out stored procedure parameter the guess really matters and we often guess wrong. Suppose the stored procedure is declared as follows:

     CREATE PROCEDURE myNumericProc(@p1 NUMERIC(6,0) OUTPUT) AS
     BEGIN
          SELECT @p1 = @p1 * 10
     END
 

If the input value is BigDecimal("1") jConnect will send a NUMERIC(1,0). This results in a numeric overflow when the server returns 10 - doesn't fit.

OTOH, if we just decide to send the value as NUMERIC(38,0) - the maximum precision, or any other precision > 6, the server will raise an error because our precision is too high for the stored procedure declaration.

The only way to correct this would be to query the server on the declared precision/scale of stored procedure parameters, but that would require jConnect to have a much more complete SQL parser so it could determine name/order of stored procedure and parameter name, and would incur a significant performance overhead for additional round-trips to the database to gather this information.

This alternate signature setBigDecimal extension allows a jConnect JDBC application to explicitly indicate what NUMERIC precision and scale should be used.

Parameters:

parameterIndex - index of the parameter being set.

x - value being sent

precision - the maximum number of digits in the value of x

scale - the maximum number of digits to the right of the decimal in the value of x.

Throws:

SQLException - if precision > 38, precision < 1, or scale < 0, or precision < scale, or if the value x does not fit in the given precision/scale range specified.