Доступ к имени триггерной/родительской таблицы внутри триггера SQLCLR

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

Триггер SQL CLR — получить исходную таблицу

И я обновлю этот ответ, когда мое решение будет очищено и опубликовано.

ОДНАКО, хотя вы говорите, что это будет применено только к нескольким таблицам, имейте в виду, что триггеры выполняются в контексте транзакции, которую выполняет оператор DML (или даже DDL). является частью. Это имеет два следствия:

1. чем дольше работает триггер, тем дольше выполняется операция DML/DDL, следовательно, тем дольше удерживаются блокировки объекта(ов). Это может отрицательно сказаться на параллелизме/производительности. Многие нервничают, связывая операторы DML/DDL с вызовами веб-сервисов к локальным (внутрисетевым/в той же сети) сервисам, но через Интернет в процесс, который должен быть довольно простым, вносится опасный, сильно варьирующийся риск. Конечно, если вы используете виртуальную машину Azure или управляемый экземпляр Azure SQL, то, возможно, задержка будет достаточно низкой, чтобы это было «достаточно безопасным». В любом случае, будьте очень осторожны! (Для ясности: этот риск не снижается при использовании триггера T-SQL для выполнения хранимой процедуры SQLCLR; это все та же транзакция)
2. если триггер не работает / выдает ошибку, по умолчанию это прерывает транзакцию и откатывает операцию DML (или DDL). Это предполагаемое поведение? Обычно сбой в регистрации события не должен прерывать саму операцию, верно? Поэтому вам, вероятно, придется проглотить ошибку (или, по крайней мере, записать ее в текстовый файл).

Вы должны иметь возможность отделить операцию DML/DLL от части ведения журнала, настроив Service Broker для обработки вызова службы ведения журнала. В этом случае вы бы:

1. Use a T-SQL trigger
   1. get the table name via:

      SELECT tab.[name]
      FROM   sys.objects tab
      WHERE  tab.[object_id] = (
                        SELECT trg.[parent_object_id]
                        FROM sys.objects trg
                        WHERE  trg.[object_id] = @@PROCID
                               );
      

   2. Соберите любую другую информацию для журнала, возможную из таблиц INSERTED и/или DELETED (после этого у вас не будет доступа к ним; хотя вы, возможно, можете переупаковать данные в этих двух таблицах в виде XML для отправки как часть сообщения Service Broker -- например, SELECT * FROM inserted FOR XML RAW('ins'); )
   3. Поставить в очередь сообщение для Service Broker, включая собранную информацию
2. Use Service Broker
   1. will handle messages asynchronously from DML / DLL operations
   2. может выполнять хранимую процедуру SQLCLR, передавая информацию, собранную в триггере T-SQL, для вызова службы ведения журнала (будь то внутренняя или внешняя сеть)

Имейте в виду (поскольку вы упомянули получение затронутого значения PK из таблиц INSERTED и DELETED), что в этих таблицах может быть несколько строк, если операция DML затрагивала несколько строк (т. е. никогда не предполагала одну строку для операций DML). ).