I have a Date type column in one of our tables and when I query the database I get the date from the resultset like:
final String createdDate = resultSet.getString("received_date");
If I run this on OC4J container on Java 5 I get
2014-12-26 05:57:31.0
while on Tomcat with Java 8 I get
2014-12-26 05:57:31
The JDBC driver are of different versions - do you think I should blame the driver for this? Is it a good direction regarding the investigation? Or is it more about Java version difference?
Thanks
Related
JPA & Hibernate application uses HSQLDB for JUnit tests.
HSQLDB 1.8.0
Hibernate 3.2.4.sp1
Java 7
While the tests worked fine against an Oracle database, getting the following error now that we are using MSSQL 2016:
Unexpected token: GETDATE in statement [select ..... effective_date < GETDATE() AND ... ]
So I understand that HSQL uses SYSDATE, CURDATE, or NOW instead of the MSSQL GETDATE function, and I've done the following:
Attempted to set sql.syntax_mss to true by URL and SQL statement:
public static final String HYPERSONIC_JDBC_URL = "jdbc:hsqldb:mem:aname;sql.syntax_mss=true";
entityManager.createNativeQuery("set database sql syntax MSS true").executeUpdate();
Register the function in the Dialect and/or create a function:
registerFunction("GETDATE", new NoArgSQLFunction("SYSDATE", new DateType()));
entityManager.createNativeQuery("CREATE FUNCTION GETDATE() RETURNS DATE RETURN CURDATE()").executeUpdate();
None of this seems to have any effect.
Live application is connected to MS SQL Server 2016 via mssql-jdbc-6.2.1.jre7 driver.
So while upgrading the libraries as #fredt mentioned in the comments is probably the best route, upgrading hsqldb.jar breaks dbunit.jar, upgrading that breaks.. etc.
Was able to remove the GETDATE occurrences and fix the sequence generation strings (select next value for seq_name from seq_name is the format it likes) and now we are back to a working state.
Upgrading these libraries can be put in the bucket with upgrading jBoss, Hiberate, jBPM and Quartz :)
JVM Timezone details : India Standard TimeAsia/Calcutta019800000
DB Timezone details : Central Standard TimeAmerica/Chicago3600000-21600000
Sample Code:
String sql = "select systimestamp as base from dual";
....
PreparedStatement stmt = con.prepareStatement(sql);
ResultSet rs = stmt.executeQuery();
while(rs.next()) {
System.out.println(rs.getTimestamp("base"));
System.out.println(rs.getString("base"));
}
Test-1:
I tested using ojdbc14.jar 10.1.0.3.0 with, it works as expected printing the db time
Output:
2013-12-05 01:23:57.141583
2013-12-5 1.23.57.141583000 -6:0
Test-2:
I tested using ojdbc5.jar & ojdbc6.jar 11.2.0.3.0 with, getTimestamp print local time where as getString prints db time.
Output:
2013-12-05 12:57:54.3508
2013-12-05 01:27:54.3508 -6:00
Please suggest what is wrong with Test-2 ojdbc driver version 11.2.0.3.0 where the getTimestamp() prints local time. My application expect the db time like Test-1 in the getTimestamp() where it matches with DB timestamp.
We had the same issue a few days ago at my company. The bottom line of this is you should never get a timestamp as a string (as it's database/driver specific) and always get the TimeStamp object and format it any way you want using a SimpleDateFormat.
And it's always worth mentioning that the Timestamp class is an abomination , from the javadocs
Due to the differences between the Timestamp class and the
java.util.Date class mentioned above, it is recommended that code not
view Timestamp values generically as an instance of java.util.Date.
The inheritance relationship between Timestamp and java.util.Date
really denotes implementation inheritance, and not type inheritance.
We are using ojdbc14_10.1.0.2.jar with a Java/J2EE application (that use directly JDBC) and JDK5, but when we tried to migrate into ojdbc5-11.2.0.3.jar we encountered an issue related to some sql request (jdbc) that doesn't work anymore.
The pseudo SQL request is :
select *
from quotas q
where q.datdeb<='2013-09-05' and q.datfin>='2013-09-05'
and q.datdeb is not null and q.datfin is not null order by ....;
The NLS parameters for date is :
DD/MM/RR
Which is not compatible with the date format giving as parameter in the request.
Everything worked fine when we were using ojdbc14; apparently it does an implicite conversion for the date.
For information, The oracle Database is 11g Release 11.2.0.3.0 - 64bit
Best regards.
I believe you just need to use the to_date function with an appropriate date mask to get around the problem.
select *
from quotas q
where q.datdeb<=to_date('2013-09-05','yyyy-mm-dd') and q.datfin>=to_date('2013-09-05', 'yyyy-mm-dd')
and q.datdeb is not null and q.datfin is not null order by ....;
I'm trying to call an Oracle stored procedure in a Java EE web application (java) using Spring 'CallableStatementCreator'. One of the inputs for the stored procedure is a DATE.
My attributeValue is a java.util.date and it correctly holds both DD-MM-YYYY and HH:MM:SS.
When using the following code:
callableStmt.setTime(6, new java.sql.Time(attributeValue.getTime()));
The result is the column in the DB (the stored procedure ultimately writes in the DB) is set to 1970-01-01 and the correct HH:MM:SS I pass as input. This worked in a previous version of my application (where I used JDBC lib 10.x.x.x)
If I use
callableStmt.setDate(6, new java.sql.Date(attributeValue.getTime()));
The DD-MM-YYYY is set correctly but the hour is set to 00:00:00.
So, what's the correct way to call and pass the attribute to this stored procedure? Also, any debug tips?
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
Oracle JDBD lib: ojdbc6-11.2.0.3
Try using a Timestamp:
callableStmt.setTimestamp(6, new java.sql.Timestamp(attributeValue.getTime()));
Using
callableStmt.setTimestamp(6, new java.sql.Timestamp(attributeValue.getTime()));
Didn't work in my case where I have a stored procedure overloaded where the only difference between my 3 functions is this last parameter: VARCHAR2, DATE or NUMBER. When using this code, the execution of my stored procedure fails because Oracle can't find out which method to use. (probably because JDBC lib doesn't map the timestamp to DATE column, as explained here )
The only way it worked was with:
callableStmt.setObject(6, new java.sql.Timestamp(attributeValue.getTime()), OracleTypes.DATE);
which seems to force the mapping between my Timestamp to DATE column in Oracle stored procedure while keeping the DD-MM-YYYY and HH:MM:SS.
I'm trying to list the dates registered in a table with SQL Server, but my problem is all the dates I'm extracting differs of 2 days with the dates in the table.
For example, I got 2012-12-25 in my database and when I retrieve it and cast it to a Java.util.Date, it becames 2012-12-23...
I've got processes on dates in another table which are working fine.
I'm using SQL Server 2008, Hibernate 3 and Spring 3.
Edit:
The column data type for the table is date, I'm retrieving it using hibernate so here is my hibernate query call:
public List<Holiday> retrieveAllHolidays() {
return (List<Holiday>) sessionFactory.getCurrentSession().createQuery("from Holiday")
.list();
}
The holiday object got two attributes: a String and a Date (this one is incorrect after retrieving from database).
The problem was linked with the JRE 7 support of the JDBC Driver (a problem with the getDate() function).
See this post for more informations: Microsoft JDBC driver team blog
Thanks again Martin smith for pointing to that other issue!