Re: limit to view

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.