× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.