Re: Forms3.0/Post-Query/update rows selected but not displayed

Try using "execute_query(all_records)" instead of a plain execute_query...

I have also done this. Find the name of the first field the cursor goes to after the query. Write a on-new-field-instance trigger for this field.. Inside the trigger do this..

BEGIN
  WHILE :SYSTEM.LAST_RECORD != 'TRUE' LOOP     NEXT_RECORD;
  END LOOP;
END;
FIRST_RECORD; The only problem
with this is every time you navigate the cursor to this field this code will execute when in fact you only want it to execute after a query. I will leave that up to you to figure out.

In article <01bdba28$5444dfe0$a049100a_at_pc743-sode.seurope.ikea.com>, Corinna.Becker_at_memo.ikea.com says...
>
>Hello,
>I have the following problem:
>
>We select several rows and make an update on them using the Post-Query
>trigger. Our problem is that when the number of rows selected is higher
>than the number of rows displayed the trigger does not fire for all rows
>selected but only for the rows displayed. Like this our data is not fully
>updated.
>
>The reason is that when the query has selected the number of rows displayed
>it pauses. It is reactivated e.g. when you press the scroll down key. So
>theoretically our users wouldn't have any problem when they would scroll
>down the whole screen and would then commit when they have reached the last
>row. As the number of data is too high this is not acceptable for them. So
>we have to do it automatically.
>
>But how can we do this? Somehow I have to find a way to force the query not
>to pause. But how can I do that? I tried the procedure "NEXT_SET" to fetch
>the next set of records (and then fire the Post-Query trigger again
>recursively). But NEXT_SET is a restricted procedure and is therefore not
>allowed in the Post-Query trigger.
>
>Maybe someone has a good idea what I can do there. Any help is welcome.
>Best regards
>Corinna
Received on Tue Jul 28 1998 - 09:02:25 CDT