SAP messages are all managed centrally through the SE91 transaction, but can appear to a program in a variety of formats.

I was always told that, when selecting a single record, I should use UP TO 1 ROWS whenever the key was not fully provided. My elementary school teacher told me that I should always aks why: why? Nobody ever told me why.

Let’s say you want to show an url in a SAPScript layout. You place the url in a SAPSCript text and assume everything will work fine. Because most times everything does work fine. It’s just that sometimes…

While writing code, you should always keep present how easy it will be to maintain. This is particularly important in data declarations. And so easy to do right.

When you’re going to modify existing records of a database table it is common to first SELECT them to see how they are and only then UPDATE them with what they will be.

When I get to a new project the system administrator generates a development key for each development system assigned to our SAP username. Usually it’s sent to me by e-mail. Usually I lose track of it.

The new way to get data from internal tables is also the new way to put data into internal tables.

Picture yourself as a monkey hanging from a tree branch. You want to jump to another branch but it’s so far away that you cannot see it. If you jump you’ll probably fall to the ground. That’s bad.

There are many excuses not to use the new functional syntax of ABAP 7.4. One is complaining that it’s impossible to debug.

But it is not.

Data entered by the user is one of the main vulnerabilities of a programme.

ABAP evolves (even though it stood mostly still for too many years). And as it evolves, it leaves behind some commands and syntax constructions which are replaced by better ones.

Besides learning what’s new it is also important to learn what becomes obsolete.

Legibility is very important in all written text. Except, maybe, in concrete poetry.

As a follow up to the previous post, here are a couple of rules to help you deal with the negative in boolean expressions.

Because…why should they be complex to read? It would only make it harder to maintain in the future.

Just because an IF condition is complex doesn’t mean it has to be complicated.

ABAP SQL is becoming more and more interesting and powerful. My latest discovery is the ability to use CASE in SELECT.

How many times in your ABAP consultant life did you have to deal with dumps happening as a consequence of a program trying to insert duplicate lines into an internal table defined with a UNIQUE KEY?

Enough.