Interne Tabelle als ALV

Getting started ... Alles für einen gelungenen Start.
25 Beiträge • Vorherige Seite 2 von 2 (current)
25 Beiträge Vorherige Seite 2 von 2 (current)

Re: Interne Tabelle als ALV

Beitrag von Lbyte (ForumUser / 18 / 0 / 0 ) »
Vielen vielen Dank für die angeregte Diskussion und eure zahlreichen Vorschläge. Ich habe mich übrigens für die SALV Klasse entschieden weil es mir simpler erschien und ich auch binnen kürzester Zeit das Ergebnis erreicht habe, was ich haben wollte.

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Interne Tabelle als ALV

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
black_adept hat geschrieben:CASE SY-LANGU und nicht Textsymbole? SLIN wird nie dein Freund werden....
Wenn ich eine lange Liste von ALV-Spalten habe, die ich in der geschilderten Weise definiere, dann wäre mir der Aufwand, für jedes davon ein Textsymbol zu definieren (was ich für alle anderen Zwecke inzwischen zu machen pflege), einfach zu hoch. Wenn ich wüsste, dass ich eine Vielzahl von Sprachen unterstützen muss, dann würde ich es machen, aber da es eh nur deutsch und englisch ist, ist ein CASE SY-LANGU nebst Copy&Paste der ganzen Definitionszeilen und Überschreiben der deutschen Begriffe mit englischen einfach eine Größenordnung bequemer - und im Code sogar noch besser lesbar, weil statt kryptischen Textsymbolnamen der Klartext dasteht.
black_adept hat geschrieben:Wenn du schon den ganzen Aufwand treibst - warum dann nicht im DDIC Datenelemente anlegen mit den richtigen Bezeichnungen und damit mit Wiederverwendungsmöglichkeit?
Das muss ich mal drüber nachdenken. Das ist das Einzige, für das mir nicht so recht ein Gegenargument einfällt. :-D Ich liebe dieses Forum; was ich hier trotz meiner Berufserfahrung schon an Informationen und Denkanstößen mitgenommen habe, geht auf keine Kuhhaut.
Ralf hat geschrieben:Nein. Ein Dynpro funktioniert nach einem ganz anderes Prinzip als ein ALV, was man schon daran erkennt, dass ein ALV ein Dynpro braucht.
Wenn Dein Programm ein Modulpool ist, ja. Mittlerweile sind aber 98% meiner Programme Reports, so dass es nur ein bildschirmfüllendes Ergebnis-ALV gibt. Technisch sind die Unterschiede natürlich weiterhin vorhanden, in der Praxis jedoch vernachlässigbar. Ich habe in meinem Report eine ALV-Tabelle, und die wird schrittweise und gut kommentiert mit Leben gefüllt. Das ist wunderbar les- und nachvollziehbar, auch ohne dass ich sie als Trivialparameter an jede Unterroutine durchreiche.
Ralf hat geschrieben:
DeathAndPain hat geschrieben:Ansonsten sind bei mir auch Puffertabellen global.
Bei dir vielleicht ;) Ich verwende Klassenattribute (und ja, das ist etwas ganz anderes).
Und was hast Du davon, mal abgesehen von der durch höheren Programmieraufwand erkauften Political Correctness? Das Problem globaler Tabellen und Variablen ist doch, dass man nicht nachvollziehen kann, wer sie wann und warum befüllt und das Programm dadurch unverständlich und nicht nachvollziehbar wird. Wenn aber (am besten schon durch die Namensgebung der Tabelle) klar (und notfalls durch einen Verwendungsnachweis auf einen Blick beweisbar) ist, dass die Tabelle nur ein einziges Mal schreibend befüllt wird, nämlich zu Programmbeginn, und ihr Zweck offensichtlich ist, dann hat man dieses Problem nicht. Dann ist die Puffertabelle im Programm zu betrachten wie eine Datenbanktabelle. Die definierst Du ja auch nicht lokal.
Ralf hat geschrieben:Es ist eher eine willkürliche ABAP-Erscheinung, dass man einen Variablennamen für unterschiedliche Variablen verwendet und man nur deshalb REFRESH erfindet, obwohl ein CLEAR reicht. Eine Tabelle ist für mich eine Variable und die lösche ich mit CLEAR.
Das ist eine sehr akademische Begründung, die nach meiner Überzeugung keinen praktischen Wert hat (wie Du ja auch durch die Formulierung "für mich" implizit einräumst).
Ralf hat geschrieben:Lösung: LOOP AT variable INTO DATA(variable)
Könnte man machen, aber abgesehen von der schlechteren Performance habe ich dann wieder das Problem, dass ich einen Namen für die Variable brauche, dem man gut ansieht, in welchem Verhältnis er zur Tabelle steht. WA_TABELLENNAME finde ich extrem sperrig, blöd zu tippen (weil man mitten im Variablennamen die Shift-Taste braucht) und vor allem optisch sehr hässlich und damit trotz der Klarheit der Benamung ein Problem für die Lesbarkeit. Da gefällt mir <TABELLENNAME> bedeutend besser. Das ist zwar auch blöd zu tippen (was ja mein verbleibender Kritikpunkt war), aber zumindest optisch macht das echt was her. *TABELLENNAME wäre freilich mein Favorit gewesen, besonders mit impliziter Definition (soll heißen, dass sollte es für alle internen Tabellen ohne explizite Deklaration automatisch geben. Selbst wenn man es im Einzelfall nicht braucht: Über den Speicherverbrauch einer einzelnen Kopfzeile brauchen wir heutzutage ja wohl nicht zu reden. Und wenn gar *TABELLENNAME eine Spezialform eines Feldsymboles wäre und dann am besten noch automatisch als Ziel bei "LOOP AT TABELLENNAME." genutzt werden würde, dann wäre damit sogar noch der Speicherverbrauch und Performancenachteil vom Tisch, und der Code wäre kürzer). Das wäre IMHO ein echter Gewinn für ABAP.
Das und implizite Kopfzeilen sind Dinge, deren Verständnis denen sehr schwer fällt, die aus anderen Programmiersprachen kommen.
Hm. Bevor ich (damals autodidaktisch anhand eines Einsteigerbuches) ABAP erlernt habe, hatte ich schon jahrelang alle möglichen BASIC-Dialekte programmiert und überdies noch an der Uni mit Programmiersprachen zu tun (darunter so geisteskrankes Zeug wie PROLOG). Trotzdem habe ich den Sinn von Kopfzeilen sofort verstanden und hatte mit diesem Detail nicht die geringsten Probleme. Die Eigenheiten von Dynpros zu verstehen finde ich da schon etwas anspruchsvoller. Und wie gesagt, was Referenzvariablen einem Programmierer abfordern, ist um Größenordnungen komplexer zu überblicken. Du kritisierst Variablen, die sich einen Namen teilen, aber Variablen, die gar keinen Namen haben, sind ok...

