Передача информации о том, кто удалил запись, на триггер удаления

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

Я могу отслеживать вставки / обновления, включив в поле «Вставить / обновить» поле «Обновлено». Это позволяет триггеру INSERT / UPDATE иметь доступ к полю «UpdatedBy» через inserted.UpdatedBy. Однако с помощью триггера Удалить данные не вставляются / обновляются. Есть ли способ передать информацию на триггер удаления, чтобы он мог знать, кто удалил запись?

Вот триггер вставки / обновления

ALTER TRIGGER [dbo].[trg_MyTable_InsertUpdate] 
ON [dbo].[MyTable]
FOR INSERT, UPDATE
AS  

INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
VALUES (inserted.ID, inserted.LastUpdatedBy)
FROM inserted 

Использование SQL Server 2012

Есть ли способ передать информацию на триггер удаления, чтобы он мог знать, кто удалил запись?

Да: с помощью очень крутой (и недостаточно используемой функции) называется CONTEXT_INFO. По сути, это сессионная память, которая существует во всех областях и не связана транзакциями. Он может использоваться для передачи информации (любая информация - ну, любая, которая помещается в ограниченном пространстве) для триггеров, а также назад и вперед между вызовами sub-proc / EXEC. И я использовал это раньше для точно такой же ситуации.

• Контекстная информация VARBINARY (128)

• Установить с помощью: SET CONTEXT_INFO

• Получить через: CONTEXT_INFO ()

Проверьте следующее, чтобы увидеть, как это работает. Обратите внимание, что я обращаюсь CHAR(128)до CONVERT(VARBINARY(128), ... Это сделано для того, чтобы принудительно заполнить пробел, чтобы было легче преобразовать его обратно VARCHARпри извлечении из него, CONTEXT_INFO()так VARBINARY(128)как он дополнен правой клавишей 0x00s.

SELECT CONTEXT_INFO();
-- Initially = NULL

DECLARE @EncodedUser VARBINARY(128);
SET @EncodedUser = CONVERT(VARBINARY(128),
                            CONVERT(CHAR(128), 'I deleted ALL your records! HA HA!')
                          );
SET CONTEXT_INFO @EncodedUser;

SELECT CONTEXT_INFO() AS [RawContextInfo],
       RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())) AS [DecodedUser];

Результаты:

0x492064656C6574656420414C4C20796F7572207265636F7264732120484120484121202020202020...
I deleted ALL your records! HA HA!

ВМЕСТЕ ВСЕ ВМЕСТЕ:

1. Приложение должно вызвать хранимую процедуру «Удалить», которая передает имя пользователя (или любое другое), которое удаляет запись. Я предполагаю, что это уже используемая модель, поскольку похоже, что вы уже отслеживаете операции вставки и обновления.

2. Хранимая процедура «Удалить» выполняет:

   DECLARE @EncodedUser VARBINARY(128);
   SET @EncodedUser = CONVERT(VARBINARY(128),
                               CONVERT(CHAR(128), @UserName)
                             );
   SET CONTEXT_INFO @EncodedUser;
   
   -- DELETE STUFF HERE

3. Триггер аудита выполняет:

   -- Set the INT value in LEFT (currently 50) to the max size of [UserWhoMadeChanges]
   INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
      SELECT del.ID, COALESCE(
                        LEFT(RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())), 50),
                        '<unknown>')
      FROM DELETED del;

4. Обратите внимание, что, как отметил @SeanGallardy в комментарии, из-за других процедур и / или специальных запросов, удаляющих записи из этой таблицы, возможно, что либо:

   • CONTEXT_INFOне был установлен и все еще NULL:

     По этой причине я обновил выше, INSERT INTO AuditTableчтобы использовать значение COALESCEпо умолчанию. Или, если вы не хотите использовать значение по умолчанию и требовать имя, вы можете сделать что-то похожее на:

     DECLARE @UserName VARCHAR(50); -- set to the size of AuditTable.[UserWhoMadeChanges]
     SET @UserName = LEFT(RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO())), 50);
     
     IF (@UserName IS NULL)
     BEGIN
        ROLLBACK TRAN; -- cancel the DELETE operation
        RAISERROR('Please set UserName via "SET CONTEXT_INFO.." and try again.', 16 ,1);
     END;
     
     -- use @UserName in the INSERT...SELECT

   • CONTEXT_INFOбыло установлено значение, которое не является допустимым именем пользователя и, следовательно, может превышать размер AuditTable.[UserWhoMadeChanges]поля:

     По этой причине я добавил LEFTфункцию, гарантирующую, что все, что было извлечено CONTEXT_INFO, не сломает INSERT. Как отмечено в коде, вам просто нужно установить 50фактический размер UserWhoMadeChangesполя.

ОБНОВЛЕНИЕ ДЛЯ SQL SERVER 2016 И НОВОЕ

