не работают каскадные удаления

Есть главная таблица:

CREATE TABLE MAN ( NUM INTEGER NOT NULL, FAM VARCHAR(30), IMA VARCHAR(30), OTCH VARCHAR(30), .................................... ); ALTER TABLE MAN ADD CONSTRAINT PK_MAN PRIMARY KEY (NUM);

Есть подчиненная:

CREATE TABLE MAN_MOVE ( NUM INTEGER, ......................... ); ALTER TABLE MAN_MOVE ADD CONSTRAINT FK_MAN_MOVE_1 FOREIGN KEY (NUM) REFERENCES MAN (NUM) ON DELETE CASCADE ON UPDATE CASCADE;

При попытке удаления записи в главной табице говорит что есть соотв. запись в подчиненной и удалять не буду. Хотя я же указал что каскадные удаления и изменения. Почему так? Раньше вроде работало........

Привет, konstsch!
Ты пишешь:

konstsch

Почему так? Раньше вроде работало........

Версия сервера какая-то?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

1.5.2


Кстати после пересоздания работают (т.е. если сначала удалить связь, а потом заново создать).
Это почему так?

Привет, konstsch!
Ты пишешь:

konstsch

k> Кстати после пересоздания работают (т.е. если сначала удалить связь, а потом заново создать). k> Это почему так?

Скорее всего, у тебя индекс был неактивен вследствие каких-либо причин...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

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

Пересчет статистики не помогает. Бэкап\ресторе то же не помогает. И чего мне теперь все связи заново создавать? Это, блин, совсем не круто, таблиц-то около сотни.

konstsch

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

Да ты що? Путаешь божий дар с яишницей. Тоиссь, констрайнт с индексом. Индекс, используемый констрайнтом, правда, вот так, в лоб, деактивировать действительно нельзя. Но он может быть неактивным от рождения. И активировать его в лоб тоже не получится. Но при помощи зубила и какой-то матери (С) таки можно. Сделай-ка ты вот такой запросец:

Select RDB$INDEX_NAME, RDB$INDEX_INACTIVE
From RDB$INDICES

и где там увидишь что-либо акромя 0 и нулла, те неактивные и есть.

konstsch

Пересчет статистики не помогает. Бэкап\ресторе то же не помогает. И чего мне теперь все связи заново создавать? Это, блин, совсем не круто, таблиц-то около сотни.

Скорее всего рестор у тебя до конца не проходит, аварийно завершается до активации индесов. Надобно сказать gbak-у щоб докладывал подробно що делает и вдумчиво последить за тем, что он будет докладывать. А может когда-то один раз не прошёл, я не знаю как gbak поступит при b/r базы с неактивными системными индексами, ибо никогда до такого безобразия базу, чтоб бакапить с неактивными системными индексами, не доводил. Может и не станет их активировать, хотя имхо не должно быть такого, ODS создаётся, а не ресторится. Так что вероятнее всего в базе у тебя есть некоторая поломатость, которая не даёт рестору пройти до конца, вот её-то и надобно изловить, починить, а потом уже бакапить-ресторить. Системные индексы втупую хаком активизировать не проблема (как - оставляю в качестве домашнего задания), но болесть базы, причину, надо лечить, а не маскировать.

автор

Да ты що? Путаешь божий дар с яишницей. Тоиссь, констрайнт с индексом.

Да вообще-то я прекрасно понимаю что есть что. Просто выразился наверно не верно.

Дак вот неактивными являются только те индексы которые сам отключил. А все системные индексы активны, т.е.

Select RDB$INDEX_NAME, RDB$INDEX_INACTIVE From RDB$INDICES

выдает или нулл или 0

кстати после пересоздания констрайта 0 меняется на нулл.

gfix проблем не нашёл.

бэкап и рэстор всегда проходил без проблем, хотя что-то я может и упустил.

?????

konstsch

А все системные индексы активны, т.е. Select RDB$INDEX_NAME, RDB$INDEX_INACTIVE From RDB$INDICES выдает или нулл или 0

если gbak -r -v проходит без сообщений об ошибках, докладывает об активации всех индексов и в полученной базе имеет место быть такая фигня - тогда я не знаю.

Имею предположить варианты:

1. С базой работали серверами очень разных версий без b/r.
2. Каскадные свойства ключи имели не сразу, а получили впоследствии путём ковыряния ручками в системных таблицах. Эксперт, например, в числе других хаков предлагает и такой. Люди, не чтящие доку, а осваивающие возможности сервера через инструмент, смело пользуются таким хаками, не подозревая, что это хаки. А любой хак имеет такое свойство, что он работает с той версией сервера, на которой проверялся, но никто не гарантирует, что будет работать со следующей.
3. Какое-то ну очень хитрое повреждение базы не уровня страниц и не уровня записей. Где-нибудь в структуре индексов на системных таблицах, что ли.
4. Регрессионный баг именно в 1.5.2. Проверять влом, каскадами не пользуюсь из религиозных соображений, мож завтра кто пользуется проверит.

Имхо по-любому твоя база должна представлять интерес для разработчиков.

konstsch

кстати после пересоздания констрайта 0 меняется на нулл.

Эти хакеры, писавшие IB, позволяли себе накладные карманы, то есть не делать разницы внутри своего кода в сервере разницы между нуллом и 0. Будет ли это когда-нить изжито - не знаю.

Скопируй куда-нить базу (при остановленном сервере ессно), мож действительно заинтересуются разработчики и принесёт пользу, и выполни

Update rdb$indeces set RDB$INDEX_INACTIVE=1
where RDB$INDEX_NAME starting 'RDB$'

Commit

Update rdb$indeces set RDB$INDEX_INACTIVE=0
where RDB$INDEX_NAME starting 'RDB$'

Commit

По идее должно помочь. Если это болезнь, а не симптом. Если симптом - либо не поможет, либо проявится опять после b/r.

Этого пока не делал:

Update rdb$indeces set RDB$INDEX_INACTIVE=1
where RDB$INDEX_NAME starting 'RDB$'

Commit

Update rdb$indeces set RDB$INDEX_INACTIVE=0
where RDB$INDEX_NAME starting 'RDB$'

Commit

В пользу того что индексы активны говорит и то, что при поиске в этих таблицах эти индексы точно используются.

а можно я тут не буду писать, как можно деактивировать и активировать индексы на pk,fk и unique, а то я уже задолбался это повторять. Если кого то это интересует, то это написано в частности в хелпе IBAnalyst.

автору хочу задать риторический вопрос - тебе и правда update cascade надо?
(то что надо cascade delete - не вопрос).