Using the Field-Symbols instead of Internal Tables

[kranthi_kiran5]

Dear Experts,

I am new to the Field symbols, I need some help in coding since my programs need to use the one year data in MSEG table, i am trying to change the program from internal tables to field symbols.

I have facing the problem in converting the for all entries using internal table to field symbols,

Select  vbeln posnr from vbap into table lt_vbap for all entries in lt_vbak where vbeln = lt_vbak .

I need to use the same query with field symbols i.e., lt_vbap & lt_vbak should be a field symbols

Can we do all the operations like using

• Where conditions in loops
• Sorting
• Parallel cursor method
• Deletions,
• Appending moving data from field symbol to internal table and vice versa.
• Comparing the values in work area.

I have checked the all the post, available,

[matt]

Can you tell me why you're moving to field symbols? if it's for performance, then it only makes sense to convert things like:

LOOP AT itab INTO wa.

   " make changes to wa

  MODIFY TABLE itab FROM wa.

ENDLOOP.

to

LOOP AT itab ASSIGNING <wa>.

  " make changes to <wa>.

ENDLOOP.

Generally converting everything to field-symbols will just make your code more complicated without any benefit.

Otherwise, everything you can do with ordinary fields you can do with field-symbols. However, you have to make sure you get the TYPE right. If you have <mara> type any then you can't use <mara>-matnr. If you have <mara> type mara, then you can!

[kranthi_kiran5]

As i have obertved from the following Link: http://zevolving.com/2009/12/use-of-field-symbols-vs-work-area/

i have move to field symbols,

In my program i need to fetch the data from the MSEG for the entire year,

while executing the report i have scheduled it in the back ground(executes approximately mare than a hour), if i execute the same report in foreground it is giving timeout error, So i am trying to implement it using Field Symbols.

[matt]

Well, as I said in my first response, and as the link you post confirms- you only get a performance improvement with work areas. Converting the tables to field-symbols doesn't do anything.

I am NOT new to field-symbols; I've been using them for 15 years...

Have your run a performance trace on your program, using ST05, to find out where the db access is, and see if perhaps it can be improved with an index?

[uppu_narayan]

Hi Kranthi,

       Following is a code snippet that have tried on my system where i am using dynamic internal table in for all entries and in where clause..............

FIELD-SYMBOLS : <lt_sflight> TYPE STANDARD TABLE,
                <lt_connid> TYPE  STANDARD TABLE,

                 <fs1> TYPE any,
                 <fs2> TYPE any.
DATA : lt_tab TYPE TABLE OF sflight,
        lt_sflight TYPE TABLE OF sflight,
        lt_connid TYPE RANGE OF sflight-connid,
        ls_connid like LINE OF lt_connid,
        ls_sflight TYPE sflight,
        lv_str TYPE string.


SELECT * FROM sflight into TABLE lt_tab UP TO 10 ROWS.


ls_connid-sign   = 'I'.   "I = include, E = exclude
ls_connid-option = 'EQ'.  "EQ, BT, NE ....
ls_connid-low    = '0400'.
*wa_ebeln-high   =    "not needed unless using the BT option
append ls_connid to lt_connid.

*APPEND '0400' to lt_connid.

ASSIGN '0400' to <fs1>.
ASSIGN lt_tab to <lt_sflight>.
ASSIGN lt_connid to <lt_connid>.
*CONCATENATE 'connid' '=' <fs1> INTO lv_str SEPARATED BY space.
CONCATENATE 'connid' 'IN' '<lt_connid>' INTO lv_str SEPARATED BY space.
ASSIGN lv_str to <fs2>.
SELECT * FROM  sflight INTO TABLE lt_sflight FOR ALL ENTRIES IN <lt_sflight>
          WHERE (<fs2>).
LOOP AT lt_sflight INTO ls_sflight.
      WRITE:  /,ls_sflight-connid.
ENDLOOP.

Note: I have not followed any standards so i hope you will do so like before using for all entries you need to do a check etc.........

I hope this will resolve your issue for some extend.......

thanks and regards,

narayan

[matt]

Do bear in mind this is just an example of how to use field symbols, and how you might be able to use a generically typed field symbol in "for all entries".

It is in no way is a real-life scenario, since you gain nothing except to make the code more unreadable and harder to maintain.

You might also like to ponder on the fact that, contrary to common belief, FOR ALL ENTRIES performs, in most cases, more poorly than INNER JOIN. So for preference, use INNER JOIN.

[uppu_narayan]

Yes Mr. i completely agree with you, this is just an example........

thanks and regards,

narayan