SQL Server 2016 добавил улучшенную версию памяти для каждого сеанса: контекст сеанса. Новый контекст сеанса, по сути, представляет собой хэш-таблицу пар ключ-значение с типом «ключ» sysname(т.е. NVARCHAR(128)) и значением «значение» SQL_VARIANT. Смысл:

1. В настоящее время существует разделение ценностей, поэтому вероятность конфликта с другими видами использования ниже.
2. Вы можете хранить различные типы, больше не нужно беспокоиться о странном поведении при возврате значения через CONTEXT_INFO()(подробности см. В моем посте: Почему CONTEXT_INFO () не возвращает точное значение, установленное SET CONTEXT_INFO? )
3. Вы получаете гораздо больше места: максимум 8000 байт на «Значение», до 256 КБ для всех ключей (по сравнению с максимумом 128 байт CONTEXT_INFO)

Для получения дополнительной информации, пожалуйста, смотрите следующие страницы документации:

• sp_set_session_context
• SESSION_CONTEXT

Это невозможно, если только вы не хотите записать идентификатор пользователя сервера SQL, а не один уровень приложения.

Вы можете сделать мягкое удаление, имея столбец с именем DeletedBy и устанавливая его по мере необходимости, тогда ваш триггер обновления может выполнять реальное удаление (или архивировать запись, я обычно избегаю жесткого удаления, где это возможно и разрешено законом), а также обновлять журнал аудита. , Чтобы принудительно выполнить удаление таким образом, определите on deleteтриггер, который вызывает ошибку. Если вы не хотите добавлять столбец в вашу физическую таблицу, вы можете определить представление, которое добавляет столбец и определить instead ofтриггеры для обработки обновления базовой таблицы, но это может быть излишним.

Есть ли способ передать информацию на триггер удаления, чтобы он мог знать, кто удалил запись?

Да, видимо, есть два пути ;-). Если есть какие-либо оговорки в отношении использования, CONTEXT_INFOкак я предложил в моем другом ответе , я просто подумал о другом способе, который имеет более чистое функциональное отделение от другого кода / процессов: использовать локальную временную таблицу.

Имя временной таблицы должно включать имя удаляемой таблицы, поскольку это поможет отделить его от любого другого кода, который может выполняться в том же сеансе. Что-то вроде:
#<TableName>DeleteAudit

Одно из преимуществ использования локальной временной таблицы CONTEXT_INFOзаключается в том, что если кто-то в другом процессе, то есть как-то вызывать этот конкретный процесс «Удалить», просто неправильно использует одно и то же имя временной таблицы, подпроцесс а) создаст новый локальный временная таблица запрошенного имени, которая будет отделена от этой исходной временной таблицы (даже если она имеет то же имя), и б) любые операторы DML для новой локальной временной таблицы в подпроцессе не будут влиять на любые данные в Локальная временная таблица создана здесь в родительском процессе, следовательно, нет перезаписи данных. Конечно, если подпроцесс выдает оператор DML для этого имени временной таблицы, не выдав сначала CREATE TABLE с тем же именем, эти операторы DML будут влиять на данные в этой таблице. НО, на данный момент мы получаем действительнов данном случае, даже в большей степени, чем с вероятностью совпадения вариантов использования CONTEXT_INFO(да, я знаю, что это произошло, поэтому я говорю «крайний случай», а не «это никогда не произойдет»).

1. Приложение должно вызвать хранимую процедуру «Удалить», которая передает имя пользователя (или любое другое), которое удаляет запись. Я предполагаю, что это уже используемая модель, поскольку похоже, что вы уже отслеживаете операции вставки и обновления.

2. Хранимая процедура «Удалить» выполняет:

   CREATE TABLE #MyTableDeleteAudit (UserName VARCHAR(50));
   INSERT INTO #MyTableDeleteAudit (UserName) VALUES (@UserName);
   
   -- DELETE STUFF HERE

3. Триггер аудита выполняет:

   -- Set the datatype and length to be the same as the [UserWhoMadeChanges] field
   DECLARE @UserName VARCHAR(50);
   IF (OBJECT_ID(N'tempdb..#TriggerTestDeleteAudit') IS NOT NULL)
   BEGIN
      SELECT @UserName = UserName
      FROM #TriggerTestDeleteAudit;
   END;
   
   -- catch the following conditions: missing table, no rows in table, or empty row
   IF (@UserName IS NULL OR @UserName NOT LIKE '%[a-z]%')
   BEGIN
     /* -- uncomment if undefined UserName == badness
      ROLLBACK TRAN; -- cancel the DELETE operation
      RAISERROR('Please set UserName via #TriggerTestDeleteAudit and try again.', 16 ,1);
      RETURN; -- exit
     */
     /* -- uncomment if undefined UserName gets default value
      SET @UserName = '<unknown>';
     */
   END;
   
   INSERT INTO AuditTable (IdOfRecordedAffected, UserWhoMadeChanges) 
      SELECT del.ID, @UserName
      FROM DELETED del;

   Я проверил этот код в триггере, и он работает, как ожидалось.