Add data to existing buffer in ABAP memory

[Former Member]

Hi All

My requirement is to store multiple data variables in ABAP memory, but my limitation is I have to loop an Itab and export these data one by one to memory. I tried using EXPORT....TO memory in the following way:

LOOP AT itab.

EXPORT itab-field1 TO MEMORY ID 'CONST_MEMID'.

ENDLOOP.

The problem is I dont want the previous contents to be overwritten. I mean the 2nd loop should not overwrite the contents written in the first loop. Any ideas how this can be achieved?

Thanks

SCPA.

[Former Member]

Hi All

My requirement is to store multiple data variables in ABAP memory, but my limitation is I have to loop an Itab and export these data one by one to memory. I tried using EXPORT....TO memory in the following way:

LOOP AT itab.

EXPORT itab-field1 TO MEMORY ID 'CONST_MEMID'.

ENDLOOP.

The problem is I dont want the previous contents to be overwritten. I mean the 2nd loop should not overwrite the contents written in the first loop. Any ideas how this can be achieved?

Thanks

SCPA.

[Former Member]

Hi,

You can move the entire internal table at one shot..instead of looping..

EXPORT itab[] TO MEMORY ID 'CONST_MEMID'.

THanks

Naren

[former_member194669]

Try to do this way.

TYPES: 
  BEGIN OF tab_type, 
    para TYPE string, 
    dobj TYPE string, 
  END OF tab_type. 

DATA: 
  id    TYPE c LENGTH 10 VALUE 'TEXTS', 
  text1 TYPE string VALUE `IKE`, 
  text2 TYPE string VALUE `TINA`, 
  line  TYPE tab_type, 
  itab  TYPE STANDARD TABLE OF tab_type. 

line-para = 'P1'. 
line-dobj = 'TEXT1'. 
APPEND line TO itab. 

line-para = 'P2'. 
line-dobj = 'TEXT2'. 
APPEND line TO itab. 

EXPORT (itab)     TO MEMORY ID id. 
IMPORT p1 = text2 
       p2 = text1 FROM MEMORY ID id. 

a®

[Former Member]

Hi

i forgot to mention some fields in the loop are deep structures. So if I declare a simple string table, I think it wont help. Infact what I am doing is something like this:

LOOP AT itab. (ITAB in turn contains names of fields)

ASSIGN (itab-field1) TO <fs>.

EXPORT <fs> TO MEMORY ID 'CONST_MEMID'. (Here <fs> can sometimes be a field or ITAB or a deep table)

ENDLOOP.

I know this is getting complicated, but hope somebody already worked on it.

[alejandro_bindi]

I don't think you can do that, how would you do the IMPORT afterwards without knowing the type of the data in memory?

If you can access the itab with the fieldnames (and the actually named data structures) from the place where you do the import, then you could create an incremental memory ID for each cycle, and do the import in the same order (generating the ID in the same way).

Something like this:

Export:

LOOP AT itab. (ITAB in turn contains names of fields)

ASSIGN (itab-field1) TO <fs>.
l_mem_id = sy-tabix.
CONDENSE l_mem_id.
CONCATENATE 'CONST_MEMID' l_mem_id INTO l_mem_id.

EXPORT <fs> TO MEMORY ID l_mem_id. (Here <fs> can sometimes be a field or ITAB or a deep table)

ENDLOOP.  

Import:

LOOP AT itab. (ITAB in turn contains names of fields)

ASSIGN (itab-field1) TO <fs>.
l_mem_id = sy-tabix.
CONDENSE l_mem_id.
CONCATENATE 'CONST_MEMID' l_mem_id INTO l_mem_id.

IMPORT <fs> FROM MEMORY ID l_mem_id. (Here <fs> can sometimes be a field or ITAB or a deep table)

ENDLOOP.  

If you really need to use only one EXPORT / ID, then I think you could use the alternative a®s suggested, generating one parameter for each itab entry. But still you'll need to generate that again when you do the import as you do for my solution.

Hope this helps.

Regards

Edited by: Alejandro Bindi on Dec 16, 2008 8:59 PM

sy-tabix, not sy-index.

[Former Member]

Hi All

Thank you very much for the responses. I was trying to make this as dynamic as possible and saving each object in seperate memory ids would make it difficult to monitor how many memory locations(datasets) get created. I have come up with an alternative where all my data variables get declared in a class and I will create an instance of the class in my program/application. After all the class attributes are populated, call the statement

call transformation id

source class_data = zcl_class (class instance)

result xml ostream.

OSTRING is of the type XSTRING which stores these class details in XML format. This is saved to the ABAP memory with the EXPORT statement and can be read back with IMPORT where needed and can be converted back to class data as follows:

call transformation id

source xml iStream

result whoami = zcl_class.

Thanks once again.

[alejandro_bindi]

Well, you could adapt the alternative a®s suggested to do something pretty dynamic.

However, if you're ending up using objects, you could make use of the Shared Memory Objects functionality instead of the classical EXPORT / IMPORT.

That way you could put in memory the actual object instance, instead of having to convert to/from XML.

Besides, it's a newer technology and offers monitoring capabilities.

Here you have a PDF on the subject: https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/900e3d9d-559e-2910-9dae-b132157a...

Regards

[Former Member]

Hi,

as far as i know u cant store deep structures and each export clear the existing memory... at least for shared memory. I think its the same for memory.

Regards

Stefan Seeburger