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