raholland3414231 wrote:

> 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.

Helen is better at this stuff than me - but here goes.

> 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.

Only a year ? :)
I dropped BDE in 1999 - and it had taken me a year then to take the
plunge with IBO

> 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.

IBO does viewing well, the fun comes with posting edits. Basically until
a change is made to the data nothing will get blocked, but even then IBO
does a good job.

> 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.

If I am right, the only way to get the prompt would be to make some
changes in a grid that this active for edits. THEN walk away without a
commit. I have fun when people are building a long multi line order and
reserving stock at every line, but you want to be able to rollback if
the order never gets completed. Multi-level transactions don't exist, so
I end up committing every line, and have a routine to return the stock
in the case of 'rolling back' the order. On occasions stock gets
'stuck', but 'stock check' keeps a check against pending orders and
flags when more stock is 'allocated' than is required by 'pending'.
Result is that someone can take all morning building an order without
blocking the transactions - and IBO does it under the hood so to speak.

> 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.

I've had customers buy the book even though they don't need to know what
is going on inside - and they find that they can understand things ;)

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.