Yes, Chuck a typo in the release number and much less capable than SQL style a backwards step too. But far less overhead and drama to 

-----Original Message-----
[] On Behalf Of Charles Stevenson
Sent: Wednesday, 7 August 2013 7:58 AM
To: U2 Users List
Subject: Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using 
DEBUG or RAID with them? Was: Universe Triggers

Thanks to a fellow u2-list member who mailed me privately.
I think David Hona was maybe thinking of that,  but it's available at 11.1, not 


On 8/5/2013 6:23 PM, Perry Taylor wrote:
> Rocket added an @variable (don't recall the name of it) that tells which call 
> is being made.
> Perry
> -----Original Message-----
> From: 
> [] On Behalf Of Charles 
> Stevenson
> Sent: Saturday, August 03, 2013 9:40 AM
> To: U2 Users List
> Subject: Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty 
> using DEBUG or RAID with them? Was: Universe Triggers
> David,
> I didn't understand your 1st clause, "Now that (from UV10.1) 
> Index-based triggers are officially supported,...".
> By "index-based triggers",  I assume you mean the trick of indexing an 
> I-descriptor that calls a subroutine that updates some other file, 
> which is generally not the sort of thing you expect such a subroutine to do.
> What is this "official support"?  Did I miss an announcement, a change 
> in the documentation, or a whitepaper?
> And  by "support"  -  just to get my hopes up beyond all reason - does 
> that mean they've introduced some mechanism (@variable?) to help 
> distinguish among calls of the subroutine for insert (where indexing 
> calls the subroutine once, to find the new value to index) delete 
> (where indexing calls the subroutine 1x, to find the value to delete), 
> and change (where indexing calls the subroutine 2x, once with the old 
> version of the record, once with the new, to see whether the indexed 
> value has changed and, if so,  what to delete, what to add.
> Distinguishing these has always been tricky for the general case.
> Hope springs eternal,
> Chuck
> On 8/1/2013 12:32 PM, Hona, David wrote:
>> Now that (from UV10.1) Index-based triggers are officially supported, can 
>> these replace your SQL-based triggers? These have less functionality and 
>> less overhead, but that's the price you have to pay....
>> Can't say I had a chance to try it for myself...yet...!
>> -----Original Message-----
>> From: 
>> [] On Behalf Of Charles 
>> Stevenson
>> Sent: Saturday, 27 July 2013 5:32 AM
>> To: U2 Users List
>> Subject: [U2] [UV] Do you avoid TRIGGERS because of the difficulty 
>> using DEBUG or RAID with them? Was: Universe Triggers
>> How many people avoid using triggers BECAUSE of the virtual impossibility of 
>> using RAID with Triggers?
>> On 7/26/2013 12:33 PM, Phil Walker wrote:
>>> I won't be holding my breath Charles ;-)
>>> -----Original Message-----
>>> From:
>>> [] On Behalf Of Charles 
>>> Stevenson
>>> Sent: Friday, 26 July 2013 9:22 p.m.
>>> To: U2 Users List
>>> Subject: Re: [U2] Universe Triggers
>>> re. triggers & Raid,  I could not agree with Phil more.  Well said.
>>> Come on, Rocket!
>>> On 7/19/2013 1:32 AM, Phil Walker wrote:
>>>> Ken,
>>>> I am glad you raised the issue about debugging a program with a file which 
>>>> has a trigger attached. I have been on to UV (Vmark/Ardent/IBM/Rocket for 
>>>> ages about fixing this pushing for the ability to be able to step into the 
>>>> trigger code, but at a VERY MINIMUM being able to debug the program and 
>>>> perform the write on the file, and in effect step over the trigger 
>>>> subroutine and carry on debugging. The issue is the trigger subroutine 
>>>> cannot support input, so what UV have done is basically say you are using 
>>>> the debugger so you are inputting debug commands so you will abort. They 
>>>> need to turn this restriction off for debugging so that either of the 
>>>> above two scenarios is supported.
>>>> In a Microsoft world I can debug anything through the connected world of 
>>>> web/databases etc......
>>>> Have had no feedback from UV
>>>> -----Original Message-----
>>>> From:
>>>> [] On Behalf Of Ken Ford
>>>> Sent: Friday, 19 July 2013 9:48 a.m.
>>>> To:
>>>> Subject: Re: [U2] Universe Triggers
>>>> Dan,
>>>> In addition to the other responses you have received, I suggest the 
>>>> following:
>>>> 1. Have one master file trigger subroutine (globally catalogued) that 
>>>> calls subroutines (locally catalogued) tailored to individual files.  This 
>>>> means you don't have to stop and restart Universe when a new trigger is 
>>>> required or a change to an existing one.  If the master subroutine 
>>>> changes, you do have to restart Universe.
>>>> 2. Use a control record that records the subroutine name and state of the 
>>>> trigger for each file having a trigger.
>>>> 3. Use a program to change the state of a trigger, using the control 
>>>> records in 2 above.
>>>> 4. Make sure all background processes that have a file with a trigger open 
>>>> are logged out when recompiling the subroutine for that file trigger.
>>>> 5. Remember that you can't do anything to a file with an active trigger 
>>>> whilst in the RAID debugger (it will crash).  Rather, if you are testing a 
>>>> file trigger subroutine, drop the trigger and use a trigger testing 
>>>> program that calls the subroutine after taking a copy of the record being 
>>>> changed, pausing whilst you change it in another session, and then 
>>>> resuming, calling the subroutine.
>>>> If you would like samples of any of the software mentioned above, let me 
>>>> know, and I can send them to you.
>>>> Regards,
>>>> Ken Ford
>>>> Universe Software Developer
>>>> t 07 3013 8605 | f 07 3002 8400
>>>> e | w

U2-Users mailing list

************** IMPORTANT MESSAGE *****************************       
This e-mail message is intended only for the addressee(s) and contains 
information which may be
If you are not the intended recipient please advise the sender by return email, 
do not use or
disclose the contents, and delete the message and any attachments from your 
system. Unless
specifically indicated, this email does not constitute formal advice or 
commitment by the sender
or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: 
If you no longer wish to receive commercial electronic messages from us, please 
reply to this
e-mail by typing Unsubscribe in the subject line. 

U2-Users mailing list

Reply via email to