Thanks for the response Wendell.
The answer to your first question is; I'd like to... I think. Right now I have separate Access file for DEV, TEST, and PROD environments. The challenge I was experiencing, and looking for a way to solve, elegantly, amounts to version management and migrating changes though the environments. I'm a Access developer out of necessity not by profession (although I think I might be discovering my calling :-)). I don't have very well developed version and environment management practices, yet...
I've actually created a form (password protected) with buttons which pass a sever/instance & database name to a function which links the tables to the selected environment. It works fine but I don't know if it actually makes sense from an operational perspective since structural differences in the DB may not align with the functionality in the Access file.
I already had a table called "Version" in my database with a float value in a single column which I set manually and then check for on the load of my main menu. If the version number is different than what the form is expecting the user is driven to an internal web page to download the proper version of the Access file. I added a computed column to that table with the value of @@SERVERNAME.
I created a subroutine which can be called from the OnLoad event of each form which sets the caption of a label and also changes the backcolor of the form. Seems to work quite nicely, but, since this required a DB change to add the computed column to my Version table, I can't actually test this until I migrate my DB changes through the environments. If there were a way to call the @@SERVERNAME SQL variable directly rather than from a table via DLOOKUP then I wouldn't have to change the structure of my Version table.