Hi, Woody. My post is rather late, but why you (and many other
people) use the same transaction to show user large amount of records
in the grid and for performing changes? I use <read_commited read>
transaction for first and <concurrency nowait> for second:

1. User looks at data.
2. User begins edit
2.1. Snapshot started
2.2. Current row re-fetched by another query within snapshot
and is showed in another controls (popup form or panel)
2.3. Changes are made in controls
2.4. Try to save changes. Variants:
2.5.1. Success - Commit snapshot
2.5.2. Lock conflict
If changes are saved in single query then Commit
else Rollback snapshot;
GoTo :) 2.1.
You can save within controls user's changes and show him
new data (reconsile) or simply show new data only.
2.6. Refresh row in main dataset

It allows you commit read transaction to free resources in moments
when it is suitable for logic of your application. And you can even
avoid effors on reconsiling by forcing early lock conflict and
informing user that raw is busy via dummy update before 2.2. It's not
good tactics, but in some cases acceptable when large memo columns are
edited.
Yes, it's retro style. You want edit within grid, I know. If so,
you can emulate it by doing all stuff around saving in snapshot on
MainDataSet.BeforePost and then do MainDataSet.Cancel within
BeforePost. And Refresh on AfterCancel. BTW, FIBPlus (descendat from
FIB like IBX) allows to assign different transaction for modify
objects of dataset (little spam :).

Best regards.