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

Where you say that the block does
 'as SUM of <extented> in this block'

the program may be looping through all the items within your block (maybe 15, maybe 300) to get the summed value. This way, the more records there is, the longer it will take. Try running the form in debug mode to see if this is the case.

If so, a running summary as discussed in Robert Profitt's e-mail and my last idea in my original e-mail may be a quicker solution.

Mark

Sean Zhang wrote in message ...
>Thank you very much for your reply.
>
>My last post many be a little confusing, here is more explain:
>
>The summary block has NO Trigger, NO Code. What I did is just set the
>following:
> <blk>.<Query All Records>="YES"( required for summary block).
> <blk>.<Number of Records Displayed>=15
> then I made a <display item>--<extented> in the block as a Formular item:
>:blk.qty * :blk.price,
> then I made a summary item <total> as SUM of <extented> in this block,
>because I only
> want <total> show once, I set <total>.<Number of Items Displayed>=1.
>
>The Sum Item <total> actaully doesn't get data from server, It instantly
>changes as user
> edits the Qty/Price and then moves cursor in the client interface (Windows
>95). I am
> pretty sure the <total> is not a sum of server data, becasue the user
won't
>save
>the changes until he finishes all editing ( maybe a few hundred lines).
>What happens
> is that when the user gets more lines (rows) in the windows, the time for
>the cursor
> to leave qty/price after change is longer. I guess the SUM does a
>recalcution for ALL
> rows even you only change one row a time.
>
>
>Once again, thank all of you for your help.
>
>>Mark Gumbs <mgumbs--AT--hotmail.com> wrote in message
>news:37492558.0_at_145.227.194.253...
>> Hi,
>>
>> Not being able to see your code or your form, i'm guessing at a few
things
>> here.
>>
>> 1.
>> 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
>> uses relevant indexes etc to maximise speed. Also, use an explicit
cursor
>> 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,
>> once to see if the too_many_rows exception needs to be raised and once
for
>> the actual query.
>>
>> 2.
>> Also, have you got some kind of counter in your form like 'Record 1 of
>200'?
>> 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
>> hidden field. When the user updates something, just subtract the old
>value
>> from the hidden field and add the new. This will save interrogating the
>DB
>> after every user move.
>>
>> Hope something from the above helps,
>>
>> Mark
>
>
>
Received on Tue May 25 1999 - 10:14:49 CEST