Настройка видимости столбцов запроса на клиенте

← →
девушка (2009-01-16 14:07) [0]

Добрый день!

При выведении пользователю данных в табличном виде удобно иметь (или очень хочется) следующие возможности:
1. хранить русскоязычные названия полей в БД, чтобы не именовать все в приложении в вручную.
2. создавать эти самые колонки таблицы(TDBGrid) динамически, т.е. знать список и свойства полей формируемого запроса.
3. давать возможность пользователю скрывать/показывать столбцы и сохранить эти настройки в БД.
4. давать возможность пользователю накладывать на запрос определенные (программистом :) ) условия - типа поиска по подстроке и т.д.

Возможностей реализовать это много.

п. 4 можно реализовать а) введением в запрос параметра б) динамическим формированием запроса (б1 - на клиенте, б2 - на сервере)
п.1,2,3 требуют, ИМХО, как минимум, создания в БД таблиы, которая хранит информацию о полях запроса и таблицы с пользовательскими настройками полей.

На данный момент есть следующий вариант решения:
В БД есть таблица с описанием полей запросов (_SQL_FIELDS). Таблица, хранящая пользовательские настройки (_USER_SQL_FIELDS) видимости и колонок таблицы.
Программа формирует SQL запрос, который забирает из БД все поля запроса, а потом, в зависимости от их видимости в _USER_SQL_FIELDS, создаются соответствующие колонки в DBGrid.
Условия на запрос налагаются так:на сервере есть ХП, которая принимает ряд параметров и (в зависимости от назначения запроса) выбирает (case) нужный запрос и подставляет в него параметры.

Описаный метод имеет очевидный недостаток - клиенту передается много не используемых данных.

----
Сразу бы хотелось сказать про выбранный метод формирирования условий запроса.
Динамический SQL я пока отвергаю из-за сложности тестирования, невозможности передавать параметры (?) и необходимости изменять систему прав.
Формирование запроса на клиенте при наличии таблицы списка условий на запрос и частей from и where - вполне работоспособный вариант и туда тоже можно подставлять параметры - но его пока отложила, поскольку понравилось делать выборку с помощью ХП (можно передать параметры, а внутри ХП разрулить правильные они или нет и т.д.).

Впринципе, хотелось бы для выборок данных использовать вызовы ХП.

Как лучше решать такие проблемы?

БД: MS SQL 2005.

← →
Медвежонок Пятачок © (2009-01-16 14:15) [1]

п.1 бессмысленный.

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

← →
девушка (2009-01-16 14:18) [2]

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

Извините, не правильно сформулировала - имелись ввиду не рускоязычные названия полей БД, а кэпшоны колонок грида.

← →
Медвежонок Пятачок © (2009-01-16 14:18) [3]

п. 4 уже реализован а ЕхЛибе, причем легко и изящно в отличие от вышеприведенных соображений

← →
Медвежонок Пятачок © (2009-01-16 14:19) [4]

а кэпшоны колонок грида.

Я про капшены и говорю

← →
девушка (2009-01-16 14:19) [5]

> не хочется именовать колонки по русски в делфи, но готова:

готова к этому более чем к перекомпилящии программы ради смены названия колонок

← →
Медвежонок Пятачок © (2009-01-16 14:21) [6]

Ну а чего тогда говоришь что движет тобой :

1. хранить русскоязычные названия полей в БД, чтобы не именовать все в приложении в вручную.

← →
девушка (2009-01-16 14:24) [7]

> п. 4 уже реализован а ЕхЛибе, причем легко и изящно в отличие
> от вышеприведенных соображений

может быть, но на данный момент для запросов из БД предпочитаю использовать ХП - т.к. проще модифицировать и с распределением прав все прозрачно

← →
Медвежонок Пятачок © (2009-01-16 14:25) [8]

а при чем здесь права?

← →
девушка (2009-01-16 14:26) [9]

> Ну а чего тогда говоришь что движет тобой :
>
> 1. хранить русскоязычные названия полей в БД, чтобы не именовать
> все в приложении в вручную.

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

← →
Медвежонок Пятачок © (2009-01-16 14:27) [10]

Ехлибовский грид дает возможность юзеру уточнить where, которое приводит к сужению выборки установленной в дизайне. А не к расширению этой выборки.
Так что права и sp здесь ни при чем

← →
девушка (2009-01-16 14:28) [11]

> а при чем здесь права?

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

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

← →
Ega23 © (2009-01-16 14:28) [12]

> может быть, но на данный момент для запросов из БД предпочитаю
> использовать ХП

При чём тут ХП или не ХП????

← →
Медвежонок Пятачок © (2009-01-16 14:28) [13]

на самом деле мной движет совсем иное

А. Понятно. Удачи.

← →
Sergey13 © (2009-01-16 14:29) [14]

> [0] девушка (16.01.09 14:07)

