I think I covered conditional compiling way back when some people still had 32-bit and others had 64-bit, because you can use conditional compiling to define your functions and things like that based on the bit version that you're working with in Access. But aside from that, I really haven't done much with it. I do agree that if you want to have certain things in your code only for the developer, then conditional compiling is not a bad idea. But if you want to be able to switch back and forth between developer stuff in any copy of the database, like let's say you're troubleshooting a workstation, then just use a developer password. It's up to you; they're your Legos. But you can keep your gold star! LOL.

I searched for "conditional", and I didn't see anything come up. As stated in our IsDev, I just used the file extension, that you pointed out has some potential problems. I also have other tempvars for other stuff, like how to handle certain debug situations when in developer mode. I saw an ancient video for VBA on these, and it mentioned project wide variables, as being only integer and how to set them up, but I'm not sure it applies to the current VBA7.  In the other person's video, he only shows conditional compile in a subroutine procedure, but I've seen examples at the top of the module before any procedures, so I'm not sure of the implication of that as for scope.

That brings up a real good question about debugging a user's workstation. So far, I've only been working with .accdb. But when I get to distributing an .accde, I'm guessing that you can't get into the VBA or immediate window. So that would make debugging a real pain. So far, when I know it's a known error that the code has encountered, I put the message in the status textbox at the top of forms, but that only helps with known possible errors, not the kind that can drive us nuts, like maybe a RTE from corruption or by "user corruption" (known as monkeying with stuff they shouldn't).