Name AutoCorrect
By Richard Rost
4 hours ago
Why I Turn Off Name AutoCorrect in Microsoft Access In this lesson, we explore the Name AutoCorrect feature in Microsoft Access, discussing what it does, what it does not do, and why many experienced developers recommend turning it off. I will show you how Name AutoCorrect attempts to update references when you rename tables or fields, but also explain its limitations, especially with VBA code, object dependencies, and performance concerns. We will walk through the relevant Access settings and compare different expert perspectives on Name AutoCorrect so you can decide whether to rely on this feature or manage changes manually as your database projects grow more complex. Darren from St. Louis, Missouri (a Gold Member) asks: I watched your Quick Queries video where you mentioned turning off Name AutoCorrect, and now I'm confused. I've been using Access at work for years and just assumed that feature was helping me. If it updates things when I rename fields and tables, why would I want to turn it off? Am I causing problems in my database without realizing it? Links
Keywords TechHelp Access, Name AutoCorrect, turn off Name AutoCorrect, Access developer tips, Object Dependencies, Track Name AutoCorrect Info, Perform Name AutoCorrect, Log Name AutoCorrect Changes, VBA issues, field rename problems, AutoCorrupt, Access best practices, database maintenance, dependency info
Intro In this lesson, we explore the Name AutoCorrect feature in Microsoft Access, discussing what it does, what it does not do, and why many experienced developers recommend turning it off. I will show you how Name AutoCorrect attempts to update references when you rename tables or fields, but also explain its limitations, especially with VBA code, object dependencies, and performance concerns. We will walk through the relevant Access settings and compare different expert perspectives on Name AutoCorrect so you can decide whether to rely on this feature or manage changes manually as your database projects grow more complex.Transcript There are a handful of Microsoft Access features that I turn off almost immediately when I create a new database. Name AutoCorrect is one of them. Welcome to another TechHelp video brought to you by AccessLearningZone.com. I am your instructor Richard Rost.
Now, I know the feature sounds great. Rename a field, rename a table, Access automatically fixes everything for you. What's not to love? Well, as we are about to see, it fixes some things, misses other things, and can leave you with a false sense of confidence that everything was updated correctly.
Today's question comes from Darren in St. Louis, Missouri, one of my Gold members. Darren says, I watched your Quick Queries video where you mentioned turning off Name AutoCorrect and now I'm confused. I have been using Access at work for years and just assumed that feature was helping me. If it updates things when I rename fields and tables, why would I want to turn it off? Am I causing problems in my database without realizing it?
Darren, that's a great question and after I did Quick Queries 85 I mentioned it briefly. After that, several people asked me to explain why I recommend turning it off. So today we are going to take a closer look at exactly what it does, what it doesn't do, and why most experienced Access developers disable it.
In a nutshell, Name AutoCorrect is one of those features that can seem really helpful when you are first getting started with Access. You rename a table or a field and Access tries to automatically update the queries and the forms and the other objects that use it. Sounds great. But if you are building a simple database without a lot of advanced features, it works just fine.
But once you start getting into VBA code, event procedures, form references, referencing fields from other forms, more complex applications, all those kinds of things, stuff can start slipping through the cracks. Access may update some things but not others, which can leave you scratching your head later trying to figure out what broke.
So let's take a closer look at exactly what Name AutoCorrect does, what it doesn't do, and why I recommend turning it off once you pass the absolute beginner stage.
All right, here I am in my TechHelp Free Template. You can grab a copy of this database off my website if you would like to, but you can go into any database, go into File, go to Options, go to Current Database, scroll down a little bit, where are you? Right down here, Name AutoCorrect options. You will see three different options in here.
Now what is Name AutoCorrect? The idea is simple. Let's say you have got a table with a field named Customer Since. Later you decide that you want it to be Customer Start Date. Name AutoCorrect is supposed to track those changes and automatically update references throughout your database. All the queries, forms, reports, other controls, anything that depends on that field.
It sounds great. Honestly, I think Microsoft added this feature with good intentions, but I also think it is one of those features that causes more problems than it solves down the line. It is kind of like Multi-Valued Fields or Attachments. You know how I feel about those things if you watch my videos for any length of time.
Those features sound really convenient when you're first learning Access. Oh, I can store multiple values in one field instead of having to build a relational combo box. Or I can store files right in my database. I can drop Word documents and PDFs in. Sounds great. But after you have been building databases for a while, you realize why experienced developers avoid those things like the plague.
Name AutoCorrect falls into that same category for me. If you want to find out more about why I hate Multi-Valued Fields or Attachments, then watch these two videos. I have put links to them down below. I have a whole page on my website about things in Access that you should not use. I call it my Evil Access Stuff. You should never use things that are frowned upon and some other stuff. Check it out.
In here, you have got your Name AutoCorrect options. You have got Track Name AutoCorrect Info, Perform Name AutoCorrect, and Log Name AutoCorrect Changes. Think of these as a hierarchy.
Track is the master switch. Perform depends on Track. If you turn off Track, then you do not get that one. Log depends on both of the others.
Track Name AutoCorrect Info tells Access to keep track of relationships between the objects in your database. Microsoft refers to this as maintaining dependency information or name maps behind the scenes. Access keeps track of which forms use which tables, which reports use which queries, which objects depend on other objects. That information is required if Access is going to attempt automatic updates later.
The downside is that all of that information has to be maintained. That means extra overhead, more work for Access, a slightly larger database, and it is just one more thing happening behind the scenes.
Then you have got Perform Name AutoCorrect. This is the setting that actually tries to fix things, to actually rename a field, rename a query, rename a table, or whatever. Access attempts to update references automatically. This is the feature that most people think of when they hear Name AutoCorrect.
Then, finally, you have Log Name AutoCorrect Changes. That is the option that actually creates a log of changes that Access makes automatically.
Now before we get into playing with this, one thing that does rely on this, if you use it at all, is the Object Dependencies. I do not talk much about these because I do not use them much myself. But if you open a table, let's say a customer table here, when you go up to Database Tools, Object Dependencies, it will tell you what other objects depend on that table. This is maintained by that other stuff.
Of course, if you want to learn more about Object Dependencies, I have a whole video on it. But this uses the same dependency information that Name AutoCorrect maintains. If you are someone who uses Object Dependencies all the time, that is one argument for leaving the tracking feature enabled. Personally, I almost never use it.
Let's do a little demo of exactly what Name AutoCorrect does. Let's say we have got a customer table. Here is my customer table. In my customer table, I have got a bunch of fields. One of them is called Customer Since. That is when the customer's record was established. They have been a customer since 2004, for example.
Now in the customer form, I have a Customer Since field, a Customer Since text box. If I go into Design View and take a peek at it, open it up, here are the properties. Let's go to All. The name of the box itself, let me slide this over here, the name of this text box is Customer Since. The control source or the field that it's bound to in the underlying table is Customer Since as well. They are both the same thing. They do not have to be, but they are. That is the default. Most forms are built like that.
Now, if I go into the table, go to Design View, and I change Customer Since, let's call this Customer Start Date or whatever you want to call it. Save it. Close it. Let's open up the form again. Customer Since is still there. It is still working. But let's see what Name AutoCorrect did. You can see right here, it has Customer Start Date in it. Open up the properties and look what happened. It changed the control source to Customer Start Date because it knows that it is bound to that field in the table.
The box itself is still called Customer Since. So it does not change the names of controls. Most of the time, if you have other fields dependent on this one and they are pointing to Customer Since, that is fine as long as Customer Since stays the same, everything will still work. It can sometimes get confusing because now two different things are associated with this text box, but there is nothing wrong with that.
Where you really start to run into problems is with VBA code. For example, I have a button here that opens up my order form. If you look at the code inside that button, it is DoCmd.OpenForm "OrderF". OrderF is the name of the form. CustomerID is the name of the customer ID field. Now, if you were to Name AutoCorrect CustomerID to something else, Access does not change that. It does not change your VBA code.
If I rename the order form, let me show you. If I rename the order form, watch this. If I come in here and find the order form, let's rename it. Let's call it OrderForm. Looks fine. Everything is good. You can open it up. It still works. But if I go into my customer form and try to use that button now, the name OrderF is misspelled or refers to a form that does not exist. Name AutoCorrect does not go through your VBA code.
Now imagine this in a real application where you have hundreds of controls, thousands of lines of VBA. You have recordsets. You have DLookup functions. You have SQL statements. Name AutoCorrect does not go through all of that and magically fix everything for you.
Now, Microsoft did specifically document that VBA code is not automatically updated. They warn developers about this. But again, this is one of those things that when you start off at a beginner level, it seems like it is okay. But then once you get into SQL, once you get into VBA, once you get into DLookup statements, now you start to see the problem if you rely on Name AutoCorrect.
Sometimes you make a little change. You do not realize that Name AutoCorrect helped you out but did not fix some button, and now some button is not working that people rely on. Now it is Monday at 9:15 AM and you are getting a dozen emails that say your database is not working.
That is why I do not trust it. It gives you a false sense of security. The problem is that it misses things. The problem is that it fixes just enough things to make you think everything was fixed. Some forms still open, some queries still run, the database appears to work. Then three weeks later, you find a button on some hidden form somewhere that does not work. Now you have a ton of emails to fix the database.
So how do you fix it? Again, File, Options, Current Database. This is current database, so you will have to do this with every new database that you create. If you have a couple, you have to do it in each one.
If you are like me and you generally start new database projects from an existing template, like I use my TechHelp Free Template for almost everything that I build, if you turn it off in your template, it will be off. Once you do that, it is OK. It has to do some stuff. Depending on the size of your database, it could take a few minutes. This is a tiny database, so it will not take a few minutes.
Notice now, if I do go into Object Dependencies, it says in order to generate object dependencies, Track Name AutoCorrect must be turned on. It is going to try to get you to turn it back on. Do not turn it back on.
My recommendation is to turn them all off, especially if you are writing VBA, you are writing SQL, you are building applications for other people. If you are at the developer level, turn them off.
Now, if you are an absolute beginner working on small personal databases, sure, it might help you occasionally. But just like Multi-Valued Fields and Attachments and all that other stuff, I would rather you learn the right habits from the beginning.
When you rename something, update your queries, check your forms, check your reports, check your VBA. You could do a global search and replace if you need to. Well, global search to find stuff. Be very careful with global replace. I have made that mistake many times myself. Do not do a find and replace and do a replace all. Do it intentionally, test your application. Do not rely on Access to guess what you meant. Just check that stuff yourself.
Now to be fair, not every Access developer agrees with me on this topic. Whenever I do a video, I always Google search and see what else other people have to say about it. One of the people I come across a lot is Colin Riddington. He is an Access MVP, very respected member of the Access community. I will put a link to this page down below in the description under the video.
Colin's position is basically that Name AutoCorrect works fine if you understand how it works and understand its limitations. In fact, he has written that he has used it extensively for years without any major issues. Honestly, I understand where he is coming from. If you know exactly what the feature does and exactly what it does not do and you are careful about how you use it, then yes, you can absolutely make it work.
This is where I respectfully disagree. For me, the fact that I have to understand dependency maps and logging tables and propagation behavior and unsupported objects and all the other caveats is exactly why I do not want to use it. I would rather just search my database, check my forms, check my reports, check my VBA and be done with it.
I think the irony is that this feature was created to make things easier, but the more I learned about how it works, the less interested I became in using it. If I have to remember what gets updated, what does not get updated, which objects are supported and which are not supported, when changes get propagated and where I might still have broken references, it is not saving me any work. It is just giving me another thing to worry about.
I would rather just know that I have to go through and make those changes myself instead of remembering what Access does and does not do. I think at some point the feature becomes more complicated than the problem it is trying to solve. For me, renaming a field and then spending a couple of minutes checking my database is simpler than relying on a feature that only updates some things and then expects me to remember everything it missed.
That is why, even though I understand Colin's position and I think it is completely valid, I still do not like Name AutoCorrect or AutoCorrupt, as some people call it.
Personally, I am of the mindset usually that if I have to rename a field and a table that I know has been around for 10 years, I just leave it. I just deal with it. I have still got fields named in my database that I named 20 years ago that I am not touching, that break a lot of my own rules, like with spaces in the field names, because I just do not want to deal with all the propagations in the SQL and the VBA I would have to fix.
Also, in my searching of the Googles, if we go back a little further in Access history, we will find a very well known Access developer named Allen Browne. If you have been around Access for any length of time, you probably have heard of Allen. He was one of the most respected experts in the Access world and his website was required reading for a lot of us back in the day.
Allen wrote an article about Name AutoCorrect back in the early 2000s. To be fair, that article is over 20 years old and Microsoft has improved the feature a lot since then. His recommendation was pretty simple. Turn it off. Just turn it off. His article goes through a long list of issues, limitations, performance concerns and things that Name AutoCorrect either did not handle correctly or did not handle at all.
Again, some of these specific problems have been improved over the years. But one of his biggest criticisms is still true today. It is the thing I have been talking the most about. Name AutoCorrect does not fix everything. It does not update VBA code. It does not magically understand every reference in your application. That is the heart of my argument too.
So while Colin says, understand the limitations and use it correctly, Allen basically says, just turn the thing off. I find myself closer to Allen's side of the fence. Not because the feature is broken, it just does not provide enough benefit to justify the complexity that it introduces. For me, it is one more thing running behind the scenes that I do not need.
All right, so the big takeaway today is that Name AutoCorrect sounds like a helpful feature, but it does not update everything. That is what makes it dangerous. I would rather spend a few minutes checking my database myself than spend hours later tracking down weird bugs caused by half-completed updates.
Post a comment down below. Let me know if you leave Name AutoCorrect on or if you are in the turn-it-off-immediately camp like me. Either way, that is going to be your TechHelp video for today, brought to you by AccessLearningZone.com.
I hope you learned something. Live long and prosper, my friends. I will see you next time.Quiz Q1. What is the main purpose of the Name AutoCorrect feature in Microsoft Access?
A. To automatically update references when tables or fields are renamed
B. To correct spelling errors in field names
C. To increase the performance of large databases
D. To prevent accidental deletion of objects
Q2. Which of the following scenarios is MOST LIKELY to cause problems if you rely on Name AutoCorrect?
A. Working with simple databases with no code or complex references
B. Using advanced VBA code and SQL within your Access application
C. Creating single-table forms only
D. Importing data from Excel each day
Q3. Name AutoCorrect does NOT update which of the following?
A. VBA code and SQL statements
B. Control sources in form text boxes
C. Queries built with the Access query designer
D. Report record sources
Q4. What is required in order for Access to display Object Dependencies?
A. Track Name AutoCorrect Info must be enabled
B. Perform Name AutoCorrect must be enabled
C. Log Name AutoCorrect Changes must be enabled
D. All Name AutoCorrect features must be disabled
Q5. According to the video, why do experienced Access developers generally turn off Name AutoCorrect?
A. It misses some references, giving a false sense of security
B. It makes databases run slower
C. It compresses the database size
D. It completely removes deleted tables from all objects
Q6. What is the relationship between "Track Name AutoCorrect Info" and "Perform Name AutoCorrect"?
A. Track is the master switch needed for Perform to work
B. Perform is needed for Track to work
C. They are independent features
D. Both must be off for Object Dependencies to work
Q7. If you turn off Name AutoCorrect in your database template, what is the result for new databases created from that template?
A. Name AutoCorrect will be off in all new databases
B. Name AutoCorrect will automatically turn on with new databases
C. It will only be off for reports, not tables
D. Each new database must be configured manually
Q8. What is one reason mentioned for leaving Name AutoCorrect on?
A. If you rely on the Object Dependencies feature
B. If you want faster searches
C. If you only use macros, not VBA
D. If you want Access to encrypt your database
Q9. What is a major risk of relying on Name AutoCorrect for field or object renaming?
A. Only some objects are updated, causing hidden problems later
B. It deletes related data in other tables
C. It breaks all linked tables
D. It prevents any future updates
Q10. What is the recommended workflow when you need to rename a field or table in Access, especially for more complex databases?
A. Manually update queries, forms, reports, and VBA code
B. Trust Name AutoCorrect to make all changes
C. Export and re-import the database after renaming
D. Delete and recreate all related objects
Q11. Which is NOT a "feature you should avoid" according to the video's instructor?
A. Multi-Valued Fields
B. Attachments
C. Single-valued text fields
D. Name AutoCorrect
Q12. Which respected Access developer was mentioned as recommending that users turn Name AutoCorrect off?
A. Allen Browne
B. Bill Gates
C. Richard Rost
D. Colin Riddington
Q13. What is the main criticism the instructor has about Name AutoCorrect?
A. It is unpredictable and can miss important references
B. It increases the risk of database corruption
C. It always overloads the CPU
D. It deletes queries automatically
Q14. If you want to check your database after a rename, what is a safe process suggested in the video?
A. Search for the old name and manually review each hit
B. Use global replace for all occurrences and trust the results
C. Assume everything is updated if the database still opens
D. Ignore broken buttons as they are rarely used
Answers: 1-A; 2-B; 3-A; 4-A; 5-A; 6-A; 7-A; 8-A; 9-A; 10-A; 11-C; 12-A; 13-A; 14-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 why I recommend disabling Microsoft Access's Name AutoCorrect feature as soon as I start working with a new database. Although the feature sounds helpful - it promises to automatically update references throughout the database if you rename a table or field - it does not do as thorough a job as many people assume. This can create unexpected issues, giving you the false impression that Access has taken care of all necessary changes when, in reality, some things get missed.
The idea behind Name AutoCorrect is pretty straightforward. Let's say you change a field name in your table, for example, from Customer Since to Customer Start Date. With Name AutoCorrect enabled, Access tries to update affected queries, forms, reports, and controls to match the new name. For simple databases with limited features, this does work most of the time and might seem pretty convenient.
However, once you move beyond basic databases and start building more complex applications that involve VBA code, controls with separate names, event procedures, or references to fields and objects from other forms, Access can begin to miss certain updates. Name AutoCorrect often fixes some references but will not update things like VBA code or SQL statements hidden in macros, queries, or embedded in code. This can lead to problems that are not immediately obvious, leading to frustrating bug hunts down the line.
Let me explain some of the technical details. In Access Options, under Current Database, you will find three Name AutoCorrect settings: Track Name AutoCorrect Info, Perform Name AutoCorrect, and Log Name AutoCorrect Changes. These work in a hierarchy. The first, Track Name AutoCorrect Info, tells Access to keep track of dependencies between your objects - tables, queries, forms, and reports. This is necessary for the other AutoCorrect features to work, but it introduces some overhead and increases database size a bit. Perform Name AutoCorrect is what actually attempts to correct references when you rename a field or object. The final option, Log Name AutoCorrect Changes, keeps a log of changes Access attempts to perform.
Another feature that depends on Name AutoCorrect tracking is Object Dependencies. If you like to use Object Dependencies to see what forms, queries, or reports rely on a given table or field, you'll need to keep at least the tracking feature enabled. Personally, I rarely use Object Dependencies since I prefer to manage these relationships myself.
To illustrate how this works in practice, imagine you have a customer table with a field originally called Customer Since. If you rename this field to Customer Start Date, Access will attempt to update the control source of corresponding bound controls on forms, so long as you built the forms in a typical way. However, the names of the controls themselves do not update. For instance, if the text box on your form is named Customer Since, it will keep that name even though its control source will now be set to the newly renamed field. That situation is not inherently a problem, but it can potentially cause confusion during maintenance.
Where real trouble often starts is with any VBA code in your application. For example, say you have a button that opens another form, referencing objects or field names in its code. If you rename the referenced form or field, Name AutoCorrect will not change the corresponding VBA code to match your new naming scheme. This can break functionality in ways you might not notice right away - especially in complex applications where the affected code does not get tested immediately after such changes.
The heart of the problem is that Name AutoCorrect creates a false sense of security. You make some structural change in your database and imagine that Access has taken care of all possible dependencies. In reality, only certain references get updated, while critical pieces - like VBA code, recordset references, DLookup calls, or SQL statements - are ignored. You might not notice what's broken until much later, when a user tries to access a feature and it fails, and now you're left chasing down bugs you could have avoided simply by manually handling the renames and making sure all references were addressed.
My recommendation is to turn off all the Name AutoCorrect options as soon as you start building a new Access database, especially if you are doing any work beyond simple personal databases. If you start every new project from a template, as I often do, make sure to turn these off in your template so you do not have to repeat the process every time.
Once you disable these features, you will lose things like Object Dependencies, but for me that is a small price to pay for better reliability and control. When you need to rename something important, such as a table or field that is widely used in your application, take the time to manually review your queries, forms, reports, and all your code. Doing a global search is invaluable, but do not attempt a mass "replace all" operation since that can cause its own problems.
It is worth noting that not all experienced Access developers agree with my approach. For example, Colin Riddington, a respected Access MVP, argues that if you fully understand the limits and function of Name AutoCorrect, you can use it safely. He has said that he uses it extensively without issue. I appreciate this viewpoint, and it is true that if you know exactly what the feature will and will not change, you can avoid most issues - just as you can avoid most car accidents if you memorize every pothole on your route. Personally, I find that having to keep track of what gets updated and what does not makes the feature more trouble than it is worth. I would rather simply control all changes myself.
This perspective is not new in the Access community. Allen Browne, a very respected expert from earlier days of Access, wrote an article many years ago recommending turning off Name AutoCorrect due to a variety of issues and performance drawbacks. While Microsoft has improved the feature over the years, the fundamental criticism remains: Name AutoCorrect just does not update all of the references in your database and can leave you with broken code you might not discover for weeks.
In summary, while Name AutoCorrect might look helpful, its partial updating of objects is exactly what makes it risky. I find that spending a few minutes to review necessary updates myself is more efficient in the long run than relying on Access to make guesses - and then dealing with mysterious bugs later.
I encourage you to share your opinions as well. Do you keep Name AutoCorrect enabled, or are you in the habit of disabling it right away? For more details and step-by-step instructions on everything I discussed here, you can find a complete video tutorial on my website at the link below. Live long and prosper, my friends.Topic List What is Name AutoCorrect in Microsoft Access
Why beginner Access users may find Name AutoCorrect helpful
Risks of relying on Name AutoCorrect for renaming
Limitations of Name AutoCorrect with VBA code
How to find and change Name AutoCorrect settings
Explanation of Track, Perform, and Log options
Demonstration: Renaming fields with Name AutoCorrect
Effects of Name AutoCorrect on form control sources
Impact of Name AutoCorrect on Object Dependencies
Arguments for turning off Name AutoCorrect
Arguments from other developers about Name AutoCorrect
Potential issues caused by partial updates from Name AutoCorrect
Recommended manual process for renaming fields and tables
How to permanently disable Name AutoCorrect in new databases
Overview of historical expert opinions on Name AutoCorrectArticle When creating a new Microsoft Access database, one of the first features I recommend turning off is Name AutoCorrect. At first glance, the idea behind Name AutoCorrect seems fantastic: if you rename a field or a table, Access automatically updates all references to that object throughout your database. For beginners working on simple databases, this feature can seem like a lifesaver. However, once you start building more advanced, robust databases, especially those using VBA or complex forms and queries, Name AutoCorrect can introduce more problems than it solves.
To understand Name AutoCorrect, think of a scenario where you have a table with a field called Customer Since. Later, you decide it is better named Customer Start Date. Access, with Name AutoCorrect enabled, does its best to update all references to this field across your queries, forms, and reports. This sounds helpful, but there are several catches you need to know about.
First, it is important to understand what the Name AutoCorrect settings actually do. In Access, under File > Options > Current Database, you will find three related options. The first is Track Name AutoCorrect Info. This tells Access to create and maintain a behind-the-scenes map of which database objects depend on which fields and tables. The second, Perform Name AutoCorrect, is what actually updates references when something is renamed. The third, Log Name AutoCorrect Changes, will record what changes Access makes automatically. These options are hierarchical, meaning the Perform option requires Track to be enabled, and the Log option requires both of the others.
One accessory feature that relies on Name AutoCorrect is Object Dependencies. If you use Object Dependencies to keep track of what fields, tables, forms, or queries depend on each other, you may need to keep the Track option enabled. However, most experienced developers rarely use this feature.
Let me walk you through a practical example. Imagine you have a table for customers and a field called Customer Since. You also have a form bound to this table, and on the form there is a text box control also named Customer Since, bound to that field. If you rename the field in your table to Customer Start Date with Name AutoCorrect enabled, Access will update the control source in your form so that the text box points to the newly renamed field. However, note that the name of the text box itself does not change; it is still called Customer Since. This can make things a bit confusing, but it will still work.
Problems start to appear when you consider VBA code. For example, you might have a button in your form with code like this:
DoCmd.OpenForm "OrderF", , , "CustomerID=" & Me.CustomerID
If you rename the underlying form from OrderF to OrderForm, Name AutoCorrect does not update your VBA code. Clicking the button will now result in an error, because the code is still trying to open a form called OrderF, which no longer exists. Similarly, if you rename fields referenced in your code, in recordsets, DLookup functions, or within SQL statements that you write by hand, those references will not be updated either.
Microsoft has documented that Name AutoCorrect does not modify VBA code or update all references. This limitation is critical. If you have a real application with many forms, controls, queries, and thousands of lines of code, Name AutoCorrect may quietly update some references but miss others, which leaves you with a partially updated database and, worse, a false sense of security that everything was fixed. That is the biggest danger. You might change a field name, and everything seems fine at first. Then weeks later, a user tries to use a part of the application that breaks because a reference was not updated.
Because of this, my advice is to turn off Name AutoCorrect as soon as you start building anything more than a very basic database. You can do this for each new database in File > Options > Current Database by unchecking the Track Name AutoCorrect Info, Perform Name AutoCorrect, and Log Name AutoCorrect Changes options. If you build new databases from a template, turn these off in your template so every new project starts with them disabled.
Object Dependencies will no longer work with these features turned off, but I personally find that to be a small trade-off. The more important thing is to avoid hidden bugs from half-completed updates.
Instead, get in the habit of manually checking your database after changing table or field names. Search through your queries, forms, reports, and especially your VBA code. Use search to find references to the old name, and update them manually. Be careful with global find-and-replace actions: always review each instance before replacing, as unintended changes can introduce their own bugs.
Some developers, such as Access MVP Colin Riddington, feel that Name AutoCorrect works fine if you understand its limitations and carefully monitor its behavior. If you prefer to rely on this feature and are comfortable tracking what it does and does not change, you might choose to keep it enabled. In contrast, experts like Allen Browne have strongly recommended turning it off, pointing to a history of bugs, performance issues, and the simple fact that it cannot update everything automatically.
My personal experience has led me to the same conclusion. The feature was designed to make things easier, but as Access databases grow in complexity, Name AutoCorrect becomes another layer of automation you have to remember and monitor. For most database projects beyond the beginner level, it is much more reliable to make renaming changes yourself, testing the application afterward to be sure nothing is broken.
In summary, while Name AutoCorrect can be helpful for simple tasks, it does not reliably update all references across your database, especially when VBA is involved. I recommend turning it off early and developing the habit of carefully managing schema changes yourself. This small investment of time upfront will save you many debugging hours down the road. |
