I'm facing an issue with an update statement that worked earlier in Oracle 9i but now it does not update any rows in Oracle 11G. Here is the statement that i'm using.
update account
set
days_to_validate = validated_date - val_requested_Date
where
validated_date >= val_requested_date
The validated_date and val_requested_date are both date fields in the format: dd-mmm-yyyy (18-Mar-2015). This was working earlier in Oracle 9i before we did an upgrade.
Pls advice on how we can fix this.
Thanks
Prashanth
I was able to fix this. I tried including the "to_date" function and it worked in Oracle 11G. Here is the change i made to the query.
update account
set days_to_validate = to_date(validated_date) - to_date(val_requested_Date)
where to_Date(validated_date) >= to_date(val_requested_date)
Related
hi guys a need your help, I'm migrating some stored procedures from sybase to oracle, and I don't know how to transform this line to oracle.
select #date_vig_aux = dateadd(ss,-1,#date_vig_aux)
I would appreciate if you help me.
Supposing date_vig_aux is defined as DATE or TIMESTAMP in pl/sql, this should translate into
date_vig_aux:=date_vig_aux+numtodsinterval(-1,'second');
We have recently uplifted a major application that was written under JDK6 using ojdbc6 against an 11g Oracle database. It was uplifted to use JDK8 against the same 11g database, but we were also in the midst of upgrading to 12c. The uplifted code has been running in production against the 11g database, but slower than it was before. Against the 12c database in our QA environment, we're noticing jobs either throwing exceptions or running VERY slow. When I looked at the code, I noticed that the project team assigned to uplift the code failed to upgrade the ojdbc from 6 to at least 8. I have since done that work, but now we are getting errors from submitting the following code:
Calendar endModDate = Calendar.getInstance();
// get the timestamp from the db
Query qry = em.createNativeQuery("select SYSTIMESTAMP from dual");
TIMESTAMPTZWrapper tsTZWrapper = (TIMESTAMPTZWrapper)qry.getSingleResult();
The em is our entity manager. But when the code calls the qry.getSingleResult() member function, we get this error:
oracle.sql.TIMESTAMPTZ cannot be cast to org.eclipse.persistence.internal.platform.database.oracle.TIMESTAMPTZWrapper
I've searched high and low for an answer, and anything that resembles an answer doesn't appear to fix my solution. This same logic is used in one other area of the code and produces the same issue. If we switch back to ojdbc6, it then works but we can't use ojdbc6 (and we really shouldn't since we're on jdk8) since we need to upgrade to Oracle 12c in the coming month.
Thanks for any assistance in this matter.
Just quick comment about TIMESTAMP datatype:
There is a bug in JDBC drivers "Bug 21891493 : JDBC SENDS TIMESTAMP SCALE OF NULL WHEN NANOSECONDS ARE ZERO", which can cause creation of excessive number child cursors in Oracle database. This bug was fixed in 12.2 JDBC drivers.
The datatype TIMESTAMP WITH TIMEZONE uses internally a function to convert the this into GMT. When you create an index on it, in some cases this function based index is not used, especially when you compare this column with TIMESTAMP value of different subtype. You should compare exec plans between 11g and 12c.
My organization recently upgraded form Oracle 10g to 11g. I had the following query that was working, but it no longer works because the V_$SESSION.SQL_ID field is not populated to link to.
SELECT SESS.OSUSER
,SESS.MACHINE
INTO v_USERID
,v_USERNAME
FROM SYS.V_$SQLAREA SEQL
JOIN SYS.V_$SESSION SESS ON SEQL.SQL_ID = SESS.SQL_ID
WHERE SEQL.SQL_TEXT LIKE 'DELETE%'
AND SEQL.SQL_TEXT LIKE '%ACCTLOG%';
Is there a work around I could use to obtain the same information?
Thanks all
I'm using Oracle 10g (XE 10.2.0.1.0), and find a behavior that I don't understand:
select *
from employees manager
join employees worker on MANAGER.EMPLOYEE_ID = WORKER.MANAGER_ID
join departments on DEPARTMENTS.manager_id = 108
where
department_id = 100
;
The problem is I think Oracle should have complain about the ambiguity of department_id in the where clause, since it's a column in both the table employees and departments. The fact is in Oracle 10g, it doesn't, and the result shows that it interprets the department_id as the one in departments. However, if I comment out the second join statement (4th line above), Oracle does complain “ORA-00918: column ambiguously defined” as expected.
So, can somebody help to explain how the ambiguity is defined in Oracle 10g? Or perhaps this is a bug in 10g?
BTW: The tables are defined in the default HR schema bundled in the Oracle 10g.
Update: Just found a related post:
Why does Oracle SQL mysteriously resolve ambiguity in one joins and does not in others
I believe it is a bug in Oracle 10g that Oracle chose not to fix. When we were upgrading our applications from 10g to 11gR2, we found a couple of queries that were written "loosely" in respect of ambiguous column names but worked in Oracle 10g. They all stopped working in 11gR2. We contacted Oracle but they pretty much said that the tolerant behavior toward ambiguous column names is a correct behavior for Oracle 10g and the stringent behavior is the correct behavior for 11g.
I think it is, because departments have no alias. Therefore everything without being qualified by an <alias>. is first treated to be from departments.
So I also think when you give departments an alias you should get the ORA-00918 again. Cannot test here though...
I believe that oracle.jdbc.V8Compatible has been deprecated in Oracle 11
Is this because for a DATE column Oracle is now doing what it did before 8i e.g. return an instance of java.sql.Timestamp for a DATE column?
Their FAQ covers it:
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-faq-090281.html#08_00
Oracle JDBC 11.1 fixes this problem. Beginning with this release the driver maps SQL DATE columns to java.sql.Timestamp by default. There is no need to set V8Compatible to get the correct mapping. V8Compatible is strongly deprecated. You should not use it at all. If you do set it to true it won't hurt anything, but you should stop using it.
As mentioned above, the 11.1 drivers by default convert SQL DATE to Timestamp when reading from the database. This always was the right thing to do and the change in 9i was a mistake. The 11.1 drivers have reverted to the correct behavior.