Hoje em dia quando quero criar uma SALV defino sempre a estrutura dos dados no DDIC já com os elementos de dados com as descrições desejadas em vez de os forçar no código.

O editor de ABAP tem sempre coisas novas para descobrir.

Quando faço CTRL-F para pesquisar texto a opção que costumo usar é a Continuar proc.

Toda a minha vida ABAPiana usei APPEND STRUCTURES para adicionar campos extra a tabelas standard.

Mas aprendi recentemente que afinal servem para mais duas coisas:

Sabes que há uns anos atrás fizeste um método qualquer cujo nome tinha a palavra MALMEQUER. Mas, e agora? Como é que o encontras?

Poderias usar a transacção SE24 para pesquisar uma a uma todas as classes alteradas por ti. Mas eras capaz de demorar algum tempo. Não faças isso.

Experimenta antes usar a transacção SE84:

Imagina que queres chamar um método mas não sabem quais os seus parâmetros. O que fazes?

Dantes tinhas de usar o pattern ou então abrir a classe numa janela ao lado para ver os parametros do método. Depois apareceu o auto-complete e tornou tudo mais simples.

Mas há ainda outra forma.

Quando quero procurar uma determinada palavra num programa ABAP normalmente uso a função de pesquisa carregando em CTRL-F. E depois vou carregando em NEXT para ir encontrando as várias ocorrências da palavra que procuro.

Mas há outra forma. E não é melhor nem pior. É simplesmente diferente: a pesquisa incremental.

Quando um método devolve um valor como RETURNING este é sempre passado por valor e não por referência. Muitas vezes faço métodos que devolvem tabelas internas, algumas bastante grandes. Mas sempre me preocupou a ideia de que, como está a ser devolvida por valor, o ABAP devolva uma cópia da tabela interna, algo que pode ter impacto na performance e na memória que o programa gasta.

Felizmente fiquei recentemente a saber que não é assim.

Quando tentas inserir um registo numa tabela que já tenha outro registo com a mesma chave primária o programa faz dump. O que em alguns casos é uma chatice porque, mesmo que te estejas nas tintas, te obriga a verificar antecipadamente se aqueles chaves já existem na tabela.

Mas o ABAP prevê esses casos e dá-te uma solução:

INSERT dbtab FROM TABLE itab [ACCEPTING DUPLICATE KEYS].

Não te preocupes que quando acrescentas o ACCEPTING DUPLICATE KEYS não violas a primeira lei da termodinâmica: os registos não são inseridos. A única diferença é que o programa não faz dump. O que pode dar jeito nos casos em que não estás preocupado com o que estás a inserir.

Às vezes as coisas estão mesmo debaixo do nosso nariz e não as vimos.

No meu cliente actual trabalho com um montes de sistemas diferentes. Quando altero a configuração num deles muitas vezes, por preguiça ou esquecimento, acabo por não o fazer nos restantes.

Mas há uma forma simples de copiar de uma só vez todas as configurações do ABAP Workbench de um sistema para outro.

Por defeito a comparação de versões é horrível. Mostra as duas versões numa única coluna, com as diferenças destacadas, o que resulta numa grande confusão. É a coisa menos práctica de sempre.

Mas não tem de ser assim.