Application Development 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: 

Missing Entries in FOR ALL ENTRIES Select Quuery

mritiz
Explorer
0 Kudos
1,042

Hi All,

I'm using Tables CDHDR and CDPOS.

Fetching data from CHDHR first using -

SELECT * FROM cdhdr INTO TABLE lt_changed_hdr WHERE objectclas = 'DEBI' AND
udate GE v_last_run_date AND
change_ind = 'U'.

Thereafter using the FOR ALL ENTRIES Query on CDPOS.

SELECT * FROM cdpos INTO TABLE lt_changed_itm FOR ALL ENTRIES IN lt_changed_hdr
WHERE objectclas = lt_changed_hdr-objectclas AND
objectid = lt_changed_hdr-objectid AND
changenr = lt_changed_hdr-changenr AND
tabname IN ('KNA1', 'KNB1', 'CDPOS').

When running the query for the single missing customer its appearing in the output.

But when running the query for set of customer's the entries goes missing, unable to figure out the issue involved here.

Also the missing entries are picked up CDHDR but not by CDPOS.

Need suggestions why is this happening.

Thanks & Regards,

Ritiz

12 REPLIES 12

BaerbelWinkler
Active Contributor
893

mritiz

Hi Ritiz,

please use the "CODE" option to embed your ABAP-Code into your question as this makes it a lot easier to read for others. You can simply update your question to do that.

Thanks!

Bärbel

DominikTylczyn
Active Contributor
893

Why don't you simply join CDHDR and CDPOS instead of using FOR ALL ENTRIES?

matt
Active Contributor
893

3a9e4ce873a94034b33dc62b0ce600ee if it's an older system where these are still cluster tables, it's not allowed.

mritiz
Explorer
0 Kudos
893

matthew.billingham so you're saying if these tables are Cluster/Pool Tables then inner join condition won't work?

turkaj
Active Participant
0 Kudos
893

Hi Ritiz,

One possible reason could be directly the use of the clause FOR ALL ENTRIES. This clause only selects records from the cdpos table that have matching records in the lt_changed_hdr table based on the specified conditions. If there are no matching records in the table lt_changed_hdr for some customers, these records will not be selected from the table cdpos.

Another possible reason could be related to the data in the table cdpos itself. It is possible that some entries are missing or incomplete, which can lead to them not being selected by the query.

To troubleshoot, you could try running the query for a single customer and compare the results with those you get when you run the query for a group of customers. You could also try checking the data in the cdpos table to see if any entries are missing or incomplete.


Regards
Jim

thkolz
Contributor
893

It's better to do a join.
I try to avoid FOR ALL ENTRIES...

SELECT * FROM cdhdr JOIN cdpos ON cdpos~objectid = cdhdr~objectid AND  
                                  cdpos~changenr = cdhdr~changenr
  INTO TABLE @DATA(lt_changed)
  WHERE cdhdr~objectclas = 'DEBI'
    AND cdhdr~udate      >= @v_last_run_date
    AND cdhdr~change_ind = 'U'
    AND cdpos~tabname    IN ( 'KNA1', 'KNB1', 'CDPOS' ).

893

Yes, that's correct. But the problem is client is using an old version of SAP (<7.31), where CDHDR and CDPOS are still Cluster table.

0 Kudos
893

Understood!

How does your table lt_change_pos looks like?

Is it TYPE STANDARD TABLE OF cdpos?


At least it should contain all key fields of CDPOS…

DominikTylczyn
Active Contributor
0 Kudos
893

matthew.billingham That would have to be a really old system, wouldn't it? Out of curiosity, do you know when CDPOS was converted to a transparent table?

matt
Active Contributor
893

3a9e4ce873a94034b33dc62b0ce600ee Some of our customers still use 7.31 (and older!), where CDPOS is a cluster table. I just checked 7.40 and it is a transparent table there.

mritiz I'm say if your CDPOS is a cluster table, you can't use SELECT with INNER JOIN.

thkolz
Contributor
893

Just created a small report in our old ECC system.
To me it seems to work like that...
I guess it's important that lt_changed_hdr and lt_changed_pos contain all key fields of CDHDR/CDPOS.

REPORT ztest.

DATA:
lt_tables_r TYPE RANGE OF tabname,
lt_changed_hdr TYPE STANDARD TABLE OF cdhdr,
lt_changed_pos TYPE STANDARD TABLE OF cdpos.

PARAMETERS p_date TYPE d OBLIGATORY.

FIELD-SYMBOLS <fs_tables_r> LIKE LINE OF lt_tables_r.

APPEND INITIAL LINE TO lt_tables_r ASSIGNING <fs_tables_r>.
<fs_tables_r>-sign = 'I'.
<fs_tables_r>-option = 'EQ'.
<fs_tables_r>-low = 'KNA1'.
APPEND INITIAL LINE TO lt_tables_r ASSIGNING <fs_tables_r>.
<fs_tables_r>-sign = 'I'.
<fs_tables_r>-option = 'EQ'.
<fs_tables_r>-low = 'KNB1'.
APPEND INITIAL LINE TO lt_tables_r ASSIGNING <fs_tables_r>.
<fs_tables_r>-sign = 'I'.
<fs_tables_r>-option = 'EQ'.
<fs_tables_r>-low = 'CDPOS'.

SELECT * FROM cdhdr INTO TABLE lt_changed_hdr WHERE objectclas = 'DEBI' AND udate >= p_date AND change_ind = 'U'.

IF lines( lt_changed_hdr ) = 0.
EXIT.
ENDIF.

SELECT * FROM cdpos
INTO TABLE lt_changed_pos FOR ALL ENTRIES IN lt_changed_hdr
WHERE objectclas = lt_changed_hdr-objectclas
AND objectid = lt_changed_hdr-objectid
AND changenr = lt_changed_hdr-changenr
AND tabname IN lt_tables_r.

cl_demo_output=>display( lt_changed_pos ).

BaerbelWinkler
Active Contributor
0 Kudos
893
mritiz

Could you please clarify what you mean by these statements?

  • When running the query for the single missing customer its appearing in the output. But when running the query for set of customer's the entries goes missing, unable to figure out the issue involved here.
  • Also the missing entries are picked up CDHDR but not by CDPOS.

I'm confused as there is no where-clause to select on OBJECTID which would contain the customer number (as stored on the database, not as displayed due to potential conversion exits).

Also: why do you include 'CDPOS' in the where-clause for TABNAME when selecting from CDPOS? There shouldn't be any entries in CDPOS where TABNAME = 'CDPOS' AND OBJECTCLAS = 'DEBI'.

Last but not least: it's better for various reasons to specify the fields you actually need for your procssing instead of using "SELECT *" which should be avoided as much as possible.