Skip to content
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

Closed
firebird-automations opened this issue Jul 24, 2015 · 13 comments

Comments

@firebird-automations
Copy link

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

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

I am not sure why that even works at all. What happens if you use {?=call test(?)} instead?

@firebird-automations
Copy link
Author

Commented by: Attila Molnár (e_pluribus_unum)

Exactly the same.

@firebird-automations
Copy link
Author

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.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2.9 [ 10691 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 3.0 [ 10440 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Link: This issue is related to JDBC297 [ JDBC297 ]

@firebird-automations
Copy link
Author

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).

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Link: This issue is related to JDBC296 [ JDBC296 ]

@firebird-automations
Copy link
Author

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.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Commented by: Attila Molnár (e_pluribus_unum)

Great!

When we can expect 2.2.9 to be released?

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

I am running the last tests now, and I am trying to get it out the door today.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment