Subject | RE: [Firebird-Architect] Database triggers |
---|---|
Author | Leyne, Sean |
Post date | 2006-09-19T19:03:42Z |
Ann,
be audited.
So, this is not a application level problem.
rather that all changes made in a transaction to be related to each
other, and that transactions be related back to a database
login/'session'/connection.
Having a trigger fire when a db connection is opened, would allow for a
Session context variable to be set and an entry in a login table to be
created.
Then, having a trigger fire when a transaction is started, would allow
for a Transaction context variable to be set and an entry into a
transaction log table created.
From there, "change logging" triggers on the individual table would be
able to use the "Transaction ID" when posting entries to the audit
tables.
Sean
> Leyne, Sean wrote:SOX requires that all changes, even those processed via database script,
> >
> > SOX tracking of all data changes made in the context of a
> > transaction/session/connection.
> >
>
> OK. Logging? This really feels like an application level
> issue rather than a database issue.
be audited.
So, this is not a application level problem.
> For example, gbak startsIt's not that SOX requires that all transactions be accounted for, but
> a transaction to backup the database. Won't SOX be unhappy
> if it has an unaccountable transaction?
rather that all changes made in a transaction to be related to each
other, and that transactions be related back to a database
login/'session'/connection.
Having a trigger fire when a db connection is opened, would allow for a
Session context variable to be set and an entry in a login table to be
created.
Then, having a trigger fire when a transaction is started, would allow
for a Transaction context variable to be set and an entry into a
transaction log table created.
From there, "change logging" triggers on the individual table would be
able to use the "Transaction ID" when posting entries to the audit
tables.
Sean