Richard Holland wrote:

> Hi, as I've posted before I'm converting a 100,000+ line BDE app in D4
> to FB 1.5+IBO4 in D7 Enterprise.
>
> I'm happy to report the entire thing runs with itself, an ini file
> pointing to a host running fb, and fbclient.dll! I'm BDE free for the
> first time in 11 years.

Congrats!

> Questions:
> 1) We used to have 1 datamodule that everything shared, often our main
> "order" dataset was reconfigured on the fly with filters and used across
> hundreds of reports. This upset me so I'm working fast to break into 5
> datamodules each containing a ilconcurrency trans for reports/updating
> statements and ilcomitted trans for browsing. I'm hoping this is the
> right direction?
>

I use concurrency for reports and comitted for browsing/update. I'm not
sure on concurrency for updating but I am that someone else will pitch in.

> 2) I had thought checking a dataset's transction for TransactionIsActive
> would tell me pending updates/inserts where there to commit/rollback -
> I'm getting this true on selectquery.open, so I'm guessing I'm wrong and
> this property is true if a logical transaction, started by either me or
> automatically, is active which could be caused by select statement dml?
> If so I'm finding it hard to detect uncomitted transaction changes and
> asking the user for input. I've noticed I can't get TimeOutProps to
> prompt, and I'm assuming my transaction is for some reason entirely my
> fault not ever going idle.

I use the built in IB_ActionCommitRetaining or IB_ActionCommit. Connect
that to your transaction and check it's properties. I think thats what
you want.

>
> 3) What I want is a constant flow of:
> -StartTransaction either explicit or via IBO
> -commit or rollback as necessary
> -be sure the OAT advances alright
>
> Especially if a lot of browsing is going on with a commit action of
> anything other than close, right?
>

Yes. If your users "hang on" with commitRetaining for a long time it
might cause problems. See the Pause Transaction example in the sources.

> 4) Any thoughts keeping the pagecontrol and treating each tabsheet as a
> "form" dataset wise? Seems like if I open/close on pagecontrol change I
> could check transactions here and act accordlingly. I'm inclined to
> ditch the pagecontrol/tabs for mdi forms (our users won't tolerate SDI,
> which I prefer). Our users get lost FAST though.

I have it set up like this and with 30 users it works fine. (The day I
need it I will implement the pauseing stuff from the excellent example.)

There is one "Main" dataset. This one is active regardless of what tab
is active. The rest of my datasets are details to this one. The datasets
that lives in a different tab are closed when the user commits. When
another tab gets active the datasets on that tab is activated
(dataset.active := true) in the event of the tabcontrol. If the main
dataset scrolls I always do a commitRetaining so any open detaildatasets
in the other tabs gets closed.

Note that all details are left open on tab change so I do not need to
commit then. The details are only closed after a committ.

Actually it was Jason who sugested this approach to me to speed up
scrolling.

I use native components so my approach might not be for you.

HTH,

/Dany