You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Turner, John" <JT...@AAS.com> on 2002/08/21 13:58:42 UTC

RE: OFF-TOPIC: Pointers to CallableStatement docs? (SOLVED)

First, thanks to everyone who replied with help and suggestions.  Quick
summary of the problem: stored procedure with 5 input parameters, 5 output
parameters, and a return status.  Normally, you would think that the correct
CallableStatement would be:

cstmt = sConn.prepareCall("{? = call sp_validate_pwd(?, ?, ?, ?, ?, ?, ?, ?,
? ,?)}");

However, this did not work, no matter what arrangement was used for
declaring and registering the inputs and outputs.  What did finally work is
ignoring the return status.  I don't know why, but the return status was
never explicity declared in the stored procedure, though it did show up in
the MS Query Analyzer as a parameter for that stored procedure.  Apparently,
since it was never explicitly declared, it's not required, and including a
spot for it in the call threw all of the other parameter positions off by
one.

So, the code snippet that is currently working is:

// prepare the stored procedure statement
try {
	cstmt = sConn.prepareCall("{call sp_validate_pwd(?, ?, ?, ?, ?, ?,
?, ?, ? ,?)}");
} catch (SQLException sqle) {
      sqle.printStackTrace();
}

// set the input parameters
try {
	cstmt.setString(1, strUserID);
      cstmt.setString(2, strPassword);
      cstmt.setString(3, strRemoteAddress);
      cstmt.setString(4, strReferURL);
      cstmt.setString(5, strHTTPUserAgent);
} catch (Exception e) {
      e.printStackTrace();
}
        
// register the output parameters for the stored procedure
try {
	cstmt.registerOutParameter(6, Types.BIT);
      cstmt.registerOutParameter(7, Types.BIT);
      cstmt.registerOutParameter(8, Types.BIT);
      cstmt.registerOutParameter(9, Types.CHAR);
      cstmt.registerOutParameter(10, Types.VARCHAR);
} catch (Exception e) {
      e.printStackTrace();
}

The moral of the story being that unless a parameter is explicitly declared
within the procedure itself, it's not available and shouldn't be accounted
for when preparing the statement, regardless of what sort of tool is used to
manage the stored procedures, like MS Query Analyzer.  Maybe this is a
bug/feature of MS Query Analyzer, where a return status is included in the
list just for housekeeping purposes, or maybe it's true regardless of
database platform.  Either way: unless a parameter is explicitly declared,
don't count on it in your CallableStatement.

Thanks again to everyone who helped, even though it was off-topic. 

John Turner
jturner@NOSPAM.aas.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Hang in ServletOutputStream.print

Posted by Paul Harvey <Pa...@fdgroup.com>.
We have a servlet which appears to hang randomly (for times up to minutes)
in ServletOutputStream.print. This is with tomcat 4 and JDK 1.4 on Solaris
7.

Has anyone else come across this problem?

I am posting this on behalf of a colleague in Oz who is trying to sort this
out.

We cannot reproduce the problem here with the same config, JDK, and tomcat
... but we are running on Solaris 6.

The machine in Oz is missing a bunch of recommended patches ... so this
could be the root of the problem.

I will try installing Sol 7 and seeing then if I can reproduce the problem
... but if anyone else has seen similar then any information could prove
useful

Thanks,

Paul.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>