Смена _запроса_ в рантайме

bakh · February 2004

Понадобилось сменить по результатам диалога в рантайме запрос, привязанный к текущему датасету...
Сам датасет для текущего бэнда сменить, как я понимаю, не составляет труда... Но в бэнде 20 с лишним мемок с указанием имени запроса...

Может есть у кого наработанные "методы борьбы с костей сапрыкиным"?..

Boris · February 2004

Мне видится выход из этой ситуации в использовании списка переменных, то есть примерно таким образом:

with frReport1.Dictionary do
begin
  if <условие1> then
   Variables['Field1'] := 'Query1."Field1"'
  else
  if <условие2> then
   Variables['Field1'] := 'Query2."Field1"';
end;

Ну, или так (абстрактный пример):

with frReport1.Dictionary do
begin
  if <диалог выполнен> then
   Variables['Field1'] := Диалог1.Параметр1;
end;

bakh · February 2004

М-м-м... Имхо, ты меня не совсем правильно понял...

Есть бэнд BigDataBand, у которого есть датасет, который зовётся _data1...
Есть запрос, из которого сей датасет берёт данные, зовётся он data1...
Всё работает, всё красиво...

Однако, есть на моей форме ещё один датасет _data2 и, соответственно, ещё один запрос data2... Поля в data1 и data2 идентичны...

По результату работы диалоговой формы я могу поменять BigDataBand.Dataset := _data2... И это хорошо...
Но в бэнде живёт десятка два мемо, в которых прописано, что их значение [data1."FieldName"]... А вот это уже бяка, т.к. имя поля правильное, но вот запрос - не тот, не [data2."FieldName"]...

Вот как-то так...

Перебирать все мемки и присваивать им принудительно?.. Ой, как неохота!..

Boris · February 2004

Так я же про это и объясняю!

Елы-палы лес густой...
В мемке пишешь не [data."FieldName"], а [FieldName], а реальное значение параметра заполняется в списке переменных, т.е

frReport1.Dictionary.Variables['FieldName'] := 'data1."FieldName"';

Или я опять не в ту степь пошел???

bakh · February 2004

(задумчиво) Всё правильно... Всё правильно...

Только ты мне по-моему советуешь это делать перед загрузкой репорта из кода программы?.. А я думал это средствами fr делать...
Или меня за 5 часов рабочего дня уже совсем переклинило?..

Да и вообще-то, честно говоря, не хотелось бы привлекать для этого дела словари... Что-то не нравятся они мне...

Alexander · February 2004

Можна я предложу примитивное решение в виде двух дата-бендов, одному из которых убирать видимость?

Boris · February 2004

Да именно так, из кода программы перед загрузкой отчета. Думаю, что на лету из отчета такое не получится.
А вот Alexander по-моему классный вариант предложил.

bakh · February 2004

2 Alexander:
Соглашусь, что решение примитивное и рабочее...

Но, имхо, тут возможны варианты хождения по граблям: это дело находится в субдетали... Вариантов смены датасета - 5... Соответсвенно, должны меняться и источники у детали...
(у меня уже едет крыша

)

Boris · February 2004

В таком случае, нельзя ли вообще изменить концепцию?
Я имею ввиду не переключаться между DataSet'ами, а менять сам SQL-запрос.
Ну, или другой вариант, может проще наклепать 5 одинаковых по структуре отчетов и вызывать нужный в зависимости от того, что возвращает диалог.
От такого действительно крыша поедет.

Alexander · February 2004

Тогда подойдем более творчески

Можна в твоем случае написать в качестве источника данных запрос с юнионами и неким ключевым полем? А потом выбирать данные с фильтром только из одного запроса? Или вобще в зависимости от выбранного юзером в ран-тайме строить запрос?
Оба варианта позволяют не изменять струтуру отчета

bakh · February 2004

2 Alexander:
Нет, этот вариант отпадает... Структура результата не позволит...

2 Boris:
Да, скорее всего это будет и проще и результативнее...
Т.е. в скрипте написать:
query.close;
query.sql.text := 'select * from x3';
query.open;

Я таки дозрел до понимания сути ДАО?..

Кстати, (даже не знаю, говорить ли это тут) было бы неплохо, что по умолчанию поля бы были бы вида ["FieldName"], т.е. без имени запроса... И брались бы из текущего датасета, т.е. привязанного к нему запроса...

Тогда бы и вопрос у меня не возникал...

Boris · February 2004

Считаю нужным добавить следующий комментарий, так как мне кажется мы немного недопонимаем друг друга.
Я имел ввиду менять текст запроса до генерации отчета, то есть следующая схема:
1. Вызов диалога
2. Выбор пользователем нужного варианта
3. Формирование запроса на основе возвращенного диалогом значения параметра
4. Генерация отчета.

Насчет того, можно ли в скрипте менять текст запроса, то я такого не пробовал и, что из этого может получиться не знаю.

bakh · February 2004

Да... Мы опять друг друга недопоняли...

Мне это надо делать именно из скрипта...
Диалог происходит не на уровне кода программы, а на уровне самого отчёта...

Boris · February 2004

Не понимаю только одного, почему нужно уже в отчете вызывать диалог, почему нельзя это сделать заранее?

bakh · February 2004

Издержки технологии!..

Отчётов - до дури, сами они и запросы к ним - все хранятся в базе...
Модуль отчётов просто вызывает ShowReport или DesignReport в зависимости от степени доступа к базе...

Ruslan · February 2004

bakh написал:

Кстати, (даже не знаю, говорить ли это тут) было бы неплохо, что по умолчанию поля бы были бы вида ["FieldName"], т.е. без имени запроса... И брались бы из текущего датасета, т.е. привязанного к нему запроса...

Тогда бы и вопрос у меня не возникал...

Так оно именно так и работает! Даже если без кавычек указать имя поля, то FR сам найдет поле текущего DataSet!

bakh · February 2004

Да-да-да!.. Я уже проверил... Действительно работает...

Так что "животрепыхающий" вопрос практически закрыт...
А я тут чуть с ума не сошёл и остальных замучал...

Было бы (опять ИМХО) всё-таки правильнее, если б для умолчального запроса имя запроса не вставлялось...

bakh · February 2004

Блин... А впереди ещё 5 рабочих дней!..

Не работает (в скрипте!) SubDetail1.DataSource := _data2;
Есть какие-нибудь мысли на эту тему?..

Я уже нифига не соображаю... Пойду домой...

FOX · February 2004

Наверно не лучший, но тоже вариант:
написать user function типа
chageDS( OldDataSource, NewDataSource)
которая меняет в полях имена источников данных
на нужные тебе, а затем в дилоге
вызвать её с нужными параметрами
chageDS( 'Data1', 'Data2').

bakh · February 2004

FOX написал:

написать user function типа
chageDS( OldDataSource, NewDataSource)

Мысль, конечно, свежая...
Только что-то не нравится мне догонять функциональность пакета своими руками...

Уже и так накололись с вертикальными числами в stretched-бэндах... Поправил, написал в суппорт, ни ответа, ни привета...

Если уж объявляется некая функциональность:

Объект "Бэнд" (TfrBandView)
Свойство	Тип	Описание
DataSource	String	Источник данных для дата-бэнда.

то, по-моему, это должно быть доступно и из скрипта...

bakh · February 2004

2 FOX: Фигня какая-то: не умеет FR передавать в параметры datasource'ы...

Блин, я сдохну, наверное, до вторника!..

Смена _запроса_ в рантайме

Комментарии

Оставить комментарий