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 -~----------~----~----~----~------~----~------~--~---
