>Martijn Tonies wrote:
>> Well, you're looking at the problem the wrong way OR you didn't
>> explain it in enough detail: WHY would you want to potentially
>> transfer millions of rows in a resultset to your users?

At 10:52 AM 9/10/2009, Geoff Worboys wrote:

>It is one thing to explain to a person that Firebird has some
>limitations... and to explore alternatives and to check whether
>the situation can be avoided.
>
>It is quite another to continually bludgeon that person with
>the "fact" that they must be wrong; that anything Firebird does
>not do must not be worth doing. (Especially when it obviously
>works, even in Firebird, in all but this odd situation.)

I'm at a loss to see who actually did that, though. I've watched a number of helpful postings that could assist the OP to deal with the situation by approaching the logic of the problem differently, that avoids the mistaken assumption that all database engines store indices in material files and can reorganise them efficiently in run-time. Standard SQL does have some theoretically sound ways to approach complex ordering of sets, independently of how this or that engine implements indexing. If the OP finds the whole thing too abstract for comfort then he only has to ask more questions.

>We start to seem a little desperate and over protective.

I haven't seen evidence of that in the posts for this thread. Until your posting, Geoff, it didn't seem contentious at all. Further, I don't see how bending it that way helps the OP solve his problem, either.

>Database and computer science theory is all very useful when it
>explains what you see from all products... but when a solution
>is available to others but not Firebird then our oh-so-elegant
>excuses start to look a little pathetic.

In these circumstances - where the poster is not asking just "how" and "whether" but also wants to know "why not" - I don't think it is surprising when a die-hard SQL engine expert such as Ann comes out with a bit of theory as an attempt to enrich perception of the problem. Theory is rarely the whole answer to everything and I fail to see how Ann's posting could be construed as some kind of attempt at an "elegant excuse". It happened to be a topic where Ann obviously felt that a theoretical insight might help to understand the underpinning of ancient design decisions.

I'd also make the point that trying to solve an end-user's problem by conducting an emotive discussion about how Firebird should change to behave more like Access or MySQL is intrusive and off-topic in this list. If people are really serious about arguing a case for a feature enhancement or a re-implementation, they should do it in firebird-architect or firebird-devel.

^ heLen ^