FastReport: параметры TfrxADOQuery (кодировка???)

[Fermerius]

В стандартном потоке нет нужных полей, чтобы быстро вытащить их из базы и не просить техподдержку компилировать новый ресурс попробовал использовать TfrxADOQuery.
Проблема при использовании параметра для позиционирования на нужной записи. Как настраивать параметры - всё очень просто. Но при добавлении в запрос параметра - сразу же исчезает список полей, как будто в запросе ошибка.
Для примера:
select fFio from Persons
поле fFio - Можно вытащить на печатную форму с помощью дизайнера
А вот если
select FFio from Persons where fFio = :Student
где параметр :Student = <DSSTUDENT."STUDFIO">
Список полей моего запроса не доступен.

Возникло предположение что это связано с кодировкой в которой работают FastReport и Oracle.
FastReport работает с кодировкой DOS, а Oracle в кодировке Win

Как можно обойти эту проблему???

[larin]

Думаю кодировка тут не причем, FasReport тоже в кодировке Win работает.
Хотелось бы получить ваш файл FR3 и попробовать.
Пришлите мне на EMAIL.

[Damir]

такая же проблема.
решаем тем, что убираем параметры в запросе, правим и затем снова возвращаем параметры. неудобно...
при этом, если просто закомментарить - не помогает, компилятор видит эти переменные, невзирая на это.

[Fermerius]

Думаю кодировка тут не причем, FasReport тоже в кодировке Win работает.
Хотелось бы получить ваш файл FR3 и попробовать.
Пришлите мне на EMAIL.

Отправлю в ближайшее время...

такая же проблема.
решаем тем, что убираем параметры в запросе, правим и затем снова возвращаем параметры. неудобно...
при этом, если просто закомментарить - не помогает, компилятор видит эти переменные, невзирая на это.

Я точно так же делал... в принципе работает
Сейчас всё же проблема в кодировке.
Разработчики не вставили в поток ссылки на основные Nrec. Приходится привязываться по ФИО. Фишка в том что если писать :Student = 'Иванов Иван Иванович', то FastReport не позиционируется, а если написать :Student = 'ˆў ­®ў ˆў ­ ˆў ­®ўЁз' Это в Dos кодировке, запись возвращается, но на печать выдаёт все поля в такой же кодировке...

Выяснил у разработчиков что в ближайшее время выйдет патч по FastReport, в него будут включены функции перекодировок типа OEMtoWin1251...

[ilshat]

Спасибо за найденные грабли! Учтем на будущее. В этом огороде слишком много граблей...
Просьбу во все потоки ввернуть NREC-ки основных таблиц давно уже озвучивал. Как обычно тишина :(

[larin]

Просьбы выводить NREC-ки основных таблиц в потоки печатных форм звучат постоянно. Мы в подразделениях разработки постоянно эту тему поднимаем, постоянно убеждаем, постоянно просим прикладных программистов добавлять NREC-ки в потоки форм. Но к сожалению эти просьбы не всегда доходят до разработчиков форм. Особенно когда приходит молодежь, то не всегда рекомендации по добавлению NREC-ков берут на вооружение. Контролировать исполнение этого негласного правила очень сложно.

Встречная просьба к пользователям. Пожалуйста, когда заметите формы в потоке которых отсутствует нужный набор ключевых полей (NREC-ков и д.р.) обязательно фиксируйте проблему в ПИР с требованием доработать поток. Эти просьбы не останутся без внимания. Будет дополнительное напоминание разработчикам отчетов.

[ilshat]

Писать в ТП или прямо вам? (вопрос неспроста ибо ТП = болото)

А вообще идет ли процесс перевода динозавра "бизнес-текст" в фаст репорт?

Контролировать процесс добавления NREC вообще то несложно, только это опять таки в руководителей проектных групп упирается! Логично, что они ответственны за это. Депремировать не пробовали :))

[larin]

В ТП конечно.

[cruger]

