Informix - capture user ID in delete trigger - asp.net

Question

I have an ASP.NET (C#) web application that connects to Informix 12.x database. The web application uses a database connection string with username and password. Users are given login accounts to use the web application and they can delete records in the database.
The database tables have "LastModifiedBy" which contains the user ID. Now, I need to implement auditing using database triggers. I need to capture what records were updated or deleted and who did it (i.e. logged in user) and save these in an audit table.
For the delete trigger, how can I capture the user ID of the logged in user and save this in the audit table?

Answer 1

The database user (available via the keyword USER) is always going to be the username associated with the shared database credentials. Your question is not very clear, but are you saying the existing LastModifiedBy attribute contains the named user or the database user? If it's the named user, I think you should probably look at your ASP.NET code to see how that gets passed into the UPDATE statement.
I'm no expert on ASP.NET, but assuming a single page request uses the same database connection throughout its processing cycle, then you could maintain a table keyed on the session ID, available via DBINFO('sessionid'), where you capture the named user at the top of the request, and then you have it available at any point throughout the process for inclusion in your audit. But if the web-server processes are using a pool of database connections and any statement could go to a different connection, even that won't work.
Ultimately, I don't think database triggers are the right solution here, not least because you'll have to write and maintain a trigger for every table in your application. If I was faced with this problem I would be more inclined to have a common Audit function within the web-app, where the named user is always available.
At the OP's request, a bit more detail. The Session ID is exactly the same concept as you see in SSMS - just a unique number that identifies the connection.
Imagine you have the following table and procedures:
CREATE TABLE session_user (
sessionid INTEGER NOT NULL,
username VARCHAR(20),
conn_date DATE,
PRIMARY KEY (sessionid)
);
CREATE PROCEDURE set_user(v_username VARCHAR(20))
UPDATE session_user SET username = v_username, conn_date = TODAY
WHERE sessionid = DBINFO('sessionid');
IF DBINFO('sqlca.sqlerrd2') = 0 THEN
INSERT INTO session_user VALUES (DBINFO('sessionid'), v_username, TODAY);
END PROCEDURE;
CREATE PROCEDURE get_user()
DEFINE v_username VARCHAR(20);
SELECT username INTO v_username
FROM session_user
WHERE sessionid = DBINFO('sessionid');
IF v_username IS NULL THEN
LET v_username = USER;
-- return system user if no record found in session_user table
END IF;
RETURN v_username;
END PROCEDURE;
NB: None of this code is tested, it's just to show the principle. I don't have an Informix instance to hand to test this on.
At the top of the request, however you execute your SQL, you would run:
EXECUTE PROCEDURE set_user($the_web_user);
Your triggers could then use get_user() wherever you want to capture that info. You'll get the actual web user if it's been recorded in the session_user table, otherwise the database user (which will be the shared database credentials if the triggering DML has come from the web-app, or the physically logged in user if the trigger is via a DB-Access session).
I still don't think this is a particularly maintainable solution - every table needs its own trigger(s). An OO audit method in the web-app would be a more DRY approach, or have a look at Informix's preexisting audit capabilities.
Note: the date field was included in the session_user table so you run a clean-up over it, because depending on how often new connections get created by the web-app, your session_user table could grow like topsy.