Re: Forms 5, Summary items TOO SLOW!!!

Hi,

[Quoted] [Quoted] Not being able to see your code or your form, i'm guessing at a few things here.

1.
[Quoted]  Are you populating your summary fields by using a post-query trigger?

If you are, make sure that the code in the post query trigger is 'tuned' and [Quoted] [Quoted] uses relevant indexes etc to maximise speed. Also, use an explicit cursor [Quoted] in your post-query trigger as opposed to a select ?? into ?? from table since this doubles up processing because the trigger fires the query twice, [Quoted] once to see if the too_many_rows exception needs to be raised and once for the actual query.

2.
[Quoted] Also, have you got some kind of counter in your form like 'Record 1 of 200'? [Quoted] [Quoted] If so, how are you finding out that you have 200 records? If you use the dreaded last_record, get your record count, first record method in your block, this will also make your processing slower because post-query is fired 200 times! Use count query before interrogating the block.

3.
The first time you return your results, save the first total or totals in a [Quoted] hidden field. When the user updates something, just subtract the old value [Quoted] from the hidden field and add the new. This will save interrogating the DB [Quoted] after every user move.

Hope something from the above helps,

Mark

Sean Zhang wrote in message ...
>Hello, everyone,
>
>We are using Developer 2000 version 2 in Windows 95
>as the client interface to Oracle 8i in SUN.
>We have a block based on <customer_order_items> table,
>when our users edit the items, they want to see some
>summarized data : i.e. total dollar so far? total order quantity so far?
>So we just make a few <display items> as summary of some fields.
>It works perfectly fine as long as the number of rows displayed in the FORM
>less than 50 lines. If an order has more than 200 rows
>( data NOT necessarily saved in the database ) , after a user keyins ( or
>edits)
>a summary field, there is a considerable delay ( like 5 seconds) when the
>user
>wants move the cursor. I understand it's the SUMMARY that causes the delay
>because if I don't use the
>summary field the FORMS processing is much faster.
>
>Suggestions sought: How can we get the LIVE Summary data as the
>user edits a from of larger number of rows without perceived delay? Any
>suggestions and advices are greatly appreciated.
>
>
>Sean Zhang
>mailto:sean_at_cnfei.com
>
>
>
Received on Mon May 24 1999 - 12:19:00 CEST