Fehlersuche wo man nicht debuggen kann

Getting started ... Alles für einen gelungenen Start.
24 Beiträge • Seite 1 von 2 (current) Nächste
24 Beiträge Seite 1 von 2 (current) Nächste

Fehlersuche wo man nicht debuggen kann

Beitrag von derandiheisst (ForumUser / 3 / 0 / 0 ) »
Hallo,

wer kenn es nicht - es gibt einen Fehler an einer Stelle an der man nicht debuggen kann, wegen Systemuser und Hintergrundverarbeitung oder warum auch immer.
Ich habe mir überlegt einen Funktionsbaustein zu erstellen, den man an der Stelle im Coding einbaut und aufruft wo der Fehler auftritt, davor und danach z.B.
Dem Funktionsbaustein werden alle Variablen, Strukturen und Tabellen übergeben. Dieser schreibt sie dann in eine Datenbanktabelle.

Soweit so gut.
Da solche Fälle ja aber öfter vorkommen wäre das Ganze noch besser wenn es generisch programmiert wäre.
D.h. man hat einen Funktionsbaustein mit vielleicht 10 Variablen, 10 Strukturen und 10 Tabellen als Parameter, die alle generisch sind.
Man kann dann eine Beliebige Tabelle übergeben, es wird dann z.B. aus der DD03L die Spaltennamen gelesen und alles in eine String-Tabelle geschrieben.

Da dies ja kein neues Problem ist, erst mal die Frage hat einer von Euch sowas in der Art schon mal gemacht?

Und wenn nicht - könnt ihr mir bitte ein paar Tipps geben, wie ich das am einfachsten hinbekomme?
Es geht mir dabei um die Übergabe von Tabellen und Strukturen und das eben generisch, hier weiß ich nicht wirklich wie ich das machen soll.

Vielen Dank!
Andreas

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


Re: Fehlersuche wo man nicht debuggen kann

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
Also, wenn ich schon weiss, wo der Fehler genau auftritt, dann kann ich mir nicht vorstellen, dass ich dann noch so einen FuBa brauche, den ich dort genau einprogrammiere.

Ansonsten setze ich dort einen Message Type 'X' ab und bekomme einen Shortdump mit vielen Informationen....

oder im Hintergrund scrhreibe ich mir alles, was ich brauche einfach ins den Spool/Logfile.

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von derandiheisst (ForumUser / 3 / 0 / 0 ) »
Unit605 hat geschrieben:Also, wenn ich schon weiss, wo der Fehler genau auftritt, dann kann ich mir nicht vorstellen, dass ich dann noch so einen FuBa brauche, den ich dort genau einprogrammiere.

Ansonsten setze ich dort einen Message Type 'X' ab und bekomme einen Shortdump mit vielen Informationen....

oder im Hintergrund scrhreibe ich mir alles, was ich brauche einfach ins den Spool/Logfile.
Danke für dein Tipp.
Leider ist es aber so, es kommt aber nur sehr selten vor und es muss analysiert werden warum das so ist.
Im Produktiv System kann ich keinen Short Dump programmieren, das kommt nicht so gut an.

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
Wenn ein Programm fehlerhaft arbeitet und man nicht im Q-System den Fehler finden kann, kann ich auch einen Kurzdump im Produktivsystem verantworten.

Ich habe auch schon Kunden und "Manager" gehabt, fuer die war ein Shortdump etwas ganz ganz boeses, aber eine Modiiication was ganz dolles.
Da muss man machmal den Kunden die Angst vor einem Shortdump nehmen und erklaeren, dass ein Shortdump etwas ganz hilfreiches ist und nicht umsonst gibt.

Wenn ich auf meine laaaaangjaehrige Erfahrung in dern ABAP Programmierung zurueckblicke, kann ich mir nicht vorstellen, wo ich so einen FuBa je eingesetzt haette.

Aus meiner Sicht, wuerde sich der Aufwand, so einen FuBa zu programmieren nicht lohnen.

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von derandiheisst (ForumUser / 3 / 0 / 0 ) »
Das geht nicht und diese Diskussion in diese Richtung ist eine Sackgasse.

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
derandiheisst hat geschrieben:Das geht nicht und diese Diskussion in diese Richtung ist eine Sackgasse.
Dann lass Dich nicht von mir und meiner Meinung abhalten und programmier den FuBa.
derandiheisst hat geschrieben:Und wenn nicht - könnt ihr mir bitte ein paar Tipps geben, wie ich das am einfachsten hinbekomme?
Allerding, einfach wird das nicht werden....

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von Dele (Specialist / 307 / 4 / 47 ) »
Für so etwas könntest du glaube ich auch die Anweisung ASSERT in Verbindung mit Checkpoint Groups verwenden.

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
Dele hat geschrieben:Für so etwas könntest du glaube ich auch die Anweisung ASSERT in Verbindung mit Checkpoint Groups verwenden.
Stimmt, da kann man sich auch einiges ins Log schreiben.

