×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 02-Aug-2016 16:09 -0500, David Gibbs wrote:
On 8/2/2016 3:56 PM, CRPence wrote:
The rules for SQL /object/ Identifiers would be applicable. Though
the "Object Naming Rules" for the OS are quite similar if not the
same.
Thanks all!
FWiW a name longer than 128 characters is diagnosed on ADDPFTRG with
msg CPD32E7 RC8 "08 - Error generating or altering trigger name" and
with the CREATE TRIGGER the excessive identifier length is diagnosed
with the msg SQL0107 [sqlcode -107] "&1 too long. Maximum &2 characters.
… -- SQL names cannot exceed 128 characters. …"
The following will fail as noted above per the name being 130 chars,
though 132 specified inclusive of the delimiters:
ADDPFTRG mylibrary/mydbfPF *after *insert pgm(mypgmlib/mypgm)
TRG("....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10....+...11....+...12....+...13")
The following can function without the above error because the name
is 128 chars, though a total of 130 chars specified inclusive of the
delimiters:
ADDPFTRG mylibrary/mydbfPF *after *insert pgm(mypgmlib/mypgm)
TRG("....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10....+...11....+...12....+...13")
Note: In both of the above TRG("…"), all of that parameter
specification [the Kwd, parentheses, and dbl-quote-delimited value]
should appear entirely on one line; email clients or archival might not
maintain the long line.
midrange.com
