Skip to Content
Author's profile photo Otto Gold

Things that are cool to change for everyone and those you’d better don’t touch

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.


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.


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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Astrid Gambill
      Astrid Gambill

      I hope you get some answers...

      Author's profile photo Susan Keohan
      Susan Keohan

      Hi Otto,
      Thanks for blogging about this!  I like my code to be warning-free too.  And I think this is akin to the 'warning fatigue' that physicians complain of - too many warnings (bells, buzzes, yellow stoplights) and you will someday ignore a warning that is relevant!

      Looking forward to responses...


      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hi Susan,

      it is not very likely we get an "official response" here, right? Anyway I think it is good for the ecosystem and also for SAP that these things don't go unattended, because everyone makes mistakes (that's what I think it is - a mistake) and maybe they will learn something good for the future here.

      I am not a fan of bells and whistles either 🙂

      Regards Otto

      Author's profile photo Former Member
      Former Member


      nice blog and please keep on letting the rest of community know what you find out there, like SELECT * will be chosen because of a bogus warning - this should ruffle some feathers with Basis, shouldn't it?



      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hi Greg,

      thanks for the comment. Can I ask you a question? What would you do if you were in their shoes? I mean if one is a good developer and understand the memory consumption and DB<->app communication, he or she is not doing SELECT * for ages (unless all fields are needed, of course). So IMO there is no need for these bells and warnings. Would you add a "technical mean" to "support" the developers not doing SELECT *? How do you check your system and folks so they're not doing this? Just out of curiosity.

      Cheers Otto

      Author's profile photo Former Member
      Former Member

      Hi Otto,

      i wish i had a system just to myself, but reality is that we need to share the scarce resource with the rest of the system users. i can understand where SAP is coming from to prevent unjustified use of the computing power and aiming for the lowest common denominator. people smarter than me watch for someone inexperienced doing damage and i trust their judgement. i do however see and have a need to run a SELECT *, and that's ok if done in moderation and i don't need to be reminded that it's not a best practice (reminds me a bit of that paper clip-man in the office applications some time ago.)



      Author's profile photo Paul Hardy
      Paul Hardy


      I have one thing to say about two of your points.

      Firstly, at my company we have spent ages peppering our code with #TOO_MANY_ITAB_FIELDS.

      I understand the concept - you don't want a big internal table filled with blank data - but in real life this is just a stupid warning.

      In regard to the change to the pattern for function modules

      I have been bitten many times by just uncommenting the MESSAGE SY_MSGTYP etc... comment that is automatically generated and then presuming the function module will actually pass out a message when it raises an exception

      Some fucntion modules, including a vast amount of standard SAP function modules do not rause the exception by saying


      but just


      Thus, if you just have the standard generated code SY-MSGTYP will be blank, and you will get a short dump. This is a Bad Thing.

      However, if you are really sure that the fucntion module in question will always have the system message variables filled after raising an exception e.g. because you wrote it yourself, or you have looked at the code insde the module, then instead of having to look through your prior programs, what I did was cut and paste the standard MESSAGE TYPE SY-MSGTYP etc code into my "Z BUFFER" in the ABAP editor and then I could paste it back whenever I wanted.

      That buffer has been filled that way for years .... the reason it is so difficult to remember is that each time SAP defined an error message structure they named all the fields diffrently e.g. MSGNO vs MSGNR etc and you can never remember which structure uses which convention.

      I wonder how many person years of programming have been wasted converting the message structures of BAPIRET2 to BDCMSGCOLL or vice versa, or even either of them to and from the standard SYST table. All three use different naming standards.

      SYST = MSGTY



      If someone can provide me with a bigger example of utter lunacy from standard SAP i am all ears.

      Cheersy Cheers


      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hi Paul,

      I quite like you positive tone. Create your own pattern. Sure, that's the way to go. 🙂

      You raised a great point with SY-MSGNO ... in case there is no message. I learnt the hard way too. Maybe others get this through a training or from colleagues, but I personally must have missed that somehow. Now I leave (copy from old code) the pattern, but always check if the messages are provided. If you have strong opinions on message handling and favourable and infavourable ways and/or recommendations, I would find it fun to read a blog about it. I've been doing this for quite some time now, but you seem to be in business even longer and I appreciate every opportunity to learn something new or a trick or two. Please consider a blog. 😉

      I have one last thing on my agenda. I would like to ask you a question (you can start with the one I am asking Greg above too). What is your "normal reaction" to such a warning? Does that motivate you to go and define a new local type or even a DDIC type, that would use the memory properly? I am trying to think the way the were thinking. Why did they do this? BTW SELECT * is really the fastest way how to get the warning go away. Do you personally believe this will educate anyone? Steer the wagon in the right direction?

      Out of curiosity: you say "at my company we have spent ages peppering our code with #TOO_MANY_ITAB_FIELDS". Could you be more specific about these ages? I am fighting this new "invention" for days only, I used to work on an older system without the "invention". Will that eat much of my time? 😕

      cheers Otto

      Author's profile photo Paul Hardy
      Paul Hardy

      My colleagues and I have an obession with having a "clean sheet" on the various SAP syntax checks e.g. SLIN, and so every time we change one of the myriad Z objects (programs / functions etc) that have been written in the past 16 years in go the #TOO_MANY_ITAB_FIELDS.

      This probably has not taken that ong really, it just seems like a long time because every second you spend doing something that you feel adds no value is one second too long.

      My gut feeling is that SAP wants me to define a TYPe with just the fields I want, and then a table type, and then a table based on that table type as opposed to be being based on the actual database table I am reading from.

      That would save some memory, but nowadays we have about six time morme meory than is ever going to be filled dven if all the users went bananas at once, so am i really gaining anything?

      The purist in me says do it anyway (declare local types etc) the reality is we are all always under so much pressure the temptation to just paste in ##TOO_MANY_ITAB_FIELDS is just overwhelming.

      Nobody at my place has succumbed to the SELECT * option and thank goodness for that.!

      Cheersy Cheers


      PS appropos exception handling, after many many months I am just starting to see the benefit of exception classes but I am still dipping my toe in the water. When i get to the end of this particular journey i will write a blog about it.

      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer

      Also, the automatic "Message" after a function module call can cause some problems when the function call is used in a WebDynpro, BSP, Webservice, or anything non-SAPGui.

      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hi Tom,

      thanks for adding this comment. I didn't realize this. Can you elaborate on what kinds of problems? I am not that experienced in that areas so I would like you to add more color here for me. I can imagine that the patterns are not "context sensitive", so it would be too much of a hassle to keep the old behavior if the patterns pastes into the "normal (means old skool) ABAP code" and behave differently when you paste the code into WDA for example.

      Anyway, please add some more infos, I am curious.

      Cheers Otto

      Author's profile photo Tom Van Doorslaer
      Tom Van Doorslaer

      Well, If you use the message statement in anything other than SAPGui, your program dumps. The message statement is intended to send a pop-up to the front end (which only works for SAPGui)

      But if you're not in the SAPGui, the backend fails to send a pop-up to the front-end, resulting in an unexpected error, and the whole shabam just dumps.

      That's why there's a development standard that you must never raise a message in an API. (Be-it BAPI, Class, BOL, Z-API,...) That's what the RETURN table is for 🙂

      Author's profile photo Former Member
      Former Member


      "No, thank you: Warnings from the syntax check"

      I also have an obsession with a clean code, but NOT JUST of warnings but the CODE ITSELF should be clean and written the right way.

      My mind almost exploded after you added the following note: "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" - congratulations you know how to bypass the warning (that's exactly what the warning says !!!!)

      The warning is good and is needed for those ABAPers who write "disgusting" code - like define struct/table on the whole MARA instead of just defining a few fields they really need. This is not hard, and also right.

      The bottom line,

      "I want my code to be "green" "you should apply  also on the code itself, it's more important.

      We don't have to agree on all the issues. Keep up with your blog.

      Contributors are more than welcome.


      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hi Dmitry,

      I would like to make sure we are on the same codepage. Do you understand that the purpose of this blog (or at least the section about the warning) is to say that for "an average developer who does not care or does not get it" it is much easier to go for SELECT * than anything else? I am not suggesting a shortcut/ the wrong thing to do here. I am saying that IMO too many will go for SELECT * instead of (doing the right thing) either adding the pragma or even defining the "minimal" work area.

      We are not in a disagreement here. Maybe it is the way I tell things. Half of my creations here on SCN are half sarcastic (if not more). I want my code to be squeaky clean from the design phase. That also includes my "execution of the design". And that is why I complain about "inventions" that are going against the trend (IMO).

      In case I didn't get your comment right, I am sorry. But I am not sharing a "trick" how to be fast and dirty here. Quite the opposite. Maybe read the piece again?

      cheers Otto

      Author's profile photo Martin Maruskin
      Martin Maruskin

      Hi Otto,

      great blog! I recently ran into the issue of many warnings produced by SLIN. I was about to put  ##TOO_MANY_ITAB_FIELDS in all places where it was yelling on me. But then I found your blog and realized that my code with this new pragma will not work in older versions. So I dropped this attempt. Now I'm producing a lot of warnings which may cause that QA people at some customers will not approve to promote it to further system. What I will do is I'l leave a short note explaining this situation.

      Anyway there should be a better way how to handle this. Maybe some system profile parameter controlling checking of pragmas can be introduced? Is there some SAP guideline on this topic?



      Author's profile photo Otto Gold
      Otto Gold
      Blog Post Author

      Hi Martin,

      unfortunately I haven't found a way how to transport my code to the older NW 7.00 releases when it contained pragmas. My understanding is that it is not possible and we cannot control/ influence/ change that. I partially converted my development to use local types (what a pain just to get the warnings go away), partly I ignore the warnings.

      Maybe if we complain enough, someone will come help us 🙂

      cheers Otto

      Author's profile photo Volker Borowski
      Volker Borowski

      Any News concerning this Transport aspect to older releases?


      Facing the same Problem.

      Right now, we run a program removing the pragmas on 7.0 after the import and rebuild a Version 7.00 Transport with the same objects.

      Just a pain, and an additional possible source of mistakes.