Wydaje się, że jest to związane z błędem 19461687 i poprzednim pytaniem . Jeśli zrzucisz zagregowaną wartość z zapytania w 11gR2 lub 12cR1, zobaczysz:
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
W SQL*Plus i SQL Developer rzeczywista wartość jest wyświetlana jako:
LISTAGG_OUTPUT
----------------------------------------
A R 4 0 0 1, A R 4 0 0 2
i nie można skopiować wartości z SQL Developer. (W 12cR2 zera nie pojawiają się już w zrzucie, wartość jest wyświetlana bez odstępów i można ją skopiować, więc wydaje się, że błąd został naprawiony.)
Wydaje się, że te bajty null powodują, że Ropuch w ogóle nie wyświetla wartości, prawdopodobnie dlatego, że widzi pierwszy bajt null i traktuje go jako terminator łańcucha (lub coś w tym stylu).
SQL Fiddle wydaje się sobie z tym radzić, ale db<>fiddle również wydaje się mieć z tym problem i nie zwraca niczego dla całych skrzypiec, gdy to zapytanie jest obecne.
Możesz przedefiniować kolumnę tabeli jako varchar2 zamiast nvarchar2 , ale zakładam, że jest to ten typ danych z jakiegoś powodu, więc prawdopodobnie nie jest to praktyczne.
Możesz więc przesłać go jako część zapytania:
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
Lub sprawdź, czy łatka błędu 19461687 rozwiąże problem za Ciebie.
