Ещё раз про переход с 2.0 на 2.1

[Tonal]

Выполняю перевод баз с 2.0 на 2.1
сервер 2.1.1.17910-0 SS
Запущен сервисом.
Предидуший 2.0.4.13130 SS
OS Win XP Home Ru + sp3

При выполнении
select * from rdb$fix_metadata('WIN1251');
Ошибочка:
RDB$TRIGGERS
                RDB$TRIGGER_SOURCE
                              CHECK_15
                                            <null>

Statement failed, SQLCODE = 100
attempted retrieval of more segments than exist
-action cancelled by trigger (1) to preserve data integrity
-Cannot update trigger used by a CHECK Constraint
-At procedure 'RDB$FIX_METADATA'

Открыл исходный вариант базы, оказалась, что CHECK_15, это триггер
созданный на основе ограничения CHK_LAND_RIGHTS_BUS_PARTS

Возникает ряд вопросов:
1) С какого перепуга скрипт вообще дёргает этот триггер?
2) Откуда там может быть ошибка - вроде букав русских нет и синтаксис
корректный.
3) Что делать дальше? :-)

Вот запись из RDB$TRIGGERS
INSERT INTO RDB$TRIGGERS (
    RDB$TRIGGER_NAME, RDB$RELATION_NAME, RDB$TRIGGER_SEQUENCE,
RDB$TRIGGER_TYPE, RDB$TRIGGER_SOURCE, RDB$TRIGGER_BLR, RDB$DESCRIPTION,
RDB$TRIGGER_INACTIVE, RDB$SYSTEM_FLAG, RDB$FLAGS
) VALUES (
    'CHECK_15', 'LAND_RIGHTS_BUS', 0, 1, NULL, NULL, NULL, 0, 3, 1
);

Ограничение создавалось в составе скрипта обновления базы (сервер 2.0.4):
create domain D_PARTS as INTEGER CHECK (value > 0);
alter table LAND_RIGHTS_BUS add PART_DIVIDEND D_PARTS;
alter table LAND_RIGHTS_BUS add PART_DIVISOR D_PARTS;
ALTER TABLE LAND_RIGHTS_BUS ADD CONSTRAINT CHK_LAND_RIGHTS_BUS_PARTS
check  (PART_DIVIDEND <= PART_DIVISOR);
for i, fld in enumerate(table.fields):
    alter table LAND_RIGHTS_BUS alter fld position i
comment on domain D_PARTS is '...';
comment on column LAND_RIGHTS_BUS.PART_DIVIDEND is '';
comment on column LAND_RIGHTS_BUS.PART_DIVISOR is '';
commit;

Да, забыл упомянуть, что 3 базы до этой сконвертировались успешно.
По идее, они отличаются только данными, а методанные я раньше
синхронизировал с помощью DBComparer-а, а потом перешел на обновление
скриптами.

И ещё.
Было бы неполхо, если бы rdb$fix_metadata сохраняла бы какие объекты
она уже успешно обработала...
Иначе оченна неудобно работать при появлении ошибок.

P.S. Это дубль сообщения отправленного вчера, но оно так и не появилось
в nntp...
--
Александр Замараев

[Dmitry Yemanov-2]

Tonal wrote:
>
> 1) С какого перепуга скрипт вообще дёргает этот триггер?

Недоработка в процедуре FIX_METADATA, похоже.

> 2) Откуда там может быть ошибка - вроде букав русских нет и синтаксис
> корректный.

Патамучта сервер не разрешает изменять системные триггеры.

> 3) Что делать дальше? :-)

Поправить код FIX_METADATA самому?


--
Дмитрий Еманов

[Tonal]

Dmitry Yemanov пишет:
>> 3) Что делать дальше? :-)
> Поправить код FIX_METADATA самому?
Пока времени нет. :-(
Могу выслать базу, если кому-то интересно.
--
Александр Замараев

[HotDog]

Dmitry Yemanov wrote:
>> 1) С какого перепуга скрипт вообще дёргает этот триггер?
>
> Недоработка в процедуре FIX_METADATA, похоже.
>
А может у него, как у меня, слетел с этого триггера флаг "системный" ?

[Tonal]

