Bug in either ANSI Join or Oracle 10.2

I can't tell whose bug this is, but it's almost certainly a bug.
My co-worker Martin wrote a query (below) that returned zero rows, which he knew was wrong.
In exploring this further, he discovered that rewriting the join from ANSI 92 to the old WHERE clause join suddenly caused a "ORA-00918: column ambiguously defined" error to arise.
Then, when he added a table qualifier to one of the column names (effective_dt became fam.effective_dt), suddenly he began to get his data.
So, here's my question. Why does a query that uses ANSI-92 Join syntax not raise the "ORA-00918: column ambiguously defined" error, WHEN THERE WAS AN AMBIGUOUSLY DEFINED COLUMN? Does the ANSI-92 join syntax imply some sort of hierarchy of table precedence that resolves the ambiguity by implication?
Here's the query, FYI:
SELECT fam.asset_mix_percent_nbr
FROM rp_mip_rpd_fund_asset_mix fam
JOIN rp_mip_rpd_fund mrf ON fam.rp_mip_rpd_fund_seq =
mrf.rp_mip_rpd_fund_seq
JOIN rp_rpd_fund rpd ON mrf.rp_rpd_fund_seq = rpd.rp_rpd_fund_seq
JOIN rp_psrpd_fund psrpd ON rpd.rp_rpd_fund_seq = psrpd.rp_rpd_fund_seq
JOIN rp_cpsrpd_fund cpsrpd ON psrpd.rp_psrpd_fund_seq =
cpsrpd.rp_psrpd_fund_seq
WHERE rpd.fast_fund_id = LPAD('96', 3, '0')
AND cpsrpd.cntrct_nbr_id = '800710'
AND fam.effective_dt =
-- AND effective_dt = -- this version returns no rows
(SELECT MAX(fam1.effective_dt)
FROM rp_mip_rpd_fund_asset_mix fam1
WHERE fam1.effective_dt <= '03-Oct-07'
AND fam1.rp_mip_rpd_fund_seq = mrf.rp_mip_rpd_fund_seq);

We're at 10.2.0.2.0 on a Sun box:
SunOS saturn1 5.9 Generic_122300-13 sun4u sparc SUNW,Sun-Fire-15000
The explain plans are identical. Here's one:
SQL Statement from editor:
SELECT fam.asset_mix_percent_nbr
FROM rp_mip_rpd_fund_asset_mix fam
JOIN rp_mip_rpd_fund mrf ON fam.rp_mip_rpd_fund_seq =
mrf.rp_mip_rpd_fund_seq
JOIN rp_rpd_fund rpd ON mrf.rp_rpd_fund_seq = rpd.rp_rpd_fund_seq
JOIN rp_psrpd_fund psrpd ON rpd.rp_rpd_fund_seq = psrpd.rp_rpd_fund_seq
JOIN rp_cpsrpd_fund cpsrpd ON psrpd.rp_psrpd_fund_seq =
cpsrpd.rp_psrpd_fund_seq
WHERE rpd.fast_fund_id = LPAD('96', 3, '0')
AND cpsrpd.cntrct_nbr_id = '800710'
AND effective_dt = -- this version returns no rows
(SELECT MAX(fam1.effective_dt)
FROM rp_mip_rpd_fund_asset_mix fam1
WHERE fam1.effective_dt <= '03-Oct-07'
AND fam1.rp_mip_rpd_fund_seq = mrf.rp_mip_rpd_fund_seq);
Statement Id=CB0A0233   Type=SELECT STATEMENT
    Cost=44 TimeStamp=10-DEC-07::06:46:32
       (1) SELECT STATEMENT CHOOSE no rows returned
     Est. Rows: 1 Cost: 20
    FILTER
           (13) TABLE TABLE ACCESS BY INDEX ROWID RP.RP_MIP_RPD_FUND_ASSET_MIX [Analyzed]
           (13)   Blocks: 5 Est. Rows: 1 of 275 Cost: 1
                Tablespace: RP
               (12) NESTED LOOPS
                    Est. Rows: 1 Cost: 18
                   (10) NESTED LOOPS
                        Est. Rows: 1 Cost: 17
                       (7) HASH JOIN
                            Est. Rows: 1 Cost: 16
                           (5) HASH JOIN
                                Est. Rows: 20 Cost: 12
                               (3) TABLE TABLE ACCESS BY INDEX ROWID RP.RP_CPSRPD_FUND [Analyzed]
                               (3)   Blocks: 1,152 Est. Rows: 20 of 75,726 Cost: 6
                                    Tablespace: RP
                                   (2) INDEX INDEX RANGE SCAN RP.RP_CPSRPD_FUND_F5 [Analyzed]
                                        Est. Rows: 20 Cost: 1
                               (4) TABLE TABLE ACCESS FULL RP.RP_PSRPD_FUND [Analyzed]
                               (4)   Blocks: 34 Est. Rows: 3,145 of 3,145 Cost: 5
                                    Tablespace: RP
                           (6) TABLE TABLE ACCESS FULL RP.RP_RPD_FUND [Analyzed]
                           (6)   Blocks: 13 Est. Rows: 3 of 276 Cost: 3
                                Tablespace: RP
                       (9) TABLE TABLE ACCESS BY INDEX ROWID RP.RP_MIP_RPD_FUND [Analyzed]
                       (9)   Blocks: 5 Est. Rows: 1 of 275 Cost: 1
                            Tablespace: RP
                           (8) INDEX INDEX RANGE SCAN RP.RP_MIP_RPD_FUND_FK2 [Analyzed]
                                Est. Rows: 1
                   (11) INDEX INDEX RANGE SCAN RP.RP_MIP_RPD_FUND_ASSET_MIX_FK1 [Analyzed]
                        Est. Rows: 1
           (16) SORT AGGREGATE
                Est. Rows: 1
               (15) TABLE TABLE ACCESS BY INDEX ROWID RP.RP_MIP_RPD_FUND_ASSET_MIX [Analyzed]
               (15)   Blocks: 5 Est. Rows: 1 of 275 Cost: 2
                    Tablespace: RP
                   (14) INDEX INDEX RANGE SCAN RP.RP_MIP_RPD_FUND_ASSET_MIX_FK1 [Analyzed]
                        Est. Rows: 1 Cost: 1

