Сценарий: мы создаем записи для запросов, которые должны быть одобрены менеджером.Во время ожидания менеджер меняется (обновляется в течение ночи из кадров HR).Нам нужно обновить запросы, чтобы указать нового менеджера.
Вот сокращенная версия запроса, которую должен сделать это:
update (select grw.approver_user_id, gup.supervisor_id
from gs3.user_role gur
join gsu.user_profile gup
on gur.user_id = gup.user_id
join gs3.request_workflow grw
on gur.user_role_id = grw.user_role_id
and gup.supervisor_id != grw.approver_user_id -- records with new mgr
where grw.auth_status_cd = 'SUBMITTED') -- reapprovals currently open
set grw.approver_id = gup.supervisor_id;
Проблема: учетная запись, выполняющая этот запрос, имеет права только на чтение gsu.user_profile
.
Внутренний select работает нормально и возвращает все строки, которые мне нужно обновить ... но даже если я не обновляю gup.supervisor_id
, мне кажется, что мне нужен доступ для записи в эту таблицу.Если я выполню это как пользователь с правами на запись gsu.user_profile
, обновление будет успешным.
Есть ли логическая причина для этого?Я бы предпочел не предоставлять разрешения учетной записи, которая ему не нужна.
Спасибо!
Обновление
Принятие ответа Томаса ... хотя на самом деле он не отвечает на мой вопрос о том, почему учетной записи, выполняющей объединение обновлений, потребуются полномочия на обновление таблицы, которую он не обновляет, я могусм. логику: «Не используйте объединения обновлений, они не являются стандартом ISO».
Обидно, потому что разница между тем, что у меня есть, и предложением Томаса в том, что нет вложенных выборокв моем.Если кто-нибудь знает стандартный способ выполнения запроса, подобный этому, без вложенных выборок, я бы хотел знать!
Спасибо, Томас!