Господа здравствуйте.

Есть логическая еденица - том. Он состоит из 4-х таблиц.
1. Таблица STO - хранилище документов
2. Таблица VOL - полей тома, собственно то, что видит в гриде пользователь.
3. Таблица NDF - со служебной информацией о томе.
4. Таблица GEN - со списками генераторов тома.

Работа идет через ОДБС. Когда пользователь в приложении открывает
том, то считывается необходимая информация из служебных таблиц NDF,
GEN и создается Рекордсет на таблицу VOL, который и открывается. Пользователь
начинает работать.

Ситуация. Несколько пользователей открыли один и тот же том и работают с ним.
В это время один из них заканчивает эту работу и решает том удалить.
Как это реализовано? Идут обычные DROP TABLE для всех 4-х таблиц.
Но первой в данном списке стоит VOL таблица. Так как если ОДБС _НЕ_ выкинет исключение,
что невозможно удалить таблицу (потому что она занята), то это
с вероятностью в 99% будет означать, что удаление остальных трех таблиц пройдет
без проблем. Т.к. невозможность удаления тома связана почти всегда именно с открытым томом,
а значит с открытым рекордсетом на таблицу VOL.
Такой способ применяется ввиду невозможности отката операции удаления таблицы.

Все было бы хорошо, если бы не некоторая особенность в поведении отдельных СУБД, с
которыми идет работа. В частности, это ИБ 6 и Фокс 6. Они обрабатывают её некорректно.
Например:
- ИБ:
При попытке удаления таблицы VOL, которая щас занята выкидывается эксэпшэн, что
мол извини.. Но затем при попытке селекта из этой таблицы в данной сессии валятся ошибки, что
такая таблица не существует. Если перелогиниться, то все становится нормально. Мелочь, но
пользователям очень неприятно.
- Фокс:
В некоторых ситуациях при явно занятой таблице спокойно позволяет её удалить др. клиенту.
А некоторых выкидывает нужное сообщение Access denied.

Ввиду этих причин необходимо разработать единый механизм для ИБ6, Фокса, Оракла, СКЛ Сервера
(хотя последние 2 абсолютно правильно отрабатывают все эти ситуации и их в принципе можно искл. из списка),
который бы позволял идентефицировать занятость таблиц тома перед их уделанием не посредством
анализа успешной или неуспешной операции DROP TABLE, а как-то иначе. И в случае когда хоть
одна из таблиц занята, в целом, запрещать операцию удаления тома.

Я так думаю, что можно на все таблицы и не заморачиваться, а пытаться идентефицировать только статус
VOL таблицы. Хотя анализ всех был бы предпочтительней.

Есть у кого-нибудь идеи? мне что-то пока ничего более-менее надежного в голову не приходит.
Может уже кто-то сталкивался с такими вещами или на сей счет есть уже готовые паттерны?
Буду признателен за любые советы в каком направлении рыть.

Напомню, что вся работа ведется через ОДБС.

Евгений.