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