Outer Join Performance Issue

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

Similar Messages

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 Hills

BTW 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

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

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

Performance Issue while Joining two Big Tables

Hello Experts,
We've the following Scenario, wherein we need to have Sales rep associated for a Sales Order. This information is available in VBPA table with Sales Order, Sales Order Item and Partner Function being the key.
NOw I'm interested in only one Partner Function for e.g. 'ZP'. This table is having around 120 million records.
I tried both options:
Option 1 - Join this table(VBPA) with Sales Order Item table(VBAP) within the Data Foundation Layer of the Analytic View and doing the filtering on Partner Function
Option 2 - Create a Attribute View for VBPA having filtering on Partner Function and then join this Attribute View in the Logical Join Layer with the Data Foundation table.
Both these options are killing the performance.
Is there any way out to achieve this ?
Your expert opinion is greatly appreciated!!
Thanks & regards,
Jomy

Hi,
Lars is correct. You may have to spend a little bit more time and give a bigger picture.
I have used this join. It takes about 2 to 3 seconds to execute this join for me. My data volume is less than yours.
You must be have used a left outer join when joining the attribute view (with constant filter ZP as specified in your first post) to the data foundation. Please cross check once again, as sometimes my fat finger inadvertently changed the join type and I had to go back and fix it. If this is a left outer join or a referential join, HANA does not perform the join if you are not requesting any field from the attribute view on table VBPA. This used to be a problem due to a bug in SP4 but got fixed in SP5.
However, if you have performed this join in the data foundation, it does enforce, the join even if you did not ask any fields from the VBPA table. The reason being that you have put a constant filter ZR (LIPS->VBPA join in data foundation as specified in one of your later replies).
If any measure you are selecting in the analytic view is a restricted measure or a calculated measure that needs some field from VBPA, then the join will be enforced as you would agree. This is where I had most trouble. My join itself is not bad but my business requirement to get the current value of a partner attribute on a higher level calculation view sent too much data from analytic view to calculation view.
Please send the full diagram of your model and vizplan. Also, if you are using a front end (like analysis office), please trap the SQL sent from this front end tool and include it in the message. Even a straight SQL you have used in which you have detected this performance issue will be helpful.
Ramana

Issues with limit/filter on outer join table in BQY

I'm converting a series of BQY's from Brio 6.6 to Hyperion 9.3. I have some questions about the "use ODBC outer join syntax on limits" option in the OCE. I sort of understand this option's purpose, but I don't completely understand the SQL I'm seeing. For example Brio 6.6 is generating the following SQL statement:
SELECT * FROM tblA AL1 LEFT OUTER JOIN tblB AL38 ON (AL38.ParentID=AL1.ChildID AND
AL38.Data='SomeData') WHERE ((NOT AL38.Action IS NULL))
Now, Hyperion 9.3 generated the SQL statement as follows:
SELECT * FROM tblA AL1 LEFT OUTER JOIN tblB AL38 ON (AL38.ParentID=AL1.ChildID AND
AL38.Data='SomeData') AND (NOT AL38.Response IS NULL))
My questions are:
1) Why isn't the "NOT AL38.Action IS NULL" statement included in the outer join in Brio? My limited understanding of the "use ODBC outer join syntax on limits" seems to indicate that it should end up there. I want the SQL to look like this, but I don't know why Brio generates this SQL.
2) How can I get Hyperion to generate the same SQL as Brio? And still use the OCE with "use ODBC outer join syntax on limits" selected?

Setting the Cardinality of Department > Employee role to OptionalOne
gives rise to cartesian join (which is a bigger issue).
Therefore, the Cardinality of Department > Employee role should remain as
OptionalMany (default).
This means, the outer join problem still remains unsolved. I have, therefore,
unmarked the above answer by me.
The question is - why has Report Builder been designed in such a way that the primary entity is always the child entity when attributes are selected from both parent and child entities?
Most people desire that all the rows of the parent entity be fetched irrespective of whether there are corresponding rows in the child entity or not. Report Builder tool should not dictate what the user wants to get, meaning it is not right to assume
that the focus of the report is Employee when attributes are selected from both Department and Employee. Report Builder should not make the child entity (i.e., Employee) as the primary entity when the user selects attributes from the child entity after
having selected attributes from the parent entity.
I am sorry to say that clients may not accept the Report Builder tool as this does not fetch the records as desired.
I hope there is someone who can suggest how the outer join problem can be solved by just tweaking the properties of the report model (SMDL).
Besides, the end users are business users and are not tech savvy. They are not expected to modify queries. They would simply drag and drop attributes from entities to create adhoc reports.

