No DEBUG statement is involved, although the equivalent I guess in either a control-C followed by entering D or RAID from the command line. This is very frustrating as I know how powerful triggers can be, and I want to deploy them widely, but I cannot do this while this design BUG is there.
Cheers, Phil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Woodward Sent: Saturday, 11 June 2005 10:01 a.m. To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] Triggers, RAID and SQL 2005 No, you can't get past the write statement if you are running a program in RAID. If you hit a DEBUG statement then execute a GO, you're still not going to be able to get past the WRITE statement to a triggered file. At least that's been my experience not too long ago on UV 10.1. BobW > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of phil walker > Sent: Friday, June 10, 2005 2:50 AM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] [UV] Triggers, RAID and SQL 2005 > > I know that are good as they are very powerful. My point is I cannot > deploy them, if developers cannot debug programs which happen to contain > writes to files which have a trigger on them. I also know they start an > implicit transaction. This in itself does not mean that you cannot use a > debugger as when I state an explicit transaction in BASIC this is not > the case. > > Personally, I do not see the need to restrict a user from being able to > debug a trigger program, or indeed have an input statement, if there is > an interactive user on the end of it, if the developer wants to do such > a thing ;-). However as IBM is unlikely to change this, I would at the > very least hope to be able to use the debugger on a program which writes > to the file with the trigger on it, and for the write not to fail when > the write occurs with a message saying no input is allowed. Universe > should be able to determine that the code is a trigger and that > execution should continue until control returns to the program being > debugged. > > I will try when I get a chance to see if I can set a break point after > the write to see if the program still fails on the write to the file > with the trigger on it. Although that is still not ideal... > > Phil > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Friday, 10 June 2005 8:16 p.m. > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] [UV] Triggers, RAID and SQL 2005 > > We use them. they're good, though slower than i-type pseudo triggers, > they give more flexibility. > Triggers begin a transaction, which you aren't supposed to be able to > step through using a debugger. > Regards, > -- > Stuart Boydell > > [EMAIL PROTECTED] wrote on 10-06-2005 13.57.58: > > > I have found what I believe to be a problem with implementing triggers > > > in UniVerse. > > > > If I have a trigger on a file and a developer is trying to resolve a > > problem in a program which happens to update/delete that file an issue > > > using 'RAID' the debugger ;-).... When the developer steps over the > > write statement, which in itself can be hard to determine when that > > will be given RAID's ability to not display the real debug position, > > then the trigger fails as no input is allowed within a trigger, and > > the program does not complete as normal. > > > > Granted you normally do not debug a program in production, but > > sometimes you may have to, and in any case in development you would > > still have triggers in, so as I see it this issue must be resolved. > > For if not I cannot see how I can propose using triggers at all. > > > > On a philosophical note, I cannot see why you cannot debug trigger > > code or indeed have an input statement if that is what you inclined to > > > do....let the developer hang themselves... > > > > As a matter of interest how many people are using triggers? > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > > > > ********************************************************************** > This email message and any files transmitted with it are confidential > and intended solely for the use of addressed recipient(s). If you have > received this email in error please notify the Spotless IS Support > Centre (61 3 9269 7555) immediately who will advise further action. > > This footnote also confirms that this email message has been scanned for > the presence of computer viruses. > ********************************************************************** > ------- > 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/
