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.....
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
