Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
Yes, Chuck a typo in the release number and much less capable than SQL style triggers...so a backwards step too. But far less overhead and drama to setup/maintain... -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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 @IDX.IOTYPE 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 10.1. Chuck 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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.
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
@IDX.IOTYPE 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 10.1. Chuck 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
Rocket added an @variable (don't recall the name of it) that tells which call is being made. Perry -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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
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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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 ken.f...@firstmac.com.au | w firstmac.com.au ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
Trigger are useful to find programs that update files incorrectly. When this happens, I create a trigger that will create a sequential file with the content of SYSTEM(9001) on Universe in order to identify the chain of calling programs. From: Hona, David david.h...@cba.com.au To: U2 Users List u2-users@listserver.u2ug.org Sent: Thursday, August 1, 2013 5:32 AM Subject: Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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 ken.f...@firstmac.com.au | w firstmac.com.au ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ** IMPORTANT MESSAGE * This e-mail message is intended only for the addressee(s) and contains information which may be confidential. 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: commbank.com.au. If you no longer wish
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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 ken.f...@firstmac.com.au | w firstmac.com.au ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ** IMPORTANT MESSAGE * This e-mail message is intended only for the addressee(s) and contains information which may be confidential. 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: commbank.com.au. 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
That is not the point. Why should I have to do a workaround to get around something which should just work. I cannot see what would be so hard about allowing the debugging of programs which access a file with a trigger associated with it without aborting which UV currently does. That as a minimum. Hey it might even be good to be able to debug he trigger itself. Yes I could build a framework to call the trigger subroutine with the appropriate arguments, but why should I have to. Why is it so hard to do things? Mostly, I don't get that feeling with SQL, although to be fair MV has lot better string handling via build in functions, but then again SQL has the CLR capability in which I can build most of the MV string handling functions. Has anyone done this BTW? Sorry for the rant guys, but just pent up years of frustration. Cheers Phil -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David Sent: Thursday, 1 August 2013 9:33 p.m. 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 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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 ken.f...@firstmac.com.au | w firstmac.com.au ___ U2-Users mailing list U2-Users@listserver.u2ug.org
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
That and the expense of their usage. Perry Taylor Zirmed, Inc. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Friday, July 26, 2013 1:32 PM 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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 ken.f...@firstmac.com.au | w firstmac.com.au ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
I must say, I use triggers in UD with no problems. When converting from D3 to UD I had a hard time getting them to work. However, with useful suggestions from several on this list I was able to get them working properly. They turned out to be a bit more robust than the D3 triggers. I've been able to debug the trigger several times when problems appeared, but haven't for a number of years as they work as expected now. The structure took a while to get my head around, but I simply have two trigger programs (globally cataloged): U2.MASTER.TRIGGER.D U2.MASTER.TRIGGER.U ...which handle all delete and update triggers. Inside each program a file is read that actually provides the trigger subroutines to CALL (via a CALL @...). So, I can insert any subroutine as a trigger in any account. These programs are cataloged locally. I don't remember any problems debugging these subroutines. Just a thought. Bill - Original Message - *From:* perry.tay...@zirmed.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 7/29/2013 6:24 AM *Subject:* Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers That and the expense of their usage. Perry Taylor Zirmed, Inc. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Friday, July 26, 2013 1:32 PM 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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 ken.f...@firstmac.com.au | w firstmac.com.au ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
We use this same concept. The triggers themselves are globally cataloged, but all they do is check a table then based on the file in question, call a 2nd locally (DIRECT) subroutine. Debugging is simple for us and never clobbers the live code when developing in a test environment on the same box. JRI -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, July 29, 2013 11:35 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 I must say, I use triggers in UD with no problems. When converting from D3 to UD I had a hard time getting them to work. However, with useful suggestions from several on this list I was able to get them working properly. They turned out to be a bit more robust than the D3 triggers. I've been able to debug the trigger several times when problems appeared, but haven't for a number of years as they work as expected now. The structure took a while to get my head around, but I simply have two trigger programs (globally cataloged): U2.MASTER.TRIGGER.D U2.MASTER.TRIGGER.U ...which handle all delete and update triggers. Inside each program a file is read that actually provides the trigger subroutines to CALL (via a CALL @...). So, I can insert any subroutine as a trigger in any account. These programs are cataloged locally. I don't remember any problems debugging these subroutines. Just a thought. Bill - Original Message - *From:* perry.tay...@zirmed.com *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 7/29/2013 6:24 AM *Subject:* Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers That and the expense of their usage. Perry Taylor Zirmed, Inc. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Friday, July 26, 2013 1:32 PM 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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
[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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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 ken.f...@firstmac.com.au | w firstmac.com.au ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] Do you avoid TRIGGERS because of the difficulty using DEBUG or RAID with them? Was: Universe Triggers
I know we use them, but whenever one of the programmers wants to debug a program they take them off, which causes us other problems as we have processes which rely on the trigger output. This would be my biggest beef with UV at the moment. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Saturday, 27 July 2013 7:32 a.m. 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] 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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ken Ford Sent: Friday, 19 July 2013 9:48 a.m. To: u2-users@listserver.u2ug.org 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 ken.f...@firstmac.com.au | w firstmac.com.au ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
