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

SAPSQL_ARRAY_INSERT_DUPREC during DB insert.

Former Member
0 Likes
1,813

Hey,

I get the following short dump when i try to insert into DSO DDACVMAP

Runtime Errors SAPSQL_ARRAY_INSERT_DUPREC

Except. CX_SY_OPEN_SQL_DB.

I have checked that the target table into which i am inserting is empty and also made sure that each record is unique.

Can this be a problem with the target table

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
1,500

Try sorting your internal table by your database keys and then describing it to get the number of lines. Then delete adjacent duplicates comparing your key fields. Finally, describe the table again to get the final number of lines. If there is any difference, it means that there <b>were</b> duplicate keys. In any event, you should be able to insert now with no problem.

Rob

12 REPLIES 12
Read only

Former Member
0 Likes
1,500

Hi,

What are the key fields of the table? Are you using a loop and single INSERTs or are you INSERTing from a table?

Regards, Joerg

Read only

0 Likes
1,500

The key fields of the target table are guid - unique identifier

date - created date

time - created time.

The Guid is 22 chars long and is always unique, the time and date were added as pre-caution.

Once i process the data, i insert it directly from the internal table.

INSERT db_tab FROM int_tab.

Read only

0 Likes
1,500

i think you are trying to insert the int table data into dbtable then correct syntax is

insert dbtab from table itab.

you can use addition accepting duplicate keys to avoid the duplication error but it will just avoid the error not adding any duplicate key field record.

insert dbtab from table itab accepting duplicate keys .

and one more thing again check the key fields are repeating or not ? and int table must be same structure as dbtable.

regards

shiba dutta

Read only

0 Likes
1,500

Hey Shiba,

i have used the addition ACCEPTING DUPLICATE KEYS for the time being, but i cannot afford to use it as a solution, and yeah that was a typo, i am using the syntax insert dbtab from table itab.

E. g: INSERT /BIC/ADDACVMAP00 FROM TABLE g_t_target ACCEPTING DUPLICATE KEYS.

one more strange thing is that if i try to insert the same records (the ones in the internal table) one at a time i don't get this dump, however if it is more than one record that i am trying to insert i get this error, although they are no way similar..

Regards,

Josh.

Read only

0 Likes
1,500

Hi,

Strange thing.

Just for debugging purposes: Yould you sort the internal table by the key fields and use DELETE ADJACENT DUPLICATES from this table and just check whether some of the rows disappear?

One more thing: Don't you have a MANDT key field for the client? Could there be a problem with that?

Regards, Joerg

Read only

0 Likes
1,500

Hi Joerg,

Yeah this is damn strange.

just to check why this happens, i entered the values of the key fields myself, in debug mode, however I get the same short dump.

This a DSO in BW and i guess that's why it is client independent.

Actually this DSO had recently been modified, an extra non-key field was added and is now active. i have declared the internal table in the program of TYPE db table, so i guess there shouldn't be any problem, right ?

Could there be anything that i am missing?

Thanks,

Josh.

Read only

0 Likes
1,500

Hi,

TYPE dbtable does not include the key fields, you have to do that manually like:

TYPE dbtable WITH UNIQUE KEY ...

(don't recall the exact syntax - please check in online help). If you declare the key EXACTLY as in the table, the first INSERT of a duplicate into your INTERNAL table should produce a dump - maybe this would help debugging...?

Regards, Joerg

Read only

Former Member
0 Likes
1,501

Try sorting your internal table by your database keys and then describing it to get the number of lines. Then delete adjacent duplicates comparing your key fields. Finally, describe the table again to get the final number of lines. If there is any difference, it means that there <b>were</b> duplicate keys. In any event, you should be able to insert now with no problem.

Rob

Read only

0 Likes
1,500

Hi Rob,

I am quite sure that the records being inserted are not duplicate, (I tried inserting only 3 records and made sure that they were not duplicate), another thing is that the target table is also empty.

I have attached the piece of code that i am using to insert to the database

DATA : l_count TYPE i.

  • Find the number of records being processed.

DESCRIBE TABLE g_t_target LINES l_count.

IF l_count > 0.

SORT g_t_target BY /bic/dguid

rstt_mdate

rstt_mtime.

  • Delete the duplicate records from the target table

DELETE ADJACENT DUPLICATES

FROM g_t_target

COMPARING /bic/dguid

rstt_mdate

rstt_mtime.

  • To insert records in table based on target table

INSERT /bic/addacvmap00 FROM TABLE g_t_target ACCEPTING DUPLICATE KEYS.

  • A message is displayed to check the records in the table

IF sy-subrc = 0.

A funny observation is that the database table allows only one entry, the next record to be inserted throws a duplicate error although it is not duplicate. This lead me to think that some how the keys of the table aren't acting as they are supposed to. ( The table had been modified recently, after which i have been facing this problem) could it be that some properties/ attributes of the table are forcing it to behave in the way it is now.

Or am i still missing something.

Thanks,

Josh.

Read only

0 Likes
1,500

hi Joshua..

Check the keyfields of ur DB Table once. They may not be defined properly.

And use this statement

INSERT db_tab FROM int_tab <b>ACCEPTING DUPLICATES KEYS</b>.

The addition ACCEPTING DUPLICATES KEYS is always needed to avoid the Runtime error.

<b>reward if Helpful.</b>

Read only

0 Likes
1,500

Hi Joshua!

If the table has been updated recently and you are experiencing the problem since then, I would investigate a bit further in this direction...

Check:

  • What is the status of the table? Is it active / inactive / something in between?

  • Do you need to re-generate the table using the db tool?

  • Are there any secondary keys defined to be unique that might be causing trouble?

  • Can you insert entries manually, using e. g. transaction SE16N with &SAP_EDIT?

Regards, Joerg

Read only

0 Likes
1,500

Hey Joerg,

The table change was not activated although it was being displayed as active in SE11.

Thanks for the suggestions.

Regards,

Josh.