| Subject | RE: [IBO] Transaction.Refresh(True) |
|---|---|
| Author | Helen Borrie |
| Post date | 2006-09-19T01:08:34Z |
At 10:00 AM 19/09/2006, you wrote:
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.
for TIB_TimeOutProps. It's explained in detail there.
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.
"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
> >Correct. A transaction Refresh iterates through all its datasets and
> > 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.
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.
>2 questions.Oh yes it does. Please follow the links through and read the help
>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?
for TIB_TimeOutProps. It's explained in detail there.
>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.
>Is there something special about these with regard to readonlyNo. A read-only transaction is still a transaction....while a
>transactions/queries?
"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