Delphi 7 на костылях: автоматизация подготовки ресурсов

Нормально там запросы хранятся в свойствах Query-компонентов, зачем было мучиться с переносом их в rc? Чет вы деятельность на пустом месте замутили…

Не хранятся там они в Query-компонентах. Не в этом проекте. И старые «обмены» я не трогал, пока их не приходилось ремонтировать или дорабатывать. Всё это предназначалось в первую очередь для новых задач.

Запросы, как ни странно, определялись ранее в тексте программы, и загонялись последовательно в один и тот же query. Примерно так:

with ExportQuery do
try
  Close;
  SQL.Clear;
  SQL.Add('SELECT DISTINCT Alias1 = C1.Alias, Alias2 = C2.Alias, ...');
  SQL.Add('FROM ... JOIN ... ');
  SQL.Add('JOIN ...');
  SQL.Add(Format('LEFT JOIN ... WHERE GroupName = %s AND OperDate BETWEEN %s AND %s',
    [QuotedStr(GroupName), QuotedStr(DtoS(BeginDate)), QuotedStr(DtoS(EndDate))]));
  SQL.Add(Format('AND ...',
    [GetIntegerObject(SectorComboBox)]));
  Open;

А новых «обменов» у меня один-два в месяц. За это время порядка четырёхсот только запросов добавлено. В новых задачах я, кстати, сразу избавился от отдельной формы на каждую задачу. Во всех последующих — одна на всех форма (настройки там достаточно однообразные), декларативное описание потребных настроек и фреймворк. Первое время я использовал ещё дата-модули, но оседлав ресурсы отошёл от них — трудозатратно, много проблем с обобщением процессов… Кстати, помимо запросов я добавляю в ресурсы «преобразования» — фактически, DSL для конкретной задачи. Вроде такого (фрагмент), это вместо кода для формирования xml:

SKU
    code=(50)+ProductID
    shortname=(50)ProductName
    name=(100)ProductName
    article=(150)article
    producercode=(50)article
    parentcode=(50)+GroupID
    SKUType==30
    *[0]units=Cfg_Chicago_SkuUnits
    *[1]prices=Cfg_Chicago_SKUPrices

Теперь представьте себе задачу: после изменения схемы БД найти все запросы, где упомянуто конкретное поле. Читали выше о том, как в компонетнах хранится текст? Между тем, задача поиска контекста по запросам возникает регулярно, пусть и не всегда причины столь жёсткие. Открывать сотню с лишним форм и протыкивать компоненты, надеясь ничего не пропустить, потрошить не совсем текстовый dfm или поиск по проекту в современном редакторе — что бы Вы выбрали? Мне хватило ровно одного раза, чтобы от хранения запросов в компонентах отказаться сразу и навсегда.

Извините, хотел ответить Вам, но промахнулся — написал в корень. Ну да заодно пример добавлю — единственное место, где есть ссылка по имени ресурса. Это потом передаётся фреймворку, а он отдаёт готовый набор данных.

