До гемороя додумался потому что надо перенести логику с клиента на сервер.
Сейчас на клиенте анализируется старое значение и новое значение отдельных полей и если выполнены определённые правила, то выполняется апдейт.
Задолбался я клиент переписывать и всё время добавлять/изменять эти правила для каждого поля.
Вот и возникла идея оставить клиенту функцию сугубо сбора данных и пересылки их на сервер, а всем остальным должен заниматься сервер.
Самый важный плюс: изменение логики на сервере без переписывания и переустановки клиента.

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

asdorЯ б отдал это на клиента, и просто, на клиенте не давал менять.

Так сейчас и есть, но переписывать клиент и переустанавливать на сотнях ПК раз в неделю или две недели - напряжно и уже достало.

iapЧто мешает на клиенте формировать запрос на основе данных
из системных таблиц относительно прав доступа к полям таблицы?
А на сервере можно апдейтить только записи, в которых что-то изменилось,
например, в триггере INSTEAD OF UPDATE.
Переписывать клиента в этом случае не придётся.

Вопрос не только в правах доступа. Основное - это бизнес логика. тригеры не используються. Апдейт происходит в SP

Владислав КолосовShovgenyuk,

бред бредович, а не "идея". Вы всерьез верите, что сервер каждое поле обновляет отдельной операцией? Уменьшите слегка нагрузку на журнал, не более того.

Вы хотите сказать, что для сервера:
Update T1 SET Field1=10, Field2=20, Field3=30 .... FieldN=1000 WHERE FieldKey=1

одно и тоже, что

Update T1 SET Field1=10 WHERE FieldKey=1
Update T1 SET Field2=20 WHERE FieldKey=1
Update T1 SET Field3=30 WHERE FieldKey=1
...
Update T1 SET FieldN=1000 WHERE FieldKey=1

?

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

О новых полях клиент не знает. Речь идёт пока что только о существующих полях. Хотя планируется и динамическое формирование форм для ввода на клиенте. Это тоже не проблемма. Есть метаданные и можна сформировать на формах ввода в клиенте динамические элементы и динамически асоциировать из из полями таблиц.

Опишу саму идея подробнее.

Клиент занимаеться только сбором данных и пересылкой их на сервер.
Сервер получает данные из клиента и записівает их во временную таблицу с неким GUID, анализирует права доступа и бизнес-логику. При необходимости формирует специальную "анкету" для клиента которая представляет собой ХML-документ из упомянутым GUID, предупреждениями, уточняющими вопросами, сообщениями для клиента.
Клиент отображает ХML-анкету и отвечает на вопросы типа "вы уверены, что надо изменить номер документа" да/нет;
"вы подтверждаете и берете на себя ответственность что в данном документе есть пометка - срочно выполнить!" да,подтверждаю/нет;
"уточните кто дал разрешение исполнить это без очереди..." ФИО...
и т.д.
Или же ХML-анкета содержит сообщения о недопустимости апдейта по причинам отсутсвия доступа или чего-то другого...

Клиент заполняе анкету и отправляет на сервер.
Сервер ищет по упомянутому GUID первоначальные данные во временной таблице и сопоставляет их из ответами в енкете, анализирует и апдейтит или не апдейтит о чём отдаёт ответ клиенту.

Плюс должна быть удобная история всех изменений.

asdorShovgenyukпропущено...


Вы хотите сказать, что для сервера:
Update T1 SET Field1=10, Field2=20, Field3=30 .... FieldN=1000 WHERE FieldKey=1

одно и тоже, что

Update T1 SET Field1=10 WHERE FieldKey=1
Update T1 SET Field2=20 WHERE FieldKey=1
Update T1 SET Field3=30 WHERE FieldKey=1
...
Update T1 SET FieldN=1000 WHERE FieldKey=1

?

Конечно же нет)))
В первом случае 1 запрос, во втором N запросов)))
Ну так я как раз и пытаюсь сделать так что бы был один запрос-первый случай.

Владислав КолосовShovgenyuk,

судя по задаче, Вам нужно повернуть поля анкеты вертикально, превратить в пары "ключ-значение".

Да, нужно, но не все поля. Кроме того мне нужно повернуть вертикально поля для истории изменений что бы потом показать клиенту кто, что и когда изменил в документе. Должна получится таблица в первой колонке которой перечень полей (атрибутов) , а во всех остальных колонках значения этих атрибутов. Количество остальных колонок должно быть равно количеству изменений (Update'ов).
При этом в таблице (в первой колонке) должны быть только те поля, которые когда либо изменялись (не все).

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