Since data operations are much more optimized in the database server than in ABAP, it is always better to use the first as much as possible. FOR ALL ENTRIES should only be used when INNER JOIN doesn’t give us what we need or is not possible (like with BSEG for example). Artificial ranges are also a possible alternative to FOR ALL ENTRIES but be careful not to reach the SQL parser limit.
User-exits (and enhancements) are usually crowded with CHECKs. The tragic consequence is that, if the check fails, nothing else after it will run. Not even the standard code. Always try to correct these. Encapsulating the code inside a routine (ideally a method) is enough to render it harmless.
When declaring structures which will receive data from an internal table, instead of declaring its type directly, use LIKE LINE OF. This way not only it becomes clear that they are related but also, if you happen to change the type of the internal table, you won’t have to worry about updating the structure’s type.
I keep learning new transaction commands. Today I learned some which solve a problem which, although rarely, has happened to me in the past.
Did this happen to you? You make a change to a text of a data element you’re using in a table to be edited through SM30. But when you go and edit that table in SM30 the old text is still there. You activate objects, close windows, open windows, no matter what you do, the new text is not shown.
Never do COMMITs inside user-exits. Also, make sure any external routine you call from there doesn’t do any COMMIT either.
Of course you already know the “Model” button in the ABAP editor that allows you to automatically add models for function modules, calls for methods and others.
The new editor has now grown a bit (it’s now only 10 years behind Eclipse instead of 20) and it allows you to automatically complete some commands through the CTRL-SPACE shortcut.
If a development requires more than one customising table consider grouping their maintenance views under a cluster. This way it will be more intuitive to maintain them. This makes even more sense if one depends on the other since in the cluster definition these relations can be explicitly defined. Example: Como encavalitar tabelas (portuguese)
Always try to select only the fields you’ll need. Selecting others is a waste of resources. Exception made for the use of FM *_SINGLE_READ because, even though these do select all fields, since they cache the data, they are still faster when used multiple times for the same key. If you just want to check if a record exists, select just one field, if possible the one you’re using as criteria to avoid declaring an extra variable.
Whenever you feel a constant value can change and you can’t add it as a user parameter, store it in ZCONSTS. This table should never be used directly. Instead, a class like ZCL_CONSTS should be created to properly access it, like shown in this article: (portuguese only) Resist the temptation of using T900 or similar tables for this purpose. It’s true that a lot of people do it. But it’s ugly, durty and besides these tables don’t even have an adequate key because they were not designed with this in mind.
When you touch an object and add it to a transport request, it becomes locked there by default. In a transport request you can also lock objects which are not yet locked in another order. But, once locked, how to unlock them?
Code which is used very often should be made available centrally, if possible under a single package (ex: ZTOOLS) so that it’s easily identified. There is a lot of code already available on the Internet to accomplish several common functions (ex: ABAP2XLSX). Adopt it; For your most common tasks, develop your own tools which you can reuse and add them to the central library; Advertise the existence of that library among your colleagues to avoid that they waste time come up with duplicate code wasting;
Sweet little trick: when in SE38 you need to surround a word or expression with () or [] or ‘’, just select it and press ( or [ or ' and it immediately becomes (it) or [it] or ‘it’. Thank you Sérgio Fraga for the tip.
If you need to adapt the content of a file with amounts, always take into consideration the user settings (USR01-DSCFM). If you need to convert a string to a number use FM MOVE_CHAR_TO_NUM. If you need to convert a number to a string use WRITE curr TO str [CURRENCY waers].
Using SELECT-OPTIONS is one of the very few reasons for using TABLES. For all other cases, explicitly declare a local variable for the equivalent structure. TABLES basically creates obscure global variables which increase ambiguity in the code. And global variables should be avoided anyway.
