New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prepared CallableStatement.getMetaData() call throws exception when no input parameters provided [JDBC402] #443
Comments
Commented by: @mrotteveel I am not sure why that even works at all. What happens if you use {?=call test(?)} instead? |
Commented by: Attila Molnár (e_pluribus_unum) Exactly the same. |
Commented by: @mrotteveel Looks like you are right, that check in getSQL should be moved out so it is only done on execute. I will see if I can fix this in Jaybird 2.2.9. As this is a executable stored procedure, technically you should be using getParameterMetaData instead of getMetaData, but out parameters aren't correctly offered in the parameter metadata at the moment... I hope to get it more JDBC compliant with JDBC297 in Jaybird 3.0. |
Modified by: @mrotteveelFix Version: Jaybird 2.2.9 [ 10691 ] |
Modified by: @mrotteveelFix Version: Jaybird 3.0 [ 10440 ] |
Modified by: @mrotteveel |
Commented by: @mrotteveel The code is pretty hairy (and scary). The reason it checks for values set (and registered out parameters) is to determine if all parameters have been "properly" registered before it ask the server to prepare the statement (otherwise it is possible that it tries to prepare a statement with the wrong number of parameters). Removing the check here in getMetaData (and getParameterMetaData) should fix this problem, but only if all out parameters have been registered, otherwise it will still result in a failure when the statement is prepared server side to obtain the metadata (because of the wrong number of parameters). |
Modified by: @mrotteveel |
Commented by: @mrotteveel Removed the check from getSQL, and created new check that is only done before execute, addBatch and as part normal JDBC escape parsing. The check in the normal JDBC escape parsing is slightly dubious, as it might break unintentionally. I will look at this as part of JDBC296 and JDBC297. |
Commented by: Attila Molnár (e_pluribus_unum) Great! When we can expect 2.2.9 to be released? |
Commented by: @mrotteveel I am running the last tests now, and I am trying to get it out the door today. |
Modified by: @mrotteveelstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: Attila Molnár (e_pluribus_unum)
Is related to JDBC297
Is related to JDBC296
Hi Mark!
create or alter procedure test(x integer)
returns (y integer)
as
begin
end
BasicDataSource ds = new BasicDataSource();
ds.setUrl("...");
ds.setUsername("SYSDBA");
ds.setPassword("masterkey");
Connection conn = ds.getConnection();
CallableStatement cs = conn.prepareCall("EXECUTE PROCEDURE test(?, ?)");
cs.registerOutParameter(2, java.sql.Types.INTEGER);
System.out.print(cs.getMetaData().getColumnClassName(1));
Exception in thread "main" org.firebirdsql.jdbc.FBSQLException: Value of parameter 1 not set and it was not registered as output parameter.
at org.firebirdsql.jdbc.FBProcedureCall.getSQL(FBProcedureCall.java:370)
at org.firebirdsql.jdbc.AbstractCallableStatement.getMetaData(AbstractCallableStatement.java:244)
at org.apache.commons.dbcp2.DelegatingPreparedStatement.getMetaData(DelegatingPreparedStatement.java:231)
at org.apache.commons.dbcp2.DelegatingPreparedStatement.getMetaData(DelegatingPreparedStatement.java:231)
getMetaData() calls getSQL() (org.firebirdsql.jdbc.FBProcedureCall), but the latter checks wheter input parameters were set. This check is not needed in this case, getMetaData() should work on a prepared statement.
workaround : cs.setObject(1, null); before cs.getMetaData() call.
Thank You!
Commits: e6cd642 4614b66 21859a9 ecb1e03 6e4f8e1 9d0b139
The text was updated successfully, but these errors were encountered: