Forum Discussion

dejvid-smth's avatar
New Contributor
5 years ago

Parametrized JDBC broken in Ready API 3.1

I am using JDBC Test Step in SoapUI to select data from an Oracle database. My sql statement contains parameters and looks something like this:

select ID
where REF_ID = :ref_id
order by UPDATED_AT desc
fetch first 1 rows only

The query contains ref_id parameter. I have defined the parameter in the configuration of the test step with valid value.


In Ready API 3.0 this worked fine. After update to Ready API 3.1 this does not work anymore. I am getting this error:

2020-02-19 10:10:46.912 - Error getting response; java.sql.SQLException: Missing IN or OUT parameter at index:: 1

When I replace the parameter in the query with specific value it works but I want to use parameters in my queries. 


One thing to note is that when I open the JDBC's Query Builder using the Build Query button and I execute my query with parameters there it works as expected.

6 Replies

  • richie's avatar
    Community Hero
    Hi dejvid-smth,

    So your query worked in v3.0 but now doesnt for v3.1?

    At this point id check the release notes for v3.1 to see if there are any related changes that have introduced a regression.

    Once that is done, id raise a support ticket with Smartbear (sorry im typing this on my phone so i cant provide the link, but youll be able to find it without too much trouble) detailing the issue. This definitely sounds like a regression and is gonna break a lot of peoples tests so its likely Smartbear will try and fix this in a subsequent maintenance release.

    In regards to the fact that the query executes fine in the QueryBuilder function, a couple of people have raised forum posts saying theyre struggling with thr jdbc step but using the QueryBuilder executes the query fine.

    As a short term workaround, could you perhaps downgrade your ReadyAPI! version back down to v3.0 to get you up and running again until Smartbear can resolve the issue? (assuming theres nothing in the v3.1 release notes saying otherwise)

    Hope this helps,

    • richie's avatar
      Community Hero
      Hey dejvid-smth ,

      Ive just reread your post and so youre saying using sql defined parms in the JDBC step with the : identifier is failing, right?

      In all my use of the JDBC step ive never bothered using the parms in the JDBC step this way (using the : identifier/alias).

      Instead ive always used properties like ${Properties#attribute} (sourcing my parm values from values stored elsewhere (i.e. in a Properties step)) or via inline scripting ${=inlinescriptingtodynamicallygeneratethevalue}

      Have you tried this approach rather than sql parms needing the :identifier syntax?


      • dejvid-smth's avatar
        New Contributor

        Hi richie,


        I have tried using the property references via Get Data and that works. Although even a simples use case with : parameter/alias doesn't. I can solve my problem with the property concatenation like you suggested but that is not the point. The parameters are there for a reason and if they don't work it is either a bug or the functionality should be removed :smileyhappy: