- 20. April 2016
  2 Kommentare

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

Wir sind Ihr Dienstleister für die Entwicklung, die Ihr SAP noch besser macht.
Schon in der Ideenphase unterstützen wir Sie bei der Definition der Anforderungen. Die Konzeption und Umsetzung erfolgt durch unsere SAP Experten.

Sie erhalten die Komplettlösung – Ihr Projekt machen wir zu unserem Projekt. Mit professionellem Projektmanagement sicheren wir den Projekterfolg.

Gerne spreche ich mit Ihnen über Ihre Ausgangslage und zeige Lösungsmöglichkeiten auf. Auf Wunsch unterbreite ich Ihnen im Anschluss ein unverbindliches Angebot.

Kontaktieren Sie mich: Telefon 0211.9462 8572-16 oder per E-Mail biermann@erlebe-software.de
Ingo Biermann, Fachbereichsleiter

 

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.

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.


SHARE


2 Kommentare zu "REUSE_ALV_FIELDCATALOG_MERGE: Dump READ_REPORT_LINE_TOO_LONG"

Elmar Vogt - 22. April 2016 | 11:26

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
Lukas Pfeil - 22. April 2016 | 15:28

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: http://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.