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

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 on bkpf and bsid

Hi Experts ,
I want to do an inner join on bsid and bkpf tables in the select query . I want to order the result on the basis of cputm field in bkpf , that is why inner join on bkpf is req , rest all the fields are from bsid . But the requirement is that we should not select the cputm field in the select , it is only to be used for sorting the result of the select query . we are also using select * from bsid where ...... endselect . and not specific fields from bsid currently . Kindly let me know how to use the inner join on bkpf and bsid in this case .
Would reward all helpful answers .
Thanks

Hi Ankit,
First make a structure of the required fields.
TABLES : bkpf,bsid.
TYPES : BEGIN OF x_tab,
          belnr like bkpf-belnr,
          kunnr like bsid-kunnr,
          bldat like bsid-bldat,
          budat like bsid-budat,
          waers like bsid-waers,
      END OF x_tab.
DATA : itab type STANDARD TABLE OF x_tab,
        wa_itab TYPE x_tab.
start-of-SELECTION.
SELECT bkpfbelnr bsidkunnr bsidbldat bsidbudat bsid~waers into table itab
   FROM bkpf INNER JOIN bsid on bkpfbelnr = bsidbelnr and
                                bkpfbukrs = bsidbukrs and
                                bkpfgjahr = bsidgjahr.
Rewards Points, if useful.
Regards
Manoj Kumar
Edited by: Manoj Kumar on Dec 26, 2007 2:36 PM

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]

Inner join in ABAP and exporting the data

Hi,
I want to use inner join in ABAP for retrieving data from 2 tables and export that data.How will i do it?

Hi,
Refer following code
*--Select query to pick the data from table VBRK
VBRP and VBPA using inner join
SELECT a~vbeln                            "Billing document
         a~fkdat                            "Billing date
         a~fktyp                            "Billing category
         a~fkart                            "Billing type
         a~vtweg                            "Distribution channel
         a~knumv                            "Number of doc condition
         b~posnr                            "Billing item
         b~matnr                            "Material Number
         b~werks                            "Plant
         b~vgbel                            "Referance
         b~netwr                            "Net value of billing item
         b~wavwr                            "Cost in document currency
         c~kunnr                            "Partner function
         FROM vbrk AS a
         INNER JOIN vbrp AS b
         ON avbeln EQ bvbeln
         INNER JOIN vbpa AS c
         ON bvbeln EQ cvbeln
        AND bposnr EQ cposnr
         INTO CORRESPONDING FIELDS OF TABLE it_vbrp
         WHERE fkdat IN s_erdat
         AND   parvw EQ 'ZS'.
IF sy-subrc EQ 0.
*--Sort table by
    SORT it_vbrp BY vgbel1.
ENDIF.
Regards,
Prashant

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

Inner join between OBOE and OBOT

Hi all,
I am trying to query these tables, but for all the system displays data from these tables in only one windows, MSQL does not inner join this tables.
So, we are looking for the relation in these two tables, or between OBOE and JDT1/OJDT would be enought.
Thanks and regards,
Javier Zapata

Hi,
i'm not sure but you can try to use the table BOT1 (Bill of Exchange Transactions details).
Here you can find the field AbsEntry (related to the table OBOT) and the field BOENumber (related to OBOE table).
Hope this helps
Regards,
Fabio Salucci

Issue with the inner join on EKKO and EKPO.

Dear All,
The report using this join takes a long time to execute.
Does this inner join have an issue?
Do i need to code this in a different way for lesser execution time?
Please give me your inputs.
SELECT
        a~ebeln
        b~ebelp
        a~bukrs
        a~bstyp
        a~bsart
        a~ekorg
        a~ekgrp
        a~kdatb
        a~kdate
        FROM ekko AS a JOIN ekpo AS b
        ON aebeln = bebeln
        INTO TABLE t_ekpo
        WHERE
        a~bukrs EQ p_bukrs
        AND a~bstyp EQ c_k
        AND a~bsart IN s_bsart
        AND a~ekorg IN s_ekorg
        AND a~ekgrp IN s_ekgrp
        AND a~kdate GE s_fdate-low
        AND a~loekz EQ space
        AND b~loekz EQ space.
Regards,
SuryaD.

