Как с помощью SQL определить под какую архитектуру процессора собран Firebird SQL Server, который обслуживает текущее соединение с БД?
Вот версию сервера я узнать могу:


"4.0.1" допустиим.
А вот под какую архитектуру процессора собран Firebird?

rdb_dev,
а ENGINE_VERSION на кой? :)
Или вот на кой 2692 в этом выводе:


?

А если по сути, то острой необходимости нет,
это скорее вопрос "комфорта" мониторинга и управления многосерверной среды.
В которой:
1) админы/девопсы "крутят" дистрибутивы и настройки;
2) поддержка/тестирование в прикладном ПО выбирает с какой из "БД" (соединением) им сейчас нужно работать;
3) разработчик получает отчёты об ошибках/замечаниях по производительности работы прикладного ПО;
4) всё это крутится в виртуалках и облаках;
5) разработчикам приходится для воспроизведения ошибок и тество использовать многосерверность локально.

Хочу чтобы у разработчика/админа через соединение с БД (а также при крашах прикладного ПО) было понятно, что за Firebird сервер обслуживает соединение. Не всё же ручками туда бегать.

П.С.: Следующим топиком должна стать доступность версии сборки ПО и конфига :)
Это норма вроде в современном мире поддержки ПО...

П.П.С.: И понятно, что начнут появляться вопросы, что на такую инфо неплохо бы раздавать GRANT.

О, забыл страницу обновить перед очередным постом.
Спасибо всем!

П.С.: Про эксплоит было прикольно, поржал...

Зачем бегать-то? На связке host/port может сидеть только один Firebird сервер.
Достаточно иметь список установленных и строку подключения к БД.


Почти.
В один условный момент времени только один работающий сервер.
А установлено и настроено в незапущенном состоянии их может быть больше 1-го....

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

у меня на компе около 30ти разных версий FB и IB. В реестре и в службах никто не зареган.
Запустить любой я могу за 2 секунды.
Дальше что?
Это как раз и есть пример, что в отчёте приложений-клиентов, я хотел бы знать больше деталей о том, какие именно дистрибутивы FiirebirdSQL обслуживали мои клиентские приложения.

В этом топике я не спрашивал про зареганность в службах или реестре.

1) Интересовала архитектура процессора , под которую собраны бинарники именно того SQL-сервера, который обслужил соединение.

2) Хочется получить именно с помощью клиента.
Почему?
Потому что приложения уже используются и обновляются своим чередом, нет нужды затевать доп. организационные или технические процедуры. А серверные среды многолики и децентрализованы.

3) В каких целях?
А) сбор статистики на предмет одно/много-образия используемых SQL-серверных сред;
Б) получать конфигурацию SQL-сервера в момент соединения, чтобы при возникновении ошибки зафиксировать в отчёте и потом иметь возможность максимально точно сконфигурировать среду для воспроизведения ошибки.

в таком случае программиста должна интересовать только версия сервера. Архитектура - это уже про другое, и с этим разбираются именно на сервере в случае проблем. Например, снять дамп фб - для суперсервера и классика будет разница.
1) Контрольно: я спрашивал про архитектуру процессора , под которую собран бинарник FirebirdSQL.
Грубо говоря: какой дистрибутив был использован админом для сервера, который обслужил соединение.
Или все дистрибутивы работают абсолютно одинаково? :)
2) Не всегда получается разбираться с ошибкой на сервере.
а) у программиста нет доступа,
б) мы говорим об условиях непостоянной серверной среды. Ошибка была позавчера, сервер мигрировал вчера, сегодня ошибка не воспроизводится, но в причинах необходимо разобраться. Можно ли исключить в этом случае, что смена сервера - не при чём?

Да.

Странно. А что же тогда столько шуму было с 3.0.4 и ODS 12.0 -12.2?