Thanks O,

The same code works like a charm when I revert back to 7.4x JDBC driver with PGSql 8.x. Could it be the way the 8.x drivers are implemented?

Thanks,

-----Original Message-----
From: Oliver Jowett [mailtoliver@opencloud.com]
Sent: Tuesday, June 07, 2005 5:42 PM
To: Vishnubhotla, Sunil
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] 8.x driver with EJB CMP

Sunil.Vishnubhotla@gwinnettcounty.com wrote:

> I am using JBoss 4.x with PosrgreSQL 8.x JDBC
> postgresql-8.0-311.jdbc3.jar. I have a CMP EJB that has a setter:
>
> void setCreationDate(java.sql.Date creationDate);
>
> When I use the setter in my ejbCreate() call:
>
> setCreationDate( new java.sql.Date( new java.util.Date().getTime() ) );
>
> it throws an SQLException : Could not create
> entity:java.sql.SQLException: ERROR: column "creation_date" is of type
> date but expression is of type character varying.
>
> What am i doing wrong ??

I guess that the JBoss CMP layer is using setString() instead of
setDate() (or setObject(..., Types.VARCHAR) not setObject(...,
Types.DATE)) to set the parameter in question. I'm not familiar with the
JBoss CMP layer, but can you configure it to use setDate() / Types.DATE?
Alternatively, change your schema to have creation_date as a text type.

-O

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Sunil.Vishnubhotla@gwinnettcounty.com wrote:

> The same code works like a charm when I revert back to 7.4x JDBC driver with PGSql 8.x. Could it be the way the 8.x drivers are implemented?

Yes, the 8.x drivers changed to make full use of the V3 protocol, which
involves pushing parameter substitution to the backend. Previous drivers
did textual substitution into the query, which had slightly different
behaviour but limited what could be done in the way of streaming large
parameter values and preserving query plans between executions.

-O

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match