Perform an Inner Join in Oracle 8

We have to make our application (that runs with Oracle 9i) backward compatible with Oracle 8.
There are certain SQL statements that were introduced in Oracle 9i, such as Inner Join (Oracle 9i now allows more of the ANSI standard SQL that MS SQL also uses)
Does anyone know of the other differences I should look out for, or any documentation that lists the new 9i differences that we may already be using.
I have trawled through lots of OTN documentation, but not been able to find anything that highlights even the Inner Join problem.
If there are any documents that also suggest a solution, that would be even better.
Thanks in advance for any help/suggestion
Mark

You have a parameter called "COMPATIBLE", and if you set to, for example 8.1.7 in your 9i database, then your application should be compatible with 8.1.7. It is that easy!
Of course, by doing so, you renounce to use the 9i features.
There is a book called "New Features" in the book list in your oracle documentation.
Regards
Laurent Schneider

Similar Messages

Inner Join. How to improve the performance of inner join query

Inner Join. How to improve the performance of inner join query.
Query is :
select f1~ablbelnr
         f1~gernr
         f1~equnr
         f1~zwnummer
         f1~adat
         f1~atim
         f1~v_zwstand
         f1~n_zwstand
         f1~aktiv
         f1~adatsoll
         f1~pruefzahl
         f1~ablstat
         f1~pruefpkt
         f1~popcode
         f1~erdat
         f1~istablart
         f2~anlage
         f2~ablesgr
         f2~abrdats
         f2~ableinh
            from eabl as f1
            inner join eablg as f2
            on f1ablbelnr = f2ablbelnr
            into corresponding fields of table it_list
            where f1~ablstat in s_mrstat
            %_HINTS ORACLE 'USE_NL (T_00 T_01) index(T_01 "EABLG~0")'.
I wanted to modify the query, since its taking lot of time to load the data.
Please suggest : -
Treat this is very urgent.

Hi Shyamal,
In your program , you are using "into corresponding fields of ".
Try not to use this addition in your select query.
Instead, just use "into table it_list".
As an example,
Just give a normal query using "into corresponding fields of" in a program. Now go to se30 ( Runtime analysis), and give the program name and execute it .
Now if you click on Analyze button , you can see, the analysis given for the query.The one given in "Red" line informs you that you need to find for alternate methods.
On the other hand, if you are using "into table itab", it will give you an entirely different analysis.
So try not to give "into corresponding fields" in your query.
Regards,
SP.

Inner Join in oracle 10g

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

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

Performance in Inner Join on VBAK

HI,
For a customized report the select statement was written like this which is giving time out error for large data. How one can improve performance of following Inner Joins.
SELECT *
      INTO CORRESPONDING FIELDS OF TABLE it_tab
       FROM vbak as A INNER JOIN vbuk as B
              ON Avbeln = Bvbeln
            INNER JOIN vbkd as C
             ON Avbeln = Cvbeln
WHERE    A~vbeln      IN so_vbeln
     AND   A~audat      IN so_audat
     AND   A~auart      IN so_auart
     AND   A~augru      IN so_augru
     AND   A~faksk    IN so_faksp
     AND   A~vkorg      IN so_vkorg
     AND   A~vtweg      IN so_vtweg
     AND   A~spart      IN so_spart
     AND   A~vkbur      IN so_vkbur
     AND   A~vkgrp      IN so_vkgrp
     AND   A~vsbed      IN so_vsbed
     AND   A~kunnr      IN so_kunnr
     and   B~gbstk      IN so_gbstx
     AND   C~posnr       = '000000'.
Thanks
anya
Moderator message: FAQ, it all depends on the content of the so_ ranges at runtime.
Please Read before Posting in the Performance and Tuning Forum
Edited by: Thomas Zloch on Nov 1, 2010 11:57 AM

