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

Есть логическая еденица - том. Он состоит из 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 таблицы. Хотя анализ всех был бы предпочтительней.

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

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

Евгений.

Специфика проекта такова, что нет в нем понятия структура БД, о котором Вы говорите.
Точнее есть, но она очень и очень динамическая, постоянно меняется. Долго писать для чего это нужно, но проект очень специфический.

Вопрос собственно остается....

Если можно, то отвечать по существу, пожалуйста, воду лить не нужно...
Мне не нравится Винда, это же не значит, что я на вопросы по обходу её глюков отвечаю, что пусть МС её переделывает.. :(