Ist vielleicht aber auch eine Persönlichkeitsfrage. Ich denke sehr formalistisch; für mich ist aufgrund der Syntax immer auf den ersten Blick klar, ob ich eine Kopfzeile oder einen Tabellenrumpf vor mir habe. Andere achten vielleicht nicht so auf die Feinheiten, die dazu gehören, oder haben Fallen wie die automatische Erzeugung einer leeren Kopfzeile bei Übergabe einer kopfzeilenlosen Tabelle per TABLES-Parameter nicht im Kopf (ein Problem, das es nicht gäbe, wenn alle Tabellen eine Kopfzeile hätten *duckundweg*).
Man kann mit Ausnahmeklassen irre Sachen machen, wenn man ein bisschen kreativ ist. Früher hab ich die Dinger gehasst wie die Pest, aber seit ich z. B. weiß, wie ich komplette Protokolle durch Verschachteln von Ausnahmen zusammenbauen kann, die ich dann einmal "auspacke" und ins Anwenderlog schreibe (mit einer generischen Klasse, die ich einmal geschrieben habe für das ganze System), bin ich ein echter Fan davon, weil ich dazu nix mehr selbst machen muss.
Das hast Du schon öfter erwähnt. Es wäre nett, wenn Du dazu mal ein bisschen Beispielcode bieten könntest, der die Funktionsweise veranschaulicht. Ich bin ja neuen Ansätzen gegenüber durchaus aufgeschlossen, wenn ich ihnen einen praktischen Nutzen abgewinnen kann. Von VALUE und CONV bin ich inzwischen ein ganz großer Fan, und selbst die komischen SWITCH- und COND-Befehle habe ich inzwischen ins Herz geschlossen. 8)

