Метки записи: |
Приветствую коллеги!
довольно часто приходится сталкиваться с проблемами связанными с ограничениями накладываемыми на вычисляемые поля источников данных и CustomSQL колонок в сервисах SelectQuery
Для первого: не работает сортировка и фильтрация (причем методика сортировки источников данных отвязанных от БД уже отработана на MemoryDataset, н увы не работает в стандартных датасетах, возможно есть какие-либо технические сложности для реализации, но это же топик пожеланий?. Верно?:) )
Для второго: сортировка благо работает, но увы... не работают фильтры, в целом, не понятно почему. Для этого есть объективные причины? Наверняка клиент сумел бы сгенерировать запрос к БД вида
Комментарии
Насчет фильтров по CustomSQL-колонкам можно добавить, что начиная с версии 3.2.0 существует тип фильтра CustomSQLFilter, в котором разработчик может указать произвольный SQL-текст условия фильтрации.
P.S. Существует некоторое количество типов запросов и приемов выборки данных, которые не позволяет реализовать SelectQuery, это вполне естественно (система задумана для поддержки трех СУБД, отсюда ограничения). В таких сложных случаях самое лучшее - реализовать обработку данных в хранимой процедуре, а результат сохранять в промежуточной таблице, из которой затем легко прочитать данные обычным SelectQuery.
Желаю успехов!
Спасибо за ответ!
Возникли дополнительные вопросы/уточнения. Есть возможность пользоваться быстрыми фильтрами при использовании CustomSQL колонок?
Благо до текущего момента не приходилось сталкиваться с такой выборкой которую можно было бы сделать только хранимой процедурой (особенно с нововведениями SQL Server 2005). Поэтому в "сложных" запросах на мой взгляд всё-таки есть более привлекательный и удобный манёвр - оформить запрос во View и затем описать получившееся представление как таблицу в terrasoft. Основное приимущество - не надо городить код который вызывает хранимую процедуру, читает из получившейся таблицы, ну нужно разруливать конкурентный доступ.
Даже если нельзя уложиться в один скалярный запрос можно воспользоваться табличной функцией, которую вызвать из вью :)
Это всё к тому, что приходится таки делать вьюшку, т.к. хотят "быстрый фильтр"...
А делать вью и прочее - долго, не удобно, разработчики же тоже люди :)
PS: Наверняка для быстрого фильтра достаточно поддерживать SQL конструкцию приведенную в первом посте, а её поддерживают даже самые примитивные из современных СУБД.
К сожалению, концепция быстрого фильтра такова, что он работает только с полями таблицы, и не работает для вычисляемых полей и полей, полученных из колонок CustomSQL.
Основная причина этого - DataGrid при наложении быстрого фильтра формирует новое условие в SelectQuery набора данных, которое поддерживает только обращение к физически существующим полям таблицы. Кстати, быстрый фильтр - исключительно встроенная в ядро возможность, управлять ею программно из конфигурации пока не удается.
В Вашем случае создание view на уровне базы - самое оптимальное решение, которое позволит Вам, помимо всего прочего, использовать быстрый фильтр в реестрах.