Helen,

I commend your communication on this.

Well spoken and presented.

Jason Wharton

----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <IBObjects@yahoogroups.com>
Sent: Sunday, October 26, 2003 8:13 PM
Subject: Re: [IBO] OldParameterOrdering


> 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