Others have already responded, and I would only like to dwell on the answers for a short while. Or maybe rather the question.
This question is typical for the inexperienced developer. This particular question is actually a little different, because there is a straight answer: there is no difference. For most questions of this type the answer is "it depends", because one
particular syntax can happen to perform better with one set of data and indexes, but with a different data/index profile another syntax gives better result.
Ideally, as long as two queries are logically equivalent, the syntax should not matter at all, because the optimizer should always figure out the best way to achieve the result. In practice, this is not the case, because there are lots of limitaitons in
an optimizer in an RDBMS.
While it certainly can matter for performance how you write your queries, that is not what you should focus on. What you should focus is to express your query as clearly as possible, and make sure that you have the relevant indexes in place. There is one
rule when it comes to query-writing you should take your heart: never entable a column in a condition in an expression, because that is likely to render index on that column useless.
For this particular question, the answer is that as you long as you write code for SQL Server, use the JOIN syntax. But if you use that in the Oracle world, you may get funny looks from people. It's a different culture over there...
Erland Sommarskog, SQL Server MVP, [email protected]

Poor Performance on Inner Join of VBUP and VBAK

The following select is performing poorly, i.e., ST05 Execution is 1, Records is 246, but Time/Exec 94,499,272. Very poor.
SELECT VBUPVBELN VBUPPOSNR VBAK~KUNNR
 FROM VBUP INNER JOIN VBAK
 ON VBUPVBELN = VBAKVBELN
 WHERE VBAK~VBTYP EQ 'C'
 AND VBUP~LFSTA NE 'C'
 AND VBUP~LFGSA NE 'C'.
VBUP has a custom index, Z01, on MANDT, LFSTA, LFGSA. There is no index on VBAK.
The Explain under ST05 indicates an Est. I/O cost of 73.94 for a Clustered Index Seek on [VBAK].[VBAK0], and an Est. I/O cost of 81.34 for an Index Seek on [VBUP].[VBUPZ01].
There is no index on VBAK, so I assume that's the first problem. But I don't understand why the index on VBUP does not appear to be helping. This the ST05 Explain: Index Seek WHERE: [PCI].[pci].[VBUP].[LFGSA] as [T_00].[LFGSA]<[@P4] OR [PCI].[pci].[VBUP].[LFGSA] as [T_00].[LFGSA]>[@P4] : [VBUP].MANDT EQ [@P1] ORDERED 1.
Is my index even being used? Any ideas how I can speed this up?
Thanks in advance for your help.
Beth

tis the negative selection which is causing the problem..try to avoid selection using not equal to.
try this.
ranges : r_lfsta for vbup-lfsta.
r_lfsta-sign = 'I'.
r_lfsta-option = 'EQ'.
r_lfsta-low = ' '.
append r_lfsta.
r_lfsta-low = 'A'.
append r_lfsta.
r_lfsta-low = 'B'.
append r_lfsta.
do similar for r_lfgsa also.
SELECT VBUP~VBELN
 VBUP~POSNR
 VBAK~KUNNR
FROM VBUP INNER JOIN VBAK
into corresponding fields of table t_vbakvbup
ON VBUPVBELN = VBAKVBELN
WHERE VBAK~VBTYP EQ 'C'
AND VBUP~LFSTA in r_lfsta
AND VBUP~LFGSA in r_lfgsa.
or
SELECT VBUP~VBELN
 VBUP~POSNR
 VBAK~KUNNR
vbup~lfsta
vbup~lfgsa
FROM VBUP INNER JOIN VBAK
into corresponding fields of table t_vbakvbup
ON VBUPVBELN = VBAKVBELN
WHERE VBAK~VBTYP EQ 'C' .
delete t_vbakvbup where lfsta ne 'C'.
delete t_vbakvbup where lfgsa ne 'C'.

Inner join and select for all entries with respect to performance

Hi Friends,
I just want to know which is more efficient with respect to performance the Inner join or select for all entries?which is more efficient? and how? can you explain me in detail ?
Regards,
Dinesh

INNER JOIN->
The data that can be selected with a view depends primarily on whether the view implements an inner join or an outer join. With an inner join, you only get the records of the cross-product for which there is an entry in all tables used in the view. With an outer join, records are also selected for which there is no entry in some of the tables used in the view.
http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21ec77446011d189700000e8322d00/content.htm
FOR ALL ENTRIES->
Outer join can be created using this addition to the where clause in a select statement. It speeds up the performance tremendously, but the cons of using this variation are listed below
Duplicates are automatically removed from the resulting data set. Hence care should be taken that the unique key of the detail line items should be given in the select statement.
If the table on which the For All Entries IN clause is based is empty, all rows are selected into the destination table. Hence it is advisable to check before-hand that the first table is not empty.
If the table on which the For All Entries IN clause is based is very large, the performance will go down instead of improving. Hence attempt should be made to keep the table size to a moderate level.
Not Recommended
Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
Recommended
Select * from zfligh appending table int_fligh
For all entries in int_cntry
Where cntry = int_cntry-cntry.

