Steve Atkins wrote:
>Using a temporary table to store that unique token is how I'd do it.
>
>Rather than grovel through the system tables during the trigger I'd do
>all the work at the client session setup. As the first thing, write
>the token into the temporary table. If that fails, create the
>temporary table and retry. Then create the transaction you want to use
>for all the other operations in the session.
>
>
>
Our problem is that we have batch/standalone applications that will not
be using the connection pool (as well as developers that may directly
modify production tables in rare instances). In those cases (heck, all
cases) , the audit triggers themselves (when an update/insert/delete
takes place) have to look to see if a temp table exists to pull the
user data from. It wont exist in tese cases, but the triggers dont know
this.....
