ऐसा लगता है कि यह बग 19461687, और इस पिछले प्रश्न से संबंधित है। . यदि आप अपनी क्वेरी से एकत्रित मान को 11gR2 या 12cR1 में डंप करते हैं, तो आप देखेंगे:
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
SQL*Plus और SQL Developer में वास्तविक मान इस प्रकार प्रदर्शित होता है:
LISTAGG_OUTPUT
----------------------------------------
A R 4 0 0 1, A R 4 0 0 2
और आप SQL डेवलपर से मान की प्रतिलिपि नहीं बना सकते। (12cR2 में शून्य अब डंप में दिखाई नहीं देते हैं, मान रिक्ति के बिना प्रदर्शित होता है, और आप इसे कॉपी कर सकते हैं, इसलिए लगता है कि बग को ठीक कर दिया गया है।)
ऐसा लगता है कि वे नल बाइट्स टॉड को मूल्य प्रदर्शित नहीं कर रहे हैं, संभवतः क्योंकि यह पहली नल बाइट देखता है और इसे एक स्ट्रिंग टर्मिनेटर (या वैसे भी उन पंक्तियों के साथ कुछ) के रूप में मानता है।
ऐसा लगता है कि SQL Fiddle इसका सामना कर रहा है, लेकिन db<>fiddle में भी इसके साथ कोई समस्या है, और जब वह क्वेरी मौजूद होती है तो पूरी फ़िडल के लिए कुछ भी वापस नहीं करती है।
आप अपने टेबल कॉलम को varchar2 . के रूप में फिर से परिभाषित कर सकते हैं nvarchar2 . के बजाय , लेकिन मुझे लगता है कि यह डेटा प्रकार किसी कारण से है, इसलिए शायद यह व्यावहारिक नहीं है।
तो आप इसे इसके बजाय क्वेरी के हिस्से के रूप में डाल सकते हैं:
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
या देखें कि 19461687 बग के लिए पैच आपके लिए समस्या का समाधान करता है या नहीं।
