Sorry, I don't as I haven't seen A2003 yet. Have you tried using the specific number instead of "username"? i.e. =Environ(7) - don't think the actual number is 7 though.
This answer was given by GHudson to another post - credit here goes to Ghudson
The Environ() function works great unless you have the Sandbox mode turned on in
Access 2003. You will need to add this public function to your Access 2003 db's if you
want to continue using the Environ() funciton...
Code:
'This function is used to allow the use of the Environ function in Access 2003
Public Function Environ(Expression)
On Error GoTo Err_Environ
Environ = VBA.Environ(Expression)
Exit_Environ:
Exit Function
Err_Environ:
MsgBox Err.Number & " - " & Err.Description
Resume Exit_Environ
End Function
This is straight from the Access 2003 offline help file...
About Microsoft Jet Expression Service sandbox mode Microsoft Office Access 2003 uses the Microsoft Jet Expression Service to evaluate expressions. The Jet Expression Service can be configured to run in sandbox mode. Sandbox mode is a mode of operaton where only safe expressions can be evaluated.
About unsafe expressions Unsafe expressions contain functions that could be exploited by malicious users to access drives, files, or other resources for which they do not have authorization. If malicious users have access to these resources, then they may be able to perform actions such as deleting all of the files from a folder, tying up a network resource, or modifying a file.
To make your Access databases (MDBs) and projects (ADPs) more resistant to malicious attacks, you should enable sandbox mode. Sandbox mode allows Access to be fully functional while blocking unsafe expressions.
Excellent information posted here chaps thank you! I have been doing some experiments and thought other new users of this function may find my test code helpful:
Code:
Function fTest()
MsgBox "User Name: 40 >>> " & Environ(40)
MsgBox "User Name: 40 >>> " & Environ("UserName")
Debug.Print "User Name: 40 >>> " & Environ(40)
Debug.Print "User Name: 40 >>> " & Environ("UserName")
End Function
Function fFindEnvironCodes()
Dim x As Integer
'For x = 40 To 40
For x = 1 To 100
If x >= 255 Then Exit For 'Causes an error if you exceed 255
Debug.Print x & " >>> " & Environ(x)
Next x
'Highest Code found on my Machine is: 45 >>> windir=C:\WINDOWS
End Function
'To test these codes open the immediate window: >>> control G or "CTRL G" paste in the function
'name either fTest or fFindEnvironCodes
'if you use the function "fTest" notice the results,
'Environ(40)Produces = >>> USERNAME=Tony Hine
'Environ("UserName") = >>> Tony Hine
'as you can see both cases are self documenting! And if you need only the "username" without
'any added text you can get it quite easily.
In the above code I show the use of Environ(40) to return the username. However on another PC, Environ(40) does not return anything! Using the above code to extract the names the numbers relate to, I found that the list did not go above 30 items. And to extract the windows username, you needed a code .... 28 >>> USERNAME=windows user.... So I would strongly recommend Adeptus' recommendation of only allowing particular uses of the environ function and just like he has shown, pre Define them in your software.
I would suggest a slight change to the code above:
Code:
function fGetUserName()
fGetUserName = VBA.Environ("UserName")
end function ' fGetUserName
Or something along the lines of GetWinUserName may be more appropriate.
And I should add, never use the "number" variety as I think you will get unpredictable results on different machines, and possibly the same machine! However I don't know for sure without exploring this further. Will let you know if I discover anything else.
Environ is a pretty resourceful function for obtaining user system settings. Using the numeric arguments can produce different results depending on the users version of Windows. I prefer to use the "text" of the argument like Environ("computername") instead of Environ(8).
The "environvariables.zip" sample I posted in that thread will allow you test the different results you can get with other versions of Windows when you use numeric arguments. Stick with the text argument to ensure you get what you want. Judging by the low number of downloads for my sample I doubt that many folks have seen that thread.
These are variables which are accessible by Name or by Number order.
Where do they come from?
Most of these values are set at startup by the windows login scrips etc, but you can set you own by using the SET command...
e.g.
Code:
SET USERNAME=BINGO
Sandbox Mode?
Why they arn't always safe: You could embed rather nasty commands into an environment variable, for example someone could change their USERNAME variable so that if you used it in an SQL statement it would delete all the users or change the admin password to something of their choice. (Basically the standard SQL injection techniques!)
I didn't realize some of them could be set Programmatically, and I can now see the danger.
I would mention for clarity that this comment:
>>>These are variables which are accessible by Name or by Number order<<<
If you use the number order be aware that this can be different on different machines. Probably safe on your own machine, (I don't know for sure) but you may have problems if your code is transferred to a different machine.
