‎2007 Oct 29 9:43 AM
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
‎2007 Oct 29 1:35 PM
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
‎2007 Oct 29 9:46 AM
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
‎2007 Oct 29 9:55 AM
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.
‎2007 Oct 29 10:11 AM
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
‎2007 Oct 29 10:22 AM
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.
‎2007 Oct 29 10:27 AM
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
‎2007 Oct 29 10:38 AM
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.
‎2007 Oct 29 10:45 AM
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
‎2007 Oct 29 1:35 PM
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
‎2007 Oct 30 4:19 AM
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.
‎2007 Oct 30 4:32 AM
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>
‎2007 Oct 30 8:02 AM
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
‎2007 Oct 30 9:33 AM
Hey Joerg,
The table change was not activated although it was being displayed as active in SE11.
Thanks for the suggestions.
Regards,
Josh.