raholland3414231 wrote:

> Thanks Dany, your post actually helped a lot.
>
> I had forgot about the action list. Exactly what I was looking for.

Also indulge yourself into the source of these things. Many cool
properties of transactions and datasets are used in a way they where
supposed to. I've learned a lot from that.

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

Sure. In my experience though, I wonder why one would need that setup.
One thing is doing a DML and filling it's parameters from another
dataset - OK, I see the use of two transactions here. But in a
master-detail relationship I don't see the need for two transactions.
Might be my ignorance though.

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

Definitely. Consistency is one of the property values that is well
named. When I moved from Paradox this was the feature that would save me
huge amounts of code. Imagine printing 500 invoices and something
changes in the middle. In Paradox I had to lock or cache or flag. Pew!

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

OK. I have had that setup in a MDI DBE Paradox and a DBE IB/FB app but I
have worked with my users to make them accept the fact that the default
behavior of the software is SAVE. This saves everyone a lot of grief. In
my app, there is some 5 to 10 different ways of scrolling the main
dataset (implicitly committing). Often, it is very difficult for the
users to understand where or what the save/cancel dialog popping up is
referring to - some users need months to learn the difference between
the two last choices of a "Yes, No, Abort". It could also be a
transaction in an MDI that is not the topmost one that's trying to
speak! Today I do a implicit commit (save) when users switch MDIs (to be
very brief, simplify a lot, I have one transaction per MDI). This is a
setting, but most use it that way. If they change something in one MDI,
when they Ctrl+Tab back they can see their changes on a refresh. Of
course, a server exception would need to be handled anyway. Only when
the whole application is shutdown do I do a rollback implicitly and only
if it's the only way out.

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

Im sorry, but the concept "BDE app" is not something I'm familiar with.
I used IDAPI and OWL when I had BDE. I migrated to VCL and IBO at the
same time. There is actually a lot you can do to make an IBO (native?)
app feel like (what I assume you mean) that. Look at DML caching for
example. I have not tried it myselfe, though.

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

Its a *great* tool for debugging. I have it included in my app for all
levels of users (though its not connected to one of those big buttons).
The DataSet Status dialog is also nice. That one, however is a bit
convoluted, IMHO. I took some code from the samples so I have a
stringlist with all the transactions and their status in a toolwindow. I
think it was the pausing sample.

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

If you get that straightened out, sharing your experience would be
appreciated!

>
> I'm on the right track?

From what I can tell, yes. Doing my first big installation with this
architecture I kept an eye on the servers OAT advancement at the clients
site and at the same time kept a dialog with the IT manager. I also
looked at how many users were logged in from time to time. Even if my
app was not 100% by the book (75% book, 25% trial and error :) ) I could
sleep at night.

But I also need to say that you should get input from other people. I'm
somewhat of a black sheep on lots of techniques and other would not
agree with me on a lot of things :)

Regards,

/Dany