At 12:04 AM 26/10/2003 -0700, Jason wrote:

> > Will a newer IBO version solve the problem?
>
>Yes, the next one will. I have added two properties to the IB_Connection
>class.
>
>ParameterOrder can be set to poAuto, poOld and poNew.
>It will default to poAuto which will cause it to do a test query against the
>server to determine which parameter ordering scheme the server is using.
>
>The second property is OldParameterOrder which simply tells which method it
>is using. This property is read only and can be accurately read after the
>connection has been made.

I'm starting to wonder how many people actually understand the implications
of the OldParameterOrder parameter. I've been struggling in fb-devel for
some days now and he's not getting it yet. Perhaps nobody else cares...

At Nickolay's request, I've restated the problem in fb-devel today, in an
attempt to get past his assumption that I'm attacking him again...(yes,
there's a history of disagreement there, to do with his attitude to Linux
incompatibilities...)

fwiw, I'm copying my posting below. If you think it matters, then please
try to support me in this. Firebird 1.5 isn't released yet.

The thread title is
Subject: Re[4]: [Firebird-devel] Firebird Server 1.5 Win32 Installation
(note that the number goes up every time Nickolay posts - looks like an
email client he wrote himself...)

Date: Mon, 27 Oct 2003 12:03:54 +1100

Hi Nickolay,

At 06:20 PM 26/10/2003 +0300, Nickolay Samofatov wrote:

>Hello, Helen !
>
> > I have put a compelling argument why this should be a flag in the
> > API. Your only argument against it is "My opinion is that no changes are
> > required in this area". No reason. No solution.
>
>I haven't seen any compelling arguments from you yet. Could you
>please try again to describe the problem and proposed solution.
>Carefully and calmly, please.
>
>Currently, what I hear is only statement that my faulty design
>descision (that I fixed parameter mapping bug) made thousands Firebird
>users suffer. This is obviously wrong, so I want to hear further
>explanation.

Then you are "hearing" the wrong message, totally, and you ought to review
this dialogue. There is NO suggestion that **fixing the bug** was a faulty
design decision. It was a good and essential decision and does not dilute
your status in any fashion.

The faulty design decision was to make it a server configuration parameter
instead of an API flag. Please try to read this message as a problem
description, not a personal attack.

Here's the problem.

When OldParameterOrdering is true, it affects all databases and all clients
on the server. It means that ** the only client that can reliably use the
server is one that "knows" about the scrambled parameters.** The
"thousands" are sites out there where IBO applications and tools are
deployed, a significant chunk of users of Firebird on Windows.

We're not talking about new sites, new applications here. We are talking
about sites which have stable, established software built with IBO **and**
other interfaces.

Here is what we will hear on the support line:

"Firebird 1.5 has some kind of really bad bug. Our software worked fine
for 5 years on IB and Firebird 1, now we are getting exceptions and bad
results."

Current answer: "No problem, just shut down the server and set OPM true."

Next support call: "I did that and now Application A works but our reports
and ad hoc queries don't."

It's a common scenario for users (without even being aware of it) to
connect their main application with IBO and their report or ad hoc query
apps with ODBC. Your implementation breaks that capability and effectively
prevents them from upgrading to 1.5.

The "workaround" scenario you proposed (which has been implemented in the
next sub-release of IBO) is a hack that does not solve the problem. It is
"one-way and all-or-nothing". All it will do is test whether OPM is true -
it doesn't neutralise the need to configure the server so that it will work
ONLY with IBO applications.

If there was a flag in the DPB of the API, then the only requirement would
be that the IBO connection be aware of it and the server would return the
scrambled parameters to that client instance. The OPO parameter would
simply go away.

**Of course** it is not reasonable to argue that Firebird should continue
indefinitely providing compatibility support for old bugs. However,
Firebird can't afford to ruthlessly ignore the realities of modern software
deployment. We have to be able to ship stuff that "just works" and doesn't
break other stuff. The reality is that our end-users don't get software
upgrades every five minutes, or even every five months. If you have always
worked in an environment where you are in total control of what users do
with their systems, and you can implement total software replacement at
short notice, then you have a luxury that has gone forever for most of us.

regards,
Helen