This content has been marked as final. Show 4 replies
I had noticed this, that's why I was leaning towards my custom method involving a dummy table.
I made a test with the dummy table method and it looks like I can successfully check the syntax of both CONTEXT and CTXCAT grammars (via query template), I just found out that I need to insert at least one record, otherwise the text query is not even executed, the optimizer is too smart....
So, unless there is some other method that doesn't require a dummy table, this seems the way to go for me.
I think it makes sense, but can you explain why you want to do this? What's the advantage of running a "pre check" rather than submitting the query and catching the error if it occurs?
Perhaps not really connected, but I'm currently working on a query parser which will take queries in end-user "Google-style" syntax, and convert them into valid Oracle Text queries. Would that help you at all?
Under normal circumstances I wouldn't do this, as you say I'd just run the query and catch the error, but I need to do this inside a report refresh performed via AJAX (using Oracle Apex) and the catch is that when such refresh fails owing to a syntax error, the partial refresh mechanism of APEX becomes broken, so even if you amend the query and submit a new valid string, it won't show up any more.
That's why I need to be sure that the string is valid before running the query, hence the syntax checking function.
The google-style parser sounds interesting, may be I can try to implement it in a future release of my app!