Similar Messages

Use ansi join syntax

From what i have been reading is better to use the new syntax(dont know how new it is)

The ANSI join syntax was new to Oracle in Oracle 8i in 1998 - that's 15 years old.
It can produce more readable code, and is both more readable and less human-error prone for outer joins.
The ANSI format lets you outer join between multiple tables in a way the old oracle-specific ( + ) syntax did not and introduces FULL OUTER JOIN which you should use very rarely.
You should not use NATURAL JOIN in code - adding unrelated columns to the tables involved can make it give very different results.
There have not been significant bugs for ANSI joins in Oracle since Oracle 10.2 was introduced about 8 years ago.
As Paul said, the ON part should be the join criteria between the tables. The were clause should be the filtering of the joined tables.
So assuming start_date, end_date and in_property_id are variables
SELECT resv_num, unit_date
    FROM p_resv_unit ru
    INNER JOIN p_pm_unit_night pun
    ON pun.resv_unit_id = ru.resv_unit_id
    WHERE pun.property_id = in_property_id
    AND pun.unit_date BETWEEN start_date AND end_date
    AND pun.pm_unit_num = cvUnitNum;
If start_date and end_date were columns in p_resv_unit the query would be:
SELECT resv_num, unit_date
    FROM p_resv_unit ru
    INNER JOIN p_pm_unit_night pun
    ON pun.resv_unit_id = ru.resv_unit_id AND pun.unit_date BETWEEN ru.start_date AND ru.end_date
    WHERE pun.property_id = in_property_id
        AND pun.pm_unit_num = cvUnitNum;
Inner join queries work with criteria in the wrong place, but they're harder to read. Outer joins don't work unless you put the criteria in the right place.

Difference between oracle join syntaxes and ANSI join syntaxes

What is difference between oracle join syntaxes and ANSI join syntaxes ?
why oracle is having different syntaxes for joins than ANSI syntaxes ?
Also Join syntaxes are different in some oracle vesrions ?

BluShadow wrote:
3360 wrote:
Yes it is. The Oracle database wasn't initially designed to be ANSI compliant. As you correctly state the ANSI standards weren't around when it was initially designed, so the statement is perfectly correct. ;)Ok, in one sense it may be correct but it is a completely misleading statement. Not sure why you think it's misleading.Because there was no ANSI standard, so making it sound like a design choice The Oracle database wasn't initially designed to be ANSI compliant. would suggest to most readers that there was a standard to be compliant to.
Like saying Ford originally did not design their cars to incorporate safety features such as ABS, seat belts and air bags.
The OP asked "why oracle is having different syntaxes for joins than ANSI syntaxes ?" and the answer is that Oracle wasn't initially designed with ANSI compliance, so it has it's old non-ANSI syntax,As shown above, the old syntax was ANSI compliant at the time and to call it non-ANSI is either incorrect or misleading dependent on your point of view.
and since ANSI syntax became the standard it now supports that. And since ANSI switched to a new standard, Oracle had to implement the new standard as well as the previous ANSI standard would be more accurate in my opinion.
Nothing misleading as far as I'm aware in that.I find the whole discussion about ANSI and Oracle's supposed non-compliance, reads like it was Oracle's choice to deviate from the standards, when it was ANSI's bullheaded decisions to pointlessly change standards that left Oracle and other vendors out of compliance, and that was a decision made solely by ANSI.
This is probably the reason ANSI no longer produces SQL standards, the endless syntax fiddling would eventually have made forward left under outer joins a reality.
{message:id=1785128}

Oracle 9i ansi joins

Hi
We are using oracle 9i database ,i want to use asni full outer join for below query .PLease any one how to use ?
SELECT COLL_SUB_NMBR AS COLL_NO, CLCOLTP, SSUCYL AS CTRY_CD
FROM TGDW_SGSSUTTRNP, TGDW_PAR_COLL
WHERE TGDW_PAR_COLL.COLL_SUB_NMBR = TGDW_SGSSUTTRNP.COLLNO
AND TGDW_PAR_COLL.COLL_TYPE = TGDW_SGSSUTTRNP.CLCOLTP
AND TGDW_PAR_COLL.COLL_TYPE IN ( 1,21)
UNION ALL
SELECT COLL_SUB_NMBR AS COLL_NO, CLCOLTP, FDGCYBNK AS CTRY_CD
FROM TGDW_SGFDGTRNP, TGDW_PAR_COLL
WHERE TGDW_PAR_COLL.COLL_SUB_NMBR = TGDW_SGFDGTRNP.COLLNO
AND TGDW_PAR_COLL.COLL_TYPE = TGDW_SGFDGTRNP.CLCOLTP
AND TGDW_PAR_COLL.COLL_TYPE = 2
Regards
MM

