ZhVВо-первых , зачем тратить молодые годы на копирование того , что уже есть и в гораздо более качественном виде. Можно просто с помощью InfoMaker-а или даже среды PowerBuilder-а (в сокращенном варианте штатного проекта и подходящего layuot-а)
- научить пользователя создавать нужные ему datawindow - manual-ы уже готовы
- предусмотреть в штатном приложении диалог для отработки последовательности действия
ls_syntax = LibraryExport(name_lib,name_obj,ExportDataWindow!)
ls_err = dw_target.Create(ls_syntax) Да, совсем забыл, такой подход тоже как-то был реализован в одном из небольших проектов.

ZhV ZhV[quot PL99] Все это подходит только для случая, когда разработчик системы сидит рядом с пользователем, получает за свою работу фиксированный оклад и исключительно трудолюбив - поддержка такого хозяйства довольно трудоемка.
"Отнюдь"(с) - Код "ГО" уже достаточно стабилен в работе и не нуждается в постоянном присмотре. А datawindow для шаблона может сочинить любой программист PB , главное - прилично знать SQL , БД приложения и соблюдать некоторые несложные "соглашения" по конструированию шаблонов. Поэтому вовсе даже наоборот - работаем удаленно по почте по мере поступления ТЗ.Навскидку - ZhV3) юзера сохраняют этот шаблон в оговоренной сетевой директории , откуда их видит "ГО" (отдельное mdi_window)и загружают к себе на исполнение - сначала ask-диалог на параметры , а потом retrieve по этим параметрам в штатном datawindow с CREATE(синтаксисом из шаблона) это самое слабое звено, учитывая, что ZhVв каталоге лежит несколько сот файлов-шаблоновВпрочем, не буду настаивать :-)

ZhV PL99За полчаса проходили цепочку запрос от бизнес-подразделения-> постановка задачи->согласование->разработка отчета->тестирование?
Если речь идет только о написании SQL-запроса, то, мне кажется, гораздо дешевле не использовать вообще никакие генераторы отчета, а выдавать пользователям результаты этого запроса в виде, например, xls-файла.
Вся ваша цепочка имеет место быть при штатной работе - зачем плодить партизанщину без нужды. Но... Когда в 15-00 просят соорудить отчет, подлежащий сдаче к 18-00, прямо с телефона - "вот такой же как ... но со сверткой подекадно и расчетом показателей прироста..." Для меня вставить агрегатные функции в SQL Select несложно - а вот для человека с экономическим образованием ? Конечно такие случаи нечасты - но они сильно укрепляют позитивные взаимотношения.Здесь я тоже позволю себе остаться при своем мнении - если пользователь захотел нечто за три часа до сдачи, то это его проблемы, а не мои.

ZhVА насчёт Excel-я - так так когда-то и было . Этот кошмар уже стал забываться , когда между SaveAs->Excel и готовым отчетом нужно сделать полтыщи кликов ...А это совсем другой вопрос, он обсуждается в соседнем топике

ZhV ZhVА еще , по соображениям безопасности - далеко не всегда целесообразно знакомить юзеров со структурой БД. PL99Как связано знание пользователем структуры БД и безопасность?
А вам не приходит в голову , почему так свободно можно купить БД налоговой или сотовых операторов ? Если б только DBA имел доступ - проблем вычислить и прищучить не было. А так по вашей методе - всякий самый рядовой юзер может получить бесконтрольный доступ к описанию базы , а иногда и к содержимому - долго ли знаючи экспортнуть на флэшку.Так это должно решаться разграничением прав доступа, а не запретом на знание структуры. Пользователь под своим логином не должен, разумеется, иметь административных прав. Что же касается доступа к таблице, скажем, клиентов, то если пользователь имеет элементарные знания SQL, то все остальное он так или иначе получит. Разумеется, что поименовав таблицу клиентов, скажем, XG1537 мы несколько затрудняем ему доступ, но, с другой стороны, наверняка, где-то рядом будет таблица, к которой этот пользователь должен иметь доступ и содержащая запись вида
XG1537 КлиентыВпрочем, опять-таки, прошу рассматривать это как MHO.