Subject One more Timestamp bug? Was RE: Bug in org.firebirdsql.jdbc.FBPreparedStatement ?
Author Agustin Gonzalez
David,

I am having further problems with the Timestamp firebird data type. I have
a JDBC statement that sets a firebird Timestamp field to the
java.sqlTimestamp value of 1988-04-09 16:30:00.0". The JDBC prepared
statement sets the parameter ok (I stepped thorugh the code), however,
after the execute update, the value that end up in the database has the
right date but the WRONG time! (the value that ends up in the db is:
"1988-04-09 00:01:12.0" ).

I stepped through the code and everything is ok (i.e. the
java.sql.Timestamp in the xsqlda contains "1988-04-09 16:30:00.0") .
Everything seems cool until the routine:
private void writeBLR(isc_db_handle_impl db,
XSQLDA xsqlda) throws GDSException {
in class: org.firebirdsql.gds.GDS_Impl;
Here, it correctly enters this statement:
} else if (dtype == SQL_TIMESTAMP) {
blr[n++] = 35; // blr_timestamp
But here my efforts ends since I have no way to know wnymore what that 35
"magic number means".

Thus the java.sql.Timestamp in the xsqlda that contains "1988-04-09
16:30:00.0" ends up in the database (in a firebird Timestamp field) with a
value: "1988-04-09 00:01:12.0" !!!!

At this point, I'd likt to know who is the author of this code so I can
chat with that person about this bug?

Thanks!
Agustin


-----Original Message-----
From: Agustin Gonzalez [SMTP:aggonzalez@...]
Sent: Tuesday, January 22, 2002 9:57 AM
To: 'IB-Java@yahoogroups.com'
Cc: 'David Jencks'
Subject: Bug in org.firebirdsql.jdbc.FBPreparedStatement ?

David,
There are a series of statements in FBPrepared statement dealing with dates
that may have a bug. They start at line 807 (see code excerpt below). The
problem is that it seems that once the code enters one of the relevant case
statements (shown below) the code invariably will throw an exception. The
bug seems a cut and paste typo and it seems that an "else is missing". The
way to fix it is to add the missing "else" clauses as shown below:

if (x instanceof java.sql.Date) {
setDate(parameterIndex, (java.sql.Date) x);
} else if (x instanceof java.sql.Timestamp) {
setDate(parameterIndex, new
java.sql.Date(((java.sql.Timestamp) x).getTime()));
} else if (x instanceof String) { // *****NOTE "else" added
here!
setDate(parameterIndex, java.sql.Date.valueOf((String) x));
} else {
throw new SQLException("Invalid conversion to date");
}

In my case, this bug prevented me from using Date types (I am using Castor
as the persistence layer in my project and I am planning to use JBoss too).
I could continue after I fixed the code as suggested.

Thanks,
---
Agustin Gonzalez, Principal
Town Lake Software
www.townlakesoftware.com
(512) 248-9839

P.S. Relevant code:
case GDS.SQL_TYPE_DATE:
if (x instanceof java.sql.Date) {
setDate(parameterIndex, (java.sql.Date) x);
} else if (x instanceof java.sql.Timestamp) {
setDate(parameterIndex, new
java.sql.Date(((java.sql.Timestamp) x).getTime()));
} if (x instanceof String) {
setDate(parameterIndex, java.sql.Date.valueOf((String) x));
} else {
throw new SQLException("Invalid conversion to date");
}
break;
case GDS.SQL_TYPE_TIME:
if (x instanceof java.sql.Time) {
setTime(parameterIndex, (java.sql.Time) x);
} else if (x instanceof java.sql.Timestamp) {
setTime(parameterIndex, new
java.sql.Time(((java.sql.Timestamp) x).getTime()));
} if (x instanceof String) {
setTime(parameterIndex, java.sql.Time.valueOf((String) x));
} else {
throw new SQLException("Invalid conversion to time");
}
break;
case GDS.SQL_TIMESTAMP:
if (x instanceof java.sql.Timestamp) {
setTimestamp(parameterIndex, (java.sql.Timestamp) x);
} else if (x instanceof java.sql.Date) {
setTimestamp(parameterIndex, new
java.sql.Timestamp(((java.sql.Date) x).getTime()));
} if (x instanceof String) {
setTimestamp(parameterIndex,
java.sql.Timestamp.valueOf((String) x));
} else {
throw new SQLException("Invalid conversion to timestamp");
}
break;