Bug in ODAC 9.7.27 with CHAR() column in Oracle 12c using AL32UTF8

[heidenbluth]

Please create a new table having a CHAR() column, such as

Code: Select all

CREATE TABLE TEST(
  ID NUMBER(9),
  CHAR_FLAG CHAR(1),
  primary key(ID))

Create a new Delphi application and open SELECT * FROM TEST using a TSmartQuery component.
Set SmartQuery.DMLRefresh := True;
At runtime, insert a new record and enter a correct value such as 'Y' into the CHAR column and post.

You will get an error as follows:

ORA-18299 value is too large for column(currently 4, maximum 1)

Do you have a fix for that problem?

[MaximG]

We have reproduced the issue according to your description, and we will investigate the causes. We will notify you about the results. As a temporary solution use the property UseUnicode :

Code: Select all

OraSession.Options.UseUnicode := True;

[sergiy.balter]

Здравствуйте, MaximG!

Обнаруженная ТС ошибка устойчиво воспроизводится во всех проектах нашей фирмы, использующих ODAC 9.7.28 в в Delphi XE. В используемых таблицах БД используется тип CHAR в CHAR-семантике, то есть

Code: Select all

ANTRAGSSTELLER_JN CHAR(1 CHAR)

Предложенный workaround

Code: Select all

OraSession.Options.UseUnicode := True;

не удалось использовать, поскольку следствием включения этой опции TOraQuery требует использования TWideStringField вместо TStringField
К сожалению, в десятке затронутых ошибкой проектах имеется в общей сложности порядка полутора тысяч TOraQuery, уже использующих TStringField.

В какие ориентировочные сроки планируется пофиксить ошибку?

Существует ли альтерантивное решение проблемы? Что такое

Code: Select all

TOraSession.Options.CharLength ?

Возникло интуитивное подозрение, что эта опция может иметь отношение к возможному workaroud. Однако описание в справке

Used to specify the size of a single character in bytes.

сложно назвать внятным. Помимо этого, во внутреннем представлении Oracle в кодировке AL32UTF8 ответ зависит от символа, например "U" представлен одним байтом, а "Ü" двумя байтами. По умолчанию занчение опции 0. Как поведет себя в этом случае ODAC, если указать 1 или 2 байта?

У нас вследствие данной проблемы срываются сроки выпуска релизов сразу для нескольких заказчиков. Потому с благодарностью приму любые подсказки и идеи.

С уважением
Sergiy Balter
Ukraine

[heidenbluth]

This serious bug has been reported more than 3 weeks ago.
Now you released version 9.7.28 and I was very disappointed this bug still exists.
How much additional time do you need to fix this issue?

[MaximG]

Вы абсолютно правы. В качестве временного решения Вы можете использовать свойство CharLength, присвоив ему значение 1. В настоящее время мы изменили поведение таким образом, чтобы значение CharLength определялось автоматически в зависимости от кодировки, которую использует пользователь. В случае использования AL32UTF8 для работы с клиентской кодировкой CL8MSWIN1251 свойство CharLength будет принимать значение 1. В настоящее время мы тестируем это исправление, поэтому оно не вошло в последний билд ODAC 9.7.28 . Мы можем выслать Вам ночную сборку ODAC с данным исправлением. Для этого сообщите, пожалуйста, номер Вашей лицензии через форму e-support.

[sergiy.balter]

Спасибо за ответ и за предложение.
Вариант с установленным в качестве workaround CharLength=1 уже несколько дней тестируется нашим QA на нескольких проектах, пока что положительно.

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

Спасибо
хороших выходных

[MaximG]

Спасибо за Вашу информацию. В случае обнаружения ошибок в ходе тестирования, сообщите нам об этом. Следующий билд ODAC будет включать исправление описанной выше ошибки. Вы можете следить за новостями ODAC на нашем сайте : https://www.devart.com/news