select COLL_SUB_NMBR, CLCOLTP, a.SSUCYL, b.FDGCYBNK from
( TGDW_SGSSUTTRNP join TGDW_PAR_COLL on
(TGDW_PAR_COLL.COLL_SUB_NMBR = TGDW_SGSSUTTRNP.COLLNO TGDW_PAR_COLL.COLL_TYPE = TGDW_SGSSUTTRNP.CLCOLTP
AND TGDW_PAR_COLL.COLL_TYPE IN ( 1,21)) a
full outer join
( TGDW_SGFDGTRNP join TGDW_PAR_COLL on
(TGDW_PAR_COLL.COLL_SUB_NMBR = TGDW_SGFDGTRNP.COLLNO AND TGDW_PAR_COLL.COLL_TYPE = TGDW_SGFDGTRNP.CLCOLTP AND TGDW_PAR_COLL.COLL_TYPE = 2)) b
using (COLL_SUB_NMBR, CLCOLTP);This is not the same query, because the original query is not using outer join but it may help to figure out on how to use the ansi join syntax
Regards
Laurent Schneider
OCM DBA

Flow accept error when using ANSI join syntax

Hi
I had a region populated by a query joining two views (one in-line using connect by). When trying to create the region if the join was coded using ANSI syntax (INNER JOIN .... USING) I got a flow accept error when either trying to proceed using the wizard, or apply changes when editing the region.
After changing to the old style Oracle join (using predicates), I was able to create the region and everything worked ok. I found the solution after reading this post Error 404 wwv_flow.accept was not found in which the OP says he would raise a bug. Did the bug get raised? I ask since his problem arose whilst he was selecting from a view using ANSI joins and using instead of triggers, and I was joining an in-line view to a view using ANSI joins and instead of triggers, but neither view has been changed, just the join syntax. The view defined in the database is used in other regions and works fine. This could indicate the OP's problem was fixed, but one still exists.
Incidentally this is the only time I have used non-ANSI joins in the entire apex app - the rest work!. Unfortunately it is impossible for me to demo the app.
Richard
using ApEx 3.0.1.00.07 and 10g (10.2.0.1) EE on Wintel

Tyler,
Apologies, what I was trying to say was that I couldn't put the application on the Oracle APEX site.
Yes, I do have a work-around, but that does not mean a bug may still exist. I count myself fortunate I saw that post and, therefore, experimented with the syntax of the join - there is no reason APEX should not accept ANSI join conditions, in fact , it does. The ANSI-joined SQL statement executed perfectly in TOAD and SQL*Plus, but I could not even save it in APEX.
regards
Richard

Query Rewrite ISSUE (ANSI JOINS do not work, traditional join works ) 11gR2

For some types of queries constructed with ANSI JOINS, materialized views are not being used.
This is currently increasing time on various reports since we cannot control the way the queries are generated(Tableau Application generates and runs queries against the STAR Schema).
Have tried to debug this behavior using DBMS_MVIEW.EXPLAIN_REWRITE and mv_capabilities function without any success.
The database is configured for query rewrite: REWRITE INTEGRITY, QUERY REWRITE ENABLED and other settings are in place.
Have successfully reproduced the issue using SH Sample schema:
Q1 and Q2 are logically identical the only difference between them being the type of join used:
Q1: ANSI JOIN
Q2: Traditional join
Below is an example that can be validated on SH sample schema.
Any help on this will be highly appreciated.
-- Q1: the query is generated by an app and needs to be rewritten with materialized view
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;
-- Q2: the query with traditional join is rewritten with materialized view
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;Tested both queries with the following materialized views:
CREATE MATERIALIZED VIEW MVIEW_TEST_1
ENABLE QUERY REWRITE
AS
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;
CREATE MATERIALIZED VIEW MVIEW_TEST_2
ENABLE QUERY REWRITE
AS
SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust, countries cntr
WHERE cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth;Explain Plans showing that Q1 does not use materialized view and Q2 uses materialized view
SET AUTOTRACE TRACEONLY
--Q1 does not use MVIEW_TEST_1
SQL> SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust
INNER JOIN countries cntr
   ON cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth; 2    3    4    5
511 rows selected.
Execution Plan
Plan hash value: 1218164197
| Id | Operation           | Name       | Rows | Bytes |TempSpc| Cost (%CPU)| Time       |
|   0 | SELECT STATEMENT      |        |   425 | 12325 |       |   916   (1)| 00:00:11 |
|   1 | HASH GROUP BY           |        |   425 | 12325 |       |   916   (1)| 00:00:11 |
|   2 |   VIEW                | VM_NWVW_1 | 55500 | 1571K|       |   916   (1)| 00:00:11 |
|   3 |    HASH GROUP BY      |        | 55500 | 1842K| 2408K|   916   (1)| 00:00:11 |
|* 4 |     HASH JOIN           |        | 55500 | 1842K|       |   409   (1)| 00:00:05 |
|   5 |      TABLE ACCESS FULL| COUNTRIES |    23 |   414 |       |     3   (0)| 00:00:01 |
|   6 |      TABLE ACCESS FULL| CUSTOMERS | 55500 |   867K|       |   405   (1)| 00:00:05 |
--Q2 uses MVIEW_TEST_2
SQL> SELECT cntr.country_subregion, cust.cust_year_of_birth, COUNT(DISTINCT cust.cust_first_name)
FROM customers cust, countries cntr
WHERE cust.country_id = cntr.country_id
GROUP BY cntr.country_subregion, cust_year_of_birth; 2    3    4
511 rows selected.
Execution Plan
Plan hash value: 2126022771
| Id | Operation               | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT          |              |     511 | 21973 |       3   (0)| 00:00:01 |
|   1 | MAT_VIEW REWRITE ACCESS FULL| MVIEW_TEST_2 |     511 | 21973 |       3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------Database version 11gR1 (Tested also on 11gR2)
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE     11.2.0.1.0     Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

Thanks for the formatting tips.
Just found an Oracle Bug which explains the above behavior.
Unfortunately the bug will be fixed only in 12.1 Release so as a workaround will try to use traditional joins.
For those who have metalink access see [Bug 10145667 : ERRORS TRYING TO REWRITE QUERY WITH EXACT TEXT MATCH TO MVIEW]

Help need for ansi join

This is the sample piece of code in oracle which I am trying to convert it to ANSI join kindly help all the in_ and P_ and v_ are coming as a in parameter
select *
FROM    fxrates_v fx1
WHERE fx1.fx_close(+) = in_fx_close AND
           fx1.fxrate_currency (+) =   decode (v_agree_type, 'L', upper(v_pledge_leh_unsec_curr) ,
                                                 'C', upper(v_pledge_cp_unsec_curr),
                                                 decode(sign(v_pre_mrgn_val), -1, upper(v_pledge_leh_unsec_curr),
                                                 upper(v_pledge_cp_unsec_curr)))/

Michael I think your one is not equivalent to the OP's one.
Let's see an example on EMP:
SQL> select * from emp
2 where comm(+) = 300;
     EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM     DEPTNO
      7499 ALLEN      SALESMAN        7698 20-FEB-81       1600        300         30
SQL> select * from emp
2 where comm(+) = null;
no rows selected
SQL> select * from emp right outer join dual on comm = 300;
     EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM     DEPTNO D
      7499 ALLEN      SALESMAN        7698 20-FEB-81       1600        300         30 X
SQL> select * from emp right outer join dual on comm = null;
     EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM     DEPTNO D
                                                                                      XIf you add the right outer join on dual and the input parameter is null you extract an all nulls row.
But the original query doesn't behave this way, the .(+) symbols have no effect on the result either if the input parameter is not null and if it is null...
This is why I simply ignored them in my re-arrangement...
So I think you can't convert the original query in ANSI sql preserving the behaviour...
Am I missing something?
Max
http://oracleitalia.wordpress.com

What is Difference between ANSI SQL and ORACLE SQL

Hi,
I am going to take the assesment test for ANSI SQL Programming before that i want to know any difference between ANSI SQL and ORACLE SQL?
I am studying for SQL but the test will be ANSI SQL please let me give an idea about the both.
Thanks
Merina Roslin

Basically there is syntax difference between both of them.
Lets say i want to join two table EMP and DEPT based on DEPTNO.
With Oracle SQL format its like this.
select e.*
from emp e, dept d
where e.deptno = d.deptnoHere the joining condition goes in the WHERE clause.
With ANSI SQL format its like this.
select e.*
from emp e
join dept d
on e.deptno = d.deptnoHere the join condition is mentioned separately and not in WHERE clause.
Oracle supports ANSI SQL starting from 9i version.
You can read more about the syntax difference Here

Forms 10g and ANSI joins

Hello,
I had thought that Oracle Forms 10g was now fully in line with the 10g database in terms of the SQL and PL/SQL it supports. However, I notice that while I can use ANSI-syntax joins ('inner join', 'left outer join' etc) in record groups, I can't use them in trigger or procedure PL/SQL. For example, the following:
cursor dist_bacs_csr(c_pln_id plan.id%TYPE)
is
    select a.id as a_id
         , a.prcng_ccy_cd
         , a.sht_nam
         , a.dist_bac_key1
         , a.dist_bac_key2
    from   asset a
    inner join asset_hldg ash on (a.id = ash.a_id)
    inner join bank_acc bac on (a.dist_bac_key1 = bac.key1 and a.dist_bac_key2 = bac.key2)
    where ash.inc_acc_ind = 'I'
    and   ash.pln_id = c_pln_id
    order by ash.a_id;works fine in SQL Plus, but if I try to include it in my form, I get the error 'Encountered the symbol "INNER" when expecting one of the following: ,; for group having intersect minus order start union where connect'
Does anyone know if Oracle plan to support ANSI joins in future versions of Forms? Or is there something obvious I'm missing..?
Cheers,
James
Edited by: James Killeen on Aug 31, 2009 8:29 PM (The alias we normally use for the ASSET table apparently triggered the forum's filter against inappropriate language..! Replaced with a nice harmless 'a' instead...)

Thanks for that - I tried FULL INNER JOIN as well but still wouldn't compile. I'll probably stick with the old-style join format for now, as I don't want to make this a procedure just so I can use the new syntax. A shame, though, as I much prefer the ANSI syntax - would be curious to know if Oracle have any plans to support it in future versions of Forms. Does anyone know if it's supported in Forms 11?

Outer Joins in Oracle 9i

Post Author: wtfinc
CA Forum: Data Connectivity and SQL
After upgrading to Oracle 9i, the SQL queries generated by Crystal Reports XI contain a syntax errors when performing Outer Joins. The particular error returned by Oracle is "Old Style Outer Join can not be used with ANSI Joins". Does anyone know a work around short of changing the datbase connection to a command and rewriting the report?

Post Author: Jagan
CA Forum: Data Connectivity and SQL
If you choose SQL Query from Crystal's Database menu, does the SQL have a combination of old and new syntax?

Need clarification on ANSI Joins

Hi All,
I need some clarification on the ANSI Join which I build to avoid an error when I am trying to execute the same in regular join.
With Regular join I am getting the error ORA-01417: a table may be outer joined to at most one other table.
Regular Join Condition:
select null
FROM
land_event_device_fraud T1, --Update Dealer
land_event_device_upgrade T2, --New Subscriber First Set
syn_intg_event_device_state T3, --Existing Subscriber
land_event_device_upgrade T4 --New Subscriber Second Set
WHERE T1.event_id = T2.event_id(+) AND T1.rate_plan_id = T2.rate_plan_id(+)
AND T1.event_id = T3.event_id(+) AND T1.rate_plan_id = T3.rate_plan_id(+)
AND T4.event_id = T1.event_id(+) AND T4.event_id = T1.rate_plan_id(+)
AND T4.event_id = T3.event_id(+) AND T4.event_id = T3.rate_plan_id(+);
--Getting error ORA-01417.
Replaced the above join with ANSI Join
SELECT NULL
FROM land_event_device_fraud t1
LEFT OUTER JOIN land_event_device_upgrade t2
ON (t1.event_id = t2.event_id AND t1.rate_plan_id = t2.rate_plan_id)
LEFT OUTER JOIN syn_intg_event_device_state t3
ON (t1.event_id = t3.event_id AND t1.rate_plan_id = t3.rate_plan_id),
land_event_device_upgrade t4
LEFT OUTER JOIN land_event_device_fraud t5
ON (t4.event_id = t5.event_id AND t4.rate_plan_id = t5.rate_plan_id)
LEFT OUTER JOIN syn_intg_event_device_state t6
ON (t4.event_id = t6.event_id AND t4.rate_plan_id = t6.rate_plan_id);
I want to know whether the ANSI Join is goig to work fine or it is going to give me any cartesian production information.
Appreciate your help here.
Thanks,
MK.

Hi,
Maddy wrote:
Hi All,
I need some clarification on the ANSI Join which I build to avoid an error when I am trying to execute the same in regular join.
With Regular join I am getting the error ORA-01417: a table may be outer joined to at most one other table.
Regular Join Condition:
select null
FROM
land_event_device_fraud T1, --Update Dealer
land_event_device_upgrade T2, --New Subscriber First Set
syn_intg_event_device_state T3, --Existing Subscriber
land_event_device_upgrade T4 --New Subscriber Second Set
WHERE T1.event_id = T2.event_id(+) AND T1.rate_plan_id = T2.rate_plan_id(+)
AND T1.event_id = T3.event_id(+) AND T1.rate_plan_id = T3.rate_plan_id(+)
AND T4.event_id = T1.event_id(+) AND T4.event_id = T1.rate_plan_id(+)
AND T4.event_id = T3.event_id(+) AND T4.event_id = T3.rate_plan_id(+);
--Getting error ORA-01417.
Replaced the above join with ANSI Join
SELECT NULL
FROM land_event_device_fraud t1
LEFT OUTER JOIN land_event_device_upgrade t2
ON (t1.event_id = t2.event_id AND t1.rate_plan_id = t2.rate_plan_id)
LEFT OUTER JOIN syn_intg_event_device_state t3
ON (t1.event_id = t3.event_id AND t1.rate_plan_id = t3.rate_plan_id),
land_event_device_upgrade t4
LEFT OUTER JOIN land_event_device_fraud t5
ON (t4.event_id = t5.event_id AND t4.rate_plan_id = t5.rate_plan_id)
LEFT OUTER JOIN syn_intg_event_device_state t6
ON (t4.event_id = t6.event_id AND t4.rate_plan_id = t6.rate_plan_id);You're mixing ANSI joins and old joins. That's very confusing. Use all of one kind or all of the other.
>
I want to know whether the ANSI Join is goig to work fine or it is going to give me any cartesian production information.What happens when you try it? Does it produce the results you want?
Whenever you have a question, post a little sample data (CREATE TABLE and INSERT statements) and the results you want from that data. Explain how you get those results from that data.
Always say which version of oracle you're using.
See the forum FAQ {message:id=9360002}
Why does the SELECT clause include only NULL? Is this going to be used as an EXISTS sub-query? If so, why bother to do outer joins, and why do you care if it does a Cartesian product? What is the compete query?
For debugging purposes, you might want to include something that you can see in the SELECT clause.

Generate ANSI SQL with Oracle IKM

Is it possible for ODI to generate ANSI SQL with the Oracle IKM?
I have used ANSI joins in a filter in an interface, now when I run the interface I get the error: ORA-25156: old style outer join (+) cannot be used with ANSI joins.
I would prefer to use ANSI joins in my filters instead of the old style (+) syntax. Is this possible?

Sure,
Go to topology, edit your Oracle technology , on SQL tab change it over to ordered joins - clause location - From , you can specify the keywords left join, right join, full outer join etc to get rid of your '(+)'

Traditional Joins vs ANSI Joins

Hi all, I come from a SQL Server background and relatively new to Oracle and I am trying to optimize the query below possibly using CTAS, eliminating the UNION ALL and also looking at changing the traditional Joins to ANSI: Ultimately I am interested in any tricks that can improve the performance of this query.
SELECT UPPER(LE.le_desc) le_desc, 1 rpt, 1 algnt, 'ADJUSTMENTS' AS rpt_typ, NULL AS uche, NULL AS uche_acct_no, NULL AS account, NULL AS description, NULL AS allocation_grp, NULL AS legal_structure, NULL AS income_bucket, NULL AS currency, NULL AS sp_investment, NULL AS amount, NULL AS allc_grp_id , ALC.allctn_id AS allctn_id, LE.le_cid,
DECODE (
SELECT lookup_data_mgmt.lookup_value FROM lookup_data_mgmt WHERE LE.mf_cde = lookup_data_mgmt.lookup_id),'Master',1,2
) m_f_ord FROM allctn ALC,
allctn_ds ADS,
allctn_gl_adj AGA,
allctn_gl_adj_dtl AGAD,
uche_acct CLA,
allctn_grp_acct AGAC,
ibg IBG,
ib IB,
allctn_grp AG,
allctr ALR,
allctr_le ALE,
le LE,
ls_flag,
curr CU,
ACCTNG_DS_uche_ACCT_GL ACCT_GL
WHERE
ALR.allctr_id = ALE.allctr_id AND
LE.le_cid = ALE.le_cid AND
ACCT_GL.ALLCTN_DS_ID = ads.allctn_ds_id AND ACCT_GL.ALLCTN_GRP_ACCT_ID = AGAC.ALLCTN_GRP_ACCT_ID AND LE.le_cid = ls_flag.le_cid AND ALR.allctr_id = ALC.allctr_id AND ALC.allctn_id = ADS.allctn_id AND ale.ALLCTR_LE_ID = ads.allctr_le_id AND AGA.allctn_ds_id = ADS.allctn_ds_id AND AGA.allctn_grp_id = AG.allctn_grp_id AND AGAD.allctn_gl_adj_id = AGA.allctn_gl_adj_id AND CLA.uche_acct_id = AGAD.uche_acct_id AND AGAC.uche_acct_id = CLA.uche_acct_id AND AG.allctn_grp_id = AGAC.allctn_grp_id AND IBG.ib_cid = IB.ib_cid AND IBG.ls_flag_id = ls_flag.ls_flag_id AND IBG.ibg_id = AG.ibg_id AND IBG.SUB_FLAG_HDG_CURR_ID = cu.curr_id (+)
GROUP BY
ALC.allctn_id,LE.le_cid,LE.le_desc,LE.mf_cde
UNION ALL
SELECT UPPER(LE.le_desc) le_desc, 2 rpt, 1 algnt, 'ADJUSTMENTS' AS rpt_typ, AGAD.uche_acct_id AS uche, CLA.acct_num AS uche_acct_no,
CASE WHEN CLA.uche_acct_id IN (SELECT AXA.uche_acct_id FROM ax_acct AXA) THEN (SELECT ax_acct_num FROM ax_acct WHERE AX_ACCT.uche_acct_id = CLA.uche_acct_id ) WHEN CLA.uche_acct_id IN (SELECT NERA.uche_acct_id FROM eph_nrstrcd_acct NERA) THEN (SELECT eph_acct_num FROM eph_nrstrcd_acct WHERE EPH_NRSTRCD_ACCT.uche_acct_id = CLA.uche_acct_id) WHEN CLA.uche_acct_id IN (SELECT EPH_RSTRCD_ACCT.uche_acct_id FROM eph_rstrcd_acct) THEN (SELECT EPH_RSTRCD_ACCT.eph_rstrcd_acct_num FROM eph_rstrcd_acct WHERE EPH_RSTRCD_ACCT.uche_acct_id = CLA.uche_acct_id ) END account, CLA.uche_acct_desc description, AG.allctn_grp_desc AS allocation_grp, ls_flag.ls_flag_name AS legal_structure, IB.ib_flag AS income_bucket, NULL AS currency, DECODE(IB.ib_flag,'SP ',(SELECT IBG.sub_flag_sp FROM ibg ibg1 WHERE ibg1.ibg_id = IBG.ibg_id AND IB.ib_cid = IBG.ib_cid),NULL) AS sp_investment, AGAD.adj_amt_in_base AS amount, AG.allctn_grp_id AS allc_grp_id , ALC.allctn_id AS allctn_id, LE.le_cid, DECODE ((SELECT lookup_data_mgmt.lookup_value FROM lookup_data_mgmt WHERE LE.mf_cde = lookup_data_mgmt.lookup_id),'Master',1,2) m_f_ord FROM allctn ALC, allctn_ds ADS, allctn_gl_adj AGA, allctn_gl_adj_dtl AGAD, uche_acct CLA, allctn_grp_acct AGAC, ibg IBG, ib IB, allctn_grp AG, allctr ALR, allctr_le ALE, le LE, ls_flag, curr CU, ACCTNG_DS_uche_ACCT_GL ACCT_GL WHERE ALR.allctr_id = ALE.allctr_id AND LE.le_cid = ALE.le_cid AND ACCT_GL.ALLCTN_DS_ID = ads.allctn_ds_id AND ACCT_GL.ALLCTN_GRP_ACCT_ID = AGAC.ALLCTN_GRP_ACCT_ID AND LE.le_cid = ls_flag.le_cid AND ALR.allctr_id = ALC.allctr_id AND ALC.allctn_id = ADS.allctn_id AND ale.ALLCTR_LE_ID = ads.allctr_le_id AND AGA.allctn_ds_id = ADS.allctn_ds_id AND AGA.allctn_grp_id = AG.allctn_grp_id AND AGAD.allctn_gl_adj_id = AGA.allctn_gl_adj_id AND CLA.uche_acct_id = AGAD.uche_acct_id AND AGAC.uche_acct_id = CLA.uche_acct_id AND AG.allctn_grp_id = AGAC.allctn_grp_id AND IBG.ib_cid = IB.ib_cid AND IBG.ls_flag_id = ls_flag.ls_flag_id AND IBG.ibg_id = AG.ibg_id AND AGAD.adj_amt_in_base <> 0 AND IBG.SUB_FLAG_HDG_CURR_ID = cu.curr_id (+)
Any help will be greatly appreciated...
Thanks

1) Can you edit your post to put [pr[/b][b]e] and [pr[/b][b]e] tags around the code to preserve white space?
2) From a performance perspective, there should be no difference between traditional and ANSI joins (unless, of course, you're on an older version of Oracle that doesn't support ANSI joins).
3) What is the query plan?
4) What is the Oracle version?
5) Are your statistics accurate?
Justin

