You remember having written a method some years ago which you need now. You know it had the word MALMEQUER somewhere in its name. But what now? How will you find it? You could use transaction SE24 to look at every class you worked on since then. But that would probably keep you busy for ages. Don’t do that. Try using transaction SE84 instead:

Let’s say you want to call a method for which you don’t know the parameters. What do you do?

You used to have to use the “pattern” button. Or open the class in a new window to look at the method’s parameters. But then the ABAP Editor evolved and we got auto-complete which made everything much more easy.

But there is yet another way.

When I want to search for a word in an ABAP program I usually press CTRL-F to use the normal search feature of the ABAP editor. I enter the word I want to find and then press “NEXT” to look for it.

But there is another way. And it’s not better nor worse. Just different: the incremental search.

When a method returns a value as a RETURNING parameter this is always done by value and not by reference. Several of my methods return internal tables, some of them quite large. It always worried me the idea that, since it’s being passed by value, ABAP would be returning a copy of the internal table, impacting both performance and the program’s used memory.

Fortunately, I recently learned that this is not​ a problem.

When you try to insert a record with a key which already exists in the table the program dumps. This, in some cases, is not desirable because, even if you don’t care, it forces you to check if the keys already exist before trying to insert then. But ABAP has a solution for these situations: INSERT dbtab FROM TABLE itab [ACCEPTING DUPLICATE KEYS]. Don’t worry because this will not violate the first law of thermodynamics: the duplicate records are not inserted.

Sometimes a thing is right under your nose and your still don’t see it.

At my current client I daily work with a lot of different systems. When I make a change in a setting of one system, either because I’m lazy or because I forget, I end up not applying it to all the others.

But there is a simple way to copy all the ABAP Workbench settings at once from one system to the other.

By default, the ABAP version comparison tool is horrible. It displays both versions in a single column and, even though the differences are highlighted, it’s awfully confusing. But it doesn’t have to be this way. Press the “settings” button at the top and you’ll find that there are 3 different display modes (besides some other nice options): one-column, two-columns and, surprise, the Split Screen Editor. This is probably the option you’ll want to choose since it’s the most powerful.

Earlier today I was doing a QC review to a new program named ZSDFAKSPE with almost 1000 lines and no comment whatsoever. An obvious clone of a standard program called SDFAKSPE.

So I decided to use the Spli-screen editor, found in transaction SE39. Having entered both programs I could then compare them side-by-side.

Being used to develop in Java and C++, the way transaction SE24 forces you to navigate between each of its parts and the fact that every method has its own include was very confusing to me when I first started using it. Why does SAP always have to make things so complicated? I eventually got used to it. At some point in time SE24 introduced the option source-code based which shows the class and all its methods in a single text.

Imagine that you’re editing one of those ancient programs with thousands of lines (yes because today you know that it’s wrong not to modularize (it’s a sin really) your methods (yes because today you always use methods) don’t have more than 200 lines).

You you call a function via RFC you need to provide the RFC DESTINATION for the remote system:

CALL FUNCTION ‘ZSNEEZED’
  DESTINATION ’sistema_longe_daqui’.

What if, for some reason, the function running in the remote system needs to call a function in the original system? How would you do it?

Although a substantial part of an ABAP programmer time is spent debugging code, most programmers I know don’t invest much in getting to know the ABAP debugger. Maybe because they spent too many years working with its previous version which was truly archaic and worthless. But the new one can do much more than you usually ask of it. And Abapinho intends to teach you how.

Today I’ll teach you just a simple key.

When you debug you use F5 key to move to the next statement (or go inside a sub-routine). But imagine an IF with multiple conditions:

IF A = 1 AND B = 2 AND C = 3.
  WRITE 'I like the word glauc'.
ENDIF.

When you debug through that IF using F5 and one of the expressions is false you’ll step out of the IF without knowing which of the three was false.

But the new debugger has a new very neat functionality which can help you to better understand what happened there.

Every once in a while I find yet another hidden SAP virtue. I just found out that there is a transaction which, for a given word in a given language, will help you translate it to another language by showing you which other translations already exist for that same word. How cool is that? Ok, it’s not Google Translate, but it’s a nice help. Oh, I almost forgot. The transaction is called STERM.

Sometimes ABAP SQL doesn’t allow you to do something you’d be able to do using the database’s native SQL. It can still be done.