> > > > All that being said, you will slap yourself in the head a couple
> > > > of times with field names like:
> > > >
> > > > "Name" and NAME both in the same table.
> > > >
> > > > If not, your boss should do that.
> > > >
> > >
> > > If NAME is just an uppercase shadow of "Name" it makes sense! Maybe

too

> > > clever - one easily trips over things like this.
> >
> > Oh, it makes sense. Until you're writing queries :-)
> >
> > select name, "Name"
> > from ...
>
> It would be
> SELECT "Name", "NAME" UpperName
> if I were going to need it. It's just for internal constraint use.
>
> It was during my testing of the use of collations with unique indexes
> and unique constraints when ISO8859_1 collation EN_US was used that I
> discovered the problem.
>
> >
> > Works just fine. Then do things like:
> > FieldByName('Name') etc...
> >
> > Very clever. Very confusing :-)
>
> Not really. I'm used to writing in C and C++, where the use of
> various-cased variables and constants has proved very useful indeed.

It's not "case" that makes the name, it's the characters.

> Nevertheless, doing this may have found a problem in Firebird.

Actually, I think it's a problem with the components you're using.

As I said earlier - "selecting an index" has nothing to do with Firebird.


With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com