да, он отрабатывает на все 100%. Коллеги исправили ошибку, удалив таблицу командой drop и пересоздав ее через DDL-команду. То есть по логике не внесли никаких изменений в метаданные.


Проверил зависимости - вообще никаких нет.

Спасабо, Дмитрий, за вашу помощь. Все это уже становится гаданьем на кофейной гуще. Дождусь следующего инцидента с таблицей и попытаюсь вытащить базу данных для исследований. Тогда опубликую еще раз сообщения. Пока ограничусь отпиской, что FB-Team рекомендует сменить версию сервиса.

PS to Kdv: Дмитрий еще раз перечитал ваши рекомендации по переходу на Юникод. Хоть мы используем "старый способ", но отличие у наших баз только одно: хоть в скриптах создания базы и описано set names и create databse default character set как UTF8 , но в реальности из-за миграции данных они остаются ISO8859_1 . Это может играть какую то негативную роль?

Судя по этому сообщению 22182137 , то разработчики именно правильно ориентировались. Основной тип текстовых данных - ISO8859_1. UTF8 выбран как вспомогательный, потому что предоставляет возможность мультибайтовых национальных символов умещать в ограниченных объемах записей уже стандартированных интерфейсов. По сравнению с использованием UTF16 это заметно.

С другой стороны замена всех символьных типов на UTF8 может привести к увеличению объема базы данных. В стандартной комплектации робота, основная база расположена на том же компьютере, где и сам робот. в зависимости от подключенного оборудования, процессор может быть от Celeron (управление одним роботом) до Core I7, Память от 1GB до 4GB. С этой стороны есть ли какие то рекомендации по использованию низкопроизводительных процессоров и небольшого объема рабочей памяти?

Всегда лучше узнать мнение специалистов. О том, какая машина будет использоваться решаю не я. Для подачи совета нужен веский аргумент. Сейчас аргументом является "это дешево и работает". Когда на одной машине работает PLC, программы с графикой и стримингом видео с вебкамеры, компилированные в Embarcadero (а Дельфи создает совсем не компактный код), да еще и база данных, вопрос становится актуальным. В данный момент база сконфигурирована так, что сразу ведет запись на диск. Но может оказаться так, что проблемы вызваны именно нехваткой памяти.

по сравнению с чем? Вы в курсе что такой кодировки в Firebird нет совсем. В последних версиях Interbase вроде есть, но как по мне она на фиг не сдалась.

Про процессор. Вы ведь в курсе что если у вас чарсет коннекта и столбца отличаются, то Firebird будет делать преобразование кодировки на лету. Это будет жрать процессор. Как по мне, то в современных условиях нужны только две кодировки UTF-8 и OCTETS для бинарных данных. Остальные оправданы разве что из за совместимости со старым ПО, которое UNICODE не поддерживает. Объём БД на диске как по мне не так критичен, во первых он не вырастет кратно, ибо записи всё равно хранятся сжатыми, а во вторых в вашем случае не каждый символ будет занимать более 1 байта.

Про память. Да потребление памяти скорее всего вырастет, но не сильно. Главный совет конфигурируйте Firebird под конкретную машину. Переходите на 3.0, там можно использовать SS с общим страничным кешем, что позволит сильно экономить потребление памяти, когда пользователей много.

Большое спасибо! Дельные рекомендации. В данный момент чарсет коннекта utf8, а столбцов с ISO на порядок больше, чем UTF8. Полный перевод всей базы на UTF8 потребует использования дополнительной программы обновления.

Переход на 3.0 уже раз обсуждался - из-за хранения пользователей в самой базе. Вот еще один аргумент скорейшего перехода. Пользователь используется всего один - sysdba. Хотя есть конфигурации с репликациями - там еще один добавляется. Но одновременных соединений от 39 до 60. Так же зависит от конфигурации: заспускаются различные треды, каждый со своим коннектом. Еще пара вопросов: при миграции с 2.5 на 3 много нюансов нужно учитывать при переводе базы? Есть ли где то готовое описание подобного перевода?

Всем спасибо за советы!