Index EKKO~D consists top-down of BSTYP and BEDAT. BSTYP is already an EQ-condition in your selection, but not very selective (many rows with the same value). So including BEDAT should help in efficiently reducing the data that needs to be scanned for finding the relevant rows. However, just a new optional S_BEDAT select option that can be left empty by the user would not help, you must force a narrow selection (one month, one week, even one day? the less the better).
This is just a quick guess from my side, there might be other options that occur to you once you have analysed the available indexes. Sometimes alternative tables could be the solution, and even less sometimes introducing a new secondary index for a standard table might be the last option (takes up space and adds processing time to insert/update/delete operations).
Thomas

How do I perform a meaningful join on monSysStatement and monSysSQLText?

I'm having difficulty understanding the relationship between records in the monSysStatement table and the monSysSQLText. Generally speaking, monSysStatement appears to contain statistics on SQL statements, while monSysSQLText contains the corresponding text. However, I've not been able to find any clear documentation on which fields connect the two.
I'm looking for something like the following: (SQL Text, CPU Time, Memory Usage)

You're (obviously?) going to be limited to SPID/KPID/InstanceID/BatchID.
Keep in mind that a 'batch' of SQL text could include many statements, eg:
=================== 1 batch, 5 statements
declare @a int
select @a = 5
select @a = @a + @@maxpagesize
select getdate()
select 'get me out of here'
go
=================== 1 batch, # of statements depends on size of mycur result set
declare @myvalue varchar(100)
open mycur
fetch mycur into @myvalue
while @@sqlstatus = 0
begin
... do something with @myvalue
fetch mycur into @myvalue
end
close mycur
go
===================
SQL text is stored as a batch (not as individual statements) in monSysSQLText, so there's no easy way to match a statement to a line of SQL text. (I'm not saying it can't be done with some additional T-SQL programming ... it's just not doable with the current MDA table column definitions.)

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

Link for BUT000 table and ADRC in CRM and inner join is not working in PCUI

Hi Gurus,
   Please tell me the link btween BUT000 and ADRC table. and i wrote one inner join between BUT000 and BUT0id table but it not working. I m in CRM 4.0 version working with PCUI.
select but000partner but000name_org1 but000name_org2 but000bus_sort1 but0id~parnter1
      but0ididnumber from but000 inner join but0id on but0idpartner = but000~parnter
into corresponding fields of table it_result where partner in s_partner.
It is giving error as partner unknown from but000 table. I delcared everything and tried with alias names also.
please clarify me.
regards,
Ramakrishna.

Hi Frederic,
   thanks a lot. But is inner join between BUT000 and BUT0ID will work. for me it is not working. plesae see this code.
tables : but000,
         but0id,
         crmm_but_custno,
         adrc.
types : begin of typ_but000,
        partner type bu_partner,
        name_org1 type BU_NAMEOR1,
        name_org2 type BU_NAMEOR2,
        bu_sort1 type BU_SORT1,
        idnumber type BU_ID_NUMBER,
        partner1 type bu_partner,
        end of typ_but000.
data: lt_but000 type table of typ_but000,
      ls_but000 like line of lt_but000.
*select-options : s_partnr for but000-partner.
start-of-selection.
      select but000partner but000name_org1 but000name_org2 but000bu_sort1 but0id~parnter1
                but0id~idnumber into corresponding fields of table lt_but000 from but000
                inner join but0id on but0idpartner = but000parnter. " where partner in s_partner.
it is giving error as but000-partner is not know or but0id-partner not known.
So, i think if it not works then i should write two select stmts.
please clarify me.
i gave u rating.
thanks
ramakrishna.

Need help with inner join and distinct rows

Hey Guys,
i have
1) BaseEnv Table
2) Link Table
3) BaseData Table
Link table has three columns Id,BaseEnvId,BaseDataId
the BaseEnvID is unique in the table where as BaseDataId can be repeated i.e multile rows of BaseEnv Table can point to same BaseData table row
Now i want to do BaseEnvTable inner join Link Table inner join BaseData Table and select 5 columsn ; Name,SyncName,Version,PPO,DOM from the BaseData table.. the problem is that after i do the inner join I get duplciate records..
i want to eliminate the duplicate records , can any one help me here

