Re: Forms question with globals and performance

You can define a global record group.

CREATE_GROUP(the_group, GLOBAL_SCOPE)
-or-
CREATE_GROUP_FROM_QUERY(the_group, 'SELECT * FROM the_table ORDER BY the_key', GLOBAL_SCOPE)

Best!

Randall

Matt B. <mcb_at_ds.znet.com> wrote in message news:tgjpld4t1sqr42_at_corp.supernews.com...
> Came across this today and was wondering if anyone else has come across
> something like this.
>
> Forms 6 running on a DG/UX UNIX box.
>
> At runtime, we have Form A and Form B.
>
> Form A calls Form B. Form B queries records from the database into a
> multi-record block and the user indicates with a Y or N in a field on each
> record if they want a particular record "selected" for return to Form A.
>
> When they select one or more records, what happens is data from the
 record(s)
> is captured in globals because it's being sent back to the calling form
 (Form
> A).
>
> So the globals look like kinda this:
>
> GLOBAL.FIELDa1, GLOBAL.FIELDb1, GLOBAL.FIELDc1...
> GLOBAL.FIELDa2, GLOBAL.FIELDb2, GLOBAL.FIELDc2...
> GLOBAL.FIELDa3, GLOBAL.FIELDb3, GLOBAL.FIELDc3...
>
> Where FIELDa, FIELDb, and FIELDc are fields on a record and 1, 2, and 3
 are
> records.
>
> In reality, the records have about 30 fields on each of them, and the user
 can
> pick pretty much an infinite number of records too (whatever's in the
 block).
> For example, with 145 records and 30 fields each, that's 4350 globals
 (each at
> up to 255 in length too) being created for the calling form to read.
>
> (No flames please - I didn't design the form - I'm just fixing it.)
>
> So what ended up happening, as far as I can tell, is that Form B would
 take
> ages to populate the globals (understandably). I found the solution in
 this
> case was to do away with most of the globals and only return "key" ones
 (about
> 5-6 per record) and then back in Form A I'd hit the database with SQL
 (using
> the key values returned for my SQL) for each record to get the other
 values
> that I was no longer getting via globals.
>
> The old way, Form B took well over 16 minutes just to even populate the
 globals
> for a test with 145 records (I gave up after 16 minutes went by and forced
 a
> core dump). The new way, they're populated, returned to Form A, and
 control is
> returned to the user within 20 seconds.
>
> Anyway, I can see where originally the form used globals for everything so
 that
> way a DB hit was avoided, but as the number of records chosen increased,
> performance went right into the ground, especially when records have many
> fields on them. We don't have this problem for other forms where we do a
> similar thing and there are only a couple of fields returned from one form
 to
> another via globals.
>
> Are there any general rules for the number of globals to use between forms
> before considering alternate ways of moving data between forms?
>
> Thanks,
>
> Matt
>
>
Received on Sat Jul 21 2001 - 23:43:46 CEST