> At 10:00 AM 19/09/2006, you wrote:
> > >
> > > I've just upgraded an oldish application to the latest IBO 4.6.B
> > > from maybe
> > > 4.5 something.
> > > I notice that the Transaction.Refresh(true) which I relied on
> quite a bit,
> > > no longer refreshes the connected queries.
> > > I now have to manually open and close them.
> > > This has to be an issue with someone else no?
> > > regards
> > > Alan McDonald
> > >
> >
> >I've narrowed this issue down to the transaction timeout properties.
> >If the transaction has timedout, a refresh will not restart it.
>
> Correct. A transaction Refresh iterates through all its datasets and
> closes and reopens them. If the transaction is dead (having been
> committed or rolled back) the transaction itself will need to be
> restarted in order to revalidate its datasets.

You cannot start a transaction with the StartTransaction method unless one
if it's datasets is active. 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. 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.

> >2 questions.
> >1. Help file talks plenty about "end[ing] a transaction that is no longer
> >needed by the system." but never explains what properties it relies on to
> >decide it is no longer needed. Can someone enlighten me please?
>
> Oh yes it does. Please follow the links through and read the help
> for TIB_TimeOutProps. It's explained in detail there.

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

>
> >2. I've never set or used timeoutprops before.
>
> Now would seem like a good time to get acquainted with it, if you'd
> like to take advantage of the automated timeout features.
>
> 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?

>
> >Is there something special about these with regard to readonly
> >transactions/queries?
>
> No. A read-only transaction is still a transaction....while a
> "read-only query" is entirely a client-side concept. By nature,
> SELECT statements are reads and other statements are writes.
>
> Any query inside an "interesting" read/write transaction is going to
> "stick" the OAT unless it is in a read-only, read-committed
> transaction. I don't believe IBO makes any special choices in
> accordance with the special OST conditions that apply to the latter.
>
> Helen

Alan