V1 Update Termination

[Former Member]

Hi Gurus,

I have a update termination message occasionally coming when VA01 and VA02 is used. It says the following

Status of Update Module.

Function Module -

---

RV_SALES_DOCUMENT_UPDATE

Staus -

---

update was terminated

Report -

---

LV45UF0V

Line -

---

257

ABAP Processor -

---

SAPSQL_ARRAY_INSERT_DUPREC

Can some one throw some light why this module is failing. The function module is invoked by the standard Sales Transaction in update mode.

Addln Info : There has been a small enhancement done via User Exit at the time of SAVE of VA01/VA02 in which a custom table is being updated.

Thanks in Advance.

Edited by: Milton P on Jan 24, 2011 6:44 PM

[Former Member]

Hi Gurus,

I have a update termination message occasionally coming when VA01 and VA02 is used. It says the following

Status of Update Module.

Function Module -

---

RV_SALES_DOCUMENT_UPDATE

Staus -

---

update was terminated

Report -

---

LV45UF0V

Line -

---

257

ABAP Processor -

---

SAPSQL_ARRAY_INSERT_DUPREC

Can some one throw some light why this module is failing. The function module is invoked by the standard Sales Transaction in update mode.

Addln Info : There has been a small enhancement done via User Exit at the time of SAVE of VA01/VA02 in which a custom table is being updated.

Thanks in Advance.

Edited by: Milton P on Jan 24, 2011 6:44 PM

[Former Member]

Hi,

1. Try commenting the enhancement and check if you get the dump again.

2. Check the number range of the document if that got over

3. Check the key fields of the custom dictionary objects created.

Thanks,

Senthil

[Former Member]

Hi Senthil,

The code is in PRD and I cannot do that while other parameters are fine.

The error is occuring at VBEP not on the custom table.

INSERT VBEP FROM TABLE DA_XVBEPI.

Prg: LV45UF0V line 267

[Former Member]

For update termination, start with SM13 to see which table failed with duplicate rows...

[Former Member]

Kris SM13 gives me the following list. Look at the 7th entry.

The duplicate rows pertains to the table VBEP

1 BANF_WRITE_DOCUMENT V1 Initial

2 ME_UPDATE_REQUISITION V1 Initial

3 ME_CREATE_MRPRECORD_REQ V1 Initial

4 RV_SALES_DOCUMENT_UPDATE V1 (no retry) Initial

5 SWE_EVENT_CREATE_IN_UPD_TASK V1 Initial

6 BANF_WRITE_DOCUMENT V1 Initial

7 RV_SALES_DOCUMENT_UPDATE V1 (no retry) Error

8 SWE_EVENT_CREATE_IN_UPD_TASK V1 Initial

9 CASH_FORECAST_SD_ORDER_UPD_3 V1 Initial

10 MCV_STATISTICS_UPD_V1_ORDER V1 Initial

11 MCV_STATISTICS_UPD_V2_ORDER V2 Initial

12 MCEX_UPDATE_11_V1 V1 Initial

13 VERKBELEG_WRITE_DOCUMENT V1 Initial

14 RV_MESSAGE_UPDATE V1 Initial

[Former Member]

Hi Milton,

What I would do is the following:

- Check the dump (ST22) to find more info which program/include causeded the short dump;

- Using this info, check OSS to see if there is a note out there for the program/include;

- If nothing found on OSS, check the VA01/VA02 user-exits and anywhere the internal tables with prefix x or y are modified incorrectly causing the short dump. Also check if any of the exits write data to memory which is not cleared after the transaction is finished causing the next transaction potentially to short dump.

- Also check if the user-exit which is updating the custom table is not using an explicit COMMIT WORK.

Kind regards,

Robert

[Former Member]

SAPSQL_ARRAY_INSERT_DUPREC

Look for the customer code that attempts to insert a row without checking to see if it already exists.....the message above says it all....the code is trying to insert a record into a table that already contains a row with the the values in the key fields....since it's an express termination, it's occurring after SAVE has been processed, and the work committed to the database. These SD errors are FREQUENTLY the result of erroneous customer code additions/modifications, often in exits (check includes named like MV45AFZ*).

[Former Member]

Maybe this OSS note can help:

[Note 923103 - Update termination when you save the scheduling agreement|https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=923103]

Good luck,

Robert

[Former Member]

Yes RJ,

Let me go through your points and the NOTE. But to answer on of your point the custom table update is being done via a function module called in update mode hence no explicit call for COMMIT WORK.

[Former Member]

Milton, if you are saving scheduling agreements I would look at the Notes suggested by RJ..

Your best bet is to see if there are custom codes that is making changes to xvbep... It is possible that changes may not be new (that the bug was always there, but the condition that caused the dump was never triggered)

Other options, In SM13, you can see all the entries in the table FXVBEP... see if you can identify the entry that is getting duplicated? Is it just one entry or all entries that are getting duplicated?

Finally, if you can consistently reproduce this dump, than half the battle is over... You got to start debugging, just keep going back to see where exactly xvbep is getting filled... it is a tough task and requires lot of patience... You can always put breakpoints at beginning and end of the MV45AFZ* USER exits and see where the duplicate rows are getting added, if your custom code is doing it.

[Former Member]

Well said Kris, let me go through the all the points of the code affecting XVBEP. But how do you find the entries of a table in SM13.

Mine is plain Sales order not scheduling agreements. But thought of going through the NOTE by RJ to get some insight.

Other interesting point is this message does not occur every time, if so as you said the battle is over, it occurs occasionally.

[Former Member]

In SM13, you will have to drill down to the failed function module and it should have display icon (which will list all the parameters for the function module)

If you are unable to replicate the error consistently, it becomes much more difficult to figure it out..then you got to analyze your custom code to see if any of them are changing xvbep (or adding entries to xvbap , just in case)

[Clemenss]

Hi Milton,

the duplicate insert array is frequently the result of user-exit programming. You may check the [User Exits In Sales Document Processing|http://help.sap.com/saphelp_46c/helpdata/en/1c/f62c7dd435d1118b3f0060b03ca329/content.htm] what kind of modifications are applied to the tables relevant for the one mentioned in short dump.

Regards,

Clemens