Performance Tunning - Connect By and Outer Join Used - Urgent

Hi,
I have written a query with the outer join and connect by prior since to establish the parent child relation ship.
All the tables having 2 lakhs record but the final result set is 20 thousand rows.
The query is taking 5 minutes to complete the execution. How could i improve the performance.
The query is
SELECT
'ABC' hrchy_id,
SUBSTR(c.abc_cd,1,1) ,
a.org_no bu_node_id,
SUBSTR(d.abc_cd,1,1) ,
a.prnt_org ,
level hrchy_lvl_nb,
a.eff_from_dt,
a.eff_to_dt,
FROM ((parent a INNER JOIN f_org b ON (a.org_no = b.org_no))
left join org c on ( (a.org_no = (c.abc_cd)))
) left join org d on ( (a.prnt_org = d.abc_cd)))
WHERE a.co_cd ='000'
START with a.prnt_org = '0'
CONNECT BY a.prnt_org = PRIOR a.org_no
ORDER SIBLINGS BY a.org_no;
Please suggest any idea or commands to improve the performance.
Thanks in advance.

Can you provide the structure of tree based SQL.
Thanks in advance.But you have it already :-)
SELECT
'ABC' hrchy_id,
a.org_no bu_node_id,
a.prnt_org ,
level hrchy_lvl_nb,
a.eff_from_dt,
a.eff_to_dt,
FROM parent a WHERE a.co_cd ='000'
START with a.prnt_org = '0'
CONNECT BY a.prnt_org = PRIOR a.org_no
ORDER SIBLINGS BY a.org_no;Regards
Dmytro

Outer join issue

Hi all,
I have a question regarding to Outer joins. This is my situation:
Sales (fact table)
id_company
id_product
yearmonth
units
dollars
Products (dimension table)
id_company
id_product
The 2 tables joins by id_company and id_product.
For a month, I need to get the units and dollars of all the products, if a product is not sold in that month the units and dollars will be zero.
The following query doesn't retrieve the correct results, because a product that is not sold in a month could be in another.
select
p.id_company, p.id_product, sum(s.units), sum(dollars)
from
products p, sales s
where
p.id_company = s.id_company(+)
and p.id_product = s.id_product(+)
and s.yearmonth = 200805
group by p.id_company, p.id_product
So this query gives the correct results:
select
p.id_company, p.id_product, sum(s.units), sum(dollars)
from
products p,
(select * from sales where yearmonth = 200805) s
where
p.id_company = s.id_company(+)
and p.id_product = s.id_product(+)
group by p.id_company, p.id_product
My question is, how can I implement the 2nd query in OBI? Is there an easier way to perform the select without sub-select?
Thanks in advance.