Re: Interne Tabelle als ALV

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
DeathAndPain hat geschrieben:
black_adept hat geschrieben:CASE SY-LANGU und nicht Textsymbole? SLIN wird nie dein Freund werden....
Wenn ich eine lange Liste von ALV-Spalten habe, die ich in der geschilderten Weise definiere, dann wäre mir der Aufwand, für jedes davon ein Textsymbol zu definieren (was ich für alle anderen Zwecke inzwischen zu machen pflege), einfach zu hoch. Wenn ich wüsste, dass ich eine Vielzahl von Sprachen unterstützen muss, dann würde ich es machen, aber da es eh nur deutsch und englisch ist, ist ein CASE SY-LANGU nebst Copy&Paste der ganzen Definitionszeilen und Überschreiben der deutschen Begriffe mit englischen einfach eine Größenordnung bequemer - und im Code sogar noch besser lesbar, weil statt kryptischen Textsymbolnamen der Klartext dasteht.
Der Aufwand beschränkt sich auf einen Doppelklick. Im Coding steht dann 'Ich bin ein Textsymbol(nnn)', wobei nnn die laufende Nummer ist. Das ist selbsterklärend und schnell gemacht.
DeathAndPain hat geschrieben:
Ralf hat geschrieben:Nein. Ein Dynpro funktioniert nach einem ganz anderes Prinzip als ein ALV, was man schon daran erkennt, dass ein ALV ein Dynpro braucht.
Wenn Dein Programm ein Modulpool ist, ja. Mittlerweile sind aber 98% meiner Programme Reports, so dass es nur ein bildschirmfüllendes Ergebnis-ALV gibt. Technisch sind die Unterschiede natürlich weiterhin vorhanden, in der Praxis jedoch vernachlässigbar.
Nein, das Eventhandling ist ein ganz anderes.
DeathAndPain hat geschrieben:Und was hast Du davon, mal abgesehen von der durch höheren Programmieraufwand erkauften Political Correctness? Das Problem globaler Tabellen und Variablen ist doch, dass man nicht nachvollziehen kann, wer sie wann und warum befüllt und das Programm dadurch unverständlich und nicht nachvollziehbar wird.
Nur ein Beispiel: Die Klasse kann ich kapseln und unsinnige Werte gleich abweisen, indem ich sie durch SET-Methoden zuweise. Das kann Vorteile bringen. Außerdem hat jeder Entwickler einen "Stil" und wer sich in meine Programme einarbeitet, muss nicht mal so und mal so denken, je nach Fall.
DeathAndPain hat geschrieben:
Ralf hat geschrieben:Es ist eher eine willkürliche ABAP-Erscheinung, dass man einen Variablennamen für unterschiedliche Variablen verwendet und man nur deshalb REFRESH erfindet, obwohl ein CLEAR reicht. Eine Tabelle ist für mich eine Variable und die lösche ich mit CLEAR.
Das ist eine sehr akademische Begründung, die nach meiner Überzeugung keinen praktischen Wert hat (wie Du ja auch durch die Formulierung "für mich" implizit einräumst).
Ich arbeite viel mit Leuten zusammen, die nicht aus der ABAP-Welt kommen und die haben (wie gesagt) immer mit denselben Konstrukten Probleme - zum Beispiel mit impliziten Kopfzeilen.
DeathAndPain hat geschrieben:
Man kann mit Ausnahmeklassen irre Sachen machen, wenn man ein bisschen kreativ ist. Früher hab ich die Dinger gehasst wie die Pest, aber seit ich z. B. weiß, wie ich komplette Protokolle durch Verschachteln von Ausnahmen zusammenbauen kann, die ich dann einmal "auspacke" und ins Anwenderlog schreibe (mit einer generischen Klasse, die ich einmal geschrieben habe für das ganze System), bin ich ein echter Fan davon, weil ich dazu nix mehr selbst machen muss.
Das hast Du schon öfter erwähnt. Es wäre nett, wenn Du dazu mal ein bisschen Beispielcode bieten könntest, der die Funktionsweise veranschaulicht. Ich bin ja neuen Ansätzen gegenüber durchaus aufgeschlossen, wenn ich ihnen einen praktischen Nutzen abgewinnen kann. Von VALUE und CONV bin ich inzwischen ein ganz großer Fan, und selbst die komischen SWITCH- und COND-Befehle habe ich inzwischen ins Herz geschlossen. 8)
Das fehlt es mir an der Zeit für ein Codebeispiel. Prinzip ist: Du wirfst eine Ausnahme, die du außen fängst und mit "previous" in die nächste Ausnahme wirfst. Das geht tief geschachtelt, so dass du nachher eine Ausnahme hast, darin eine vorhergehende Ausnahme und darin wieder eine vorhergehende Ausnahme. Das in ein Protokoll geschrieben und ins Anwenderlog und schon kannst du nachvollziehen, was alles passiert ist. Das ist gerade bei Ausnahmen gut, die nicht zwingend einen Programmabbruch zur Folge haben müssen.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Interne Tabelle als ALV

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Der Aufwand beschränkt sich auf einen Doppelklick. Im Coding steht dann 'Ich bin ein Textsymbol(nnn)', wobei nnn die laufende Nummer ist. Das ist selbsterklärend und schnell gemacht.
Du lässt es einfacher klingen, als es ist. Wenn ich den Klartext im Coding eintrage, dann steht da der Name des Feldes, dem ich als der Entwickler in aller Regel schon aus dem Kopf eine passende Spaltenüberschrift zuordnen kann. So schreibe ich das flüssig herunter, an der Stelle, an der auch die anderen Eigenschaften des ALV-Feldes stehen.

