Thanks Dany, your post actually helped a lot.

I had forgot about the action list. Exactly what I was looking for.

I also tracked a bug down causing a dataset hooked to my
ib_transaction to go into edit and then post. This was causing a read
of TransactionIsActive to be true when I thought it should be false.
This seemingly minor issue spawned my original post.

My plan is still to logically group IB_Transactions while being
careful to make sure I:

1) Realize when a dataset in one transaction references a dataset
hooked to another I can run into issues. These issues are not
errors/bugs/problems. They are just transactions doing their jobs.

2) Keep isolation level in mind for my users. A sensitive report that
needs a consistent view from start to finish should not be read committed.

3) My users need to press a "Save" or "Abort" button when they're done
with some work. If my users try to leave an area of my application
without doing so they should be asked if they want to save/abort their
changes. At this time I don't see a need to use commitretaining, so
they would be commit/rollback;

4) If me or my clients treat this application like a BDE app, it will
defeat itself

5) I should probably see everything I do happen in ib_monitor for too
many reasons to list here.

6) Learn to tune timeoutprops and my UI to account for a "serial
browser", as many of my users seem to be.

I'm on the right track?

--- In IBObjects@yahoogroups.com, Dany M <arbit@...> wrote: