Non-ANSI Outer Join Operator Issue
I am currently using Designer 11.5.0.0. Itu2019s XI Rel 2, but Iu2019m not sure what service pack. I have created several universes with outer joins against a SQL Server 2005 database, but when I try using them in a Crystal report, I get the following error:
Failed to retrieve date from the database.
Details: 42000:[Microsoft][ODBC SQL Server Driver][SQL Server] The query uses non-ANSI outer join operators (u201C=u201D or u201C=u201D). To run this query without modification, please set the compatibility level for current database to 80 or lower, using stored procedure sp_dbcmptlevel. It is strongly recommended to rewrite the query using ANSI outer join operators (LEFT OUTER JOIN, RIGHT OUTER JOIN). In the future versions of SQL Server, non-ANSI join operators will not be supported even in backward-compatibility modes.
Here is my ODBC DSN configuration:
Microsoft SQL Server ODBC Driver Version 03.85.1132
Data Source Name: FlexOPS
Data Source Description:
Server: dalsvrw031
Database: (Default)
Language: (Default)
Translate Character Data: Yes
Log Long Running Queries: No
Log Driver Statistics: No
Use Integrated Security: No
Use Regional Settings: No
Prepared Statements Option: Drop temporary procedures on disconnect
Use Failover Server: No
Use ANSI Quoted Identifiers: Yes
Use ANSI Null, Paddings and Warnings: Yes
Data Encryption: No
Okay, so I understand what the issue is. It appears that the version of Designer that I am using does not default the ANSI92 parameter to u201CYesu201D. So all the outer joins I have created in each of my universe are using the old *= as the join operator. And apparently, the ODBC driver I am using is not very happy with that.
As I understand it from what Iu2019ve read on other sites, I have the following options:
1) Set the ANSI92 parameter to Yes, drop all my joins, close and re-open Designer, and recreate all of the joins.
2) Find a different driver or connectivity method that will support non-ANSI joins.
3) Set my database back to SQL 2000 compatibility.
Option 1 is unappealing as it will cause a lot of time redoing all the work that Iu2019ve spent the past month doing. Option 2 is only a band-aid fix at best. Option 3 really isnu2019t an option for us.
So I am wondering what other options I have to change these non-ANSI joins to ANSI compatible joins. Do I need to update Designer with a service pack? Is there a script out there that will automatically do this in each of the universes?
I would appreciate any suggestions or guidance on this.
Thanks,
Lee
Edited by: Lee Vance on Jul 6, 2009 10:02 PM
Hi,
try the following:
open your universe in the Universe designer, go to File->Parameter, select the Parameter tab and change the value of the ANSI92 parameter from No to Yes.
Regards,
Stratos
Similar Messages
-
Non-ANSI Outer Join Operator Issue (reposted due to text issues)
I am currently using Designer 11.5.0.0. Itu2019s XI Rel 2, but Iu2019m not sure what service pack. I have created several universes with outer joins against a SQL Server 2005 database, but when I try using them in a Crystal report, I get the following error:
Failed to retrieve date from the database. Details: 42000:[Microsoft][ODBC SQL Server Driver][SQL Server] The query uses non-ANSI outer join operators (u201C=u201D or u201C=u201D). To run this query without modification, please set the compatibility level for current database to 80 or lower, using stored procedure sp_dbcmptlevel. It is strongly recommended to rewrite the query using ANSI outer join operators (LEFT OUTER JOIN, RIGHT OUTER JOIN). In the future versions of SQL Server, non-ANSI join operators will not be supported even in backward-compatibility modes.
Here is my ODBC DSN configuration:
Microsoft SQL Server ODBC Driver Version 03.85.1132
Data Source Name: FlexOPS
Data Source Description:
Server: dalsvrw031
Database: (Default)
Language: (Default)
Translate Character
Data: Yes
Log Long Running Queries: No
Log Driver Statistics: No
Use Integrated Security: No
Use Regional Settings: No
Prepared Statements Option: Drop temporary procedures on disconnect
Use Failover Server: No
Use ANSI Quoted Identifiers: Yes
Use ANSI Null, Paddings and Warnings: Yes
Data Encryption: No
Okay, so I understand what the issue is. It appears that the version of Designer that I am using does not default the ANSI92 parameter to u201CYesu201D. So all the outer joins I have created in each of my universe are using the old *= as the join operator. And apparently, the ODBC driver I am using is not very happy with that.
As I understand it from what Iu2019ve read on other sites, I have the following options:
1) Set the ANSI92 parameter to Yes, drop all my joins, close and re-open Designer, and recreate all of the joins.
2) Find a different driver or connectivity method that will support non-ANSI joins.
3) Set my database back to SQL 2000 compatibility.
Option 1 is unappealing as it will cause a lot of time redoing all the work that Iu2019ve spent the past month doing. Option 2 is only a band-aid fix at best. Option 3 really isnu2019t an option for us.So I am wondering what other options I have to change these non-ANSI joins to ANSI compatible joins. Do I need to update Designer with a service pack? Is there a script out there that will automatically do this in each of the universes? I would appreciate any suggestions or guidance on this.
Thanks,
Lee -
ANSI SQL 92 SYNTAX OUTER JOIN PERFORMANCE ISSUE
Good Morning
Could anyone explain why the excution time for these two (ment to be identical)
queries run so differently.
oracle syntax execution time 1.06 seconds
select COUNT(*) from
PL_EVENT_VIEW pev,
PL_EVENT_STAFF_VIEW pesv
WHERE pev.EVENT_ID=PESV.EVENT_ID(+)
AND pev.WEEKS=PESV.WEEK_NUM(+)
AND pev.event_id=2520
ansi sql 92 syntax execution time 7.05 seconds
select COUNT(*) from
PL_EVENT_VIEW pev
LEFT JOIN PL_EVENT_STAFF_VIEW pesv
ON (pev.EVENT_ID=PESV.EVENT_ID
AND pev.WEEKS=PESV.WEEK_NUM)
WHERE pev.event_id=2520
Thanks
David HillsBTW Oracle outer join operator (+) and ANSI SQL OUTER JOIN syntax are NOT equivalent. Consider following:
DROP TABLE T1;
CREATE TABLE T1 (C1 NUMBER);
DROP TABLE T2;
CREATE TABLE T2 (C2 NUMBER);
DROP TABLE T3;
CREATE TABLE T3 (C3 NUMBER);
-- Following SELECT works:
SELECT COUNT(*)
FROM T1, T2, T3
WHERE C2 = C1
AND C3(+) = C1
COUNT(*)
0
-- But:
SELECT COUNT(*)
FROM T1, T2, T3
WHERE C2 = C1
AND C3(+) = C1
AND C3(+) = C2
AND C3(+) = C1
ERROR at line 4:
ORA-01417: a table may be outer joined to at most one other table
-- However with ANSI syntax:
SELECT COUNT(*)
FROM T1
JOIN T2 ON (C2 = C1)
LEFT JOIN T3 ON (C3 = C1 AND C3 = C2)
COUNT(*)
0 -
ORA-01719: outer join operator (+) not allowed in operand of OR or IN
I am getting the following Error when I tried to execute my Query.
Error : ORA-01719: outer join operator (+) not allowed in operand of OR or IN
select unique t.estblmt_src_typ_id as estblmt_src_typ_id,
t.name as name from estblmt_src_typ t, src_estblmt_unknown_data u, estblmt_src eSrc, estblmt e,
additional_addr aa, country c, src_country_state_region scsr
where
(t.estblmt_src_typ_id=u.estblmt_src_typ_id and
e.state_region_id=scsr.state_region_id and
upper(scsr.code1)='UNKNOWN' and
u.processed_ind = 'N' and
eSrc.Estblmt_Alt_Id = u.estblmt_alt_id and
u.estblmt_src_typ_id = eSrc.estblmt_src_typ_id and
eSrc.Estblmt_Id = e.estblmt_id and
e.country_id = c.country_id and
u.estblmt_element = 'State Region' and
scsr.estblmt_src_typ_id = u.estblmt_src_typ_id and
aa.estblmt_id(+)=e.estblmt_id and
e.end_dt is null) or
(t.estblmt_src_typ_id=u.estblmt_src_typ_id and
aa.state_region_id=scsr.state_region_id and
upper(scsr.code1)='UNKNOWN' and u.processed_ind = 'N' and
eSrc.Estblmt_Alt_Id = u.estblmt_alt_id and
u.estblmt_src_typ_id = eSrc.estblmt_src_typ_id and
eSrc.Estblmt_Id = aa.estblmt_id and aa.country_id = c.country_id and (u.estblmt_element = 'Additional State Code' or u.estblmt_element = 'Additional State Province') and scsr.estblmt_src_typ_id = u.estblmt_src_typ_id
and aa.estblmt_id=e.estblmt_id and e.end_dt is null) order by t.nameFirst, is this query being executed within Apex or at the SQL prompt or in SQL Workshop, or something else? Some context of where it's being executed may help.
Next, that's a query from hell. How about rewrting it to use ANSI join syntax instead, so it'a bit more readable?
A quick example for part of it would be:
FROM (additional_addr aa LEFT OUTER JOIN estblmt e ON aa.estblmt_id = e.estblmt_id )
etc.
Just add additional parenthesis for each additional table join, similar to:
FROM ((additional_addr aa LEFT OUTER JOIN estblmt e ON aa.estblmt_id = e.estblmt_id )
LEFT OUTER JOIN src_country_state_region scsr ON aa.state_region_id = scsr.state_region_id )
In the long run it will make the query a bit more legible, so your where clause only lists the query conditions, not the join conditions. Then it becomes easier to quickly glance at it and see where potential problems may be.
Bill Ferguson -
Outer Join problems - "ORA-30563 outer join operator (+) not allowed in select-list"
Products: Discoverer 4.1.33.0.2
(Admin and User/Plus)
8i EE 8.1.7 (Discoverer server)
8i EE 8.1.5 ('source data' server)
Background assumptions: (1) If a column from an "outer-joined" table is compared to a constant, the outer join operator must be applied to that column in order for the outer join to work. (2) A 'Condition' specified in Discoverer User/Plus manifests as a comparison to a constant.
I created a join in Admin between two folders, selected 'outer join on detail' option. In User/Plus, created worksheet containing columns from the joined folders. When no Conditions are NOT specified, results seem ok. However, when Condition IS added, worksheet encounters "ORA-30563 outer join operator (+) not allowed in select-list" and returns blank sheet.
To workaround, created Custom folder with outer join in place. Didn't work either with Conditions specified. No error, but I think that because Discoverer did not 'outer join' the Condition column, the outer join was ignored.
Any insights, ideas, or workarounds are much appreciated.
-JimIf you build a query that uses an outer join then any items from the potentially deficient side of the join will have (+) appended to them everywhere in the sql. Up until 8.1.7 this was OK in the select list as it was just treated as noise and ignored - However this now fails with ORA-30563:
outer join operator (+) not allowed in select-list...
In 4.1.33.1.6 you get the error 'ORA-30563 outer join operator(+) not allowed in select list'.
In 4.1.36.1.10 the query runs OK.. Your work around I would guess would be to create a custom folder as you suggested. -
How to achieve outer join operator(+) in HQL?
Dear all,
The two tables employee and customer have not explicate association (by FK and PK). In Oracle SQL, we can use the operator (+) as follows for an outer join. For example,
SELECT * FROM employee, customer where employee.name = customer.name(+)
However, HQL does not support this outer join operator. How can we translate the above SQL select to HQL?
Regards.
Pengyoushashi_rajak wrote:
Already posted in [ hibernate forum|https://forum.hibernate.org/viewtopic.php?f=1&t=997869] . This does not have to do with java.
Yes, but I did not get any solution.
Hibernate has something to do with java. You can not say for example java has nothing to do with Internet or Internet has nothing to do with Computer. Anyhow, thanks for your reply. -
Dear All,
Please help me in tuning the below query as it is including the outer join and is going for full table scans.
Query :
SELECT
T27.CONFLICT_ID,
T27.LAST_UPD,
T27.CREATED,
T27.LAST_UPD_BY,
T27.CREATED_BY,
T27.MODIFICATION_NUM,
T27.ROW_ID,
T24.ATTRIB_39,
T27.REMIT_ADDR_ORG_ID,
T27.REMIT_ORG_EXT_ID,
T16.NAME,
T25.ACCNT_TYPE_CD,
T27.RECAL_TAX_SRV_FLG,
T27.PROJ_ID,
T8.PROJ_NUM,
T8.BU_ID,
T5.NAME,
T8.INTEGRATION_ID,
T12.CURCY_CD,
T25.PR_BL_ADDR_ID,
T25.URL,
T27.TTL_INVC_AMT,
T27.INVC_TYPE_CD,
T27.TTL_PD_AMT,
T3.CG_ASSSET_ID,
T17.ASSET_NUM,
T27.VENDR_INVOICE_NUM,
T4.TOT_QTY_SHIP,
T4.TOT_EXTND_PRICE,
T27.ACCNT_ID,
T25.INTEGRATION_ID,
T25.NAME,
T25.BU_ID,
T25.AVAIL_CREDIT_AMT,
T10.NAME,
T27.AGREEMENT_ID,
T4.TOT_EXTND_TAX,
T27.STMT_SOURCE_CD,
T4.SRC_INVLOC_ID,
T27.STATUS_CD,
T4.TOT_QTY_BONUS,
T27.X_DEPOSIT_AMT,
T27.COMMENTS,
T27.INVC_FULLY_PAID_DT,
T26.SEQ_NUM,
T27.ELEMENT_ID,
T26.INSCLM_ID,
T14.INSCLAIM_NUM,
T27.BL_PER_ID,
T27.INS_CLAIM_ID,
T27.FN_ACCNT_ID,
T27.CUSTOMER_REF_NUM,
T27.TTL_NONREC_AMT,
T25.OU_NUM,
T24.ATTRIB_39,
T27.AMT_CURCY_CD,
T2.CCNUM_ENCRPKEY_REF,
T18.PR_DEPOSIT_ID,
T19.DISCNT_RULE_CD,
T27.ORDER_ID,
T4.STATUS_CHG_FLG,
T25.MAIN_PH_NUM,
T25.MAIN_FAX_PH_NUM,
T27.DELINQUENT_FLG,
T15.LOGIN,
T25.PR_POSTN_ID,
T4.ORDER_NUM,
T22.ADDR,
T22.ZIPCODE,
T27.INVC_NUM,
T27.INVC_DT,
T22.COUNTRY,
T22.CITY,
T27.BL_ADDR_ID,
T23.NAME,
T27.POSTED_DT,
T20.NAME,
T27.BL_PERIOD_ID,
T27.GOODS_DLVRD_TS,
T23.NET_DAYS,
T27.PAYMENT_TERM_ID,
T23.DUE_DT,
T27.DUE_DT,
T27.VOID_REASON_TEXT,
T27.DEPT_CD,
T24.ATTRIB_60,
T24.ATTRIB_28,
T21.AMT,
T1.STATE,
T1.ADDR,
T1.ADDR_LINE_2,
T1.COUNTRY,
T1.CITY,
T1.ZIPCODE,
T11.LOGIN,
T21.ROW_ID,
T9.ROW_ID,
T1.ROW_ID,
T13.ROW_ID,
T7.ROW_ID
FROM
SIEBEL.S_ADDR_PER T1,
SIEBEL.S_PTY_PAY_PRFL T2,
SIEBEL.S_INVLOC T3,
SIEBEL.S_ORDER T4,
SIEBEL.S_ORG_EXT T5,
SIEBEL.S_POSTN T6,
SIEBEL.S_PARTY T7,
SIEBEL.S_PROJ T8,
SIEBEL.S_CON_ADDR T9,
SIEBEL.S_ORG_EXT T10,
SIEBEL.S_USER T11,
SIEBEL.S_DOC_QUOTE T12,
SIEBEL.S_ACCNT_POSTN T13,
SIEBEL.S_INS_CLAIM T14,
SIEBEL.S_USER T15,
SIEBEL.S_ORG_EXT T16,
SIEBEL.S_ASSET T17,
SIEBEL.S_ORDER_TNTX T18,
SIEBEL.S_ORG_EXT_TNTX T19,
SIEBEL.S_PERIOD T20,
SIEBEL.S_DEPOSIT_TNT T21,
SIEBEL.S_ADDR_PER T22,
SIEBEL.S_PAYMENT_TERM T23,
SIEBEL.S_ORG_EXT_X T24,
SIEBEL.S_ORG_EXT T25,
SIEBEL.S_INSCLM_ELMNT T26,
SIEBEL.S_INVOICE T27
WHERE
T25.BU_ID = T10.PAR_ROW_ID (+) AND
T26.INSCLM_ID = T14.ROW_ID (+) AND
T27.ELEMENT_ID = T26.ROW_ID (+) AND
T27.LAST_UPD_BY = T15.PAR_ROW_ID (+) AND
T4.QUOTE_ID = T12.ROW_ID (+) AND
T3.CG_ASSSET_ID = T17.ROW_ID (+) AND
T27.BL_ADDR_ID = T22.ROW_ID (+) AND
T8.BU_ID = T5.PAR_ROW_ID (+) AND
T27.PER_PAY_PRFL_ID = T2.ROW_ID (+) AND
T27.REMIT_ORG_EXT_ID = T16.PAR_ROW_ID (+) AND
T27.PROJ_ID = T8.ROW_ID (+) AND
T27.BL_PERIOD_ID = T20.ROW_ID (+) AND
T27.PAYMENT_TERM_ID = T23.ROW_ID (+) AND
T12.BU_ID = T19.PAR_ROW_ID (+) AND
T27.ACCNT_ID = T25.PAR_ROW_ID (+) AND
T27.ORDER_ID = T18.ROW_ID (+) AND
T4.SRC_INVLOC_ID = T3.ROW_ID (+) AND
T27.ORDER_ID = T4.ROW_ID (+) AND
T27.ACCNT_ID = T24.PAR_ROW_ID (+) AND
T18.PR_DEPOSIT_ID = T21.ROW_ID (+) AND
T27.BL_ADDR_ID = T9.ADDR_PER_ID (+) AND
T27.ACCNT_ID = T9.ACCNT_ID (+) AND
T27.BL_ADDR_ID = T1.ROW_ID (+) AND
T25.PR_POSTN_ID = T13.POSITION_ID (+) AND
T25.ROW_ID = T13.OU_EXT_ID (+) AND
T13.POSITION_ID = T7.ROW_ID (+) AND
T13.POSITION_ID = T6.PAR_ROW_ID (+) AND
T6.PR_EMP_ID = T11.PAR_ROW_ID (+) AND
(T27.INVC_TYPE_CD = :1) AND
(T27.DEPT_CD = :2);
Explan Plan Output :
PLAN_TABLE_OUTPUT
Plan hash value: 3132260827
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 1958 | 1896K (11)| 00:50:46 |
| 1 | NESTED LOOPS OUTER | | 1 | 1958 | 1896K (11)| 00:50:46 |
| 2 | NESTED LOOPS OUTER | | 1 | 1922 | 1896K (11)| 00:50:46 |
| 3 | NESTED LOOPS OUTER | | 1 | 1885 | 1896K (11)| 00:50:46 |
| 4 | NESTED LOOPS OUTER | | 1 | 1861 | 1896K (11)| 00:50:46 |
| 5 | NESTED LOOPS OUTER | | 1 | 1849 | 1896K (11)| 00:50:46 |
| 6 | NESTED LOOPS OUTER | | 1 | 1817 | 1896K (11)| 00:50:46 |
| 7 | NESTED LOOPS OUTER | | 1 | 1792 | 1896K (11)| 00:50:46 |
| 8 | NESTED LOOPS OUTER | | 1 | 1771 | 1896K (11)| 00:50:46 |
| 9 | NESTED LOOPS OUTER | | 1 | 1739 | 1896K (11)| 00:50:46 |
| 10 | NESTED LOOPS OUTER | | 1 | 1483 | 1896K (11)| 00:50:46 |
| 11 | NESTED LOOPS OUTER | | 1 | 1451 | 1896K (11)| 00:50:46 |
| 12 | NESTED LOOPS OUTER | | 1 | 1419 | 1896K (11)| 00:50:46 |
| 13 | NESTED LOOPS OUTER | | 1 | 1361 | 1896K (11)| 00:50:46 |
| 14 | NESTED LOOPS OUTER | | 1 | 1276 | 1896K (11)| 00:50:46 |
| 15 | NESTED LOOPS OUTER | | 1 | 1202 | 1896K (11)| 00:50:46 |
| 16 | NESTED LOOPS OUTER | | 1 | 1108 | 1896K (11)| 00:50:46 |
| 17 | NESTED LOOPS OUTER | | 1 | 1087 | 1896K (11)| 00:50:46 |
| 18 | NESTED LOOPS OUTER | | 1 | 1040 | 1896K (11)| 00:50:46 |
| 19 | NESTED LOOPS OUTER | | 1 | 939 | 1896K (11)| 00:50:46 |
| 20 | NESTED LOOPS OUTER | | 1 | 894 | 1896K (11)| 00:50:46 |
| 21 | NESTED LOOPS OUTER | | 1 | 868 | 1896K (11)| 00:50:46 |
| 22 | NESTED LOOPS OUTER | | 1 | 843 | 1896K (11)| 00:50:46 |
| 23 | NESTED LOOPS OUTER | | 1 | 824 | 1896K (11)| 00:50:46 |
| 24 | NESTED LOOPS OUTER | | 1 | 690 | 1896K (11)| 00:50:46 |
| 25 | NESTED LOOPS OUTER | | 1 | 613 | 1896K (11)| 00:50:46 |
| 26 | NESTED LOOPS OUTER | | 1 | 457 | 1896K (11)| 00:50:46 |
|* 27 | TABLE ACCESS FULL | S_INVOICE | 1 | 269 | 1896K (11)| 00:50:46 |
| 28 | TABLE ACCESS BY INDEX ROWID| S_PROJ | 1 | 188 | 1 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | S_PROJ_P1 | 1 | | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | S_PAYMENT_TERM | 1 | 156 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | S_PAYMENT_TERM_P1 | 1 | | 1 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID | S_INSCLM_ELMNT | 1 | 77 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | S_INSCLM_ELMNT_P1 | 1 | | 1 (0)| 00:00:01 |
| 34 | TABLE ACCESS BY INDEX ROWID | S_INS_CLAIM | 1 | 134 | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | S_INS_CLAIM_P1 | 1 | | 1 (0)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | S_PERIOD | 1 | 19 | 1 (0)| 00:00:01 |
|* 37 | INDEX UNIQUE SCAN | S_PERIOD_P1 | 1 | | 1 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | S_USER | 1 | 25 | 2 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | S_ORDER_TNTX | 1 | 26 | 2 (0)| 00:00:01 |
|* 41 | INDEX UNIQUE SCAN | S_ORDER_TNTX_P1 | 1 | | 1 (0)| 00:00:01 |
| 42 | TABLE ACCESS BY INDEX ROWID | S_DEPOSIT_TNT | 1 | 45 | 1 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | S_DEPOSIT_TNT_P1 | 1 | | 1 (0)| 00:00:01 |
| 44 | TABLE ACCESS BY INDEX ROWID | S_ORDER | 1 | 101 | 2 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | S_ORDER_P1 | 1 | | 1 (0)| 00:00:01 |
| 46 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 | 47 | 1 (0)| 00:00:01 |
|* 47 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 | | 1 (0)| 00:00:01 |
| 48 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 | 21 | 1 (0)| 00:00:01 |
|* 49 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 | | 1 (0)| 00:00:01 |
| 50 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_TNTX | 1 | 94 | 1 (0)| 00:00:01 |
|* 51 | INDEX RANGE SCAN | S_ORG_EXT_TNTX_U1 | 1 | | 1 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_PTY_PAY_PRFL | 1 | 74 | 1 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | S_PTY_PAY_PRFL_P1 | 1 | | 1 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 85 | 2 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 58 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | 1 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 256 | 2 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_ACCNT_POSTN | 1 | 32 | 3 (0)| 00:00:01 |
|* 65 | INDEX RANGE SCAN | S_ACCNT_POSTN_U1 | 1 | | 2 (0)| 00:00:01 |
| 66 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 21 | 1 (0)| 00:00:01 |
|* 67 | INDEX UNIQUE SCAN | S_POSTN_U2 | 1 | | 1 (0)| 00:00:01 |
| 68 | TABLE ACCESS BY INDEX ROWID | S_USER | 1 | 25 | 2 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | S_USER_U2 | 1 | | 1 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 2 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
|* 72 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | 12 | 1 (0)| 00:00:01 |
| 73 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 1 | 24 | 2 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | S_ASSET_P1 | 1 | | 2 (0)| 00:00:01 |
| 75 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 1 | 37 | 2 (0)| 00:00:01 |
|* 76 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 1 | | 2 (0)| 00:00:01 |
| 77 | TABLE ACCESS BY INDEX ROWID | S_CON_ADDR | 1 | 36 | 3 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | S_CON_ADDR_U1 | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
27 - filter("T27"."DEPT_CD"=:2 AND "T27"."INVC_TYPE_CD"=:1)
29 - access("T27"."PROJ_ID"="T8"."ROW_ID"(+))
31 - access("T27"."PAYMENT_TERM_ID"="T23"."ROW_ID"(+))
33 - access("T27"."ELEMENT_ID"="T26"."ROW_ID"(+))
35 - access("T26"."INSCLM_ID"="T14"."ROW_ID"(+))
37 - access("T27"."BL_PERIOD_ID"="T20"."ROW_ID"(+))
39 - access("T27"."LAST_UPD_BY"="T15"."PAR_ROW_ID"(+))
41 - access("T27"."ORDER_ID"="T18"."ROW_ID"(+))
43 - access("T18"."PR_DEPOSIT_ID"="T21"."ROW_ID"(+))
45 - access("T27"."ORDER_ID"="T4"."ROW_ID"(+))
47 - access("T4"."SRC_INVLOC_ID"="T3"."ROW_ID"(+))
49 - access("T4"."QUOTE_ID"="T12"."ROW_ID"(+))
51 - access("T12"."BU_ID"="T19"."PAR_ROW_ID"(+))
53 - access("T27"."PER_PAY_PRFL_ID"="T2"."ROW_ID"(+))
55 - access("T27"."BL_ADDR_ID"="T1"."ROW_ID"(+))
57 - access("T27"."BL_ADDR_ID"="T22"."ROW_ID"(+))
59 - access("T8"."BU_ID"="T5"."PAR_ROW_ID"(+))
61 - access("T27"."REMIT_ORG_EXT_ID"="T16"."PAR_ROW_ID"(+))
63 - access("T27"."ACCNT_ID"="T25"."PAR_ROW_ID"(+))
65 - access("T25"."ROW_ID"="T13"."OU_EXT_ID"(+) AND "T25"."PR_POSTN_ID"="T13"."POSITION_ID"(+))
67 - access("T13"."POSITION_ID"="T6"."PAR_ROW_ID"(+))
69 - access("T6"."PR_EMP_ID"="T11"."PAR_ROW_ID"(+))
71 - access("T25"."BU_ID"="T10"."PAR_ROW_ID"(+))
72 - access("T13"."POSITION_ID"="T7"."ROW_ID"(+))
74 - access("T3"."CG_ASSSET_ID"="T17"."ROW_ID"(+))
76 - access("T27"."ACCNT_ID"="T24"."PAR_ROW_ID"(+))
78 - access("T27"."BL_ADDR_ID"="T9"."ADDR_PER_ID"(+) AND "T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
filter("T27"."ACCNT_ID"="T9"."ACCNT_ID"(+))
117 rows selected.
We are using 10.2.0.3 oracle version.Hi
according to the explain plan, > 99% of the cost of the query is coming from a single operation -- step 27, full scan of S_INVOICE table.
This probably means that there are no usable indexes on DEPT_CD and/or INVC_TYPE_CD.
So start by tuning SELECT * FROM S_INVOICE T27 WHERE ("T27"."DEPT_CD"=:2 AND "T27"."INVC_TYPE_CD"=:1)
BTW the plan shows that 1 row is to be returned, while Oracle actually returns 117 -- this means that the optimizer estimates are not very reliable here.
Best regards,
Nikolay -
ORA-01719: outer join operator (+) not allowed in operand of OR
Hi all:
I understand the error, but I'm not sure how to fix my query. In our database, a person does not NEED to have an address. The report I'm trying to create has a parameter for which address the user would like to have displayed. BUT, I need to outer join to the address table since people don't need an address, but we'd want to display all records, even if the address is null. Here's only part of my code since the query is quite large. Let me know if more is needed, and I'll supply it. I'm definately stuck. At this point I'm thinkin' of just creating two reports; one that displays the clients address, and a second that'll display the house physical address. The code:
WHERE
:P_ADDR = 'Lessee Mailing Address' AND
lessee.actor_inst = address.actor_inst (+)
) OR (
:P_ADDR = 'Unit Address' AND
housing.actor_inst = address.actor_inst (+)
) ANDStick with ANSI SQL Notation, then you can overcome this restriction.
See Back to basics: outer joins
and look for »ORA-01719« -
I am on Oracle 10g.
I believe the following two statements are equivalent.
This statement returns the correct results
select k.key, NVL(v.value, k.en_value) as lvalue
from sku_key k, sku_key_value v
WHERE k.id_sku_key = v.id_sku_key (+)
and k.id_sku_key = 5
and v.id_sku_language (+) = 33;
This statement returns no results (however, if I remove the line "and v.id_sku_language = 33" then results are returned, just not the correct results).
select k.key, NVL(v.value, k.en_value) as lvalue
from sku_key k LEFT JOIN sku_key_value v ON k.id_sku_key = v.id_sku_key
where k.id_sku_key = 5
and v.id_sku_language = 33;
What needs to be done to the ANSI JOIN statement to make it equivalent to the (+) join statement?
Thanks,
JohnThis change fixes the problem:
select k.key, NVL(v.value, k.en_value) as lvalue
from sku_key k
LEFT JOIN sku_key_value v ON (k.id_sku_key = v.id_sku_key
and (v.id_sku_language = 33
or v.id_sku_language is null))
where k.id_sku_key = 5 -
Toplink outer join issue using ExpressionBuilder getAlllowingNull
I am trying to retrieve some records through a Toplink outer join expression using ExpressionBuilder's getAllowingNull() with an IN clause but I don't get the correct results.
In my setup I have the following structure
CREATE TABLE BOX
MY_BOX_ID NUMBER(10) PRIMARY KEY
, MY_CODE VARCHAR2(30) NOT NULL CONSTRAINT u_code UNIQUE
CREATE TABLE ITEM
MY_ITEM_ID NUMBER(10) PRIMARY KEY
,MY_TYPE NUMBER(6) NOT NULL
,BOX_ID REFERENCES BOX(MY_BOX_ID)
INSERT INTO BOX values (1, '001');
INSERT INTO ITEM values (1, 1, 1);
INSERT INTO ITEM values (2, 1, null);
The Toplink mappings are the most common ones and the code that retrieves the results is
Vector vals = new Vector();
vals.add(new String('001'));
Vector dbList = null;
try
DatabaseSession dbSession = getToplinkSession();
ReadAllQuery query = new ReadAllQuery();
query.setReferenceClass(Item.class);
ExpressionBuilder expBuilder = new ExpressionBuilder();
Expression exp = expBuilder.getAllowingNull("Box").get("myCode").in(vals);
query.setSelectionCriteria(exp);
dbList = (Vector) dbSession.executeQuery(query);
catch(Exception e)
e.printStackTrace();
When I run the piece of code Toplink generates the following DB query
SELECT t1.MY_ITEM_ID, t1.MY_TYPE FROM BOX t0, ITEM t1 WHERE ((t0.MY_CODE IN ('001')) AND (t0.MY_BOX_ID (+) = t1.BOX_ID))
which returns just the record for which the foreign key is not null
MY_ITEM_ID MY_TYPE
1 1
However I would have expected to get back two records including the one where the foreign key box_id is null. That have happened if the generated SQL would have been:
SELECT t1.MY_ITEM_ID, t1.MY_TYPE FROM BOX t0, ITEM t1 WHERE ((t0.MY_CODE (+) IN ('001')) AND (t0.MY_BOX_ID (+) = t1.BOX_ID))
with the outer join operator applied to the query key as well.
I was wondering if someone could provide some advice on how to get the correct result.
Thanks for any help,
LucianHello,
Calling builder.getAllowingNull("name_of_field_in_MyJDO"); returns an expression that is not used anywhere in the following code, and so it is not used in the query.
The addJoinedAttribute(String) on ReadAllQuery will make a simple join expression using the String as the query key. If you want to use an outerJoin instead of the simple inner join created, try:
readAllQry.addJoinedAttribute(builder.getAllowingNull("name_of_field_in_MyJDO"));
instead. You will also want to remove any joining statements added at the mapping level made in trying to get this to work, otherwise the inner join specified though those options will still be used.
Best Regards,
Chris -
Left Outer Joining multiple tables to one source table FAILS with VLD-1511
Hi all,
Is it me, or is OWB unable to handle left outer joining 1 source table to multiple other tables?
I want to load a fact table so I have 1 source table with measures. This table must be outer joined to some dimensions that have their FK in the fact table.
The SQL statement would look like this (and is perfectly valid):
select ...
from input, dim1, dim2
where input.c1 = dim1.c1(+)
and input.c2 = dim2.c2(+);
I put the where clause in the joiner operator and validate, but that gives me message VLD-1511: A table may be outer joined to at most one other table.
Even splitting this up into one outer join per joiner still gives this message.
A search and look around on the forum and on metalink shows there are related issues (like bug 3334035). Seemingly creating a view is the work-around to use.....? (ie downgrading owb to a simple gui tool) }-;
Have other people experienced this problem of not being able to outer join one input table to multiple other tables?
Thanks,
EdI have had some feedback from Oracle. It turns out this has to do with 2 issues. Below I have pasted the text that Support gave me:
<---------- START QUOTE ---------->
RESEARCH
=========
Bug 3437036 KEY LOOKUP DOES NOT DETECT ORA-1417 IN VALIDATE/GENERATE STEP
Unpublished Bug 4211684 FORWARD PORT OF BUG 3437036
shows:
Some more development has been completed when this bug is fixed in Paris.
The following are the details:
1. If the join condition contains a full outer join such as
tab1.c (+) = tab2.c (+) and tab2.c (+) = tab3.c
then the new validations implemented for this bug do not apply since
in OWB, full outer join triggers generation of joins in ANSI syntax.
ANSI syntax does not have the original problem the base bug of this
bug reported.
2. If the join condition does not contain any full outer join condition,
then the join is generated in Oracle join syntax, which is subject two
several restrictions. The fix to this bug check two of the restrictions.
3. The first restriction in Oracle syntax is that the outer join operator
"(+)" can only directly be attached to a column name. If you attach it
to an expression, such as the following:
(tab1.c + 1) (+) = tab2.c
Then there will be an ORA-936 error at the time of mapping deployment.
For this case, I have added a validation message VLD-1512 to error out
this situation.
4. The second restriction in Oracle syntax is that a table can only be
outer joined to exactly one other table.
For example, this is an invalid join in Oracle syntax:
tab1.c (+) = tab2.c and tab1.d (+) = tab3.d
because tab1 is left outer joined to tab2 and tab3.
But note that the following is still valid in Oracle syntax:
tab1.c (+) = tab2.c and tab1.d = tab3.d (+)
because tab1 is left outer joined to tab2 and right outer joined to tab3.
So this latter case does not violate the restriction that "same oj" to
more than 1 table is not allowed.
If same oj to more than 1 table is specified in a join condition,
VLD-1511 will be issued, and the map is made invalid.
<---------- END QUOTE ---------->
OWB does a partial validation, ie not all access paths are (can be) checked. A full check is only done by the database itself. So some scenarios (like checking whether multiple tables are outer joined the correct way) are not checked, and in this case are flagged with an error (even though it is actually a correct scenario).
Seemingly this was not flagged with an error in earlier versions of OWB, so beware, OWB behaviour may change when upgrading...
Alternative solutions are (1) using key lookups, (2) using a view with all outer joins in there, (3) using intermediate result tables between the joins.
Hope this info helps some people prevent spending too much time on a false error message,
Ed -
ORA-30563, Outer Join not allowed in select list
I can not find any information about this error message that I am getting.
I have just upgraded my Oracle database from Version 7.3 to Version 8.1.7, a stored procedure that was written in v7.3 has outer joins in the select statement.
when trying to run this proc in version 8 I get this meesage.(ORA-30563, Outer Join not allowed in select list)
code ex:
Select alt.id
decode(alt.advise, NULL, NULL, AA.act_yr(+))||'-'||AA.act_per(+)||'-'||AA.Acc_per_no(+)) as advise_no
from alt, AA;
Is there any information about this message anywhere? or does anybody know if this is a known issue with oracle ver 8.1.7?
Thanks
CJIt appears to have been a bug in 7.x
From a metalink note on bugs fixed in 8i (doc 132632.1)
974742 Oracle does not report an error if (+) is specified in select-list. The OUTER JOIN operator (+) is only valid in WHERE clause predicates. As this is not flagged as an error the query can give unexpected results. The correct action to avoid this problem is to fix the query.
Ken -
Internal Assertion Error while using outer join
Hi-
Has anyone experienced this error before: State: HY000. Code: 397397248. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 46036] Internal Assertion: Condition !pConjunct->IsAndCond(), file server/Query/Optimizer/Request/Src/SQORToCNF.cpp, line 46. (HY000)
It happened after I changed the join in logical layer from inner join into left outer join from Fact Tab1 to Fact Tab2, This needs to be changed for cases:
Fact Tab1 contains:
Period|Currency|FX Rate
Mar-09|USD|1
Apr-09|USD|1.1
Fact Tab2 contains:
Period|Currency|Product|Profit
Mar-09|USD|Metal Abs|1000
Mar-09|USD|Grey Wood|2000
Expected Result:
Period|Currency|Product|Profit|FX Rate
Mar-09|USD|Metal Abs|1000|1
Mar-09|USD|Grey Wood|2000|1
Apr-09|USD|(NULL)|(NULL)|1.1
But, it shows the error as above (have changed the SERVER_THREAD_STACK_SIZE to 512 KB too but no luck, any idea?
Thanks,
WillHey Will,
Recently I've seen OBIEE generate some bad queries on an Oracle Database. I had setup a few time series measures and when I added more than three into a report, I got a table not found error. It turned out that it was a combination of the query getting very complex and the way it was using ANSI SQL Left Outer Join operator. I'm wondering if your situation is similar.
Can you try the following?
1. Log into the RPD and for your user, set the logging level to 7 (Manage->Security then find your user).
2. Clear all the caches (BI Server=Manage->Cache delete them all, Presentation Server=Settings->Manage Sessions then close all cursors)
3. Run the report for a date range that works fine
4. Run the report for a date range that causes the error.
5. Look at the physical SQL generated in the log files (Settings->Manage Sessions)
Compare the two queries and see if anything stands out. In fact try to execute both in SQL Developer or Toad and see if you get any errors. If you can, post the physical SQL and I might be able to notice something.
Just to confirm, you're using OCI to connect to an Oracle source right?
In my situation, I fixed it by disabling the LEFT OUTER JOIN syntax on the database. We might be able to get you to do something similar to fix your problem.
Thanks!
-Joe -
Not using Index when SDO_RELATE in Spatial Query is used in LEFT OUTER JOIN
I want to know for every City (Point geometry) in which Municipality (Polygon geometry) it is.
Some cities will not be covered by any municipality (as there is no data for it), so its municipality name should be blank in the result
We have 4942 cities (point geometries)
and 500 municipalities (polygon geometry)
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1
LEFT OUTER JOIN MUNICIPALITY T2 ON SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'The explain plan for this query is:
SELECT STATEMENT
FILTER
Filter Predicates
MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'
MERGE JOIN
TABLE ACCESS CITY FULL 11
BUFFER SORT 100605
TABLE ACCESS MUNICIPALITY FULL 20So the cost is in the BUFFER (whatever that is), it takes +2000 seconds to run this, it is not using the spatial index.
And we are not getting all rows, but only the ones interacting with a municipality, e.g. 2436 rows.
But I want all rows, including the ones not interacting with any Municipality.
When we want only those cities that actually are in a municipality, I use a different query and it will use the index.
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1, MUNICIPALITY T2
WHERE SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'I get (only) 2436 rows (as expected) in 5 seconds (it is fast) and the explain plan shows it is using the spatial index.
But in this case, I am not getting any cities not inside any municipality (of course)
SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS MUNICIPALITY FULL 22
TABLE ACCESS CITY BY INDEX ROWID 22
DOMAIN INDEX CITY_SDX 0
Access Predicates
MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'I always thought a LEFT OUTER JOIN would return all rows from the Table, whatever happens in the next,
but it seems the query has been rewritten so that it is now using a Filter Predicate in the end, which filters those geometries having no interaction.
As an example I also do thing alphanumerically, I do get 4942 rows, including the ones which have no Municipality name.
In this case the names must match, so its only for testing if the LEFT OUTER JOIN returns stuff correctly, which it does in this case.
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1
LEFT OUTER JOIN MUNICIPALITY T2 ON T1.NAME = T2.NAMEIs this an Oracle Spatial bug, e.g. not return 4942 rows, but only 2436 rows on the first query?
Note all tests performed on Oracle 11g R2 (11.2.0.1.0)Patrick,
Even so, your geoms in the relate were the wrong way around.
Also, I don't recall you saying (or showing) that you wanted the municipality geometry returned. Still,
no matter, easy to do.
Here are some additional suggestions. I don't have your data so I have had to use some of my own.
set serveroutput on timing on autotrace on
SELECT T1.SPECIES as City,
(SELECT T2.ADMIN_NAME FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as Municipality,
(SELECT T2.GEOM FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as geom
FROM GUTDATA T1;
762 rows selected
Elapsed: 00:00:21.656
Plan hash value: 2160035213
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 762 | 49530 | 5 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES | 1 | 115 | 0 (0)| 00:00:01 |
|* 2 | DOMAIN INDEX | AUSTRALIAN_STATES_GEOM_SPX | | | 0 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES | 1 | 115 | 0 (0)| 00:00:01 |
|* 4 | DOMAIN INDEX | AUSTRALIAN_STATES_GEOM_SPX | | | 0 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL | GUTDATA | 762 | 49530 | 5 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
Statistics
7 user calls
24576 physical read total bytes
0 physical write total bytes
0 spare statistic 3
0 commit cleanout failures: cannot pin
0 TBS Extension: bytes extended
0 total number of times SMON posted
0 SMON posted for undo segment recovery
0 SMON posted for dropping temp segment
0 segment prealloc tasksThe above can look messy as you add more (SELECT ...) attributes, but is is fast (though can't use in Materialized Views).
/* The set of all cities not in municipalities */
SELECT T1.SPECIES as City,
cast(null as varchar2(42)) as municipality,
cast(null as sdo_geometry) as geom
FROM GUTDATA T1
WHERE NOT EXISTS (SELECT 1
FROM AUSTRALIAN_STATES T2
WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
UNION ALL
/* The set of all cities in municipalities */
SELECT T1.SPECIES as City,
T2.ADMIN_NAME as Municipality,
T2.GEOM as geom
FROM GUTDATA T1
INNER JOIN
AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
762 rows selected
Elapsed: 00:00:59.953
Plan hash value: 2854682795
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 99 | 13450 | 38 (87)| 00:00:01 |
| 1 | UNION-ALL | | | | | |
|* 2 | FILTER | | | | | |
| 3 | TABLE ACCESS FULL| GUTDATA | 762 | 49530 | 5 (0)| 00:00:01 |
|* 4 | DOMAIN INDEX | AUSTRALIAN_STATES_GEOM_SPX | | | 0 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 61 | 10980 | 33 (0)| 00:00:01 |
| 6 | TABLE ACCESS FULL| AUSTRALIAN_STATES | 8 | 920 | 3 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL| GUTDATA | 8 | 520 | 4 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter( NOT EXISTS (SELECT 0 FROM "AUSTRALIAN_STATES" "T2" WHERE "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE'))
4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
7 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
Statistics
7 user calls
131072 physical read total bytes
0 physical write total bytes
0 spare statistic 3
0 commit cleanout failures: cannot pin
0 TBS Extension: bytes extended
0 total number of times SMON posted
0 SMON posted for undo segment recovery
0 SMON posted for dropping temp segment
0 segment prealloc tasksMuch slower but Materialized View friendly.
This one is a bit more "natural" but still slower than the first.
set serveroutput on timing on autotrace on
/* The set of all cities in municipalities */
WITH municipal_cities As (
SELECT T1.ID as City,
T2.ADMIN_NAME as Municipality,
T2.GEOM as geom
FROM GUTDATA T1
INNER JOIN
AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
SELECT T1.ID as City,
T2.Municipality as Municipality,
T2.GEOM as geom
FROM GUTDATA T1
LEFT OUTER JOIN
municipal_cities T2
ON (T2.CITY = T1.ID);
762 rows selected
Elapsed: 00:00:50.228
Plan hash value: 745978991
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 762 | 44196 | 36 (3)| 00:00:01 |
|* 1 | HASH JOIN RIGHT OUTER| | 762 | 44196 | 36 (3)| 00:00:01 |
| 2 | VIEW | | 61 | 3294 | 33 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 61 | 10980 | 33 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL | AUSTRALIAN_STATES | 8 | 920 | 3 (0)| 00:00:01 |
|* 5 | TABLE ACCESS FULL | GUTDATA | 8 | 520 | 4 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN| GUTDATA_ID_PK | 762 | 3048 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("T2"."CITY"(+)="T1"."ID")
5 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
Statistics
7 user calls
49152 physical read total bytes
0 physical write total bytes
0 spare statistic 3
0 commit cleanout failures: cannot pin
0 TBS Extension: bytes extended
0 total number of times SMON posted
0 SMON posted for undo segment recovery
0 SMON posted for dropping temp segment
0 segment prealloc tasksFinally, the Pièce de résistance: trick the LEFT OUTER JOIN operator...
set serveroutput on timing on autotrace on
SELECT T1.SPECIES as City,
T2.ADMIN_NAME as Municipality,
T2.GEOM as geom
FROM GUTDATA T1
LEFT OUTER JOIN
AUSTRALIAN_STATES T2
ON (t2.admin_name = to_char(t1.ID) OR
SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
762 rows selected
Elapsed: 00:00:50.273
Plan hash value: 158854308
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 762 | 92964 | 2294 (1)| 00:00:28 |
| 1 | NESTED LOOPS OUTER | | 762 | 92964 | 2294 (1)| 00:00:28 |
| 2 | TABLE ACCESS FULL | GUTDATA | 762 | 49530 | 5 (0)| 00:00:01 |
| 3 | VIEW | | 1 | 57 | 3 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL| AUSTRALIAN_STATES | 1 | 115 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("T2"."ADMIN_NAME"=TO_CHAR("T1"."ID") OR
"MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
Statistics
7 user calls
0 physical read total bytes
0 physical write total bytes
0 spare statistic 3
0 commit cleanout failures: cannot pin
0 TBS Extension: bytes extended
0 total number of times SMON posted
0 SMON posted for undo segment recovery
0 SMON posted for dropping temp segment
0 segment prealloc tasksTry these combinations to see what works for you.
Interestingly, for me, the following returns absolutely nothing.
SELECT T1.SPECIES as City,
T2.ADMIN_NAME as Municipality
FROM GUTDATA T1
LEFT OUTER JOIN
AUSTRALIAN_STATES T2
ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
MINUS
SELECT T1.SPECIES as City,
T2.ADMIN_NAME as Municipality
FROM GUTDATA T1
LEFT OUTER JOIN
AUSTRALIAN_STATES T2
ON (t2.admin_name = to_char(t1.ID) OR
SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');(I leave it to you to see if you can see why as the LEFT OUTER JOIN seems to be working correctly for me but I am not going to dedicate time to detailed checking of results.)
Note all tests performed on Oracle 11g R2 (11.2.0.1.0)
If you get the answer you want: mark the post as answered to assign points.
regards
Simon -
Full outer join Bug or my misunderstanding?
CREATE GLOBAL TEMPORARY TABLE BP_ATTRIBUTE_CHARVAL_GTT
( "ATTRIBUTE_ID" NUMBER(10,0),
"PARTNER_ID" NUMBER(10,0),
"CHAR_VALUE" VARCHAR2(4000 BYTE),
"LAST_UPDATE_DATE" DATE,
"DISABLE_DATE" DATE
) ON COMMIT DEETE ROWS ;
CREATE TABLE BP_ATTRIBUTE_CHARVAL
( "ATTRIBUTE_ID" NUMBER(10,0),
"PARTNER_ID" NUMBER(10,0),
"CHAR_VALUE" VARCHAR2(4000 BYTE),
"LAST_UPDATE_DATE" DATE,
"DISABLE_DATE" DATE
REM INSERTING into BP_ATTRIBUTE_CHARVAL
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (888854,710326,'1',to_date('29-NOV-06','DD-MON-RR'),to_date('01-JAN-06','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591330,710326,'01',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591321,710326,'N',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591331,710326,'00',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591329,710326,'01',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591332,710326,'01',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591324,710326,'2',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591333,710326,'01',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591323,710326,'X1',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591334,710326,'BS',to_date('09-FEB-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
REM INSERTING into BP_ATTRIBUTE_CHARVAL_GTT
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591330,707408,'01',to_date('29-MAR-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591321,707408,'N',to_date('23-JAN-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591331,707408,'00',to_date('23-JAN-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591329,707408,'01',to_date('23-JAN-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591332,707408,'00',to_date('29-MAR-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591324,707408,'2',to_date('29-MAR-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591333,707408,'01',to_date('23-JAN-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591323,707408,'X1',to_date('23-JAN-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (591334,707408,'BS',to_date('23-JAN-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (876570,707408,'01',to_date('29-MAR-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT (ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (876568,707408,'1234560003264801',to_date('29-MAR-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (876569,707408,'f3a1d996-720e-4e0a-989c-6d4f3e8e629a',to_date('29-MAR-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
Insert into BP_ATTRIBUTE_CHARVAL_GTT(ATTRIBUTE_ID,PARTNER_ID,CHAR_VALUE,LAST_UPDATE_DATE,DISABLE_DATE) values (874948,707408,'20060318000000',to_date('29-MAR-06','DD-MON-RR'),to_date('07-NOV-01','DD-MON-RR'));
select 707408,
decode(g.attribute_id,NULL,c.attribute_id,g.attribute_id) attribute_id,
case
when c.last_update_date is null and g.last_update_date is not null
then
g.char_value
when g.last_update_date is null and c.last_update_date is not null
then
c.char_value
when g.last_update_date >= c.last_update_date
then
g.char_value
else
c.char_value
end char_value,
decode(g.last_update_date,c.last_update_date,g.last_update_date,c.last_update_date) last_update_date,
decode(g.disable_date,c.disable_date,g.disable_date,c.disable_date) disable_date
from bp_attribute_charval_gtt g
full outer join
bp_attribute_charval c
on c.attribute_id = g.attribute_id
where c.partner_id=710326;Hi Guys
When I run the above query I get a problem.
I am expecting to see is a merge of all the attribute_id's and their values.
The query does not appear to be merging the data as intended.
My understanding of the full outer join is that its a combination of left and outer joins,
so the above query is intended to return with the total number of unique attributes
and their appropriate values
a) I have a bug in the Sql
b) This is an oracle bug
c) My understanding is incorrect
Please Help
Message was edited by:
Keith Jamieson (fixed insert statements for gtt )How do you expect a full outer join operation when you have given --
where c.partner_id=710326;According to your supplied data - i don't think your query can perform that full outer join operation because of that filtration. Just remove that last condition and checked it. You will get your desired result - hopefully.
"It's like you want to view the things by closing down your both eyes". Do you think it will pay?
Regards.
Satyaki De.
Maybe you are looking for
-
Need table name where SRM stores POs and Contracts
I need SRM tables where data for PO and Contract is stored (similar to EKPO, EKKN etc.). We will be using SRM 7/
-
Hello everyone. We are having production problem and need to fix. If anyone has run into this problem can you please post ASAP we need to resolve...... our shipping is being held up. When we run this specific program we keep on getting: The exceptio
-
Hi all, We are doing RFC->XI(BPM)->File scenarios. When we test the scenario with the same input and sometimes it works fine. But in some case we are getting a "Scheduled" status in the 'Monitor for processed XML messages(sxmb_moni)' . Ex if we test
-
When I import raw files from my Nikon D600 into Aperture I get a tryangle sign with "unsupported image format"
-
Safari won't work and won't uninstall.
I downloaded Safari 7 to my 2009 Macbook OS X, but when I tried to open it it wouldn't work with my computer. After searching for hours I finally downloaded Firefox on another computer and transferred it with a flash drive. But I still can't get Safa