Need Help: SAP User cannot Post on every Transaction

[Former Member]

Hi Experts,

I have a problem on our QAS system, I have tried to post a lot of documents in transaction MIGO, in creating RFQ through ME41, in Posting Accounting Document in FB50. But all of them failed with the Express Document appearing at the end of the "Document Number Created" message.

Express Documents range from:

I. "MESSAGE_TYPE_X" when creating RFQ of One Time Vendors:

+Short text of error message:

Database error changing table ADRC

Long text of error message:

Technical information about the message:

Message class....... "AM"

Number.............. 842

Variable 1.......... "ADRC"

Variable 2.......... " "

Variable 3.......... " "

Variable 4.......... " "

Information on where terminated

Termination occurred in the ABAP program "SAPLSZA0" - in "ADDR_SAVE_INTERN".

The main program was "RSM13000 ".

In the source code you have the termination point in line 553

of the (Include) program "LSZA0U47".

The program "SAPLSZA0" was started in the update system.+

II. SAPSQL_ARRAY_INSERT_DUPREC, Post Goods Receipt in MIGO

+An exception occurred that is explained in detail below.

The exception, which is assigned to class 'CX_SY_OPEN_SQL_DB', was not caught

in

procedure "INSERT_TABLES" "(FORM)", nor was it propagated by a RAISING clause.

Since the caller of the procedure could not have anticipated that the

exception would occur, the current program is terminated.

The reason for the exception is:

If you use an ABAP/4 Open SQL array insert to insert a record in

the database and that record already exists with the same key,

this results in a termination.

(With an ABAP/4 Open SQL single record insert in the same error

situation, processing does not terminate, but SY-SUBRC is set to 4.)+

III. SAPSQL_ARRAY_INSERT_DUPREC, Posting through FB50

+An exception occurred that is explained in detail below.

The exception, which is assigned to class 'CX_SY_OPEN_SQL_DB', was not caught

in

procedure "INSERT_TABLES" "(FORM)", nor was it propagated by a RAISING clause.

Since the caller of the procedure could not have anticipated that the

exception would occur, the current program is terminated.

The reason for the exception is:

If you use an ABAP/4 Open SQL array insert to insert a record in

the database and that record already exists with the same key,

this results in a termination.

(With an ABAP/4 Open SQL single record insert in the same error

situation, processing does not terminate, but SY-SUBRC is set to 4.)+

Please provide direct solution for the system problem. And please tell me also what are the usual causes of these problems (Configuration-wise or ABAP)

[Former Member]

solution applied

[tomas_black]

Hello Cecilio,

all these problems have the same root cause likely: the number range. Here's a step-by-step solution for each one of them:

for problem I:

Please implement the report from the note #445575 and check the address range.

My suggestions:

1. Please run the report "Z_OSSNOTE_445575" from the note #445575 to find out the highest address number already assigned in ADRC, ADRP together.

2. Add (say) 100 number to it.

3. Then, change the value of the current number in SA01 transaction, button "status".

for problem II:

please follow the steps with regards to resetting the number range buffer as per the note #83731:

83731 SAPSQL_ARRAY_INSERT_DUPREC for INSERT COBK

Also, can you please review these notes?

#419538 Deleting commitments for earmarked funds at prod. startup

#824771 KBxxN: Program termination SAPSQL_ARRAY_INSERT_DUPREC

for problem III:

the problem occured because of a problem with your number range buffer (again);

Please have a look into note 83731 and reset the number range buffer:

First reset the number range buffer of the application server. Start Transaction SM56 and choose 'Number range buffer -> Reset'. Fill the fields of the following dialog field as follows:

Client <current client>

Object RK_BELEG

Sub-object <controlling area>

Range

Year

Global Reset X

Let us know if this has solved the problems.

Best Regards,

Tomas Black