My current client’s system is finally being upgraded to 7.50 and, after all these years stuck with the old ABAP, I am now finally able to enjoy the wonders introduced in 7.40.

There are dozens of these wonders and I don’t intend to start making a post on all of them as there is already so much quality information on most of them. Besides, Abapinho always tries to write about something new or, at least, not very known.

But this simple functionality, although not that extraordinary, pleases me: you no longer need to add IS INITIAL in an IF command when the condition is a method returning a boolean.

Some time ago we spoke about SAAB and its advantages as a tool to analyse, debug and find problems in our code. In that article we didn’t explore an important aspect of it: Activation variants.

We have all used implicit enhancements to add code to the beginning or end of a standard function, form or method. But you may not know that it can also be used to add fields to data structures, whether they’re declared as TYPES or directly as DATA.

We learn in school that all code should have comments. Then, in real life, we find that not everyone was paying attention to what was said in school. As a consequence, most code is obscure and without proper comments.

I was always careful to comment every relevant step of my code, specially the parts which are obscure or not self-explanatory.

But since I recently read Uncle Bob’s Clean Code , my opinion on this changed. Today I believe that the less comments the better. And yet, I don’t see this as contradictory to what I used to think.

Even though you look at an SAP system as a whole, it is composed by several distinct and interconnected parts. There is a small standard program which checks if each part’s clock is correct and synchronised.

It probably won’t be of much use for your daily work. Still, it’s an interesting curiosity.

The view below shows how simple it is to create the conditions to inject ABAP commands into programs in a productive system. I considered whether to publish this. But, as it already happened in the past, I believe it is better for this to be known because it is very important for system administrators to be aware of this so they can protect their systems against this threat. Thank you Ricardo Monteiro for the tip.

Some time ago you created a table and its maintenance screens as local objects.

When, later, you regret it and decide to transport the table, how will you be able to also transport the maintenance screens?

Transporting the maintenance screens function group together with the table is not enough.

I was sure I had already posted about this before but I can’t find it so here it goes (again?).

Some function modules save global data which must then be used by another function module belonging to the same function group. So, if you need to test them, they must run in sequence inside the same transaction.

Everybody knows you can use SE37 to test a function module. What few people know is that you can also use SE37 to test a sequence of function modules inside the same transaction. Those who don’t know this end up creating a small program to call those functions in sequence and that’s also ok. But here’s how you can avoid that.

The PARAMETERS and SELECT-OPTIONS already have some configuration options. But sometimes you need more control, more customising. Interestingly, although it’s not simple nor obvious, it can be done through a standard function module.

In a well protected system, normal users don’t have debug permissions. Very often, this makes it harder for ABAP programmers to help solve the users' problems, not being able to debug directly in their session.

But there is a legit, albeit obscure, work-around for this problem.

Here we are again facing a dilemma: hide something because it is dangerous and someone can do bad things using this information or teach it because it would be condescending to presume the readers are not responsible enough to know it. Dictatorships usually go for the first: burning books, censorship, etc. Abapinho like to believe that its readers are responsible people and deserve the right to know.

Thus, here it is. No, it’s not a user manual on how to enrich uranium nor a formula for homemade nitroglycerin. But it’s something similar: a trick that allows you to change standard objects without the need for a key.

As we all know, system adminstrators are very bad, cold blooded and cruel people. To prove it you just need to read the Bastard Operator from Hell.

We, ABAP programmers, are hopeless victims in the hands of these evil creatures.

But not always do we have to be smashed under their hairy fingers.

By default SE16N always shows the values in the external format, applying the conversion exit to all of them. Until recently, I used to go the ancient SE17 whenever I needed to see them in their internal format. But Rui Nunes told me how to do it in SE16N.

Here’s a not very orthodox wat to deal with a report’s selection screen. Sometimes you may need to have a special parameter which you prefer to hide from normal users but still need access to. Example: a flag to activate a debug/trace mode. I’ll show you how you can do this by just typing the magic word, ABRACADABRA. It goes like this: DATA: unhide_parameters TYPE flag. PARAMETERS: p_debug AS CHECKBOX. AT SELECTION-SCREEN.

I recently found a program which was generating an SQL statement by concatenating several variables with fixed SQL parts. But, either by not paying attention or simple ignorance, the person who did it, thought it would make sense to associate a text-symbol to each of these variables with. Something like this: