As I understand it IBO does a little automatic transaction handling
under the hood. What I need to find out is what I need to handle
myself, what IBO can handle on it's own, etc.

Backstory:

My application is commercial and we sell hundreds per year. Our
biggest compliment is how well laid out and easy to use the sofware
is. It's no
coincidence that the software has tabbed notebooks and a lot of
dataset manipulation that doesn't make sense to me (Excel). Yes, this
is a BDE->FB conversion- delayed over a year.

Our main form is populated with a ton of dbedits showing the makeup of
a an order with two detail grids showing this order's pick/drop
information.

So at the basic level I'll have 3 IBOQueries open here with select
statements. (My plan is to go all native ASAP). From what I can tell
this starts an under the hood transaction for the selects that remains
open. Our users will sit on either this screen or another screen
that's one select query showing rows of active orders in a grid (this
one IS native already). Since they will browse for hours working,
shall I keep the transaction open and do tr pausing? I did a monitor
on this and saw some commits happen as time went on. I set the
PromptUser to 60 seconds and walked away from a screen, never once
seeing the prompt. If what I'm seeing is true, IBO seems to be
handling these browse situations perfectly. So far I'm only calling
explicit transactions on things I think need concurrency and calls to
.edit/.insert/delete, cursors,D_SQL executes.

I bought Helen's Firebird Book, IBO 4, and the GSC. I'm reading
through Helen's transaction section. This is a VERY well written book
and will probably never leave my office. IBO has to be the most well
thought out and written data access component set i've ever used. I
can't imagine working with any other components after this. I just
thought you two should know how appreciative a lot of people are of
your hard work.

Richard Holland
Holland Solutions/Dr. Dispatch