You need to bring in the yearmonth from the product table itself for this to work.
e.g. if you product has 100 rows and you have 10 yearmonths, then your new product table will have 100*10 = 1000 rows. You can achieve this by snowflaking in physical layer (time --> product on 1=1 complex join) . keep the time-fact join in physical layer.
(If you don't want above, then create a view in db or physical layer with time full outer join product and joinng the resultant view to fact on yearmonth, id_companyand id_product )
Then bring the yearmonth column in product logical table in the same LTS with outer join specified.
In answers, use p.id_company, p.id_product, sum(s.units), sum(dollars)where p.yearmonth is filtered.

Outer Join issue in SSRS

Symptom description:
I have a Department table and an Employee table. In Department table, Deptno is the primary key. In Employee table, Empid is the primary key and Deptno is a foreign key pointing to Deptno of Department table.
Using BIDS, I have created a Data Source View (DSV) incorporating the above two tables and a relationship is also formed where Employee is the source and Department is the destination. I have then autogenerated a Report Model (.smdl) using the DSV.
Now, when I select attributes from both Department entity and Employee entity in Report Builder 3.0, the query generated by Report Builder fetches only those records from Department for which an employee exists.
My objective is to fetch all records from Department when Department is joined with Employee irrespective of whether an employee exists or not for that department. How can this be achieved?
Given below is the query generated by Report Builder:
SELECT DISTINCT
    "DEPT"."DepartmentNo" "DepartmentNo",
    "DEPT"."DepartmentDepartmentName" "DepartmentDepartmentName",
    "DEPT"."City" "City",
    "EMP"."EMPID" "EmployeeID",
    "EMP"."EMP_NAME" "EmployeeName",
    "EMP"."SALARY" "Salary"
FROM
    "CLINICOPIA_REPORTS"."EMP" "EMP"
    LEFT OUTER JOIN (
        SELECT /*+ NO_MERGE */
            "DEPT"."DEPTNO" "DepartmentNo",
            "DEPT"."DEPT_NAME" "DepartmentDepartmentName",
            "DEPT"."CITY" "City",
            "DEPT"."DEPTNO" "DEPTNO"
        FROM
            "CLINICOPIA_REPORTS"."DEPT" "DEPT"
    ) "DEPT" ON "EMP"."DEPTNO" = "DEPT"."DEPTNO"
WHERE
    CAST(1 AS NUMERIC(1,0)) = 1
ORDER BY
    "DepartmentNo", "DepartmentDepartmentName", "City", "EmployeeID", "EmployeeName", "Salary";
Environment: SharePoint 2010 serves as the Web Front-End Server and also hosts Reporting Services Add-in. SQL Server 2008 R2 SP2 is the Back-End Server hosting Sql Server Reporting Services
(SSRS) in SharePoint Integrated mode. The data is fetched in the Report Builder 3.0 reports from an Oracle database.
Environment details-
Web Front-End Server: SharePoint Server 2010 with Enterprise Client Access License features. Operating System is Microsoft Windows Server 2008 R2 Standard - 64 Bit.
Back-End Database Server: SQL Server 2008 R2 Enterprise SP2. Operating System is Microsoft Windows Server 2008 R2 Standard - 64 Bit.
Oracle Database Server: Operating System is Red Hat Enterprise Linux Server release 5 (Tikanga). Oracle Database version is Oracle Database 10g R2 Enterprise Edition Release 10.2.0.2.0 - Production.

Setting the Cardinality of Department > Employee role to OptionalOne
gives rise to cartesian join (which is a bigger issue).
Therefore, the Cardinality of Department > Employee role should remain as
OptionalMany (default).
This means, the outer join problem still remains unsolved. I have, therefore,
unmarked the above answer by me.
The question is - why has Report Builder been designed in such a way that the primary entity is always the child entity when attributes are selected from both parent and child entities?
Most people desire that all the rows of the parent entity be fetched irrespective of whether there are corresponding rows in the child entity or not. Report Builder tool should not dictate what the user wants to get, meaning it is not right to assume
that the focus of the report is Employee when attributes are selected from both Department and Employee. Report Builder should not make the child entity (i.e., Employee) as the primary entity when the user selects attributes from the child entity after
having selected attributes from the parent entity.
I am sorry to say that clients may not accept the Report Builder tool as this does not fetch the records as desired.
I hope there is someone who can suggest how the outer join problem can be solved by just tweaking the properties of the report model (SMDL).
Besides, the end users are business users and are not tech savvy. They are not expected to modify queries. They would simply drag and drop attributes from entities to create adhoc reports.

Performance when OUTER JOINS are used

Hello Everyone,
I have read in asktom.com about the performance of an SQL query when OUTER JOINS are used. I am not able to find the same artical and would like any of you guys to clarify if the sql that I have written would be better or not.
1. I haven't used OUTER JOINS in an SQL query. The query used 3-4 tables.
In those 3-4 tables one table is transaction table (big one) and the other are tables like transaction_type.
2. The transactions tables thas the typ_code and the typ_desc is present in transaction_type. It is one(transaction_type) to many(transactions) relationship
3. And also as all the typ_code of transactions tables has definte value in transaction_types table, I thought of not usng OUTER JOINS.
Would you guys agree with me?

I have read in asktom.com about the performance of an
SQL query when OUTER JOINS are used. I am not able to
find the same artical and would like any of you guys
to clarify if the sql that I have written would be
better or not.The first thing to consider using outer joins or not - is whether the required business functionality needs them or not? Performance should be only the second thing because getting invalid results VERY FAST doesn't make any sense :)
Gints Plivna
http://www.gplivna.eu

Problems performing an outer join

I added some criteria to the following sql statement to get the relationship.
ie ('Husband', 'Wife','Father','Mother','Step Mother','Step Father','Father in-law','Mother in-law')
The problem is that I also want to beable to display those that are not in this category. So I thought that I could do and outer join such as
and hcr.relationship_name(+) in ('Husband',
'Wife',
This does not work. Can anyone recommend how I can perform an outer join to get that information that does not meet the in statement?
thanks
select      hac.case_id,hac.relation_to_hoh_id,hcr.RELATIONSHIP_NAME,
          decode(ha.GENDER_ID,1,'(F)',2,'(M)',3,'(T)') || ' Adult ' ||
          round((trunc(sYSdate) - ha.DATE_OF_BIRTH) / 365,0) info, 0 sort_by
from      dpss_hts.hts_applicant ha,
          dpss_hts.hts_applicant_case hac,
          dpss_hts.certa_relationship hcr
where      ha.applicant_id = hac.applicant_id
and      round((trunc(sYSdate) - ha.DATE_OF_BIRTH) / 365,0) > 17
and      hac.relation_to_hoh_id = hcr.RELATIONSHIP_ID
and hcr.relationship_name in ('Husband',
'Wife',
'Father',
'Mother',
'Step Mother',
'Step Father',
'Father in-law',
'Mother in-law')

If I understand correctly, you want to display the relationship_name only if it is one of those in the list. If it is not, then you want to display the rest of the data, but not the realtionship_name.
Two approaches spring to mind. You can use an in-line view to select only the relationship_names you are interested in, then outer join to that in-line view like:
SELECT hac.case_id, hac.relation_to_hoh_id, hcr.relationship_name,
       DECODE(ha.gender_id, 1, '(F)', 2, '(M)', 3, '(T)')||' Adult '||
       ROUND((TRUNC(sysdate) - ha.date_of_birth) / 365, 0) info, 0 sort_by
FROM dpss_hts.hts_applicant ha, dpss_hts.hts_applicant_case hac,
     SELECT relationship_id, relationship_name
     FROM dpss_hts.certa_relationship
     WHERE hcr.relationship_name in ('Husband', 'Wife', 'Father', 'Mother',
                                     'Step Mother', 'Step Father',
                                     'Father in-law', 'Mother in-law') hcr
WHERE ha.applicant_id = hac.applicant_id and
      ROUND((TRUNC(sysdate) - ha.date_of_birth) / 365, 0) > 17 and
      hac.relation_to_hoh_id = hcr.relationship_id(+)Another alternative would be do leave the current join intact, lose the predicate on relationship_name and do the dciding in the SELECT list.
Something like:
SELECT hac.case_id, hac.relation_to_hoh_id,
       CASE WHEN hcr.relationship_name IN ('Husband', 'Wife', 'Father',
                                           'Mother', 'Step Mother',
                                           'Step Father', 'Father in-law',
                                           'Mother in-law') THEN hcr.relationship_name
            ELSE NULL END relationship_name,
       DECODE(ha.gender_id, 1, '(F)', 2, '(M)', 3, '(T)')||' Adult '||
       ROUND((TRUNC(sysdate) - ha.date_of_birth) / 365, 0) info, 0 sort_by
FROM dpss_hts.hts_applicant ha, dpss_hts.hts_applicant_case hac,
     dpss_hts.certa_relationship hcr
WHERE ha.applicant_id = hac.applicant_id and
      ROUND((TRUNC(sysdate) - ha.date_of_birth) / 365, 0) > 17 and
      hac.relation_to_hoh_id = hcr.relationship_idHTH
John

Using Command to fix null / left outer join issue

Hi
I was told awhile ago that it's possible to fix crystal's issue with left outer join and null records being eliminated.
I think i remember most of how this goes, but i can't seem to duplicate it.
1) You can't have any select expert -- record
2) You create the report normally and then make a new report using the SQL Query
     - Can't remember if its the whole report or upto the tables that have hisotry (null results)
