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