"
Apoiado por

O caminho mais curto para ir de SELECT a RANGE

Hoje debruçamo-nos sobre como tentar optimizar o código para transformar um SELECT num RANGE.

Comecemos pelo código mais simplório, sem qualquer tentativa de optimização:


DATA: lt_kunnr TYPE STANDARD TABLE OF kunnr,
        lr_kunnr TYPE RANGE OF kunnr,
        wa_kunnr LIKE LINE OF lr_kunnr.
FIELD-SYMBOLS:  LIKE LINE OF lt_kunnr.

SELECT kunnr
  INTO CORRESPONDING FIELDS OF TABLE lt_kunnr
  FROM kna1.

wa_kunnr-sign = 'I'.
wa_kunnr-option = 'EQ'.
LOOP AT lt_kunnr ASSIGNING .
  wa_kunnr-low = .
  APPEND wa_kunnr TO lr_kunnr.
ENDLOOP.
  • 7 comandos
  • 4 variáveis
  • 15 linhas

Há 8 anos atrás sugeri que podia ser um pouco melhorado:


DATA: r_kunnr TYPE RANGE OF kunnr,
      wa_kunnr LIKE LINE OF r_kunnr.

SELECT kunnr AS low
  INTO CORRESPONDING FIELDS OF TABLE r_kunnr
  FROM kna1.

wa_kunnr-sign = 'I'.
wa_kunnr-option = 'EQ'.
MODIFY r_kunnr FROM wa_kunnr TRANSPORTING sign option WHERE low <> ''.
  • 4 comandos
  • 2 variáveis
  • 10 linhas

Entretanto, com o ABAP 7.40 a manipulação de tabela internas sofisticou e permite simplificar mais:


DATA r_kunnr TYPE RANGE OF kunnr.

SELECT kunnr AS low
INTO CORRESPONDING FIELDS OF TABLE r_kunnr
FROM kna1.

r_kunnr = VALUE #( FOR wa IN r_kunnr
                   option = 'EQ' sign = 'I'
                   ( low = wa-low ) ).
  • 2 comandos
  • 1 variável!
  • 9 linhas

Mas depois o Sérgio Fraga mostrou-me que o SQL também sofisticou e permite agora fazer algo que não podia ser mais simples:


DATA r_kunnr TYPE RANGE OF kunnr.

SELECT 'EQ' AS option, 'I' AS sign, kunnr AS low
INTO CORRESPONDING FIELDS OF TABLE @r_kunnr
FROM kna1.
  • 1 comando!
  • 1 variável!
  • 5 linhas

Nada mau! Melhor só mesmo se conseguisse declarar a variável inline mas não sei como o poderia fazer.

Actualização: o Gabriel mostrou que é de facto possível declarar a variável inline:


SELECT 'I' AS sign, 'EQ' AS option, kunnr AS low, kunnr AS high
INTO TABLE @DATA(r_kunnr)
FROM kna1.

É apenas fundamental que os campos sejam listados nesta ordem, incluindo o HIGH, para que a tabela interna gerada inline seja considerada um RANGE válido. Obrigado Gabriel!

  • 1 comando!
  • 0 variáveis!
  • 3 linhas!

Os 7 comandos, 4 variáveis e 15 linhas ficaram reduzidos a 1 comando e 3 linhas. Agora sim, parece-me impossível simplificar mais!

O Abapinho saúda-vos.

7 comentários a “O caminho mais curto para ir de SELECT a RANGE”

  1. Rui Dantas Diz:

    Porque a meio passamos para lfa1?

  2. Nuno Godinho Diz:

    Ops! Obrigado! Já substituí todas as LFA1 por KNA1 :)

  3. Pedro Monteiro Diz:

    Excelente :)

  4. Nuno Godinho Diz:

    Que bom que gostaste. Também gosto bastante deste artigo :)

  5. Luís Sismeiro Diz:

    Muito boa dica.

    Quando combinada com a transacção STVARV e a tabala correspondente, TVARVC, ficamos com uma combinação poderosa.

  6. Nuno Godinho Diz:

    Olá Luís,

    Ainda bem que gostaste.

    Em relação à TVARV e à TVARVC… sugiro que as deixes de usar como tabelas de constantes. A meu ver é uma má práctica que, infelizmente, por alguma razão se generalizou. Estas tabelas são usadas pelo sistema para guardar variantes da SE38. Não só usá-las para outra função é pouco limpo como estas estão longe de ser as tabelas ideais para guardar constantes porque não foram desenhadas para isso.

    Sugiro espreitares o abaK (https://github.com/abapinho/abaK). É fácil de instalar e em tudo melhor para esse objectivo. Qualquer dúvida diz.

  7. Luís Sismeiro Diz:

    Obrigado Nuno. Vou ver o abaK. :)

Deixe um comentário


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).