Inner join and select for all entries with respect to performance in SAP

Hi Friends,
I just want to know which is more efficient with respect to performance the Inner join or select for all entries?which is more efficient?
Regards,
Dinesh

I did some testing a while ago and found that a JOIN is usually a bit more efficient than FOR ALL ENTRIES. This wasn't always the case though, so the best thing to do is to write it both ways and see which is faster.
Rob

Performance difference between left outer join / inner join

Hi,
I've got a complex query which among other things accesses quite a large table. If I use inner join to join this table, the response is quite fast and execution plan shows it uses nested loops to gather the data.
If I change inner join to left outer join, I get a big performance drop. Cost of query goes from 1441 to 28544.
I don't uderstand why there's such a difference. For inner join, database has to remove all the rows that don't have match in inner-joined table. For left join it can keep all records and just return NULL values for records that don't have a match. In my mind left join should be faster, as it seems simpler. And the access plan could be the same, couldn't it?
Execution plan for inner join:
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 288 | 1441 (1)| 00:00:18 |
| 1 | HASH GROUP BY | | 1 | 288 | 1441 (1)| 00:00:18 |
| 2 | NESTED LOOPS OUTER | | 1 | 288 | 1440 (1)| 00:00:18 |
| 3 | NESTED LOOPS | | 1 | 261 | 1438 (1)| 00:00:18 |
| 4 | NESTED LOOPS | | 318 | 74412 | 508 (1)| 00:00:07 |
| 5 | NESTED LOOPS | | 318 | 51834 | 189 (0)| 00:00:03 |
| 6 | TABLE ACCESS BY INDEX ROWID| RESURCE | 1 | 106 | 1 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | RESURCE_PRINCIPAL_NAME_INDEX | 1 | | 0 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE | 318 | 18126 | 188 (0)| 00:00:03 |
|* 9 | INDEX RANGE SCAN | TASK_USES_RESUR_IDX$$_0CDC0002 | 318 | | 3 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | TASK | 1 | 71 | 1 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | TASK_PK | 1 | | 0 (0)| 00:00:01 |
| 12 | TABLE ACCESS BY INDEX ROWID | TASK_WORK_HISTORY | 1 | 27 | 3 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | TASK_WORK_HISTORY_INDEX1 | 1 | | 2 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | TASK_USES_RESURCE | 1 | 27 | 2 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | TASK_USES_RESURCE_UK1 | 1 | | 1 (0)| 00:00:01 |
For left outer join:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 318 | 1596K| | 28544 (2)| 00:05:43 |
|* 1 | HASH JOIN OUTER | | 318 | 1596K| 1584K| 28544 (2)| 00:05:43 |
| 2 | VIEW | | 318 | 1580K| | 508 (1)| 00:00:07 |
| 3 | NESTED LOOPS | | 318 | 74412 | | 508 (1)| 00:00:07 |
| 4 | NESTED LOOPS | | 318 | 51834 | | 189 (0)| 00:00:03 |
| 5 | TABLE ACCESS BY INDEX ROWID| RESURCE | 1 | 106 | | 1 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | RESURCE_PRINCIPAL_NAME_INDEX | 1 | | | 0 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE | 318 | 18126 | | 188 (0)| 00:00:03 |
|* 8 | INDEX RANGE SCAN | TASK_USES_RESUR_IDX$$_0CDC0002 | 318 | | | 3 (0)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | TASK | 1 | 71 | | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | TASK_PK | 1 | | | 0 (0)| 00:00:01 |
| 11 | VIEW | | 1480K| 73M| | 23431 (2)| 00:04:42 |
|* 12 | HASH JOIN RIGHT OUTER | | 1480K| 76M| 38M| 23431 (2)| 00:04:42 |
| 13 | TABLE ACCESS FULL | TASK_USES_RESURCE | 1486K| 21M| | 2938 (2)| 00:00:36 |
| 14 | VIEW | | 1445K| 53M| | 15031 (2)| 00:03:01 |
| 15 | HASH GROUP BY | | 1445K| 37M| 110M| 15031 (2)| 00:03:01 |
| 16 | TABLE ACCESS FULL | TASK_WORK_HISTORY | 1445K| 37M| | 3897 (2)| 00:00:47 |
--------------------------------------------------------------------------------------------------------------------------

