Freddie26предполагаю которые знают что нужно для починки этой базы.
похоже, что не знают. Иначе бы у них база уже давно прекратила "повреждаться".

Freddie26Потому я и занимаюсь написанием утилиты по откату чужих транзакций.
ты никогда такую написать не сможешь. Отрубить пользователей - можно, разными способами. При этом, как тебе уже сказали, те транзакции сами станут rollback. Поэтому откатывать уже будет нечего.

Freddie26мне выше предложили ссылку, в которой предлагаются причины поломки баз (советую почитать прежде чем обвинять разработчиков)
вы сами-то эту статью читали? Похоже что нет, иначе не предлагали бы мне ее почитать. Потому что (сюрприз), это я эту статью написал.
Freddie26 то на момент backup/restore могут остаться активные транзакции.
на момент backup - могут, но это вас не должно волновать, а на момент restore - не могут, никак, в принципе.
Freddie26 Проблема в том что -gfix работает грубо, в результате я с большой вероятностью потеряю половину базы
проблема в том, что вы новичок, и постоянно пишете чушь, совершенно этого не стесняясь.
Freddie26Всемирная паутина говорит о грубости работы -gfix и о куче минусов.
где написано о "грубости его работы"? Да, он не чинит ряд повреждений, зато есть наш FBFirstAid, может, проще купить его, чем писать свою утилиту, которая будет заведомо хуже?

Источник питания не успевает включиться? Ну так купите UPS. Я так понимаю, что у вас "источник питания" это какой-то дизель-генератор.
Freddie26Сервер упал, что происходит с транзакциями пользователей, которые были подключены в этот момент к базе?
На сколько я понимаю это порождает ошибки в базе, таблицы становятся не читаемыми.
ух, ох... состояния этих транзакций останется в Active в Transaction Inventory Page, и при первом монопольном подключении к базе сервер их сам переведет в RolledBack. Это быстро и не больно, и не может приводить ни к каким повреждениям.
Ошибки в базе происходят, как уже сказали выше, или от незаконченной записи на диск, или от искажений записи. И это вызвано только ОС и железом.

Freddie26к сожалению конечные пользователи БД умудряются убить базу...
ты уточняй, как и где. Если база у них - да, конечно умудряются. Но в этом случае повреждения обычно совсем другие.
Я вообще, кстати, в первый раз слышу, чтобы человек при повреждениях базы беспокоился про какие-то там "активные транзакции", которые, как я уже написал, никакого интереса или боязни не представляют в силу архитектуры IB/FB.

давайте вернемся к исходному вопросу.

Freddie26Всемирная паутина говорит о грубости работы -gfix и о куче минусов. Я честно говоря только на словах знаю про -gfix, понимаю что там большой функционал, но не разу ее не запускал. Однако те кто из сотрудников запускал говорят: "совместно придуманное нами решение лучше". Работает примерно по тому же принципу, но результат лучше и быстрее получается.
Прошу ответить, хотя бы на часть

- о какой "грубости работы gfix и куче минусов" говорит всемирная паутина? Ссылки, мнения.
- в чем состоит "совместно придуманное нами решение"? Если не секрет. Если только речь не про мифическую "отмену транзакций".

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

kgb ussr,

да я представляю, что в таких местах происходит, но вот мне не очень ясно, что за выводы и на каком основании делают "старшие товарищи", которых мы тут, похоже, в глаза не видели.
Самые проблемные разработчики - это те, которые ни с кем не общаются, и никогда нигде не спрашивают. Вот Freddie26 - исключение, и это хорошо, но неясно, кто там рядом наводит тень на плетень.

Freddie26Под грубостью я подразумевал потерю информации.
сюрприз - но повреждение БД это всегда потеря какой то информации. Часто последних введенных данных, и тех, где повреждены сектора диска, и т.п.
И без gfix -mend могут быть повреждения как мастер-записей, так и деталей, и их все равно придется удалять. Ну или долго и нудно их восстанавливать, только "восстановить" такие записи можно только по памяти. Например, убилась запись клиента А, остались его заказы, и мы помним, что это клиент А, а не кто-то другой. А можем и не помнить.
Freddie26Решение состоит в том чтобы брать пустую базу идентичную поврежденной, удалять в ней PK, FK, UQ, отключать и удалять индексы, отключать триггеры, затем копировать битую базу в пустую
ну, IBPump есть для этого.
Freddie26а именно для FK у которых значение ON DELETE = CASCADE
в нормальных базах нет таких ФК. То есть, в здравом уме каскадно записи никто не удаляет.
Freddie26второй проблемой явилось обновление базы "на горячую".
не совсем понятно, что это значит.
Freddie26раньше они это делали при помощи -gfix, приходилось часами работать с базой, чтобы достичь хоть какого то восстановления
Freddie26ну да, мы поэтому и сделали FBFirstAid, но все равно тут гарантий что не будет удаленных ПК-ФК нет.
также восстанавливать БД дорого если обращаться к специалистам или покупать специальные программы для их восстановления, которые гарантировали бы 50% результат (наверно с предложенной вами программой не сталкивались или повреждения серьезные что такой низкий шанс на восстановление врать не буду не знаю)
с моей точки зрения все это чешуя. База может убиться целиком, а может повредиться совсем чуть. Для пользователя "восстановление БД" означает ее 100% восстановление, чего практически никогда не бывает. В вашем случае "50% результат" тоже не гарантирует работоспособности БД с приложением.
Исходя из примера выше, при повреждении записи с клиентом А, программа никогда не увидит заказы, оставшиеся от этого клиента, просто потому что разработчику и в голову не может прийти такая ситуация (и это нормально).
Ну и экономить деньги клиентов не надо. Они должны платить за свою дурость, если не делают резервные копии (и если разработчик позаботился предупредить об этом клиента). Повреждения бывают разные, как я уже сказал.
Как вы думаете, бывают у нас базы, которые вообще невозможно восстановить, и нет никаких бэкапов?

В целом, конечно, идея может имеет какой-то смысл, ведь у разработчика БД всегда есть "образец базы". Впрочем, посмотрите на наш Extractor.
http://ib-aid.com/download/IBFirstAIDDiagnostician.exe
описание тут
http://ib-aid.com/articles/item153

Гаджимурадов РустамЭто как раз то, о чём я говорил в прошлый раз - нечто, в лучшем случае, спорное выдаётся как
абсолютная истина. А когда ему говоришь, что он ахинею несёт - обижаться и возмущаться начинает.
ну почему же спорное? "в нормальных базах записи не удаляют" (с) местное. И вроде здесь же согласились, что каскадное удаление - зло. Я не отрицаю, что его где-то можно использовать, но это составляет единицы процента от всех ФК базы данных.
А вы мне начинаете, что "каскадное удаление можно использовать". Да все можно использовать, кто ж спорит...