Help on - convert ansi sql to oracle sql

hi gurus,
i'm try'g to convert ansi sql to oracle sql.
but i'm getting an error. can u please let me know, if i can convert it or is it better to use ansi sql!
original code in ansi format::
select distinct bfc.NBR_SEQ, bfc.IDN_ENTITY, bfc.CDE_TYPE_ENTITY, n.CDE_STATUS,
         gec.idn_group as idn_parent_id, bfc.IDN_FUNC_BUSS,
         case when bfc.CDE_TYPE_ENTITY = 'P' OR bfc.CDE_TYPE_ENTITY = 'A' then
            PKG_FW_NVGTR.GET_NAM_PAGE(bfc.IDN_ENTITY)
          else
            PKG_FW_NVGTR.GET_NAM_GROUP(bfc.IDN_ENTITY)
         end as ENTITY_NAM,
         p.Category, p.Display_Txt, p.show_in_nav, p.page_uri
from
    T_BUSS_FUNC_ENTITY_CREF bfc
    inner join t_buss_func bf on bfc.idn_func_buss = bf.idn_func_buss
    inner join t_entity_prog_cref epc on bfc.idn_entity = epc.idn_entity and bfc.cde_type_entity = epc.cde_type_entity
    left outer join t_page p on bfc.idn_entity = p.idn_page
    left outer join t_group_entity_cref gec on bfc.idn_entity = gec.idn_entity and bfc.cde_type_entity = gec.cde_type_entity
    left outer join t_nvgtr n on bfc.idn_entity = n.idn_entity and bfc.cde_type_entity = n.cde_type_entity
