Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

The Select Query

Former Member
0 Likes
537

Hi All,

SELECT matnr FROM mara INTO TABLE gt_mara

WHERE matnr IN s_matnr

AND mtart = p_mtart.

IF NOT gt_mara[] IS INITIAL.

SORT gt_mara BY matnr.

SELECT aufnr objnr aufpl FROM caufv INTO TABLE gt_caufv

FOR ALL ENTRIES IN gt_mara

WHERE aufnr IN s_aufnr

AND auart = p_auart

AND werks = p_werks

AND plnbez = gt_mara-matnr.

ENDIF.

I have replaced the above for all entries query by the below inner join. Found in the debugg both have same number of records in the (DEV server). Performance wise also this one is better. Let me know both are exactly same or not.

SELECT a~matnr

b~aufnr

b~objnr

b~aufpl

INTO TABLE gt_caufv FROM mara AS a INNER JOIN caufv AS b

ON amatnr = bplnbez WHERE matnr IN s_matnr

AND mtart =<b> p_mtart</b>

AND aufnr IN s_aufnr

AND auart = p_auart

AND werks = p_werks.

My concern with the join is <b>amatnr = bplnbez</b> is whether this will give me unique records or duplicate records. It seems to be good and unique in the DEV but not sure about the PROD server . Kindly Clarify.

Thanks,

4 REPLIES 4
Read only

Former Member
0 Likes
490

Hi,

You can carry on with the second query as it will create no problem and performance wise also it is more efficient.

Since u r selecting from mara based on only matnr and all the other conditions in the second itab is based on input parameters ,always the record will be unique.

Also remember to change the query like this.

SELECT a~matnr

b~aufnr

b~objnr

b~aufpl

INTO TABLE gt_caufv FROM mara AS a INNER JOIN caufv AS b

ON amatnr = bplnbez WHERE <b>a~</b>matnr IN s_matnr

AND <b>a~</b>mtart = p_mtart

AND <b>b~</b>aufnr IN s_aufnr

AND <b>b~</b>auart = p_auart

AND <b>b~</b>werks = p_werks.

Read only

0 Likes
490

Sounds Good.

Thanks,

S

Read only

0 Likes
490

Anju's answer is incorrect, since it does not take into account the possibility of duplicates in the join due to the material appearing on different orders in CAUFV, which will NOT occur with FOR ALL ENTRIES.

They are NOT always the same.

Good luck

Brian

null

Read only

Former Member
0 Likes
490

The join by itself will allow duplicate records if they exist, since the same material could exist in more than one order.

However, the FOR ALL ENTRIES addition de-dups the result set; this is a feature of FOR ALL ENTRIES. This forces the original to be distinct apart from any other consideration.

If you want to guarantee the records are unique, why not just add DISTINCT?

e.g.

      SELECT DISTINCT
             a~matnr
             b~aufnr
             b~objnr
             b~aufpl
             INTO TABLE gt_caufv
             FROM mara AS a
             INNER JOIN caufv AS b
             ON a~matnr = b~plnbez
             WHERE matnr IN s_matnr
               AND mtart = p_mtart
               AND aufnr IN s_aufnr
               AND auart = p_auart
               AND werks = p_werks.

Alternatively, you could SORT the resulting itab and DELETE ADJACENT DUPLICATES.

In the case of DISTINCT, the sorting and deleting of duplicates occurs on the database server; in the case of explicit SORT and DELETE ADJACENT DUPLICATES, it occurs on the application server. This may be a consideration for performance.

Lastly, the join and FOR ALL ENTRIES are different in one other way.

If the itab gt_mara in FOR ALL ENTRIES is empty, the WHERE clause is ignored and the whole table is loaded. This is a feature of FOR ALL ENTRIES, which you can confirm in SAP HELP. If this is not the behavior that you expect, you need to check for it.

Good luck.

Brian

Edited for spelling, wording

Message was edited by:

Brian Sammond