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

[Alan Campin <alan0307d@xxxxxxxxx>]

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.