On 17-Dec-2015 13:48 -0600, Justin Dearing wrote:-snip-
On Thu, Dec 17, 2015 at 12:41 PM CRPence wrote:
On 17-Dec-2015 10:14 -0600, Justin Dearing wrote:
<<SNIP>>IOW, what /specifically/ was the generated statement?
LABEL ON TABLE SCHEMANAME.VIEWNAME
IS 'A long string of human readable english' ;
GENERATE_SQL generates 3 label statement, at least when I invoke it
the way I do. The one above, and two large ones that ad the label and
text values for the columns
What am I doing wrong?
In this case I think you're right.
The data, in fact, may not _be_ in the catalogs.<snip/>
So to summarize, QSYS2.GENERATE_SQL() is looking in multiple places
for the label statement, And QSYS2.SYSTABLES.TABLE_TEXT does not.
Likely both features look the same place for the text; i.e. within the *FILE object. The latter however, *looked* [past-tense emphasize] sometime in the past when the file was created or changed or when the DBXREF catalog data was last refreshed, such that the data was stored in the row; the data is not retrieved from the object dynamically when the catalog is queried. The former would look at the *FILE on disk, thus dynamically retrieving the data from the object.
I tried to allude to the possibility that the TABLE_TEXT not being visible in the catalogs may have an origin in a defect; that the correction was to re-apply the label [I suggested using LABEL ON TABLE, but CHGPF TEXT() should effect the same, and what is the effect of CHGOBJD TEXT() I do not recall, but IIRC the /Librarian/ feature [that maintains the OIR of the generic object-types] invokes the Database [as object handler] when the OBJTYPE(*FILE) Object Type is of the Database File (DBF) specific variety of *FILE in order that the Database can do any /extra/ processing such as notify the DBXREF that the file TEXT attribute has changed. Thus the effect of each should be similarly reflected in the catalogs.