Skip to Main Content
  • Questions
  • Problems with WHERE var IN (:list)...

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Jim.

Asked: October 31, 2006 - 12:30 pm UTC

Last updated: November 01, 2006 - 8:52 am UTC

Version: 10g (10.2.0)

Viewed 1000+ times

You Asked

I am trying to build a static cursor using an embedded SQL query that has an 'IN' clause containing a variable number of parameters. The purpose of this query is to pull from a table the subjects to run the query against. Since the actual query takes 160 lines, the pertinent line is as follows:

EXEC SQL DECLARE count_cursor CURSOR FOR
SELECT
a.value,
COUNT(DISTINCT a.column1 || a.column2 || a.column3)
FROM
table1 a,
table2 b
WHERE
a.key = b.key
AND a.key2 IN (:list_key2)



This is what :list_key2 is assigned in Pro*C. Key2 is a NUMBER(9):

if ( ( exit_status != EXIT_FAILURE ) && ( *rpt_type == 'N' ) )
{
while ( sqlca.sqlcode == 0 )
{
/* Get a row. */
EXEC SQL FETCH payer_cursor
INTO :key2;
if ( sqlca.sqlcode != 0 )
{
fprintf( stderr, "SQLCODE = %d, MESSAGE = %s\n",
sqlca.sqlcode, sqlca.sqlerrm.sqlerrmc );

exit_status = EXIT_FAILURE;
}
else if ( sqlca.sqlcode == 0 )
{
/* Append payer to the payer list */
strcat( payer_list, ", " );
sprintf( tmp_buf, "%d", key2 );
strcat( payer_list, tmp_buf );
}
}
}


I realize this is pseudocode, but the concept is clearly represented, and I hope is simple enough to generate an example.

and Tom said...

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Varing in lists

Jim, October 31, 2006 - 5:43 pm UTC

The answer was helpful in understanding the problem, but PL/SQL does not seem to be an
option. Now that I understand the problem better, a coworker suggested building
a temp table to put the list into, then do a subselect within the 'IN'. I had
already written the program using method 3, and it worked. My tech lead wanted
me to use static SQL and solve the problem without the slower dynamic SQL.

The size of the list presents a problem. Right now, the list is from 1 to 3
elements, but in about a year, it will become from 1 to 75. My mission is to
write this so that it does not need to be revisited in a year to make it still
work.

The reason PL/SQL is not an option is that this is only one program in an
environment not set up for PL/SQL. When I enabled PL/SQL, it broke the queries
in embedded SQL using Pro*C. I am not an expert, but I also have no experts to
tap into to get past that. If I am doing something that could be remedied, I
would like to know how.

Rechecking shows the client is 10.2.0, but the Oracle engine is 9.2.0.4.0.

Tom Kyte
October 31, 2006 - 6:25 pm UTC

why not?

does your lead tech understand that all sql in oracle is dynamic sql and static sql is just a trick of the programming language and that dynamic sql is just as fast (or slow) as static sql???

you do not precompile for plsql here - you can reference plsql in your sql naturally.



Varying in list

Jim, November 01, 2006 - 8:13 am UTC

My tech lead is located over 2000 miles from me and contact is by email or teleconference. I am seeking a technical solution, and the political solutions will have to wait until I am hired.

I have decided to solve the problem by using 'IN (SELECT ...) to supply a superlist to select against. That will satisfy the need for speed and placate my team lead. The dynamic cursor was easy once I figured it out, and was easy to apply to other cursors in the same program with similar problems. Doing a subselect will have it's own problems, but they are due to the initial need for a dynamic cursor, and not technical problems. I will have to navigate to a common solution to three sets of business rules.

Tom Kyte
November 01, 2006 - 8:52 am UTC

you may do whatever you like, my point is:

dynamic sql is not by design nor implementation slower than "static" sql, "static" sql is a "trick of the language", all sql in Oracle is dynamic sql.

The link I pointed you do shows PLSQL (pipelined functions) as well as "pure sql" approaches.



Varying In list

Jim, November 01, 2006 - 10:04 am UTC

Thanks, Tom. I need to reread that link carefully, as I missed the "pure SQL" approach. Knowing that 'static' SQL is the same as 'dynamic' SQL will help me convince my tech lead that the time trying to get away from dynamic cursors is just spinning tires. Your rapid response has been a real help.