Problems with bound parameters in oracle text queries

Question

Executing the following query I get strange effects depending on the value I pass for the search string :str ...
With value "Med" everything works fine and I get the results I have expected.
But when passing "Tech" as value to the query, the result is ORA-20000 and DRG-50901 (Oracle Text error, syntax error in parser)
select * from (
SELECT /*+ FIRST_ROWS */ *
FROM SERVICE_CATEGORY sCat
WHERE (
CONTAINS ( sCat.SERVICE_CATEGORY_C , '<QUERY><textquery grammar="CONTEXT"><progression><seq>{'
|| :str || '}</seq><seq>'
|| :str || '%</seq><seq>%'
|| :str || '%</seq><seq>fuzzy({'
|| :str || '},1,100,WEIGHT)</seq></progression></textquery></QUERY>', 1 ) <> 0 AND
sCat.SERVICE_TYPE_C IS NULL AND sCat.SERVICE_SPECIALTY_C IS NULL )
ORDER BY score(1) DESC ) where rownum <= 20
When passing the search string "Tech" directly to the query without using bound paramters, everthing works fine:
select * from (
SELECT /*+ FIRST_ROWS */ *
FROM SERVICE_CATEGORY sCat
WHERE (
CONTAINS ( sCat.SERVICE_CATEGORY_C , '<QUERY><textquery grammar="CONTEXT"><progression><seq>{'
|| 'Tech' || '}</seq><seq>'
|| 'Tech' || '%</seq><seq>%'
|| 'Tech' || '%</seq><seq>fuzzy({'
|| 'Tech' || '},1,100,WEIGHT)</seq></progression></textquery></QUERY>', 1 ) <> 0 AND
sCat.SERVICE_TYPE_C IS NULL AND sCat.SERVICE_SPECIALTY_C IS NULL )
ORDER BY score(1) DESC ) where rownum <= 20
Also, when I use >0 instead of <>0 everthing works fine:
select * from (
SELECT /*+ FIRST_ROWS */ *
FROM SERVICE_CATEGORY sCat
WHERE (
CONTAINS ( sCat.SERVICE_CATEGORY_C , '<QUERY><textquery grammar="CONTEXT"><progression><seq>{'
|| 'Tech' || '}</seq><seq>'
|| 'Tech' || '%</seq><seq>%'
|| 'Tech' || '%</seq><seq>fuzzy({'
|| 'Tech' || '},1,100,WEIGHT)</seq></progression></textquery></QUERY>', 1 ) > 0 AND
sCat.SERVICE_TYPE_C IS NULL AND sCat.SERVICE_SPECIALTY_C IS NULL )
ORDER BY score(1) DESC ) where rownum <= 20
Does anybody have an explanation for the strange effect when using a bound parameter in combination with <> 0?

Answer 1

I don't know why your query using bind variables is giving you a problem but use of literal inside CONTAINS second argument is encouraged anyway over bind variables starting with 10gR2 (unless you are confident enough about the cost and selectivity of your queries to the extent that you can use SQL hint instead). The literal replacement feature introduced in release 9i caused a hard-parse if the literal value changed but starting with 10gR2, at least for CONTAINS, a hard-parse is avoided even if the literal value has changed as long as the cost and selectivity is similar to an existing cursor in the library cache (e.g. within 10%).
Faisal