FWIW, Although in theory this technique may logically access multiple dictionary items for every record read, and potentially worse, if other records are accessed by some foreign key, in practice there is so much cache memory floating around in a commercial (and even home based) system, that the physical reads are only a fraction of what they used to be, in coal-powered systems.
For a start, one I-type may use several other I-types in its execution but they are "compiled" into pseudo-subroutine so it is NOT the case that each element causes a Dict read. So in the case of say 3 Dict entries TOM, DICK and HARRY where TOM = A+B, DICK = C+D and HARRY = TOM + DICK , once they have been compiled TOM and DICK can be deleted but independent HARRY keeps on running (at least until it gets re-compiled). Even paged memory is unlikely to be rolled out to disk as this is only likely to happen if your discs [US translation: Disks] cannot deliver data fast enough to keep the cache "alive". If however you use a foriegn key to access a record from "secondary file" from whence you need several fields (e.g. a read to a Product record for Description, weight, and colour [color]) then you could shave off a little time by pulling-in the whole record in one hit (@record) and slice and dice it within the I-type or subroutine. For a one-off this may not be worth the time to set up, but a weekly run on a big file is another story. Sadly, I'm getting a bit rusty on Uv these days as all our new stuff is SQL based - but keep flying the flag y'hear. Ray (the celt [kelt]) - G! ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