В FastReport-отчётах мухи отделены от котлет. Т.е. данные получает одна подсистема (vip-интефрейс), а внешний вид строит другая (FastReport). Этой технологии и следует придерживаться. Если данных не хватает - вэлком в докомпиляцию.

С нашей стороны обещаем эрногомически улучшить этот процесс. Работы уже идут, колбэки приветствууются.

[ilshat]

вэлком в докомпиляцию.

В чем преимущество докомпиляции перед ADO в самом отчете? Как раз таки ADO дает быстрый результат при малых затратах. А вот докомпиляция - неизведанного размера грабли.
Если вы отделили мух от котлет - дайте хорошую вилку для котлет и хорошую мухобойку для мух! Уровня редактора FastReport.

[cruger]

Ильшат, преимущества докомпиляции во многом архитектурные:
1 Докомпилируется сам интерфейс, формирующий данные, поэтому есть доступ к логическим таблицам, из которых выгребаются данные (нет проблемы "добавьте нрек", для добавления в поток поля уже существующего узла не надо делать отдельный запрос к бд), всяческим полезным методам интерфейса и тд.
2 Доступ к другим объектам, видным из интерфейсов: глобальным статическим функциям, внешним функциям, объектным интерфейсам и пр.
3 Централизованный доступ к данным. Не надо открывать новое соединение, прошивать для него логин-пароль, беспокоиться об администрировании этой учётки, об обработке нехватки прав при формировании отчёта, о несанкционированном доступе в общем.
3а Особенно защита от нсд в настоящее время актуальна ввиду 152 ФЗ - о персональных данных. Мы (Корпорация Галактика) сертифицируем средство защиты по доступу к БД обычным образом, через вип. Доступ сторонними средствами (а Фастрепорт в этом смысле - стороннее средство) в случае его использования предстоит сертифицировать операторам персональных данных самостоятельно.

Насчёт хорошей вилки - дык ждём колбэков на тему той, что есть. Чем неудобна, где грабли и т.д. Шлите отзывы и пожелания, будем учитывать.

[larin]

Федор, вообщето Ильшат сейчас не может воспользоваться докомпиляцией потока данных. Поскольку практически нигде в Галактике потоки данных не заявлены как PUBLIC. Это препятствие нужно нам срочно устранять.

[Fermerius]

После установки патчей появилось две новых функции OemToAnsi и обратно AnsiToOem.
Проблема с кодировкой решена!!!

Теперь новая проблема: объект TfrxADODataBase отказывается хранить пароль.
Т.е. если в строке подключения указать ID и Password при первом запуске формы - коннект идёт.
Но после этого в строке подключения исчезает запись Password.
До патчей достаточно было указать в свойствах DataBase "Использовать пароль".
Сейчас приходится при каждом запуске вводить пароль пользователя

[larin]

Да я тоже заметил такое поведение. Но это не связно с установкой последних обновлений. Дело в том что мастер, который открывается по клику на значке, и раньше так работал. Он всегда при открытии устанавливает опцию "Спрашивать пароль". Если забыть ее переключить - то поле LoginPrompt будет выставлено в True, а из строки подключения пароль будет вычищен.

Если же вызвать мастер редактирования строки подключения к базе по клику из инспектора свойств. То там открывается другой мастер. Он сохраняет поле LoginPrompt. См. картинку. Рекомендую пользоваться инспектором, чтобы изменять и корректировать параметры подключения.

К Вам и к посетителям форума встречный вопрос.
Как вы думаете? Нужно ли изменить поведение окна "Мастрер подключения к БД"?

Я как-то думал, и пришел к выводу, что возможно это специально было сделано. Как средство борьбы с забывчивостью. Чтобы пореже сохраняли пароли в отчетах. Ведь храниться он там в открытом виде.

[Fermerius]

Да я тоже заметил такое поведение. Но это не связно с установкой последних обновлений. ...........

Ага, пробовал и так и так.
Всё равно сбрасывает.
пробовал на разных fr3 в разных базах под разными пользователями