Notes about updating this blog: last update is 6/9/2013 and is marked red. Be careful about TOO_MANY_ITAB_FIELDS in combination with older NW relases!!! Also if you cannot find a way how to create your own pattern for message raising which got removed from the CALL FUNCTION pattern, check the screenshot where to go.

<rant>

Dear SAP,

I have just upgraded my system and there are several things I would like to ask you about. There are things that would be very cool if you could change them for everyone, every single SAP system at some stage (via upgrades and for new installations too). But there are also things, that don’t help at all. They don’t help me at least. Of course, this is my opinion only, and I am more wondering about your reasons (please share it with us, we are listening), than a blind criticism.

No, thank you: CALL FUNCTION pattern in SE80

First of all the trigger for this blog: When I use the function module pattern in SE80 after the upgrade to Basis 7.31, the default message handling is gone. I could understand what might have been the reason: you want the developers to more active and instead of just leaving the MESSAGE code there as the default handling, you want the developers to actually do something, right? Well, ok, good idea. But the problem is that (if I am not mistaken), the default MESSAGE statement was there for so long, that thousands of developers (more like millions?) have gotten used to it, they have been designing their code with this “feature in mind” and last but not least they have been very efficient using this particular part of the pattern.

I was FAR MORE efficient before you changed this. Now, when I use the CALL FUNCTION pattern, I must go search for a section of code, where I have this message handling from the old times. I want it the old way, but the system took it away.

Did you run a Design thinking session first and that got you this idea? Well, the source of the idea is not that important for me. Did anyone think about the impact? That is far more important for me.

Quick fix: (as suggested in the comments below)

No, thank you: Warnings from the syntax check

Example number two: I am a tidy developer, I don’t like warnings in my code and that is why 99,9% of my code is warning free (in case you’re interested, that 0,1% of the code with warnings is shortening the real field length to a shorter length for SQL operations; then I am able to compare something that is 40 characters long field, but I know it only has 20 characters long value with a DB field that is 20 characters long by definition; if you wonder what is the reason for this, it is of course the fact that fields with same values are often defined differently and I don’t want to spend time on conversions).

Now, after the upgrade, all my code turns yellow, because of the funny warning that you’ve introduced, that one can hide with pragma called ##TOO_MANY_ITAB_FIELDS. For those who don’t know it yet: if you define your work-area as type MARA, but you only select MATNR field, you will get this warning telling you that your work-area is too big which is a waste of memory (I am guessing that is the reason here). In case of single field I can understand that, total waste. But how often we – normal average ABAPers – select half of the fields from a table (knowing that we don’t need the other fields and that is why we don’t ask for them, we are efficient with our SQLs by naming the fields we want, so why do you tell me the same thing with this new warning?) and to be fast (and spare ourselves the effort to define a local or even a DDIC type) we define the work-area as TYPE TABLE OF whatever we’re querying?

Screenshots follow, so we all are on the same code-page:

I want my code to be “green”. I don’t want any warnings. I must go and get rid of these so that I can see the IMPORTANT warnings – those telling me PROBLEMS with my code. Maybe the intention is right, but honestly… I don’t appreciate this particular effort. If it must be there, because customer asked for it, ok. But give me a mean to turn it off. Is there such way? I have checked the documentation and didn’t find one.

Added later: There is a very VERY fast way how to get rid of this warning. Guess what. If you perform SELECT * instead of listing the fields so you’re now using all fields of your work-area, the warning goes away. I don’t want to argue about your good intentions, dear SAP, but what is your estimation that people don’t go this way? My estimation? Well, people hate annoying warnings more than sub-optimal database access…

Added 6/9/2013

If you build software, that is not meant for one system only, be careful with peppering your code with the pragmas. Older relases don’t know anything about pragmas and will produce errors during the import of a transport.

Please do: clients 001 and 066

On the other hand there are things that are very good and the right way for the sake of the better world to do in the SAP standard. An example from the recent history would be the blog by Frank Bucholz: How to remove unused clients including client 001 and 066.

See my comment below the blog asking when we don’t install these clients at all instead of following instructions how to remove them. Frank is well known for his effort to make the world better, so the fact that I am highlighting his blog is to appreciate an important piece of information for everyone. It is not a criticism in any way. But it is also an appeal on SAP to finish doing the right thing here – don’t install what we don’t need. Taking care of these clients is for me far more important than adding warnings or removing patterns that add more work for the normal mortals.

</rant>

p.s.: If anyone knows how to get rid of these new “features”, please let me know. If anyone can explain why they are there and I am wrong, please also leave a comment.