Suppressing an insuppressible warning while INSERT INTO itab

Question

I am adding a new entry to a sorted internal table inside a loop. As the loop I'm in has a sort order that's different from that of the sorted table, I have to use an INSERT INTO statement instead of an APPEND TO as the latter risks violating the sort order causing a dump.

However, when I add that code, I get a syntax check warning with internal message code "MESSAGE GJK", in EPC it says:

Program: ZCL_CLASS Method METHOD_NAME Row: 301
Syntax check warning.

In the table "LT_TABLE_NAME" a row was to be changed, 
deleted or inserted. It is not possible
to determine statically if a LOOP is active over "LT_TABLE_NAME"

Internal message code: MESSAGE GJK
Cannot be hidden using a pragma.

But "Cannot be hidden using a pragma" just doesn't work for me. I understand the reason for the warning but I know at build time with 100% certainty that no loop will be active on the internal table that I'm inserting new records into. Yet I cannot hide this warning. Aside from causing useless warnings while developing, in some environments I wouldn't be able to transport code with syntax check warnings in it!

Is there any way to suppress this insuppresible warning?

Failing that, is there any way to avoid it? I can probably do so by using a temporary unsorted table as an intermediate and then just APPENDing the rows into the sorted table, but I balk at creating a useless (million-row) internal table just to bypass what seems to be a glaring oversight.

Answer 1

The most likely reason for getting this warning is actually a syntax error! It will happen whenever you've got a statement like the following:

INSERT [work area] INTO [internal table].

The actual syntax for insert into an itab requires INTO TABLE:

INSERT [work area] INTO TABLE [internal table].

The warning's description doesn't seem to match what is actually happening here. Presumably it's considering that the table might have a header area (which is not the case). If you run this code, you'll get a TABLE_ILLEGAL_STATEMENT dump with a much more descriptive error message:

An attempt was made to change, delete or add a row in internal table "[internal table]". There is no valid cursor for this table however.

This is actually the second time I've encountered this but it's such a confusing message that I didn't remember the solution. I didn't intend to self-answer when I posted this but I realised my mistake when I got the dump. I'm guessing the main problem is relying on syntax errors to tell me when I'm using incorrect syntax: syntax check apparently doesn't consider this an outright error even if it probably should.

Answer 2

This message cannot be supressed, as it has been already stated in your previous question. However, we can get rid of the initial cause of the problem and it is the only right way of doing here. This error reports that some operation on internal table was carried out using implicit index specification, as it described in detailed message:

During the program flow, the current LOOP row is used, this means INDEX sy-tabix is used. If no LOOP is active over the table at this time, the runtime error TABLE_ILLEGAL_STATEMENT occurs.

For the current case of such an implicit operation, no encompassing LOOP statement for the table can be statically found (using the syntax check).

For some reason compiler doesn't see your loop and therefore cannot find loop index. What can be done in that case:

1. Use INSERT wa INTO TABLE instead of short form of INSERT.

2. Use explicit index for you INSERT statement

   INSERT wa INTO itab INDEX loopIdx.
   

ABAP documentation for INSERT wa INTO itab syntax variant confirms that this syntax requires LOOP:

This variant is only possible within a LOOP across the same table and if the addition USING KEY is not specified in the LOOP. Each row to be inserted can be inserted before the current row in the LOOP.

P.S. Full text of this message could be fetched using DOCU_CALL FM passing message code TRMSG_MESSAGE_GJK there. All message codes are stored in DOKIL table.