Добрый вечер!

Есть ли какой способ узнать время последнего изменения метаданных?

Задача: Есть программка-клиент на Delphi и FibPlus. Fib+ используют локальный кэш метаданных. Проблемы появляются если в таблицу добавляется новое поле - тогда Fib+ это поле игнорируют при генерировании Insert и update SQL.
Сейчас кэш можно сбросить только вручную. Хочется это дело автоматизировать. Например через дату последней модификации структуры БД. (проверять при подключении и инвалидировать кэш, если дата поменялась). Вопрос как получить эту дату? Или может уважаемые форумчане могут подсказать альтернативный способ?

Уточняю, я пишу клиента. Контролировать кто, как и когда меняет метаданные вне моих возможностей.
Я для себя вижу 3 типа действий:
1) проинформировать о необходимости сбрасывать кэш после изменения метаданных
2) отключить кэширование метаданных на клиенте
3) инвалидировать кэш метаданных автоматически

Сейчас используется 1й пункт, но ко мне изредка всё же приходят баг-репорты вызванные несоответствием кэша и метаданных.

Если я вас верно понял, в Firebird такая инфа из коробки не доступна.

FB используется 2.5.

Пока подумываю о том, чтобы повесить свои триггеры на RDB$ процедуры:
RDB$FIELDS, RDB$PROCEDURE_PARAMETERS
и возможно на RDB$RELATIONS, RDB$RELATION_FIELDS

Чем это плохо?

Dimitry SibiryakovТем, что такие триггера работают непредсказуемо
Можно поподробнее?
Иногда срабатывают, а иногда нет?
Или вообще отключаются и перестают работать?
Или вообще могут мешать обновлению метаданных?

п.с. придумались варианты 4) обновлять "дату обновления метаданных" вручную. (сам юзер поменял, сам пусть и обновляет), ну заодно можно и триггер повесить (если триггер не сработает, то вручную пусть обновляют) 5) при подключении всегда принудительно запускать валидацию метаданных в отдельном потоке

Dimitry SibiryakovDimitry SibiryakovВыбирай вариант 2.
Мне вот интересно: ТСы просто никогда не слушают моих советов или целенаправленно
поступают наоборот?..

Дмитрий, совет вполне услышан. Именно на уровне совета, а не руководства к действию. И в этом большая разница.
У меня своя задача, за которую я несу ответственность. Для принятия решения мне не хватало знаний - здесь я эти знания получил (частично, пока ещё не хватает конкретики про непредсказуемость). Спасибо огромное! (виноват, - забыл поблагодарить).
В данном случае аргумент - "эти триггера слетают при ресторе" - для меня критичный - теперь я точно знаю почему триггера мне не подойдут. Без этого кусочка информации единственным формальным обоснованием для принятия решения было бы только "так ребята на форуме сказали". =)

Гаджимурадов Рустамdebose> не хватает конкретики про непредсказуемость

Не столько непредсказуемость, сколько недокументированность.
Недокументированная фича, работоспособность которой никто
не гарантировал, тем более в новых версиях.

Ну так хорошо бы её документировать. В конце-концов с точки зрения юзера (ака меня), системные таблицы - это тоже таблицы, а значит - "почему бы с ними не работать как с обычными таблицами?". Тем более что документация вроде бы этого явно не запрещает.

Dimitry SibiryakovMikeDDТогда получается что необходимость сброса кэша метаданных им известно

Осталось только выяснить: а зачем аффтар его вообще использует.

А это самый лучший вопрос. И единственный приходящий мне в голову ответ на него - because I can. Ну и микрооптимизации. Этот кэш существенно уменьшает количество запросов по метаданным к серверу. Включить его легко. Один только побочный эффект (из-за которого весь топик) - если кто-то (в реале специально кое-как обученный человек) добавил колонку в таблицу и забыл сбросить кэш у всех юзеров. Такое просходит не каждый день и даже не каждый месяц, но когда происходит - выясняется, что про кэш он забыл, не знал и т.п.

Dimitry SibiryakovdeboseЭтот кэш существенно уменьшает количество запросов по метаданным к серверу.

В правильно написанном приложении количество таких запросов равно нулю. Вряд ли кэш сможет
существенно его уменьшить.
У меня не сферическое в вакууме. У меня реальное legacy. С полноценным дизайнером форм (IDE) и на датасетах, где повсеместно используется select * from и генерированием Update/Insert/Delete запросов на лету. В общем, как есть так есть.