Schreibe ich jedoch Textsymbole und mache dabei das, was bei Variablen verpönt ist, aber leider üblich und hier von Dir propagiert wird, nämlich völlig aussagelose Namen für die Textsymbole (wobei das 3-Zeichen-Limit sicherlich nicht hilfreich ist), dann habe ich anschließend eine Liste von Textsymbolen T01 bis T27. Und dann darf ich immer hin- und herspringen, um zu schauen, von welchem Feld das denn jetzt der Überschriftstext sein soll. Oder ich arrangiere mir einen Splitscreen mit dem Code links und den Textsymbolen rechts und flitze mit den Augen immer hin und her. Klar kann man das machen. Aber dass der Mehraufwand nur ein Doppelklick sei, ist ein Gerücht.
Nur ein Beispiel: Die Klasse kann ich kapseln und unsinnige Werte gleich abweisen, indem ich sie durch SET-Methoden zuweise.
Es ging hier aber nicht um OO im Allgemeinen, sondern ganz konkret um Puffertabellen für Datenbankwerte. Wir reden hier von einer primitiven Puffertabelle, die einfach nur Zeilen aus der Datenbanktabelle für schnellen Zugriff vorhält. Wenn Du darin "unsinnige Werte" hast, dann hast Du ein Problem, das mit Pufferung nichts zu tun hat, denn dann stehen diese Werte auch in Deiner Datenbanktabelle.

Re: Interne Tabelle als ALV

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
DeathAndPain hat geschrieben:Du lässt es einfacher klingen, als es ist. Wenn ich den Klartext im Coding eintrage, dann steht da der Name des Feldes, dem ich als der Entwickler in aller Regel schon aus dem Kopf eine passende Spaltenüberschrift zuordnen kann. So schreibe ich das flüssig herunter, an der Stelle, an der auch die anderen Eigenschaften des ALV-Feldes stehen.

