Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

BW ABAP string value not being saved when running from transaction

Former Member
0 Kudos

I have a large ABAP program used to upload flat-files into BW. The code contains an include which checks what system the code is being run on and updates a SERVER_PATH variable accordingly. i.e. if the user runs from BWD the temporary files are stored on the BWD server for later load to BW and BWP likewise.

The parent code is contained in a BW transaction ZIGGI.

When the code is run from ZIGGI the value for SERVER_PATH remains "initial"

When the code is run directly from SE38 the case statement returns the relevant value

Can anyone explain why this is happening and/or how it can be stopped...?


 DATA: SERVER_PATH TYPE string VALUE 'initial'.
*&---------------------------------------------------------------------*
*& Code to vary the server path depending on the system the code is
*being run on *
*&---------------------------------------------------------------------*
case sy-sysid.
  when 'BWD'.
    SERVER_PATH = '\bwdevtbwdtemp'.
  when 'BWP'.
    SERVER_PATH = '\bwpsrvbwdtemp'.
  when OTHERS.
    SERVER_PATH = 'default'.
endcase.

7 REPLIES 7

maciej_domagaa
Contributor
0 Kudos

If the variable SERVER_PATH remains with value "initial" it means that the program flow control never reaches the "case" statement you mentioned when called from transaction ZIGGI.

To explain why it behaves like that you must check the rest of your code (before that "case" statement). The best idea to find out what is going on would be to use the debugger (start ZIGGI transaction, at its initial screen type "/h" in the t-code field, hit Enter, process some next step in your ZIGGI transaction - you will see your code in action)

good luck

0 Kudos

but why when I run the program from SE38 does it behave differently?

since the transaction just calls the same program shouldn't it be identical? I've tested several times with several other people with me too and the same result happens each time...

0 Kudos

ideas?

0 Kudos

please...

0 Kudos

1. Make sure your transaction is of the right type (type chosen when creating transaction code).

2. Check statements in your code like:

if SY-TCODE = ...

regards

0 Kudos

1) so what is the "right type"?

2) again why would statements in my code behave 1 way if the code is run from se38 versus from the transaction?

0 Kudos

anyone?