#sql-server #triggers #ado.net
#sql-сервер #триггеры #ado.net
Вопрос:
У меня неясная проблема с SqlDataAdapter
тем, что таблица данных не заполняется строкой. Сбой происходит только в производственном выпуске.
Он работает на
- Режим отладки на компьютере разработчика
- Режим выпуска на компьютере разработчика
Недавно мы добавили некоторые журналы аудита во все наши таблицы, и у нас есть 2 запускаемых триггера. 1 в самой таблице, которая отправляет копию строки в формате JSON в нашу таблицу журнала аудита. А затем второй триггер для самой таблицы журнала аудита, который выглядит следующим образом:
CREATE or ALTER TRIGGER [dbo].[trg_AuditLog_Insert] ON [dbo].[AuditLog] AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
DECLARE @Qry varchar(255)
SELECT
@Qry = event_info
FROM sys.dm_exec_sessions AS es
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) AS ib
WHERE es.session_id = @@SPID
UPDATE AuditLog
SET
[CallerProc] = @Qry
FROM
AuditLog al
INNER JOIN inserted i on i.AuditLogID=al.AuditLogID
END
По сути, он просто обновляет таблицу AuditLog и сообщает нам, какой SP был запущен, что вызвало обновление любой таблицы аудита.
Если мы отключим этот триггер, то SQLDataAdapater.Fill
метод начнет работать должным образом. По сути, команда SqlCommand, используемая в методе Fill, представляет собой базовую хранимую процедуру, которая проверяет учетные данные для входа. Я добавил некоторую трассировку, и, похоже, все работает нормально. Триггеры работают правильно, команда SQL, похоже, работает правильно, но Datatable просто не заполняется (пока мы не отключим триггер). Приветствуются любые советы.
Комментарии:
1. ..вы проверили важное примечание в разрешениях sys.dm_exec_input_buffer() ? docs.microsoft.com/en-us/sql/relational-databases /… :
2. хорошо … я разберусь с этим. Вполне может быть проблемой? Как ни странно, триггер все еще работает, но, очевидно, он оказывает какое-то влияние на возвращаемые строки
3. Спасибо… это было так … нужно было применить правильные разрешения
Ответ №1:
Хорошо … для тех, кто может столкнуться с этим. Решение состояло в том, чтобы убедиться, что разрешения сервера состояния просмотра были применены для пользователя SQL, используемого в версии выпуска приложения