...continued
Complete execution plan for left join:
| Id | Operation                       | Name                           | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |                                |   318 | 1594K|       | 28544   (2)| 00:05:43 |
|* 1 | HASH JOIN OUTER                |                                |   318 | 1594K| 1584K| 28544   (2)| 00:05:43 |
|   2 |   VIEW                          |                                |   318 | 1578K|       |   508   (1)| 00:00:07 |
|   3 |    NESTED LOOPS                 |                                |   318 | 74412 |       |   508   (1)| 00:00:07 |
|   4 |     NESTED LOOPS                |                                |   318 | 51834 |       |   189   (0)| 00:00:03 |
|   5 |      TABLE ACCESS BY INDEX ROWID| RESURCE                        |     1 |   106 |       |     1   (0)| 00:00:01 |
|* 6 |       INDEX UNIQUE SCAN         | RESURCE_PRINCIPAL_NAME_INDEX   |     1 |       |       |     0   (0)| 00:00:01 |
|   7 |      TABLE ACCESS BY INDEX ROWID| TASK_USES_RESURCE              |   318 | 18126 |       |   188   (0)| 00:00:03 |
|* 8 |       INDEX RANGE SCAN          | TASK_USES_RESUR_IDX$$_0CDC0002 |   318 |       |       |     3   (0)| 00:00:01 |
|   9 |     TABLE ACCESS BY INDEX ROWID | TASK                           |     1 |    71 |       |     1   (0)| 00:00:01 |
|* 10 |      INDEX UNIQUE SCAN          | TASK_PK                        |     1 |       |       |     0   (0)| 00:00:01 |
| 11 |   VIEW                          |                                | 1480K|    73M|       | 23431   (2)| 00:04:42 |
|* 12 |    HASH JOIN RIGHT OUTER        |                                | 1480K|    76M|    38M| 23431   (2)| 00:04:42 |
| 13 |     TABLE ACCESS FULL           | TASK_USES_RESURCE              | 1486K|    21M|       | 2938   (2)| 00:00:36 |
| 14 |     VIEW                        |                                | 1445K|    53M|       | 15031   (2)| 00:03:01 |
| 15 |      HASH GROUP BY              |                                | 1445K|    37M|   110M| 15031   (2)| 00:03:01 |
| 16 |       TABLE ACCESS FULL         | TASK_WORK_HISTORY              | 1445K|    37M|       | 3897   (2)| 00:00:47 |
Query Block Name / Object Alias (identified by operation id):
   1 - SEL$1AFB0324
   2 - SEL$58A6D7F6 / from$_subquery$_005@SEL$8
   3 - SEL$58A6D7F6
   5 - SEL$58A6D7F6 / RESURCEWORKER@SEL$2
   6 - SEL$58A6D7F6 / RESURCEWORKER@SEL$2
   7 - SEL$58A6D7F6 / TASKUSESRESURCE@SEL$1
   8 - SEL$58A6D7F6 / TASKUSESRESURCE@SEL$1
   9 - SEL$58A6D7F6 / TASK@SEL$1
10 - SEL$58A6D7F6 / TASK@SEL$1
11 - SEL$7EBCC247 / TRW@SEL$3
12 - SEL$7EBCC247
13 - SEL$7EBCC247 / TUR@SEL$4
14 - SEL$6        / TRW_IN@SEL$5
15 - SEL$6
16 - SEL$6        / TWH@SEL$6
Predicate Information (identified by operation id):
   1 - access("TRW"."RESURCE_ID"(+)="TASKUSESRESURCE"."RESURCE_ID" AND "TRW"."TASK_ID"(+)="TASK"."ID")
   6 - access("RESURCEWORKER"."USER_PRINCIPAL_NAME"=U'jernej')
   8 - access("TASKUSESRESURCE"."RESURCE_ID"="RESURCEWORKER"."ID")
