Real programmers don't use debuggers :-)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Trebbien Sent: Friday, April 21, 2006 3:40 PM To: Allen E. Elwood; U2Users Subject: RE: [U2] [UV] Triggers I mostly use a CRT statement to list data from a basic program I'm debugging, something of this nature: X=123 Y=ABC CRT "pt at line 101, x is: ":X To pause the program at a point you can use an INPUT statement: CRT "pt at line 101, x is: ":X:;INPUT ANS We call a lot of subroutines and most of the time I do not want to march through one of those programs, if you enter OUT at the debugger prompt processing will continue without stopping in the subroutines. Have a Great Day! Paul Trebbien Kore Technologies, Senior Support Tech. "Solutions that work. People who care." V 858.678.0030 F 858.300.2600 W koretech.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen E. Elwood Sent: Thursday, April 20, 2006 2:36 PM To: U2Users Subject: RE: [U2] [UV] Triggers I'm mostly a U2/Pick kind a guy, but can't you just put in PRINT statements and input statements to pause execution once you get to a certain point? I still do this myself instead of the debugger if I'm in a loop and I need to find out what I'm doing wrong and I have a number of variables that all need to be displayed each iteration to discern the cause of the problem - just to save typing. In fact, I just did this yesterday for a routine that was uploading shipment data and was not behaving. As you can see in the PICK code below, they are remmed out now - problem solved! :) hth, Allen. FOR SORTI = 1 TO ORD.COUNT PARTS.LOTS<1,SORTI> = ORDER.PARTS<1,SORTI>:'|':ORDER.LOTS<1,SORTI> NEXT SORTI * PRINT 'PARTS.LOTS=':PARTS.LOTS;INPUT BUG;IF BUG THEN DEBUG * * Locate shipped PART.LOTS in the list of ordered part lots and use that to sort * the shipment data in the same order as the ordered data. FOR ACTI = 1 TO ACT.COUNT PART.LOT = ACT.PARTS<1,ACTI>:'|':ACT.LOTS<1,ACTI> LOCATE PART.LOT IN PARTS.LOTS<1> SETTING PL.INDEX ELSE PL.INDEX = '' *PRINT 'PART.LOT=':PART.LOT *PRINT 'PL.INDEX=':PL.INDEX *INPUT BUG;IF BUG THEN DEBUG IF PL.INDEX THEN IF SORTED.QTYS<1,PL.INDEX> > "" THEN SORTED.QTYS<1,PL.INDEX,-1> := ACT.QTYS<1,ACTI> SORTED.PARTS<1,PL.INDEX,-1> := ACT.PARTS<1,ACTI> SORTED.LOTS<1,PL.INDEX,-1> := ACT.LOTS<1,ACTI> END ELSE SORTED.QTYS = INSERT(SORTED.QTYS, 1, PL.INDEX, 0, ACT.QTYS<1,ACTI>) SORTED.PARTS = INSERT(SORTED.PARTS, 1, PL.INDEX, 0, ACT.PARTS<1,ACTI>) SORTED.LOTS = INSERT(SORTED.LOTS, 1, PL.INDEX, 0, ACT.LOTS<1,ACTI>) END *PRINT 'SORTED.QTYS ':SORTED.QTYS *PRINT 'SORTED.PARTS ':SORTED.PARTS *PRINT 'SORTED.LOTS ':SORTED.LOTS *INPUT BUG;IF BUG THEN DEBUG -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of phil walker Sent: Thursday, April 20, 2006 12:58 To: U2Users Subject: RE: [U2] [UV] Triggers 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/ ------- 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/
