Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
isp
Danke! Leider hats nicht geholfen.a-dead-trousers hat geschrieben:hi!
Ich glaub der Fehler liegt in deinem LIKE:
Meintest du nicht vielleicht '%Konrad%' oder so.
(Du hast die Wildcards vergessen)
lg ADT
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
isp
Huch! Das ist mir gar nicht aufgefallenblack_adept hat geschrieben:Wenn du ein Einzelfeld via SELECT einzelfeld INTO TABLE tabelle_vom_typ_datenbanktabelle in eine interne Tabelle schiebst, ist in den meisten Fällen das Ergebnis ganz und gar nicht das was du haben möchtest. ( Stichpunkt: MANDT ).
In dem Fall ist eine HASH-Tabelle (oder genauer der UNIQUE KEY) sinnlos, da im Endeffekt beim Einfügen in die interne Tabelle von den drei "Konrads" nur einer übrig bleibt. ABAP macht nämlich hier nichts anderes als, dass es immer wieder versucht die DB-Ergebnisse in die Tabelle zu schreiben und da alle den gleichen Schlüssel haben, bleibt am Schluss nur der übrig der zuletzt gefunden wurde.isp hat geschrieben:ich habe eine Liste :
Konrad
Konrad
Konrad
ausgegeben wird :
Konrad - 3
Code: Alles auswählen.
Konrad XZY
Konrad Maier
Konrad von Freiherr
Bin der gleichen Meinung, aber vielleicht sogar noch etwas radikaler: ich würde einen STANDARD TABLE verwenden. Dann hast du nämlich nachwievor die Möglichkeit deine Ergebnisse nach eigenen Wünschen zu sortieren. Falls du wirklich den schnellen Zugriff auf das Ergbnis brauchst kannst du dann immer noch READ TABLE ... BINARY SEARCH verwenden. (Aber natürlich erst nach einem entsprechenden SORT)Haubi hat geschrieben:Eine Hash-Tabelle würde ich eigentlich nur dann einsetzen, wenn ich immer mit vollqualifiziertem Schlüssel zugreife, d.h. READ TABLE ... WITH TABLE KEY. Ansonsten ergibt der Einsatz für mich keinen Sinn.
Wenn die Einträge der Tabelle nach Name sortiert ausgegeben werden sollen würde ich eher eine SORTED TABLE verwenden.