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.