Helen,
I think you're answering someone else's email here...
you're certainly not helping with this thread.

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

I never use autocommit. I very rarely use CommitRetain. So that's not it.

>
> >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!)
>

that's not what the code it doing. So your comments are meaningless.

> 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 AM testing the transaction and that's what leads to the anomolies I'm
reporting.

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

I don't need 1001 points - just one or maybe 2. I assume it's when
AllowCheckOAT reached it's timeout. But I can't find what event might
restart the AllowCheckOAT timer. i.e. what restarts the "system need".
After the timeout is reached, Refresh does nothing - it's benign. That's not
what used to happen.

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

I don't use Builder and I've never mentioned it.

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

I have and they offer nothing to me in this regard.