Приветствую уважаемых коллег.

Понадобилось мне тут переделать одно из своих Delphi-приложений, которое цепляется к БД FB2.5 и тащит из неё данные. Использую FIBы. Приложение должно отправить на сервер SQL-запрос и получить данные. На моей машине я развернул бэкап боевой базы, к которому и цепляюсь. Вот текст запроса:


Юзаю Delphi 2010 с FIB+ 7.5. Совершенно точно знаю, что строка, соответствующая условию, в базе есть. Тем не менее, компонент pFIBQuery возвращает пустой набор данных. База в кодировке UTF8, к самой базе цепляюсь с кодировкой WIN1251. При подстановке в запрос названия единицы вместо параметра также возвращается пустой НД. FlameRobin выполняет этот запрос правильно. Нужен совет: как при TCP-коннекте на одной и той же машине правильно отследить, что именно и в какой кодировке отправляется на сервер? Какой инструмент лучше для этого использовать?
Заранее благодарен.

А нет ли какой-то доки по использованию трейса?

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

авторИ что же мешает сделать
Зачем? Должно работать и так. Что удивило - то же самое приложение до переделки работало правильно с тем же кодом, и переделка этот кусок не затронула.

авторМожет потому не затронуло, что первые 127 символов utf8 совпадают с ASCII и проблемы начались как только в искомой строке стали встречаться национальные символы?
Я об этом думал, но не подтвердилось.
Завтра займусь трассировкой. На крайняк переведу приложение на связку Lazarus+IBX от Rik - там будет UTF8 без BOM, и гемора с перекодировкой нет вообще. А у ФИБов с Delphi здесь, похоже, иногда бывают проблемы из-за разницы между UTF16 и UTF8.

авторАсь?..
Да, здесь есть хрень. Когда я писал первую программу с ФИБами на D2010, я долго плевался с выбором кодировки соединения, получая раз за разом Malformed string. Эксперименты показали, что при соединении с кодировкой WIN1251 проблем нет, и данные из компонентов через параметры вносились корректно и без сообщений об ошибках. Потом я много раз пытался реализовать преобразование текста в UTF8 и его передачу в ФИБы с подключением к базе с соответствующей кодировкой, но в конце концов плюнул - уж очень мудрёное у этих ФИБов нутро. А Лазарь с IBX от Rik меня в этом плане очень порадовал - там все визуальные компоненты LCL принимают текст в UTF8 напрямую, и всё это даже работает в Линуксе.

Здесь действительно есть косяк с моей стороны. Разница в кодировках, на первый взгляд, кажется тупостью, но я в свое время реально *** с этими ФИБами, цепляясь через UTF8, передавая строки и получая Malformed string. Но я уверен, что при использовании средств мониторинга задача с поиском бага и возможной правкой ФИБов на предмет корректной передачи строк в UTF8 может существенно облегчиться.

авторТелепатия не нужна. В FIBPlus кодировка соединения задается через параметр соединения "lc_ctype"
У Любезного, соответственно, lc_ctype=WIN1251
Но в D2010 компоненты VCL все юникоднутые и работают с UTF16. И не все компоненты доступа правильно обрабатывают эту кодировку и готовят строки к передаче на сервер.

авторВ FIBPlus кодировка соединения задается через параметр соединения "lc_ctype"
Не только. Там есть два способа задания кодировки соединения - через DBParams (TStrings) и через набор свойств TpFIBDatabase.ConnectParams. Как работает эта связка при задании параметров в Runtime - одному Бузаджи известно, хотя можно и сорцы поисследовать. Возможно, в этой связке могут быть какие-то косяки.

авторПрихожу к выводу, что это глюк в конкретной версии FIBPlus.
Я тоже это предполагаю. Завтра буду ковырять. Но хотелось бы предварительно подтвердить или опровергнуть это с помощью мониторинга. Очень надеюсь, что своими правками не сломаю эти ФИБы.

авторИз этого же faq чуть ниже:
Ты, похоже, так и не вник в суть проблемы. Если сервер отдает данные в WIN1251, а компоненты доступа не преобразуют их в UTF16, отображение их на экране корректным не будет. ФИБы однозначно выполняют какое-то скрытое преобразование. Иначе ничем не объяснить то, что вычитывая данные стандартным механизмом через FieldByName, я получаю значения, которые без проблем выводятся в TLabel, TEdit и другие официальные лицаVCL-компоненты без каких-либо дополнительных преобразований с моей стороны.

авторМожет быть, а может и не быть. Это зависит от текущей ANSI кодовой страницы.
С этой частью я как-то не экспериментировал - времени не было.
авторТому чуваку в эмбаркадере, который додумался обеспечить прозрачное, автоматическое и неотключаемое перекодирование между AnsiString и WideString стоило бы выдать запрет на профессию архитектора.
+1. Если бы его можно было отключить хотя бы флагом компилятора или настройкой в IDE, проблем было бы гораздо меньше.

авторПосле задания полей в ConnectParams в DBParams помещаются правильные названия параметров со значениями
Ты проверял на практике, исследовал сорцы?
Я завтра обязательно проверю это в Delphi. Есть вероятность, что в разных версиях ФИБов могут быть различия в коде.

Господа, нужна подсказка по трейсу в винде. Запускаю сессию, но получаю ошибку. Как правильно писать путь к логу?

автора) прочитать внимательно заголовок fbtrace.conf и примеры в том же fbtrace.conf, найти там что-нибудь про бэкслеши
Смотрю.
автор# For log file name Sed syntax for substitutions is supported.
# I.e. \0 - whole matched string, \1 ... \9 - parenthesis subexpressions.
# \\ is backslash.
# String values should be enclosed into (any kind of) quotes if contains
# spaces embedded, for example:
# log_filename 'C:\Documents and Settings\Firebird\My Documents\trace.log'
# include_filter "Database Stats"

Кажись, дошло, спасибо.
авторб) прочитать документацию к Trace and Audit Services и понять, что в случае пользовательской трейс-сессии лог задавать вообще не нужно
Не обязательно или не нужно?
Ну не знаю... Кодировку, ИМХО, проще выявлять не на лету в командной строке, а через исследование в хорошем текстовом редакторе с возможностью бинарного просмотра файла.

Проблему отловил без файла лога. Какой же я дурила... И зря гнал на ФИБы. Нельзя в Delphi называть переменные словами вроде UnitName. Благо, что есть трейс, который позволил выловить причину после первой же успешной сессии - в параметр передавалось значение "pFIBQuery".