I think @LOGNAME comes from windows which appears to cache it. We found
after changing the user names a reboot of the server was required to
bring in the updated name. We also have a .bat file which does an: ECHO
%USERNAME% but I don't recall which it returned.
For us the reboot was the easiest fix, if you can't reboot perhaps a
"secedit /refresh" (IIRC) would work?
Hth
Colin Alfke
Calgary Canada
>-----Original Message-----
>From: Eric Neu
>
>Greetings all,
>
>Does anyone here know how UniData on Windows sets @LOGNAME.
>Where/When does it get set? (UniData 6.1, Windows 2003SE)
>
>We've recently undergone a standards enforcement for NT user
>ids and many of my users had their user id changed. When these
>users use a process that checks @LOGNAME (from BASIC) to
>determine who they are their old user id is returned.
>
>I thought perhaps UniData might have stored some trace of the
>old IDs in the user's registry but logging on a new machine
>produces the same result.
>
>I also thought perhaps UniData might cache Windows credentials
>and forcing a password change might trigger an update but that
>didn't help.
>
>I'll try a server reboot after the close of business but if
>that doesn't work I'm not sure what to try next. I have
>considered using
>GETENV('USERNAME') to return the ID I'm expecting (which works
>btw) but that means changing a slew of programs and I'd prefer
>not to do that.
>
>Any information on this would be really helpful.
>
>
>Thank you,
>
>Eric Neu
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/