Skip to Content

ABAP Language News for Release 7.40

This blog summarizes a series of blogs that I have written about the most important ABAP language news for Release 7.40 during the last few month.

Getting Started

First you might be interested in

What is ABAP 7.40?

Then you can

Warm up with Expressions.

ABAP News by Subject

Have a more detailed look at

After all of this, surely it is time to say bye, bye to MOVE and COMPUTE

Learn More

Lookup the News in the ABAP Keyword Documentation.

Come to CD261 at TechEd 2013 (rock your code with ABAP 7.40)!

There is also a slide deck around somewhere.

More News

Meanwhile, support Packages are out that are bundled with new kernel releases and that come with further new ABAP features.


for further enhancements of the ABAP language!

You must be Logged on to comment or reply to a post.
  • Hi Horst,

    Do you know if there is any plan to adjust the SAPGUI based ABAP editor syntax highlighting for the new 7.40 syntax?

    Program like DEMO_HTML_BROWSER or DEMO_CALL_DB_PROCEDURE look strange there, however it looks ok in Eclipse ADT.

    My SAPGUI is 7.30 Patch 6 Hotfix 1.



    • Hi Peter,


      in my


         SAP-Frontend für Windows

         730 Final Release





      it looks fine.





      • Hi Horst,


        Thanks for checking it. So it must be kernel or BASIS SP issue.

        Since it's a newly installed ECC 6.0 Ehp7 system, it was not patched yet.


        Can you maybe also send me some info about this?

        Our system:

        Kernel 7.40 patch 37

        SAP_BASIS    740    0002    SAPKB74002    SAP Basis Component


        Thanks in advance,


        • Hi Peter,


          That's not that easy to answer since our development systens at SAP  always represent the latest support package.Since the functionality was delivered with AS ABAP 7.40, SP02, the editor should look OK from that release on (Kernel and ABAP).


          I Checked a SAP NetWeaver 7.40, Kernel 7.40, Kernel Patchnumber : 42 and it looks OK there.



  • Thanks for posting all this here for all the poor guys who do not have access to a 7.40 System.


    It's well written and I like the "before 7.40" and after technik, that realy helps to see the differences.


    Thanks TIMO

  • Actually I love this new feature with the google-like search in SE80. I didn't see it anywhere mentioned (only for the Eclipse environment - I guess it was developed mainly for ADT, but ported back to SE80), but it's really nice feature, so it's  also worth to mention. It seems already available in 731 release also (just checked for in a system with SP08).


  • Hi Horst,


    Can we expect some data type like Boolean, as we have in other Languages ?


    In fact, in ABAP we are forced to waste a complete CHAR1, in order to decleare a boolean value like abap_true or abap_false.


    Thanking You All.

    • Hi Ankit,


      I'm afraid it is too late for that.


      One reason that we cannot simply introduce a new type is it's name.


      For each meaningful name (BOOL, BOOLE, BOOLEAN, ...) there might be conflicts with already existing names in the dictionary or in existing programs. And who wants to have a name with a lsmaller  risk of conflict but that is awkwardly long? The names of our DECFLOAT16 or  DECFLOAT34 introduced with 7.02 are already much too long  for that reason.





      • Hi Horst,


        Thanks for the reply.


        But I just wanted to know,


        Why are we forced to use 16 bits ( by using CHAR1 ),

        if we can get the same thing done in 1 bit ( by using some sort of boolean variable ).


        In fact just I was curious to know that,

        What stops SAP, to have a 1 Bit Data Type for boolean ?


        Is there any other bottleneck apart from the nominclature problem ?


        Thanking You All.

        • Hi Ankit,


          The problem of downward compatibility is in fact the main hindrance factor for introducing a new data type.


          Another one is simply the effort. Introducing a new data type into the language can be done but is only the tip of the iceberg. There are tons of tools that also have to be adjusted.





  • Horst,

    We are upgrading to 7.40 and I am using your blog to guide out developers into these new things.

    But we remark that some previously obsolete statements have become syntax errors.

    One of them is this one: the use of the "*" in "*credat".

      SELECT *
        FROM  pa0001
        WHERE pernr  EQ *zft_bcf-pernr
          AND endda  GE *credat
          AND begda  LE *credat.


    Is there an overview of these disappearing obsolete statements? Some SAP-document might help me to convince our developers they have to change their way of working.


    If you can already confirm this one has officially become an error, that is already a start.

    Thanks for helping.


    • Hi Kris,


      Now this one is funny.


      Yes. we recommend not to use an asterisk (*) as the first character of a name, see or


      But, alas, ABAP allows an asterisk as the first character of a name. Run my program DEMO_CHARACTERS_IN_ABAP_NAMES that shows the real situation (isn't it cool?).


      So, the above syntax is not nice (tell your developers!), but unfortunately correct. You found a bug. The new Open SQL Parser believed in the good in man and hoped that nobody would use such names. Well, now it seems that it was ony a question.of time, til somebody stumbled over it.


      My Open SQ colleague has fixed the kernel directly after forwarding your comment; check out upcoming sap note 1978210 (created only minutes ago)..


      Now you can wait for the kernel patch or - much, much better - convince your colleagues to use better names .






      PS: Here is a list of the intented syntax changes (bug fixes) in Open SQL:!ABAP_MODIFICATION_5@5@

      • Hi Horst,

        probably could be not a bug....


        In Sap, i'm able to write code like this:


        TABLES: bkpf, *bkpf.




        SELECT * FROM bkpf.

          WRITE:/ bkpf-belnr, sy-uline(65).

          SELECT * FROM *bkpf WHERE awkey = bkpf-awkey.

            WRITE:/ *bkpf-belnr.






        I used to call "*bkpf" table as "Abap cluster table" (not strickly in sense of Db terminology).

        As you can see, i can use the same table like an "alias".




        I know very well that today, this syntax is "obsolete" and it's not the "right way" to procedd.


        But in old Sap releases (i.e: 3.0/3.1)  some standard programs used this syntax.




        Best Regards


        • Hi Andrea,


          Your above code uses the obsolete short form of SELECT.


          For reasons of downward compatibility you can still write this outside of classes and if you don't use new syntax like a @ in front of host variables:


          TABLES *scarr.


          SELECT * FROM *scarr. "No Syntax Error



          DATA carrier TYPE scarr-carrid.

          SELECT * FROM *scarr WHERE carrid = @carrier. "Syntax Error



          Kind regards



  • /
  • Hi Horst,

    I'm an ex ext. developer -> SCM (DP/SNP)...(SSC Building)


    There are only two things I need to know:


    1. WIll it ever be possible to use group name field in dictionary structures for other cases than using it with move-corresponding ( or will meshes be used here )...Fieldcatalog?.. SELECT statement?


    2. Why is it not possible to export and Import single system data when using SAP LOGON.. will it ever be possible to do that? (Maybe XML, waiting for this simple feature for about 15 years now)




    • Hi Thomas,


      1. WIll it ever be possible to use group name field in dictionary structures for other cases than using it with move-corresponding ( or will meshes be used here )...Fieldcatalog?.. SELECT statement?

      As far as I know, there are not such plans. The possibility of defining the group name is simpy for being able to define a global structure in the same way as a program local structure with INCLUDE TYPE ... AS name. The purpose is only for adressing all components of an included structure inside an ABAP program. The group name is even not relevant for MOVE-CORRESPONDING. I don't see a releation to meshes here.


      2. Why is it not possible to export and Import single system data when using SAP LOGON.. will it ever be possible to do that? (Maybe XML, waiting for this simple feature for about 15 years now)


      Not my department!


      (but would like that too )

  • /
  • Hello Horst Keller,


    First of all thanks a lot for this excelent blog!


    I am using the most I can the new tools of the latest ABAP release but I am having an issue and maybe you, or someone, could help me.


    Type with only company codes

    types ty_company type table of bukrs.


    Now let's say that we have a local table lt_t001 with a lot of company codes.


    My goal is to insert all the companies in lt_t001 to lt_company with CORRESPONDING command:


    data(lt_company) = CORRESPONDING ty_company( lt_t001 mapping table_line = bukrs ).


    I am having an error "The type C is not a structure".


    When I use tables with only one column, I can refer to it, in loops for example, with the command table_line, but it seems that the CORRESPONDING can not deal with it.


    Am I doing something wrong or must I go to the old fashion loop and append a company in lt_company for each iteration of lt_t001?


    Thanks a lot

    Sérgio Fraga

    • Hello Sérgio Fraga,


      Unfortunately, the pseudo component table_line cannot be used as a component of an internal table in the mapping rule.


      This was not clear, when the recent documentation was released but added in a later version. In fact, the developers then still hoped to get it running .


      As a workaround, you might create a structured table type with one named component.




      • Thanks a lot for your quick answer Horst,


        That's too bad but let's have faith on those developers!


        The workaround is nice but it doesn't make sence to create a workaround just to force the use of new command..I will go the old fashion loop for now..



        Sérgio Fraga

  • I do have a SELECT-issue and don't know a solution for that. I want to make the following:


    Given a list of languages, we want to get all valid languages in a selection range table.


           "! list of languages
           doku_langus      TYPE w_pc_clang,

           "! selection range of languages
           doku_langu_range TYPE RANGE OF spras.


         SELECT 'I' AS sign 'EQ' AS option spras AS low
         INTO CORRESPONDING FIELDS OF TABLE doku_langu_range FROM t002
         FOR ALL ENTRIES IN doku_langus
         WHERE spras EQ doku_langus-table_line.


    Syntax Check says:

    1. divide columns by comma => OK

    2. trail host variables with @ => OK

    3. FOR ALL ENTRIES with host variables are not allowed. =>DEAD END


    Has anyone a solution for that without modifying the range table with MODIFY....? I just want to make a single select to get a selection range.

    • Try new syntax:

      select 'I' as sign, 'EQ' as option, spras as low

        from t002

        for all entries in @doku_langus

        where spras = @doku_langus-table_line

        into corresponding fields of table @doku_langu_range

    • I wonder why you open that discussion here, but OK ...


      Funnily, I had a similar problem some weeks ago.


      You want to do something like this:


      TYPES doku_langus TYPE TABLE OF t002-spras WITH EMPTY KEY.
      DATA(doku_langus) = VALUE doku_langus( ( 'D' ) ( 'E' ) ( 'F' ) ).

      SELECT 'I' AS sign, 'EQ' AS option, spras AS low
            FROM t002
            FOR ALL ENTRIES IN @doku_langus
            WHERE spras = @doku_langus-table_line
            INTO TABLE @DATA(doku_langu_range).


      This is not possible, because for the time being FOR ALL ENTRIES is not allowed together with host variables in the SELECT list.


      Why not beat it with another RANGES table?


      TYPES doku_langus TYPE RANGE OF t002-spras.
      DATA(doku_langus) = VALUE doku_langus(  sign = 'I' option = 'EQ'
                                              ( low = 'D' ) ( low = 'E' ) ( low = 'F' ) ).

      SELECT 'I' AS sign, 'EQ' AS option, spras AS low
            FROM t002
            WHERE spras in @doku_langus
            INTO TABLE @DATA(doku_langu_range).


      Instead of looking up a FOR ALL ENTRIES table, you can look up a RANGES table, at least in such a simple case.

  • Hi Horst,


    Superb Doc!!!


    One doubt: suppose I am using a read statement like: (10,000 records)


    DATA(ind) = line_index( lt_vbak[ vbeln = '7000015769' ] ).


    I tried comparing the time taken by Binary search and this new style.

    It seems the new approach is taking more time for this kind of read statement.


    Is it possible to specify BINARY SEARCH in the new coding style some how ?


    Please do let us know.




  • Hello,

    Is there any possibility, to use some kind of "corresponding #" in FOR loops?


    In my case, I have a table, with a several columns which I filled via a select,

    but I have to fill one of the columns with a concatenated value.

    ("SELECT ... awkey = belnr && bukrs && gjahr" is not working in our release)


    So I'd like to replace this, by a FOR loop if possible:

    LOOP AT lt_tab ASSIGING FIELD-SYMBOL( <ls_tab> ).

         <ls_tab>-awkey = <ls_tab>-belnr && <ls_tab>-bukrs && <ls_tab>-gjahr.




    Many thanks in advance for some hints how to do this

    • Maybe you can use String-Templates ( || ) instead of &&:


      &lt;ls_tab>-awkey = |{ &lt;ls_tab>-belnr }{ &lt;ls_tab>-bukrs }{&lt;ls_tab>-gjahr}|


      Do you use the new Open-SQL syntax with @ for variables usage? Like this:


      SELECT f1, f2, f3 FROM table INTO @lt_tab

        WHERE f4 = @lv_input.


      Maybe this can solve your problem with the SELECT.

      • I tried:





          |{ belnr }{ bukrs }{ gjahr }| as awkey

          into table @DATA(lt_table)

          from bseg.


        And also this:





          belnr && bukrs && gjahr as awkey

          into table @DATA(lt_table)

          from bseg.

        which in general should work - if all variables were CHAR, but GJAHR is NUMC, but CAST to STRING/CHAR is not available so far but only to FLTP or DEC

        (We are currently on EHP7 SP 9)

        That's why I was looking for an easy way for a FOR loop instead

        • You are right, documentation for "sql_exp - sql_string" sais you can concatenate:


          Unfortunately, corresponding to my knowledge does not support anything else than explicit column names for the mapping, i also missed something like that already. It would be nice to have something like this for your case:

          lt_tab_new = corresponding #( lt_tab mapping awkey = |{ belnr }{ bukrs }{ gjahr }| ).


          You could use VALUE, but i think you lose both performance and readability:


          lt_tab = VALUE #( LET lt_backup = lt_tab IN

              FOR ls_segment IN lt_backup

          ( belnr = ls_segment-belnr

            bukrs = ls_segment-bukrs

            gjahr = ls_segment-gjahr

            awkey = |{ ls_segment-belnr }{ ls_segment-bukrs }{ ls_segment-gjahr }| ) ).


          (LET is needed, if you want to reuse lt_tab for the result of the value expression).


          Another option for immediately assembling your table would be a SELECT ... ENDSELECT instead of the SELECT INTO TABLE followed by your loop.

    • It seems that the solution can't be done directly in the SQL Statement due to the fact that BSEG is not a transparent table.

      The only solution I found would be the following (using a FOR expression) :



            BEGIN OF ty_s_bseg,

              belnr TYPE bseg-belnr,

              bukrs TYPE bseg-bukrs,

              gjahr TYPE bseg-gjahr,

              awkey TYPE string,

            END OF ty_s_bseg.



          TYPES: ty_t_bseg TYPE STANDARD TABLE OF ty_s_bseg WITH EMPTY KEY.



          SELECT bukrs, belnr, gjahr

            FROM bseg

            INTO TABLE @DATA(lt_db_bseg).



          DATA(lt_table) = VALUE ty_t_bseg( FOR <ls_db_bseg> IN lt_db_bseg

                                         ( CORRESPONDING #( BASE ( VALUE #( awkey = |{ <ls_db_bseg>-belnr }{ <ls_db_bseg>-bukrs }{ <ls_db_bseg>-gjahr }| ) )

                                         <ls_db_bseg> ) ) ).

    • You might also check the capabilities of ABAP CDS for your release. It might support there more string functions than Open SQL already. You can easily wrap the access to transparent tables in CDS views and access those with Open SQl.

      • Well it seems, that for the time beeing, the fastest and easiest way is still


             <>-AWKEY = <>-BELNR && <>-BUKRS && <>-GJAHR.



        As the only meaningful options would be either having this kind of concat directly in the select, or having something like Thomas Krügl supposed:
        lt_new_tab = CORRESPONDING #( lt_tab MAPPING awkey = |{ belnr }{ bukrs }{ gjahr }| ).

    • Hi, you find the ABAP release information directly in your system, TA ABAPHELP, enter "News" and off you go. The most recent news matching the EHP of your system are listed at the top.