> Is there a way to pass in the entire WHERE clause as a parameter?
yeah, but then there's no point in using a stored procedure, because the
advantage of the stored procedure is that the database can figure it out
ahead of time ("compile" it, as it were), and if the retrieval condition
columns are known, it can't do that
> or how about using LIKE and sending in an array?
not sure how that would work, but LIKE is notoriously inefficient
if you say LIKE "foo%" then an index might be used
but if you say LIKE "%foo%" then no index will be used
if you have an array of primary keys, then that is efficient (and you gain
little by having a stored proc)
i assume you will be using something like
WHERE pkey IN ( n, m, ... )
where n etc. are key values
but this begs the question of where those pkeys came from in the first place
if they were obtained from a previous query, the question then arises, why
do you need to query again, why weren't the tables in this second query
included in a JOIN in the first
rudy
____ • The WDVL Discussion List from WDVL.COM • ____
To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED]
Send Your Posts To: [EMAIL PROTECTED]
To change subscription settings to the wdvltalk digest version:
http://wdvl.internet.com/WDVL/Forum/#sub
________________ http://www.wdvl.com _______________________
You are currently subscribed to wdvltalk as: archive@jab.org
To unsubscribe send a blank email to [EMAIL PROTECTED]