А что за программа? Я к тому, что ИМХО, то что выводится пользователю он ДОЛЖЕН видеть, даже если ему кажется, что это ему как бы не нужно. А посему, ИМХО опять же, заниматься подобными рющечками - только БЕСПОЛЕЗНО загружать и усложнять программу. По крайней мере для большОй части программ.

← →
Медвежонок Пятачок © (2009-01-16 14:29) [15]

Оно блондинко.

← →
девушка (2009-01-16 14:30) [16]

> Ехлибовский грид дает возможность юзеру уточнить where,
> которое приводит к сужению выборки установленной в дизайне.
> А не к расширению этой выборки.
> Так что права и sp здесь ни при чем

имеется ввиду фильтрация данных на клиенте?

← →
Медвежонок Пятачок © (2009-01-16 14:31) [17]

имеется ввиду фильтрация данных на клиенте?

where - это на клиенте?

← →
девушка (2009-01-16 14:35) [18]

> А что за программа? Я к тому, что ИМХО, то что выводится
> пользователю он ДОЛЖЕН видеть, даже если ему кажется, что
> это ему как бы не нужно. А посему, ИМХО опять же, заниматься
> подобными рющечками - только БЕСПОЛЕЗНО загружать и усложнять
> программу. По крайней мере для большОй части программ.

Что нужно видеть пользователю пока окончательно не определено.
Т.е. он может в любой момент потребовать еще пару-тройку столбцов вывести и переназвать попросить.

На данный момент реализован функционал с затаскиванием всех полей выборки и пометкой их на видимость.

> Оно блондинко.

Оно в печали просто

> [18] девушка (16.01.09 14:35)
> Что нужно видеть пользователю пока окончательно не определено.

Это как это? А что прога будет делать определено? А как же вы проектируете БД, что не знаете что нужно пользователю?

create procedure test
@p_....
@p_....
@p_columns varchar(max) out
as
select * from test
set @p_columns = "col1=кол1" + chr(13)+chr(10) + "col2=кол2"+......

и в афтер опен пройтись по филдам

пишется "универсальный решатель задач и всего остального"

Бессмысленны все пункты, кроме 4-го (это я по своему печальному опыту говорю, тоже, в свое время развлекался подобием словаря данных) - польза от таких усложнений не стоит потраченной работы.
Что касается запрета на показ/отображения столбцов, то это делается легко и просто (равно как и сохранение порядка и размера столбцов) в том же EhLib-е. Правда до хранения этого безобразия в базе никто пока не додумался, а все хранится там, где запускается (на компьютере пользователя, в реестре или в ini-файле)

Медвежонок Пятачок © (16.01.09 14:45) [21]

> пишется "универсальный решатель задач и всего остального"

Он уже написан. Давно

Он уже написан. Давно

девушка видимо хочет свой персональный.
с перламутровыми пуговицами.

>1. хранить русскоязычные названия полей в БД, чтобы не именовать все в приложении в вручную.

Если сервер позволяет хранить описатели колонок, то можно табличные названия хранить там же, например отделяя их запятой от полного названия. При открытии датасета считывать из метаданных заголовки и присваивать их соотв. свойтсвам филдов.
Хотя в общем случае затея гнилая, т.к. неизвестно что делать с запросами из нескольких таблиц, а также с вычисляемыми полями. В целом затея гнилая ИМХО.
Отображаемые в сетках табличные данные - суть чисто клиентская фича, он и должен ею заниматься.

>2. создавать эти самые колонки таблицы(TDBGrid) динамически, т.е. знать список и свойства полей формируемого запроса.

Колонки и так создаются динамически при открытии НД. Также как и список и свойства полей. Правда с типом полей в некоторых случаях могут быть траблы. Например, АДО децимальные поля может интерпретировать как BCD, причем с потерей значности

>3. давать возможность пользователю скрывать/показывать столбцы и сохранить эти настройки в >БД.

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

Я использую иную технологию: отображаются не все поля датасета, а некоторые "основные", но при этом есть Stay-on-top форма (показываемая или прятаемая по желанию пользователя), отображающая полную информацию о текущей строке. На ней же управление отображением или прятанием колонок (например, если нужно посортировать по некторому полю, в данный момент в сетке не представленному). Сохранение же в файл не деляется.

>4. давать возможность пользователю накладывать на запрос определенные (программистом :) ) >условия - типа поиска по подстроке и т.д.

Надо написать универсальную формочку, в которой пользователь сможет указывать произвольный фильтр и использовать ее. Иногда удобно сохранять и восстанавливать при запуске последний фильтр (например чтобы при появлении окна не было пустой сетки или, наоборот, 10-минутного ожидания пока вытянется вся инфа). Однако здесь те же траблы, что и при запоминаниии вида грида.

В целом советую посмотреть как подобные вещи реализуются в качественных профессиональных приложениях.

Настройка видимости столбцов запроса на клиенте Найти похожие ветки