ANSI to traditional (+) join syntax

Hi All,
Can anyone pl help me to understand how the diff tables in this tables are joined ( even 1 join would help) as I am not able to differentiate where the first join ended and whether the result is attched to the previous one or what all :(
I am little confused about how to convert this query in ANSI to the traditional (+) sysntax as I am not able to understannd which table is joined to which table and where exactly the previous join ends.
select distinct a.instrument_id       "INSTRUMENT ID",
                a.name                "DESCRIPTION",
                a.DEBT_PRIORITY_CLASS "DEBT PRIORITY CLASS",
                c.alias               "ISIN",
                b.alias               "MDSCURVE"
  from (select distinct i.instrument_id,
                        i.name,
                        case
                          when (mn2.display_name != 'DEBT PRIORITY CLASS' and
                               mn2.display_name is not null) then
                           mn2.display_name
                          else
                           mn1.display_name
                        end "DEBT_PRIORITY_CLASS"
          from instrument i, inst_debt id
          left join marsnode mn1 on (id.debt_priority_class_id = mn1.node_id and
                                    mn1.close_date is null and
                                    mn1.type_id = 58412926883279)
          left join marsnodelink mnl1 on (mn1.node_id = mnl1.node_id and
                                         mnl1.close_date is null and
                                         mnl1.begin_cob_date <=
                                         TO_DATE('27-Oct-2010',
                                                  'DD-Mon-YYYY') and
                                         mnl1.end_cob_date >
                                         TO_DATE('27-Oct-2010',
                                                  'DD-Mon-YYYY'))
          left join marsnode mn2 on (mnl1.parent_id = mn2.node_id and
                                    mn2.close_date is null and
                                    mn2.type_id = 58412926883279)
         where i.instrument_id = id.instrument_id
           and i.end_cob_date > TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
           and i.close_action_id is null
           and i.product_sub_type_id = 3
           and i.begin_cob_date <= TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
           and i.instrument_vn = id.instrument_vn) a
  left outer join (select i.instrument_id, ia.alias as alias
                     from instrument i, inst_alias ia, domain d
                    where i.instrument_id = ia.instrument_id
                      and ia.domain_id = d.domain_id
                      and d.name = 'MDSCURVE'
                      and i.close_action_id is null
                      and i.product_sub_type_id = 3
                      and i.begin_cob_date <=
                          TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
                      and i.end_cob_date >
                          TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')) b on (a.instrument_id =
                                                                      b.instrument_id)
  left outer join (select i.instrument_id, ia.alias as alias
                     from instrument i, inst_alias ia, domain d
                    where i.instrument_id = ia.instrument_id
                      and ia.domain_id = d.domain_id
                      and d.name = 'ISIN'
                      and i.close_action_id is null
                      and i.product_sub_type_id = 3
                      and i.begin_cob_date <=
                          TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
                      and i.end_cob_date >
                          TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')) c on (a.instrument_id =  c.instrument_id)Specialy the problem with the first left outer join (from instrument i, inst_debt id) , there are many outer joins and i am not able to understand this thing.
Please help me to understand this thing.
Rgds,
Aashish

maybe the comments in this will help...
SELECT   DISTINCT a.instrument_id "INSTRUMENT ID",
                  a.name "DESCRIPTION",
                  a.DEBT_PRIORITY_CLASS "DEBT PRIORITY CLASS",
                  c.alias "ISIN",
                  b.alias "MDSCURVE"
  FROM         (SELECT   DISTINCT
                         i.instrument_id,
                         i.name,
                         CASE
                            WHEN (mn2.display_name != 'DEBT PRIORITY CLASS'
                                  AND mn2.display_name IS NOT NULL)
                            THEN
                               mn2.display_name
                            ELSE
                               mn1.display_name
                         END
                            "DEBT_PRIORITY_CLASS"
                  FROM   instrument i,
                                  inst_debt id
                               LEFT JOIN
                                  marsnode mn1 -- LEFT JOIN from inst_debt to marsnode
                               ON (id.debt_priority_class_id = mn1.node_id
                                   AND mn1.close_date IS NULL
                                   AND mn1.type_id = 58412926883279)
                            LEFT JOIN  -- LEFT JOIN from marsnode to marsnodelink
                               marsnodelink mnl1
                            ON (mn1.node_id = mnl1.node_id
                                AND mnl1.close_date IS NULL
                                AND mnl1.begin_cob_date <=
                                      TO_DATE ('27-Oct-2010', 'DD-Mon-YYYY')
                                AND mnl1.end_cob_date >
                                      TO_DATE ('27-Oct-2010', 'DD-Mon-YYYY'))
                         LEFT JOIN
                            marsnode mn2 -- LEFT JOIN from marsnodelink to marsnode
                         ON (    mnl1.parent_id = mn2.node_id
                             AND mn2.close_date IS NULL
                             AND mn2.type_id = 58412926883279)
                 WHERE   i.instrument_id = id.instrument_id
                         AND i.end_cob_date >
                               TO_DATE ('27-Oct-2010', 'DD-Mon-YYYY')
                         AND i.close_action_id IS NULL
                         AND i.product_sub_type_id = 3
                         AND i.begin_cob_date <=
                               TO_DATE ('27-Oct-2010', 'DD-Mon-YYYY')
                         AND i.instrument_vn = id.instrument_vn) a -- End of in-line view 'a'
            LEFT OUTER JOIN -- LEFT OUTER JOIN from in-line view 'a' to inline view 'b'
               (SELECT   i.instrument_id, ia.alias AS alias
                  FROM   instrument i, inst_alias ia, domain d
                 WHERE       i.instrument_id = ia.instrument_id
                         AND ia.domain_id = d.domain_id
                         AND d.name = 'MDSCURVE'
                         AND i.close_action_id IS NULL
                         AND i.product_sub_type_id = 3
                         AND i.begin_cob_date <=
                               TO_DATE ('27-Oct-2010', 'DD-Mon-YYYY')
                         AND i.end_cob_date >
                               TO_DATE ('27-Oct-2010', 'DD-Mon-YYYY')) b -- End of inline view 'b'
            ON (a.instrument_id = b.instrument_id)
         LEFT OUTER JOIN --LEFT OUTER JOIN from inline view 'a' to inline view 'c'
            (SELECT   i.instrument_id, ia.alias AS alias
               FROM   instrument i, inst_alias ia, domain d
              WHERE       i.instrument_id = ia.instrument_id
                      AND ia.domain_id = d.domain_id
                      AND d.name = 'ISIN'
                      AND i.close_action_id IS NULL
                      AND i.product_sub_type_id = 3
                      AND i.begin_cob_date <=
                            TO_DATE ('27-Oct-2010', 'DD-Mon-YYYY')
                      AND i.end_cob_date >
                            TO_DATE ('27-Oct-2010', 'DD-Mon-YYYY')) c --End of inline view 'c'
         ON (a.instrument_id = c.instrument_id)?
Cheers
Ben

Similar Messages

  • Update to ansi 99 sql join syntax

    Hello All
    I'm updating some code to ansi 99 compliant sql.
    I have
    SELECT
      CL_ASSIGNED_NUMBERS2.TITLE,
      CL_ASSIGNED_NUMBERS2.FIRST_NAME,
      CL_ASSIGNED_NUMBERS2.SURNAME,
      CL_ASSIGNED_NUMBERS2.NUM,
      CL_NUMBERS2.OTHER_NUM,
      CL_ASSIGNED_NUMBERS2.LOCATION,
      CL_AS_DEPTS.DEPT_NAME,
      CL_FURTHER_CONTACTS.TITLE,
      CL_FURTHER_CONTACTS.FIRST_NAME,
      CL_FURTHER_CONTACTS.SURNAME,
      EMAIL.LSE_EMAIL,
      CL_ASSIGNED_NUMBERS2.NUMBER_DESC,
      CL_FURTHER_CONTACTS.NUM,
      CL_FURTHER_CONTACTS.LOCATION,
      CL_ASSIGNED_NUMBERS2.AREA,
      CL_ASSIGNED_NUMBERS2.DESC_DIR_ENTRY,
      CL_ASSIGNED_NUMBERS2.AREA_DIR_ENTRY,
      CL_NUMBERS3.OTHER_NUM,
      CL_ASSIGNED_NUMBERS2.PREF_EMAIL
    FROM
      CALL_LOG.CL_ASSIGNED_NUMBERS  CL_ASSIGNED_NUMBERS2,
      CALL_LOG.CL_NUMBERS  CL_NUMBERS2,
      CALL_LOG.CL_DEPARTMENTS  CL_AS_DEPTS,
      CALL_LOG.CL_ASSIGNED_NUMBERS  CL_FURTHER_CONTACTS,
      CALL_LOG.CURRENT_PERSONAL_EMAILS  EMAIL,
      CALL_LOG.CL_NUMBERS  CL_NUMBERS3
    WHERE
      ( CL_ASSIGNED_NUMBERS2.FURTHER_CONTACT_CAN_ID=CL_FURTHER_CONTACTS.CAN_ID(+)  )
      AND  ( CL_ASSIGNED_NUMBERS2.DEPT_CODE=CL_AS_DEPTS.DEPT_CODE(+)  )
      AND  ( CL_NUMBERS2.NUM=CL_ASSIGNED_NUMBERS2.NUM(+)  )
      AND  ( CL_ASSIGNED_NUMBERS2.PLAY_REF=EMAIL.PLAY_REF(+)  )
      AND  ( CL_FURTHER_CONTACTS.NUM=CL_NUMBERS3.NUM(+)  )which i have rewritten as
    SELECT
      AS_NO.TITLE,
      AS_NO.FIRST_NAME,
      AS_NO.SURNAME,
      AS_NO.NUM,
      NO.OTHER_NUM,
      AS_NO.LOCATION,
      DEPT.DEPT_NAME,
      AS_NO.TITLE,
      CONS.FIRST_NAME,
      CONS.SURNAME,
      EMAIL.LSE_EMAIL,
      AS_NO.NUMBER_DESC,
      CONS.NUM,
      CONS.LOCATION,
      AS_NO.AREA,
      AS_NO.DESC_DIR_ENTRY,
      AS_NO.AREA_DIR_ENTRY,
      NOS.OTHER_NUM,
      AS_NO.PREF_EMAIL
    FROM CL_ASSIGNED_NUMBERS AS_NO
    LEFT OUTER JOIN CL_ASSIGNED_NUMBERS CONS ON (AS_NO.FURTHER_CONTACT_CAN_ID=CONS.FURTHER_CONTACT_CAN_ID)
    LEFT OUTER JOIN CL_DEPARTMENTS DEPT ON (AS_NO.DEPT_CODE=DEPT.DEPT_CODE)
    LEFT OUTER JOIN CL_NUMBERS NO ON (AS_NO.NUM=NO.NUM)
    LEFT OUTER JOIN CURRENT_PERSONAL_EMAILS EMAIL ON (AS_NO.PLAY_REF=EMAIL.PLAY_REF)
    LEFT OUTER JOIN CL_NUMBERS NOS ON (CONS.NUM=NOS.NUM)with the first query i get 8130 rows, with the second I get 9676.
    Yet to me the seem like the same query. Can anyone give me an idea as to where I've gone wrong?
    Thanks and Regards
    Ali

    select count (*)
    FROM
    CALL_LOG.CL_ASSIGNED_NUMBERS  CL_ASSIGNED_NUMBERS2,
    CALL_LOG.CL_NUMBERS  CL_NUMBERS2,
    CALL_LOG.CL_ASSIGNED_NUMBERS  CL_FURTHER_CONTACTS
    WHERE
    ( CL_ASSIGNED_NUMBERS2.FURTHER_CONTACT_CAN_ID=CL_FURTHER_CONTACTS.CAN_ID(+)  )
    AND ( CL_NUMBERS2.NUM=CL_ASSIGNED_NUMBERS2.NUM(+) )
      COUNT(*)
          8130
    select count (*) from
    CL_NUMBERS NO
    LEFT OUTER JOIN CL_ASSIGNED_NUMBERS AS_NO ON (AS_NO.NUM = NO.NUM)
      4  LEFT OUTER JOIN CL_ASSIGNED_NUMBERS CONS ON (AS_NO.FURTHER_CONTACT_CAN_ID = CONS.FURTHER_CONTACT_CAN_ID)
      5  .
    SQL> /
      COUNT(*)
         10268Can this be reduced to two tables (aliases) only? Or, which single table/alias produces the discrepancy?
    Can either or both of NUM and FURTHER_CONTACT_CAN_ID in CL_NUMBERS be NULL, or FURTHER_CONTACT_CAN_ID in CL_ASSIGNED_NUMBERS be NULL?
    If any of those columns on the LEFT side the OUTER JOIN can be NULL, can you wrap it/them with NVL(,0), and try both counts again, i.e.,
    select count (*)
    FROM
    CALL_LOG.CL_ASSIGNED_NUMBERS  CL_ASSIGNED_NUMBERS2,
    CALL_LOG.CL_NUMBERS  CL_NUMBERS2,
    CALL_LOG.CL_ASSIGNED_NUMBERS  CL_FURTHER_CONTACTS
    WHERE
    ( NVL(CL_ASSIGNED_NUMBERS2.FURTHER_CONTACT_CAN_ID,-9)=CL_FURTHER_CONTACTS.CAN_ID(+))
    AND (NVL(CL_NUMBERS2.NUM,-9)=CL_ASSIGNED_NUMBERS2.NUM(+) )
    select count (*) from
    CL_NUMBERS NO
    LEFT OUTER JOIN CL_ASSIGNED_NUMBERS AS_NO ON (NVL(AS_NO.NUM,-9) = NO.NUM)
    LEFT OUTER JOIN CL_ASSIGNED_NUMBERS CONS ON (NVL(AS_NO.FURTHER_CONTACT_CAN_ID,-9) = CONS.FURTHER_CONTACT_CAN_ID)Assuming that both those columns are numeric, and that '-9' is not a valid value for those columns.
    Edited by: SeanMacGC on Apr 8, 2009 12:34 PM

  • 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]

  • 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

  • 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}

  • ANSI/9i Join Syntax and Pretty Code

    I've always tried to keep my SQL statement code formatted in a way that I think helps readability. I picked up the following style because I found it easy to quickly find the FROM clause and the JOINS or conditions:
    select e.ename,
           e.sal,
           d.dname
    from   emp e,
           dept d
       * Joins
    where  e.deptno = d.deptno
       * Conditions
    and    d.dname = 'SALES'
    /Of course, for such a simple query I wouldn't have used the comments to divide the WHERE clause into joins and conditions...
    Anyway, since Tom Kyte and the 9i documentation suggest using the ANSI join syntax (amongst other reasons), I have decided to begin changing my ways. However, I am having troubles figuring out how to format my SQL to still be "pretty."
    For the previous example, a new formatting style seems easy:
    select e.ename,
           e.sal,
           d.dname
    from   emp e
      join dept d          on e.deptno = d.deptno
    where  d.dname = 'SALES'
    /Now, when we use an example that has optional joins is where I can't figure what my style should be:
    select e.ename,
           m.ename as manager
    from        emp e
      left join emp m      on e.mgr = m.empno
    where  e.deptno = 10
    /I don't really like this style since it gets so wide, causing problems when indenting for subqueries/inline-views. It also looks kinda clunky because the tables are indented more than everything else...
    Anyway, since I don't want to spend a bunch of time figuring out things like style, I'd like to see what other formats people are using. I'd appreciate seeing how others are formatting thier SQL when using the new 9i (old-ANSI) syntax.
    Thanks, Stan

    That looks to me like left aligned (but I may be on the wrong side of the looking glass...)
    By preference is to left-align the KEYWORDS and the data words, using indentation to distinguish the start of the different clauses (SELECT, FROM, WHERE, ORDER BY, etc.). This approach is easily standardised with Textpad or similar editing tools. Quite how one programs a text editor to turn one's code into a Rorschach blot is beyond me.
    I haven't done much with ANSI joins, so I hadn't come up with a standard for layout. The following is what I think I would do if I ever had to, and is basically an adaption of what I do now ...
    FROM   user_indexes i
           , user_ind_columns ic2
           , user_tab_columns c2with the ANSI join stuff indented and aligned. I find rigourous application of UPPER and lower case tends to assist clarity: indentation and alignment are not enough.
    SELECT i.table_name
           , i.index_name
           , ic2.column_position
    FROM   user_indexes i
           INNER JOIN user_ind_columns ic2
           ON i.table_name = ic2.table_name
           AND i.index_name = ic2.index_name
           INNER JOIN user_tab_columns c2
           ON ic2.table_name = c2.table_name
           AND ic2.column_name = c2.column_name
    WHERE  i.uniqueness='UNIQUE'
    ORDER  BY i.table_name
           , i.index_name
           , ic2.column_position
    /

  • 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

  • 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.

  • URGENT - need help with ansi/iso outer joins

    Hi,
    I am currently preparing for the OCP sql exam for the 9i developer track and I think a statement is printed wrong in my study book, please could somebody confirm the following:-
    Oracle Outer Join syntax
    from tab_a, tab_b
    where a.col_1 (+) = b.col_1
    ANSI/ISO Equivalent
    from tab_a a left outer join tab_b b
    on a.col_1 = b.col_1
    Should n't the above be a right outer join
    Please could somebody confirm or explain if I am wrong.
    Thanks in anticipation.
    Simon
    Note. The book is OCP Introduction to 9i sql (1Z0-007) page 115 (table 3-1) - author Jason Couchman

    It seems so....
    See
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_103a.htm#2107297

  • Bug in JOIN syntax? (oracle 9i)

    Hi,
    take these three tables:
    MASTER (id NUMBER, name VARCHAR2(10))
    DETAIL (id NUMBER, master_id NUMBER)
    SUBDETAIL (id NUMBER, detail_id NUMBER, name VARCHAR(10)
    When I perform this query:
    SELECT SUBDETAIL.id as did, MASTER.id as mid
    FROM SUBDETAIL
    JOIN DETAIL ON (SUBDETAIL.detail_id = DETAIL.id)
    JOIN MASTER ON (DETAIL.master_id = MASTER.id)
    WHERE
    name = 'joe';
    I would expect the parser to give me 'column ambiguously defined' (because the 'name' field from the whereclause is defined in both subdetail and master).
    However, it does not say that. Instead, it assumes that it should use the name field from master. This is confusing, as this could easily lead to mistakes (as it did in my application)
    Greetings,
    Ivo

    There seems to be a difference between the way Oracle resolves column names using the ANSI join syntax and Oracle's syntax. It appears that Oracle does not know about the columns, until it processes each join, and further, the last table joined seems to be sued to resolve nameing conflicts. Consider:
    SQL> SELECT * FROM master;
            ID NAME
             1 joe
    SQL> SELECT * FROM subdetail;
            ID  DETAIL_ID NAME
             1          2 fred
    SQL> SELECT * FROM detail;
            ID  MASTER_ID
             2          1
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM subdetail
      3       JOIN detail ON (subdetail.detail_id = detail.id)
      4       JOIN master ON (detail.master_id = master.id)
      5  WHERE name = 'joe';
           DID        MID
             1          1
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM subdetail
      3       JOIN detail ON (subdetail.detail_id = detail.id)
      4       JOIN master ON (detail.master_id = master.id)
      5  WHERE name = 'fred';
    no rows selected
    So, it is clearly going after master.name. However,
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM detail
      3       JOIN master ON (master.id = master_id)
      4       JOIN subdetail ON (subdetail.detail_id = detail.id)
      5  WHERE name = 'joe'
    no rows selected
    But,
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM detail
      3       JOIN subdetail ON (subdetail.detail_id = detail.id)
      4       JOIN master ON (master.id = master_id)
      5  WHERE name = 'joe'
           DID        MID
             1          1
    Old style syntax gives:
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM subdetail, detail, master
      3  WHERE subdetail.detail_id = detail.id and
      4        detail.master_id = master.id and
      5        name = 'joe';
          name = 'joe'
    ERROR at line 5:
    ORA-00918: column ambiguously defined
    and note that
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM subdetail
      3      JOIN master ON (detail.master_id = master.id)
      4      JOIN detail ON (subdetail.detail_id = detail.id)
      5  WHERE name = 'joe'
        JOIN master ON (detail.master_id = master.id)
    ERROR at line 3:
    ORA-00904: invalid column nameSo, in ANSI syntax, order matters, and whatever the syntax good testing matters.
    TTFN
    John

  • Outer Join Syntax in sql2k to Oracle Migration

    All of my existing SQL Server 2000 code is using the (INNER, LEFT OUTER, RIGHT OUTER) JOIN syntax which according to Oracle SQL Reference (A90125-01) is supported. The migration workbench seems to want to convert this to the old style syntax of putting (+) in the where clause conditions. I am therefore getting lots of warnings telling me that "complex outer joins are not reliably supported". Is there a setting somewhere that will tell the migration workbench to maintain (subject to required conversion) the original syntax format.

    Hi Doug,
    The issue you report has been tackled in a recent internal build released by the OMWB team. OMWB version 9.2.0.1.6 which is freely downloadable on the http:\\mtg.ie.oracle.com site. As I've mentioned, this is an internal release and is therefore not supported - although it is very stable and has already been used by several internal customers. We expect to have a fully supported release of OMWB available on OTN in December.
    In version 9.2.0.1.6, there is an option in the "Parse Options" tab on the Stored Procedures property sheet called "Generate Oracle 8i Outer Joins" - this setting is switched off by default in this build and would therefore preserve your ANSI compliant joins by default. Switching the setting on causes the OMWB parser to generate the joins in the old (+) Oracle syntax standard.
    I hope this helps,
    Tom.

  • When Mig Workbench will support the JOIN syntax?

    Oracle 9i supports the ANSI SQL standard. The current workbench
    version converts the JOIN syntax into the (+) syntax. Does
    anybody know if and when the Migration Workbench will support
    the JOIN syntax i.e. not try and convert it?
    Thanks
    Costas

    Hi,
    Oracle 9i now supported ANSI standard outer joins. We are
    currently planning our coming releases of the Workbench and we
    would hope to include outer join capability in version 2.0.3 of
    the Workbench . We have not finalised plans yet but it looks like
    being Q1 next Calendar year.
    Regards
    John

  • Request your expert opinions -- 9i join syntax?

    Are you who do SQL programming going to use the new 9i JOIN syntax? Is the old syntax (using the + sign) going to be depricated soon? What do you think? Why should I switch to the new format? I am wondering what others are doing or planning to do.
    Thank you very much for your time.

    Personally, I think the ANSI compliant syntax is clearer and easier to read. Also it has FULL OUTER which is something the old Oracle syntax doesn't support.
    However, I don't think (+) will be deprecated before 10i and I think it will remained suppported for the foreseeable future: there're just too many lines of SQL code out there using it!
    my tuppence halfpenny worth, APC

  • OBIEE not applying outer join syntax to filters

    (Note: I've already thoroughly searched the forums before posting this. Thanks)
    My problem is the following:
    I'm trying to build a report that is a count from my fact table, grouped by month from my date dimension for a given year, resulting in 12 data points. The problem is that not all months have actual data, but I still need those months to show on the report with a count of zero. Typical simple reporting requirement.
    I have already done the obvious and within my business layer made the join between my fact table and my date dimension an outer join on the fact side, just like you'd do if writing the query by hand. And when tested by hand this includes all dates for the year anyway, and when coupled with the appropriate null test on the count measure I'd get my 12 data points with zeros were appropriate.
    The problem is that there are additional filters I need to apply on the fact data (there are a couple text-based code values that didn't warrant full tables themselves so are just degenerate dimensions directly on the fact table.)
    When these filters are applied at the Answer level, I'm only getting back the months that actually have data, and lose the months where the count should be zero. A check of the session log for the query that was generated shows the problem. While OBI properly generates the outer-join syntax for the join itself between the two tables (my date dim and fact table) it does NOT apply the outer-syntax to the constant-based filter against the fact, effectively negating the outer join.
    Actual query from the log (I simply changed the table aliases from the ugly T##### stuff OBI generates to something more readable for posting here):
    select D.DT_MONTH_NAME as c1,
    D.DT_MONTH_NUM as c2,
    I.INC_TYPE as c3,
    I.INC_EMP_GROUP as c4,
    sum(case when I.INC_KEY is null then 0 else 1 end ) as c5
    from DATE_DIM D, INCIDENT_F I
    where ( D.DATE_KEY = I.DATE_KEY (+) ) and ( D.DT_YEAR = 2010 and I.INC_EMP_GROUP = 'CONTRACTOR' )
    group by D.DT_MONTH_NUM, D.DT_MONTH_NAME, I.INC_TYPE, I.INC_EMP_GROUP
    order by c2
    You can see that the outer syntax (+) is applied to the join, but not to the filter on I.INC_EMP_GROUP. If I take this query and drop it in something like SQL Developer, it only returns the months with data. If I throw the (+) after I.INC_EMP_GROUP like I'd do if writing this by hand, the desired zero-months results pop back in.
    I have already searched the forums and while lots of people seem to have asked this question, the only solutions involve things like trickery in the business layer using dummy fact tables followed by manipulations at the report level etc. Unfortunately I can't rely on these as the system is eventually to be turned over to users who can't be expected to apply various hacks to write reports.
    Anyone ever get to the bottom of getting OBI to apply outer join logic in filters as well, when the filtered table is meant to be outer-joined to?
    Any comments are appreciated.
    John

    I know that this thread is a bit old thought it might be helpful to some one...
    The Issue is, when using Degener@teDimen$ion ( this is !nner joned to FACT tables in BMM) and if any of the dimensions {other than theDegener@teDimen$ion (Let us say Dim X) } have an ()uter join to any of the fact tables, and you were doing your analysis using Degener@teDimen$ion,  Dim X, Measure value you will face the following issues.
    when filtering the analysis on the ()uter join dimension ( Dim X), the IN filter will not work. Reason is that the filter is getting applied to both the Dimension and FACT tables and the values that exist in Dimension Dim X but not in FACT table wont show up.
         The above issue can be fixed by changing the join between the fact and Degener@teDimen$ion from inner to outer. I think this is a bug.. because  it is supposed to filter the fact  table after the entire outer joined result is obtained but not filter the fact table for the Dim X values and do a outer join. I think the BI should be intelligent enough.

  • Drag-n-n-drop query joins uses WHERE, not INNER JOIN syntax

    When I highlight a few tables and drag them onto the sql worksheet, it will build a select statement for me and join the tables by their foreign keys.
    That's a nice feature, thanks!
    Three questions. Is it possible to:
    1. get it to use the INNER JOIN and LEFT OUTER JOIN syntax instead of joining the tables in the WHERE clause?
    2. control the table aliases so that it will automatically use the "standard alias" for the table instead of A, B, C, etc.?
    3. get it to not put the schema name into the query?
    Thanks!
    Edited by: David Wendelken on Nov 22, 2008 1:48 PM. Grammar mistake.

    Hi Gopi,
    Your code is Good.
    But try to avoid Inner join with more number of Tables ...because this is a performance issue..
    try to use..
    select (primary key fields mainly,other fields) from LIKP into itab where bolnr in p_bolnr(paramater).
    next try to use for all entries option..
    select (primary key fields mainly,other fields) from VBFA for all entries in itab where (give the condition)....
    simillarly do for the other select ....ok this will try to reduce the performance issue....
    <b><REMOVED BY MODERATOR></b>
    Message was edited by:
            Alvaro Tejada Galindo

Maybe you are looking for

  • Key Reports for Customers (Follow-Up from P2P)

    Currently, we are working intensively on enhancing the reporting area in B1 and XL Reporter. Our ambition is to reach a situation where most of the required reports will be installed automatically. We would like to know your opinion about your prefer

  • Backing up files from the iPad

    I'm buying an iPad Retina tomorrow. I will be traveling with it shortly, and will be storing images from my camera to the iPad via a Lightning USB connector. Does this connector work the other way too?  I.E. can I attach an external USB key to the co

  • Problem in events

    Hi, There are two tabs in my selection screen ,when I enter the values in first tab and click the execute button ,ALV is shown.After showing the ALV when back button is clicked ,it will come to the first tab.Uptill this point program is working fine.

  • Error messages BAPI

    Hi all, Again with the 'BAPI_GOODSMVT_CREATE'. I wat to create a error messages file, where it display me the reason why the paramenter gt_bapigm_headret in some cases is initial. How can I do it? Thanks in advance. Regards, Marisol.

  • Elements 13 crashing when attempting to start

    Bought elements and downloaded.  When I attempt to click either the organizer or photo editor option from the they both instantly crash. I have not been able to open the program at all.  Attempted to run as admin with no luck.  This is a fully author