At 11:46 PM 28/10/2003 +0100, Aage Johansen wrote:

>On Mon, 27 Oct 2003 03:05:02 +0000 (UTC), Helen Borrie wrote:
>
>Helen, it seems we need Dialect=4...

;-|

>However, making Fb/1.5 act like the
>old one (in this respect) seems not to be possible.

The current OPO emulates the old one - with some differences, if I
understand Nickolay correctly. It sounds to me as if OPO doesn't cause the
engine to loop into the old code, but to loop into some other new code that
he wrote to get the parameters to come back with the old ordering.

>If I'm reading firebird-devel correctly, there is no way IBO users can move
>to Fb/1.5 before _all_ applications are relinked to a new/fixed IBO version
>(which should work correctly with both new and old Firebird engines).

For IBO apps compiled with current and past IBO versions OPO should do
that, at least theoretically. The problem is that the server can't be used
in any other way, so it's broken for ODBC, JDBC, PHP, etc.

Jason's current fix makes it so that the application can tell whether the
server is set up with OPO. IBO parsing currently doesn't handle the fixed
parameter ordering, as far as I can tell. This is a hack, since the
application actually has to connect to the server to find out. However, it
does mean that it will get the right answer, even if there is no
firebird.conf, since IB and Fb 1.0 will return the same answer as Fb 1.5
with OPO set to true.
*****
The "hole" exists where OPO is set to false (the default). IBO can't deal
with that. (Jason, please correct this if I've interpreted your
description wrongly. I'm speaking on the assumption that you haven't added
any loop processing to handle new parameter ordering).
*****
I've become convinced that an API flag isn't a solution. If Firebird were
the only consideration, it would be the right thing. But what happens if
the app is connecting via a client lib that doesn't have the flag? IB (any
flavour) or Fb 1.0.

As this dialog proceeded in devel, I inquired whether an extra, optional
flag on the alias definitions could be considered as a way to localise the
"decision" to the client side. There have been no comments on this, so I
don't know whether it is a realistic proposition or not. I remain
convinced that the server configuration is NOT the right way to do it.

>I'm now somewhat apprehensive/reluctant to go ahead with an upgrade to
>Fb/1.5 when it is released.

* If you can live with OPO I don't see a problem.
* If Jason comes back on this and tells us he has included processing of
correctly ordered parameters, and my assumption is wrong, then it should be
OK too.
* In theory, it should be OK, no matter what, if you always use FieldByName
or Row.ByName to access returned parameters - just that I do recall Geoff
mentioning that there could be a problem with ByName under some conditions.

Helen