(Rappel : L’ABAP est le langage dans lequel tout SAP R/3 est développé. On parle là d’unERP à beaucoup de millions d’euros de licence, avec une industrie entière qui gravite autour. Il montre parfois qu’il a trois décennies d’âge.) (Note de 2025 : deux autres décennies plus tard, ce qui suit est peut-être corrigé. Connaissant SAP je n’en mettrai pas ma main au feu.)

Ce code compile (sans rien faire mais ce n’est pas le problème) :

REPORT  ZCCO_TEST.
IF 1 2 .
ENDIF.

Ceci ne compile pas :

REPORT  ZCCO_TEST.
IF ( 1 * 5 ) 2 .
ENDIF.

Relational operator "*" is not supported, qu’il dit. On ne fait donc pas de calcul dans une condition. Je suis condamné à utiliser une variable de travail (une de plus).

Ceci non plus ne passe pas :

REPORT  ZCCO_TEST.
IF 12.
ENDIF.

Pourquoi ? Il manque des espaces autour du “. Un scandale, effectivement.

C’est pareil pour les parenthèses (IF ( 1 2 ) .), il faut les séparer de ce qu’elles contiennent par des espaces. Sauf dans le cas d’un ordre SQL comme SELECT… INTO (variable1, variable2) WHERE… où, là, les parenthèses doivent être collées au reste.

Les limites de ce genre sont pléthore en ABAP. Je hais ce langage. On peut faire son boulot avec, mais c’est comme taper sur un clavier avec des moufles.

Il y a aussi des incohérences un peu pénibles. Par exemple, deux syntaxes totalement différentes selon que l’on recherche une donnée dans une table réelle (de la base de données) ou interne (un bête tableau en mémoire, de même structure que la table réelle).

Le premier ressemble à ça (recherche d’un poste de commande sur sa clé primaire constituée de vbeln et posnr) :

SELECT … FROM vbap
WHERE vbeln = …
AND posnr = …

Par contre pour la table interne :

READ TABLE t_vbap …
WITH KEY vbeln =…
posnr = …

Vous avez remarqué : dans un cas il y a un AND entre les deux critères de recherche. Dans l’autre, non. Pourquoi ? Mystère. Petit détail, oui. Mais à la fin de la journée on en perd, des minutes à faire plaisir au compilateur.