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

Similar Messages

  • Outer join syntax - oracle 8i

    Here is an Oracle 8i issue I've run into ....
    I am trying to create a table that contains a record for each hour of the day (even if count is 0). I have a problem when I try a right outer join using the following syntax:
    SELECT MDT.date_field, COUNT(*)
    FROM MASTER_DATE_TABLE MDT, hsa_tgt.PICIS_OR POR
    WHERE MDT.date_field = TO_CHAR(POR.OR_IN_DTTM,'YYYYMMDDHH24') (+)
    AND TO_DATE(MDT.date_field,'YYYYMMDDHH24') >= '01-Jan-2006'
    AND TO_DATE(MDT.date_field,'YYYYMMDDHH24') <= '31-Jan-2006'
    GROUP BY MDT.date_field;
    The problem 'SQL code no properly ended' only occurs if I use the TO_CHAR function (or any function for that matter) on the outer join line.
    Is there a workaround? I did manage to create a temporary table and then successfully do an outer join in order to bypass having the to_char function in the join statement.
    Maybe a union?
    TIA

    I had to put it in a subquery? (if that's what it's called)
    SELECT a1.date_field DateAndHour, b1.OR_date, NVL(b1.record_count,0)
    FROM  MASTER_DATE_TABLE a1,
                  (SELECT TO_CHAR(b.OR_IN_DTTM,'YYYYMMDDHH24') OR_date, COUNT(*) record_count
                FROM hsa_tgt.PICIS_OR b
                GROUP BY TO_CHAR(b.OR_IN_DTTM,'YYYYMMDDHH24')) b1
    WHERE a1.date_field  = b1.OR_date (+)
    GROUP BY a1.date_field, b1.OR_date, b1.record_count
    HAVING (TO_DATE(a1.date_field,'YYYYMMDDHH24') BETWEEN '01-Jan-2006' AND '31-Jan-2006')
    ORDER BY a1.date_field;

  • 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

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

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

  • 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

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

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

  • Joins in Oracle 8i

    Hi
    Oracle 8i supports keywords for join syntax?
    INNER JOIN
    ON

    You can see that yourself by searching the documentation: http://www.oracle.com/pls/tahiti/tahiti.homepage
    The answer is: no.
    Regards,
    Rob.

  • Translate JOIN syntax from LEFT JOIN, RIGHT JOIN to (+)

    I have looked through a lot of documentation, but have yet to see some concreate examples of how to code a JOIN when you are used to LEFT, RIGHT JOIN, etc.
    Could someone translate these, removing the LEFT OUTER JOIN, etc. and replace with the (+). I am fairly new to Oracle and have been using the others all along?
    SELECT *
    FROM LOCATION L
    LEFT OUTER JOIN DEPT D
    ON (L.LocationID = D.LocationID)
    LEFT OUTER JOIN EMPLOYEE E
    ON (D.DeptID = E.DeptID);
    SELECT *
    FROM EMPLOYEE E
    RIGHT OUTER JOIN DEPT D
    ON (D.DeptID = E.DeptID)
    RIGHT OUTER JOIN LOCATION L
    ON (L.LocationID = D.LocationID);
    SELECT *
    FROM LOCATION L
    FULL JOIN DEPT D
    ON (L.LocationID = D.LocationID)
    FULL JOIN EMPLOYEE E
    ON (D.DeptID = E.DeptID);
    Thank you.

    However,
    select  b.*
    from    table_a a
    ,       table_b b
    where   a.user_id = b.userid(+);<=>
    select          b.*
    from            table_a a
    left outer join table_b b
    on              b.user_id = a.user_idand
    select  b.*
    from    table_a a
    ,       table_b b
    where   a.user_id(+) = b.userid;<=>
    select            b.*
    from              table_a a
    right outer join  table_b b
    on                b.user_id = a.user_idI'm not sure about the full join.
    Edit:
    Ah, yes, I remember. The only way to do a full outer join with Oracle syntax (that I'm aware of) is to use UNION:
    select  b.*
    from    table_a a
    ,       table_b b
    where   a.user_id(+) = b.userid;
    union
    select  b.*
    from    table_a a
    ,       table_b b
    where   a.user_id = b.userid(+);

  • 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

  • Inner Join in oracle 10g

    Is it possible to use inner join in oracle 10g?

    SQL> select ename, dname
      2  from emp inner join dept
      3  on emp.deptno=dept.deptno;
    ENAME      DNAME
    SMITH      RESEARCH
    ALLEN      SALES
    WARD       SALES
    JONES      RESEARCH
    MARTIN     SALES
    BLAKE      SALES
    CLARK      ACCOUNTING
    SCOTT      RESEARCH
    KING       ACCOUNTING
    TURNER     SALES
    ADAMS      RESEARCH
    ENAME      DNAME
    JAMES      SALES
    FORD       RESEARCH
    MILLER     ACCOUNTING
    14 rows selected.
    SQL>

  • How to provide joins between oracle tables and sql server tables

    Hi,
    I have a requirement that i need to generate a report form two different data base. i.e Oracle and Sql Server.
    how to provide joins between oracle tables and sql server tables ? Any help on this
    Regards,
    Malli

    user10675696 wrote:
    I have a requirement that i need to generate a report form two different data base. i.e Oracle and Sql Server. Bad idea most times. Heterogeneous joins do not exactly scale and performance can be severely degraded by network speed and b/w availability. And there is nothing you can do in the application and database layers to address performance issue at the network level in this case - your code's performance is simply at the mercy of network performance. With a single glaring fact - network performance is continually degrading. All the time. Always. Until it is upgraded. When the performance degradation starts all over again.
    If the tables are not small (few 1000 rows each) and row volumes static, I would not consider doing a heterogeneous join. Instead I would rather go for a materialised view on the Oracle side, use a proper table and index structure, and do a local database join.

  • 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

  • Time Out Connection to Database

    Dears,, I am trying to connect to the database through Toad or Sql but it gave me the following error: ORA-12170: TNS:Connect timeout occurred Also, ifd i tried to log in the database UNIX server through Putty ,it gave me the following error Network

  • Stuck on Happy Mac?

    Hello, my old iMac G3 (summer 2000) is stuck on the Happy Mac during boot! I can put a CD in and boot from a software restore disk, which I did, but even after restoring it's not working! Help me please! P.S. I'm running OS 9.0.x

  • Moving Graph Palette out of Pane

    Hello, My current LV8.6.1 project has two modern XY graphs on the FP, separated by splitter bars and set to scale with the split.  I have used property nodes to sync the graph scales and cursors using various graph change events.  Because of this, th

  • Firefox shortcut will not open firefox, only beeps.

    Beep is the same as critical stop, no dialog box shows. Shortcut points to firefox.exe, which will not open.

  • When I click "Edit Original" in the links panel it opens MICROSOFT PAINT!

    When I click "Edit Original" with a jpeg selected in the links panel it opens Microsoft Paint! In Windows (7) the file association is Windows Picture Viewer (NOT Paint!) and in Bridge it is associated with Photoshop CC. In InDesign we have the option