Как отследить и сбросить все подключения к виду?

[Aleksandr.]

FB 2.0.1.
Юзверям поставляется программа из двух частей - клиент и сервер. Сервер получает и отправляет информацию от сервера нашей фирмы, клиент работает с просмотром и редактированием. Просмотр, в основном, осуществляется через виды.

Когда на серверную часть программы приходит команда дропнуть вид ввиду удаления и создания заново какой-либо из соединяемых в нем таблиц, он через POST_EVENT сообщает всем подключенным клиентам о необходимости отключиться от этого Вида, после чего пытается дропнуть его снова. Но ввиду проблемы с событиями у FB (иногда они не ловятся "клиентом") клиент может не получить уведомления о необходимости отключения, и начинаются неприятности. Для сервера все попытки выполнить запрос типа DROP VIEW заканчиваются ошибкой, что, мол, вид используется, а клиент его не закрывает, пока юзверю на том клиенте не придет в голову блажь закрыть окошко...

Возникает вопрос: можно как-то отследить и принудительно отключить все транзакции, использующие заданный вид?

[kdv]

никак. собственно, и создавать/удалять метаданные на ходу - тоже не дело.

[Slavik]

У меня как-то была аналогичная задача. Решил следующим образом.
Добавил в базу "служебную" табличку, в которой прописал, из каких реальных вьюшек должны читать клиенты. Служба обновления, при необходимости замены вьюшки, создаёт рядышком новую с индеском, напр., VIEW01. Создание новых уникальных объектов в FB ни к каким конфликтам не приводило. После успешного создания новых вьюшек обновлялась "служебная" табличка. Далее служба пытаеться удалить все старые вьюшки с игнорированием любых конфликтов: если нарвётся - не страшно, в следующий раз попробует ещё раз.
Естественно, клиент при открытии формы должен считывать из "служебной" таблички имя нужной вьюшки и подставлять в запрос.

Аналогично можно и с таблицами.

[WildSery]

Это всё не по-файрбердовски как-то.
Метаданные - есть метаданные. Фиксированные и неизменяемые.
Способов динамически формировать запросы - море.
Вплоть до того, чтобы запрос хранить в BLOBe специальной таблицы динамических запросов.
Хранимые процедуры + Execute Block + динамические запросы достаточны имхо.