Док,

если суперсервер, то даже одинаковой разрядности два разных не пройдут.
А если классик или суперклассик - то да, разная разрядность - отказать, одинаковая - можно.
Собственно, 32-разрядные сервера ФБ сейчас имеет смысл пользовать только если у тебя есть 32разрядные UDF, которые нечем заменить для 64 (ни перекомпилировать, ни заменить встроенными функциями).

Старый плюшевый мишка,

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

Так что, самое осмысленное - это несколько приложений в режиме embedded на одном компе. Тут - да, они все типа суперсклассик.

ДокА вот IBE, как выяснилось, бывает в природе только 32-битный. Вот и приходится, как светофору, пускать движение поочередно
ну что ты, ей-богу. 32битный ИБЕ прекрасно коннектится к 64бит серверу. Ну клиент 32битный ему нужен, и что? Для этого разве надо ставить 32битный сервер?

rdb_devНу ты дал, конечно..
"у tcp нет разрядности" :-) А локальный протокол в тройке и далее лучше оставить для embedded.

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

А вот с первой, битой базой - чаще всего из-за повреждений с ней невозможно работать, или как минимум поврежденный участок не скопируется и не прочитается никак. Сервер (и тут до лампочки, суперсервер это или что-то еще) при обнаружении серьезных ошибок прекращает работать с базой принудительно, о чем выдает соответствующее сообщение.
Нормально и по максимуму экспортировать базу можно экспортом в FirstAid, поскольку тут Firebird не задействован для чтения поврежденных данных.
Читаем
https://ib-aid.com/download/docs/firebird_firstaid_recovery_guide_ru.pdf
с 10й страницы - "Ремонт с помощью извлечения данных"

ggreggoryДа-да, вот про это я и спрашиваю.
про что - если первая база повредилась на компе из-за глюков памяти или файловой системы, и там же сделали вторую базу, которая может быть аналогично повреждена?
Это не вопрос, и ФБ тут вообще ни при чём.
ggreggoryПоследние приводят к внутренним ошибкам сервера. Это имелось ввиду. И да, речь не о ремонте, а именно о ручном переносе данных операторами
ну, тогда да, имеет смысл обезопаститься, 2 супера на разных портах. Но в таких случаях, когда с исходной базой возникают
internal Firebird consistency check
"работа операторов" - вообще бред. Как можно что-то перенести, если любой тычок в поврежденные данные приводит к ошибке, и последующей невозможности работы с базой?
Я понимаю, что у вас идет проработка сценариев, но этот сценарий совсем хреновый. Тут при ремонте-то приходится всякие действия повторять по 2-3 раза, а вы про "операторов" говорите. Которые ничего кроме тупого тыканья кнопки сделать не могут.
Гораздо эффективнее и быстрее отремонтировать или экспортировать БД, а уже потом переносить данные.

Кроме того, в подобных случаях нет никаких бэкапов, а если и есть, то битая база от сентября, а ее копия - от января. И залить данные из сентябрьской в январскую не всегда возможно.
А есть еще такие, когда дают базу на ремонт, и продолжают с ней работать. А потом спрашивают - как из побитой базы перенести данные в починенную? В 80% случаев - никак. А даже если и "как", то это может сделать только разработчик приложения и БД. Оператор этого сделать никак не сможет.