RE: SQL010 - length of a table's record

Oh, if only companies would learn to trust and listen to the experts they are paying. I have never figured out why the people they pay to have the expertise suddenly are too inexperienced to have the right answers and will pay someone else big bucks to come in and tell them something "must be done" that makes absolutely no sense.

Whew! Now can I come down off the soap box?

Duane

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Wednesday, August 10, 2016 2:37 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: SQL010 - length of a table's record

I don't know who "they" is...

But I assume _you_ get paid for your expertise.

From a quick Google, it appears that MS SQL Server only supports rows of ~8K bytes.

So you've been given a design that at least 2 major RDBMS platforms can't support.

Pushing back on a "dumb idea", asking why, and otherwise using your expertise to ensure the most benefit to the company is the right thing to do.

From experience, it only seems like corporate rules are written in stone. ;)

Charles

On Wed, Aug 10, 2016 at 2:23 PM, Darryl Freinkel <dhfreinkel@xxxxxxxxx>
wrote:

I am working in one of the huge corporate structures where they
provide the tables and we fill them.

Otherwise, it would have been done differently.

Thanks.
😷


On Wed, Aug 10, 2016 at 1:14 PM, Mike Jones
<mike.jones.sysdev@xxxxxxxxx>
wrote:

Hi Darryl,

Also, consider if your application really needs to SELECT all those
columns. Eliminating some columns from the SELECT, as opposed to
shortening how many bytes you select from each column, may be a
better choice.

Applications should only select columns they are using, and not
select columns they are not. Performance will improve in most cases
if you

follow

that rule, and code volume will decrease. SELECT * is something you

should

avoid embedding in an application, if that is what you're doing.

400 columns in a table likely means the table is not conforming to
3rd normal form for table design, but that is a separate concern.

Mike

-----Darryl Freinkel <dhfreinkel@xxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxx>
From: Darryl Freinkel <dhfreinkel@xxxxxxxxx>
Date: 08/10/2016 11:38AM
Subject: SQL010 - length of a table's record


Something I have not had to deal with before.

I have to create a table that has about 400 fields which are
mostly

VARCHAR

and of length 100 to 2000 each. So I get SQL0101.

I have always heard that the table sizes can go into the yoda byte

sizes

but never a record length maximum.

For now I have reduced the field sizes to 50 chars to get passed
the

issue.

This is a V5R4 system.

Is there a work around or different way to use these huge record sizes?

TIA
--
Darryl Freinkel

--
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
Darryl Freinkel
--
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
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.

Please contact support@xxxxxxxxxxxx for any subscription related questions.
________________________________
________________________________
CONFIDENTIALITY NOTICE: This electronic message transmission is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. If you have received this transmission, but are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this information is strictly prohibited. If you have received this e-mail in error, please contact NALC Health Benefit Plan at 703-729-4677 and delete and destroy the original message and all copies.