const
  PARTDEFS: array [0..nnn] of TCustomPartitionDef = (
    //**************************************************************
    // Отчёт «XXX»
    //**************************************************************
    // Продажи (нарастающим итогом)
    //**************************************************************
    (
      PartId: 'Sales';
      PartCaption: 'Продажи';
      DatasetSource: 'SQL_XXX_Sales';
      ConversionsSource: 'Cfg_XXX_Sales'; // Это тоже в ресурсах лежит
      FileNameTemplate: 'YYY_{{Filial}}_{{month}}_Sales.xls';
      EnabledFor: [emDay, emMonth];
    ),
...

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

в батнике увидел touch — тоже не виндовая программа, что-то стороннее…

это из линукса, он ставится вместе с git. Git я использую БЕЗУСЛОВНО, вот просто без вариантов. Чего и всем программистам желаю. При этом без touch автоматизация работать будет, лишь замедлится реакция среды на изменения. Там ещё sleep есть в зависимостях, и его отсутствие тоже не критично (про всё это есть в README.md)

Редактор запросов в виде компонента — ненужная хрень

Согласен. Даже при том, что это не редактор, он только хранит код внутри себя. Для редактирования он использует редактор IDE, на скриншоте это видно. Ненужным он оказался именно по «некрасивому» способу хранения и по причине привязки к неплохому, но единственному редактору. Без мультикурсора :). Зато двойной клик на компоненте, открывающий сразу текст запроса (с подсветкой синтаксиса SQL, которая в Дельфи есть) сразу во вкладке основного редактора, всяко быстрее будет, чем выделить компонент, переключиться в Object Inspector, найти свойство sql и нажать на маленькую кнопку с многоточием (по двойному клику на AdoQuery, к примеру, открывается список параметров запроса, а вовсе не его текст). А потом в случае использования штатного компонента ещё на «Code editor» надо тыкнуть, если захотелось подсветить синтаксис. Но тупиковая ветвь, да. История. Эпос :).

Мне бы виделся такой простой вариант.
Раз запросы хранятся в виде файлов, то значит есть загрузчик запросов в Query или через что они там выполняются. Пишем 2 варианта загрузчика —

1. непосредственно из внешних файлов, при отладочных запусках.
2. из ресурсов, при рабочем билде
   Пишем батник для сборки рабочего билда, с предварительной сборкой ресурсов.

Предложение интересное, но не лишённое крупного недостатка. Работа приложения в момент разработки сильно отличается в основном функционале от того, что уходит конечным пользователям. Отладочные запуски не вскрывают проблем со сборкой ресурсов. Тут либо специально тестировать, либо признать что «так сойдёт» и когда-нибудь напороться.
И обратите внимание, что это предложение исключает только оперативный мониторинг, который во всей этой затее — самая простая часть! Создавать rc-файл для компилятора всё равно чем-то надо. Либо вручную (Фе!), либо опять же кодогенерация.

А вот за это прямо-таки большущее человеческое спасибо. Зная, что именно искать, уже немало полезного нашёл. Обязательно исследую этот вопрос на днях.
Да, в семёрке оно уже есть (впервые появилось в 5-й). И в приложенных исходниках интерфейсы нашёл.

Дома — только линукс, но никакого Паскаля. Я его, конечно, умею, и даже люблю — по заповеди, как самого лучшего врага :).

Я предпочитаю Java, она ламповая и тёплая. Я её умею, и кое-что именно на ней крутится (серверное). Жаль, давно не приходилось тот проект дорабатывать, релакс же буквально, под Idea-то Ultimate! Оцените иронию: дефицитная ныне специализация на Delphi позволяет мне оплачивать лично для себя коммерческую "Идею", чтобы отдохнуть от Delphi. Но вообще на текущем месте с Java чисто инфраструктурные проблемы, да и вообще под неё надо ломать унаследованную парадигму "настольный клиент — sql сервер", а это больно, и, прямо скажем, не от меня зависит.

Вот и погоняю некроконструктов. Потому, что если зомби не ест, не пьёт и не спит, да ещё и работает добросовестно, то заменить его на того, кто хочет кушать, просит особых условий и вообще состоит в профсоюзе — не самая лучшая идея с точки зрения экономической целесообразности, к сожалению.

В тестовом задании, когда устраивался на работу, так и сделал. Сказали: "круто, но..."
Мешают два обстоятельства. С одной стороны, ресурсы всё же связаны с кодом — каждая задача имеет не только запросы, но и код, чрезмерное абстрагирование всё усложнило бы до безобразия. И до кучи деплой а-ля колхоз. Настольное приложение, кто-то обновляет на автомате, кто-то нет, а кто-то только думает, что на автомате. Поскольку техподдержка тоже на мне, рассинхронизация версий кода и ресурсов — лишняя точка для прорастания проблем. Поэтому единый артефакт сильно облегчает сопровождение. Или обновили, или нет.