Таблица:




Добавляю запись с помощью TIBQuery + TIBUpdateSQL.

Код:




Код апдейтера:




IBX'ы показывают: "Unsupported feature".

Проблема проявляется в procedure TIBQuery.SetParams в строчке case Params[i].DataType of.

Один из параметров (OBJECT_NAME) имеет тип ftFixedWideChar, соответственно, не обрабатывается case'ом.

Вопросов, как обычно, два: кто виноват и что делать?

Еще некоторые уточнения. Под D7 всё работало. Добавлять в базу нужно именно связкой TIBQuery + TIBUpdateSQL. Если двугих вариантов не будет, буду переписывать TIBQuery. Надеюсь на свой глюк.

> [0] Дмитрий Белькевич   (30.06.09 13:33)

Ты все таки разберись - ты вставляешь запись или изменяешь ее?

>Ты все таки разберись - ты вставляешь запись или изменяешь ее?

Вставляю. Изменение edit на insert ничего не меняет.

> Вставляю. Изменение edit на insert ничего не меняет.

та шо ви говорите ! а какой в таком случае по-вашему запрос из компонента TIBUpdateSQL будет "дергаться" Insert или Update ?

-----------------------------------
По сути вопроса. Чарсет при создании базы данных какой ? часом не UTF8 ?
Бо шо-то мне этот ваш вопрос сильно напоминает последние два пункта из вот этого: http://ibase.ru/unicode_faq.html

>та шо ви говорите ! а какой в таком случае по-вашему запрос из компонента TIBUpdateSQL будет "дергаться" Insert или Update ?

Посмотрел - апдейт дёргается. Странно, что в d7 работает. Поменяю на insert. Очень давно изначальный код писался - видно ошибся.

Базу создавал IBExpertom. Чарсет устанавливал win1251. Смотрю Registration Info. Написано - win1251.

FAQ посмотрю, спасибо.

FAQ посмотрел. Увы, UTF8 не причастна к проблеме...

> FAQ посмотрел. Увы, UTF8 не причастна к проблеме...

То есть как ? А как же это ?

> Один из параметров (OBJECT_NAME) имеет тип ftFixedWideChar,
>  соответственно, не обрабатывается case'ом.

> PEAKTOP  (30.06.2009 15:28:06)  [6]

И что это является эквивалентом UTF8
Вообще у меня статья составила мрачное впечатление.

Хорошо. Но я UTF8 нигде не указывал. Сама база - win1251, как и поле OBJECT_NAME таблицы, как и чарсет соединения - win1251. Откуда такая кодировка может взяться?

Видимо из-за Юникодовости Д2009 и обычной кривизне "Борланда" при работе с параметрами.
ftFixedWideChar - это зеркальный тип nchar или как оно там в FB 2.1 называется. Это криво преобразованое
, кстати а почему char, а не varchar.
В Д7 у тебя было ftFixedChar
Если мое предположение верно, то бороться только так - ожидать выхода Д13+ или же изменить тип в базе, для начала на varchar, затем nvarchar или ее эквивалент. nvarchar должно помочь.

Проблема действительно в типе поля - char, временно поменял на varchar - тип поля  стал ftWideString. Попробую тип поля в базе постоянно поменять.

Всем спасибо, особенная благодарность Подгорецкому.

> Дмитрий Белькевич  (30.06.2009 17:08:10)  [10]

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

> [9] Anatoly Podgoretsky ©   (30.06.09 16:06)
> Меняй на nvarchar

А можно попросить разъяснить для чайика, в чем отличие varchar  от nvarchar?

> Павел Калугин ©   (02.07.09 09:04) [12]

В MS SQL
varchar -это символьные данные (строка) переменной длины один байт на символ

nvarchar -  это символьные данные (строка) переменной длины в Юникоде

У IB,FB и Оракла  нет типа nvarchar, а только varchar, в котором юникод или какая другая кодировка определяется настройками (но это возможно ошибочное утверждение, ибо я  работал с этими СУБД нерегулярно и давно. Во всяком случае в LangRef по IB 6 в типах данных nvarchar нет).

> Павел Калугин  (02.07.2009 9:04:12)  [12]

Юникод/Не Юникод

> Вариант  (02.07.2009 9:21:13)  [13]

Про Оракл - varchar2
Про ФБ - постоянная оговорка, "или что там аналогичное", но точного аналога nvarchar там нет, только пародия.

> но точного аналога nvarchar там нет, только пародия.

NVARCHAR(N) у нас нет вообще. И даже пародии.

NCHAR(N) - не более, чем ссылка на CHAR(N) (http://firebirdsql.su/doku.php?id=tipy_dannyx) для "любителей красивостей" DDL кода и портирования DDL из других серверов. Пришел из проекта Fyracle (Firebird с синтаксисом Oracle), когда-то еще давно, когда после слияния кода Firebird 1.0 и Yaffil в Firebird 1.5 были планы по объединению Firebird 2.0 и Fyracle в Vulcan (Firebird 3.0). Сейчас текущая версия Firebird 2.5 и этими планами и не пахнет. Будет Firebird 3.0, но без Fyracle.

> в котором юникод или какая другая кодировка определяется настройками

Не настройками, а указанием:
1) CHARACTER SET при создании базы
2) CHARACTER SET при создании домена (USER-DEFINED типа данных)
3) CHARACTER SET при создании столбца таблицы.

При создании столбца в таблице поиск для определения CHARACTER SET осущетвляется в обратном прядке.

> PEAKTOP  (02.07.2009 12:00:16)  [16]

Во, даже пародии нет.