Hi Dave,
Glad to hear my code helped in your project.
Interesting request, I had not considered that option.
I like a challenge so I played with this a bit.
I have met with *some* success.
You'll have to decide if it will work for you.
1. Follow this link:
http://www.mvps.org/access/api/api0015.htm
2. Copy/paste all the code to a new standard module.
Compile the code and save the module as modReadRegFile
3. Open up the unsecured database login form.
Put this code in the Form's Open event:
Me.txtUserName = fReturnRegKeyValue(HKEY_CURRENT_USER,
"Software\Microsoft\Office\8.0\Access\Settings", "Last User")
Make sure that all goes on ONE line!
You will need to adjust this obviously to your machine.
This was on a machine with Access 97 and a default install location.
Your best bet is to navigate down in the Registry hive for the Office/Access install information.
I'm thinking it should be pretty similar to the above, but I am out of the office and cannot test
this on other operating systems/access installations.
Please be careful in the Registry!! Look, but don't touch anything!
4. Compile the code in the form and save/close.
5. Open up the unsecured database and log into the secured database by entering the user name and
password in the text fields.
6. Close the secured database.
7. Open up the unsecured database again and the login form User Name field should display the name
you just used.
Hey, it works!!
But......
Now log in with a different User Name/Password.
Come back to the unsecured database and the login form will still show the first User Name you used.
Hummm....not good.
So, you will have to decide if this will work for you.
Presumably, a user will only be logging into the secured one from their workstation and only be
logging in as themselves. So this *could* work for you. I'm not sure.
There might be a way to write the information to the registry when the secured database starts up
(after a successful login of course), but I have not experimented with that option.
You could also write the value to a table in the unsecured database, but this might not account for
an unsuccessful login. The User Name field would then display an inaccurate name.
Another option *may* be to somehow pass in the User Name to the secured database and then write that
information to a table in the secured one. The unsecured one would read that value (presumably by
creating a temporary workspace) from the secured database and put that in the User Name field. Not
quite sure, however, if that would work. Seems like a lot of extra work to me though just to save
the user a few keystrokes.
Hope that helps,