Программист-ЛюбительПри этом можно встроить в источники данных разграничения по ролям.У меня в клиенте sql нет вообще, все обращение через процедуры. Соответственно, если нужны будут разные where для разных ролей - буду в ХП либо писать if и возвращать разные курсоры, либо склеивать запрос динамически, либо использовать or в одном запросе - в зависимости от требований производительности.

Программист-ЛюбительПри отображении сложных данных, имеющих определенную внутреннюю структуру, очень полезно использовать соответствующий контрол - тривью, аутлинер, т.п. Пример: очень многие системы хранят в каталоге организаций отношение парент-чаилд (дочерняя/зависимая фирма, холдинг и входящие в него компании и т.п.). Среди учетных систем финансового толка мне пока не попадались такие, где эта информация отображалась наглядно в виде дерева.TcxTreeList - и колонки, и дерево.

Программист-ЛюбительОбязательно должен быть "мгновенный поиск". По мере набора текста в наборе данных должна позиционироваться запись, содержащая данный текст. Выглядит элементарно, но очень эффективно при поиске информации. Для этого же образца должна быть не менее мгновенная фильтрация набора.Это есть, прикладываю скрин. Поиск в отдельной строке - на самом деле фильтрация на клиенте, в лукап-комбо работает такая же (строится такое же выражение по отдельным словам). В самом гриде уже в каждой колонке есть инкрементальный поиск.

Программист-ЛюбительЧто касается фильтров. Формально, если в наборе есть поля из справочников, программистам очень просто сделать выбор по справочникам. Можно добавить пукт <Все> к перечислению из справочника. Но при практической работе фильты в понятиях бизнес-терминов обычно охватывают несколько полей, или вообще представляют собой сложные выражения для секции WHERE. Я считаю что такие и нужно иметь возможность конфигурировать для табличной формы. Как простейший частный случай перекрывают возможности простого фильтра - перечисления из справочника.Да, это интересный способ, приму на вооружение. Я обычно делал для такого отдельные параметры.

SlalomПосмотрите в сторону Oracle APEX - очень грамотно все сделано. Можно много почерпнуть для своих поделок.Спасибо, посмотрю.

П-ЛУ меня очень похожий визуальный построитель SQL WHERE условий, только используется он в "проверочных отчетах" - для контроля качества данных. К условиям для фильтров я себе такую штуку прикручивать не стал.Нет, это работает в обратном направлении. Пользователь набирает в строке поиска куски слов, я (в коде) формирую простое условие, грид по нему фильтрует. То, что показано на скрине - редактор фильтра самого грида, пользователь обычно туда не лезет.

Еще думаю добавить кнопку для быстрого добавления условия фильтрации "текущее поле=текущему значению".

Еще забавно, что клиенту в общем-то совсем без разницы, на сервере ли БД лежит логика или на сервере приложений. Ему достаточно получать данные для отображения и вызывать процедуры с параметрами. Т.е. в перспективе можно переложить логику в среднее звено, сделать клиента в браузере, или научить этого же клиента работать через tcp/ip (т.е. не только в интрасети) не с БД а с промежуточным сервером, который может выполнять процедуры хоть в БД хоть в AppServer.