Re: how to increase field size without increasing the field size

The funny thing about this to me is how people are always saying there are
no costs to using file I/O and bringing the entire database into the
program. In other words, no database independence.

Just watching this one thread and you have the real costs. Billions spent
dealing with problems like this where we should just be able to increase
the field size and recompile the few programs that use the PO fields which
is what anyone else using SQL on other systems is doing.


On Mon, Apr 28, 2014 at 9:47 AM, James H. H. Lampert <
jamesl@xxxxxxxxxxxxxxxxx> wrote:

In our Wintouch product, we've occasionally had situations where a
customer needed a longer field for something that's built into the product.
There, the solution is to simply create a longer version as a user-defined
field, and then slave the two fields together in the installation-specific
programs.

Some years ago, in our QuestView product, I found that my predecessors
hadn't provided a big enough field in the internal data structures for (if
I remember right) the RRN. And simply expanding the field would have
required massive recoding, moving dozens of fields referenced by multiple
programs, with massive potential for errors. So (as I recall) I just added
a longer version to a place in the structure that was "reserved for future
expansion," and (again) slaved the two to each other.

--
JHHL

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.