Mike, I may have mislead you slightly, in that in the scenario I have I do not actually want to debug the trigger code, although I cannot see why you should not be able to but that is a separate issue, but rather the application vendor wants to debug their code, in the live environment as it is difficult to replicate the exact situation in development. So they try and debug their programs, but as we have put triggers on some files for auditing etc, their debug session aborts when they perform a write or delete on the files with triggers.
This would be the same in a development environment also. The situation is really no different, basically the way IBM have implemented triggers in UV means that you cannot debug programs. There was also an issue early on with have a trigger on a file which you accessed via uv objects. It would abort. I am not sure if that is still an issue, but I will find out in the coming months.... Cheers, Phil. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rajkowski Sent: Friday, 21 April 2006 4:15 a.m. To: U2Users Subject: RE: [U2] [UV] Triggers Actually, you do have an update and a delete Trigger in Unidata. : LIST.TRIGGER CUSTOMER BEFORE UPDATE TRIGGER: not defined BEFORE DELETE TRIGGER: not defined As for the debugging issue, I have always written programs to test the subroutine prior to using it as a trigger. Yes, I can see the need to debug in a live environment. Now, I am not sure about the issues in UniVerse, yet you may want to try to save off the input parameters in the trigger program if it fails, and then work with a copy of the subroutine, not attached to the file as a trigger. Michael Rajkowski -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Haskett Sent: Thursday, April 20, 2006 8:55 AM To: 'U2Users' Subject: RE: [U2] [UV] Triggers Phil: Fortunately, this is not the case in UniData. However, triggers (plural) is really a misnomer as you can only put one trigger (singular) on a UniData file. Bill Haskett > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of phil walker > Sent: Wednesday, April 19, 2006 11:02 PM > To: U2Users > Subject: [U2] [UV] Triggers > > How many people in this group as using triggers in there applications? > > For those that do, how do they manage to use the debugger? > > As from what I have been able to ascertains it seems as soon as you > try to debug a program which write/deletes to/from a file/table with a > trigger on the program aborts, as you cannot have input within a > trigger. > > This is a major design flaw as far as I am concerned, and very > frustrating... > > Firstly, if someone wants to have an input statement inside a trigger > program let them. There is enough rope in UV for people to hang > themselves. So let people make their own bed... > > Secondly, even if you cannot have input inside a trigger, the debuging > session should not be considered normal input, and UV should recognise > this and perform the write, stepping over the trigger code and > performing the next operation in the program being debugged. > > Any comments? ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