10 - access("TASKUSESRESURCE"."TASK_ID"="TASK"."ID")
12 - access("TUR"."RESURCE_ID"(+)="TRW_IN"."RESURCE_ID" AND "TUR"."TASK_ID"(+)="TRW_IN"."TASK_ID")                                                                                                                                                                                                         Jonathan, I've been to one of your workshops in Ljubljana. I'm still trying to understand everything you explained and use it, but there's much I have to learn and understand.
The way I see this query it should fist join and filter the first three tables and only then join the trw subquery. The problem with this subqrey is task_work_history table, which is accessed in very different ways in different places, so there will always be many reads to gather required data. For now, however, I'd be hapy to just bring the performance of inner join to left join...

Relationship between tables while using inner joins.

Hi,
I had a few clarifications on "inner joins", and as i was going through the forum, i came across two points,
1. In one of the threads it said " inner joins is applicable for tables that have a parent child relationship.
2. In another thread it said " inner join is established from master table (the table on the left) to the transcation table (the table on the right)".
I have two clarifications based on the above points.
1. Is it necessary that the tables on which im performing an inner join should have a parent-child/children relationship or is it enough that the tables just have a common field.
2. Also is it necessary that the master table should come first, (or can i use any child table from where i can fetch the records when there is a mater table in my report) as shown below.
Eg: select * <fields> from <master table> inner join <table> on <field> into <itab>.
Edited by: Narayananchandran on Dec 27, 2010 12:31 PM

have two clarifications based on the above points.
1. Is it necessary that the tables on which im performing an inner join should have a parent-child/children relationship or is it enough that the tables just have a common field.
2. Also is it necessary that the master table should come first, (or can i use any child table from where i can fetch the records when there is a mater table in my report) as shown below.
Eg: select * <fields> from <master table> inner join <table> on <field> into <itab>
1) NO
2) NO

Help:Nested Inner Join

Hello Folks,
I have a query which has a nested Inner Join as follows
INNER JOIN(Client
INNER JOIN CUBS SNAPSHOT ON Client . Client = CUBS SNAPSHOT . CLIENT) ON CancelDesc . CancelReason = CUBS SNAPSHOT . CANCELREASONcouldnt figure out wat is the quivalent of this nested inner join in Oracle Server. I am trying to create a report based on this inner join of a query. Can anyone throw some light on this.
Thanks

Hi,
Inner joins don't need to be nested. The results will be the same, no matter in what order the tables are joined.
In Oracle, don't use table names with spaces in them, and don't put spaces before or after the dots that separate table name qualifiers from column names.
I think this is what you want:
INNER JOIN     cubs_snapshot ON     CancelDesc.CancelReason = cubs_snapshot.cancelreason
INNER JOIN     Client            ON     Client.Client           = cubs_snapshot.clientWhenever you have a question, post a little sample data (CREATE TABLE and INSERT statememts) for all tables invlovled, and the results you want from that data.
If you really did need to nest joins, you could join some tables in a sub-query, then use the result set of that sub-query as if it were a table.
For example:
WITH cubs_and_client            AS
     SELECT     CancelReason
     ,     ...     -- Whatever other columns are needed in superior query or queries
     FROM          client
     INNER JOIN     cubs_snapshot     ON     Client.Client           = cubs_snapshot.client
SELECT
INNER JOIN     cubs_and_client     ON     CancelDesc.CancelReason = cubs_and_client.CancelReason
...In this example, the two tables cubs_snapshot and client are joined in a sub-query. The results of that sub-query can be referenced later in the query as if it were a table called cubs_and_client, very much like a view.

Help: Modifying inner join

Hello Folks,
I have an Access Query and am rewriting the whole query in Oracle to run a report.The thing is Am a beginner in oracle and am scratching my head on how to modify this inner join. please help me in rewriting this inner join in oracle. thanks a million
   ((Debtor INNER JOIN MAX_TRANS_DATE AS MAX_TRANS_DATE_1 ON Debtor .
        EVENT_ID = MAX_TRANS_DATE_1.EVENT_ID) INNER JOIN
        TMP$ALL_RECOVERY_TYPE
        ON(Debtor . EVENT_CASE_ID = TMP$ALL_RECOVERY_TYPE . EVENT_CASE_ID) AND
        (Debtor . EVENT_ID = TMP$ALL_RECOVERY_TYPE . EVENT_ID))
