An easy way of programmatically accessing the texts of any program: DATA: t_textos TYPE TABLE OF textpool. READ TEXTPOOL sy-repid INTO t_textos LANGUAGE sy-langu STATE 'A’. Now, you have all of the texts available in the internal table T_TEXTOS. As if this were not enough, you can also change the texts programmatically with the following commands: INSERT TEXTPOOL sy-repid FROM t_textos LANGUAGE sy-langu. DELETE TEXTPOOL PROGRAM LANGUAGE 'E’. According to SAP, these last two commands are for internal use only.

ABAP programmers don’t explore the possibilities of SQL, probably for historical reasons. There are many who instead of using INNER JOINs still think it’s faster to do several SELECTs for internal tables and then process the data in ABAP. But the truth is that even if there are exceptions, the rule is: the lower the number of accesses to the database, the better the performance. And it makes sense because, after all, they were written explicitly for this; relational databases are much more adept at processing relational data than an ABAP program. There are of course things that, due to their complexity, cannot be done with a simple INNER JOIN. Nevertheless, some of these things can be done in a single SELECT.

Here’s a cool mini-function to obtain some details of a remote system accessible by RFC: RFC_SYSTEM_INFO I cannot give any example here because it would reveal very important secret information about my client which would certainly be used by the baddies to perform industrial espionage. But it is easy to test in SE37. Thanks to kingofthebigmacs for the photo. Greetings from Abapinho.

If you look up the UNAME system variable in debug within a RFC call you may think it kind of odd to find a username that is not your own. What happens is that the system adopts a specific username for remote calls and a new session is started. A new session implies a new execution context and, hence, all our strategically placed breakpoints will no longer be recognised. This problem can hinder a simple debug forcing us to run through the code looking for THAT remote call to THAT particular system. SAP has a solution.

There are countless standard functions to make calculations with dates. There are too many of them, they are redundant and, in many cases, they are obscure or impossible to understand. I’ve been meaning to insert an article here with a list of the most useful ones. But now it’s no longer necessary.

Here’s a simple way to start debugging a job: Go to transaction SM37; Click on the job you want to debug; type JDBG in the command line (without /) and press ENTER; and… bang! you’re now debugging the job. Thank you Ricardo Monteiro for the tip. And thank you Ingolf for the photo. Greetings from Abapinho

Some months ago I showed how to transform the debugger into a time machine. Today’s tip is simple but useful: there is a keyboard shortcut which makes it even simple to travel in time: shift + F12 Just place the cursor in the line you want to travel to and then… shift+F12. Thank you Maxsuel Maia for the tip. Greetings from Abapinho.

And there you go, if you read the title you know the hint. Now, here are some hints about the hint:

Hello, my name is Abapinho and I’m 5 years old. I’m still growing up. Thank you to everyone who visited me during my short life and a special thank you to all those who participated with tips, ideas and posts. Greetings from me, Abapinho.

Recently, I have compiled a set of personal best practices. I decided to share them here by creating a new category (which will soon appear on the menu to the left) into which they will be grouped. The original idea was to make a PDF file but, since they are constantly being reviewed and expanded, this was largely impractical. As such, they will be published one by one. The goal is for these practices to be visible in their entirety as a user-friendly, accessible reference.

When a development is completed in SAP, the time to send it to other systems where it can be duly tested and then executed by users has finally arrived. Before that occurs, however, it has to be checked for lapses, errors and other problems that could lead to our programmes behaving in an unpredictable manner. There is a very useful tool that allows some of these errors and gaps to be filtered out. It is called ABAP Code Inspector.

How many times have you been left with a “hanging” window when you end a debug?

Unless you want to do data editing, the only dignified way to use ALVs these days is through SALV classes. They are more modern and more elegant, and those who use them can achieve a social status until now only available to owners of a license plate.

You are doing a LOOP AT in a 1000-line table, and you know that you want line 853. Until recently, you had two options: either hit F8 852 times, running the risk of hitting it 853 times and having to start all over again, or create a watchpoint with the condition SY-TABIX = 852 or something close, and pray that it worked. Now you have a third option.

ABAP is getting smarter all the time. Back in my day, no one did anything with it. And now, slowly, more than a fifth of a century late, it’s trying to imitate C and Java, and becoming more flexible. I was going to do something like this: