Кто-нибудь уже решал подобную задачу в Access ADP? - форма строится на хранимой процедуре, процедура возвращает переменный набор полей в результируещем рекордсете. Мне нужно реализовать в существующем приложении возможность добавлять Custom Fields к любому бизнес объекту, причем эти Custom Fields могут быть text, boolean, Datatime, ValueList

Например пользователь может решить что в существюющей системе помимо прочих данных о Customer ему до зарезу необходимо так же поле CreditCardNumber - text, CreditCardType - ValueList (Visa, MasterCard etc) и Approve - boolean

Все это он добавляем в Settings для Customer - после чего эту инфу нужно видеть в табличной форме CustomerList (хорошо что форму не нужно днлать editable - редактирование будет осуществляться в колумарной форме на одну запись)


Эту функциональность я реализовывал в ASP.NET приложение год назад, теперь вот начальство захотело добавить такую фичу в существующее Access приложение. Что и как делать на серверной части- проблем нет, а вот с GUI -

пока у меня одна мысль - добавлять в форму скажем 10 несвязанных полей, при открытии проверять а если CustomFields в результирующем рекордсете , связывать пустые контролы, а ненужные прятать.

Неужели никому эта тема не интересна? :)

АлексейКтема интересна, токо нафиг такая самодеятельность

один наклепает тысячу ненужных полей
другой погрохает ...

Жизнь ваще страшная штука, ты знаешь чем она заканчивается? :)

А если серьезно,представь что ты создаешь систему не для одного заказчика - с которым все ясно и прозрачно (и то не всегда). А для многих и многих - и каждый хочет вести свой бизнес чуть чуть по-своему. И возможность это "чуть чуть" предоставить потенциальному заказчику без дополнительных затрат на custom development - и есть флексабилити (гибкость) которая существенно помогает сделать потенциального заказчика просто заказчиком.

Вот описание http://rpmsoftware.com/rpm/feature.php?a=Fields

А теперь подумай о таких общих системах как Issue Tracking Management, Change Control Management, Process& Project Management - все это было реализовано в рамках одной системы и легко настраивается под большинство запросов заказчиков. Если кто-нибудь видел StarTeam - идея была взята оттуда. Представь, в существующей системе ты можешь сам добавлять нужные для тебя поля (CustomFields) , видеть их в гриде, редактировать, фильтровать информацию по ним, делать поиск. Причем без обращений к фирме разработчику (и без дополнительных затрат) :)

HummerНа форму помещаем рамку подчинённой формы - в её источнике указываем временную табличку с этими полями...

подчиненная форма с источником данных но без контролов (количество и тип которых заранее не известны) - это интересный подход :)

Витал Глянь здесь. М.б. это выход (или вход)

Спасибо, я никогда флексгрид не использовал, возможно это выход

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


Я думаю, я должнен немного прояснить как это все организовано.
Самое основное - пользователь не изменяет структуры данных.

Итак, создается сервисная таблица
ObjectType (ObjectTypeID int, ObjectTypeName varchar...) , для каждой бизнес сущности в эту тоблицу заносится запись и присваивается ID типа
например (5, "customer"). Тогда любой объект в системе можно будет задать парой значений - ObjectTypeID, ObjectSpecificID -это будет ПК записи в соответствующей таблице, например пара значение (5,1130) - ссылается на кастомера с первичным ключом 1130

Далее создаем таблицу CustomField -
CustomFieldID int ПК,
FieldName,
FieldType (например 1 - текст, 2 число,3 дата и т.д.)
ObjectTypeID - определяет какому типу объектов это поле принажлежит,
TabOrder - порядок среди других полей для данного типа объектов

Далее создаем таблицу CustomFieldValue
CustomFieldValue PK
CustomFieldID
Value
ObjectSpecificID - а тут мы храним ключ конкретного объекта, которому и принадлежит это значение customField

То есть, если мы для нашего типа Customer создаем 3 кастом поля - то в таблице CustomField будет 3 записи с ObjectTypeID=5
Когда же мы начнем присваивать значения этим кастом полям для конкретного кастомера - будут создаваться записи в таблице CustomFieldValue

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

Пример выше сильно упрощен и сокращен дабы показать идею, на самом деле там еще есть списки значений, ссылочные типы на бизнес объекты в системе, система безопасности когда кастом полям назначается уровень доступа, группы кастом полей - когда по определенному условию такая група может быть видимой или скрытой и всякое такое прочее