"
Supported by

The RANGEs double negatives

RANGEs have interesting properties.

Take these two lines as an example. They look the same but they behave differently:

SignOptionLow
INEX
EEQX

Crazy, right?

Yesterday I bumped into yet another weird double negative which I had never thought about. When using a RANGE as a criteria in a SELECT WHERE and the range is empty, the criteria will always return TRUE. It is counter-intuitive because the mathematically correct would be FALSE (after all, the value is not in the range), but the way it behaves is very convenient as we all know. An empty RANGE behaves like a wildcard. Ok. Fair enough.

But, what if we add a NOT:


DATA r TYPE RANGE of kunnr.

SELECT * FROM kna1 INTO TABLE @data(t)
WHERE kunnr NOT IN r.

The RANGE is empty so we’re sure none of the KUNNRs will be there so, mathematically speaking, it should always return TRUE. But, since the empty RANGE works as a wildcard and returns TRUE when it should return FALSE,… its negative will return FALSE when it should return TRUE. And this is good. I guess…

Greetings from Abapinho.

2 comentários a “The RANGEs double negatives”

  1. Tas Diz:

    Nuno, RANGE são muito úteis, mas é preciso muita cautela ao se utilizar com grande volume de dados. Já tive algumas experiências negativas, onde ocorreu dump por conta da tabela de range estar com muitos registros.

  2. Nuno Godinho Diz:

    Olá Thiago,

    Sim, sem dúvida. Penso que já abordei isso num artigo há alguns atrás. Imagino que dependa da base de dados e das configurações do seu parser de SQL. Raramente uso ranges com centenas de entradas. Mas quando o decido fazer (porque causa da limitação de só se poder ter um FOR ALL ENTRIES por query) a minha regra de polegar é não deixar passar dos 1000-1500 registos, ainda que saiba que em alguns casos dá para mais. Obrigado pelo aviso!

    Abraço,
    Nuno

Deixe um comentário


About Abapinho
Abapinho runs on WordPress
Articles (RSS) e Comments (RSS).