Skip to Content

Archived discussions are read-only. Learn more about SAP Q&A

Basic Question related to Negation IS INITIAL or IS NOT INITIAL

Hi Experts,

I am in confusion regarding very simple conditional statement.

which one is preferred in the following condition statements.

1. IF NOT so_vkorg-low IS INITIAL

Perform validation

ENDIF.

2. IF so_vkorg IS NOT INITIAL.

Perform validation

ENDIF.

3. IF so_vkorg-low IS INITIAL.

Do nothing

ELSE.

Perform validation

ENDIF.

I have read some where checking negation in a condition statement is not preferred, Instead go for other way around .

Expecting some valid points from experts

Thanks

Sreeni

Former Member
Former Member replied

Hi Sreeni,

I'm surprised to see such question coming up, but to be honest, I'm even more surprised to see the answers posted so far. Since release 6.10 the version [IS NOT INITIAL|http://help.sap.com/abapdocu_70/en/ABENNEWS-610-OTHERS.htm#!ABAP_MODIFICATION_3@3@] is available and should be used. The simple reason is that this is the most legible version and thus should be preferred over version 1. After all, ABAP programs are rather verbose and statements reflect English language. If in doubt read it to your grandma and check which version she understands - though I'm not saying that this should be the standard test for figuring out how to code....

Version 3. is obviously silly, because it's misleading (introduces a branch that is not required) and increases the number of statements (makes the program harder to read - at least in those cases where the additional statements are not inserted for simplifying some otherwise hard to understand construct/algorithm).

Anyhow, as mentioned by previous posters, there's no real performance difference among those statements. The statement you've heard about possible performance impact of negations refers most likely to database selects where a select with a condition containing a not equal (i.e. "<>") might result in the database ignoring an index for selection, though the selection via index would've been faster.

The layman's explanation to this phenomenon is that the cost base optimizer (i.e. the part of the database that decides how to read the data) sees a not equal, which indicates that for this field probably the majority of rows are matching (since you're only excluding one specific value). Such an assumption is based on an even distribution of data, which you don't always have. E.g. let's take an order status field with lots of completed historic orders in the system. If I select all the orders with status not equal to complete, I should end up with a fairly small number of orders (compared to the number of entries in the whole table) and thus should most likely use an index on order status if present (and no other better index is available).

Please note that my explanation of the possible performance issue is a simplified version and I've just added it to put your statement into context. In the end it means that once you have such a select, you should see whether it works fine or not and tune the statement if it's slow.

Cheers, harald

0 View this answer in context
Not what you were looking for? View more on this topic or Ask a question