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/
