Ошибка сервера FB2.0 при изменении типа столбца на UTF8

[fb.bird]

Всем привет. Всё-таки я пробился на этот форум несмотря на то что Google Mail пометил как спам письмо от kdv с активацией

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

1) Создаем таблицу RL_DISCIPLINES с двумя полями:
CREATE TABLE RL_DISCIPLINES (
ID INTEGER NOT NULL,
DISCNAME_RUS CHAR(254) CHARACTER SET WIN1251 COLLATE WIN1251
);

вводим строк 20 данных в эту таблицу на русском языке.
2)
Потом вдруг решаем изменить тип данных столбца DISCNAME_RUS на CHAR(254) CHARACTER SET UTF8 COLLATE UNICODE
3) изменяем имя столбца на DISCNAME.

После этого БД работает нормально, но проблема заключается в следующих моментах:
1) Не проходит успешно Restore DataBase после его Backup при помощи IBExpert
2) Не проходит успешно Restore DataBase после его Backup при помощи утилиты gback.exe
3) После создания в этой таблице дополнительного поля
discname_utf8 типа CHARACTER SET UTF8 COLLATE UNICODE
при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id

размер базы данных растет бесконечно, сервер уходит в бесконечный цикл, хотя и работает стабильно, не падает. Размер файла БД растет и растет и конца-края этому не видно.

сервер FireBird 2.0.0 установлен в архитектуре SuperServer под операционной системой Windows 2000 Professinal SP4 RUS.

Цель: Необходимо цикл backup/restore database выполнить успешно.

Ниже приведен отрывок протокола сообщений утилиты gback при restore DB:

gbak: activating and creating deferred index FK_RL_INFRESOURCES_RESTYPE_ID
gbak: activating and creating deferred index FK_RL_DISCBYCHAIR_DISCID
gbak:cannot commit index FK_RL_DISCBYCHAIR_DISCID
gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"
gbak: ERROR: Foreign key reference target does not exist
gbak: committing metadata
gbak:finishing, closing, and going home
gbak:Database is not online due to failure to activate one or more indices.
gbak:Run gfix -online to bring database online without active indices.

когда же операцию восстановления БД из баккапа делаю в IBExpert, он сообщает:

bak:restoring data for table RL_DISCBYCHAIR
gbak: 27 records restored
IBE: Invalid token.
Malformed string.
gds_$send failed.

Вот: Malformed string !

Кстати, образ БД крохотный. 1 Mb.
Если что могу выслать. Никаких коммерческих секретов у меня нет

[kdv]

В горячо любимом мной сервере FireBird 2.0.0

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

потом вдруг решаем изменить тип данных столбца

каким именно образом?

) Не проходит успешно Restore DataBase после его Backup при помощи IBExpert

про IBExpert опустим, но ситуации с невосстановимым бэкапом указаны здесь:
www.ibase.ru/devinfo/db_repair.htm

при изменении типа столбца ПРЕДВАРИТЕЛЬНО надо проверить будут-ли читаться в этом типе УЖЕ ИМЕЮЩИЕСЯ ДАННЫЕ. Потому что изменение типа столбца данные не модифицирует.

размер базы данных растет бесконечно, сервер уходит в бесконечный цикл

Вы, очевидно, совсем новичок, если не знаете такой элементарной вещи. Да, insert into select может зациклиться.

gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"

у Вас что, строковый столбец в 254 символа - первичный ключ???

[WildSery]

при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id

размер базы данных растет бесконечно

А ты чего ожидал? От инсерта-то без ограничения видимости...
Тут как раз ничего удивительного, и багом не является. Читай в FAQ.

[kdv]

Если что могу выслать. Никаких коммерческих секретов у меня нет

выслать на предмет чего? Кстати, размер БД в 1мб также говорит о том, что похоже размер страницы БД выбран неверно.

[fb.bird]

нет такой версии. она уже давно снята с download.

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

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

Где вопросы? Я пытаюсь сказать что существует ошибка.

потом вдруг решаем изменить тип данных столбца

каким именно образом?

В IBExpert в выпадающем контекстном меню есть кнопка Edit Field - там можно изменить тип столбца, а как Вы изменяете тип столбца ? Другим способом ? не доверяете IBExpert ?

про IBExpert опустим, но ситуации с невосстановимым бэкапом указаны здесь:
www.ibase.ru/devinfo/db_repair.htm

В статье рассматриваются случаи когда БД повреждена, а у меня же она не повреждена

при изменении типа столбца ПРЕДВАРИТЕЛЬНО надо проверить будут-ли читаться в этом типе УЖЕ ИМЕЮЩИЕСЯ ДАННЫЕ. Потому что изменение типа столбца данные не модифицирует.

Данные прекрасно читаются.

размер базы данных растет бесконечно, сервер уходит в бесконечный цикл

