Надо бы новый проект наваять. Для "внутреннего" пользования.
В стиле "тяп-ляп", чтобы без особого напряга, но так, чтобы долго не возвращаться.

Исходные данные: есть система регистрации событий. Зарегистрированные данные хранятся в субд FireBird. Естественно, метаданные базы постоянно эволюционируют.

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

Кое-что все же известно:
1) хранящиеся данные модифицироваться этими самыми юзерами не будут никогда;
2) данные нужны как в жидком (скроллируемая табличка), так и в твердом виде (отчет).
3) IBExpert в руки юзерам давать нельзя, тут и обсуждать нечего.

Работа будет выглядеть так: юзер запускает эту чЮдо-программку, вводит логин/пароль; после коннекта юзер видит список доступных видов (например, в стиле а-ля Opera, с табами, ну или еще как).
Если он такой умный, то может создавать новый вид сам, если нет - то: обычный select from... , возможно, с параметрами. Если запрос компилируется и выполняется без ошибок, он запоминается (особая табличка в базе). Полям запроса могут быть в полуавтоматическом режиме (например, на основе описания полей или их доменов) заданы русские алиасы.
Ну, на основе запросов можно сваять FastReport - отчетик (отчетики), а шаблончик(...чики) его(их) также запомнить его специальной табличко.

Если вид стал нерабочим (например, из-за противоречий с новыми метаданными базы), то его можно либо изменить до рабочего состояния (исправив sql - предложение), либо просто "убить".

Вот и все.

Работы вроде немного, но все равно, вопрос: может, кто-нибудь знает что-то похожее готовое?

andreymx...
запросы будут из одной таблицы, или юзвери понимают, что такое джойн?
1. Запросы произвольные. Sql-предложение будет настолько сложным, насколько хитер составитель и насколько его готов "скушать" сервер. Первый этап - ввод sql-предложения просто в виде текста, следующий (возможно) - предоставление интерфейса для подключения какого-нибудь графического QueryBuilder (мне лично - не нужно).

2. Ожидаемая ценность проекта в том числе именно в его доступности и в нулевой коммерческой стоимости. Я вполне понимаю, что практически все делать придется мне самому. Ожидаемая польза - поток критики.

3. Модуль запросов практически готов. Сейчас соображаю, как лучше это все визуализировать. В последнюю очередь будет модуль работы с отчетами. Думал, рабочий вариант будет готов к понедельнику.

MaratIsk, просто шикарно! :) Практически 100% то, что я хотел.

Думаю чуть модифицировать твою служебную структуру: введу для каждого именованного запроса историю версий запроса (то же самое - для хранимых шаблонов отчетов). Чтобы криворукие юзеры могли внести свои кривые изменения, а я бы потом смог легко вернуться к истинной (т.е. верной) версии.

...ну и не стану заморачиваться на мультисерверность. Хотя здорово, конечно.

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

Вопросник...запроса историю версий запроса (то же самое - для хранимых шаблонов отчетов)...
...а также историю версий значений параметров. Это будет рюхно. :)

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

1. Ну, мы же все понимаем, что юзеры будут только смотреть на результаты запросов. Ввел параметры значение параметров, полистал результаты, экспортировал в MS Excel (etc), всё. А запросы придется писать нам . Хотя, для моей задачи юзерами будут другие программеры (проект - "внутренний").

2. "Интерпретатор языка" в генераторе Марата и так присутствует (FastScript).