Of course, why would anyone need a BASIC program larger than 32K? I
believe it's called progress. Non-configurable size limits are just
__NOT__ acceptable in today's computing environment. The attendant
"work-arounds" are just plain ugly, and inexcusable.
The greatest aspect of PICK is the narrow gulf between the logical and
the physical; database structure is logical, query syntax is logical, in
fact, the entire machine is a logical machine. Twenty year old physical
limitation should have been resolved at least ten years ago. :-(
Bill
------------------------------------------------------------------------
Kevin King said the following on 10/25/2010 8:27 AM:
Agreed on all points. Will check this on my customer's system.
On Mon, Oct 25, 2010 at 9:11 AM, Dave Davis<dda...@harriscomputer.com>wrote:
That's some shopping list.
I haven't seen anything anywhere that lets you adjust this limit.
Besides breaking the record up into separate tables, you may need to make a
temp file that normalizes this for you, by doing something like stringing
the value or row number into the key.
I've never had anything approaching 10240 values in a multivalue.
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org [mailto:
u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Monday, October 25, 2010 10:54 AM
To: U2 Users List
Subject: [U2] "too many values in sort"
Unidata 6.1.15 on AIX. The following command:
SSELECT SHOPPING.LIST BY.EXP PROD.NUM
Yields the message "too many values in sort". There is one record in this
file with 36,457 product numbers but would that "break" the BY.EXP? If so,
is there a config parameter somewhere that could be tweaked to make this
work?
-Kevin
http://www.PrecisOnline.com
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
