views:

27

answers:

2

I have an application which connects to SQL Server 2000 (using a generic SQL Login and SQL Authentication). I would like to implement some logging via triggers to track data changes. I can't use USER_NAME() because that returns the generic account.

I've poked through master..sysprocesses and it doesn't seem to record the username (although it does record the machine name).

Any ideas how, within SQL, to gain access to the username?

(Note: yes, I could pass it in as a variable via the application ... but that would mean I'd have to roll out a new version of the app; I'm trying to do this from within SQL, so I can avoid that, if possible.)

+1  A: 

Have you tried SYSTEM_USER?

SELECT SYSTEM_USER
Alex
Yep. SQL Server Books Online says: "If the current user is logged in to Microsoft® SQL Server™ using Windows Authentication, SYSTEM_USER returns the Windows 2000 or Windows NT 4.0 login identification name, for example, DOMAIN\user_login_name. However, if the current user is logged in to SQL Server using SQL Server Authentication, SYSTEM_USER returns the SQL Server login identification name, for example, sa for a user logged in as sa." So, in this case I'd get the generic login, which isn't desirable.
David T. Macknet
I'm afraid this is not possible through SQL authentication.
Alex
+1  A: 

You can't. Simple. SQL Server has no knowledge of the end user with a SQL login at all

The same applies if you use a proxy (web server etc) too: you don't know the end user. We use parameters/stored procs to pass in the username from the web server.

I would suggest that you set CONTEXT_INFO in the client which persists for that connection.

gbn
That's as I suspected, thanks. Unfortunately for me, alas. I was hoping that somebody had managed it, though, as this answer means that I have to release a new build of several applications to 40+ offices.
David T. Macknet
Funny, though: `master..sysprocesses` does record the machine name, so it knows the source of the connection, just not whatever security authentication information is in place *at* that machine. Seems strange that it wouldn't know who's logged in, because that user must have some privileges in order to establish the connection. So, the user has a valid security token, but SQL Server just ... doesn't pay any attention to it? Odd.
David T. Macknet
David T. Macknet: The NT login token is not attached to the connection because the client specifies "SQL auth". It is just not available. The NT login token is machine independent too: you can have multiple users from one client.
gbn