Not anything else.  True values are any that evaluate numerically as non-zero.  Strings evaluate numerically by treating the beginning of the string as a number until a non-numeric character is encountered.  So "1 avocado" evaluates numerically as 1 and "-.04abc" evaluates numerically as -0.04.  Both of these strings are true.  "basil" is just as false as the null string. 

For more discussion see the docs here:


It's unclear what's going on here, but it would be worth checking the .int version of the compiled class to see if there's anything unexpected (not sure what that might).  Also ensure that the latest version of your code is compiled, though I'm sure you've already done that.

Well, applications can audit to the audit database using $system.Security.Audit().  That would provide the rollback protection described and also the other benefits that the CACHEAUDIT database affords.

I think it would be difficult to form a general purpose rollback handler that would be simple enough to be the most usable solution.  Rollbacks aren't necessarily like exceptions.  Speaking very generally, there's two main cases, I think:

 a. The transaction is in a function you're writing. You already have complete control so you don't need a special handler.  

 b. The transaction is in the function you're calling in a function or that function calls. Remember transactions can be nested and there could be many transactions inside the callee.  Your code doesn't know whether the callee's rollback was expected or not, and doesn't really have any context around what is being rolled back, so I'm not sure how you'd have a sensible handler - it would be very non-local.  With any function you call, In the end, your code is going to get some indication of success, and if callers of a particular function have some need to know whether rollback was performed, then I suspect it's specific to that function and up to it to return the necessary info to its callers in a way that is appropriate within the interface it provides.


Hi Derek,

Audit records are not be rolled back if they were inserted in a transaction that happened to roll back.  (Note that I am assuming we're talking about the standard system auditing that either gets inserted implicitly or by calling $system.Security.Audit() explicitly.)

The records are journaled, but not flagged as being in-transaction, and so they are skipped by rollback.  Note that the same applies to entries created by the standard error log: ^%ETN and the Log() method of the exception object.

So, there's no need to call DISABLE^%NOJRN, though even if you did, it would not cause <ROLLFAIL> error.

As for getting this to automatically happen any time there's a rollback, there's nothing at the system level that provides that.  I believe there are various triggers within Objects and SQL, but I'm sure you know more about those than I do.