Tim,

I played a bit around, and saw that you can also use an in-memory table as a "session
variable" table. So no problem about accumulating dead table files.

Works like a charm. Great !

Again, thanks very much !

Heiko

Could gathering a few details from the client side, sending them to the =
server as parameters or when the connection is opened, and saving them =
in a table perhaps help?

Off the top of my head, the following will accurately ID who's who from =
what and where:

System.Diagnostics.Process.GetCurrentProcess().SessionId   Gets the =
session ID for the current user  making the DB call. Must be unique per =
Windows OS, and works with Terminal Services/Citrix. 0 is the console =
session

System.Diagnostics.Process.GetCurrentProcess().Id      Gets the process =
ID of the app making the DB call. Allows you to find out which app is =
calling when multiple launches are allowed

System.Environment.GetEnvironmentVariable("ComputerName")    Gets you =
the PC name. If you're on the same network, you won't have any =
duplicates

System.Environment.GetEnvironmentVariable( "UserName" )        Gets you =
the name of the current user logged into the machine/machine session =
with TS/Citrix. Let's you ID the user regardless of what DB account is =
used in the app.


System.Environment.GetEnvironmentVariable( "LogonServer" )     Gets you =
the name of the machine that authenticated the user. Doubt this has any =
value for what you're describing though.

Could you use the first 4 to accurately ID who's making the updates as a =
parameter to the DB call, have the trigger read the value and update =
your log table? Even something like a "machine name: session id: user =
name: proc id" format for human reading should be 100% accurate with =
finding who did what & when if you add a timestamp value. I'm not sure =
how to update a table when a session closes the connection though.

That's my 2 cents worth.



jr











"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in =
message =
news:23FFAFFE-88D7-41CB-896F-F8C46267525A@news.elevatesoft.com...
> Heiko,
>=20
> << The latter is the problem. I'm using C/S and every client connects =
to the=20
> server as the same EDB user, the user management is done by the =
application.=20
> So only the client knows, which user is logged on at the moment.
>=20
> I can't change that, because I need the ability to change the username =

> while the session stays connected.
>=20
> Can someone think of a way to access my application username from =
inside a=20
> trigger ? >>
>=20
> Hmm, that's a tough one.  Are the user names guaranteed to be unique, =
or=20
> would it be possible to have two different sessions using the same=20
> application-controlled user name ?
>=20
> --=20
> Tim Young
> Elevate Software
> www.elevatesoft.com=20
>=20
>

Heiko,

<< In case of unexpectedly terminated sessions, will the EDB server delete
the temporary table files after a while ? >>

Yes, when a dead session is removed, all temporary tables are automatically
deleted.

--
Tim Young
Elevate Software
www.elevatesoft.com