PreparedStatement, SELECT...WHERE FIELD_ABC IN (?,?,?) Number of ? not fix

Question

Hi,
I want to use the PreparedStatement for a SELECT Query, The SELECT query has a where clause in which there is a condition like:
WHERE FIELD_ABC IN (?,?,?) AND FIELD_XYZ=?
The number of parameters passed in IN clause are not fixed and they are changing dynamically so I can not put fixed number of '?' in the query.
Please help me with ideas of achieving the advantages of PreparedStatement for SELECT query with IN clause. Is there some way to achieve this? Can I pass an Array of values for parameters of IN Clause?

Answer 1

>
What?! That definitely will NOT work.
The only hope you have is to build up a query with the
appropriate number of "?"s. Have two strings, one for
the prefix part (everything upto the "IN ("), and one
for the suffix (everything including and after the
Then write a little loop that appends the appropriate
number of "?, " to the prefix (and take care to not
have an extra "," after the last one), and then append
the suffix, and prepare that query.good luck preparing the a query every time you send one, so why prepare it?!
>
Other ideas: insert the values into a temporary table
with one column, and join the column (that you have in
the IN clause) to that table.
So again, every time you execute a query, you will execute multiple 'insert' queries for it. wonderful!
I'd say if you are most of the time having like 3 values inside the IN cluase, prepare a query that has (?,?,?) and when you send an actual query check if you have 3 values, use it, otherwise just execute the query.
This can be generalized, assume that one third of your queries have 2 values, another one third have 3 values, and the rest of the queries have various number of values inside the IN clause, In this case you prepare two queries, first with (?,?), second with (?,?,?). When you have a query, decide which prepared query to use or if you just send unprepared query.
This approach however does not help if the number of values inside the IN clause in your queries is uniformly distributed over a large range
>
This would be a very useful JDBC addition, by the way:
a JDBC escape to handle IN clauses (just like the JDBC
clauses to handle outer joins, etc.)