Konstantin R. Beliaev пишет:
>
> Dmitry Yemanov wrote:
>>> 1) С какого перепуга скрипт вообще дёргает этот триггер?
>> Недоработка в процедуре FIX_METADATA, похоже.
> А может у него, как у меня, слетел с этого триггера флаг "системный" ?
INSERT INTO RDB$TRIGGERS (
    RDB$TRIGGER_NAME, RDB$RELATION_NAME, RDB$TRIGGER_SEQUENCE,
RDB$TRIGGER_TYPE, RDB$TRIGGER_SOURCE, RDB$TRIGGER_BLR, RDB$DESCRIPTION,
RDB$TRIGGER_INACTIVE, RDB$SYSTEM_FLAG, RDB$FLAGS
) VALUES (
    'CHECK_15', 'LAND_RIGHTS_BUS', 0, 1, NULL, NULL, NULL, 0, 3, 1
);
Т.е. RDB$SYSTEM_FLAG = 3
В выполняемых запросах явно прописано:
coalesce(rdb$system_flag, 0) in (0, 3)

Я поискал, значение RDB$SYSTEM_FLAG = 3 вроде применяется именно для
триггеров созданных для ограничений:
http://www.firebirdsql.org/index.php?op=devel&sub=qa&id=testinfo&test=functional.qms/basic.qms/db.qms/db_30.qmt
RDB$SYSTEM_FLAG                        0 USER

RDB$SYSTEM_FLAG                        1 SYSTEM

RDB$SYSTEM_FLAG                        2 QLI
RDB$SYSTEM_FLAG                        3 CHECK_CONSTRAINT

RDB$SYSTEM_FLAG                        4 REFERENTIAL_CONSTRAINT


Т.е. вывод простой: если в базе присутствуют CHECK CONSTRAINT то
FIX_METADATA может обломаться на пустом месте.

А т.к. 3 базы у меня нормально перегнались, от чего это зависит - х.з.
--
Александр Замараев

[Dmitry Yemanov-2]

Tonal wrote:
>
> INSERT INTO RDB$TRIGGERS (
>    RDB$TRIGGER_NAME, RDB$RELATION_NAME, RDB$TRIGGER_SEQUENCE,
> RDB$TRIGGER_TYPE, RDB$TRIGGER_SOURCE, RDB$TRIGGER_BLR, RDB$DESCRIPTION,
> RDB$TRIGGER_INACTIVE, RDB$SYSTEM_FLAG, RDB$FLAGS
> ) VALUES (
>    'CHECK_15', 'LAND_RIGHTS_BUS', 0, 1, NULL, NULL, NULL, 0, 3, 1
> );

Кстати. А почему у тебя у данного триггера нет ни source, ни BLR? Это
явно аномальная ситуация.

> Т.е. вывод простой: если в базе присутствуют CHECK CONSTRAINT то
> FIX_METADATA может обломаться на пустом месте.

Ну, если твой странный случай считать прецедентом...


--
Дмитрий Еманов

[Tonal]

Dmitry Yemanov пишет:
>>    'CHECK_15', 'LAND_RIGHTS_BUS', 0, 1, NULL, NULL, NULL, 0, 3, 1
> Кстати. А почему у тебя у данного триггера нет ни source, ни BLR? Это
> явно аномальная ситуация.
Это IBExtert при копировании строки в INSERT так сработал.
Есть и source:
check  (PART_DIVIDEND <= PART_DIVISOR)
и blr:
blr_version5,
blr_begin,
    blr_if,
       blr_gtr,
          blr_field, 1, 13,
'P','A','R','T','_','D','I','V','I','D','E','N','D',
          blr_field, 1, 12, 'P','A','R','T','_','D','I','V','I','S','O','R',
       blr_abort, blr_gds_code, 16,
'c','h','e','c','k','_','c','o','n','s','t','r','a','i','n','t',
       blr_end,
    blr_end,
blr_eoc

>> Т.е. вывод простой: если в базе присутствуют CHECK CONSTRAINT то
>> FIX_METADATA может обломаться на пустом месте.
> Ну, если твой странный случай считать прецедентом...
А как определить уже прецедент или ещё никому не интересный глюк? :-)

Мне то это было не критично, база с тестовыми данными. Я данные заново
сгенерил.

Похоже вот в чём дело:
Я выполнял такую последовательность действий в одном коннекте:
input '../misc/upgrade/metadata/metadata_charset_create.sql';
select * from rdb$check_metadata;
select * from rdb$fix_metadata('WIN1251');
commit;

Если rdb$check_metadata пропустить, или сделать реконнект после неё, всё
проходит без ошибок.

Думаю стоит несколько хотя бы подчеркнуть в документации.
http://www.ibase.ru/firebird/21/metadata_charset.htm
После предложения:
Иначе, первый "плохой" объект является последним в списке перед
возникновением ошибки.
Добавить:
Внимание, т.к. процедура rdb$check_metadata изменяет метаданные, перед
их исправлением следует сделать реконнект!

И выделить красным. :-)
--
Александр Замараев