Cela semble être lié au bogue 19461687, et cette question précédente . Si vous videz la valeur agrégée de votre requête dans 11gR2 ou 12cR1, vous voyez :
LISTAGG_OUTPUT
--------------------------------------------------------------------------------------------------
Typ=1 Len=25 CharacterSet=AL32UTF8: 0,41,0,52,0,34,0,30,0,30,0,31,2c,0,41,0,52,0,34,0,30,0,30,0,32
Dans SQL*Plus et SQL Developer, la valeur réelle est affichée comme :
LISTAGG_OUTPUT
----------------------------------------
A R 4 0 0 1, A R 4 0 0 2
et vous ne pouvez pas copier la valeur de SQL Developer. (En 12cR2 les zéros n'apparaissent plus dans le dump, la valeur est affichée sans l'espacement, et vous pouvez la copier, donc le bug semble avoir été corrigé.)
Ces octets nuls semblent empêcher Toad d'afficher la valeur du tout, probablement parce qu'il voit le premier octet nul et le traite comme un terminateur de chaîne (ou quelque chose comme ça de toute façon).
SQL Fiddle semble faire face à cela, mais db<>fiddle semble également avoir un problème avec cela et ne renvoie rien pour l'ensemble du violon lorsque cette requête est présente.
Vous pouvez redéfinir votre colonne de table en tant que varchar2 au lieu de nvarchar2 , mais je suppose que c'est ce type de données pour une raison, donc ce n'est probablement pas pratique.
Vous pouvez donc le caster dans le cadre de la requête à la place :
SELECT LISTAGG(CAST(MOD_CODE AS VARCHAR2(12)),',')
WITHIN GROUP (ORDER BY MOD_CODE) LISTAGG_OUTPUT
FROM XOTEST_A
WHERE MOD_CODE IN ('AR4001','AR4002');
LISTAGG_OUTPUT
----------------------------------------
AR4001,AR4002
Ou voyez si le correctif pour le bogue 19461687 résout le problème pour vous.
