Fehlermeldung: Es existiert bereits eine Zeile mit demselben Schlüssel
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
Hallo,
ich bekomme folgenden Kurzdump:
Es existiert bereits eine Zeile mit demselben Schlüssel
Der relevante Code wäre folgender (es handelt sich hierbei natürlich um Fragmente):
ich bekomme folgenden Kurzdump:
Es existiert bereits eine Zeile mit demselben Schlüssel
Der relevante Code wäre folgender (es handelt sich hierbei natürlich um Fragmente):
Code: Alles auswählen.
TYPES: BEGIN OF ty_tre,
zzrvind TYPE dimaiobpar-zzrvind,
END OF ty_tre.
DATA: it_tre TYPE SORTED TABLE OF ty_tre WITH UNIQUE KEY zzrvind,
IF it_tre IS NOT INITIAL.
SELECT insobject zzrvind FROM dimaiobpar
INTO TABLE it_mnba
FOR ALL ENTRIES IN it_tre
WHERE zzrvind = it_tre-zzrvind.
DELETE ADJACENT DUPLICATES FROM it_mnba.
ENDIF.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Der UNIQUE-Key ist das Problem.
Da du DELETE ADJACENT DUPLICATES verwendest, vermute ich mal, dass in deiner DB-Tabelle mehr als ein Datensatz mit dem Schlüssel ZZRVIND vorkommt und es daher beim INSERT in die interne Tabelle zur Schlüsselverletzung kommt.
Da du DELETE ADJACENT DUPLICATES verwendest, vermute ich mal, dass in deiner DB-Tabelle mehr als ein Datensatz mit dem Schlüssel ZZRVIND vorkommt und es daher beim INSERT in die interne Tabelle zur Schlüsselverletzung kommt.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Nein, denn er INSERTed ja gar nicht in die Tabelle mit dem UNIQUE KEY, sondern in eine andere.
Wir haben hier wieder einmal das Problem, dass die für eine Antwort ausschlaggebenden Codeteile nicht mitgepostet worden sind, so dass sich die Frage allenfalls spekulativ beantworten lässt. Da der Dump bei einem INSERT in die Tabelle it_mnba auftritt, müssten wir wissen, wie diese definiert ist. Offensichtlich wird einer ihrer Schlüssel verletzt, aber mit dem Schlüssel der Tabelle it_tre hat das nichts zu tun.
Wir haben hier wieder einmal das Problem, dass die für eine Antwort ausschlaggebenden Codeteile nicht mitgepostet worden sind, so dass sich die Frage allenfalls spekulativ beantworten lässt. Da der Dump bei einem INSERT in die Tabelle it_mnba auftritt, müssten wir wissen, wie diese definiert ist. Offensichtlich wird einer ihrer Schlüssel verletzt, aber mit dem Schlüssel der Tabelle it_tre hat das nichts zu tun.
it_mnba ist wie folgt definiert.
DATA: it_mnba TYPE SORTED TABLE OF ty_vtref WITH UNIQUE KEY vtref.
Mal eine Frage am Rande, wird eine interne Tabelle eigentlich definiert oder deklariert (rein nach der Definition und dem Sprachgebrauch ).
Vielen Dank.
DATA: it_mnba TYPE SORTED TABLE OF ty_vtref WITH UNIQUE KEY vtref.
Mal eine Frage am Rande, wird eine interne Tabelle eigentlich definiert oder deklariert (rein nach der Definition und dem Sprachgebrauch ).
Vielen Dank.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Meine erste Antwort hat nach wie vor Gültigkeit 😉
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Nein, hat sie nicht, denn für die Tabelle it_mnba ist es egal, wie oft ein Wert für das Feld ZZRVIND vorkommt. 😛
Allerdings gehe ich davon aus, dass der SELECT analog zu dem von Dir ursprünglich Geantworteten mehrere Zeilen der Datenbanktabelle dimaiobpar geliefert hat, bei denen der Wert des Feldes vtref gleich ist. Dann ist der Dump nur folgerichtig.
Allerdings gehe ich davon aus, dass der SELECT analog zu dem von Dir ursprünglich Geantworteten mehrere Zeilen der Datenbanktabelle dimaiobpar geliefert hat, bei denen der Wert des Feldes vtref gleich ist. Dann ist der Dump nur folgerichtig.
In ABAP ist eine interne Tabelle ein Spezialfall eines Datenfeldes, und Felder werden deklariert. Umgangssprachlich hört man da allerdings beides; da wird nicht drauf geachtet und stört auch keinen.Mal eine Frage am Rande, wird eine interne Tabelle eigentlich definiert oder deklariert (rein nach der Definition und dem Sprachgebrauch ).
Hi,
wenn das so aussieht,
dann hast du in der Tabelle it_mnba in vtref die Werte aus zzrvind stehen.
/Edwin
da muss ich wiederstprechen, wir wissen immer noch nicht wie die Structur "ty_vtref" aussieht, und der select hat nicht into corresponding fields.Nein, hat sie nicht, denn für die Tabelle it_mnba ist es egal, wie oft ein Wert für das Feld ZZRVIND vorkommt.
wenn das so aussieht,
Code: Alles auswählen.
TYPES : BEGIN OF ty_vtref,
spaltex type c length 20,
vtref TYPE c LENGTH 20.
TYPES : END OF ty_vtref.
DATA: it_mnba TYPE SORTED TABLE OF ty_vtref WITH UNIQUE KEY vtref.
SELECT insobject zzrvind FROM dimaiobpar
INTO TABLE it_mnba.
/Edwin
Poste doch mal bitte die Zeile in der der Shortdump auftritt, dann kann man dir evtl. auch helfen, so ist es stochern im Nebel...
2465 IF it_tre IS NOT INITIAL.
2466
>>>>> SELECT insobject zzrvind FROM dimaiobpar
2468 INTO TABLE it_mnba
2469 FOR ALL ENTRIES IN it_gwu
2470 WHERE zzrvind = it_tre-zzrvind.
2471
2472 DELETE ADJACENT DUPLICATES FROM it_mnba.
So steht es im Kurzdump
2466
>>>>> SELECT insobject zzrvind FROM dimaiobpar
2468 INTO TABLE it_mnba
2469 FOR ALL ENTRIES IN it_gwu
2470 WHERE zzrvind = it_tre-zzrvind.
2471
2472 DELETE ADJACENT DUPLICATES FROM it_mnba.
So steht es im Kurzdump
😂
Das wäre die Struktur von ty_vtref:edwin hat geschrieben: ↑10.10.2019 16:05Hi,da muss ich wiederstprechen, wir wissen immer noch nicht wie die Structur "ty_vtref" aussieht, und der select hat nicht into corresponding fields.Nein, hat sie nicht, denn für die Tabelle it_mnba ist es egal, wie oft ein Wert für das Feld ZZRVIND vorkommt.
wenn das so aussieht,dann hast du in der Tabelle it_mnba in vtref die Werte aus zzrvind stehen.Code: Alles auswählen.
TYPES : BEGIN OF ty_vtref, spaltex type c length 20, vtref TYPE c LENGTH 20. TYPES : END OF ty_vtref. DATA: it_mnba TYPE SORTED TABLE OF ty_vtref WITH UNIQUE KEY vtref. SELECT insobject zzrvind FROM dimaiobpar INTO TABLE it_mnba.
/Edwin
TYPES: BEGIN OF ty_vtref,
vtref TYPE dfkkop-vtref,
zzversnrt TYPE dfkkopk-zzversnrt,
augrp TYPE dimaiobpar-augrp,
rc TYPE sy-subrc,
END OF ty_vtref.
Wir wissen weder wie it_mnba definiert ist, noch it_gwu noch wissen wir wie dein Z-Feld in der dimaiobpar aussieht...
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Doch, wissen wir:schick hat geschrieben:Wir wissen weder wie it_mnba definiert ist
Code: Alles auswählen.
TYPES: BEGIN OF ty_vtref,
vtref TYPE dfkkop-vtref,
zzversnrt TYPE dfkkopk-zzversnrt,
augrp TYPE dimaiobpar-augrp,
rc TYPE sy-subrc,
END OF ty_vtref.
DATA: it_mnba TYPE SORTED TABLE OF ty_vtref WITH UNIQUE KEY vtref.@Lowrider: Schau doch bitte, dass Dein SELECT in eine Tabelle geht, deren Deklaration die Spalten enthält, die Du da reinfüllst.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
a-dead-trousers
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Dass die Felder nicht übereingestimmt haben, hab ich völlig übersehen. 😕
Eigentlich hätte der im SELECT gar nicht vorkommende Schlüssel VTREF der internen Tabelle schon als Anhaltspunkt gereicht.
Eigentlich hätte der im SELECT gar nicht vorkommende Schlüssel VTREF der internen Tabelle schon als Anhaltspunkt gereicht.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
3015
Views
Views
Klasse existiert bereits und dann doch nicht
von sapnup » 18.08.2017 12:02 • Verfasst in ABAP® für Anfänger
von sapnup » 18.08.2017 12:02 • Verfasst in ABAP® für Anfänger
8
Antw.
Antw.
7094
Views
Views
Eingabe IBAN Fehlermeldung "Schlüssel hat keinen ISO-Co
von Martin4711 » 20.06.2005 16:29 • Verfasst in Financials
von Martin4711 » 20.06.2005 16:29 • Verfasst in Financials
1
Antw.
Antw.
1800
Views
Views
Bearbeiten / Löschen einer bereits geschriebenen Zeile
von JanMeier » 11.08.2007 23:09 • Verfasst in Dialogprogrammierung
von JanMeier » 11.08.2007 23:09 • Verfasst in Dialogprogrammierung
1
Antw.
Antw.
2807
Views
Views
Schlüssel > 120, generischer Schlüssel vergrößern
von zer0 » 27.01.2014 09:20 • Verfasst in ABAP® Core
von zer0 » 27.01.2014 09:20 • Verfasst in ABAP® Core
1
Antw.
Antw.
4453
Views
Views
Amtl. Schlüssel (PV) bei freiwillig Versicherten
von Nicole_80 » 03.06.2008 08:54 • Verfasst in Human Resources
von Nicole_80 » 03.06.2008 08:54 • Verfasst in Human Resources
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 4 Stunden von DeathAndPain 4 / 550
vor 4 Stunden von DeathAndPain 4 / 550
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 4 Stunden von DeathAndPain 4 / 550
vor 4 Stunden von DeathAndPain 4 / 550