Tag > estilo
Supported by
Supported by Inetum

The *_SINGLE_READ functions

images/thumbnail.jpg - Thumbnail
When you need to derive a single record from a database table, you normally use SELECT SINGLE, which is like this in its most basic form, as everyone knows: SELECT SINGLE * FROM KNA1 WHERE KUNNR = '1234567890'. Of course, if you are interested in just a few fields, ideally you select them explicitly to avoid copying unnecessary data from one side to the other: DATA: lv_name1 TYPE name1. SELECT SINGLE name1 INTO lv_name1 FROM KNA1 WHERE KUNNR = '1234567890'.

Instant RANGE - just add water

images/thumbnail.jpg - Thumbnail
I’m going to teach you a magic formula for creating a RANGE that is almost as easy as just adding water. Imagine that you want to create a RANGE from a database selection to then use it in another SELECT. Obviously you can do it like this: DATA: lt_kunnr TYPE STANDARD TABLE OF kunnr, lr_kunnr TYPE RANGE OF kunnr, wa_kunnr LIKE LINE OF lr_kunnr. FIELD-SYMBOLS: <kunnr> LIKE LINE OF lt_kunnr. SELECT kunnr INTO TABLE lt_kunnr FROM kna1.

LOOP ASSIGNING instead of LOOP INTO

images/thumbnail.jpg - Thumbnail
In the beginning there was INTO. Actually, in the beginning it was not even INTO.

Global macros

images/thumbnail.jpg - Thumbnail
In a previous article we talked about macros, a relatively obscure and little used feature that can be both useful as well as create a huge mess. But these aren’t the only ABAP macros. There are others that are even more obscure and with even greater potential to mix up a system: the global macros. I don’t know if I should tell you this, as it’s so strange… But, I don’t think it’s a good idea to hide it… Therefore, I’ll tell all.

<!--:pt-->Import/Export = Contrabando<!--:-->

images/thumbnail.jpg - Thumbnail
O Java, uma linguagem de programação bem pensada, ajuda o programador a organizar o seu código obrigando-o a desenvolvê-lo de forma estruturada. A sua própria filosofia potencia o pensamento estruturado e promove coerência e arrumação. Já o ABAP&hellip; promove o caos. Está cheio de caminhos perniciosos que levam direitinho a um inferno confuso e labiríntico. E geralmente são as coisas aparentemente mais convenientes que se revelam as mais perigosas. Uma das conveniências piores é a parelha IMPORT e EXPORT.

<!--:pt-->Macros - Velocidade de ponta<!--:-->


Normalmente quando há um pedaço de código que pretendemos reutilizar várias vezes, transformamo-lo numa sub-rotina que pode depois ser invocada repetidamente. Embora a SAP não saiba estruturar o seu próprio código, ainda assim, o ABAP, coitadinho, permite-o. E até disponibiliza várias alternativas para modularizar o código. Eu conto quatro alternativas que listo aqui, da mais rígida para a mais flácida: METHOD, FUNCTION, FORM, DEFINE. Se os 3 primeiros são já familiar de todos, o último - DEFINE - quase ninguém usa. O DEFINE permite definir macros em ABAP. E o que são macros? São sub-rotinas aparentes. Aparentes porquê?

<!--:pt-->Evitar mensagens dinâmicas<!--:-->


Qual é, digam lá, a melhor coisinha que o ABAP tem? É, digo eu, poder fazer where used em cima de tudo o que mexe. E no entanto, esta maravilhosa funcionalidade só funciona maravilhosamente quando as coisas não são invocadas dinamicamente. Eu uso o where used amiúde para descobrir onde uma determinada mensagem está a ser usada. Ora não é nada incomum encontrar chamadas dinâmicas a mensagens, principalmente em casos onde as mensagens não são enviadas directamente para o utilizador mas sim, por exemplo, para o Application Log.

<!--:pt-->READ TABLE blablabla TRANSPORTING NO FIELDS<!--:-->


Por vezes ao fazer READ TABLE a uma tabela interna queremos apenas verificar se um determinado registo existe, e não nos preocupamos com os dados retornados. Algo tipo: READ TABLE lt_kna1 INTO wa_kna1 WITH KEY kunnr = l_kunnr. CHECK SY-SUBRC = 0. Ora já que a estrutura WA_KNA1 não vai ser necessária de qualquer forma, mais vale não a usar, usando antes a opção TRANSPORTING NO FIELDS: READ TABLE lt_kna1 TRANSPORTING NO FIELDS WITH KEY kunnr = l_kunnr.