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

Runtime Error :ITAB_DUPLICATE_KEY Select on BSIS and BSAS Table

Former Member
0 Likes
3,987

Hi Experts,

We get a frequent dump on the below select in Production system  for dupliacte key

select data from bsis into itab where bukrs on selection screen

                                                     gjhar  on selection screen

                                                      

->dump on this select

   select data from bsas appending table itab where bukrs on selection screen

                                                                           gjhar  on selection screen

My ITAB is sorted table  WITH UNIQUE KEY  bukrs gjahr belnr buzei

I cannot replicate the same error in production and i have checked the database table and i am quite sure  that BSIS and BSAS cannot have duplicate

records for the key bukrs gjahr belnr buzei

I can make the itab non unqiue key and it will not cause this issue but i wanted to know if this scenario can happen?

Thanks

1 ACCEPTED SOLUTION
Read only

RaymondGiuseppi
Active Contributor
0 Likes
3,056

Theorically, yes, if a document item get cleared during the extraction, escpecially if you select many records and don't bypass buffers. But very rare...

Regards,

Raymond

Hi Experts,

We get a frequent dump on the below select in Production system  for dupliacte key

select data from bsis into itab where bukrs on selection screen

                                                     gjhar  on selection screen

                                                      

->dump on this select

   select data from bsas appending table itab where bukrs on selection screen

                                                                           gjhar  on selection screen

My ITAB is sorted table  WITH UNIQUE KEY  bukrs gjahr belnr buzei

I cannot replicate the same error in production and i have checked the database table and i am quite sure  that BSIS and BSAS cannot have duplicate

records for the key bukrs gjahr belnr buzei

I can make the itab non unqiue key and it will not cause this issue but i wanted to know if this scenario can happen?

Thanks

11 REPLIES 11
Read only

RaymondGiuseppi
Active Contributor
0 Likes
3,057

Theorically, yes, if a document item get cleared during the extraction, escpecially if you select many records and don't bypass buffers. But very rare...

Regards,

Raymond

Read only

0 Likes
3,056

You could also try an execution of report RFINDEX in quality assurance and/or development systems to execute "FI Consistency check", check the first two boxes "Documents vs Indexes" and "Indexes vs Documents". Alas only SAP is allowed to use the correction tool included (and locked/hidden) in this tool.

But if your are enough self confident, you should be able to find it in debug mode , but don't do this in production of course, if errors are reported in production create an OSS message with component FI-GL-GL-X.

Regards,

Raymond

Read only

vigneshyeram
Active Participant
0 Likes
3,056

Dear Bhanu,

The concept is you cannot append the internal table which is declared as sorted you should always Insert the internal table

So when you write select with appending it gives dump.
A table index administrates the logical order of table rows. As the primary table index of a standard table for managing the order arising from index operations. However, the order in the index has no relation to the content of the table rows But primary table index of a sorted table for managing the order of table rows in accordance with the sorted primary or secondary table key. So when you append it appends as last entry not in order so it gives dump.

Hope it helps you.

Kindly let me know.

Thanks & Regards,

Vignesh Yeram

Read only

0 Likes
3,056

Hi Vignesh,

Not able to understand what you are saying may be a example could be great.

Do you have any SAP help document which sayes we cannot use "Appending" operation with

sorted tables.

Read only

0 Likes
3,056

Dear Bhanu,

Usually this concept of not using appending for sorted tables are better known to CRM technical people. right now i dont have anydocument but technically the tables which has algorithm you cannot disturb that for example when you append you are appending the records one after the another so sorting is disturbed it's algorithm is disturbed so it gives dump. When you insert a sorted table it is implicitly inserted into sorted internal table in sorted way.Also if you try to append duplicate entries it will give runtime error. Also a runtime error occurs if you disturb the sort order of a sorted table by appending to it.

On your request just now i found a link http://scn.sap.com/thread/1171093

Hope it helps you

Kindly let me know.

Thanks & Regards,

Vignesh Yeram

Read only

0 Likes
3,056

Hi Bhanu and Vignesh,

In fact if you try to append rows against sorted columns sequence. Inserting lower value than last maximum in ascending sorted table results in error. This is because append tries to add rows at the end of table. However:

  • This will be Runtime Error <ITAB_ILLEGAL_SORT_ORDER>, which is other than Runtime Error <ITAB_DUPLICATE_KEY> mentioned in the post.
  • This happens only with single APPEND TO statement, APPENDING TABLE sorts numbers automaticall and does not cause dump, so here we are safe.

Regards

Adam

Read only

0 Likes
3,056

Just for information there is no problem to SELECT APPENDING TABLE if the target table is sorted.

The result set is inserted into the internal table itab line-by-line; a sorting process is executed in the case of a sorted table. If INTO is used, the internal table is initialized. Previous lines remain intact if APPENDING is used.

(http://help.sap.com/abapdocu_731/en/abapinto_clause.htm)

So, the error should come from actual duplicates.

Regards,

Raymond

Read only

Former Member
0 Likes
3,056

Hello Bhanu,

This run time error may occur if change operations are performed in the selected table at the time when the SELECT statements are executed. So If you want to use your ITAB as sorted one then you have to use enqueue locks to avoid simultaneous change operations.

OR

Use your ITAB with non unique key and use "DELETE ADJACENT DUPLICATES"  considering your business logic. But keep in mind you should be very careful here.

Regards,

Sudhir Kothavale.

Read only

adam_krawczyk1
Contributor
0 Likes
3,056

Hi Bhanu,

I think that error is anyhow caused by logic and duplicated data.

  • Your internal sorted table is defined with 4 unique keys, which are subset of primary key in BSIS and BSAS tables.
  • It means that they do cover full key for tables. BUKRS, GJAHR, BELNR, BUZEI teoretically not need to be unique within single table, as you may have same 4 columns values, but other columns which are in primary key (like BSIS-HKONT, BSIS-AUGDT, BSAS-HKONT, BSAS-AUGDT etc.) will be different and the row is still unique in database.
  • In addition your query filters in WHERE condtion contain only bukrs and gjahr which makes it even more probable that within single table the paired value will be repeated. If there are at least two rows in BSIS or BSAS that have same values for bukrs and gjahr, you will get duplicate key error.

If you cannot reproduce situation you can do:

  • TRY CATCH block for these two select statements for mentioned exception
  • In case of error is caught, implement CATCH section to see which rows gave duplication and log it. Then you will find root cause.

Hope it helps.

Regards,

Adam

Read only

0 Likes
3,056

Sudhir: Its a report program no enqueues....totally worng.

Vignesh:We can use Appending with sorted tables.

Thanks Guys for your help. For  now i will try to replicate the scenario or will try to catpturre the exception.

Thanks

Bhanu

Read only

0 Likes
3,056

Hello Bhanu,

I am talking about the tables from where you are fetching the data. For more details refer SAP note 1080997.

Regards,

Sudhir Kothavale.