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 ....;
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 :)
I got a problem with JPA StoredProcedureQuery, the problem consist I'm getting different values unexpected. In MySQL workbench I execute the stored procedure called sp_GET_Result that it is waiting two parameters called startDate and endDate.
For instance:
And the results are like:
So far it's ok, but the problem is when I call it from Java JPA.
This is my java routine
I'm getting this results:
[2017-01-31, 2017-02-01, 2017-02-02, 2017-02-03, 2017-02-04, 2017-02-05, 2017-02-06, 2017-02-07, 2017-02-08, 2017-02-09, 2017-02-10, 2017-02-11, 2017-02-12, 2017-02-13, 2017-02-14, 2017-02-15, 2017-02-16, 2017-02-17, 2017-02-18, 2017-02-19, 2017-02-20, 2017-02-21, 2017-02-22, 2017-02-23, 2017-02-24, 2017-02-25, 2017-02-26, 2017-02-27]
I think the problem not is with the store procedure if not with the parameters that java is sending.
Because I did a try out printing the parameters that Java is sending and MySQL is receiving and the results are like:
starDate , endDate
[2017-01-31, 2017-02-27] but Why?? because I'm sending from 2017-02-01 to 2017-02-28.
The problem not is the store procedure, the really problem is the variation in the results.
Most probably your JDBC driver converts your input dates into the UTC format, which is used by database. Or via versa, your response dates are converted into your local timezone. Check the JDBC driver setting: https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-configuration-properties.html.
I have a PreparedStatement intended to be run both on ORACLE and on MYSQL.
But I cannot figure out how to handle the CAST(NULL AS ...)
On Oracle the following works (but not on Mysql):
SELECT TIMB_INS,
CAST(NULL AS TIMESTAMP) AS TIMB_CLO
FROM TOPS
On Mysql the following works (but not on Oracle):
SELECT TIMB_INS,
CAST(NULL AS DATETIME) AS TIMB_CLO
FROM TOPS
(Please note that the first column selected, "TIMB_INS", returns the correct data type for target database type in both cases, i.e. TIMESTAMP for Oracle and DATETIME for MySql.)
There is a way to put it so that it works for both?
I.E. Can i make it db-indipendent in some way?
Thanks
Marco
Based on the tags I can see you're calling this statement from some java code. There are several ways doing so:
Use the DAO pattern. I.e. for each SQL flavor provide a java file that contains the SQL-s.
Use an ORM like Hibernate or JPA. That will take care of this kind of differences.
As a quick hack, you can edit the SQL manually, like in the snippet below. But then you have to determine somehow if the underlying database is Oracle or MySQL
String SQL_PATTERN = "... CAST(NULL AS %s) AS TIMB_CLO ...";
String SQL = String.format(SQL_PATTERN, isOracle ? "TIMESTAMP" : "DATETIME");
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
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.