As classes SALV são mais versáteis e sofisticadas do que os antigos módulos de função. Portanto, para ALVs novas, usa sempre a SALV. Excepção feita para ALVs que precisem de editar os dados pois nesse caso as SALV ainda são muito pouco capazes. https://scn.sap.com/docs/DOC-10365 https://scn.sap.com/docs/DOC-10366

Temos duas variáveis: DATA palavra1 TYPE string. DATA palavra2 TYPE string. DATA: frase TYPE string. palavra1 = ‘isto’. palavra2 = ‘aquilo’. E queremos concatená-las metendo entre elas a palavra ‘mais’ e, claro, separando-as por espaços.

Na mitologia grega a forma de comunicação mais frequentemente utilizada pelos deuses para comunicar com os mortais era o estupro. Estupravam por dá cá aquela palha. O mais parecido que temos com estupro no ABAP é o comando SUBMIT, que é também a forma mais comum de comunicação entre dois programas.

O editor de ABAP tem coisas que não lembram ao diabo. Até dá para escrever ao mesmo tempo em várias linhas.

Não está. Mas eles - os senhores que fazem e refazem o ABAP propriamente dito - vão tentando remediar a situação. Olha por exemplo esta nova funcionalidade.

Sabias que podes fazer LOOP de uma tabela interna com uma estrutura A para dentro de uma estrutura do tipo B?

Uma vez que as operações de dados estão muito mais optimizadas no servidor de base de dados do que no ABAP, é sempre preferível o primeiro. FOR ALL ENTRIES só deve ser usado quando não se conseguir fazer INNER JOIN (como com a BSEG por exemplo). Quando possível, usar RANGES artificiais é preferível a usar FOR ALL ENTRIES mas é preciso cuidado para não ultrapassar o limite do parser de SQL.

É comum encontrar o comando CHECK em user-exits. A trágica consequência disto é que, se o CHECK falha, nenhum do código que se segue a esse CHECK será alcançado. Como é comum (ainda que má prática) que num user-exit sejam tratados vários assuntos diferentes, um CHECK relacionado com um assunto pode inibir o acesso aos assuntos seguintes. Uma forma simples de evitar este risco é, como sempre aconselho, encapsular o código em rotinas.

Para indentares um bloco de linhas só com teclas faz assim:

Ao declarar uma estrutura que vai receber dados de uma tabela interna, em vez de a declarares directamente com o seu tipo, usa LIKE LINE OF. Assim, não só ficará claro que estão relacionadas como, se mudares o tipo da tabela interna, não terás de te preocupar em mudar também o tipo da estrutura.

Todos os dias aprendo novos comandos para introduzir no campo da transacção. Hoje aprendi uns que resolvem um problema que, ainda que raramente, já me aconteceu no passado. Vê lá se isto já te aconteceu: fazes uma alteração a um texto de um elemento usado numa tabela que editas a partir da SM30. Mas quando vais à SM30 o texto antigo continua lá. Activas vezes sem conta, sais e entras da transacção e nada.

Não faças COMMIT dentro de user-exits. E garante também que rotinas que possas chamar a partir de user-exits não o fazem.

Claro que já conheces o botão “Modelo” no editor de ABAP que permite introduzir automaticamente modelos para módulos de função, chamadas a métodos e outros. Mas o novo editor agora cresceu um bocadinho (já só está 10 anos atrasado em relação ao Eclipse em vez de 20) e já permite completar automaticamente alguns comandos através do atalho CTRL-SPACE.

Se um desenvolvimento necessitar de mais do que uma tabela de parametrização, considera agrupar as tuas vistas de manutenção num “cluster”. Assim será mais intuitivo mantê-las. Isto fará ainda mais sentido se umas dependerem de outras uma vez que na definição do “cluster” estas relações podem ser explicitadas. Exemplo: Como encavalitar tabelas

Tenta seleccionar sempre apenas os campos que vais realmente usar. Escolher todos é um desperdício de recursos. Excepção feita ao uso das FM *_SINGLE_READ que, embora leiam os campos todos, fazem cache dos dados, sendo por isso ainda assim mais rápidos de usar quando usados múltiplas vezes com a mesma chave. Se queres apenas verificar que um registo existe, selecciona apenas um campo, e se possível aquele que estás a usar como critério, evitando assim declarares uma variável extra.