seg856
Но в этом случае 1) невозможно прописать, кто делал "delete", 2) можно найти только автора последней модификации, а предыдущие авторы не сохраняются.

Аспид
Предложу некоторую альтернативу.
У меня есть таблица - srvMonitor, в которой прописываются все вошедшие (ну и при нормальном выходе, там же пишут о выходе)
В этой талбице, много полезной инфы.
Я не знаю как в Мускуле организовано.
В MS SQL при записи в лог, по SPID, вычисляется действующий id_monitor.
И прописывается ссылка на него.
Описал конечно схематично.
В итоге, можно посмотреть кто удалил, с какого хоста, из какого ПО.

seg856
То есть, чтобы удалить строку из tbl, я в хр. процедуре обновляю поле uu (это ид. пользователя, изменившего таблицу).
При этом в лог life_tbl будет добавлена строка, где x_operation='u'.
Затем я удаляю эту строку из tbl, в life_tbl записывается эта же строка, x_operation='d'.
Так?

seg856
Что такое SPID?

seg856
Какая у Вас еще информация в srvMonitor?

CREATE TABLE [dbo].[svcMonitor](
    [ID_MONITOR] [int] IDENTITY(1,1) NOT NULL,
    [ID_USER] [int] NULL CONSTRAINT [DF_MONITOR_ID_USER]  DEFAULT ((1)),
    [hostname] [varchar](128) NULL,
    [login_time] [datetime] NULL,
    [exit_time] [datetime] NULL,
    [isfail] [smallint] NOT NULL CONSTRAINT [DF_MONITOR_isfail]  DEFAULT ((0)),
    [ismark] [smallint] NOT NULL CONSTRAINT [DF_MONITOR_ismark]  DEFAULT ((0)),
    [app] [varchar](128) NULL,
    [ver] [varchar](20) NULL,
    [spid] [smallint] NULL,
 CONSTRAINT [PK_MONITOR] PRIMARY KEY CLUSTERED 
(
    [ID_MONITOR] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

seg856
Как в триггере записывать значение поля x_usrid (ид. пользователя, произведшего изменения) в таблицу life_tbl?
(Пользователи не совпадают с пользователями mysql)

PaulWist

Что бы при этом в логе не возникали записи с признаком Update, в триггере на Update необходимо проанализировать какая команда DML выполняется, что бы пропустить запись в лог "паразитного" update.

seg856
А как анализировать? Ведь update есть нормальные, если мы изменяем запись. Как отличить "паразитного" от "непаразитного"?

seg856
Если я без использования программы напрямую буду изменять таблицы БД, то никто не узнает, что это происходило, так как строка будет перенесена в лог с ид. пользователя, который раньше что-то делал с таблицей. По логу будет записано, что изменения произвел этот пользователь.

PaulWist
2. Если удаление происходит от ЛЮБОГО логина/пользователя БД, те минуя интерфейс проги и интерфейс БД (те есть права на Delete для юзеров), то остаётся только фиксировать время и хост с которого было выполнено удалние, покольку удаление через другую прогу/провайдера не знает о твоих юзерах НИЧЕГО.

Igor Korolyov

PaulWist
2. Если удаление происходит от ЛЮБОГО логина/пользователя БД, те минуя интерфейс проги и интерфейс БД (те есть права на Delete для юзеров), то остаётся только фиксировать время и хост с которого было выполнено удалние, покольку удаление через другую прогу/провайдера не знает о твоих юзерах НИЧЕГО.

Можно сделать так чтобы триггер не позволял удалить запись, если он не видит этого "пользователя программы". Конечно от пользователя с правами позволяющими отключать или изменять триггер это не поможет, но от "порезанного в правах" - вполне.

Аспид
Предложу некоторую альтернативу.
У меня есть таблица - srvMonitor, в которой прописываются все вошедшие (ну и при нормальном выходе, там же пишут о выходе)
В этой талбице, много полезной инфы.
Я не знаю как в Мускуле организовано.
В MS SQL при записи в лог, по SPID, вычисляется действующий id_monitor.
И прописывается ссылка на него.
Описал конечно схематично.
В итоге, можно посмотреть кто удалил, с какого хоста, из какого ПО.

И поскольку работает триггер на таблицу, не зависит из ХП ты что то делаешь, или правишь из своих каких то, служебных ПО.
(Например в MS SQL - Managment studio, в мускуле таких средств предостаточно)

Гулин Федор
но это ж надо на каждую такую таблицу тригер делать - что достаточно трудозатратно

Igor Korolyov
Такого рода триггера практически всегда генерируются, а не "вручную" пишутся. Поэтому трудоёмкости тут никакой нет.