Есть две таблицы:
Table1 из столбцами: Field1, Field2, Field3 .... FieldN
Table2 из такими же столбцами: Field1, Field2, Field3 .... FieldN
У Table2 только одна запись из новыми значениями для одной из многих записей из Table1.


Нужно в Table1 обновить только те столбцы, значение в которых изменились.
Если Table1.Field1 отличается от Table2.Field1, то нужно выполнить
Update Table1 SET Field1 = Table2.Field1
Аналогично для всех остальных столбцов.

Если Table1.Field1 не отличается от Table2.Field1, то UPDATE не должно выполнятся.

Как можно это сделать кроме отдельных IF для каждого поля?
Идеально было бы делать один UPDATE сразу для всех Field, а не по отдельности для каждого.

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

AkinaКак я понимаю, для любой записи из Table2 найдётся куча записей в Table1, которые имеют другое значение Field1. И что, их все обновлять???



ShovgenyukУ Table2 только одна запись из новыми значениями для одной из многих записей из Table1

Поиск ОДНОЙ записи из Table1 которую надо обновлять производится по ключу
WHERE Table1.FieldKey=Table2.FieldKey
Первичный ключ в одном поле FieldKey.

Гигабайт Мегабайтович КилобайтовShovgenyuk,

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

Парралельно надо писать лог: кто, что, когда изменил.
Кроме того, есть некая бизнес-логика, которая определяет кому и при каких условиях можно изменять некоторые поля, а при каких - нельзя.
Сейчас это все на клиенте. Надо перенести всю бизнес-логику на сервер, а клиент будет просто собирать все значения для всех полей и передавать на сервер.

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

alexeyvg,

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

Akina,

Просто вопрос о поиске столбцов которые надо апдейтить, со строками проблем нет :)

alexeyvgЭээ, так если поле не меняется, значит, и апдэйта не было, и право на апдэйт для данной операции данному пользователю не нужно?
Да, именно так.
Если новое значение поля равно старому и на это поле есть ограничение апдейт, то не надо его апдейтить вообще.
Иначе пользователь получит сообщение об ошибке, например "у вас отсутствует разрешение на изменение даты документа" и ответит "так я и не меняю дату, она какая была, такая и остаётся" и будет прав.

TaPaKну, имхо, можно получать изменённые колонки, если прав на них нет - орать, если достаточно, то апдейт всей линии без извращений

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

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

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

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 будет меньше полей) ну и основное - очень существенно уменьшить расход дискового пространства на сохранение истории, так как в истории будут сохранятся только те поля которые изменялись, а не каждый раз все поля.