Ну там где есть - очевидно, не повреждаются. Но пользователей сотни у кого есть, у кого нет. В 90% случаях gbak-ом восстанавливаются из автоматических резервных копий с потерей пары дней работы. В оставшихся 10% случаях (когда все так плохо и настолько повреждено, что даже автоматические резервные копии уже долго не делались или умер диск вместе с базой и с резервными копиями) - как правило, проще начать с нуля, тк восстановление экспертами с IBExpert или разными сургеонами выйдет в круглую сумму.

Ну тут все-таки переход на юникодную Delphi лучше, чем насиловать Delphi 2007. На Delphi 2007 все эти костыли всё равно через раз работают и по-нормальному как на юникодной Delphi все равно не будет.

Скорее всего, нет. Т. к. смотрю, скажем, в DB.pas, читаю и вижу фигу. Чужой код вообще плохо читается. Хотя была идея работать напрямую с базой на сервере (через gds32.dll) и создать что-то на базе TTcpSocket чтобы сделать что-то типа своего сервера, который бы обращался к Firebird. Но теперь думаю, что скорее всего оно того не стоит, быстрее чем IBSQL (а не IBQuery, который не нужно использовать) не будет.

В FireDAC кстати правильно настроенный аналог IBQuery (TFdQuery) работает примерно с той же скоростью, что IBSQL в IBX. Оттого и кажется что гриды на FireDAC могли бы быстрее отображаться (тк сравнивать надо не TFdQuery и IBSQL, а TFdQuery и TIBQuery). А в IBX - конечно есть IBSQL - но DataSource и гриды ведь всё равно требуют медленный TIBQuery.

Умеет. И по скорости, и по шифрованию. Загвоздка только в прокладке неподходящей
конфигурации.


И даже умеет работать при нестабильном коннекте? Ну это - когда у клиента "интернет работает, сайты открываются", но пакеты теряются и TIBDatabase, TIBTransaction, TIBQuery и прочее глючит?

"Фантастика в соседнем отделе". В TCP пакеты теряться не могут. Их потеря
приводит к разрыву соединения и с этим ни один stateful протокол не справится по
определению.

Зря Вы не стали писать свой собственный сокет-сервер. Получили бы неоценимый опыт.


Да - но попробуй это объясни пользователям. Они говорят "интернет есть", а когда им говоришь про необходимость непрерывного бесперебойного соединения для клиент-серверных программ - считают, что им голову морочат ведь сбербанк онлайн, видеосистемы, тимвивер и прочее работают.

Просто Вы масштабы проблемы видимо не поняли. При локальном коннекте и даже при сетевом всё работает нормально. Но стоит только сделать подключение к базе через Интернет (используя какой нибудь Хамачи). Хорошо если проводной Интернет, а не какой-нибудь 3G/4G. То всё начинает жутко тормозить. Пинг между компьютерами может быть всего 50 миллисекунд. Но при этом каждое обращение к базе может занимать 200 миллисекунд. Обращений таких при открытии разделов множество и не надо говорить про потоки, это поможет разве что добавить глюков в программу. А при выполнении операций еще больше (там запросов туда-сюда гоняется очень много и всё последовательно). Надо, конечно, оптимизировать всё и возможно, всё переписывать - но это в идеальном мире. Знаю и видела на прошлой работе, что в 1С для этого придумали что то типа &НаСервере, &НаКлиенте (правда с этими &НаСервере башку можно сломать). А по итогу разделы открываются по 5 секунд, а разные операции могут занимать и по 30 секунд - при пинге через черную командную строку в 50 мс. Притом что при подключении по Team Viewer или через RDP если работать с базой локально или в локальной сети всё практически мгновенно. Ускорить бы этот неоптимальный код раза в 2 просто переходом с IBX на FireDAC но похоже, что это не спасёт. А так делать, конечно, мне нечего как оптимизировать код ради оптимизации.

Так в локальной сети же всё нормально. Проблемы если подключаться к базе через Интернет. И не каждый админ возьмется такое настроить.