Dit lijkt verband te houden met bug 19461687 en deze vorige vraag . Als u de geaggregeerde waarde van uw zoekopdracht dumpt in 11gR2 of 12cR1 ziet u:
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
In SQL*Plus en SQL Developer wordt de werkelijke waarde weergegeven als:
LISTAGG_OUTPUT
----------------------------------------
A R 4 0 0 1, A R 4 0 0 2
en u kunt de waarde niet kopiëren van SQL Developer. (In 12cR2 verschijnen de nullen niet langer in de dump, de waarde wordt weergegeven zonder de spatiëring en je kunt deze kopiëren, dus de bug lijkt te zijn verholpen.)
Die null-bytes lijken ervoor te zorgen dat Toad de waarde helemaal niet weergeeft, vermoedelijk omdat hij de eerste null-byte ziet en deze behandelt als een string-terminator (of toch iets in die richting).
SQL Fiddle lijkt hiermee om te gaan, maar db<>fiddle lijkt er ook een probleem mee te hebben en retourneert niets voor de hele viool als die query aanwezig is.
U kunt uw tabelkolom opnieuw definiëren als varchar2 in plaats van nvarchar2 , maar ik neem aan dat het dat gegevenstype is met een reden, dus dat is waarschijnlijk niet praktisch.
Je zou het dus in plaats daarvan als onderdeel van de query kunnen casten:
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
Of kijk of de patch voor bug 19461687 het probleem voor je oplost.