Strange, isn’t it? But I ruminated a pretty long time of the night for this title. The following words will – hopefully – explain what I mean with it. Okay, now that I have caught your attention by using this weird title, let’s call the next thoughts:

A Guide To Poblem Fixing In Programming

I engaged in problem solving and solution finding since I began programming ABAP. So let’s step right into the topic (I do not want my first blog entry to become too long…): What can you do, if you have a programming error?

Find the problem!

What? You say, you know your problem? I say: No, you don’t! You know the error that resolves by the problem. But you will have to find the reason for the error. If you do that, you have already done a lot and you can conentrate on finding a solution.

Follow these steps to fix the problem:

  1. Extract the very essence of your code. Remove everything that does not belong to the problem:
    • remove comments
    • remove unused code
    • remove parameters that have nothing to to with the problem
    • remove exception handling
    • remove unnecessary data definitions
    • shorten code, variable names, data wherever you can
  2. Write a demo program that only contains what is necessary to reproduce the error.
    • do not use built in type definitions which may not exist in every standard SAP system
    • write code than can be compiled and executed in other systems
    • write code than can be simply copied and pasted in other SAP systems
      • do not use dynpros (unless your problem is about dynpros)
        • if you need a container, use CL_GUI_CONTAINER=>SCREEN0 as parent
        • use docking containers which could be easily created and docked at a selection screen or list
        • use standard GUI-status so that the user must not create a specific status (SET PF-STATUS ‘STLI’ OF PROGRAM ‘SAPMSSY0’.)
      • do not use database access with specific data (unless you have problems with a SELECT or JOIN statement)
      • use standard tables for selection like T000 or T005
  3. Do transformations that will simplify the code by yourself (use variable name “ITAB-MATERIAL” instead of “/SCN/FL_OPT_KT-MAT_DEF_PREP_NEW”. This makes it others as easy as can be to help you.
  4. RTFM! 😉
    • Search documentation
    • check if the function module is documented in other languages.
    • check if the class is documented on the net
  5. Try to change things and check if the error still occurs.
  6. concentrate on one problem at a time
    • if you find out that there are more difficulties, extract the one problem that is most urgent
  7. Work on the problem.
    • think for yourself before you ask others to do the thinking
    • think about solution solving strategies
    • think about changing relevant things
  8. Explain the problem
    • explain the circumstances
    • explain used abbreviations even if you think everyone knows them (SD, DB, BRF, …)
    • explain what you have tried so far
    • explain your opinion of what could be the reason
    • be precise
  9. ask others
    • ask collegues
    • make a call to friends
    • post the problem to a forum

When working on 2nd point you might find out that the problem does not occurs anymore. In this case: Congratulations! You found out, that the problem is buried somewhere else. start at number 1 and make sure you leave the parts that are responsible for the error.

All other tipps will help you to get nearer to the problem. And it will help others understanding your problem.


And time, time is not on your side (Tina Turner, Golden Eye)

When asking others please do the things I mentioned before. This is work and it costs time, for sure. But it’s you having the problem so you should spent your time on it, not others.

Be aware that others did not work on the problem as long as you did. So you will have to explain the surroundings and circumstances that belong to the problem.

Be aware that others spent their (free) time to help you. Therfore do your best to be precise, short and polite.


All over the forums, blogs and communities there are a lot of good and clever people who like to help. For me I can also say, I like to help. But I do not like to help someone if

  • it takes much effort to think about what the question could be (I get a short dump. can you help?)
  • I realize that the requester did not think by himself
  • I have to make much effort to reproduce the problem
  • the questioner does not say what solutions he or she tried to fix the problem (I already tried. It didn’t work.)
  • the questioner is unfriendly or rude

Be thankful!

After persons give you hints or solutions on your problem, please give a response (thanks, I will try). If you fixed the problem give a feedback all the more! Again describe what helped to find the solution and what you did to fix it. It will be a pleasure to the helper if he knows that he could help you and it will help others who have a similar problem and find your thread.

Back to the beginning

The title was: The problem is the solution. I tried to refer to the philosphical idiom “the answer lies within you”. I hoped I showed with this guide that this is often also true with problems.

You will not have to follow all of these points step by step. The guide should give you some hints on what to take care of when solving a problem.

Most of what helps me finding the solution is to write a simple demo program that exactly explains the problem and nothing else. This is the method I try to present most of the tricks in the Tricktresor. Describe the problem. Simplify the code. Present a solution.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Ralf Wenzel

    Hi Enno. This is really good stuff and I recommend not only to read, but to study this. If someone searches the solution, this search begins with building the question. My advice to all of “my” users is: “It does not work” is NOT an incident description. I need to know, what they have done in which way they have done it and – really! – I need to know, why they have done it (because some “incidents” are the result of a bad training or misunderstanding of the application).

    There is another advice for the “Netiquette”-thing: Do not use buzzwords like “urgent!”. Each problem is urgent, otherwise you won’t ask in a professional forum like this.

    And if someone provides you the solution of your problem and you think “oh my god, this is so self-evident” – don’t worry. We all have posted stupid questions. There are no such thing as a stupid question, but only stupid answers 😉   Sometimes, you just got the wrong track. Occasionally, I brood on a problem for hours, got to bed in frustration and at next morning, I did the first glimpse on my last day’s coding and BANG! the solution was there! 😀


Leave a Reply