Rather than try to identify a 'part' of a statement to run in a separate transaction context (of
sorts), would it be possible to always restrict a single statement to seeing the result of all
statements before it, but not be able to see its own?

None of the modifying statements (update, insert, delete) really let us specify an order in which
changes are to happen, so it'd be difficult to plan such a statement to make use of self-visibility
within the statement. We can't really use the loops / side-effects to our advantage, but we can
definitely shoot ourselves in the foot with them. The wording of insert/update/delete statements is
very much (I think) oriented toward this view of statements not seeing their own changes.

From a nested-transaction point of view, it's a bit weird though. A transaction should normally see
its own changes, so you'd assume that a single-statement transaction would see its own changes too.
Statement atomicity seems slightly different from transaction atomicity.

But records don't have a good place to store a statement_number next to transaction_number, do they?

-Philip

---------- Original Message -----------
From: David Johnson <d_johnson@...>

> If Firebird is capable of supporting nested transactions (really big
> if), then the insert could be separated into a nested transaction that
> is owned by the user's transaction. In this scenario, the select runs
> under the user's transaction. The select cannot see anything that is
> inserted by the nested transaction, so there is no loop.

------- End of Original Message -------