#oracle
#Oracle
Вопрос:
Я вызываю хранимую процедуру из своего Java-приложения с 4 входными параметрами и 6 выходными параметрами. Код работает нормально на рабочей машине, выдавая правильный вывод. Но когда я запускаю тот же код в другой системе, я получаю некоторую ошибку. Пожалуйста, смотрите трассировку журнала ниже:
**14:48:12,684 ERROR [STDERR] java.sql.SQLException: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at "RFDBTEMP.VEHICLE_TRACKING_2", line 3895
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at "RFDBTEMP.VEHICLE_TRACKING_2", line 4550
ORA-20000: WB_WEIGHT_CAL[no tolerance check for sec wt]V_MWTL_WEIGHT_INDEX :2/ORA-01843: not a valid month
ORA-06512: at "RFDBTEMP.VEHICLE_TRACKING_2", line 2250
ORA-01843: not a valid month
ORA-06512: at line 1
14:48:12,685 ERROR [STDERR] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:439)
14:48:12,686 ERROR [STDERR] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:395)
14:48:12,689 ERROR [STDERR] at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:802)
14:48:12,691 ERROR [STDERR] at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:436)
14:48:12,693 ERROR [STDERR] at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186)
14:48:12,695 ERROR [STDERR] at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:521)
14:48:12,697 ERROR [STDERR] at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:202)
14:48:12,701 ERROR [STDERR] at oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:1005)
14:48:12,703 ERROR [STDERR] at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1307)
14:48:12,705 ERROR [STDERR] at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3449)
14:48:12,708 ERROR [STDERR] at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3530)
14:48:12,709 ERROR [STDERR] at oracle.jdbc.driver.OracleCallableStatement.executeUpdate(OracleCallableStatement.java:4735)
14:48:12,711 ERROR [STDERR] at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper.
java:1350)**
Может ли быть вероятность того, что эта ошибка связана с настройками системной среды или какой-либо другой настройкой в системе?
Примечание: в хранимой процедуре нет параметра даты, но внутри процедуры используется «SYSTIMESTAMP». Я запускаю свое приложение на сервере JBoss 4.
Комментарии:
1. Мы не можем диагностировать внутренние компоненты пакета, которые мы не видим. (И нет, мы не хотим видеть тысячи строк кода!) Но похоже, что у вас есть неявное или явное преобразование строки в дату, которое может быть неудачным из-за данных или других настроек NLS; и, возможно, обработчик исключений, который не может обработать длинное сообщение. Вам нужно отладить это в вашем пакете или, по крайней мере, посмотреть номера строк, о которых сообщается.
2. Привет, Алекс! Настройки NLS те же, и мы передаем одни и те же данные. Кроме того, я просмотрел номера строк, указанные в журнале, но ничего там не нашел. Код одинаков для обеих систем, указывающих на одну и ту же базу данных.
3. Итак, что же происходит в строке 2250? Это выбор даты из таблицы или вставка даты в таблицу? Там какая-то манипуляция с датой, иначе эта ошибка не была бы вызвана. Может быть, вы можете добавить раздел кода вокруг этого к вопросу?
4. Тот же самый Java-код и хранимая процедура прекрасно работают в производственной системе. Ошибка возникает на разных компьютерах для одних и тех же сборок. Я просто хочу знать, может ли такая ошибка возникнуть из-за некоторых системных настроек или настроек среды. Или, может быть, из-за построенных войн и банок.
5. Ну, ответ «да». Возможно, настройки NLS или язык сервера (который влияет на NLS). В противном случае это похоже на проблему с данными — хотя, если они указывают на одну и ту же базу данных (и схему), это кажется маловероятным. Однако без кода или каких-либо дополнительных сведений об окружающей среде ваш вопрос слишком широк.