Проблема с добавлением записи в таблицу. Delphi 2009.

← →
Дмитрий Белькевич (2009-06-30 13:33) [0]

Таблица:

CREATE TABLE PROTOCOLS_OBJECTS ( OBJECT_NAME CHAR(100), OBJECT_UID INTEGER NOT NULL, USER_UID INTEGER, TREE_ID INTEGER DEFAULT 0 );

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

Код:

IBQuery1.Active := True; IBQuery1.Edit; IBQuery1.FieldByName("OBJECT_NAME").AsString := "test"; IBQuery1.FieldByName("OBJECT_UID").AsInteger := 10; IBQuery1.Post;

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

insert into PROTOCOLS_OBJECTS (OBJECT_NAME, OBJECT_UID, USER_UID, TREE_ID) values (:OBJECT_NAME, :OBJECT_UID, :USER_UID, :TREE_ID)

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

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

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

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

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

← →
Sergey13 © (2009-06-30 13:42) [1]

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

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

← →
Дмитрий Белькевич (2009-06-30 14:07) [2]

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

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

← →
PEAKTOP © (2009-06-30 14:48) [3]

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

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

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

← →
Дмитрий Белькевич (2009-06-30 15:00) [4]

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

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

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

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

← →
Дмитрий Белькевич (2009-06-30 15:22) [5]

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

← →
PEAKTOP © (2009-06-30 15:28) [6]

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

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

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

← →
Anatoly Podgoretsky © (2009-06-30 15:46) [7]

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

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

← →
Дмитрий Белькевич (2009-06-30 15:51) [8]

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

← →
Anatoly Podgoretsky © (2009-06-30 16:06) [9]

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

← →
Дмитрий Белькевич (2009-06-30 17:08) [10]

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

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

← →
Anatoly Podgoretsky © (2009-07-01 09:53) [11]

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

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

← →
Павел Калугин © (2009-07-02 09:04) [12]

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

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

← →
Вариант (2009-07-02 09:21) [13]

> Павел Калугин © (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]

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

Проблема с добавлением записи в таблицу. Delphi 2009. Найти похожие ветки