RE: Trigger buffer information in SQL triggers

[vhamberg@xxxxxxxxxxx]

Jim, are external triggers out of the question? Are you trying to use SQL 
triggers for cross-platform compatibility or something? Because, as I bet you 
know, external triggers (those that do not use the SQL coding, rather call 
standard RPG or C) can see the member information.

This was interesting and helpful.
Vern

-------------- Original message -------------- 

> Vern, 
> 
> Thanks, this was a great summary. Alas, it does say there that member 
> information is not available to SQL triggers, at least in v5r1. I think 
> I have to admit defeat on that approach. 
> 
> We are testing a possible solution now where the application that 
> creates the temporary member will also flag the record so that we can 
> identify it in the trigger body and keep it from writing the audit. 
> That seems to hold some promise. 
> 
> Charles, in regard to your followup on SQL support of multiple members, 
> I don't disagree overall. The alias approach is far from recognition of 
> multiple members by SQL, but is about the only weapon we have right now. 
> I just wanted to make the members of the list aware that there are some 
> limited capabilities here. 
> 
> Thanks everyone for their help. 
> 
> Jim Reinardy 
> 
> -----Original Message----- 
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of 
> vhamberg@xxxxxxxxxxx 
> Sent: Tuesday, April 05, 2005 2:11 PM 
> To: midrange-l@xxxxxxxxxxxx 
> Subject: Trigger buffer information in SQL triggers 
> 
> We had a thread today related to this - there's an article by Kent 
> Milligan where he lists the trigger buffer data that is NOT available - 
> trigger event, trigger time, commit level, relative record number, file 
> name, library name, and member name. The link to the whole article is 
> http://www.as400network.com/artarchive/index.cfm?fuseaction=viewarticle&; 
> CO_ContentID=11436&channel=art&subart=top&topicid=50 called "Uncovering 
> V5R1 Triggers" I'm going to assume that the offsets and lengths to old 
> and new records and null maps are also not available - SQL probably uses 
> them for its own purposes. 
> 
> Vern