Re: limit to view

Hoteltravelfun, I know that you've been beat up before about the questions
you ask. May I suggest that you give this a read.

http://www.catb.org/esr/faqs/smart-questions.html

It will not only help you help yourself, but giving us more information to
be able to help you.

Do you truly have 32,767 characters? I don't read books that long. LOL.
It sounds like it's too complicated. I would try to break it down some
how.



On Fri, Aug 8, 2014 at 7:28 PM, Hoteltravelfundotcom <
hoteltravelfun@xxxxxxxxx> wrote:

its create view, yes, will check for more info.


On Fri, Aug 8, 2014 at 7:25 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 08-Aug-2014 17:00 -0500, Hoteltravelfundotcom wrote:

I got message

Why so secretive? Is the message confidential? If so, probably not
best to ask on a public forum.


so there is a limit to the view.?

The further away, the wider the scope, but likely less detail will be
available; the closer-in, the narrower the scope, but at some point the
details can also become lost as the ability to focus likely abates.

Lots of limits everywhere, including various limits for a SQL VIEW,
including the CREATE VIEW statement; at one time for example, the
VIEW_DEFINITION had [and may still have] a limit of 10K in bytes [i.e.
10000 vs 10KB].


I can break them up is the only option?

When something is too big, breaking up the item into smaller pieces is
often an option; sometimes though, not a functional\usable option in the
particular scenario.

After reading ahead... [I infer possibly an appropriate answer might
be:] Probably, however limiting embedded comments and other extraneous
characters might suffice. Presuming the failing request is a CREATE

VIEW,

encapsulating some longer VIEW text into other VIEW definitions such that
some subqueries refer to the VIEW instead of being defined by the entire
SELECT would likely prove helpful in that regard; i.e. breaking up one

long

VIEW into multiple CREATE VIEW statements. However if a VIEW is so

complex

as to require that many characters, entirely possible that the complexity
of the VIEW in definition may exceed some other limit(s) other than just
number of characters.


Length of statement exceeds 32,767 characters.

That is the USEnglish text apparently. Best to always give the Message
Identifier with the message text for which language translation would

never

be an issue; that opens up the possibility that someone with a different
language feature might be able to waste their time to be helpful despite
the author offering up almost no useful supporting information. The
/context/ of the message, for example, is generally of interest to a

reader

so they are better able to assist; knowing the request for which the
message was issued, the input up to the point that the message was

issued,

and from where and to whom and\or to what the message was issued are all
part of the /context/ of the messaging.

While a reader might successfully have inferred the message identifier
is SQL6015 with the same text "Length of statement exceeds 32,767
characters.", and therefore presumably identifies a like condition to

what

was merely alluded with text, the missing /context/ of the messaging

gives

the reader little more about how the author encountered the [error]
condition. Possibly the SQL6### range of messages are reserved for the

use

of the Start [ineractive] SQL (STRSQL) feature, such that the error might
be presumed to have been sent T/QSQISE [though F1=Help "Additional

Message

Information" and joblog for iSQL messages are often logged only in the
interactive session rather than appearing with the from-program and
to-program]; but knowing specifically that a particularly long SQL CREATE
VIEW statement was issued and stating how many /pages/ of data were

entered

in the session before Enter was pressed both would go a long way to

adding

/context/ to the failing condition.

--
Regards, Chuck

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

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