Runtime error ITAB_DUPLICATE_KEY due to declaration of internal table type hashed table

[Former Member]

Hi All,

I am facing runtime error  ITAB_DUPLICATE_KEY during retreving the data from the VBKD table into an internal table type hashed table.

Actually I am performing the following things..

Firstly I am retreving the data from the custom table into a internal table which is declared as TYPE STANDARD TABLE WITH DEFAULT KEY.

Upto this is fine..

Again retreving the data from the VBKD table for all entries in the above internal table into an another internal table which is declared as

TYPE HASHED TABLE WITH UNIQUE KEY VBELN.

I am getting runtime error as ITAB_DUPLICATE_KEY.

Whether is there any problem in the declaration of the second internal table?

And also for the VBKD table as I observe that there are 2 KEY fields which are VBELN and POSNR.

If the table contains 2 key fields, then whether can we declare the internal table like hashed table with unique key as 1 field  i.e VBELN?

Whether runtime error is due to the Declaration...?

I know if we declare the internal table as NON-UNIQUE KEY then runtime error wont occurs..

But I need to know whether I am declaring the internal tabel correctly i.e if there are 2 key fields can we declare unique key with 1 key field...If YES...then what was the reason for the runtime error.

Any suggestion will be appreciated.

Regards

Raj

[Former Member]

VBKD is a line item table.  It is pretty sure that if you select on vbeln, you will get more than 1 record per vbeln.

Neal

[Former Member]

HI,

Actually in my custom table the key fields are KUNNR,VBELN,ERDAT,MATNR

I am  retreving the data from the custom table based on the selction screen date and sorted internal table by VBELN but I did not delete the adjacent duplicates of VBELN.

And my second internal table as per the requirement I am declaring the internal table as shown below.

TYPES: BEGIN OF ty_vbkd,
vbeln TYPE vbkd-vbeln,
bstkd TYPE vbkd-bstkd,
END OF ty_vbkd,

it_vbkd type hashed table of ty_vbkd with unique key vbeln.

and I am retreving data from VBKD table for all entries in the above custom table.

Now if I wrote the adjacent duplicates from the first internal table comparing by VBELN is enough?

or I need to include the key filed POSNR also and declare the second internal table like shown below..

it_vbkd type hashed table of ty_vbkd with unique key vbeln posnr.

Actually the runtime error occurs in production and we are unable to replicate the scenario in the development client that was the big problem

otherwise i can write the code and test.

Suggestions appreciated.

Regards

Raj

.

[Former Member]

Option 1

Select single from the second table.  But that say that it doesn't mater which record of the duplicates you will pull.  Is that a true statement? What happens if there are 3 line items and each has a different bstkd?

I'm still thinking about other options [As time allows]

Neal

[tolga_polat]

you can do like this :

LOOP AT <first_table>
        INTO wa.
     ls_vbkd_hashed-bstkd = wa-bstkd." Because at new make other fields *
AT NEW VBELN.
     ls_vbkd_hashed-vbeln = <wa>-vbeln.
     INSERT ls_vbkd_hadhed
          INTO TABLE lt_vbkd_hashed.
     CLEAR : ls_vbkd_hashed.
ENDAT.
ENDLOOP.

Regards

Tolga

Message was edited by: Tolga POLAT

[Former Member]

Hi Polat,

Thanks for the reply...

Actually there is no bstkd field in the custom table..

So as per the logic given by you it wont work..

Actually my concern is declaration part only but not the coding part..

i.e. How to declare the internal table as type hashed table so that we can eliminate the runtime error..

Regards

Raj

[tolga_polat]

Hi Raj,

for dublicate error, you have to eliminate key fields dublication.

I give you example for your answer

"

And my second internal table as per the requirement I am declaring the internal table as shown below.

TYPES: BEGIN OF ty_vbkd,
vbeln TYPE vbkd-vbeln,
bstkd TYPE vbkd-bstkd,
END OF ty_vbkd,

it_vbkd type hashed table of ty_vbkd with unique key vbeln.

