Если выполнить стандартный запрос IBExpert-а "Database monitoring -> Attachments" (я немного урезал его под свои нужды), то выдает ошибку: arifmetic exception, numeric overflow, or string truncation. Cannot translitirate character between character sets.
Проблема судя по всему заключается в русскоязычном имени ПК, которое должно отображаться в поле "Remote Address". Можно ли как-то преобразовать выводимые данные в рабочий формат да и вообще какой набор символов нужно подсовывать?

Запрос:

Симонов Денис,

У меня лично стоит FB 2.5.2.26540 и наблюдается такая же проблема, у клиентов (их примерно 16 с русскоязычным именем ПК) версии FB 2.5, но сборки могут отличаться. Помогает переименование ПК в англоязычное имя, но слетают лицензии на ПО, поэтому я сомневаюсь, что это выход из сложившейся ситуации.

Симонов Денис,

Кодировка win1251, TA не используется. В mon$remote_address отображается имя ПК, если подключиться через IBExpert. Проблема в том, что пытаюсь мониторить через приложение подключения к БД и в списке подключенных может быть IBExpert, mon$remote_address которого имеет имя ПК...
Лично на моей машине все пути англоязычные, соответственно остальные поля не должны вызывать ошибку при запросе.
Попробую обновиться до 2.5.3, посмотрим что из этого получится.

Симонов Денис,

и еще вопрос пока не забыл. Если делать, например, бэкап, то в этом же "мониторе" отображается подключение к БД, но не отображается mon$remote_process (это поле имеет значение NULL). Вы случайно не в курсе будет ли писаться, что процесс породил gbak, например? Планируются ли подобные изменения?

NickDee,

только что попробовал на клиентской машине в IBExpert открыть монитор под UTF8, ничего не изменилось. Я и приводить поле к UTF8 через cast пробовал - все равно ошибка.

Симонов Денис,

На самом деле бэкап вызывается через компонент ADIBBackup в Delphi. Строчка выглядит примерно так:
gbak -b -g *.fdb *.fbk -user SYSDBA -pass masterke (т.е. бэкап без сборки мусора).
Точно так же, если делать бэкап через IBExpert, то в "мониторе" тоже не отображается mon$remote_process.

Симонов Денис,

проблема как раз таки есть. Раньше наше приложение сидело под рутовым пользователем, примерно полгода назад мы от этого отказались и создали дополнительную роль для пользователей программы. Сейчас имеем несколько приложений, которые теоретически могут подключаться к БД под рутом. В основном мы используем clasic server. На нем есть такая особеность: если подключиться к БД под рутом и после коннекта отправить БД в shutdown, то потом БД нельзя ни поднять Online, ни снова отправить в shutdown. БД "зависает между состояниями". Чтобы предотвратить эти зависания мы разработали сервис, который мониторит коннекты на серверах пользователей и если кто-то сидит под рутом, то мы меняем настройки на выделенную роль. По мимо коннектов пользователей так же под мониторинг попадает и IBExpert, который коннектится к БД под рутом и как правило стоит для поддержки клиентов (т.е. для разработчиков), но клиенту ничего не мешает им пользоваться.
Проблема еще в том, что некоторые пользователи ("очень умные") пишут сами приложения или где-то их приобретают я не знаю, но как выяснилось через какие-то сторонние приложения коннектятся к нашим БД. Именно поэтому хотелось бы наверняка знать чей коннект поднят.

kdv ,

символы * в имени БД и бэкапа я намеренно поставил, имена у нас задаются корректно, с этим проблем нет.

kdv,

под рутом я имею в виду SYSDBA

Симонов Денис,

как раз мониторинг и предназначен чтобы отловить тех, кто использует SYSDBA для подключения к БД. Для 100 клиентов это не просто сделать - взять и сменить логин/пароль на админа, к тому же кучу приложений переписать в множестве мест, где поднимаются коннекты к БД... Мне честно говоря не понятно как мониторинг вообще может влиять на производительность? Это такой же запрос к БД как и остальные, разве что он опрашивает системные таблицы, которые и так нельзя изменить.