×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 16/09/2009, at 11:18 PM, Charles Wilt wrote:
The point would be, you'd benefit from not having to %trimr() the
fields yet don't pay a i/o hit when accessing any records.
My comment about "easier to determine the actual length" was alluding
to the various trim functions no longer being necessary.
What makes you think there is no I/O hit?
It takes more work for the system to find the data in the over-flow
area than in the "normal" record area--even if ALL the field data is
in the overflow. Also, as additional data is added to the record in
the overflow area it can become fragmented and so increase the cost to
reassemble. I suspect the cost of I/O involving much data in the
overflow area will outweigh any benefit obtained from these fields
being automatically defined as VARYING in the program.
I'd rather define as fixed-length and then move to a VARYING field
using %TRIMR. One hit in the code at a place of MY choosing and then
the benefits of VARYING from then on. If I don't need to concatenate
then I don't need to trim and I don't need to pay the cost either in
my code or in database.
I'd consider such a field as an alternative to a small (say <50) fixed
length field. Particularly in a table access by native RPG op-codes.
Otherwise you're taking a dual i/O hit for some records even if you
don't need the variable length field. Of course, an alternative would
be to have a logical that didn't include the varying field(s).
While there are distinct advantages to using VARYING within a program
it makes less sense in primarily fixed-length database system.
It will be more expensive to access varying-length fields in a
database file. Whether that additional expense is prohibitive will
depend on what you're doing and on what system. You may find it an
acceptable cost. For me, I wouldn't bother using VARLEN on any field
less than a few hundred bytes (unless I had a specific design
requirement) and even then I would set the allocated length to ensure
80%-90% of the data fitted within the normal record area.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
