I like your approach and instruction, MichaelRed

. Have a star!
You're right; the environment in which I'm currently working *is* small, and the databases aren't ever used by more than about 10 people at a time at this company.
I'm curious about the particular security breach problems you mention, with respect to mapped drives. What are they, please?
I like your idea of a flashing indicator to keep in my mind, and make it *easy* to check, the fact that I'm working with dummy data

. The alternating color approach is a nice simple one; for the benefit of others, I'll say that I presume you use the Timer event and TimerInterval property to initiate the flashing, just setting the TimerInterval back to 0 if/when you want it to stop flashing (or just want the computer to stop wasting time processing it if it won't be seen anyway). I think I'll use the idea by dropping a separate tiny pop-up form in the corner, if the user is one of our admins and the linked tables' actual "directory of residence" isn't the live data directory. (...or maybe I could use a toolbar, so it could be docked in a permanent place out of the way of other forms ... I'll get to learn about menu bars and cool bars and those things now, Yay :-D !...)
I get the general idea as you describe your URL-based approach, but I would appreciate more explicit explanation of the details. This might be relevant to my questions here: I use Access 97 and haven't had opportunity/reason to develop much for Access 2000 yet.
First, just how do you link through a URL? Do you simply enter a URL in the 'Link' dialog box prompting for a source table? I suspect the answer is yes; I just tested using the file:// notation, which worked, and I presume that http:// would work just as well if I had any databases in a folder set up as a web-space.
Second, if I read your description correctly, you have two sets of tables linked all the time; and your command button simply renames each set of "local tables" (the links, not the actual source tables) when you click it. In this way, your code and table/field references never need to change; the single set of names simply refers to different sets of tables, depending on your need (and clicking of the command button in response to that need ;-) ). So my question: Does the button code have to close all the objects that refer to the tables before the renaming? How "invisible" is the change when you make it (not that it has to be too invisible for administrators)? This simple one-click on-the-fly table swap seems like one of those useful ideas that one is very glad to have had suggested

! (I don't suppose that having extra links (linked tables) in the database costs much of either storage or performance?)
You mention another function: copying data to a third separate test database, for testing with specific/current data. Do you maintain three sets of links, then? Wouldn't it be easier to copy the data to the test tables you already use? I'm certainly conceding that I may not have understood something. It's why I ask questions <bright smile>. Indeed, anytime there has been a table-design change (renamed fields, changed field types, etc.), I make a new copy of my whole "Data Storage" database(s), so that the structure matches (including relationships). So, it seems to me that a "switch links between live and test data" button and a "replace test tables with fresh copies of live tables" button are called for. The latter button would, I think, do the job of your "second button" without need for a third database or set of tables. (...unless your test databases contain only certain specific data for testing purposes...)
Thanks for the lessons and ideas!