At 02:06 PM 8/09/2005 +0000, you wrote:

> > Try to provide more information about what your transaction is doing.
>That's the funny thing. We don't have to actually use the
>connection/transaction/query to see this problem. The
>connection/transaction/query are designed on a Delphi datamodule.
>When the program is started, the datamodule is instantiated. We never
>get to the part of the program that uses the query. We simply start
>the program and then exit. But, I think when the connection is
>created the internal IBO logic to test the parameter ordering is
>executed. And I believe this is where the transaction problem is
>occuring.

OK; what I meant was, would you describe the transaction setup. So

1) Are you
a) using the internal transaction as the DefaultTransaction of the
ib_connection or
b) are you assigning an explicit ib_transaction to this property?

2) If b), what are the settings for the transaction properties Isolation,
ReadOnly, Autocommit? (One thing I'm trying to get to here is why you
would set a ReadOnly transaction to Autocommit...thus causing the ReadOnly
transaction to block the advance of the OAT and OIT.)

I have another question for you - see below --

> >
> > Could you please answer *all* of the following questions:
> >
> > 1) Are you using TIB_Query or TIBOQuery?
> >
>TIB_Query
>
> >
> > 2) Please provide EXACTLY which versions of each piece you are using:
> >
> > a. Delphi - which version, edition and upgrade level. Get this from
>the Help|About box in the IDE.
> >
>Version 7.0 (Build 8.1)

OK: you have the fully patched Delphi 7, as I do. Jason, would you note
this, please?

I'm seeing what seems to be differences between this version of Delphi and
others, regarding how default values are interpreted from and written to
the DFM. Geoff and I have been on this case for some days. We are using
different versions of Delphi 7 (Geoff has the unpatched D7 Personal
Edition, whereas I have the fully patched Enterprise edition). When I
bring source code from a previously Delphi 6 project into Delphi 7, the
transaction isolation goes "wild" and, effectively, I cannot get a
transaction in tiCommitted isolation, no matter what I do. It seems to be
related to the default value of the Isolation property of TIB_Transaction
being changed from tiCommitted to tiConcurrency during the transition to v.4.5.

There appear to be quite a lot of variables in the equation, so I'm not
able at this stage to say exactly what's occurring. It's OK in my fully
patched Delphi 6 Enterprise with IBO 4.5, but seems to be not OK in that
Delphi if I have IBO 4.3Aa installed...

Geoff thought that, for consistency across Delphi and IBO versions, IBO
probably should write the Object Inspector setting for Isolation to the DFM
unconditionally, i.e. NOT to force the deletion of that property setting
from the DFM in the case where it appears to match the internal
default. (I hope I got this right, Geoff...)

> > b. IBO - read the Version string from the IB_Connection in the Object
> > Inspector. 4.3Aa and 4.5.B (we see the problem with either version)
>
> > c. Database server: Brand (Firebird/IB) and build number
>FB 1.0.3 or FB 1.5.3 (we see the problem with either version)

Fb 1.5.3 is not a release version. (Jason, N.B.)

> > d. If any Fb 1.5 build, the setting in firebird.conf for
> OldParameterOrdering
>We've made no changes to this file: "#OldParameterOrdering = 0"

This is interesting in the light of the problem that I've been tracking
(although my issues have not been tested under the Fb 1.5.3 release candidate!)

Theoretically, you should not need to change the default setting of
ParameterOrder at all *except* when you have OldParameterOrdering set to
1; in which case it should be set to poOld. The underlying property is a
Boolean, that gets set according to the value of the flag that, in turn, is
set according to the value of ParameterOrder in the IDE. Logically, if it
isn't poOld then it is poNew and one should ignore it for Fb 1.5.x and set
it to poOld for Fb 1.0.x. (At least I think so. It does confuse my
mixed-up head that the property's definition differs from the way it
surfaces in the Object Inspector...)

> > e. Client library: Brand (Firebird/IB) and build number FB 6.2.3.972
> (FB 1.0.3) or FB 6.3.3.4842 (FB 1.5.3)

This is a slightly confused mix for addressing the OldParameterOrdering
issue. With the Fb 1.0.x server and client, only poOld is applicable
(which the TIB_Connection should detect and set automatically.) The
correction to the parameter ordering was not present in Fb 1.0.x.

You are using the unreleased 1.5.3 server and client and switching back and
forth between this and Fb 1.0.x. So it seems impossible, on present
accounts, to determine whether the problem you are seeing arises from a
regression in the release candidate code ( we don't see any pattern for Fb
1.5.2...) or is due to using an executable that was compiled for one Fb
version and is being used with another.

Something seems fishy to me, though. No answers, just more questions...

Helen