3) You move parts from WHERE to FROM
Hopefully someone can help correct the steps i'm doing wrong or add what i'm missing from this.
Below is the Query from my comlpeted report, but when i run it with the last LEFT OUTER JOIN added it removes all the products with no sales during that year.
Any help would be greatly appreciated even if it's to say this can't be done.
SELECT
"prod_warehouse"."pw_whs_id",
"prod_warehouse"."pw_prodline_id",
"prod_warehouse"."pw_prod_id",
"prod_warehouse"."pw_bin_location1",
"prod_warehouse"."pw_min_onhand_qty",
"prod_warehouse"."pw_max_onhand_qty",
"prod_warehouse"."pw_onhand_qty",
"product_lookup"."prlkp_lang1_1_desc",
"prod_customer"."prcu_cust_part_num",
"contract_details"."cond_level1_amt",
"sales_history"."sah_year"
FROM   (((("sisl_data05"."dbo"."products" "products"
LEFT OUTER JOIN "sisl_data05"."dbo"."prod_warehouse" "prod_warehouse"
ON ("products"."pr_prod_id"="prod_warehouse"."pw_prod_id")
AND ("products"."pr_prodline_id"="prod_warehouse"."pw_prodline_id"))
LEFT OUTER JOIN "sisl_data05"."dbo"."product_lookup" "product_lookup"
ON ("products"."pr_prod_id"="product_lookup"."prlkp_prod_id")
AND ("products"."pr_prodline_id"="product_lookup"."prlkp_prodline_id"))
LEFT OUTER JOIN "sisl_data05"."dbo"."prod_customer" "prod_customer"
ON ("products"."pr_prod_id"="prod_customer"."prcu_prod_id")
AND ("products"."pr_prodline_id"="prod_customer"."prcu_prodline_id"))
LEFT OUTER JOIN "sisl_data05"."dbo"."contract_details" "contract_details"
ON "prod_warehouse"."pw_prod_id"="contract_details"."cond_prod_id")
LEFT OUTER JOIN "sisl_data05"."dbo"."sales_history" "sales_history"
ON (("prod_warehouse"."pw_whs_id"="sales_history"."sah_sortkey1")
AND ("prod_warehouse"."pw_prod_id"="sales_history"."sah_sortkey2"))
AND ("prod_warehouse"."pw_prodline_id"="sales_history"."sah_sortkey3")
WHERE
"prod_warehouse"."pw_whs_id"='20123'
AND ("prod_warehouse"."pw_onhand_qty"<>0
OR "prod_warehouse"."pw_bin_location1"<>' '
OR "prod_warehouse"."pw_max_onhand_qty">0)
AND "sales_history"."sah_year"=2014
ORDER BY "prod_warehouse"."pw_bin_location1", "prod_warehouse"."pw_prod_id"