where
    BF.nam_func_buss = 'CP' AND--P_NAM_FUNC_BUSS and
    epc.cde_program in
      ( select p.cde_program from t_program p where p.nam_program in (
          SELECT * FROM TABLE (CAST(PKG_FW_NVGTR.FN_GET_ARRAY_FROM_COMMA_LIST('LC', ',') AS TYP_ARRAY))))
order by
    bfc.NBR_SEQ;tried to convert into oracle
SELECT DISTINCT bfc.NBR_SEQ,
             bfc.IDN_ENTITY,
             bfc.CDE_TYPE_ENTITY,
             n.CDE_STATUS,
             gec.idn_group as idn_parent_id,
             bfc.IDN_FUNC_BUSS,
             case when bfc.CDE_TYPE_ENTITY = 'P' OR bfc.CDE_TYPE_ENTITY = 'A' then
                         PKG_FW_NVGTR.GET_NAM_PAGE(bfc.IDN_ENTITY)
                       else
                         PKG_FW_NVGTR.GET_NAM_GROUP(bfc.IDN_ENTITY)
             end as ENTITY_NAM,
             p.Category,
             p.Display_Txt,
             p.show_in_nav,
             p.page_uri
FROM    T_BUSS_FUNC_ENTITY_CREF bfc,
             T_BUSS_FUNC bf,
             T_ENTITY_PROG_CREF epc,
             T_PAGE p,
             T_GROUP_ENTITY_CREF gec,
             T_NVGTR n
