Salah satu nomor 'Epoch' numerik Anda tampaknya terlalu besar (atau terlalu kecil) untuk numtodsinterval() berfungsi untuk menangani. Nilai terbesar yang dapat Anda lewati karena jumlah detik adalah 2^31-1:
SQL> select numtodsinterval(power(2,31) - 1, 'SECOND') as interval from dual;
INTERVAL
--------------
24855 3:14:7.0
SQL> select numtodsinterval(power(2,31), 'SECOND') as interval from dual;
SQL Error: ORA-01873: the leading precision of the interval is too small
01873. 00000 - "the leading precision of the interval is too small"
*Cause: The leading precision of the interval is too small to store the
specified interval.
*Action: Increase the leading precision of the interval or specify an
interval with a smaller leading precision.
Sebagai zaman bahwa jumlah detik tertinggi yang diizinkan mewakili 2038-01-19 03:14:07. Ini masalah tahun 2038 , pada dasarnya.
Anda bisa sampai di sana dengan angka negatif juga:
SQL> select numtodsinterval(-2208988800, 'SECOND') as interval from dual;
SQL Error: ORA-01873: the leading precision of the interval is too small
Menggunakan -power(2, 31) membungkus ke nilai positif, tetapi kesalahan yang lebih rendah dari itu:
SQL> select numtodsinterval(power(2,31) - 1, 'SECOND') as interval from dual;
INTERVAL
--------------
24855 3:14:7.0
SQL> select numtodsinterval(-power(2,31), 'SECOND') as interval from dual;
INTERVAL
--------------
24855 3:14:8.0
SQL> select numtodsinterval(-power(2,31) - 1, 'SECOND') as interval from dual;
SQL Error: ORA-01873: the leading precision of the interval is too small
Anda membagi dengan 1000, jadi salah satu kolom Anda F ke K memiliki nilai yang melebihi 2147483647000. Itu seharusnya cukup mudah ditemukan, dan Anda mungkin ingin mempertimbangkan untuk menambahkan batasan centang ke kolom tersebut sehingga tidak dapat disetel juga tinggi - periksa apakah nilai kolom kurang dari atau sama dengan 1000 * (power(2, 31) - 1) . Dan lebih besar dari nol, atau lebih besar dari-1000 * (power(2, 31) juga.
Alasan tidak error ketika Anda memiliki filter seperti where Col1 = 123 adalah bahwa filter (predikat) Anda didorong ke atas ke kueri tampilan dan baris dengan nilai yang terlalu tinggi tidak dievaluasi. Mungkin Anda hanya memiliki satu nilai seperti itu, dan col1 nilainya tidak 123 dan col2 nilainya tidak 'xyz'. Jika Anda mengidentifikasi baris masalah dan memfilternya menggunakan col1 yang sebenarnya nilai itu masih akan error. Tanpa filter, evaluasi dilakukan untuk semua baris.
Angka negatif spesifik yang Anda miliki tampaknya merupakan angka ajaib:
SQL> select date '1970-01-01' - 2208988800/86400 from dual;
DATE'1970-01-01'-2208988800/86400
---------------------------------
1900-01-01 00:00:00
Jika Anda ingin mengecualikannya, Anda harus mengubah definisi tampilan untuk menambahkan filter, mis:
...
AND tab2.colh > 0
atau ubah ekspresi kolom untuk menanganinya, baik mengabaikannya dan membiarkannya nol, atau mungkin lebih berguna mengembalikan tanggal ajaib itu:
TO_CHAR(CASE WHEN tab2.colh = -2208988800000 THEN DATE'1900-01-01'
ELSE DATE'1970-01-01' + NUMTODSINTERVAL( tab2.colh / 1000,'SECOND')
END, 'YYYY/MM/DD HH24:MI:SS') AS Col13,
Anda juga dapat mengubah dari menggunakan interval menjadi menggunakan aritmatika tanggal:
TO_CHAR(DATE'1970-01-01' + ( tab2.colh / 86400000 ), 'YYYY/MM/DD HH24:MI:SS') AS Col13,
Anda harus mengubah definisi tampilan daripada kueri Anda, kecuali colh disertakan dalam daftar pilih (yang tampaknya tidak demikian), dan meskipun demikian, Anda hanya dapat mengecualikannya - dan itu mungkin masih tidak selalu menghindari kesalahan, bergantung pada cara pengoptimal menangani kueri.