Schreibe ich jedoch Textsymbole und mache dabei das, was bei Variablen verpönt ist, aber leider üblich und hier von Dir propagiert wird, nämlich völlig aussagelose Namen für die Textsymbole (wobei das 3-Zeichen-Limit sicherlich nicht hilfreich ist), dann habe ich anschließend eine Liste von Textsymbolen T01 bis T27. Und dann darf ich immer hin- und herspringen, um zu schauen, von welchem Feld das denn jetzt der Überschriftstext sein soll. Oder ich arrangiere mir einen Splitscreen mit dem Code links und den Textsymbolen rechts und flitze mit den Augen immer hin und her. Klar kann man das machen. Aber dass der Mehraufwand nur ein Doppelklick sei, ist ein Gerücht.
Schon mal folgende Angabe versucht?

Code: Alles auswählen.

lv_field-coltext = 'ich bin ein Text mit Textsymbol'(T01).
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Interne Tabelle als ALV

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
a-dead-trousers hat geschrieben:Schon mal folgende Angabe versucht?

Code: Alles auswählen.

lv_field-coltext = 'ich bin ein Text mit Textsymbol'(T01).
Die meinte ich.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Interne Tabelle als ALV

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
a-dead-trousers hat geschrieben:

Code: Alles auswählen.

lv_field-coltext = 'ich bin ein Text mit Textsymbol'(T01).
Und damit wird dann SLIN doch wieder zum Freund und man hat sogar einen Default für nicht übersetzte Symbole.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Interne Tabelle als ALV

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Diese Syntax kenne ich nicht. Kann mir bitte jemand erklären, was sie tut? Einen Text im Klartext anzugeben und zugleich auf ein Textsymbol zu verweisen, kommt mir irgendwie widersprüchlich vor.

Re: Interne Tabelle als ALV

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
DeathAndPain hat geschrieben:Diese Syntax kenne ich nicht. Kann mir bitte jemand erklären, was sie tut? Einen Text im Klartext anzugeben und zugleich auf ein Textsymbol zu verweisen, kommt mir irgendwie widersprüchlich vor.
Du schreibst den Text hin und machst einen Doppelklick darauf. Sodann wird ein Textelement mit eben diesem Text angelegt und die Nummer wird hinter dem Literal automatisch eingefügt. Das führt dazu, dass du mit einfachen Mitteln ein Textelement anlegst (du brauchst dich um die Nummerierung auch nicht zu kümmern) und es außerdem als Default für alle nicht übersetzen Sprachen gilt (weil es ein Textelement der Originalsprache ist).

Das geht auch en bloc über den Textabgleich. Also machst du, wenn das Programm fertig ist, einmal den Abgleich und alle Textelemente sind angelegt. Einfacher gehts echt nicht mehr, eine Rechtfertigung für so ein CASE SY-LANGU gibt es eigentlich nicht.


Ralf

Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
DeathAndPain

Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Interne Tabelle als ALV

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
ralf.wenzel hat geschrieben:
20.11.2017 09:27
Das fehlt es mir an der Zeit für ein Codebeispiel.
Ich habe gerade eines geschrieben für einen anderen Zweck:

Code: Alles auswählen.

*&---------------------------------------------------------------------*
*& Report  ZZRWTEST
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*

REPORT zzrwtest.

" written as test class - start with Strg+F10 (!)

*----------------------------------------------------------------------*
*       CLASS lcl_raise_kaskade_demo DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_raise_kaskade_demo DEFINITION FOR TESTING
  DURATION SHORT
  RISK LEVEL HARMLESS.

  PRIVATE SECTION.
* ================

    CLASS-DATA:
      texts  TYPE STANDARD TABLE OF string.

    CLASS-METHODS:
      "! logging method
      "!
      "! @parameter i_any       | any error
      logger
        IMPORTING
          i_any TYPE any.

    METHODS:
      raiser FOR TESTING.

ENDCLASS.       "lcl_raise_kaskade_demo

