Quick Queries #67
By Richard Rost
24 days ago
Why Are My Records Changing? Relationship Mistake
In this Microsoft Access tutorial, we'll talk about a common form design mistake that causes all records in a continuous form to update at once, and I'll explain how to set up proper relationships between tables to avoid this error. You'll learn about lookup combos for assigning managers, discuss query joins, and get answers to viewer questions on form names, ribbon security settings, file size limits, and language translation options.
Lydia from Glendale, Arizona (a Platinum Member) asks: I have an employee table and a manager table. Each employee can be assigned a manager, so I created a form where I can pick a manager for each employee. The problem is that when I update the manager on one employee record, it changes the manager for all employees instead of just that one. What am I doing wrong?
Prerequisites
Links
Recommended Courses
Up Next
Keywords
TechHelp Access, hidden relationship mistake, continuous forms, updating manager field, employee manager form, foreign key, combo box selection, self-join relationship, outer join, lock fields, property sheet form name, shift key security, two gigabyte limit, split database
Transcript
Today we're going to talk about why all the records on your continuous form seem to change, or at least one or more fields do. I'm going to teach you about the hidden relationship mistake that a lot of beginners make that completely breaks your Microsoft Access forms.
That plus we've got answers to your questions from YouTube and more. Let's get into it.
First up, we've got a question from Lydia from Glendale, Arizona, one of my Platinum members. Lydia says, I have an employee table and a manager table. Each employee can be assigned a manager. So I created a form where I can pick a manager for each employee. The problem is that when I update the manager on one employee record, it changes the manager for all employees instead of just that one. What am I doing wrong?
Lydia has been through the first couple of my expert classes where we just start learning about relationships. Lydia, you made one of the most basic relationship mistakes that people make when they start working with multiple tables together. I'm going to show everybody exactly what you did, and hopefully it will help someone else out there too.
Here I am in my TechHelp free template. This is a free database you can grab off my website if you want to. Now, I don't have employees and managers in here, but I do have customers. Let's pretend that customers represent your employees. It's just a list of people.
Let's add a manager table real quick. Create table design. Manager ID. That's our auto number. Then a manager name. We'll just put their first and last names together. That's OK. Then hit save. It's just for class purposes. Normally, I wouldn't do that. Manager table. Primary key. Yes. That's our auto number right there. Save it.
Let's put some data in here. Who are our managers? We've got Karen. She always wants to talk to the manager. Then we've got Philip. Let's say I don't know. We've got two managers. Save it. Close it.
As a side note, you could make the same table have both managers and employees by just putting a manager check box in there. That's called a self-join relationship. That's a lot more advanced, though. Don't worry about that yet.
Now, we need a way to get that manager ID into our customer table so we can pick a manager for each customer. Right-click, design view. I like to put them all up top. I'm just going to insert a row up here, a blank row, and stick manager ID in there. That's our number of type long integer. That's our foreign key that points to the manager table. Save it.
All right. Now, the way I like to get that data in there is I like to put a combo box on the customer form that we could pick a manager with. And I have a whole video on this. I'll give you a link to all these videos in a minute.
But I'm just going to come down here. I'm going to go to form design, find a combo box. It is right there. Drop it down here. Have the combo box get the value. So I'm going to table a query. Next, we're getting our values from the manager table. Next, bring over both of those fields. We need the ID and the name. Next. What do you want to sort by? Well, manager name. Next. That's what the box is going to look like. That's fine. And the key column is hidden. That number is what we actually care about. Next. We're going to store that value in the manager ID of the customer table, or in your case, the employee table. Next. What do you want the label to be? Manager is fine. And there's your box.
A little format paint. Get that guy black. So there's our manager. Save it. Close it. Open it. And now I can pick managers. Karen is my manager. Go to the next record. Karen is this guy's manager. Next record. Let's say this guy's Philip. And so on. You pick your managers. That's how you pick it. Now that's how I do it.
Now, let's get into your problem. Lydia wants to see a continuous form like this with the employees with the manager listed on here as well.
So now we're going to get rid of state, customer since, and credit limit. Now we're going to stick the manager there. Now this guy is based on the customer table. And if you look in the customer table - and this is the mistake people make - they look in the customer table and they say, I don't have the manager name in here. I got the manager ID, but I don't want to see that one or that two on here. I want to see the manager's name.
Here's the next logical step that people think you have to do. They come over here and they make a query. This is exactly what you did, Lydia. Query design. Customer and manager. They're joined together. That's fine.
Remember your join type, because if you don't change your join type, you're not going to see people who don't have a manager. If you bring over all the fields over here and the manager name, and you run this query now, you're only going to see those five records because they're the only ones that have managers. So make sure you change this to an outer join right there so you see all the records in the customer table, even if they don't have a manager ID. I have a video for that too. I'll give you a link to that in a minute.
But now we have a data set that also has the manager name in it for people who have managers picked. That's what I want to see on my form.
Let's save this query. I'll just save this as the manager Q. And now I can take my customer list and I can go into design view and I can change this to that manager Q. And now I could put the manager name on here.
Add existing fields. There's the manager name. Let's bring that over here. Beautiful. I'm just going to delete the label, stick it up there. I'll copy this and paste it. Copy and paste. And we'll bring it over here. That's our manager. Things are looking good so far.
Save it. Close it. Open it. And where are the guys with the manager? There they are. That looks good. I can see every employee. I can see the managers over here. That's fine.
Now I want to change someone's manager. I want to change Richard Rost's manager to Philip. Hit tab. And what happened? It changed everybody to Philip. I didn't want to do that. I just want to change this guy to Philip. Let's put it back to Karen. And they all went back to Karen again. That's interesting. Anybody know why that's happening? Pause the video. Think about it for a minute. See if you can figure out why that's happening.
Did you get it?
Here's what you're doing. You're not actually changing this record from Karen to Philip. You're changing Karen to Philip. When you bring in two tables into a query like that - this manager Q - these are all fields from the customer table. This is a field from the manager table. You're literally changing the record in the manager table. If I come in here, and if I change Karen to Joe, notice they all changed to Joe. What you did was you changed Karen to Joe. And that's why if you change it to Philip, it looks like you picked Philip and then everybody else changed to Philip, but that's not what happened. You literally turned Karen into Philip.
Now, what you have to do is if you really want to be able to change the manager on this continuous form, you can. If you're running over a network and you have a lot of users, it might make things slow, but you can make this a combo box. Which means you can go back to what you had before. You don't need a query in here.
Get rid of this. We're going to go back to having this based right off the customer table. Customer T. Now, the customer T only has the manager ID, but that's fine. That's all you need.
Because watch, you can go form design, combo box. Put a combo box here. Look up the values from the table or query. Same combo box we made before. In fact, you could steal it right off the other form if you want to. Manager T. Bring over both fields. Sort by manager name. That's what it's going to look like. Store the value in the manager ID of the customer table. Next. What label do you want? I'm going to delete it anyway, so it doesn't matter. And here you go.
Now, you have a combo box right on that customer list form. If I open it up, look at that. Now I can change Karen to Philip, and I'm just changing that record. I'm not changing all of them.
That's why I always say you should always, well, not always, but you should mostly make your forms based on a single query. And if you do bring in fields from other tables, lock them so that can't happen. Lock this field, right? When you had the other one with just a text box there. So you can't change Karen and Philip. Lock it. Go into the properties. Take this guy, go to data, and say lock this: Yes. On the text box, not on the combo box. Because then your users can't accidentally change the related records. I see it happen all the time. This is a popular problem that a lot of beginners have when you first are getting into relationships.
Try, if possible, to make your forms based on a single table. And if you have other lookup fields in here, then lock those fields.
And a mention to the more advanced users: this is fine for small databases. I try to avoid combo boxes and lookup fields in continuous forms. Because if you start running this over a network, especially if this list is long, this is really going to get slow. Especially if you're running over the internet, you've got SQL Server, and you're pulling this off the web. The more combo boxes you have, the more lookups you have in here, this is going to get really, really slow. So try to avoid that if possible.
I like to just maybe show the item here, like we had before. But to change it, you just have to open up the single form and make the change here. That's my preferred way to do it. But there's nothing wrong with this on a small database, small network. This is fine. Two managers, no big deal.
Here's some other videos you can watch for more help with this stuff. Go watch my relationships video.
Here's a video on making those relational combo boxes.
Here's a good video on those self-join relationships I was talking about earlier. It's something with genealogy, right? You have people that relate to other people. This way you wouldn't need a separate manager table. A person has a father and a mother and each of those are other people, so the same table just links to itself. Check this out.
And don't forget about those outer joins that I mentioned. That little relationship there - if you don't do that you can be missing records on one side or the other. So check them out too. These are all free videos. They're on my YouTube channel. They're on my website. Go watch them.
So Lydia, I hope that answers your question. I hope that helps you. I hope it helps someone else out there. If it helped you, let me know. Post a comment down below. You're why I do this. You're why I do what I do.
Let's take a look at another question. Jack from Hamburg, Germany, along with about five other people, have asked me, why aren't you teaching the Monaco SQL editor yet?
Bottom line, it still has some bugs. I like to wait until they've ironed out most of the bugs, and when I stop seeing bugs being posted in the different forums and the email threads that I'm in, once it's stable and it's working perfectly and it's been out for like six months without any major issues, I'll start doing videos on it. But until then, I wait. I like to be better safe than sorry.
I like to teach people stuff that for business-critical databases, I don't jump on new features. I haven't updated my production version of Access in a while, so I'm very cautious about stuff like that. But when it's ready, when it's fully cooked, I'll be doing some videos on it.
All right, let's head over to YouTube.
Cruision Fiber Geek: How come when I open Access, I don't get all the tabs on the ribbon like Create Database? I only see Duke and Home. Are you playing the Duke Nukem version of Microsoft Access?
I do see everything if I hold the shift button down while it opens. Is this a security setting? The database was set up by someone at least a year before I started using it. I'm learning how to make changes and update as needed.
Ah, yes. You just answered your own question. Whoever built that database did some stuff to lock down the ribbon. They set up some security in it. And by holding down that shift key, it bypasses the startup routine, so your main menu doesn't load and whatever other security settings are baked into there don't have a chance to run.
You can leave that on there if you want to. Just know that you won't be able to make changes to it unless you do hold down that shift key when you start the database. Here's a video that you can watch that explains a little bit more about the security features, that shift key, how to turn all that stuff on and off. Go watch this if you have any other questions.
Next up, Boren Beton says when you have a larger number of forms and subforms, how can you quickly see the name of the form, especially subforms? Do you have a quick way?
Well, not really. There's no secret trick to this one. Really just look in the property sheet. You go into design view and there's the name right there. That's the name of the form.
As far as subforms go, let's see. I have somebody with a subform in here. I think it's the order form. Order F. This is a subform down here. Right-click, design view. Click on it. That's the order detail. That's the name of it. You can put some code in there so it shows up maybe in the caption or up here. There are lots of ways to do it, but there's no quick way that I know of while you're in form view to see it. If you're sitting here, you could put it into caption yourself if you want to. Or if I'm not understanding your question, let me know. Post another question and give me some more details.
Next up, I got one Carlos with - hold on, let me hit the translate. Which videos or courses are available in Spanish?
Well, I don't speak Spanish myself. Now, YouTube will sometimes translate some of my videos into Spanish. There's also a new feature in the Edge browser that I did a video on a couple of days ago, where Edge can now live translate the audio. So you'll hear me speaking in Spanish. Well, that's not really me; it's a computerized voice, but you get the point.
So use the Edge browser and then you can watch any of the videos on my website in Spanish, which is pretty cool. I'm not sure about how YouTube is handling that, but I think that's pretty neat.
Atlantic X100 asks, does the two gigabyte file size limit exist? Oh, yes. Oh, it exists. It's very real. In fact, I suggest not letting your Access back-end file get over 1.5 gigabytes, because some temporary table writes, a big query, any of that can cause your database to balloon over two gigabytes. That's a hard limit. So you will crash. You'll run into, hey, I can't do anything about this errors. But remember, you can split your database into multiple back-end files, so really you can only have one table that hits that limit. I have several whole videos on this subject, so search my website for them, and here's one of the more popular ones. So check it out.
All right, folks. That's going to do it for another Quick Queries. Hope you learned something. Live long and prosper, my friends. Enjoy your weekend. I'll see you next time.
Quiz
Q1. What is the most common relationship mistake beginners make in Microsoft Access forms that causes all records in a continuous form to appear to change when editing a field?
A. Using fields from a related table directly in the query and form without locking them
B. Forgetting to set a primary key on the main table
C. Not using any queries at all in their forms
D. Using an incorrect data type for the fields
Q2. When should you use a combo box to select a related record, such as assigning a manager to an employee, on a Microsoft Access form?
A. When you want to pick a value from another table and store its ID in the current record
B. When you want to edit the related table directly from the form
C. Only on reports, not on forms
D. Only if you are using a split database
Q3. Why does editing a related field such as manager name on a form based on a multi-table query often change the value for all records, not just the one being edited?
A. Because the form is updating the value in the related table, not just the linking field in the main table
B. Because the customer table does not have any fields
C. Because Access locks all records while editing
D. Because the query does not allow updates
Q4. What is the recommended approach for displaying related look-up information, such as a manager's name, in a continuous form while still allowing assignment of managers to individual records?
A. Use a combo box to select the manager and store the manager ID in each record
B. Allow users to edit the manager's name directly in the related table from the form
C. Create a separate form for updating manager information
D. Require users to memorize all manager IDs
Q5. What is the potential disadvantage of having many combo boxes or lookup fields in a continuous form when working over a network or with a large list?
A. It can slow down performance significantly
B. It makes the database more secure
C. It prevents any data from being updated
D. It increases the two gigabyte file size limit
Q6. What should you do if you need to display a related value (like a manager's name) from another table in your form, but do not want users to change it accidentally?
A. Lock the field displaying the related value so it is read-only
B. Remove the field from the form entirely
C. Make the field a required field
D. Hide the field using conditional formatting
Q7. What kind of join should you use in a query to ensure you see all records from the main table, even if they do not have a related manager assigned?
A. An outer join from the main table to the related table
B. An inner join between both tables
C. A cross join of both tables
D. A self-join within a single table
Q8. What is a self-join relationship in Microsoft Access?
A. When a table relates to itself, such as an employee table that stores managers in the same table
B. When two unrelated tables are joined together
C. When a table is duplicated for backup purposes
D. When a form joins to multiple queries
Q9. Why should you avoid letting your Access backend file approach or exceed two gigabytes in size?
A. It is a hard file size limit and exceeding it can crash the database
B. It prevents new forms from being created
C. It makes all queries run faster
D. It improves performance of networked databases
Q10. How can you bypass custom security settings that hide menu tabs when opening a Microsoft Access database?
A. Hold down the Shift key while opening the database
B. Open the database in Safe Mode
C. Right-click and choose "Unlock menus"
D. Delete all macros from the database
Q11. What is the best way to see the name of a form or subform while in design view?
A. Look for the name in the property sheet of the selected form or subform
B. Look at the title bar of the main Access window
C. It is visible only when the form is open in datasheet view
D. Search the database objects pane for highlighted names
Q12. What did the video recommend for most situations concerning the data sources for forms?
A. Base forms on a single table or query and lock any related fields from other tables
B. Only use forms based on multiple queries
C. Always allow users to edit related values for convenience
D. Rely on macros to manage form data
Answers: 1-A; 2-A; 3-A; 4-A; 5-A; 6-A; 7-A; 8-A; 9-A; 10-A; 11-A; 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
In today's Quick Queries video from Access Learning Zone, I will be talking about a common issue many people run into when working with continuous forms in Microsoft Access. Specifically, I'll explain why, when you try to change a value for a single record on a continuous form, you may see that value change for every record on the form instead. There's a hidden mistake in how relationships are set up that can break your forms, especially if you're just getting started with multiple tables in Access.
Let's get into the details by discussing Lydia's question. She has both an employee table and a manager table. Each employee is supposed to have a manager assigned, and she set up a form so you can pick a manager for each employee. The problem she's experiencing is that changing the manager for one employee is ending up changing the manager for every employee, not just the one record. This is a problem many people new to working with Access relationships face, so I want to walk you through what typically causes it.
For illustration, let me use my TechHelp free template. While I do not have an employee/manager setup in this sample database, I do have a customer table, which works just as well for the demo. First, I quickly create a manager table with a manager ID as the AutoNumber primary key and the manager name field, combining first and last names. I add a couple of managers (Karen and Philip, for example) just to demonstrate the functionality. You could, by the way, design this using a self-join, where the same table contains both employees and managers, but that's an advanced topic for another day.
Next, to relate the manager with each customer (which stands in for our employee), we add a ManagerID field into the customer table. This field acts as a foreign key pointing back to the manager table. The best way to allow users to pick a manager for each customer is to use a combo box on the form that lets you select from available managers. This combo box will store the chosen manager's ID in the customer record.
Here is where beginners often make the mistake Lydia described. She wanted to display both the employee and their manager name on a continuous form, so she created a query joining the employee and manager tables. She then used that query as the record source for the form, bringing both the relevant employee and manager fields into view. It seemed to work: the manager's name displayed next to each employee.
But the trick is, if you try to change a manager's name via the form (for example, switching Richard's manager from Karen to Philip), what actually happens is the manager's name changes everywhere. That's because when you use a field from the manager table directly in the form bound to a multi-table query, you're editing the data in the manager table itself, rather than only associating that manager with a single employee record. So, if you change Karen's name to Philip, you haven't reassigned one employee: you have renamed Karen everywhere—thus everyone assigned to Karen is instantly switched to Philip.
To avoid this, and correctly allow each employee (or customer, in my example) to be assigned a manager individually, you want your continuous form to be bound directly to the employee (or customer) table, not to a multi-table query. You can then use a combo box to display the manager name and store the manager ID for each individual record. This setup lets you pick a different manager for each employee, and making a change only affects the current record—not all of them.
Additionally, when showing lookup fields (like manager name) from related tables on a form, I recommend locking those controls so users cannot edit them directly. If you're showing the manager's name from the manager table, be sure to make the field display-only so nobody can accidentally edit manager names for the whole database. Only the combo box used to pick a manager for an employee should be editable.
There's another important point here for more advanced users: putting multiple combo boxes in continuous forms can cause performance issues, especially on larger networks or if you're using back-end databases like SQL Server. Each combo box can slow things down, so it's generally better for larger databases to show only the lookup value (like the manager's name) and use a separate single form for edits.
If you're interested in digging deeper into related concepts, I have other resources. I have videos discussing relationships in Access, how to create reliable relational combo boxes, self-join relationships for more advanced situations, and the use of outer joins to ensure you see all records even if some are missing related data. All these videos are available for free on my website and YouTube channel.
Now let's answer a few other questions that came in.
One common question is about the Monaco SQL editor. Several viewers have asked why I have not covered it yet. The simple answer is that it still has bugs, and I prefer to wait until a new feature has been stable for a good period before I recommend using it in business-critical databases. Once it is thoroughly tested and reliable, I will include tutorials.
Another question came up about missing ribbon tabs in Access. In some cases, users only see limited tabs like Home and not others like Create when they open Access. This is likely due to startup security settings the database creator configured. Holding down the Shift key while opening Access bypasses those startup routines, giving you access to everything. If you need more details on this type of lockdown and how to turn it on or off, I have a video covering those security features and the use of the Shift key.
Another viewer asked if there is any quick method to view the names of forms and subforms, especially when managing many of them. There is no rapid shortcut for this: the best way is to look in the property sheet in design view, where the name is listed. Subforms can be checked the same way. If you want, you can also display the form name in the caption or elsewhere on the form using a bit of code, but there is no built-in shortcut for viewing these in form view.
One user asked about Spanish videos or courses. I do not speak Spanish myself, but YouTube sometimes provides automatic translations of my videos. Also, the Edge browser now has a feature to translate audio live, so you can watch my videos with computer-generated Spanish audio on my site. This is a useful workaround for Spanish-speaking viewers.
Another frequent question concerns the Access database file size limit of two gigabytes. Yes, that is a real and important limitation. In fact, I recommend you keep your backend file below 1.5 gigabytes to avoid running into trouble with temporary files or large queries. Note that you can split your database into multiple backend files to avoid this issue, though a single table cannot exceed the two gigabyte limit. I have several videos covering Access size limits and how to manage them.
That wraps up another Quick Queries session. I hope you found this helpful and learned something useful today. 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
Why updating a field on a continuous form updates all records
Designing a manager table with auto number and manager name
Adding manager data and creating sample records
Linking a manager to customers using foreign key
Storing manager ID in the customer table
Creating a combo box to select manager for each employee
Storing combo box value in the related foreign key field
Displaying manager names in a continuous form
Using a query to join customer and manager tables
Configuring outer join to show all records with or without managers
Adding manager name field to a continuous form via query
Explaining why changing joined table fields affects all records
Fixing the form so only the correct record's manager changes
Designing forms to be based on single tables when possible
Locking fields that are joined from other tables to prevent editing
Using combo boxes for related fields on continuous forms
Combo box performance considerations in networked environments
Recommendation to edit related fields on single forms in large databases
Article
One common problem that many Microsoft Access beginners run into is that all the records in a continuous form appear to change when you update just one field. For example, you may have an Employee table and a Manager table, where each employee can be assigned a manager. When you set up a form to choose a manager for each employee, you might notice that changing the manager for one employee seems to also change it for all employees. This can be confusing and frustrating, but it usually comes down to a simple mistake involving how you link your tables and display fields in forms.
Let's walk through a classic scenario to explain this. Imagine you have two tables: Employees and Managers. Each employee should have a manager, and you want to display this in a form. The way you handle the table relationships and form controls will determine whether things work as expected or fall apart.
First, you need a Manager table, which you could set up in table design view with an auto number field called ManagerID and a text field for the manager's name. After saving and entering a few manager names, like Karen and Philip, your Manager table is ready.
The next step is to allow each employee in your Employee (or Customer) table to be assigned a manager. You do this by adding a ManagerID field to your Employee table. This will be a number (long integer) field, acting as a foreign key referring to the Manager table.
When creating a form to assign a manager to an employee, the best way is to use a combo box. In the form design view, add a combo box control that pulls its options from the Manager table. Walk through the combo box wizard: select ManagerID and ManagerName as available fields, sort by ManagerName, and then make sure the combo box writes its value into the ManagerID field of the Employee table. Now, when you open the form, you can assign or change the manager for each employee independently—exactly what you want.
Now, let's address the common mistake. Many beginners, after setting up their tables, want to display not just the ManagerID, but also the actual name of the manager next to each employee. They create a new query that joins the Employee table to the Manager table, pulling in the ManagerName field. Using this query as the data source for a continuous form, they add the ManagerName field to the form so the user can see it directly.
At first glance, this seems perfect. You see a list of employees with their managers' names. But the moment you try to change the manager's name on the form, you run into trouble: updating the manager for one employee causes the manager to change for all employees who share the same manager. Or, worse, you accidentally overwrite the manager's name in the Manager table entirely.
What's really happening is that you are not just changing the manager assigned to a particular employee, but actually editing the manager name in the Manager table itself. Since all related employees are linked to that manager by ManagerID, changing the name affects everyone tied to it. For example, if you have three employees with ManagerID 1, whose name is Karen, and you change Karen to Philip on the form, all three now appear to have Philip as their manager, but only because you changed the record in the Manager table, not just for one employee.
The solution is to avoid putting editable fields from the Manager table directly on your Employee or continuous form. If you display ManagerName in a text box, you should lock it so users cannot accidentally edit it. Only the ManagerID in the Employee table should be editable, and you should use the combo box to select or change the manager by ID. That way, when you change the combo box, you are only updating that employee's ManagerID field; the Manager table's names stay untouched, and other employees are unaffected.
If you want to show the manager's name in the list, you can add the ManagerName field to your query to display it, but make sure the text box showing ManagerName is locked (set its Locked property to Yes in its properties window). This makes the form user-friendly but prevents accidental data corruption.
For advanced users or larger databases, keep in mind that using many combo boxes and lookups in a continuous form can slow down your database, especially over a network. It's often better to show the manager name in the list as a locked display, then switch to a single-form view with the combo box to make changes. But for smaller databases and short manager lists, the combo box in the continuous form is acceptable.
To sum up, always base your forms on a single table or a carefully designed query. Any lookup fields from other tables should be displayed as locked, non-editable fields. Use combo boxes to let users change foreign key values (like ManagerID), but do not let them edit related table data directly from these forms. This practice keeps your data safe and your forms behaving correctly.
For those curious about more advanced designs, you can structure a self-join relationship so that managers and employees are in the same table, using parent-child relationships—a technique useful for modeling family trees or hierarchies—but that is more advanced and not necessary for most simple scenarios.
In summary, if all your records seem to change when you update a field in a continuous form, check what data source your form is using, and double-check which fields are editable. Only the foreign key value should be changed through a combo box, and any related descriptive fields from other tables should be locked to prevent accidental overwrites. This adjustment will keep your forms working correctly and your database relationships intact.
|
