Re: modification required to pass Sun's CTS

Oliver,

This is what we have to pass.

rsSch.createTab("Numeric_Tab",sqlp,conn);

msg.setMsg("get the CallableStatement object");
cstmt = conn.prepareCall("{call Numeric_Proc
(?,?,?)}");

msg.setMsg("Register the output parameter");
cstmt.registerOutParameter
(1,java.sql.Types.NUMERIC,15);
cstmt.registerOutParameter
(2,java.sql.Types.NUMERIC,15);
cstmt.registerOutParameter
(3,java.sql.Types.NUMERIC,15);

msg.setMsg("execute the procedure");
cstmt.executeUpdate();
msg.setMsg("invoke getBigDecimal method");
oRetVal = cstmt.getBigDecimal(1);
String sRetStr = rsSch.extractVal
("Numeric_Tab",1,sqlp,conn);
msg.setMsg("extracted MAX_VAL from
Numeric_Tab");
maxBigDecimalVal = new BigDecimal(sRetStr);

msg.addOutputMsg("" + maxBigDecimalVal, "" +
oRetVal);

if( (oRetVal.compareTo(maxBigDecimalVal) ==
0) )
{
msg.setMsg("getBigDecimal returns
the Maximum value ");
}
else
{
msg.printTestError("getBigDecimal()
did not return the Maximum value", "test getBigDecimal Failed!");

}

On 1-Jun-05, at 5:37 PM, Oliver Jowett wrote:

> Dave Cramer wrote:
>
>> The cts calls executeUpdate on a function with out parameters.
>> I know the API says that executeUpdate is only to be used when no
>> results are expected,
>> but this is the way the test is.
>> Any thoughts on changing executeUpdate to allow results to be
>> returned?
>>
>
> That's almost certainly the wrong thing to do. executeUpdate is
> quite specific about throwing exceptions when a resultset is returned.
>
> I think the confusion arises from JDBC not considering an OUT
> parameter to be a "result". i.e. you can have a function with OUT
> parameters that returns a resultset, but equally you can have one
> that doesn't return a resultset; and the values in the resultset
> (if any) are separate to the returned OUT parameter values.
>
> Given that the backend OUT parameter support is implemented as a
> resultset, maybe it makes sense to hide the resultset of a function
> with OUT parameters entirely, since it's really an implementation
> artifact? Then executeUpdate shouldn't need changes.
>
> Does the CTS have the reverse case, i.e. requiring a function that
> has both OUT parameters and a resultset? Seems like that'd be hard
> to support at all with the current scheme..
>
> -O
>
>

Dave Cramer
davec(at)postgresintl(dot)com
www.postgresintl.com
ICQ #14675561
jabber davecramer(at)jabber(dot)org
ph (519 939 0336 )