WHERE bfc.IDN_FUNC_BUSS = bf.IDN_FUNC_BUSS
AND bfc.IDN_ENTITY = epc.IDN_ENTITY
AND bfc.CDE_TYPE_ENTITY = epc.CDE_TYPE_ENTITY
AND bfc.IDN_ENTITY(+) = p.IDN_PAGE
AND bfc.IDN_ENTITY(+) = gec.IDN_ENTITY
AND bfc.CDE_TYPE_ENTITY(+) = gec.CDE_TYPE_ENTITY
AND bfc.IDN_ENTITY(+) = n.IDN_ENTITY
AND bfc.CDE_TYPE_ENTITY(+) = n.CDE_TYPE_ENTITY
AND BF.nam_func_buss = 'CP' AND--P_NAM_FUNC_BUSS and
    epc.cde_program in
      ( select p.cde_program from t_program p where p.nam_program in (
          SELECT * FROM TABLE (CAST(PKG_FW_NVGTR.FN_GET_ARRAY_FROM_COMMA_LIST('LC', ',') AS TYP_ARRAY))))
               order by
                 bfc.NBR_SEQ;error is
ORA-01417: a table may be outer joined to at most one other tableso how can i convert it?
thanks

user642856 wrote:
explain plan for this select statement
ID         PID       Operation                                                                                  Name                                                                Rows    Bytes    Cost     CPU Cost          IO Cost Temp space      IN-OUT PQ Dist PStart   PStop
0                      SELECT STATEMENT                                                                                                                                       10M                  1183M 570694 33G      567917
1          0            SORT UNIQUE                                                                                                                                                            10M                  1183M 287940 17G      286502 2607M
2          1              HASH JOIN                                                                                                                                                   10M                  1216M 179       1G        84
3          2                COLLECTION ITERATOR PICKLER FETCH   PKG_FW_NVGTR.FN_GET_ARRAY_FROM_COMMA_LIST
4          2                HASH JOIN OUTER                                                                                                                         2693             299K     58         34M      55
5          4                  HASH JOIN OUTER                                                                                                                                   37                     3959     11         24M      9
6          5                    HASH JOIN OUTER                                                                                                                     37                         3663     10         18M      8
7          6                      HASH JOIN                                                                                                                               37                         1147     7          12M      6
8          7                        HASH JOIN                                                                                                                             59                         1180     5          6060823            4
9          8                          NESTED LOOPS                                                                                                       2                      24                     3          15843   3
10         9                            TABLE ACCESS BY INDEX ROWID T_BUSS_FUNC             1                      6                      1             8341     1
11         10                             INDEX UNIQUE SCAN                                UK_NAM_FUNC_BUSS 1                       0                      1050     0
12         9                            TABLE ACCESS FULL                                             T_PROGRAM                2                      12             2          7501     2
13         8                          INDEX FULL SCAN                            PK_T_ENTITY_PROG_CREF      59                     472       1             18921   1
14         7                        TABLE ACCESS FULL                         T_BUSS_FUNC_ENTITY_CREF 37                     407       2             14891   2
15         6                      TABLE ACCESS FULL                           T_PAGE                                                           26                     1768     2          14141   2
16         5                    INDEX FULL SCAN                                              UK_UNIQUE_GROUP_DEPENDENT 26              208             1          12321   1
17         4                  TABLE ACCESS FULL                                           T_NVGTR                                                          6986             47K      46         3179613            46                                                           as you can see.. cpu cost is in 33G..
is there any better way?
thanksCan you run this in a session please:
ALTER SESSION set optimizer_dynamic_sampling = 4;Then run an explain plan again.
And you have a function in there - PKG_FW_NVGTR.FN_GET_ARRAY_FROM_COMMA_LIST - which isn't helping things.

