Binary search SY-SUBRC = 4 obwohl Eintrag vorhanden (HEX identisch)

Re: Binary search SY-SUBRC = 4 obwohl Eintrag vorhanden (HEX identisch)

Komme offenbar spät, will aber auch noch meinen Senf dazu abgeben. 😁

Ich habe keine Zweifel, dass Dein Problem tatsächlich mit dem Fehlen eines Index bei Deiner internen Tabelle zu tun hat. Deswegen wirst Du mit der Umstellung auf eine SORTED TABLE auch erfolgreich gewesen sein; da kommst Du um die Angabe eines Primärindexes nämlich nicht herum.

Es wäre aber genauso auch mit Deiner Inline-Deklaration der internen Tabelle nebst BINARY SEARCH gegangen, und zwar ohne das Ganze schlechter lesbar zu machen. Du hättest nur den Umstand berücksichtigen müssen, dass eine inline deklarierte Tabelle keinen Deinen Wünschen entsprechenden Schlüssel hat und diesen daher bei Deinem SORT-Befehl explizit angeben müssen:
ASCENDING muss man hingegen nicht angeben. Das ist ja explizit von der SAP dokumentiert, dass ASCENDING angenommen wird, wenn nichts angegeben wird, und es entspricht auch der menschlichen Intuition (wenn Du jemandem sagst, er solle eine Papierliste alphabetisch sortieren, wirst Du niemanden finden, der dies ungefragt absteigend tut). Das trotzdem hinzuschreiben, finde ich persönlich affig (sorry msfox), es sei denn, man hat auch DESCENDING-Spalten dabei und will es auf diesem Hintergrund deutlicher machen, welche Spalten aufsteigend und welche absteigend sortiert werden.

Gegen den BINARY SEARCH ist nichts einzuwenden; der hat schon immer einwandfrei funktioniert.

msfox hat geschrieben:Dafür setzte sich aber andere Entwickler hin und fangen plötzlich an, meinen Quellcode auf die neue Syntax umzustellen, nur um ein paar Zeilen zu sparen. Das hat zur Folge, dass es z.T. unlesbarer wird und beim Debuggen schwieriger wird.

Wenn das passiert, ist es in der Tat Mist. Meistens ist es allerdings so, dass die neue Syntax nicht nur kürzer, sondern tatsächlich auch besser lesbar ist. Nur muss man aufgeschlossen genug sein, sich damit auch zu beschäftigen und Übung zu sammeln. Wenn man in einem fremden Code die neue Syntax erstmals sieht, weil man sie nie selber ausprobiert hat, klar, dann ist sie komplett ungewohnt und fremd und damit schwer zu lesen und zu verstehen.

Ich kann mich noch erinnern, wie ich das erste Mal den REDUCE-Befehl gesehen und mich gefragt habe, um Himmels willen, wer soll denn da verstehen, was da passiert? Aber dann habe ich mich damit auseinandergesetzt und ihn selbst in meinen Programmen verwendet und bin mittlerweile der Meinung, dass er besser verständlich ist als der alte Weg über einen LOOP. Natürlich nur, wenn er nicht zu brutal verschachtelt ist. Da muss man ein gewisses Fingerspitzengefühl aufbringen.

In den allermeisten Fällen ist aber nach meiner Erfahrung der kürzere Code auch der besser lesbare und der längere enthält nur mehr Ballast. Wie den Doppelpunkt bei Deinem SORT. 😜

Re: Binary search SY-SUBRC = 4 obwohl Eintrag vorhanden (HEX identisch)

Das ist die Frage, ob es das wäre. Wie soll die Syntax dann genau aussehen? Wenn man mitten in den SELECT-Befehl eine Typdeklaration einer internen Tabelle mit reinbaut, wird der SELECT-Befehl unübersichtlich (was viele SELECT-Befehle ohnehin schon sind). Zudem soll man inline deklarierte Felder ja nur sehr lokal verwenden, also möglichst direkt nach dem SELECT verwursten.