Aber ob das auch mit "vielleicht 10 Variablen, 10 Strukturen und 10 Tabellen als Parameter," funktioniert?

Man muesste jedes ASSERT wieder neu erstellen, da die ganzen Variablen/Strukturen/Tabellen unterschiedlich sind.

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von Daniel (Specialist / 314 / 68 / 44 ) »
An den Baustein die Daten via exporting übergeben.
Im Baustein den Import-Parameter nicht typisieren
und mit Export Name to DB wegschreiben. Fettisch.

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von ratsnus (Specialist / 357 / 2 / 56 ) »
zum Thema Hintergrund, extern angetriggert etc.

http://www.abapforum.com/forum/viewtopi ... debug#p380
<:: XING-Gruppe Tricktresor::>

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
ratsnus hat geschrieben:zum Thema Hintergrund, extern angetriggert etc.

http://www.abapforum.com/forum/viewtopi ... debug#p380

Wenn DAS in einem Produktivsystem moeglich waere:: (
dass entsprechende Berechtigungen vorliegen, um den Prozess debuggen zu können und vor allem Werte im Debugging ändern zu können.

kann ein Entwickler im Produktivsystem machen was er will, ohne irgendwelche Spuren zu hinterlassen!!!

Es wird wohl keine Firma geben, wo man so schnell die Berechtigung zum Debuggen UND!!! Aendern von Werte, in einem Produktivsystem, bekommt. Das waere schon grob fahrlaessig.
Zuletzt geändert von Unit605 am 06.06.2016 20:31, insgesamt 1-mal geändert.

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
öhhhh... :evil:
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: Fehlersuche wo man nicht debuggen kann

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
a-dead-trousers hat geschrieben:öhhhh... :evil:
Soll das "öhhhh..." bedeuten, dass Deine Firma grob fahrlaessig handelt? :D

Ich hatte auch schon eine Firma, wo ich alle diese "boesen" Berechtigungen hatte.
Lang, lang ist es her.... und dort habe ich das sogar auf Wunsch des Projektmanagers auch ausgenutzt und habe ein Material, dass so querstand und nur genervt hat, im Produktivsystem, ohne jeglich Spuren zu hinterlassen, geloescht.
Der Projektmanager wollte aber nicht wissen, wie ich es gemacht habe. War auch besser so :-)

Re: Fehlersuche wo man nicht debuggen kann

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
Unit605 hat geschrieben:Lang, lang ist es her.... und dort habe ich das sogar auf Wunsch des Projektmanagers auch ausgenutzt und habe ein Material, dass so querstand und nur genervt hat, im Produktivsystem, ohne jeglich Spuren zu hinterlassen, geloescht.
Da steht bei uns des öfteren etwas quer und kann nur mehr per SE16 gerade gebogen werden. :oops:
Ich darf mir selbst(!) die Berechtigung (Rolle) aber nur mit einem Tag Gültigkeit zuweisen und das wird dann auch peinlichst genau protkolliert.
Wenn die Revision das in den Logs rauskramt müsste ich Rede und Antwort stehen. (müsste, weil es zum Glück noch nie passiert ist)
Also schreib ich mir zusätzlich noch selber in meinen persönlichen Aufzeichnungen auf, was ich wann, wo und wie verändert hab.
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: Fehlersuche wo man nicht debuggen kann

Beitrag von erp-bt (Specialist / 163 / 4 / 21 ) »
Hallo,

aus meiner Sicht wäre LOG-POINT mit Checkpoint-Gruppe der richtige Ansatz.

Viele Grüße,
...entwickelnder Berater...beratender Entwickler

Vergleichbare Themen

1
Antw.
2578
Views
RFC JOB Debuggen
von autohandel7 » 04.12.2018 12:10 • Verfasst in Basis
3
Antw.
2166
Views
RFC debuggen
von aeon » 03.05.2005 09:12 • Verfasst in ABAP® Core
4
Antw.
2800
Views
RFC debuggen
von dimes » 04.09.2008 12:44 • Verfasst in ABAP® Core
4
Antw.
2997
Views
Zahllauf debuggen
von Margolwes » 12.03.2019 09:43 • Verfasst in Financials
3
Antw.
491
Views
Smartforms debuggen
von L0w-RiDer » 16.01.2020 13:19 • Verfasst in ABAP® für Anfänger

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

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.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140