Это будет почти невозможно сделать в SQL Server 2000, потому что обновление вполне может происходить из переменной, имеющей это значение, или соединения с другой таблицей, которая имеет это значение и не жестко запрограммирована в хранимом процессе, триггер и т. д. Обновление также может происходить из пакета DTS, задания, фрагмента динамического кода, запускаемого приложением, или даже из анализатора запросов, поэтому сам код может нигде не записываться в базе данных.
Возможно, лучшим подходом может быть создание таблицы аудита для рассматриваемой таблицы и запись в нее пользователя и кода из spid, который сгенерировал изменение, а также старых и новых значений. Вам придется подождать, пока это не произойдет снова, но тогда вы точно будете знать, что изменило значение и к какому значению оно будет возвращено, если потребуется.
В качестве альтернативы вы можете запускать профилировщик в системе до тех пор, пока это не произойдет, но профилировщик имеет тенденцию снижать производительность и обычно не является хорошей идеей для запуска в производственной системе. Если это происходит очень часто, это может быть приемлемой альтернативой.
Вот подсказка о том, как вы можете получить некоторую информацию, которую вы хотите для конечного кода триггера, который вы пишете:
create table #temp (eventtype nvarchar (1000), parameters int, eventinfo nvarchar (4000), myspid int)
declare @myspid int
select @myspid =@@spid
insert #temp (eventtype,parameters, eventinfo)
exec ('dbcc inputbuffer (@@spid)')
update #temp
set myspid = @ myspid
выберите имя хоста, имя_программы, eventinfo
от #temp t
присоединиться к sysprocesses s на t.myspid = s.spid
ГДЕ spid = @ myspid