One question that Ansi join convert to (+)

Hi,
Original sql as below:
left join limit_order on limit_order.id = active_request_leg_map.DEAL_ID and limit_order.rita_deal_id = request.rita_deal_id
I want to use （+） instead of Ansi join, how to do it?
Thanks
Edited by: user886998 on 2011-4-4 下午9:01
Edited by: user886998 on 2011-4-4 下午9:02
Edited by: user886998 on 2011-4-4 下午9:05
Edited by: user886998 on 2011-4-4 下午9:06

Hi,
Welcome to the forum!
user886998 wrote:
Original sql as below:
left join limit_order on limit_order.id = active_request_leg_map.DEAL_ID and limit_order.rita_deal_id = request.rita_deal_id
I want to use （+） instead of Ansi join, how to do it?Why? Are you using Oracle 8 (or earlier)? That's the only good reason for using non-ANSI joins, especially for outer joins.
Whenever you post a question, say which version of Oracle you're using.
If you really must do this without ANSI joins, then join active_request_leg_map and request in a sub-query, and then join limit_order to that result set.
SELECT ...
FROM    (
            SELECT a.deal_id
            ,       r.rita_deal_id
            FROM    active_request_leg_map a
            ,       request                 r
            WHERE   ...
        )            sq
,       limit_order lo
WHERE   lo.id (+)            = sq.deal_id
AND     lo.rita_deal_id (+) = sq.rita_deal_id
...If you'd care to post a little sample data (CREATE TABLE and INSERT statements for all tables) and the results you want from that data, then I could show you exactly, and test it.

Bug in either ANSI Join or Oracle 10.2

Similar Messages

Maybe you are looking for