Re: modification required to pass Sun's CTS - Mailing list pgsql-jdbc

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@postgresintl.com
www.postgresintl.com
ICQ #14675561
jabber davecramer@jabber.org
ph (519 939 0336 )