ABAP Export to Database / Memory area

[former_member201275]

I have a program with a selection screen with a field ‚run_type‘.

When the program is executed I save the ‚run_type‘ to memory i.e.

EXPORT run_type FROM lv_run_type TO DATABASE indx(zw) ID 'RUN_TYPE'.

The output from this program is an alv grid which has a button for ‚booking‘. When this button is clicked then an event is triggered and in this event i have:

import run_type to lv_run_type from database indx(zw) id ‚RUN_TYPE'.

This however seems not to be working. For example when ‚run_type‘ ‚abc‘ is selected and the button in alv is clicked, the import statement sometimes returns a different value.

I think this is because someone else is also executing the program at the same time and therefore the database field is getting filled with another value.

How do i get around this?

[michael_piesche]

If I understand you correctly, you are doing everthing in one session: 1) executing your program, 2) display of ALV, 3) pressing button "booking".

Instead of "TO DATABASE", you could also use "MEMORY ID", which is only visible for the current session:

EXPORT run_type FROM lv_run_type TO MEMORY ID lv_memory_id.

IMPORT run_type TO lv_run_type FROM MEMORY ID lv_memory_id.

Whereas to database can be accessed from all other sessions, and your value will be overwritten by other sessions, that is, if you dont handle the specified index more carefully to avoid this.
Please make yourself also familar with the ABAP documentation about the export statement.

But instead of Exporting it to Memory or Database, I would look for another solution within your program and creating global variables within, this way you would also limit the access not only to the current session but also to the relevant programm.

Unless I still dont understand why you would have to choose the ABAP Tools export/import.

[former_member201275]

Hi Michael,

thank you for your answer. It is because the program is calling a class and this field is not passed as one of the Parameters, and therefore when the 'booking' button is pressed in that part of the Code non of the selections from the original program are available.

[michael_piesche]

gemini.twin, then you still have the following options:

1. In this case "TO MEMORY ID" will still also work and would be a better fit than "TO DATABASE"
2. You could also use the "dirty assign" method, where you access the variables of any calling routine from within your booking method (ASSIGN (‘(your_programm)lv_run_type’) TO <runtype>.)
3. But you could also add a global class variable to that class where you set the run_type when it is set and call it from your class when the booking button is pressed

If I only had these options, I would probably favor option 3, but still all options require knowledge from outside your "booking method" and this makes it harder for other developers to understand the full logic, but considering factors such as development time, impact and complexity, I would recommend option 1 with comments to why and where these memory variables are set and read.

[former_member201275]

Thank you so much for your advice!

I am not sure i can go with option 3. I can add an import parameter ‚RUN_TYPE‘ to my class HR_CL_RUN, however this class calls function module REUSE_ALV_GRID_DISPLAY_LVC.

Then i have a program HR_PGM_RUN which has a subroutine i.e. 'form user_command' which executes according to the button pushed in the ALV.

As soon as I use the REUSE_ALV_GRID_DISPLAY_LVC i no longer have my parameter RUN_TYPE, i.e. in program HR_PGM_RUN there is no more instance of the original class.

Forgot to Mention; the callback program specified in the Parameters of REUSE_ALV_GRID_DISPLAY_LVC is a different program to the one that starts the process.

[michael_piesche]

gemini.twin, "TO MEMORY ID" will solve your problem. Are you able to implement this? If not, let us know why.

[FredericGirod]

Did you check the possibility of using SHMA ?

[Nawanandana]

Hi,

If the data is exported using EXPORT...TO SHARED MEMORY... then it will be visible to across internal sessions. if it will be visible to across user logins.

If the data is exported using EXPORT...TO DATABASE... then it is "persistent" and is available to any user, any internal session, any time.

If the data is exported using the syntax EXPORT...TO MEMORY... then it is visible ONLY within the same internal session (basically, within the call stack of a program).

Further Data Clusters