INNER JOIN CUBS TRANSACTIONS
    ON (Debtor . EVENT_ID = CUBS TRANSACTIONS . EVENT_ID)
   AND (Debtor . EVENT_CASE_ID = CUBS TRANSACTIONS . EVENT_CASE_ID)

Thanks for getting back. But still am unable to get the correct data. I will try to break it down.
Microsoft Access Table MAX_TRANS_DATE menitoned above in the inner join was originally coming from table called TRANSACTIONS i.e.( MAX_TRANS_DATE = SELECT [Transactions].[EVENT_ID], Max([Transactions].[TRANSDATE]) AS MaxOfTRANSDATE
FROM Debtor INNER JOIN Transactions ON [Debtor].[EVENT_ID]=[Transactions].[EVENT_ID]
GROUP BY [Transactions].[EVENT_ID];
Here the problem is am recreating the access database query in oracle database and we dont have MAX_TRANS_DATE in the Oracle database but we do have TRANSACTIONS table.
So i just used TRANSACTIONS in the inner join instead of MAX_TRANS_DATE.
But the result is wrong.The Field Transdate from TRANSACTIONS is pulling dates as 10/5/2006 instead of 02/01/2010. I suspect something is wrong with the joins.Please help me. I can provide the old access query and the new oracle query that i have created.
Thanks
Edited by: user11961230 on Mar 5, 2010 11:49 AM

Alternate for inner join to improve performance

Hi all,
I have used an inner join query to fetch data from five different tables into an internal table with where clause conditions.
The execution time is almost 5-6 min for this particular query(I have more data in all five DB tables- more than 10 million records in every table).
Is there any alternate for inner join to improve performance.?
TIA.
Regards,
Karthik

Hi All,
Thanks for all your interest.
SELECT a~object_id a~description a~descr_language
            a~guid AS object_guid a~process_type
            a~changed_at
            a~created_at AS created_timestamp
            a~zzorderadm_h0207 AS cpid
            a~zzorderadm_h0208 AS submitter
            a~zzorderadm_h0303 AS cust_ref
            a~zzorderadm_h1001 AS summary
            a~zzorderadm_h1005 AS summary_uc
            a~zzclose_date     AS clsd_date
            d~stat AS status
            f~priority
            FROM crmd_orderadm_h AS a INNER JOIN crmd_link AS b ON a~guid = b~guid_hi
            INNER JOIN crmd_partner AS c ON b~guid_set = c~guid
            INNER JOIN crm_jest AS d ON objnr = a~guid
            INNER JOIN crmd_activity_h AS f ON f~guid = a~guid
            INTO CORRESPONDING FIELDS OF TABLE et_service_request_list
            WHERE process_type IN lt_processtyperange
            AND   a~created_at IN lt_daterange
            AND   partner_no IN lr_partner_no
            AND   stat IN lt_statusrange
            AND   object_id IN lt_requestnumberrange
            AND   zzorderadm_h0207 IN r_cpid
            AND   zzorderadm_h0208 IN r_submitter
            AND   zzorderadm_h0303 IN r_cust_ref
            AND   zzorderadm_h1005 IN r_trans_desc
            AND   d~inact = ' '
            AND   b~objtype_hi = '05'
            AND   b~objtype_set = '07'.
            f~priority
            FROM crmd_orderadm_h AS a INNER JOIN crmd_link AS b ON a~guid = b~guid_hi
            INNER JOIN crmd_partner AS c ON b~guid_set = c~guid
            INNER JOIN crm_jest AS d ON objnr = a~guid
            INNER JOIN crmd_activity_h AS f ON f~guid = a~guid
            INTO CORRESPONDING FIELDS OF TABLE et_service_request_list
            WHERE process_type IN lt_processtyperange
            AND   a~created_at IN lt_daterange
            AND   partner_no IN lr_partner_no
            AND   stat IN lt_statusrange
            AND   object_id IN lt_requestnumberrange
            AND   zzorderadm_h0207 IN r_cpid
            AND   zzorderadm_h0208 IN r_submitter
            AND   zzorderadm_h0303 IN r_cust_ref
            AND   zzorderadm_h1005 IN r_trans_desc
            AND   d~inact = ' '
            AND   b~objtype_hi = '05'
            AND   b~objtype_set = '07'.

INNER JOIN with FOR ALL ENTRIES IN Performance ?

I am using following the following Select using Inner join with For All Entries in.
 SELECT kebeln kebelp kvbeln kvbelp
 FROM ekkn AS k INNER JOIN ekbe AS b ON kebeln = bebeln
 AND kebelp = bebelp
 INTO TABLE gi_purchase
 FOR ALL ENTRIES
 IN gi_sales
 WHERE k~mandt EQ sy-mandt
 AND k~vbeln EQ gi_sales-vbeln
 AND k~vbelp EQ gi_sales-posnr
 AND b~budat EQ p_date.
If i am not doing inner join then I will have to do 2 select with for all entries in on ekkn and ekbe tables and then compare them.
I want to know which one has better performance
Inner join with for all entries in
 or
2 Selects with for all entries in

the join is almost aways faster:
<a href="/people/rob.burbank/blog/2007/03/19/joins-vs-for-all-entries--which-performs-better">JOINS vs. FOR ALL ENTRIES - Which Performs Better?</a>
<a href="http://blogs.ittoolbox.com/sap/db2/archives/for-all-entries-vs-db2-join-8912">FOR ALL ENTRIES vs DB2 JOIN</a>
Rob

Inner Join with For All Entries - Performance ?

I am using following the following Select using Inner join with For All Entries in.
 SELECT kebeln kebelp kvbeln kvbelp
 FROM ekkn AS k INNER JOIN ekbe AS b ON kebeln = bebeln
 AND kebelp = bebelp
 INTO TABLE gi_purchase
 FOR ALL ENTRIES
 IN gi_sales
 WHERE k~mandt EQ sy-mandt
 AND k~vbeln EQ gi_sales-vbeln
 AND k~vbelp EQ gi_sales-posnr
 AND b~budat EQ p_date.
If i am not doing inner join then I will have to do 2 select with for all entries in on ekkn and ekbe tables and then compare them.
I want to know which one has better performance
Inner join with for all entries in
 or
2 Selects with for all entries in

An Inner Join with for all entries should be done if you add this....
IF NOT gi_sales[] IS INITIAL.
SELECT k~ebeln k~ebelp k~vbeln k~vbelp
FROM ekkn AS k INNER JOIN ekbe AS b ON k~ebeln = b~ebeln
AND k~ebelp = b~ebelp
INTO TABLE gi_purchase
FOR ALL ENTRIES
IN gi_sales
WHERE k~mandt EQ sy-mandt
AND k~vbeln EQ gi_sales-vbeln
AND k~vbelp EQ gi_sales-posnr
AND b~budat EQ p_date.
ENDIF.
Also, while you use an index or the complete key for the SELECT, your not going to suffer from lack of performance -;)
Greetings,
Blag.

Does INNER JOIN work with Oracle 8i ? (ORA-00933)

hi,
I try to execute the sql:
SELECT
A0.FULL_NAME,A0.MANAGER_ID,A0.DEPT_NO,A0.TOP_DEPT
FROM
HR_ORG A0
INNER JOIN
HR_EMP A1
ON
A0.MANAGER_ID=A1.EMP_NO
WHERE
A1.NAME = 'michael'
but I caught an exception:
java.sql.SQLException: ORA-00933: SQL...(message in
chinese)
Does INNER JOIN work with Oracle 8i ?
thanks.

INNER JOIN syntax is introduced in 9i, it does not exists in 8i. You can rewrite your statement:
SELECT
A0.FULL_NAME,A0.MANAGER_ID,A0.DEPT_NO,A0.TOP_DEPT
FROM
HR_ORG A0
, HR_EMP A1
WHERE
A0.MANAGER_ID=A1.EMP_NO
AND
A1.NAME = 'michael'

Perform an Inner Join in Oracle 8

Similar Messages

Maybe you are looking for