Ann,

Thanks for your gracious and informed reply. (I was on an IEEE working
group for a standards proposal a long time back, but it wasn't so
bad--and it didn't cost anything to participate.... :~\

I have one more question for you and the group at large: If you
install a collation that treats upper and lower-case letters as
equivalent, would this issue arise? That is, my table's named
"data_table" (with the quotes so it's in the system tables in
lower-case) and I do this select (without the quotes so the SQL
compiler is going to convert the token:
data_table
to
DATA_TABLE
before it goes looking for it in the system tables. So, if I've got a
collation that considers these equal, would that solve the issue I'm
having?

Is such a collation even practical? (I realize it'd violate some
provisions of the standard that allow "MyTableName" and "mytablename"
to be distinct identifiers.)

The reason I'm interested in knowing that is a lot of the data I'm
going to be storing is textual in nature and I don't want to have to
worry about duplicate columns in all upper case or what-have-you
(unless there really is no other option). Clearly case-insensitivity
would be useful to many folks who've posted to this group.

As far as identifiers are concerned, I'm now resigned to just dealing
with ugly all upper-case identifiers--unless someone's working on
collations that allow case insensitivity...and that would affect the
lookup in the system tables. David Schnepper's collations aren't
available for FB 1.5 at this point--and I don't know what's in his set
anyway. In any case, I'd be very interested in hearing from anyone who
has a case-insensitive collation available to install or even plans to
implement one; I might be able to help.

Ann, two thoughts on your gracious reply to my overly long post:

The reason for not putting things into the system tables in all upper
case is that it makes them really hard to read. In particular, if you
then extract the DDL from the system tables, it not only wouldn't
match what you'd originally used to create the tables (assuming you
used lower-case in the first place), but it's unnecessarily hard to read.

The issue of comparing the SQL tokens to what's in the system tables
is a whole n'other can of worms--case insensitivity would sure be
helpful for lots of us (as I've already mentioned). For the
applications that are of interest to me, the minor performance
difference is insignificant (I presume use of PREPARE STATEMENT means
that the SQL compiler only needs to find the corresponding entries in
the system tables once anyway.)

You also wrote:

> In fact, the culprit here, it seems to me, is neither the standard
> nor Firebird, but an overly ambitious GUI tool that decided that
> all identifiers should be quoted.

Actually, IBAccess apparently only quoted them because I entered them
in lower-case--and in defiance of the example identifiers which were
all upper-case. When I extracted the DDL, it gave the identifiers back
to me quoted, so it was consistent and I can see where I took a wrong
turn in using it the way I did.

I'd hate for the implementers of that tool to be blamed for my
mistake!

John
Alpha-G Consulting