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
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
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
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.
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
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.
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
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