Ambiguous Name
By Richard Rost
2 months ago
Fix Ambiguous Name Errors & Find Duplicate Procedures In this video, we will talk about the "ambiguous name detected" error in Microsoft Access and what causes it, especially when working with VBA code. I will show you how having duplicate procedure names can lead to this issue, how to track down conflicting names using the Find tool and debug - compile, and ways to resolve it by renaming or changing procedure scope. We will also cover tips to prevent this error, especially when copying code from different sources. Priya from Wellington, New Zealand (a Gold Member) asks: How can I fix the "ambiguous name detected" error in Microsoft Access after copying a module into my database, and is this caused by something I did when pasting the code or do I need to change a setting in Access? PrerequisitesLinksRecommended Courses
Keywords TechHelp Access, ambiguous name detected, VBA error, duplicate subroutine, duplicate function, code module conflict, status function, debug compile, find duplicate code, public vs private procedure, variable scope, procedure visibility, code backup, AccessLearningZone
Subscribe to Ambiguous Name
Get notifications when this page is updated
Intro In this video, we will talk about the "ambiguous name detected" error in Microsoft Access and what causes it, especially when working with VBA code. I will show you how having duplicate procedure names can lead to this issue, how to track down conflicting names using the Find tool and debug - compile, and ways to resolve it by renaming or changing procedure scope. We will also cover tips to prevent this error, especially when copying code from different sources.Transcript If Microsoft Access suddenly throws "ambiguous name detected" at you, it means you have two different things named the same and VBA can't tell which one you meant.
Hey folks, welcome to another TechHelp video brought to you by AccessLearningZone.com. I am your instructor Richard Rost. Today we are going to talk about that error message "ambiguous name detected," what it really means, and how to track it down fast.
Most of the time, it is something simple like you forgot you already used that name somewhere else. And yes, sometimes that's a tax you pay for copying random code off the internet and just pasting it into your database willy-nilly. You are guilty. I know it. And it could even be something that you copied and pasted from my code vault. I don't know.
Before we get started today, there are a couple of prerequisites. First, this is a VBA developer-level video. So if you have never done any VBA programming before, go watch this video. It will teach you everything you need to know to get started in about 20 minutes. You should also know how to compile your database. Debug - compile once in a while. These are both free videos. They're on my website. They're on my YouTube channel. Go watch those and then come back.
Today's question comes from Priya in Wellington, New Zealand, one of my gold members. Priya says, how can I fix the ambiguous name detected after copying one of your modules (blame me) into my Access database? I am working on a database at work. We use it to track service requests and equipment. I grabbed one of the code modules from one of your templates because I wanted to add a little status message feature like you showed - the dreaded status box. But now, when I try to run the database, I get an error that says "ambiguous name detected" and it won't let me do anything.
I am not really a programmer. My first thought was maybe the code I copied has a problem in it, but I copied it exactly the way it was. I have got other code in my database already and it worked fine before I added this. Is this something I did wrong when I copied it over or is there a setting I am missing in Access to get it to work?
Well, ambiguous name is basically that. You have got two different things, probably two different subroutines in the database, that are named exactly the same and Access can't tell which one you are referring to. Think of it like yelling, "Hey, Mike," and you have six different Mikes in the office and they all turn around and they go, "Huh? Which one?"
In fact, funny story. My name - I am Richard Rost Jr. and my father is Senior and of course I had to continue it, so my son is the third. The funny thing is when we all get together at family gatherings and they go, "Hey, Richard," we can all ignore the person because "Oh, I thought you were talking to my dad," or "Oh, I thought you were..." That's kind of funny, but that's an ambiguous name. We all have the same first, middle, and last names, nothing to differentiate. So I use that suffix.
Now you mentioned you copied something from my code, but I am assuming the culprit is probably your status function. This comes up constantly. If you copy and paste code from templates from the internet, from my code vault, another template, whatever, if you have already got something called status and then you paste in another module that also has something called status, it is going to cause the problem.
Now, if both of them are public, which means they're visible from anywhere in your VBA project, then when you call status, VBA throws up its hands. It says, "Which one? First status module or me?" It reminds me of that scene from "A Night at the Roxbury," where they're like, "You, him, me, you, him. Me, him." So instead of guessing, VBA just throws up its hands and says, "I don't know which one you are talking about."
Let's take a look. I get this, by the way, all the time from people who copy my stuff and they have also copied stuff off of this website and then they copy stuff off of that website and they've got a bunch of stuff that they don't understand, and they just drop it all in an Access database and wonder why it doesn't work.
So here we are. This is my TechHelp free template. That's a free database. Download it if you want to. Down here, I have a global module. If I look down here, I have a global module. This is a database-level module, and in here, I have a sub called status. It just displays a message on this box right here. That is all status does. I have a whole separate video on it. Watch it if you want to learn more about this.
Let's say, in addition to that, I copied some new module from the web or from the code vault. So I am going to go to create and then module, and this is a new module. In here, I say "Public Sub Status(S as String)" and then this one just message boxes S. OK. So here is a new status function. Save this new module. Close this down.
This button here calls the status function to just display "hello world" right there. That is all this guy does. If you take a peek here, design view. Click, build event. It is "status hello world." OK. Save it. Close it. Now we open up the main menu.
Now as soon as I click on this button, there it is. "Ambiguous name detected: status." It has no idea what you are talking about because there are two of them. Which one do I use? This will break your code. It is going to sit here; you have to hit "Stop" up top here, reset.
Now, if you hit debug - compile, which you should always do whenever you put new code in your database (and of course, make sure you are backing everything up too), if you are copying stuff off the web, even my site, back up your database first. I have a whole slide - where is the slide for that? Oh, that's very important. There it is. Back up your database before you copy stuff from the web, or my website, or anybody's website, or even make any changes. You should be having a nice nightly backup.
But if you do a debug - compile, even so, it will say "ambiguous name detected." So when you put any new code in your database, run that debug - compile. It will point out any problems - anything you didn't copy right, any syntax errors, that kind of stuff.
Now how do you find the other one? If you have got a whole bunch of code in here and you can't figure out where it is, well, we can do a database-level find. All you have to do is hit Ctrl+F. That will bring up the find window. There it is. Now it has got status. The default is current module. That only looks in this module. Current procedure means that's the procedure that you are in. A procedure is either a subroutine or a function. They look the same pretty much except for the word sub or function. The default is this whole window. Project is your entire database - that's what we want to use.
Then "select the text" is like just search inside here, for example. We want to go "Current Project," find next. It did not find it; notice how this bounces around. Find next again. Oh, there it is. There's the other one.
Now you can pick which one you want. Let's rename this guy. If it's not crazy and complicated, call this one "Status2." OK. Then save that. Then if you click the button, now the original status function works.
Another similar situation that comes up with people a lot is that... OK, let's get rid of this new module. We do not need this anymore. We're done with you. Another thing is that sometimes people make another status function in a form and do not realize why this one isn't working. For example, if you come in here, design view, right-click, build event. In here, you have a private subroutine called status, "S as string", and this one just message boxes S instead of using the status box.
Now let's say in your order button, instead of this, let's say here we are going to status "Hi there." OK. But you forgot you have this one up here. So you are thinking it is going to use the status box on the main menu, but this all compiles all nicely and fine. You click the button and you get that. Why is that? Well, because modules that are in the form (the form module, they call it), the code behind this form and all of its buttons, will take priority over any database-level modules. So this status function will never get called from that form unless you call it by its full name.
Just like form controls have a full name - right? This would be "Forms!CustomerF!FirstName." You can call this guy by "GlobalMod.Status." So if you want to come back into this form here, design view, right-click, build event, you have a status here but you do not want to use that one. You can come down here and say "GlobalMod.Status." All right. Save it. Debug - compile once in a while. Close it. Then hit the order button. Oh, it is back there. By the way, it is ignoring its own status function, using the global one. That is a little bit more of an advanced tip.
If you had that other module, you could also make that one private, but then it is only able to be called by other stuff in that module. So if you have a status that is used by that module a lot, just make it private instead of public, and then the rest of the database will not see it but everything in its own module will still use it. I have a whole separate video on scope, variable scope, and all that stuff, and that explains it in a lot more detail.
Real quick, while I have your attention, hit that like and subscribe button for me. It helps me out a lot. Thanks.
To wrap it up, a couple of tips here. First, do not use overly generic procedure names. Do not have a sub called "Date." There are some reserved words you can't use, but simple ones like temp, process, update, status... I know I called mine status, but mine's the boss. Mine's the big one. So you can't use "Status;" I have already used it.
Make sure new code won't collide with existing code. Get in the habit of hitting debug - compile once in a while. I even put it in my merch store on a mouse pad. There it is right there. See it? Debug - compile once in a while. It's on there. "Ambiguous name detected" is one of those scary-looking errors, but it's really just a two-minute fix once you know what it means.
Here is another good video for you to watch if you want to learn more about variable scope and visibility, who can see what in your database, public, private, all that stuff. If you like this kind of stuff, if you like learning with me, if you like my teaching style, come and check out my developer lessons. I just released Developer Level 51, so there is tons and tons of stuff on my website for you to learn from. Here is the link. I will put a link down below you can click on.
So let's wrap this up.
Remember, "ambiguous name detected" is VBA's way of saying, "Hey, you have got two different things with the same name and I do not know which one you mean." Most of the time, it happens when you accidentally duplicated a sub or a function (also called a procedure) somewhere in your database, especially when both of them are public, because public procedures are visible project-wide, database-wide.
Best way to track it down: debug - compile, use your find with the current project option to search for the name it is complaining about. Once you find the duplicate, it is usually simple to fix. Just rename one of them, delete the one you do not need, or change one of them to private if you need to.
If you have been copying code from different templates, from different random internet sources, even from my code vault, remember, always back up your database first and always compile right after adding the new code.
As always, post your comment down below and let me know what you thought of today's video and how you plan to use this in your database.
That is going to do it folks. That is your TechHelp video for today brought to you by AccessLearningZone.com. I hope you learned something. Live long and prosper, my friends. I'll see you next time.Quiz Q1. What does the "ambiguous name detected" error in Microsoft Access VBA usually mean?
A. You have two different things with the same name and VBA cannot determine which one you mean
B. You have a syntax error in your code
C. Your database is corrupt and needs to be repaired
D. Your VBA project has too many modules
Q2. What is a common cause of the "ambiguous name detected" error after copying code from the internet?
A. Having too many records in your table
B. Copying a procedure with a name already in use in your database
C. Forgetting to save your database
D. Not compacting and repairing your database
Q3. If two public procedures with the same name exist in different modules, what will happen when you call that procedure?
A. VBA will ask you which one you want to use
B. VBA will pick the first one it finds
C. Access will throw the "ambiguous name detected" error
D. The form-level procedure will always override
Q4. Which tool should you use in the VBA editor to search for duplicate procedure names across your entire database?
A. Single Module Find
B. Ctrl+H (Replace)
C. Project-level Find (Ctrl+F, Current Project option)
D. Debug.Print
Q5. What is the best practice before copying and pasting new code from the web into your Access database?
A. Make sure your database is open in edit mode
B. Back up your database
C. Change all public procedures to private
D. Remove all previous modules
Q6. When should you use the "Debug - Compile" action in the VBA editor?
A. Only after making table changes
B. After adding new code or making changes to your modules
C. Once a year
D. Only before splitting your database
Q7. If you want a procedure to only be visible to other code within the same module, what keyword should you use?
A. Public
B. Static
C. Private
D. Global
Q8. What happens if a procedure in a form's module and a public procedure in a standard module share the same name and you call that name from a button on the form?
A. The public procedure in the standard module is called
B. VBA throws an error
C. The form module's procedure takes priority
D. Both procedures are called
Q9. How can you specify which module's procedure you want to use when procedures have the same name?
A. Use the module name as a prefix (e.g., GlobalMod.Status)
B. It's impossible to specify
C. Change the procedure to static
D. Use a reserved keyword
Q10. What could be an effective way to resolve an "ambiguous name detected" error if you need to keep both procedures?
A. Rename one of the procedures
B. Make both procedures private in their respective modules
C. Delete all other code in your database
D. Both A and B
Q11. Why is it not recommended to use overly generic procedure names like "Date" or "Status"?
A. Because they are too long
B. Because they can conflict with reserved words or other common code
C. Because VBA compiles slower
D. Because Access will only recognize the first letter
Q12. What is a good habit to form when working with VBA code in Access to help catch errors early?
A. Run Debug - Compile regularly
B. Only write code in lowercase
C. Never use subroutines
D. Use only built-in Access macros
Answers: 1-A; 2-B; 3-C; 4-C; 5-B; 6-B; 7-C; 8-C; 9-A; 10-D; 11-B; 12-A
DISCLAIMER: Quiz questions are AI generated. If you find any that are wrong, don't make sense, or aren't related to the video topic at hand, then please post a comment and let me know. Thanks.Summary Today's video from Access Learning Zone focuses on troubleshooting the "ambiguous name detected" error in Microsoft Access VBA. As your instructor, I want to explain what this error really means, why it happens, and show you some reliable methods for finding and fixing the issue quickly.
When Access throws the "ambiguous name detected" error, it signals that two or more procedures or objects in your VBA code share the same name, so VBA cannot determine which one you intended to use. This is a common situation, especially if you frequently copy and paste code from various sources, like templates, code vaults, or even directly from my own examples. This tends to happen when people add functionality by bringing in code without first making sure those names do not already exist elsewhere in their database.
Before tackling this topic, I recommend you have some understanding of VBA and know how to compile your database from the Debug menu. If you are brand new to VBA, be sure to watch my intro videos first; they are available both on my website and my YouTube channel.
This issue was brought up by a student who copied one of my code modules into her Access database to add a status message feature. After adding the code, the database refused to run and reported the "ambiguous name detected" error. The question she posed is a very common one: Is the problem in the code, or is some setting in Access to blame?
Fundamentally, the error is caused by having two different procedures (often subroutines or functions) with the same name. VBA cannot determine which one to use when you call the procedure. For example, if you have a function called Status in one module and copy-paste another Status function from somewhere else, VBA sees both as available and raises this error rather than guessing which one you want.
To demonstrate, let me describe an example using my free TechHelp template database. Imagine it includes a global module at the database level, with a public sub called Status designed simply to display a message. If, after that, you copy in another module that also contains a public sub called Status, now there are two procedures with the same name, both accessible from anywhere in your project. When you attempt to use Status, Access cannot decide which one you mean and stops the code, flagging the ambiguous name error.
You will most likely notice this right away when running the project, but if you are unsure where the duplicate might be, there are efficient ways to track it down. One of the best habits you can develop is using Debug – Compile after adding new code or making changes. This will often point immediately to errors, including ambiguous naming.
If you do not know where the duplicate is, use Access's Find feature. Press Ctrl+F in the VBA editor to bring up the Find window. Set your search option to "Current Project" to check the entire database for the procedure name. This method swiftly locates every instance, allowing you to review and resolve the duplicates.
When you spot the duplicate procedures, choose whether to rename one of them, remove something you do not need, or, if appropriate, set one of the procedures to Private so it is only available within that module. Changing a procedure from Public to Private prevents it from being visible across the entire database, reducing the risk of ambiguity.
Another nuanced situation involves procedures defined in both a database-level module and a form's code module. Keep in mind that if a private sub with the same name exists in your form, calling that procedure from the form will always run the local one, not the global one, unless you explicitly specify the module. For instance, you can reference the correct one by using the full module name, like GlobalMod.Status. This technique helps you use the correct version of the procedure if you intend to call the global one rather than the local duplicate.
Scope is an essential concept here. If you find yourself needing a procedure to be accessed only inside certain modules, define it as Private to keep things safe and organized. For a deeper discussion on scope and visibility in VBA, I recommend watching my dedicated video on the subject.
Here are some best practices to prevent this issue in the future. Avoid naming your procedures with overly generic names, like Date, Update, Status, or Temp. While some words are reserved and cannot be used, others may not be, but are still likely to create conflicts in larger projects. Always back up your database before copying or inserting significant pieces of code from outside sources. Get into the routine of compiling your project using Debug – Compile after any substantial change.
In summary, the "ambiguous name detected" error is just Access's way of telling you that duplicate names have made it impossible for VBA to know which piece of code to use. Most of the time, it is a quick fix: find the duplicates using search, then either rename, remove, or set one of the procedures to Private as needed. Always compile and back up your database to stay on the safe side when working with new code from different templates or sources.
You can find a complete video tutorial with step-by-step instructions on everything discussed here on my website at the link below. Live long and prosper, my friends.Topic List Understanding the "ambiguous name detected" error in Access VBA
Identifying causes of ambiguous name errors in VBA
Demonstration of error using duplicate procedure names
Using Debug - Compile to find duplicate procedures
Performing a database-wide search for procedure names
Differences between public and private procedures
Resolving ambiguous names by renaming or deleting procedures
Form module code precedence over global modules
Calling global module procedures explicitly from forms
Changing procedure visibility to private to avoid conflicts
Best practices for avoiding ambiguous names in VBA
Backing up databases before importing new codeArticle If you are working with Microsoft Access and you suddenly see the error "ambiguous name detected," it means that your VBA project contains two procedures—either functions or subroutines—with exactly the same name, and Access can no longer tell which one you intend to use. This is a common problem, especially if you are copying and pasting code from different sources or templates, and it can be confusing until you know what to look for.
Consider this as if you were in an office and yelled, "Hey, Mike!" but there are six different Mikes in the room. Everybody turns around, but no one is quite sure who you wanted. Access, when it sees two or more procedures with the same name, reacts in a similar way—it is unsure which one you want, so it refuses to proceed and throws the error.
The most common way this happens is by copying modules that contain procedures with simple, generic names like "Status" into your database. If your project already has a subroutine or function named "Status," and then you add another one (perhaps from some code you found online or from a different database template), Access will get confused any time you try to use that name. This often happens with helpful functions like status message routines or similarly titled, commonly-used subs.
Say you already have a module with a procedure like this:
Public Sub Status(S As String)
' display message in your custom status box
End Sub
Now imagine you copy in a new module, and it happens to have the following code:
Public Sub Status(S As String)
MsgBox S
End Sub
You save both. Now, when you try to use the Status function—maybe by wiring a button to call Status "Hello World"—Access doesn't know which Status function you mean. Both are declared as Public, so they are available throughout the entire project. When you click the button, Access throws the error "ambiguous name detected: status," and your code stops running until you resolve the conflict.
To fix this, you need to find both versions of the procedure. The easiest way is to open the VBA editor (press Alt+F11 in Access) and use the Find command (Ctrl+F). Enter the name it is complaining about, in this case "Status." In the Find dialog, set the search option to "Current Project" to search through all your modules, not just the current one. Go through the results and see where Status is defined. If you find two or more subs or functions with the same name, you need to resolve the duplication.
You can resolve the issue in one of several ways. The simplest is to rename one of the procedures to something unique. For example, you might rename one sub to "Status2." Another option is to delete the duplicate if you no longer need it. If the duplicate is only meant to be called inside its own module and nowhere else, you can mark it as Private instead of Public:
Private Sub Status(S As String)
' code here
End Sub
By making a procedure Private, it is visible only inside its own module and is not accessible from forms, reports, or other modules. This can often resolve ambiguity if only one version needs to be accessed from the whole project.
There is another twist to this issue. Sometimes, you might have a procedure with the same name stored behind a Form module and another procedure of the same name stored in a global module. Here is an example you might encounter. Suppose you have a global module called GlobalMod containing your main Status procedure, and then you accidentally add another procedure called Status within a Form's code module. The code in the Form module will always take priority if you call Status from inside that Form, regardless of whether you want to use the global one or not. If you intend to use the global version, you need to qualify it by its module name, such as GlobalMod.Status "message".
If you want to check your code for such errors before they become a problem, always use Debug > Compile from the VBA editor whenever you add new code to your database. This forces Access to check for errors in your project, including duplicated and ambiguous names, syntax problems, and other issues.
A helpful tip is to avoid generic, commonly used procedure names in your projects. Names like "Date," "Temp," "Update," or "Status" are easy to collide with code you might copy in the future, and some of these also conflict with VBA's own built-in keywords. Always favor more descriptive names, especially for procedures with wide or public scope.
Backing up your database before adding new code is also a great habit. Whenever you're copying code from the web or different templates, make a copy of your database first so you can quickly restore it if something gets mixed up by duplicate names or other errors.
To recap, "ambiguous name detected" simply means you have more than one routine in your database with the exact same name, and VBA cannot decide which to use. Find the procedures using Ctrl+F in the VBA editor with "Current Project" selected, rename or delete extras as needed, and compile your code to make sure everything works. By understanding and resolving ambiguous name errors, you keep your Access applications working smoothly and avoid headaches down the road. |
