Stored procedure call escape ({call ...}) support

Lance Andersen - Oracle Lance.Andersen at
Thu Jan 3 08:02:04 PST 2013

the escape for call is supported on the various Statement objects.  However the level of functionality is limited based on the type of Statement that you use (return output parameters, set input parameters..etc)
On Jan 3, 2013, at 8:52 AM, Mark Rotteveel wrote:

> I am currently rewriting the JDBC escape implementation in Jaybird, and reviewing the implementation of CallableStatement related to the {call ...} escape.
> Currently I am wondering if I should support the call-escape in Statement and PreparedStatement as well. The current implementation in Jaybird does support this right now (probably accidentally given the current escape parser, and with some caveats), but it provides some challenges with regard to double or maybe even triple parsing the statement, which I could simply remove if I only need to support it in CallableStatement.
> On the one hand only the CallableStatement javadoc ( mentions the call-escape,

Correct as this is from  JDBC 1.0 and CallableStatement is really the best vehicle as it provides all of the functionality (though nothing prevents you from using the other Statement objects
> but on the other hand section 6.4 of JDBC 4.1 mentions:
> "Support for calling stored procedures using the execute method on the Statement, PreparedStatement, and CallableStatement interfaces only requires that [..]"

This is for Java EE which requires support of stored procdures
> Which to me seems to imply that {call ... } should also be supported on Statement and PreparedStatement. Is that assumption correct?
yes but see my 1st response above
> Also with regard to the {? = call ...} escape, is it allowed to extend this escape to support multiple output parameters (eg {?,?,? = call ...} or maybe {(?,?,?) = call ...}

no it is not allowed
> or should cases with multiple output parameters simply only be supported with the Firebird specific syntax?

yes as  Escape syntax is supposed to be generic not implementation specific


> Mark
> -- 
> Mark Rotteveel

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at

More information about the jdbc-spec-discuss mailing list