SqlDataAdapater.Fill(DataTable) не возвращает строки

#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, используемого в версии выпуска приложения