REUSE_ALV_FIELDCATALOG_MERGE: Dump READ_REPORT_LINE_TOO_LONG

Jeder kennt sie: Die REUSE-Funktionsbausteine für die ALV-Generierung in einem klassischen ABAP-Report. Oft benutzt, wenn schnell ein kleiner Report benötigt wird, um Daten auszulesen, aber auch bei komplexeren Programmen mit langwieriger interner Verarbeitung ist das Ergebnis oft eine Tabelle, die wir dem User präsentieren möchten. Und mit was geht das schneller und simpler, als mit den bekannten REUSE-Bausteinen? Mit der internen Tabelle füttern, die man dargestellt haben möchte und fertig!

Dazu wird zuerst der Feldkatalog mit dem FuBa REUSE_ALV_FIELDCATALOG_MERGE mithilfe der internen Tabelle aufgebaut und anschließend der Baustein REUSE_ALV_GRID_DISPLAY mit Feldkatalog und ebenfalls interner Tabelle versorgt.

REUSE_ALV_FIELDCATALOG_MERGE

REUSE_ALV_FIELDCATALOG_MERGE

Der Dump READ_REPORT_LINE_TOO_LONG

Jetzt kommt es dabei aber – manchmal – zu dem im ersten Moment wenig aussagekräftigen Dump READ_REPORT_LINE_TOO_LONG aufgrund der Ausnahme CX_SY_READ_SRC_LINE_TOO_LONG.

Dump READ_REPORT_LINE_TOO_LONG

Dump READ_REPORT_LINE_TOO_LONG

Die Ursache

Bei der Analyse verwirrt der Hinweis “Die ABAP-Programmzeilen sind breiter als die interne Tabelle”. Wir schließen gleich auf “unsere” eigene Tabelle, die wir mit Daten gefüllt haben und nun ausgeben wollten (oben: gt_output) und fragen uns, was diese Meldung heißen soll. Wenn wir weiter in der angegebenen Codestelle des Dumps nachforschen, geraten wir noch mehr ins Grübeln, denn der präsentierte Code ist nicht der von uns erstellte.

Fremdes Coding

Fremdes Coding

Der Grund des Programmabbruchs ist ebenso simpel, wie die Lösung des Problems: Da wir dem Funktionsbaustein REUSE_ALV_FIELDCATALOG_MERGE den Namen der internen Tabelle und des Reports mitgeben, liest der Baustein das komplette Coding, intern in eine interne Tabelle. Deren Zeilen haben aber eine maximale Zeilenlänge von 72 Zeichen. Besitzt unser Report nun Zeilen, die länger als 72 Zeichen sind, tritt der Laufzeitfehler auf.

Top 3 Programmierfehler in ABAP für SAP HANA

Whitepaper: Top 3 Programmierfehler in ABAP für SAP HANA

Vermeiden Sie diese Top 3 Fehler bei der Programmierung in ABAP für HANA.

Die Lösung

Wie wirken dem entgegen? Im Menü unter “Hilfsmittel à Einstellungen” das folgende Pop-up öffnen und die Checkbox für die “Abwärtskompatible Zeilenlänge” anhaken:

Abwärtskompatible Zeilenlänge

Abwärtskompatible Zeilenlänge

Sollten Zeilen mit Überlänge im Report vorkommen, erscheint eine Warnung, welche fragt, ob die Zeilen umgebrochen werden sollen. Das nimmt uns die manuelle Arbeit ab, auch wenn es manchmal weniger “schön” geschieht, was den Code betrifft. Zusätzlich sieht man im Editor jetzt eine rot-punktierte Linie, die anzeigt wo die 72 Zeichen enden und welche Grenze wir nicht überschreiben dürfen.

Was ist Ihre bevorzugte Methode, um ALVs zu generieren? Hinterlassen Sie uns gerne Ihre Kommentare.

Christoph Lordieck

Christoph Lordieck

Als Bereichsleiter SAP Entwicklung berate ich Unternehmen rund um das Thema SAP Individualentwicklung. Einige Jahre Projekt- und Umsetzungserfahrung haben meinen Wissenshunger noch nicht gestillt und ich suche ständig nach neuen Themen und Entwicklungen im ABAP-Umfeld.

Sie haben Fragen? Kontaktieren Sie mich!



Das könnte Sie auch interessieren

In vielen Bereichen geht die SAP neue Wege, um die Erfahrungen für Benutzer, Administratoren und Entwickler weiter zu verbessern. Sei es SAPUI5 als Framework für HTML5 Anwendungen, BOPF als stark […]

weiterlesen

Ist es möglich, die Einhaltung von Programmier-Richtlinien mit nur einem Klick umzusetzen? In dieser mehrteiligen Blogserie wird gezeigt, wie das Tool 'Pretty_Printer' genutzt und erweitert werden kann, um bei der […]

weiterlesen

Vermissen Sie auch regelmäßig die Möglichkeit in SAP schnell eine SQL-Abfrage zu basteln? Ohne die SE80, aber mit mehr Möglichkeiten als die SE16N? Dann sollten Sie sich die Transaktion SQVI […]

weiterlesen

2 Kommentare zu "REUSE_ALV_FIELDCATALOG_MERGE: Dump READ_REPORT_LINE_TOO_LONG"

Sehr geehrter Herr Pfeil,
vielen Dank für den sehr interessanten Beitrag.
Auch wenn ich schon 24 Jahre ABAP-Erfahrung habe, wäre ich auf die Editor-Einstellungen so schnell nicht gekommen.
Man lernt nie aus!

Selbst hatte ich das Problem noch nicht, weil ich lieber direkt die Klasse CL_GUI_ALV_GRID verwende, da habe ich deutlich mehr Einfluss auf die Gestaltung des Grids. Außerdem finde ich das Schreiben von Event-Handlern für den Grid bequemer.
Die Einstellung ’72 Zeichen’ verwende ich schon lange nicht mehr. Die Zeit der IBM-Lochkarten ist nun wirklich rum und beim modernen ABAP mit Inline-Declarations ist man schnell mal über die ominösen 72 Zeichen hinaus.

Mit freundlichen Grüßen
Elmar Vogt

Antworten

Sehr geehrter Herr Vogt,

besten Dank für Ihren Kommentar!
Es freut mich, dass Ihnen der Artikel eine Kleinigkeit “beibringen” konnte.

Die Klasse CL_GUI_ALV_GRID ist sicherlich “the-way-to-code”, wenn fortgeschrittene Features, wie Sie schon sagen, z.B. Eventhandler benötigt werden. Hier bestärke ich Sie in Ihrer Entscheidung.
Mein Kollege Lars Sommer verfasste vor einiger Zeit einen Artikel, der die verschiedenen ALV-Varianten vergleicht, falls Sie noch etwas Leselust haben: https://erlebe-software.de/2015/01/25/alv-varianten/

Freundliche Grüße
Lukas Pfeil

Antworten

Schreiben Sie einen Kommentar

Bitte füllen Sie alle mit * gekennzeichneten Felder aus. Ihre E-Mail Adresse wird nicht veröffentlicht.





Kontaktieren Sie uns!
Alexander Koessner-Maier
Alexander Kössner-Maier Kundenservice