Please post DDL, so that people do not have to guess what the keys, constraints, Declarative Referential Integrity, data types, etc. in your schema are. Learn how to follow ISO-11179 data element naming conventions and formatting rules. Temporal data should
use ISO-8601 formats. Code should be in Standard SQL as much as possible and not local dialect.
This is minimal polite behavior on SQL forums. Now we have to guess and type, guess and type, etc. because of your bad manners.
CREATE TABLE Base_Env
(base_env_id CHAR(10) NOT NULL PRIMARY KEY,
Think about the name Base_Data; do you have lots of tables without data? Silly, unh?
CREATE TABLE Base_Data
(base_data_id CHAR(10) NOT NULL PRIMARY KEY,
Your Links table is wrong in concept and implementation. The term “link” refers to a pointer chain structure used in network databases and makes no sense in RDBMS. There is no generic, magic, universal “id” in RDBMS! People that do this are called “id-iots”
in SQL slang.
We can model a particular relationship in a table by referencing the keys in other tables. But we need to know if the relationship is 1:1, 1:m, or n:m. This is the membership of the relationship. Your narrative implies this:
CREATE TABLE Links
(base_env_id CHAR(10) NOT NULL UNIQUE
REFERENCES Base_Env (base_env_id),
base_data_id CHAR(10) NOT NULL
REFERENCES Base_Data (base_data_id));
>> The base_env_id is unique in the table where as base_data_id can be repeated I.e multiple rows of Base_Env Table can point [sic] to same Base_Data table row. <<
Again, RDBMS has no pointers! We have referenced an referencing tables. This is a fundamental concept.
That narrative you posted has no ON clauses! And the narrative is also wrong. There is no generic “name”, etc. What tables were used in your non-query? Replace the ?? in this skeleton:
SELECT ??.something_name, ??.sync_name, ??.something_version,
??.ppo, ??.dom
FROM Base_Env AS E, Links AS L, Base_Data AS D
WHERE ?????????;
>> I want to eliminate the duplicate records [sic], can any one help me here?<<
Where is the sample data? Where is the results? Please read a book on RDBMS so you can post correct SQL and try again.
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL

How to re-write this big SELECT Query with INNER JOINs?

Hi Experts
I have a performance killer SELECT query with an inner join of 3 tables u2013 VBAP, VBAK and VBEP together, which populates records to an internal table INT_COLL_ORD. Based on these records selected, in another SELECT query, records are fetched from VBUK table to the internal table INT_VBUK.
SELECT A~VBELN A~POSNR A~MATNR A~KWMENG A~KBMENG A~ERDAT A~ERZET A~PSTYV D~AUART E~ETTYP E~EDATU
INTO TABLE INT_TAB_RES
FROM VBAP AS A INNER JOIN VBAK AS D
ON D~VBELN EQ A~VBELN AND D~MANDT EQ A~MANDT
INNER JOIN VBEP AS E
ON E~VBELN EQ A~VBELN AND E~POSNR EQ A~POSNR AND E~MANDT EQ A~MANDT
WHERE A~VBELN IN s_VBELN AND
       D~auart in s_auart AND
       D~vkorg in s_vkorg AND
       D~vbtyp eq 'C'     AND
       ( ( matnr LIKE c_prefix_sp AND zz_msposnr NE 0 AND kbmeng EQ 0 )
       OR ( matnr LIKE c_prefix_fp AND kwmeng NE A~kbmeng ) ) AND
       A~ABGRU EQ SPACE AND
       A~MTVFP IN R_MTVFP AND
       A~PRCTR IN R_PRCT AND
       E~ETENR EQ '1'.
SORT INT_COLL_ORD BY VBELN POSNR ETTYP.
DELETE ADJACENT DUPLICATES FROM INT_TAB_RES COMPARING VBELN POSNR.
CHECK NOT INT_TAB_RES [] IS INITIAL.
SELECT VBELN UVALL CMGST INTO TABLE INT_VBUK
FROM VBUK FOR ALL ENTRIES IN INT_TAB_RES
WHERE VBELN = INT_TAB_RES-VBELN AND UVALL NE 'A'.
Now, the requirement is:
I want to split this query. Like, first join VBAK and VBUK first. With this selection, go to the inner join of VBAP and VBEP (on key VBELN) to get the results. How can I re-write this Query?
Please help.
Thx n Rgds

Hi Nagraj
As of your suggestion, I have re-written the query as below:
* Declarations
TYPES: BEGIN OF TYP_COLL_ORD,
        VBELN LIKE VBAK-VBELN,
        POSNR LIKE VBUP-POSNR,
        MATNR LIKE VBAP-MATNR,
        KWMENG LIKE VBAP-KWMENG,
        KBMENG LIKE VBAP-KBMENG,
        ERDAT LIKE VBAK-ERDAT,
        ERZET LIKE VBAK-ERZET,
        PSTYV LIKE VBAP-PSTYV,
        AUART LIKE VBAK-AUART, u201Calready exists in type
        ETTYP LIKE VBEP-ETTYP,
        EDATU LIKE VBEP-EDATU.
TYPES: END OF TYP_COLL_ORD.
DATA: INT_COLL_ORD TYPE TABLE OF TYP_COLL_ORD WITH HEADER LINE.
TYPES: BEGIN OF TYP_VBUK,
        AUART LIKE VBAK-AUART, u201Chave added this field
        VBELN LIKE VBUK-VBELN,
        UVALL LIKE VBUK-UVALL,
        CMGST LIKE VBUK-CMGST.
TYPES: END OF TYP_VBUK.
DATA: INT_VBUK TYPE TABLE OF TYP_VBUK WITH HEADER LINE.
*QUERY#1 u2013 for VBAK & VBUK Join
SELECT A~AUART B~VBELN B~UVALL B~CMGST
INTO TABLE INT_VBUK
FROM VBAK AS A INNER JOIN VBUK AS B
ON A~VBELN EQ B~VBELN
WHERE A~VBELN IN s_VBELN AND
A~auart in s_auart AND
A~vkorg in s_vkorg AND
A~vbtyp eq 'C' AND
B~UVALL NE 'A'.
IF NOT INT_VBUK[] IS INITIAL.
SORT INT_VBUK BY VBELN.
DELETE ADJACENT DUPLICATES FROM INT_VBUK COMPARING VBELN.
*QUERY#2 u2013 for VBAP & VBEP Join
SELECT A~VBELN A~POSNR A~MATNR A~KWMENG A~KBMENG A~ERDAT A~ERZET A~PSTYV B~ETTYP B~EDATU
INTO TABLE INT_COLL_ORD
FROM VBAP AS A INNER JOIN VBEP AS B
ON B~VBELN EQ A~VBELN AND B~POSNR EQ A~POSNR AND B~MANDT EQ A~MANDT
FOR ALL ENTRIES IN INT_VBUK
WHERE A~VBELN = INT_VBUK-VBELN AND
( ( matnr LIKE c_prefix_sp AND zz_msposnr NE 0 AND kbmeng EQ 0 )
OR ( matnr LIKE c_prefix_fp AND kwmeng NE A~kbmeng ) ) AND
A~ABGRU EQ SPACE AND
A~MTVFP IN R_MTVFP AND
A~PRCTR IN R_PRCT AND
B~ETENR EQ '1'.
ENDIF.
SORT INT_COLL_ORD BY VBELN POSNR ETTYP.
DELETE ADJACENT DUPLICATES FROM INT_COLL_ORD
    COMPARING VBELN POSNR.
CHECK NOT INT_COLL_ORD[] IS INITIAL.
LOOP AT INT_COLL_ORD.
    CLEAR: L_MTART,L_ATPPR,L_ETTYP.
    IF L_PREVIOUS_ETTYP NE INT_COLL_ORD-ETTYP OR
      L_PREVIOUS_AUART NE INT_COLL_ORD-AUART.
      READ TABLE INT_OVRCTL WITH KEY AUART = INT_COLL_ORD-AUART ETTYP = INT_COLL_ORD-ETTYP.
      CHECK SY-SUBRC NE 0.
Now, the issue is:
Please note that declaration for INT_COLL_ORD has a field AUART, which is used in further parts of program (see the statement just above)
But, since neither VBAP nor VBEP contains AUART field, it cannot be fetched through the QUERY#2. So this value is not populated into INT_COLL_ORD through SELECT Query.
Since this field is used in later part of program & that the internal table has no value for this field, it dumps!!
How to include this value into the INT_COLL_ORD?
Plz suggest....

Poor Performance on Inner Join of VBUP and VBAK

Similar Messages

Maybe you are looking for