Как оказалось при подготовке(prepare) запроса в IB/FB...

> Вот это для меня новость - т.е. при каждой препарации запроса
> пересчитывается кол-во страниц!?

Для каждой участвующей таблицы сканируются ее pointer pages. По числу
занятых слотов на них определяется кол-во страниц данных. По этой цифре
оценивается число записей.

Модификация метаданных "по живому"

> Я отвечал по факту, а не по намерению. Т.е. если альтеруемый объект не
> заюзан на момент альтера, то это безопасно.

Создание и удаление таблиц во время интенсивных вставок в другие таблицы
часто приводит к повреждениям - в основном конфликтам между системными
страницами и страницами данных. Конечно, в основном на классике, но и на
супере тоже наблюдал не раз.

С уважением,
Алексей Ковязин

Из вопросов теста: "точность типа double precision"

> укажите точность типа double precision (максимальное число знаков)
> ответил 17, а в качестве правильного ответа указано 15
> зашел в IBE, проверил:
> select cast(CAST(1123 as DOUBLE PRECISION)/1233451 as varchar(100)) from
RDB$DATABASE
> 0.0009104536783382559
> 16 знаков-то, как ни крути :)

16-ый знак не гарантируется.
Т.е. он может быть показан не для всех чисел

--
Хорсун Влад

FB2 больше не допускает альтер/дроп процедур "in use"

> (Для FB1 все работает как часы.)

FB2 больше не допускает альтер/дроп процедур "in use". Но счетчик
использования держит каждый препарированный запрос, в котором используется
процедура, плюс каждая аналогичная транзакция.

--
Дмитрий Еманов

Кажется из epi

- двойная бухгалтерская запись - это замечательная (!) бухгалтерская
выдумкка такой регистрации (как камера Вильсона) событий и фактов,
которая, в частности, позволяет (постоянно) убеждаться в
справедливости обобщенного закона Ломоносова-Лавуазье:
"Сумма везде всего всегда равняется всему"*
___
*Просьба не путать с основным законом социализьма:
"Всего на всех не хватит, патамучта всех много, а всего мало."