triggers and update count

Hi all,

in a recent project we are attempting to make use of triggers to increment
snapshot ids (kept in separate tables), which will save CPU cycles when
querying for recent changes to the database.
The reasons to use triggers over some implementation in the businesslogic (
e.g. SimpleORM's pre-flush hooks) are several, e.g.
a) one snapshot represents the state of several tables (i.e. several
triggers work on the same snapshot)
b) manual data edits should still be safe and painless.

The issue we have come accross with this approach is that when SORM flushes
a record to the database, the update count contains updates to tables
updated by the trigger (SQL Server) and the optimistric lock check code (see
below) in SRecordInstance.flush() will throw an
SException.InternalErrorsince it is expecting the update count to be
1:

  /// Execute the Query
      int result = 0;
      try {
        result = ps.executeUpdate();
      } catch (Exception rsex) {
        throw new SException.JDBC(
          "Executing " + qry + " for " + this, rsex);
      }
      if (result != 1) {
        if (optimisticFieldValues != null && result == 0)
          throw new BrokenOptimisticLockException(this);
        else
          throw new SException.InternalError(
            "Rows Updated " + result + " != 1 "  + this);
      }

Now the question:
Why is the check done for result != 1 rather than "result not in {1,2,3}"?
Simpleorm is built around primary keys and I am assuming that
SRecordInstance.flush() could never update more that one row directly. If
the update counter is indeed higher than 1, then only due to - intended -
sideeffects. What uninteded effects could this code be trying to trap? Is it
safe or would we miss nasty conditions if we were to write the optimistic
check code as:
if ( result <= 0 || result >=3 ) {
    // handle condition

Thanks for any responses in advance,
Alexander