At 06:32 PM 19/09/2006, you wrote:

>You cannot start a transaction with the StartTransaction method unless one
>if it's datasets is active.

Utter bunkum. A transaction *has* to be started in order to pass a
request, e.g. to open a dataset (which needs a SELECT statement).

>So my code now reads like this:
>
> bJobStatusCanStart := False;
> for i:=0 to dmLocalStore.IB_TransactionJobStatus.DatasetCount-1 do begin
> if dmLocalStore.IB_TransactionJobStatus.Datasets[i].Active then
> bJobStatusCanStart := True;
> end;
> if not dmLocalStore.IB_TransactionJobStatus.Started and
>bJobStatusCanStart then begin
> dmLocalStore.IB_TransactionJobStatus.StartTransaction;
> end;
> dmLocalStore.IB_TransactionJobStatus.Refresh(true);
>
>But this still raises an exception when the transaction has timed out.

A "timed-out" transaction is but a previously started transaction
that has been explicitly committed (or rolled back) according to the
timeoutprops settings. Note, though, that a transaction that's set
up to CommitRetain effectively can never time out, since it gets
restarted immediately. Maybe you are getting some complications by
having Autocommit true?

>One
>of the Datasets still appear to be active while
>dmLocalStore.IB_TransactionJobStatus.Started returns False, but I get a
>"Transaction has already been started" exception when I try to start the
>transaction.

Don't test the datasets to determine whether a transaction is started
- test the transaction. (Thinking this through will require you to
discard your strange beliefs about the order in which things happen!)

It's a very good design strategy to ALWAYS test the status of a
transaction *before* you try to start it (or end it by committing or
rolling back).

>I've been thru the help with a fine tooth comb. What constitutes "no longer
>needed by the system" is definitely NOT explained.

There is not a 1001-point list describing all of the possible
conditions. It's the actual properties that you configure that
determines the timeout conditions.

> > Over time the issue of storage of defaults in Delphi and their
> > behaviour from one Delphi release to another has been a repeated
> > source of headaches. From 4.5 onward (as far as I recall), Jason did
> > something to circumvent this issue. I think it's possible that, with
> > old sourcecode, your existing apps might have defaults stored in the
> > DFM that are tripping up your expectations with more recent IBO
> > versions.....meaning that, for self-training purposes, it's probably
> > going to cause less frustration if you start out with new objects.
>
>that's a no starter - if you saw my datamodule you'd say the same thing.
>Can you tell me what defaults have changed or been deleted? Do you have any
>idea?

I do have an idea of the ones that affected my applications,
specifically transaction isolation and the Wait and RecVersion
settings for ReadCommitted transactions. Exactly how the changes
would nett out for would depend on what you were using
before. Because of the bugginess of default behaviour and DFM
storage of it in Delphi 6 and 7, I've taken care to configure
everything explicitly for the past 2 or 3 years and not rely on
Delphi to do the right thing.

With a bit of luck, Geoff will be watching this thread and can
pinpoint particular issues for you, esp. considering you are using
Builder, not Delphi. I know that he did quite a bit of digging
around to try to find out what was going on, during the period
between IBO 4.3 and 4.5, and made some of the recommendations for
improving the situation.

Since we *are* talking about changes that happened a good long time
ago....a good many sub-releases back....it would pay you to study the
release notes of the various versions.

Sorry I can't throw more light.

Helen