Ich finde es auch kein Problem, nach dem SELECT einen SORT hinterherzuschieben oder alternativ mit ORDER BY zu arbeiten (je nachdem, ob man die entsprechende Rechenlast in der Datenbank oder im ABAP-Interpreter haben möchte. Für beides gibt es Argumente). Schade finde ich nur, dass man bei der 7.40-Syntax keinen BINARY SEARCH angeben kann und daher in diesem Fall auf den ollen READ TABLE-Befehl zurückgreifen muss (den ich außer in Spezialfällen wie diesen gar nicht mehr verwende, weil er einfach nur sperriger und schlechter zu lesen ist).

Außerhalb von SELECT-Befehlen kann man ja den Datentyp bei Inline-Deklarationen durchaus angeben, indem man VALUE, CONV oder eine der anderen derartigen Funktionen benutzt und darin anstatt der Raute den gewünschten Datentyp angibt.

Re: Binary search SY-SUBRC = 4 obwohl Eintrag vorhanden (HEX identisch)

Der BINARY SEARCH ist komplett in Ordnung. Den gab es schon in Release 3.1i (wo es noch gar keine internen Tabellentypen gab), so dass er dort alternativlos war, wenn man nicht sequenziell suchen wollte. Dementsprechend ausgereift ist er. Hat immer problemlos funktioniert. Aber klar, die Tabelle muss dafür halt sortiert sein.

Re: Binary search SY-SUBRC = 4 obwohl Eintrag vorhanden (HEX identisch)

Ich denke, das würde sich negativ auf die Performance auswirken, weil die Suchergebnisse dann ja nach dem Lesen auch nach dem Datenbanktabellenschlüssel sortiert werden müssten. Je nach Anwendungsfall braucht man das vielleicht gar nicht, etwa wenn man nur einmal über die gelesenen Daten LOOPen und irgendwas damit veranstalten möchte. Generell ist ja der Rat der SAP, Inline-Deklarationen nur lokal zu verwenden. Wenn Du die interne Tabelle im weiteren Programmverlauf intensiver nutzen willst, solltest Du sie per DATA deklarieren. Dann kannst Du ihr auch Sortierung und Schlüssel mitgeben.

Wenn Schlüssel und Sortierung aus der Datenbanktabelle übernommen werden würden, wäre auch die Frage, was man mit der Spalte MANDT macht. Die wirst Du bei Zugriffen auf Deine interne Tabelle in aller Regel nicht angeben wollen, aber in fast allen Datenbanktabellen ist es die erste Spalte des Primärschlüssels. Wenn Du in der Tabelle suchst und diese Spalte nicht angibst, kann ABAP den Suchschlüssel nicht nutzen.

Schon aus diesem Grund kann man argumentieren, dass der Programmierer einen für sein Programm passenden Schlüssel für die interne Tabelle selber angeben soll. Zugleich ist das auch ein Grund, weshalb ich SELECT * selten mache (in S/4 HANA gilt das ja ohnehin als verpönt). Ich will in meinen Tabellen nur Spalten, die ich für meine Zwecke tatsächlich brauche. Neben der MANDT-Spalte gibt es in den allermeisten Anwendungsfällen auch andere Spalten in der Datenbanktabelle, die man in seinem konkreten Programm nicht alle braucht. Die interne Tabelle mit dem TYPES-Befehl maßzuschneidern und nur die relevanten Spalten aufzunehmen, ist zwar ein bisschen Tipparbeit, aber hinterher hat man nicht nur etwas bessere Performance (weniger übertragene Daten und belegter Speicherplatz), sondern vor allem liest es sich im Debugger bedeutend schöner, wenn man da nur für die Routine tatsächlich relevante Spalten zu sehen bekommt und nicht zusätzlich lauter Spaltenmüll. Zum einen sieht man (gerade bei einem fremden Programm oder einem, an dem man lange nicht mehr dran war) den Spalten im Debugger nicht an, ob sie relevant sind. Zum anderen ist es nervig, wenn die erste, die siebte und die fünfzehnte Spalte relevant sind und man dann seitwärts hin- und herscrollen und schauen muss, wo denn nun die interessanten Daten stehen. Und das alles nur, weil der Programmierer zu faul gewesen ist, ein paar Zeilen TYPES-Befehl zu tippen.