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.