MaxDB DBIF_RSQL_SQL_ERROR SAPLM61X 'duplicate name'

[Former Member]

Hello all,

i'm facing a strange problem. the sap-standard mrp run dumps regularly with the following dump (only parts posted here). i'm not a db-admin so i don't know what i am looking at. i have searched this forum as well as several others and found out about db-parameter SHAREDSQL, so i can tell you it is already set to NO.

appreciate your expertise ...

______________________________________

Laufzeitfehler DBIF_RSQL_SQL_ERROR

Ausnahme CX_SY_OPEN_SQL_DB

Datum und Zeit 30.01.2008 22:20:10

...

Hinweise zur Fehlerbehebung

Fehlertext der Datenbank...: "Duplicate name"

Interne Aufrufcodierung....: "[RSQL/FTCH/MDBS ]"

Bitte die Einträge im SAP-Systemlog auswerten (Transaktion SM21).

Falls der Fehler in einem nicht modifizierten SAP-Programm vorkommt

findet sich vielleicht eine Vorablösung im SAP-Hinweissystem.

Falls Sie selbst Zugang zum SAP-Hinweissystem haben, so suchen Sie

bitte zunächst mit folgenden Schlagworten:

"DBIF_RSQL_SQL_ERROR" "CX_SY_OPEN_SQL_DB"

"SAPLM61X" bzw. "LM61XF1K"

"SELECT_MDBS_BS"

...

SAP-Kernel............... "640"

hergestellt am........... "Mar 21 2007 19:43:03"

hergestellt auf.......... "Linux GNU SLES-9 x86_64 cc3.3.3"

Datenbankversion......... "SAPDB 7.5.0.041 "

Patch-Level.............. "175"

Patch-Text............... " "

Unterstützte Umgebung....

Datenbank ............... "MaxDB 7.5.0"

SAP-Datenbankversion..... "640"

Betriebssystem........... "Linux 2.6"

...

Datenbank-Release... 640

Kernel-Release...... 640

Verbindungstyp...... 3 (2 = R/2, 3 = R/3, E = Extern, R = Reg. Extern)

Aufrufsart.......... "asynchron with reply (imode 0)" (S = Synchron, a/A =

Asynchron, T = Transakt. )

Mandant............. 400

Benutzer............ "BATCH"

Transaktion......... " (Program: SAPMM61X)"

Funktionsbaustein... "MRP_MATERIAL_PARALLEL"

...

132 IF esfilt-ergbz IS INITIAL.

-

-

---

SELECT * FROM mdbs

134 INTO mdbs

135 WHERE matnr EQ mdkp-matnr

136 AND werks EQ mdkp-plwrk

137 AND bstyp EQ bstypf

138 * AND loekz EQ space "note 189712

139 AND ( loekz EQ space "note 189712

140 OR loekz EQ chars ) "note 189712

141 AND elikz EQ space.

...

[Former Member]

i am closing this post as i was pointed to open a call with SAP. this call did not provide a solution either, since the DB-trace did not offer a clue and further traces cannot be done easily since the problem is not reproducable.

so it seems i'm stuck with the problem.

[Former Member]

i am updating this in order to enable other people stuck with this problem to find a bit of information.

the cause of this problem is the aborting of processes - not necessarily the abortion of the process that dumps, but of any other before the one.

as of now there's no correction for this maxdb-version but there's a workaround which reduces the appearence of the error (in my case a reduction to 0).

restart your workprocesses periodically by setting the parameters:

rdisp/noptime

rdisp/wp_auto_restart

in tx. RZ10/RZ11. as for appropriate values for these parameters you will have to try and find out according to the frequency of the error - in our case we set:

rdisp/noptime 87000

rdisp/wp_auto_restart 86400

which is about every 24 hours.

[markus_doehr2]

What MaxDB version are your running? I´ve not seen this error before...

Markus

[Former Member]

hi markus,

i'm not sure what do you mean by 'version'. in the dump it calls itself like posted above:

SAP-Kernel............... "640"

hergestellt am........... "Mar 21 2007 19:43:03"

hergestellt auf.......... "Linux GNU SLES-9 x86_64 cc3.3.3"

Datenbankversion......... "SAPDB 7.5.0.041 "

Patch-Level.............. "175"

Patch-Text............... " "

Unterstützte Umgebung....

Datenbank ............... "MaxDB 7.5.0"

SAP-Datenbankversion..... "640"

Betriebssystem........... "Linux 2.6"

[roland_mallmann]

Hi Mylene,

as you seem to be an SAP customer, please -if not already done- open an OSS message on queue BC-DB-SDB.

In that message, please post:

- the exact MaxDB version (incl. Buildnr.) (you can retrieve it from transaction DB50)

- the exact SQL statement as it was sent to the DB (retrievable from the relevant workprocess-tracefile in SM50)

For analysis purposes, an opened R/3 connection is needed aswell.

Please mention if the error is reproduceable everytime aswell.

Thanks & regards,

Roland