Try this:
SELECT
prod_warehouse.pw_whs_id,
prod_warehouse.pw_prodline_id,
prod_warehouse.pw_prod_id,
prod_warehouse.pw_bin_location1,
prod_warehouse.pw_min_onhand_qty,
prod_warehouse.pw_max_onhand_qty,
prod_warehouse.pw_onhand_qty,
product_lookup.prlkp_lang1_1_desc,
prod_customer.prcu_cust_part_num,
contract_details.cond_level1_amt,
sales_history.sah_year
FROM sisl_data05.dbo.products products
LEFT OUTER JOIN sisl_data05.dbo.prod_warehouse prod_warehouse
    ON products.pr_prod_id=prod_warehouse.pw_prod_id
    AND products.pr_prodline_id=prod_warehouse.pw_prodline_id
LEFT OUTER JOIN sisl_data05.dbo.product_lookup product_lookup
    ON products.pr_prod_id=product_lookup.prlkp_prod_id)
    AND products.pr_prodline_id=product_lookup.prlkp_prodline_id
LEFT OUTER JOIN sisl_data05.dbo.prod_customer prod_customer
    ON products.pr_prod_id=prod_customer.prcu_prod_id
    AND products.pr_prodline_id=prod_customer.prcu_prodline_id
LEFT OUTER JOIN sisl_data05.dbo.contract_details contract_details
    ON prod_warehouse.pw_prod_id=contract_details.cond_prod_id