*----------------------------------------------------------------------*
*       CLASS lcl_raise_kaskade_demo IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lcl_raise_kaskade_demo IMPLEMENTATION.

  METHOD raiser.

    DATA exc TYPE REF TO cx_root.
    DATA descr TYPE REF TO cl_abap_typedescr.
    DATA bapiret2 TYPE bapiret2.
    DATA bapiret2tab TYPE bapiret2tab.

    TRY.
        " raise an exc
        RAISE EXCEPTION TYPE cx_aunit_prog_access
          EXPORTING
            textid       = cx_aunit_prog_access=>cx_aunit_prog_access
            program_name = 'BLA'.

      CATCH cx_aunit_prog_access INTO exc.

        TRY.
            " raise another exc and register previous
            RAISE EXCEPTION TYPE cx_bgrfc_invalid_destination
              EXPORTING
                textid            = cx_bgrfc_invalid_destination=>inbound_dest_not_registered
                previous          = exc
                dest_name_inbound = 'BLUB'.

          CATCH cx_bgrfc_invalid_destination INTO exc.

            " example 1: write exc-package to log
            logger( exc ).

            " example 2: write bapiret2-structure to log
            logger( bapiret2 ).

            " example 3: write bapiret2-table to log
            logger( bapiret2tab ).

            " there may be many other cases
            " (symsg, syst, ....)
        ENDTRY.
    ENDTRY.

  ENDMETHOD.       " raiser

  METHOD logger.

    DATA descr TYPE REF TO cl_abap_typedescr.
    DATA exc TYPE REF TO cx_root.
    DATA text TYPE string.

    TRY.
        " for exc: unpack package recursively
        descr = cl_abap_typedescr=>describe_by_object_ref( i_any ).
        exc = i_any.
        IF exc->previous IS NOT INITIAL.
          logger( exc->previous ).
        ENDIF.

        " get text and write it to log (SBAL or log table)
        text = exc->get_text( ).

        " in this case: collect message texts in itab
        INSERT text INTO TABLE texts.
BREAK-POINT.  " have a look to table TEXTS!

      CATCH cx_sy_dyn_call_illegal_type.
        " for structures and tables: write to log
        descr = cl_abap_typedescr=>describe_by_data( i_any ).

        CASE descr->kind.
            " just one message
          WHEN cl_abap_typedescr=>kind_struct.
            " write to log

            " message table
          WHEN cl_abap_typedescr=>kind_table.
            " write to log in a LOOP

            " literal, single field
          WHEN cl_abap_typedescr=>kind_elem.
            " write comment to log

          WHEN OTHERS.
            " throw exc
        ENDCASE.
    ENDTRY.

  ENDMETHOD.                    "logger

ENDCLASS.       "lcl_raise_kaskade_demo
Die beiden Ausnahmeklassen sind zufällig gewählt.

Hier kann man schön sehen, wie man solche kaskadierten Exceptions sammeln und nacheinander auswerten kann, indem man die letzte (und somit das ganze Paket) an eine Logger-Klasse übergeben kann. Die packt das dann aus und (das ist hier nicht mehr implementiert) schreibt die Sachen in ein Log (das kann SBAL sein oder eine Log-Tabelle oder sonstwas).

Ebenso kann man auch alles andere übergeben, was an Fehlern so auftaucht (BAPIRET2-Meldungen einzeln oder als Tabelle aus Funktionsbausteinen, etc.). Der Aufrufer kümmert sich dabei um nichts, er hat irgendeinen Fehler in irgendeiner Form und kippt den in die Methode. Am Ende muss es dann eine Methode geben, die ein Log darstellt.

Was man noch machen könnte: Einen optionalen Parameter, der z. B. die fehlererzeugenden Daten weggeschrieben werden, die dann dargestellt werden, wenn man im SBAL auf den "Details" Button klickt. Wenn man nichts übergibt, könnte man grundsätzlich Name von Klasse, Methode, etc. wegschreiben, damit man die Fehlerstelle einfacher findet. Mal so als Idee ins Unreine.


Ralf

Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag (Insgesamt 2):
LooperSaskuAc

Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Vergleichbare Themen

4
Antw.
227
Views
5
Antw.
1248
Views
Inhalt interne Tabelle an andere interne Tabelle übergeben
von L0w-RiDer » 30.01.2020 16:28 • Verfasst in ABAP® für Anfänger
5
Antw.
3004
Views
interne Tabelle in andere interne Tabelle (Format)
von Gast » 20.10.2004 14:44 • Verfasst in ABAP® Core
5
Antw.
303
Views

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 72
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141