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:
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:
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:
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:
Make sure the user is the same
Date or number format may be different:
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:
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
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".
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.
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.