On Sun, 2014-04-27 at 07:28 -0400, Steve Richter wrote:
Was thinking I could create a 2nd file that has all the fields of the
order header but which expands the ponum field. So there are two
files: ORHEAD and ORHEADN. Then use triggers to mirror the contents
of the two files. So the files are always identical, except ORHEADN
contains the full PONUM and ORHEAD contains the first 15 chars of
PONUM.
But what would happen if the PONUM's first (or any) 15 characters could
be duplicated across many PONUM's where the additional characters made
the data unique?
eg: ORHEAD ORHEADN
PO1234567890123 PO1234567890123abcdef
PO1234567890123 PO12345678901234472ab
Also what about any programs that use the field to perform sorts?
Is the field "reference/display/print/sort only" or is it used to access
other files?
If the field is unique (or at least a unique code that may be replicated
multiple times) then I guess its possible to code something that where a
field is >13 characters the program looks up the ORHEADN by the long
key, if it finds a record then it puts the short code into ORHEAD, if no
record is found then it generates a truly unique short code and uses
that in the ORHEAD and creates a new record in ORHEADN with the new
short code and the long code.
Another idea would be to add the field to the end of the ORHEAD with
lvlchck(*no) and store the data in both fields (although uniqueness of
the 13 char field would also require some thought, or the 13 char field
dropped from usage although it still exists within the file; in the
latter then a good idea would be to blank all the 13 char fields so its
obvious its not the field you are looking for.)
While the above might work, you'd need to gather the information as to
how many programs would need the new logic, or be changed to access the
new file/or field (lvlchk(*no)), as apposed to programs that would need
re-compiling because of a field length change... if the numbers are
close then re-compiling because of a field length change is by far the
better way over some mangling/linking/extra field solution. Not
forgetting that some time down the line a new/changed program might be
required and the programmer would have to know there was some jiggery
pokey going on with that field being stored in multiple places with
differing sizes and "that way leads to pain, and pain leads to the dark
side."
My gut instinct is always "do it once, do it right, forget about it" as
although the upfront, finding programs/re-compilation/testing, costs are
higher, it makes maintenance much easier as there is no "silly" logic
involved that everyone must remember.
midrange.com