and I am retreving data from VBKD table for all entries in the above custom table.

"

with AT NEW or DELETE ADJACENT DUPLICATES FROM itab CONPARING f1 f2 f3 you can eliminate dublication.

For declaration if you dont want to use DELETE you have to add POSNR key field to your hashed table or just use DELETE comparing vbeln.

[Former Member]

Hi All,

Anyone knows the reason for going to dump.

Actually when i check in quality client for VBKD there are multiple entries for the saleorder number.

there the program executed correctly without having runtime error.

But what is the reason in PRD it is giving runtime error.

Suggestions Appreciated.

Regards

Raj

[Former Member]

You still haven't given us sufficient code to evaluate your question!

It is going to come down to :

VBKD has multiple records per vbeln

AND

Hashed itab's can not have duplicate keys in them!

You have to either only read one of the multiple records,

Combine the multiple records down to one,

OR extend the hashed key.

There are no other options.

Neal

PS: OR eliminate the hashed itab...

[tolga_polat]

Hi Raj,

you can declare both vbeln and posnr as key.

DATA : lt_vbkd TYPE HASHED TABLE OF vbkd WITH UNIQUE KEY vbeln posnr.

[Former Member]

Yes, the problem is with the second table declaration.  It is missing a key field, causing duplicate keys and then runtime errors.  Instead, declare your second table as:

DATA gt_vbkd TYPE HASHED TABLE OF vbkd

             WITH UNIQUE KEY vbeln posnr.

To clarify, hashed tables must have a unique key.  Sorted tables can have unique or non-unique keys.  Standard tables cannot have a unique key.

Best,

Eric

[Former Member]

Hi Raj,

I think you kind of know the issue yourself that data from one internal table with two key fields looks like duplicate entries for another table with just one key though its really not as they are from different line items. So, if you want to use key fields of internal table, you'll have to match thiem in case. But my question to you is.... do you really need Key fields in internal table? Can you not use a simple declaration without key fields?

Regards

Sachin

[Former Member]

Hi,

the advantage of an hash table is that the retrieving will be faster. this acually works like their will be hash function which will generate the index of the record you are searching for using the keys that you submit. Here in your table you have the primary key a combination key but in your internal table you have defined only one key. So there for when the hash internal table is searched using the particular it will find duplicate entries because in your actual table you have defined the key as a combination key

With regards

Suneesh

[Former Member]

Hi Raj,

When you check the table VBKD, you will find that there are multiple values for same primary key field(As it is not the header table). So, your declaration is fine but add other key fields available in the table.

Regards,

Shahir Mirza

[Former Member]

Hi Raj,

Since the vbkd is a line item table it will have multiple recorde per vbeln.

To correct this error first sort the first standard internal table by vbeln and remove adjacent duplicate entries comparing vbeln.

Now declare the hashed internal table with two unique keys VBELN and POSNR so that the combination only will be checked and avoids duplication.

Regards

Ashish Kumar,

Applexus Technologies

[Former Member]

hi raj kumar ,

"Firstly I am retreving the data from the custom table into a internal table which is declared as TYPE STANDARD TABLE WITH DEFAULT KEY. "

In this internal table you have to check whether there is a duplicate entry and you should delete it  .

" TYPE HASHED TABLE WITH UNIQUE KEY VBELN " .

Change it to TYPE HASHED TABLE WITH UNIQUE KEY VBELN POSNR.

Still you have the problem then it can be because of the below mentioned reason ..

With the SELECT statement, entries should be read into an internal table  of the type HASHED TABLE via the addition "INTO itab" or "APPENDING itab". The addition "FOR ALL ENTRIES" is also used.The result of a SELECT statement with the addition "FOR ALL ENTRIES"  could be built by the database interface in several portions.  Internally, temporary duplicates may arise. The internal elimination of the duplicates was incorrect.

[Former Member]

Hii

raj kumar

firstly

The problem is with the TYPE HASHED TABLE WITH UNIQUE KEY VBELN declaration.

