Hi. If (as you'd expect) the DBMS handles this issue automatically with
fresh SQL,
the issue has to do with the DBMS processing parameter values sent via
prepared statements. There are other examples of this, such as
comparing
a CHAR(100) column value to a shorter string. The DBMS processes
the fresh SQL and silently interprets the query to expand the smaller
string
with enough blanks to make it 100 characters long, and then makes the
comparison you would want. However, if you send the smaller string via
a parameter, the comparison will fail until you manually pad it to 100
chars.
  I do not think Oracle will change any of this, so Jeff's suggestion
is
good. We hope Oracle's driver returns the correct answer to
storesUpperCaseIdentifiers()
etc ;) * 0.5.
Joe

That is not the complete truth. Those methods only say how an _unquoted_
identifier will be treated. Even though the database will return true for
storesUpperCaseIdentifiers() it is perfectly possible for the database to
have lower case object names. For example, see the following SQL session:

SQL>create table "a"(c1 integer);
SQL>create table a(c1 integer);
SQL>insert into a values (1);
SQL>insert into "a" values (2);
SQL>select * from a;
         C1
===========
          1

                  1 row found

SQL>select * from "a";
         C1
===========
          2

                  1 row found

SQL>select cast(table_name as character(20)) from
information_schema.tables where
table_schema=current_user;

====================
A
a

                  2 rows found

SQL>

The above session is with Mimer SQL but I doubt Oracle behaves differently
on this issue.

From this perspective it is also clear that the meta data methods
discussed here _must_ be case sensitive to handle object created with
quoted names.

Also, any database that return false for storesUpperCaseIdentifiers() is
not in compliance with the SQL standard.