TRANSACTIONS and ON ERROR Another issue exists with ON ERROR within a transaction, at least when it was implemented back in the early to mid nineties.
I have not tested it recently and Ardent, Informix or IBM may have addressed it, but if a transaction was active and a situation arose which normally would require the ON ERROR clause to be taken then it would not be and from memory the program would abort. TRIGGERS and client access I have also come across and issue where access to a table with a trigger on caused Universe Objects to cause a core dump on the server side. Has anyone experienced this in recent releases. Phil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gyle Iverson Sent: Saturday, June 19, 2004 3:14 PM To: [EMAIL PROTECTED] Subject: RE: [U2] [UV] WHILE READNEXT id DO Ray Wurlod opined: >Personally, I love this syntax. When training others, I >usually explain it in this form; READNEXT has to generate a >true/untrue value of some kind to determine whether to go down >its THEN or ELSE path. We take advantage of that "Boolean >context" to trigger the behaviour of WHERE or UNTIL in a >looping context. > >READNEXT is not the only statement that exhibits this >behaviour. Almost any statement that has THEN/ELSE can use >it. But READNEXT, READSEQ/READBLK are the most "sensible". [snip] >It would be nice were there a section in the BASIC manual >about the Boolean context of certain statements, but that's >only a minor complaint. Of course, each statement syntax that >appears to make at least one of THEN or ELSE mandatory would >need a note referring to this section. Hello, Ray. We can agree that the syntax has a certain appeal, yet finding a practical use for such has always escaped me in real applications for anything but READNEXT. Why? The syntax precludes handling of ON ERROR or LOCKED clauses. Never mind that the READNEXT, READSEQ and READBLK statements should [but do not] have an ON ERROR clauses. After all, files may be damaged or networks may be interrupted. I assume your "sensible" reference would not be so if these statements should later support such a clause. Writing robust, recoverable, error-tolerant code precludes taking the approach that a file I/O statement may have only a THEN or ELSE condition. Perhaps if there were a structured exception mechanism within BASIC one could safely use such syntax, but I discourage its use for anything but simple one-time utility programs. Best regards, Gyle ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
