Hello Svein.

So far I used the 'old +0 or || '' trick' just in the where-clause (suppose because so far we haven't had any problems with the
order-by).

I tried as you have proposed and it works. We are now revising the order by's in our application and the stored procedures.

Nevertheless I think the optimizer in this case could get 'optimized'. Don't know if to post it to the development group.

Thanks for the tip,

Stefan

El 04/05/2011 9:44, Svein Erling Tysvær escribió:

>
> Hi Stefan!
>
> With every new Firebird version, the optimizer is improved. In most cases, that will lead to quicker or equally quick query
> execution, but occasionally the optimizer gets things wrong and things slow down. I have little to no experience with Fb 2.5,
> so I cannot say how often you risk running into such a problem, just that regarding Fb 2.5 vs Fb 2.1 this is not commonly
> reported to this list.
>
> The quick solution would be the old +0 or || '' trick, i.e. change your query to
>
> order by nro_albaran+0, nro_linea;
>
> or
>
> order by nro_albaran || '', nro_linea;
>
> depending on the type of nro_albaran. Adding this to the first field in the order by, should at least prevent any index from
> being used for the ordering part (although, in some situations using the order by could speed things up).
>
> I don't think you'll find anything in any configuration file, and, yes, it could be beneficial to test your queries when
> changing database version (you don't have to execute all queries, just take a closer look at those that produce a different
> plan when comparing Fb 2.1 to Fb 2.5).
>
> HTH,
> Set
>
>

[Non-text portions of this message have been removed]