Добрый день, товарищи.
Подскажите, пожалуйста, по такому вопросу. Фрагментировал большую таблицу. Таблица настолько большая, что через alter table fragment init не получилось, поэтому создал рядом такую же, но с фрагментацией, перелил в нее данные и rename`ом поменял их местами. Проверил работоспособность приложения и дропнул старую таблицу. Все это производилось через отдельную сессию (ну кроме приложения), никак не связанную с пулом jdbc-сессий приложения. Но, когда я после дропа еще раз попытался проверить работоспособность приложения, получил странную ошибку - при prepareStatment вставки записи в третью таблицу, на которую однако старая таблица имела внешний ключ, получил следующее:

The specified table <имя дропнутой таблицы> is not in database. (code=-206): ISAM error: no record found. (code=-111).

Перезапуск сервера приложений помог, но я не могу понять, что именно произошло - реконнект к бд или сброс какого-то кеша jdbc-пула.
Вопрос - почему субд все еще пытается производить какие-то операции над несуществующим объектом? Или виновата не субд, а пул jdbc-соединений? Но как он мог узнать о переименовании таблицы?

Спасибо за столь объемный ответ. Версия субд 11.7, csdk не используется - просто jdbc драйвер и пул на сфере.
Я бы даже согласился, с багом rename`а, но проблема в том, что тогда получается бага не только у rename`а, а еще и у drop`а. Насколько я понимаю, любая ddl операция над таблицей должна инвалидировать все скомпилированные запросы, в которых эта таблица участвует.
У меня складывается ощущение, что проблема в том, что drop detail-таблицы не влияет на валидность плана запроса вставки записи в master, но при исполнении она (detail) все таки затрагивается. Видимо надо каким-то образом выкинуть таки эти скомпилированные запросы из памяти, например "пустым" ddl над master-таблицей, но что-то это все мне уже напонимает шаманство. Проще сервер перегрузить, чем все связи и зависимости вычислять. Вариант с повторным prepare тоже не очень удачный, т.к. пользователи все-таки получат по ошибке на каждую сессию пула.
А для чего перезагружать БД? Это уже совсем ни в какие рамки не лезет, чтобы после каждого rename/drop бд перегружать...