Skip to end of metadata
Go to start of metadata


You have run a transaction with the same actions in 2 ways (from SAP menu or BDC, dialog or background, etc.), but they ddi't produce the same result.

There can be many symptoms. You checked all other FAQs but you still don't understand what the issue is.

The following table shows all the possibilities that can be cause of a different behavior.

Real examples, how to use the table:

  • Example 1: the CTU works when you execute it interactively with E display mode, but doesn't work anymore when you use N display mode, let's say a screen is displayed without error message which means screen is not expected.
    • By reading the table, we see that the following are excluded: #1 because SY-BINPT is 'X' in both E and N display mode, #2 because SY-BATCH is always space in both display modes, #3 because SY-CALLD is "X" in both cases, etc. But these ones can be the culprits: #4, #8, #9.
  • Example 2: when you run the transaction via CTU (with default options), it looks like different (text editor is ugly, old-fashioned) than when you run the transaction normally from the SAP menu.
    • We see that #1 is a good culprit as SY-BINPT is "X" when CTU is run, but it is space when run from the SAP menu. #3 (SY-CALLD) could also be the culprit.

Detailed description (meaning of variable or return values)



SY-BINPT value may vary:

  • 'X' if execution is via CTU provided that CTU_PARAMS-NOBINPT is space, or via BI session
  • space otherwise

If via CTU, set CTU_PARAMS-NOBINPT = 'X'. If via BI session, execute it via RSBDCCTU with NOBINPT = 'X'. You have to enter its Queue ID (you see it in SM35).


SY-BATCH value may vary:

  • 'X' if it's run via BI session with display mode N
  • 'X' (again) if it's run via CTU or BI session with display modes Q, D, H, S
  • space otherwise
    Note: if the program is run in a background job, SY-BATCH is also set to 'X', whatever the options of the BDC are

You may try to do a new recording using "simulate background mode", then run it again in both display modes. If it's the same issue, then SY-BATCH is not the culprit. If another issue occurs, then check the other entries of this table


SY-CALLD value may vary:

  • Space if the transaction is called from the SAP main menu or from LEAVE TO TRANSACTION statement
  • 'X' otherwise (if called by CALL TRANSACTION, etc.)

Create a program which only does a LEAVE TO TRANSACTION to the transaction you want to record, then do a recording of SA38/SE38 to call this program


BDC_RUNNING function module: it can detect precisely how the transaction is run.

Unfortunately, the only solution is to modify the code where BDC_RUNNING is used, or use a substitute to BDC


SY-SUBRC may vary after an authorization check if the user varies:

  • If the BI session in 'N' or 'Q' mode runs with the user indicated in the BDC_OPEN_GROUP parameter
  • Otherwise it runs with the current user

Make sure the user is the same


Date or number format may be different:

  • The BI session in 'N' or 'Q' mode runs with the date or number format passed to BDC_OPEN_GROUP, or if blank the user parameter* otherwise it runs with the format of the current user

Make sure that the user formats are identical to the parameters


Dump CNTL_ERROR may be generated because controls can't be displayed via BI sessions in 'N' or 'Q' mode, or in a background job

Unfortunately, the only solution is to modify the code to either not display the control when run in BDC, or use a substitute to BDC


The BDC stops before the end, no error is indicated. It happens when:

  • You run in 'N' or 'Q' mode, the BDC stops at the first COMMIT WORK statement
  • You run CTU without CTU_PARAMS-RACOMMIT = 'X'

For CTU, you may overpass this behavior by setting CTU_PARAMS-RACOMMIT = 'X'. For BI session, you may call it by converting it into CTU using RSBDCCTU program and call it with RACOMMIT checkbox ticked. You'll need to get its Queue ID from SM35


  • With 'N' or 'Q' mode, for "inactive" screens (see question May I remove the BDC_CURSOR lines systematically? above), the cursor is positioned at the first field
  • With the other modes, it is positioned as during the recording of the transaction (often at the first input field of the screen)

Make sure BDC_CURSOR is filled for these "inactive" screens


Scrolling in table controls. If the program doesn't assign a function code to the scroll key, scrolling is impossible in BDC. For more information, see the FAQs below "How to scroll a table control".

  • First, make sure if the program implements a function code to scroll or to position directly
  • If the function code is only able to scroll, then think to use the Default screen size (see below the point about DEFSIZE)


When an input field doesn't need to be changed (initial value is correct), in one case you rewrite it (with same value) and in the other you don't, then the transaction may work differently because statements of the screen flow logic can identify that the content was rewritten (for example FIELD ... MODULE ... ON REQUEST)

Either write the input field in both cases, or don't write it at all.


Asynchronous updates. Symptom is often a lock issue. Chained transactions work intermittently (first always work), especially works best when there's a delay between each transaction (WAIT UP TO, debug, All-screens mode). Maybe there is an asynchronous process in previous transaction that was not over. When you execute it in screen by screen mode or debugging it, you give time to the asynchronous process to finish. When several BDC are chained, a previous BDC probably used an asynchronous update task to update tables, which is not finished yet. That could also be asynchronous RFC or submitted jobs, but that's far less frequent.

  • The best solution is to execute the BDC with synchronous (S or L) update mode. See Update mode chapter in Batch Input - BDC for more details.
  • Another solution is to wait a few seconds (ABAP statement WAIT UP TO x SECONDS), but it is not advised as performance will be degraded if many BDC are executed as you force a delay between each, or the delay may not be sufficient if the system happens to be slowed down a lot.


DEFSIZE and step loop/table control. Number of lines may vary according to screen size. If it's executed in All-Screens mode, and BDC was initially run with standard screen size option (CTU_PARAMS-DEFSIZE = 'X'), then number of lines in table controls may be less than in All-Screens mode.



SAP memory (SPA/GPA parameters especially) is not refreshed. In chained transactions, first one succeeds but the next ones systematically fail, or first one fails but the next ones succeed. The issue is often a screen (with financial area input field) that is displayed because the SPA/GPA parameter (of the financial area) is not set, but is set when the input field is entered, so the screen is not displayed at the next transaction call.


  • No labels