ORA-24816: расширенные non длинные данные по связи поставленные после фактического длиннего или столбца LOB

Я получаю следующее исключение при обновлении таблицы в спящем режиме

ORA-24816: расширенные non длинные данные по связи поставленные после фактического длиннего или столбца LOB

Я также извлек sql-запрос, он выглядит как

Update table_name set columnName (LOB)=value, colmun2 (String with 4000)=value where id=?;

объект класса

class Test{

    @Lob
    private String errorText;

    @Column(length = 4000)
    private String text;
}

пожалуйста, помогите мне, что не так в этом

спасибо Рави Кумар!--3-->

6
hibernate java oracle11g orm

6 ответов

под управлением oerr ora 24816 чтобы получить подробную информацию об ошибках:

$ oerr ora 24816
24816, ... "Expanded non LONG bind data supplied after actual LONG or LOB column"
// *Cause:  A Bind value of length potentially > 4000 bytes follows binding for
//          LOB or LONG.
// *Action: Re-order the binds so that the LONG bind or LOB binds are all
//          at the end of the bind list.

таким образом, другое решение, которое использует только 1 запрос, будет перемещать ваши LOB/LONG привязки после всех ваших не-LOB/LONG Привязок. Это может быть или не быть возможным с Hibernate. Возможно, что-то вроде:

update T set column2 (String with 4000)=:1, columnName (LOB)=:3 where id=:2;

это ограничение DML, по-видимому, было вокруг, по крайней мере, Oracle 8и.

ссылки:

5

Я нашел проблему. 1. Когда hibernate обновляет данные в БД и сущность имеет столбец 4000 символов и столбец типа lob, то hibernate бросает это исключение

Я решил эту проблему, написав две очереди обновления 1. Сначала я сохранил сущность с помощью Update() 2. Написал еще один запрос обновления для обновления столбца lob

спасибо Рави!--1-->

3

Я также столкнулся с той же ошибкой в oracle db и foudn, что Hibernate ребята исправлены здесь

в моем случае мы уже использовали hiberante 4.3.7, но не упоминали, что поле Lob в Entity

Воспроизводить Действия

  1. имеют поля с типом данных varchar2 и типом данных clob.Убедитесь,что ваше имя столбца находится в этом алфавитном порядке clob_field,varchar_two_field1, varchar_two_field2.
  2. Обновить сейчас clob_field с
  3. это должно закончиться ошибкой ORA-24816: расширенные non длинные данные по связи поставленные после фактического длиннего или столбца LOB

решение

  1. убедитесь, что у вас есть hiberante 4.1.8,

  2. аннотировать поле clob / blob в соответствующем объекте как

    import javax.persistence.Lob;  
...
    @Lob
    @Column(name = "description")
    private String description;  
....

Если вы хотите см. разницу, после внесения вышеуказанных изменений включите debug для операторов sql, установив "true" на "hibernate.show_sql" в упорстве.XML.

0

я столкнулся с этой проблемой сегодня, пытаясь вставить данные в таблицу. Чтобы избежать этой ошибки, просто сохраните все поля, имеющие "бизнес" тип данных в конце инструкции Insert.

Table1 имеет 8 полей (Field1,Field2,.... Field8 и т. д..),

из которых

Field1 и Field2 имеют типы данных CLOB

а остальные-данные Varchar2 типы

. Тогда при вставке данных, убедитесь, что вы держите Field1 и Field2 значения в конце, как показано ниже. 

 INSERT INTO TABLE1 ( Field3,Field4,Field5,Field6,Field7,Field8,Field1,Field2)  
    Values ('a','b','c','d','e','f','htgybyvvbshbhabjh','cbsdbvsb')
0

поместите привязку LOB в конце. Посмотрим, решит ли это проблему..

0

Я понимаю, что этот поток довольно старый, но я думал, что поделюсь своим собственным опытом с тем же сообщением об ошибке здесь для дальнейшего использования.

у меня были точно такие же симптомы (т. е. ORA-24816) в течение нескольких дней. Я был немного сбоку от различных потоков, с которыми я столкнулся, предполагая, что это связано с порядком привязки параметров. В моем случае это не было проблемой. Кроме того, я пытался воспроизвести эту ошибку, это произошло только после развертывания приложения сервер, я не мог воспроизвести это через интеграционные тесты.

однако я взглянул на код, где я привязывал параметр, и нашел:

preparedStatement.setString(index, someStringValue);

Я заменил это:

preparedStatement.setClob(index, new StringReader(someStringValue));

это сделал трюк для меня.

эта нить из далекого 2009 было весьма полезно.

0