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

Similar Messages

  • 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

  • ANSI SQL Syntax - What belongs to join-clause and what to where-clause

    Hello,
    we currently have a discussion about the ANSI SQL Syntax where we do not agree what belongs to the join clause and what belongs to the where clause in an ANSI Sytnax SQL Query.
    Lets say there is a query like this:
    +SELECT *+
    FROM employees emp, departments dept
    WHERE emp.dept_country = dept.dept_country
    AND emp.dept_name = dept.dept_name
    AND dept.dept_type = 'HQ'
    AND emp.emp_lastname = 'Smith'
    Primary key of the departments table is on the columns dept_country, dept_name and dept_type. We have a Oracle database 10g.
    Now I have rewritten the query to Ansi Syntax:
    +SELECT *+
    FROM employees emp
    JOIN departments dept
    ON emp.dept_country = dept.dept_country AND emp.dept_name = dept.dept_name
    WHERE dept.dept_type = 'HQ'
    AND emp.emp_lastname = 'Smith'
    Another developer says that this is not completely correct, every filter on a column that belongs to the primary-key of the joined table has to be in the join clause, like this:
    +SELECT *+
    FROM employees emp
    JOIN departments dept
    +ON emp.dept_country = dept.dept_country AND emp.dept_name = dept.dept_name AND dept.dept_type = 'HQ'
    WHERE emp.emp_lastname = 'Smith'
    Can somebody tell me which on is correct?
    Is there any definition for that? I couldn't find it in the Oracle Database definition.
    I just found out the names of the ANSI documents here: http://docs.oracle.com/cd/B19306_01/server.102/b14200/ap_standard_sql001.htm#i11939
    I had a look at the ANSI webstore but there you have to buy the PDF files. In my case thats exaggerated because both of the Queries work and i am just interessted if there is one correct way.
    Thank you in advance
    Marco

    Hi,
    As i guideline i would say, answer the question: should the result of the join be filtered or should only filtered rows be joined from a particular table?
    This is helpful in the case of outer joins also, for inner joins it doesnt matters as said already be former posters, where there may be hughe semantical differences depending of where the predicates are placed.
    From performance view, if we talk about oracle, take a look a the execution plans. You will see that there is (probably) no difference in case of inner joins. Even in case of outer joins the optimizer pushes the predicate as a filter towards the table if it semantically possible.
    Regards

  • Datawindow graphical syntax outer join BUG

    Ok, so this is a bug report.  I don't know where i'm supposed to post it for SAP (i do have support).
    The outer join syntax is ansi.
    Using the graphical SQL designer, outer joins are incorrectly written by powerbuilder.  This has been going on ever since ANSI style outer join sytax was added (PB 9?).
    I think it has to do with the datawindow's use of both right and outer joins and its lack of use of inner joins.  The end result is that we have to rewrite a lot of stuff in sql since powerbuilder is generating bad sql.
    The typical example is the use of 2 or more outer joins where the joins are being done using 2 or more columns.
    PB will create both a LEFT and a RIGHT outer join by duplicating the table name.  The table (receive) is only selected ONCE in the sql graphical designer.
    And this is the result:
    Microsoft SQL Native Client
    The objects "receive" and "receive" in the FROM clause have the same exposed names. Use correlation names to distinguish them.
    Do you want to correct errors?
    I would love to see the datawindow sql corrected and written in a more standard way.
    1 change the OUTER JOIN syntax in the db profile setup to indicate the syntax.  not outer join, but syntax.  If you select ANSI have it write ALL joins using JOIN ( from ta join tb on ta.col = tb.col) intead of from tablea, tableb where tablea.col = tableb.col
    2 - eliminate the use of right outer joins.
    At that point i believe that the datawindow could more easily be fixed by SAP to not duplicate tables when in generates the syntax.

    If you have an Oracle Support agreement you can log a Service Request with Oracle, but they may respond that it is not really a bug. The problem is that the "outer" keyword in your 3rd example is being treated as an alias for TABLE_A because it is not considered a reserved keyword.
    with table_a as (
    select 1 as id, 'abc' as value_a from dual union all
    select 2 as id, 'def' as value_a from dual union all
    select 3 as id, 'ghi' as value_a from dual
    , table_b as (
    select 2 as id, 'jkl' as value_b from dual union all
    select 3 as id, 'mno' as value_b from dual union all
    select 4 as id, 'pqr' as value_b from dual
    select ID, outer.VALUE_A, VALUE_B from TABLE_A outer join TABLE_B using (ID);
    ID                     VALUE_A VALUE_B
    2                      def     jkl
    3                      ghi     mnoIf you query the V$RESERVED_WORDS view it will tell you which keywords are reserved.
    select * from V$RESERVED_WORDS where keyword in ('OUTER', 'SELECT','USING');
    KEYWORD                        LENGTH                 RESERVED RES_TYPE RES_ATTR RES_SEMI DUPLICATE
    USING                          5                      N        N        N        N        N
    OUTER                          5                      N        N        N        N        N
    SELECT                         6                      Y        N        N        N        NYou would get a similar result if you tried
    select ID, VALUE_A, VALUE_B from TABLE_A using join TABLE_B using (ID);Regards,
    Bob

  • ANSI SQL syntax?

    Hi all,
    I have a simple query
    SELECT A.*, B.Dstrct_Code FROM MSF601 A, MSF600 B
    WHERE ALTERNATE_REF LIKE 'PF%'
    AND A.alt_ref_code = B.Equip_No
    AND B.Dstrct_Code = 'ACME';
    which works fine, but I want to convert it to ANSI
    SQL syntax, so I tried
    SELECT A.*, B.Dstrct_Code FROM MSF601 A, MSF600 B
    WHERE ALTERNATE_REF LIKE 'PF%'
    INNER JOIN ON A.alt_ref_code = B.Equip_No
    AND B.Dstrct_Code = 'ACME';
    but I get
    ERROR at line 3:
    ORA-00933: SQL command not properly ended
    Could some kind soul explain why?
    Paul...

    An example that looks a lot like your example:
    SQL> select dept.*
      2       , emp.ename
      3    from dept, emp
      4   where dept.dname like '%A%'
      5   inner join on dept.deptno = emp.deptno
      6     and emp.sal > 1000
      7  /
    inner join on dept.deptno = emp.deptno
    FOUT in regel 5:
    .ORA-00933: SQL command not properly ended
    SQL> select dept.*
      2       , emp.ename
      3    from dept
      4         inner join emp on dept.deptno = emp.deptno
      5   where dept.dname like '%A%'
      6     and emp.sal > 1000
      7  /
                                    DEPTNO DNAME          LOC           ENAME
                                        30 SALES          CHICAGO       ALLEN
                                        30 SALES          CHICAGO       WARD
                                        20 RESEARCH       DALLAS        JONES
                                        30 SALES          CHICAGO       MARTIN
                                        30 SALES          CHICAGO       BLAKE
                                        10 ACCOUNTING     NEW YORK      CLARK
                                        20 RESEARCH       DALLAS        SCOTT
                                        10 ACCOUNTING     NEW YORK      KING
                                        30 SALES          CHICAGO       TURNER
                                        20 RESEARCH       DALLAS        ADAMS
                                        20 RESEARCH       DALLAS        FORD
                                        10 ACCOUNTING     NEW YORK      MILLER
    12 rijen zijn geselecteerd.Regards,
    Rob.

  • How to generate ANSI SQL syntax mapping

    I am not able to force OWB to generate ANSI SQL syntax mapping.
    In mapping configuration I have checked "ANSI SQL syntax" On, "Operating mode" is "Set based fail over to row based", "Optimize code" is On.
    "PLSQL generation mode" is set to 10gR2.
    OWB 10.2.0.4.36, OraDB 10.2.0.4.0

    Oracle SQL is based on ANSI sql 92 standards. But not possible to generate queries in ansi sql 92 format?

  • 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

  • SQL 92 Outer Join Syntax and Funtion.

    When i am trying to use {fn substring(..)} or {oj table} in sql query to make it database independent, oralce driver does not support this.
    Could any one explain the above issue?
    If so, How do i use it? Explain the syntax a bit.
    Thanks in Advance,
    Ramani.

    I should add that I have tried to change SQLServerPlatform to have shouldPrintOuterJoinInWhereClause() return "true". This embeds a "=*" in the join conditions in the WHERE clause.
    SQL Server 2000 still supports this syntax, but the "=*" isn't ALWAYS the correct operator. It is IMPORTANT to put the "*" on the correct side of the expression.
    TopLink always prints "=*", and it always puts it in the correct space, but the OPERATORS are not always in the correct order so you are creating a "left join" on the wrong table.
    So my other question, is it possible to FORCE TopLink to remember to put the outer join table in the RIGHT SIDE?
    Nate

  • ANSI SQL Syntax Vs Old Syntax

    Hi,
    Is there a performance difference between ansi and old syntax.
    The following query
    SELECT ITD.display_description
    FROM structure_child SC
    RIGHT OUTER JOIN structure S ON SC.structure_id = S.structure_id
    INNER JOIN structure_level SL ON SL.structure_level_id = S.structure_level_id
    INNER JOIN item_type_naming ITN ON ITN.structure_id = S.structure_id
    INNER JOIN item_type_description ITD ON ITN.item_type_description_id = ITD.item_type_description_id
    AND item_type_id = p_item_type_id
    WHERE ( S.structure_id = p_structure_id OR S.structure_id = 0)
    and itd.item_type_id = p_item_type_id
    ORDER BY structure_level
    Runs much slower than the old style query
    SELECT ITD.DISPLAY_DESCRIPTION
    FROM structure S, structure_child SC, structure_level SL,item_type_naming ITN,
    item_type_description ITD
    WHERE SC.structure_id(+) = S.structure_id
    AND SL.structure_level_id = S.structure_level_id
    AND ITN.structure_id = S.structure_id
    AND ITN.item_type_description_id = ITD.item_type_description_id
    AND item_type_id = p_item_type_id
    AND (S.structure_id = p_structure_id OR S.structure_id = 0)
    ORDER BY structure_level
    Any reasons why this is the case. Also is there any hint I can give to improve the performance.

    They ought to be the same.
    Be sure to run the query twice to ensure the extra time doesn't including parsing, etc.
    Do you get the same results?
    Are the explain/execution plans the same?
    The only caveat I can think of with ANSI joins is that there is a problem using them over a dblink in which one of the remote tables has a LOB column, an error is generated it that case...
    Steve

  • Problematic sql with outer join

    There is one sql statement:
    INSERT INTO XXOM_SSC_TEMP_MMI_GTEMP (HEADER_ID, LAST_UPDATE_DATE) SELECT DISTINCT OOH.HEADER_ID, XSOH.LAST_UPDATE_DATE FROM OE_ORDER_HEADERS_ALL OOH INNER JOIN (SELECT TRANSACTION_TYPE_ID FROM OE_TRANSACTION_TYPES_TL OTT WHERE OTT.NAME NOT IN ('ORDER_RMA_MMI' ) AND OTT.LANGUAGE = 'US') OTT ON (OTT.TRANSACTION_TYPE_ID = OOH.ORDER_TYPE_ID) LEFT OUTER JOIN XXOM_3LP_SYM_ORA_ORDER_HDR XSOH ON (TO_CHAR (XSOH.ORDERTYPE) = SUBSTR ( OOH.ORIG_SYS_DOCUMENT_REF, 1, INSTR (OOH.ORIG_SYS_DOCUMENT_REF, '-', 1) - 1) AND TO_CHAR (XSOH.ORDERNBR) = SUBSTR ( OOH.ORIG_SYS_DOCUMENT_REF, INSTR (OOH.ORIG_SYS_DOCUMENT_REF, '-', 1) + 1) AND (XSOH.LAST_UPDATE_DATE >= :B1 )) INNER JOIN OE_ORDER_LINES_ALL OOL ON (OOH.HEADER_ID = OOL.HEADER_ID AND OOL.SHIP_FROM_ORG_ID = :B2 ) WHERE OOH.BOOKED_FLAG = 'Y' AND XSOH.ORG_ID = OOH.ORG_ID
    Porblematic query has insufficient and sub-optimal join conditions which makes it more expensive.One has recommended to remove one unnecessary outer join from the query and also fix the join to pick index.
    But how can we remove outer join and in place of that what should we write.

    Your code is unreadable, man! Surely your boss does not let you produce stuff like that? Format it. Because I'm a helpful person, I just put it through the formatter on http://www.dpriver.com/pp/sqlformat.htm :INSERT INTO xxom_ssc_temp_mmi_gtemp
                (header_id,
                 last_update_date)
    SELECT DISTINCT OOH.header_id,
                    XSOH.last_update_date
    FROM   oe_order_headers_all OOH
           inner join (SELECT transaction_type_id
                       FROM   oe_transaction_types_tl OTT
                       WHERE  OTT.name NOT IN ( 'ORDER_RMA_MMI' )
                              AND OTT.LANGUAGE = 'US') OTT
                   ON ( OTT.transaction_type_id = OOH.order_type_id )
           left outer join xxom_3lp_sym_ora_order_hdr XSOH
                        ON ( To_char (XSOH.ordertype) =
                             Substr (OOH.orig_sys_document_ref,
                             1,
                             Instr (OOH.orig_sys_document_ref,
                             '-', 1)
                             - 1)
                             AND To_char (XSOH.ordernbr) =
                                 Substr (OOH.orig_sys_document_ref,
                                 Instr (OOH.orig_sys_document_ref, '-', 1) + 1
                             AND ( XSOH.last_update_date >= :B1 ) )
           inner join oe_order_lines_all OOL
                   ON ( OOH.header_id = OOL.header_id
                        AND OOL.ship_from_org_id = :B2 )
    WHERE  OOH.booked_flag = 'Y'
           AND XSOH.org_id = OOH.org_id

  • Oracle sql to outer join based on reg exp

    Hi,
    I am expecting output like (3). I want to join two tables with regex. join condition
    . For example, in table1.string(abcYYMMDD.txt) I want to match date part (YYMMDD) wit any possible number in Table2.string (abc150420.txt)
    Please suggest.
    (1) table1:
    abcYYMMDD.txt
    ddefYYMMDD.txt
    ghiYYMMDD.txt
    (2) table2:
    abc150420.txt
    abc150421.txt
    abc150422.txt
    abc150320.txt
    ddef150101.txt
    ddef150404.txt
    (3) Table1 left join Table2 (join example - abc(replace YYMMDD by regex).txt=abc150420.txt)
    abcYYMMDD.txt,abc150420.txt
    abcYYMMDD.txt,abc150421.txt
    abcYYMMDD.txt,abc150422.txt
    abcYYMMDD.txt,abc150320.txt
    ddefYYMMDD.txt,ddef150101.txt
    ddefYYMMDD.txt,ddef150404.txt
    ghiYYMMDD.txt,

    The audittime field is a timestamp field.
    If I give the below query, rownum is not in the sequential order, see below few records..
    SELECT rownum,to_char(audit_time_stamp,'dd-mon-yyyy HH24:MI:SS.FF') from audit_details ORDER BY audit_time_stamp
    ROWNUM     to_char(audit_time_stamp,'dd-mon-yyyy HH24:MI:SS.FF')
    16     18-apr-2007 14:30:52.551010
    17     18-apr-2007 16:33:21.900305
    18     18-apr-2007 17:49:44.061420
    19     18-apr-2007 17:49:44.134804
    20     19-apr-2007 16:40:15.775235
    21     22-apr-2007 23:31:01.818784
    ROWNUM     To_char(audit_time_stamp,'dd-mon-yyyy HH24:MI:SS.FF')
    1     01-may-2007 19:17:46.880342
    2     01-may-2007 19:24:04.952571
    3     01-may-2007 19:24:32.182110
    4     01-may-2007 19:25:49.464260
    5     01-may-2007 19:25:52.127018
    6     01-may-2007 19:27:34.099095
    7     01-may-2007 19:30:34.763481
    8     01-may-2007 19:31:06.226955
    9     01-may-2007 19:32:36.727196
    10     01-may-2007 19:40:44.061941

  • 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,
    Will

    Hey 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

  • Outer Joins Generated in SQL but not specified in Data Foundation

    Hi:
      I created a very simple universe on a MS Access database. there are four tables, joined by equi joins. Yet, when I select the objects (one from each table), the generated SQL has outer joins! This was not the case in XI 3.1 using Designer. Has anyone else run into this?
    I tried to create a similar scenario with SQL server and I got the same issue.
    Here is the generated SQL from the MS Access based query:
    SELECT
      Country.country,
      Region.region,
      City.city,
      Customer.first_name,
      Customer.last_name
    FROM
      Country,
      Region,
      City,
      Customer,
      { oj Country LEFT OUTER JOIN Region ON Country.country_id=Region.country_id },
      { oj Region LEFT OUTER JOIN City ON Region.region_id=City.region_id },
      { oj City LEFT OUTER JOIN Customer ON City.city_id=Customer.city_id }
    Notice all the outer joins -- they are not specified as outer joins in Data Foundation yet Webi Rich Client continues to generate the outer joins.
    Thanks!
    -Mike

    Hi,
    This sounds familiar.
    I think this may have been a bug recently solved in Patch2.10 for BI 4.0 SP02
    Whenever a user creates a join in the data foundation using drag & drop (and not editing the join using the UI), the flag for defining the outer join status is improperly set.
    This causes the SQL generation to create a left outer join when the UI displays that no outer join has been set.
    The workaround is to edit the join (double-click to show the join editor) and then do OK. In this case a inner join will be used in the SQL generation.
    This was confirmed fixed (in an internal discussion) in Patch2.10 . Does it sound familar ?
    Regards,
    H

  • Outer Join logic

    The following code is an example of how to perform an outer join, in this case with ReportQuery (thanks Doug):
            ExpressionBuilder eb = new ExpressionBuilder();
            ReportQuery rq = new ReportQuery(Employee.class, eb);
            rq.addAttribute("firstName");
            rq.addAttribute("lastName");
            rq.addAttribute("areaCode", eb.anyOfAllowingNone("phoneNumbers").get("areaCode"));
            List<ReportQueryResult> results =  (List<ReportQueryResult>) session.executeQuery(rq);My question is about the logic Toplink uses to generate the outer join statement with the "(+)" in the generated sql.
    Does Toplink only generate the join statement if the same attribute is chosen in the select statement (in the above example "areaCode")?
    Along the same line of questioning, does it matter which attribute was in the get() call? So, in the above example did it have to be areaCode, or could it have been any other attribute of phoneNumber, and it still would have performed the join?
    In my case, because the selection attributes are built up dynamicly, should I add all attributes of my child class (my equivalent PhoneNumber class)?

    Thanks for your reply Doug.
    One last question, hopefully.
    I have a parent table with 2 child tables. When attempting an outer join with both, toplink does not attempt to outer join either. I understand why, sort of - as you get an error when attempting this in sqlplus with "(+)" syntax.
    I understand that you can outer join > 1 other table to a parent with ansi sql syntax:
        select dept.*,emp.*
        from dept left outer join emp
        on dept.deptno = emp.deptnoWill toplink allow > 1 child table outer join to a parent table?

Maybe you are looking for

  • Aggregation Level in not prepared to run on HANA

    Hello Experts, I've the following system configuration: CPMBPC 810: SP 0001 POASBC 100_731: SP 0005 HANABPC 810: SP 0001 Hence we've PAK and BPC license too for working with PAK. Now, I've created an Aggregation level: ZTPM_AG01 on top of a Multiprov

  • ITunes music folder location

    Hello everyone. I already posted this question one year ago, without to receive a satisfactory reply: http://discussions.apple.com/thread.jspa?threadID=899085 . In my Music folder, near to the iTunes folder, I have other 25 folders, one for Artist. I

  • QT pro conversion rate question

    I have QT Pro, lets say I'm converting a .mov file from 13.97 mbits/s (thats what the inspector tells me) to 2400 kbps. If the source file is 13.97 mbits/s will I really see the difference in quality of the the new QT file @2400kbps? First part is co

  • SUM execution phase hanging in 'Start JAVA' step

    Good day I'm trying to update the Java stack of a solman 7.1 stack 10 instance. I'm using SUM v1 SP10 patch0. Everything runs fine until  5.6 [Execution --> Start Java] which times out after a while. Part of START-AS-JAVA.LOG: Java instance =02 SCS i

  • How to set imessage back up

    please help mypartner and I set imessage back up on phone