That still wouldn't work within the bounds of a transaction.. All the writes take place when the transend command is hit - no write errors will be generated till then.
Simon --------------------------------- Simon Verona Director Dealer Management Services Ltd Sent from my iPhone On 4 May 2009, at 13:34, Mike Preece <[email protected]> wrote: > > If you had all of your IO going through a standard subroutine then you > could trap, record and/or return each and every error code. You could > do anything you wanted. > > On Apr 30, 2:33 pm, Bruce Willmore <[email protected]> wrote: >> Thanks, Dan. >> >> The more that I thought about it last night, the more that I realized >> what the answer was going to be, and it makes perfect sense, although >> it sure would be nice if TRANSEND could throw some kind of indicator >> as to what transpired. Maybe a suggestion for a future release... :-) >> >> I sincerely appreciate everybody's assistance in this, and I >> apologize >> if I might've seemed a bit "panicky" earlier. This is a high-profile >> application, and I was starting to get that "deer in the headlights" >> feeling from the questioning that was starting to occur. >> >> Even though I can't trap the source of the problem within a >> Transaction Boundary, I'm still going to recommend that the >> application continue to use them, because the benefits that >> Transaction Boundaries extend far outweigh the difficulties in >> troubleshooting. >> >> On Apr 30, 8:54 am, Daniel Klein <[email protected]> wrote: >> >>> This is by design. The updates within the transaction boundaries >>> are treated >>> as a single update; there is no way to target why a specific >>> update failed. >> >>> If you really need to know why a particular update failed, then >>> you should >>> interrogate the permissions on the file prior to the update, or >>> (better yet) >>> perhaps when the file is initially OPEN'd by writing and deleting >>> a 'dummy' >>> record. >> >>> Dan >> >>> On Wed, Apr 29, 2009 at 3:17 PM, Bruce Willmore >>> <[email protected]>wrote: >> >>>> Hi everyone: >> >>>> I'm hoping that somebody can help me. We are running jBase >>>> 4.1.6.7 on >>>> HP/UX B.11.31 >> >>>> I should also note that we are not currently using Transaction >>>> Journaling, although we do plan to shortly. >> >>>> I'm going to start to describe my problem with a little code >>>> snippet: >> >>>> WRITE Record ON SomeFile, ItemID SETTING ResultCode ON ERROR do >>>> something >> >>>> If SomeFile happens to be read-only, then ResultCode will be set >>>> with >>>> a value indicating failure and the ON ERROR clause in the WRITE >>>> statement will get executed. >> >>>> However, if the WRITE statement is defined within a Transaction >>>> Boundary such as >> >>>> TRANSTART SYNC ELSE do something >>>> WRITE Record ON SomeFile,ItemID SETTING ResultCode ON ERROR do >>>> something >>>> TRANSEND ELSE do something >> >>>> then the SETTING and ON ERROR clauses in the WRITE statement do not >>>> execute. The ELSE clause in the TRANSEND statement executes, >>>> which I >>>> would expect, but it does not provide any indication as to why the >>>> transaction failed; only that it did fail. >> >>>> Now, I used a read-only file in my example simply because it is an >>>> easy condition to reproduce. I encountered this situation in real >>>> life >>>> with a file that got corrupted during a stress test of our QA Web >>>> Service, and the jBase backend of the service started to throw >>>> errors >>>> indicating that the TRANSEND statement had failed. Nothing more, >>>> even >>>> though all WRITEs that occur are done using SETTING and ON ERROR >>>> clauses to throw the proper error codes for the backend >>>> application to >>>> interpret. I had to investigate all of the files that are written >>>> to >>>> before finding the culprit. >> >>>> On to the actual question... Is there something that we may have >>>> done >>>> in our configuration or elsewhere that is causing jBase to behave >>>> in >>>> this fashion? Is this a bug in jBase, or is this simply the >>>> designed >>>> behavior? Thank you in advance for your assistance.- Hide quoted >>>> text - >> >>> - Show quoted text - >> >> > > > --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
