Why NOT to use Field-Symbols to access Global Memory?

By | November 29, 2011 | Tricks | 8,089 | 3

Sometimes, we don’t have access to all the variables which we are looking for. Especially this happens when we are working with CMOD user-exits, BADI implementation, etc. So, we do it this way:

Access Global Memory using FS

* This code is inside a BADI implementation where global memory 
* of SAPMV45A is available
  field-symbols: <fs_xvbap> type standard table of vbapvb.
  assign '(SAPMV45A)XVBAP[])' to <fs_xvbap>.
  if sy-subrc eq 0.
     "Further logic to access data from <fs_xvbap>

Where it is used

  • This is used frequently in the CMOD userexits, BADI implementations, where we don’t have access to all the memory.
  • We can also use this technique inside debugger to quickly access variable and check its content.

Why to refrain using it

It was mainly used to communicate between program and debugger in old debugger. Since introduction to new debugger from ABAP release 640, this technique to access global memory using field-symbols is obsolete. Moreover this statement is system statement, so it may be discontinued at any time. Although it doesn’t appear that it would go away any time soon, but it should be used with extreme care.

It is also dangerous from data integrity perspective since memory is accessed via field symbols, it can be easily changed. If it is used by anyone who is not fully familiar with downline usage of those variables, than it may create serious issues.

Best possible solution

We can use implicit enhancement point in the program from where we want to use the global memory. In this implementation we can save the data in global memory of a function group. And we can get back the values where ever required using another FM in the same FG so we can have access to the data what we have just saved.

Like It? Share!!

Don't miss an Update

Get notified of the new post, right into your inbox

Naimesh Patel{271 articles}

I'm SAP ABAP Consultant for more than a decade. I like to experiment with ABAP especially OO. I have been SDN Top Contributor.
Follow :

Explore all of his 271 articles.

Load comments


  • Kesav

    Yes !!! Did not even think about such option when its available.
    Thanks Naimesh

  • marcin

    I totally agree with suggestion of not using memory access this way. Nevetherless if one decided to use, please pay attention that it would work only if programs run in one internal session. That is you can’t SUBMIT, CALL TRANSACTION and then access memory of caller using this technique. More on this can be found here http://forums.sdn.sap.com/message.jspa?messageID=9249839.

    Of course if one sticks to best practices, it would never be required to use it that anyway. Hey! what do we have an ABAP/SAP memory for :)

  • Naimesh Patel

    Hello Marcin,

    Thanks for pointing out the nice summary.

    I’m also not fan of EXPORT / IMPORT to MEMORY. There are couple of problems with it. Like, We don’t know from where it was exported and to where it is imported.
    Since, we lost the context in CALL TRANSACTION, SUBMIT, EXPORT to MEMORY won’t even work. It would only work, if we do it EXPORT to DB or SHARED BUFFER.

    Naimesh Patel

Comments on this Post are now closed. If you have something important to share, you can always contact me.

You seem to be new here. Subscribe to stay connected.