gbak: ERROR:violation of FOREIGN KEY constraint "PK_RL_DISCIPLINES" on table "RL_DISCIPLINES"

у Вас что, строковый столбец в 254 символа - первичный ключ???

Нет. Данная таблица RL_DISCIPLINES - её идишник (ID) является внешним ключом (Foreign Key) для столбца DISCID таблицы RL_DISCBYCHAIR.

[fb.bird]

выслать на предмет чего?

Выслать на предмет доказательства существования проблемы.

Кстати, размер БД в 1мб также говорит о том, что похоже размер страницы БД выбран неверно.

Т.е. как это неверно ? Теперь уже и размер страницы БД нельзя выставлять равным 4096 байт ?
Нельзя выбирать произвольно размер страницы БД ?
Если быть точным размер файла 1 011 712 байт.

[fb.bird]

Вы, очевидно, совсем новичок, если не знаете такой элементарной вещи. Да, insert into select может зациклиться.

В честь чего то, что insert into select может зациклиться, это нормально ?

Я так понимаю сначала должна быть произведена выборка (select) данных из таблицы, а только затем начата вставка (insert).
Вы хотите сказать что вставка начинается тогда уже когда считаны первые строки данных чтение не произведено до конца а уже начата вставка ? И типа select будет читать данные произведенные вставкой записей из таблицы ?
Я Вас не понимаю.

[fb.bird]

при запуске запроса
insert into rl_disciplines(discname_utf8)
select
discname
from rl_disciplines
order by id

размер базы данных растет бесконечно

А ты чего ожидал? От инсерта-то без ограничения видимости...
Тут как раз ничего удивительного, и багом не является. Читай в FAQ.

Где insert без ограничения видимости ? Я конечно понимаю что запрос сделан неправильно, что такой запрос бесполезен, но мне непонятно то что сервер может уйти в бесконечный цикл.
Вообще основная проблема в том, восстановление БД не проходит успешно.

[fb.bird]

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

Я вижу Вы не верите в любовь с первого раза. ((c) Задорнов)

[kdv]

Выслать на предмет доказательства существования проблемы.

какой именно проблемы. если с рестором - добро пожаловать в платный ремонт. Ссылку на документ, в котором объясняются похожие причины, дал.

Т.е. как это неверно ? Теперь уже и размер страницы БД нельзя выставлять равным 4096 байт ?

можно. 4к это нормально.

Нельзя выбирать произвольно размер страницы БД ?

можно, но 1 и 2 к лучше не выбирать.

Если быть точным размер файла 1 011 712 байт.

шут с ним.
если бы проблема касалась конкретного бага... Пока что не вижу ответов на вопрос по поводу как Вы модифицировали тип столбца, и почему не проверили столбец на конвертируемость данных в новый тип.

Итак. Резюмирую:

1. insert into select from - да, зацикливание, таково поведение InterBase/Firebird всех версий.

www.ibase.ru/ibfaq.htm#insinf

2. да, при изменении типа столбца данные столбца не конвертируются автоматически. Это стандартное поведение сервера. К чему может привести, описано тут:

http://www.ibase.ru/devinfo/db_repair.htm#col_alter

3

Цель: Необходимо цикл backup/restore database выполнить успешно.

исправляйте проблему в исходных данных. В Вашем случае, мне кажется, проще не мучиться а пересоздать БД заново с нужными типами столбцов.

[kdv]

и дополнительно, еще раз обращаю внимание на 2.0.0:
www.ibase.ru/devinfo/allversions.htm

[dimitr]

В IBExpert в выпадающем контекстном меню есть кнопка Edit Field - там можно изменить тип столбца, а как Вы изменяете тип столбца ? Другим способом ? не доверяете IBExpert ?

я доверяю только оператору ALTER TABLE. За отсебятину IBExpert'а пусть несут ответственность его авторы.

[kdv]

В статье рассматриваются случаи когда БД повреждена, а у меня же она не повреждена

еще один невнимательный читатель. в части статьи, описывающей невосстановимый бэкап, как раз и написано про случаи, когда повреждена ЛОГИЧЕСКАЯ структура БД, а не физическая. Пусть даже с Вашей точки зрения БД не повреждена, но ведь ее рестор не проходит, а значит логическое повреждение ЕСТЬ. рестор может восстановить только логически целостные данные.

В общем, дальше неинтересно обсуждать, пока Вы не
1. установите FB 2.03
2. будете менять типы данных корректно, средствами сервера, а не абы как.

[fb.bird]

какой именно проблемы. если с рестором ...
Ссылку на документ, в котором объясняются похожие причины, дал.

Спасибо, почитал.

В Вашем случае, мне кажется, проще не мучиться а пересоздать БД заново с нужными типами столбцов.

Спасибо большое за помощь, я так и сделал. Помогло.