Jason Wharton wrote:

>
> To do as you are suggesting would require me to parse in the
> additional column and figure out where it was in the numerical position
> relative to other columns (which would be hard if it was an *).

I'm not trying to push you to use this workaround against your will,
but's not that hard. You can do:

SELECT
UPPER(B.FOO), B.*
FROM
BAR B
ORDER BY
1

...and you know that the index will be 1. :) A (very slightly) more
involved issue would be "hiding" the additional column from the IBO
user.

For me, however, the real downside of this is the additional network
traffic. It's a neat trick because it doesn't require a metadata change
or a collation driver, but it's obviously not a long-term solution.

It does, though, suggest one way this could be implemented...

> So, in summary, if the server would allow UPPER() in the ORDER BY then the
> developer of IBO apps could have case insensitivity without having to do
> anything in their database and just checking a simple option in the property
> editor.

Yes, I agree this would be a good feature, and I can think of no reason
(save time and effort) to limit it to UPPER, FWIW. Does anyone know if
the SQL standard have anything to say on this point?

-Craig

--
Craig Stuntz Vertex Systems Corporation
Senior Developer http://www.vertexsoftware.com

Delphi/InterBase weblog: http://delphi.weblogs.com
_______________________________________________
Ib-architect mailing list
Ib-architect@...
http://mers.com/mailman/listinfo/ib-architect