LEFT OUTER JOIN sisl_data05.dbo.sales_history sales_history
    ON prod_warehouse.pw_whs_id=sales_history.sah_sortkey1
    AND prod_warehouse.pw_prod_id=sales_history.sah_sortkey2
    AND prod_warehouse.pw_prodline_id=sales_history.sah_sortkey3
    AND sales_history.sah_year = 2014
WHERE prod_warehouse.pw_whs_id='20123'
AND (prod_warehouse.pw_onhand_qty<>0
    OR prod_warehouse.pw_bin_location1<>' '
    OR prod_warehouse.pw_max_onhand_qty>0)
Take a look at what I've done with the last line of the last join. The issue is that when you left join to a table and you use that table in the Where clause, you've basically turned your you left outer join into an inner join because the record has to be there in order to get the value in the filter. By moving the filter into the join, you'll still get the rest of the data when there is no corresponding record.
NOTE: Crystal adds all sorts of "extra" stuff like quotes and parentheses that you don't need and which I have removed to make the query easier to read.
-Dell

Performance issue with joins on table VBAK, VBEP, VBKD and VBAP

hi all,
i have a report where there is a join on all 4 tables VBAK, VBEP, VBKD and VBAP.
the report is giving performance issues because of this join.
all the key fields are used for the joining of tables. but some of the non-key fields like vbap-vstel, vbap-abgru and vbep-wadat are also part of select query and are getting filled.
because of these there is a performance issue.
is there any way i can improve the performance of the join select query?
i am trying "for all entries" clause...
kindly provide any alternative if possible.
thanks.

Hi,
Pls perform some of the below steps as applicable for the performance improvement:
a) Remove join on all the tables and put joins only on header and item (VBAK & VBAP).
b) code should have separate select for VBEP and VBKD.
c) remove the non key fields from the where clause. Once you retrieve data from the database into the internal table, sort the table and delete the entries which are not part of the non-key fields like vstel, abgru and wadat.
d) last option is you can create index in the VBAP & VBEP table with respect to the fields vstel, abgru & wadat ( not advisable)
e) buffering option on database tables also possible.
f) select only the fields into the internal table that are applicable for the processing logic and also the select query should contaian the field names in the same order as mentioned in the database table.
Hope this helps.
Regards
JLN

Performance for outer join

Hello expert,
following statement is left outer join or right outer join? and comparing with statement " from PCM RIGHT OUTER JOIN R ON PCM.practice_state_code = R.practice_state_code ", whose performance is better? Appreciate very much.
PCM.practice_state_code (+) = R.practice_state_code

Hi,
843178 wrote:
Hello expert,
following statement is left outer join or right outer join?
PCM.practice_state_code (+) = R.practice_state_codeNeither. It's the old outer join notation. Using that syntax, the order in which you put the tables in the FROM clause doesn't matter.
and comparing with statement " from PCM RIGHT OUTER JOIN R ON PCM.practice_state_code = R.practice_state_code ", whose performance is better? They're equal.

BISE1 Outer Join issues

Hi, another issue I'm running in to using BISE1. I've got a simple star-schema relational model, basically copying it straight into the business layer without any adjustments.
I have a dimension (DIM_MEASURES) that I need to have outer join - i.e. on any report, I ALWAYS want to see every value of DIM_MEASURES, even if no data exists in the fact tables for some of the values.
I've gone in to the business model and changed the complex join to LEFT OUTER, RIGHT OUTER, and FULL OUTER - and I can't get ANY of these to return all rows of the dimension.
Am I doing something wrong, or is this a bug?
Thx,
Scott

Hi Scott,
My guess is that it should work that way. Maybe you can inspect your Query log file and find out which select statement is produced.
Good Luck,
Daan Bakboord

Outer Join Performance Issue

Similar Messages

Maybe you are looking for