Re: Forms 6/FORM_TRIGGER_FAILURE in a POST-QUERY

karturner_at_aol.com (Progger) wrote in message news:<2328f217.0204111802.24142614_at_posting.google.com>...
> Can someone tell me what all the FORM_TRIGGER_FAILURE does in a
> POST-QUERY trigger when raised? Looking at help tells me that is
> flushes the current record.
>
> I have a form that is extremely complex. It has a pre-query trigger
> that sets the default where clause based on what a user wants to query
> on. At this point there is a possibility of 5 different complex where
> clauses. There are (were) 2 other selection criteria that were not
> set up in the pre-query that the post-query trigger is doing a
> FORM_TRIGGER_FAILURE to drop the record that doesn't match. I say
> "were" because one of them I was able to eliminate, but the other
> would be impossible to eliminate. Let me say that ALL of the code
> works exactly as it was designed. Great!....except it is slooooooow.
> The problem has been narrowed down to the raise form_trigger_failure.
> Execute all the code exactly except comment out the raise
> form_trigger_failure, the query returns immediately....more records
> than needed of course.
>
> Also this problem actually started when this unchanged form was
> converted from 4.5 to 6.
>
> Any info would be appreciated!

Hi,
why don't you try to implement the restrictions as a Stored function in the server, and use it in the where clause of you query?

This should be fast.

I think you could do it.

If things are wayyyyyyyyyyyyy too complex, you can use the following techinque:

in varray(1000000) you insert all rows that should be returned from you query.
And in the forms you use Block based on a Procedure instead of block based on a table.

You should return a cursor to
TABLE(v) operator.
e.g.

open c for select * from table(v);

return c;

HTH,
Mihail Daskalov
Brainbench MVP for Oracle Admin Received on Mon Apr 15 2002 - 18:07:40 CEST