Since VBKD is an item table with key fields VBELN and POSNR.But U have onlu mentioned VBELN in hashed table declaration and because of that getting duplicate entries.

So declarae the Internal table type hashed table with all combination of key dields.

secondly, before the FOR ALL ENTRIES

sort  the STANDARD TABLE WITH DEFAULT KEY by VBELN.

Next delete adjacent duplicates comparing the requirement fields.

then use for all entries.

Regards

Syed

[matt]

Once you've got your data declarations correct, don't use FOR ALL ENTRIES. Use an INNER JOIN instead.

For All Entries is old technology and should be avoided as much as possible. In nearly every case an INNER JOIN is more efficient than FOR ALL ENTRIES. Inner join usually provides for simpler and less error prone program code.

[Former Member]

Raj,

You should know that this in most likely the most important thing anyone has said to you in this thread...

Neal

[matt]

In case anyone wonders why, here's the reply I gave someone earlier:

See this thread: http://scn.sap.com/thread/3374731

Also: http://scn.sap.com/docs/DOC-29243 contains a huge amount of

extremely useful information about writing efficient code, and debunks

some other myths (e.g. that move-corresponding is a performance killer -

it isn't).

Google using: "for all entries" myth site:sap.com for more information.

If someone tells you to use FOR ALL ENTRIES - point them to these posts!

[Former Member]

I did not know that...thanks a bunch.

[Former Member]

HI All,

Whether can anyone please clarify  ...

If the database table(Taking EG:VBKD) is having 2 key fields then internal table must be declared as follows..

it_vbkd type hashed table of ty_vbkd with unique key vbeln posnr.

is it correct?

Regards

Raj

[Former Member]

Yes, the internal hashed table must have the same key fields as the transparent table.

[Former Member]

No, that depends on how you read the table or more importantly when you insert.  However, if you need every matching item represented, then the keys must be identical.

So, say that you knew that you were going to get duplication data, then having every item represented would only cause you headaches.  Then, instead, you could select single or select upto 1. 

So if your output does not have the line item number in it. Then your output will appear to have many records needlessly repeating if you represent every record.  It really depends on the exact need!

Neal

[Former Member]

You're right.  I just meant it should have the same key if you want to remove any possibility of runtime error ITAB_DUPLICATE_KEY when inserting to the itab from a database query of that table with no joins.

So I realize now my previous statement assumed a lot.

[Former Member]

Sorry,

My wife always complains that I'm too picky...

Neal

[Former Member]

Haha, no prob.  SCN could use more picky.

[Former Member]

Hii

raj kumar

It is not mandatory to declare hashed type internal table with all combination of key field but it's always better to declarae with all key fields.

Because we might need some operation with the internal table like insert, modify,delete and sort.

Suppose u want to to delete duplicate entries from ur internal table comparing only vbeln then there will be a problem.

Regards

Syed

[SuhaSaha]

My 2 cents ...

First-things-first -

I know if we declare the internal table as NON-UNIQUE KEY then runtime error wont occurs..

Afaik you can't define HASHED tables with NON-UNIQUE keys, this is only possible for SORTED & STANDARD tables.

As each of the responders have said the definition your hashed internal table seems incorrect. As Neal has already pointed out the definition should depend entirely on the scenario you want to achieve.

Couple of things i would like to point out -

1. You can change the definition of the internal table key to SORTED NON-UNIQUE KEY vbeln & forget about the runtime error (i'm not sure how it'll affect the business logic ).
2. When selecting from VBKD are you using the POSNR field, you can remove the field from the SELECT since FAE itself removes the duplicate entries before filling up the target internal table

- Suhas

PS - To get better (and faster) responses try to provide as much information as possible viz., the code which triggers this RT error, select from VBKD etc

[Former Member]

Hi Suhas,

Thanks for the reply...

Actually as I mentioned above the actual code in my custom program with declarations is shown below..

TYPES

: BEGIN OF ty_vbkd,
vbeln TYPE vbkd-vbeln,
bstkd TYPE vbkd-bstkd,
END OF ty_vbkd,
it_vbkd TYPE HASHED TABLE OF ty_vbkd WITH UNIQUE KEY vbeln.

TYPES: it_order  TYPE STANDARD TABLE OF zcustom_table WITH DEFAULT KEY.

Actually in my custom table(zcustom_table) the key fields are KUNNR,VBELN,ERDAT,MATNR

SELECT *
    INTO TABLE it_order
    FROM zcustom_table
   WHERE erdat IN irt_date.(Selection screen date)

  IF sy-subrc = 0.
    SORT it_order BY vbeln DESCENDING.
  ENDIF.

SELECT vbeln
         bstkd
    INTO TABLE it_vbkd
    FROM vbkd
     FOR ALL ENTRIES IN it_order
   WHERE vbeln = it_order-vbeln.

*Appending to the final output table

Loop at it_order into wa_order.

READ TABLE it_vbkd ASSIGNING <vbkd>
                          WITH KEY vbeln = <ord>-vbeln.
    IF sy-subrc = 0.
      ls_output-bstkd = <vbkd>-bstkd.
    ENDIF.

    APPEND ls_output TO rt_output.(final output table)

Endloop.

.

So..during retreving data from VBKD table I am getting runtime error ITAB_DUPLICATE_KEY.

Whether it is due to some data problem?..And also from the runtime error(ST22) i am not able to find which sale order is going to dump..is there any way to find for which sale order it is going dump?

Suggestion appreciated.

Regards

Raj

[SuhaSaha]

Hi,

Can you please send the screenshot of ST22 showing which section of the code is giving the RT error?

Moreover what is the type of the int. table RT_OUTPUT?

BR,

Suhas

[Former Member]

Hi Suhas,

I am sending the screen shot.

Moreover my final RT_OUTPUT is of type

TYPE STANDARD TABLE OF ty_output WITH DEFAULT KEY

t_

And during appending to final internal table it is not going to dump...During retrival from VBKD it is going to Dump.

I am not able to send the entire dump analysis.If you provide the mail id I will send the dump analysis screen shot.

Regards

Raj

.

[Former Member]

Hi,

Sort the first internal table and delete the duplicate entries. Then in the second internal table add one more key field POSNR.

With regards,

Riju Thomas.

[pankaj_parida2]

Dear Raj,

Add one more field POSNR on your Custom table as a Secondary Primary key.

delete duplicate entry comparing VBELN AND POSNR.

Declear VBKD as "STANDARD TABLE WITH DEFAULT KEY".

with regards

pankaj

[Former Member]

Dear Raj,

if you only want is a unique record from VBKD in every VBELN,

Just do this.

SELECT DISTICNT vbeln
         bstkd
    INTO TABLE it_vbkd
    FROM vbkd
     FOR ALL ENTRIES IN it_order
   WHERE vbeln = it_order-vbeln.

Regards,

Rogelio

[former_member15255]

Hello Rajkumar,

Please make use of Distinct in your query, this should cause dump.

Regards

Suresh Nair

[Former Member]

Hi all,

Thanks for the replies given by you all....

points are awarded.

Actually it issue is related to the data problem...

In the VBKD table by mistake for one sale order number there are different customer purchase orders(BSTKD) is updated..

so when I am retreving data from VBKD into the internal table which is declared as shown below

TYPES 

: BEGIN OF ty_vbkd,
vbeln TYPE vbkd-vbeln,
bstkd TYPE vbkd-bstkd,
END OF ty_vbkd,
it_vbkd TYPE HASHED TABLE OF ty_vbkd WITH UNIQUE KEY vbeln.

SELECT vbeln
         bstkd
    INTO TABLE it_vbkd
    FROM vbkd
     FOR ALL ENTRIES IN it_order
   WHERE vbeln = it_order-vbeln.

so for that sale order it has multiple BSTKD so VBELN is not unique hence it is going to dump.

Once again thanks for all who given replies to my questions.

I am closing this thread.