That is correct. The JDBC task doesn't change the names. But if you create the 
classes (om) it creates the column names with uppercase letters and than there 
is the problem because you cannot make any queries. Here is an example:

Generated XML file (correct):

    <table name="address">
        <column name="class" javaName="aClass" primaryKey="true" 
required="true" size="2" type="CHAR"/>
        <column name="id" primaryKey="true" required="true" size="30" 
type="VARCHAR"/>
        <column name="position" primaryKey="true" required="true" 
type="INTEGER"/>
        <column name="name1" size="50" type="VARCHAR"/>
        <column name="name2" size="50" type="VARCHAR"/>
        <column name="name3" size="50" type="VARCHAR"/>
        <column name="street" size="50" type="VARCHAR"/>
        <column name="zipcode" size="25" type="VARCHAR"/>
        <column name="city" size="60" type="VARCHAR"/>
        <column name="phone" size="40" type="VARCHAR"/>
        <column name="phone2" size="40" type="VARCHAR"/>
        <column name="country" size="200" type="VARCHAR"/>
        <column name="state" size="200" type="VARCHAR"/>
        <column name="fax" size="40" type="VARCHAR"/>
        <column name="email" size="150" type="VARCHAR"/>
    </table>

Generated constants in the BaseAddressPeer (incorrect):

    static
    {
          CLASS = "address.CLASS";
          ID = "address.ID";
          POSITION = "address.POSITION";
          NAME1 = "address.NAME1";
          NAME2 = "address.NAME2";
          NAME3 = "address.NAME3";
          STREET = "address.STREET";
          ZIPCODE = "address.ZIPCODE";
          CITY = "address.CITY";
          PHONE = "address.PHONE";
          PHONE2 = "address.PHONE2";
          COUNTRY = "address.COUNTRY";
          STATE = "address.STATE";
          FAX = "address.FAX";
          EMAIL = "address.EMAIL";
    ....


I think the uppercase column names or uppercase because it's better to read 
(?). There is no bug in the Sybase JDBC driver (5.5 and 6.0). I've tested a 
generated SQL statement on the sybase console (isql) and it fails if the case 
is not correct, for example:

SELECT .... FROM address WHERE address.CITY="Hamburg"

failes, but with address.city="..." everything is okay. I think this case 
sensitive behaviour is a Sybase-"feature"... Maybe I should ask someone on a 
Sybase JDBC mailinglist howto disable this behaviour.

Bye
Thoralf


> -----Ursprüngliche Nachricht-----
> Von: Thomas Fischer [mailto:[EMAIL PROTECTED] 
> Gesendet: Samstag, 15. Juli 2006 09:10
> An: Apache Torque Users List
> Betreff: Re: Sybase case insensitive column names
> 
> 
> Hi,
> 
> This is strange; the jdbc task should preserve the case of 
> the table and 
> column names (I checked that using mysql; as I do not have a sybase 
> database). The jdbc task uses the DatabaseMetaData from the 
> jdbc driver to 
> get the database; if the database is case sensitive and the 
> DatabaseMetaData does not preserve case it is a bug of the 
> jdbc driver.
> 
>      Thomas
> 
> On Thu, 13 Jul 2006, Thoralf Rickert wrote:
> 
> > Hi!
> >
> > I've created a schema.xml for an existing Sybase database and I was 
> > able to generate the corresponding java classes. If I try to make a 
> > query with them I run into a problem. The database uses 
> case sensitive 
> > column names but torque generates uppercase column names. 
> For example 
> > the following query throws an exception, because the column "STATE" 
> > cannot be found (in the database it's called "state").
> >
> >  SELECT states.STATE FROM states ORDER BY states.STATE ASC
> >
> > Is there a way to handle this? Is there a sybase specific 
> connection 
> > setting or something like that?
> >
> > Thanks
> > Thoralf
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to