On 14-Oct-2016 07:35 -0500, David Gibbs wrote:
OK, this is driving me a bit crazy.
The online help for the ADDPFTRG command says you can specify a 256
character trigger name if you surround it with double quotes. But I
haven't been able to do this.
Back in August, Chuck Pence mentioned ...
I did not notice the comment had a date; ugh, so easy. I just spent
over a half hour trying to get Google to find that text or a variation,
with no luck; after which I finally went into my NNTP reader and
searched my past messages to get the Subject and finally Google web
search found something. I am shocked at how poorly Google searches
function now, than in the past, for very specific searches.
[Trigger naming rules?]
(
http://archive.midrange.com/midrange-l/201608/msg00027.html)
Given the catalog files limit SQL identifiers to 128 characters, I
suspect the reference to 258 may be an error;
By all indications, the text in the Help for the TRG parameter of the
Add Physical File Trigger (ADDPFTRG) should suggest there is a limit of
"128 characters, or 130 characters when the double quotes are specified
as delimiters" just like is noted for SQL Identifiers in the "Identifier
Limits" docs for "SQL Limits" to which a doc link is given in the above
archived message.
I stumbled upon what I expect is another defect in the docs; though
in hindsight, I am not sure what I expected to find there, because I
knew that all that could be obtained is a stored length rather than a
max length. The field name Qdb_Qdbftrg_Name_Len of the Retrieve File
Description (QDBRTVFD) API is incorrectly identified by the descriptive
text "Length of the trigger program name" whereas that is apparently
instead, the "Length of the trigger name"; esp. given that, the field
name Qdbftpgm [of CHAR(10)] defines the "Trigger program name."
Also, the SYSTRIGGER table allows 128 characters for a trigger name,
so I'm thinking Chuck is correct.
Can anyone create a trigger on a PF with a name longer than 128?
I am quite confident nobody will be able. Notably, because if that
were possible to effect, then there would be *other problems* that would
cause a *conundrum*. That is because the names are not only stored in
the DB XREF, but the SQL depends on those names that are stored there,
to perform user-requested functions. Essentially, there is no /index/
of those trigger-names via the *LIB object, like there is for typical
external object types [there is no *TRG object type]; a request against
the trigger name must be directed to the data in the Physical File(s)
(PF) QADBXT* in QSYS, as indexed by the Logical File(s) (LF) QADBXT* in
QSYS. That is to suggest, the keyed access path(s) of those system
database cross reference (DBXREF) files tracking the triggers, is the
/index/ of those trigger-names [for lack of a *TRG object in QSYS].
Unlike Remove Physical File Trigger (RMVPFTRG), DROP TRIGGER does not
specify a TABLE name from which the trigger is being removed; the only
way to look-up the name, is via those stored names in the catalogs/DBXREF.
Any time I try to do so I get a CPD32E7 with RC 8.
As my examples show in a followup reply; msgCPD32E7 RC8 or msgSQL0107
[aka sqlcode=-107]:
[Trigger naming rules?]
(
http://archive.midrange.com/midrange-l/201608/msg00033.html)
midrange.com
