Make text box automatic, based on drop-down menu

Just curious, what is the "Me." prefix? What does that mean?

EDIT: And how do I "bind the text box to the table field and use a line of VBA code to set the value:

   Me.PartNumber = Me.Combo69.Column(1)"?

Technically 'Me' returns a reference to the current instance of the class in which the code is running, but just think of it as shorthand for referring to the current form.

As regards the question of whether to store the P/N in a column in the form's underlying table, whether you should or should not do this depends on whether to do so would be redundant or not.  If, for whatever customer you select in the combo box, the part number will always be the same, then you should not store it in a column as that introduces redundancy.  If, on the other hand, having selected a customer, the part number can then legitimately be edited to different value, there is no redundancy, so toy should do as Marshall said, and assign the value to a bound text box in the combo box's AfterUpdate event procedure.  You can then edit the value if necessary.

This really is a matter of what is known in the language of the database relational model as 'functional dependency'.  A column is functionally determined by another column (or columns)  if from the value of the first column(s) the value of the second is always known to be the same.

So in a Contacts table for instance, if there is a row for me, and the value of the ContactID primary key of the table is 42, then from the ContactID value 42, wherever we encounter it, we always know that the value of the FirstName attribute is 'Ken' and that of the LastName attribute 'Sheridan'.  For a table to be in Third Normal Form all non-key columns must be functionally determined solely by the whole of the primary key.  So if the Contacts table also includes CityID and CountyID columns, where CityID represents 'Stafford' then CityID is functionally determined solely by the whole of the primary key ContactID because it's where I live and there is no other column in the table from which you can deduce that I live in Stafford.

In this hypothetical Contacts table the value at the CountyID column position of my row represents Staffordshire.  Now this is again functionally determined by the whole of the primary key ContactID, because it's the County where I live, but it is not solely determined by ContactID as from CityID we can also deduce that I live in Staffordshire because that is where Stafford, not surprisingly, is located.  So CountyID is transitively functionally determined by ContactID via CityID, which means the table is not normalized to Third Normal Form (3NF).

So what, you might ask?  The reason this is important is that it leaves the table wide open to update anomalies.  Say I move to Lancaster, in which case the CityID is updated to whatever is the value which represents Lancaster, but CountyID is not updated to the value representing Lancashire.  My cousin, who is also in the table, has always lived in Lancaster.  We now have two inconsistent rows, one which tells us Lancaster is in Staffordshire, one which tells us it's in Lancashire.  It's pretty obvious which is correct to anyone with a passing acquaintance with English geography or the etymology of English county names, but that's beside the point.  Redundancy is not merely inefficient, but opens the door to such update anomalies, and as Murphy's Law tells us "Anything that can go wrong, will go wrong ".

By normalizing the table by the removal of the redundant CountyID column the problem is eliminated, because we know from the one row for Lancaster in the Cities table that it is in Lancashire.  To see the county for each contact we simply join the Contacts and Cities tables on CityID.

However, a column might not be transitively functionally dependent even though at first sight it might be thought to be so.  The classic example of this is a UnitPrice attribute of a product in an OrderDetails table, where an Orders table has a UnitPrice column.  It might be thought that to include a UnitPrice column in the OrderDetails table as well as a ProductID column would be redundant as the price is determined by the ProductID.  This is not the case, though, as over time the unit price of a product will change, but the price in the OrderDetails table should be fixed as that at the time the order was created.  The UnitPrice column in Products is determined by its key, ProductID, but that in OrderDetails is determined not by the ProductID column in OrderDetails, but by the key of that table, which is a composite one of OrderID and ProductID.  So the UnitPrice column in OrderDetails is determined solely by the whole of the key, and is therefore not transitively functionally dependent on the key.  Consequently the table is normalized to Third Normal Form and the inclusion of UnitPrice columns in both tables is legitimate and necessary.  When a new OrderDetails record is inserted the current unit price for the product can be looked up from Products and assigned to the UnitPrice column in OrderDetails where its value will remain fixed whatever changes are made to the UnitPrice column's value in Products.

Thank you both so much. 

I'm not overly concerned with redundancies, especially at this time.  If all of the data comes from the form and into the table, there shouldn't be an issue, right?  Even if a P/N gets changed, the old data will stay where it is, right? 

And I'm still sure I don't understand what Marshall is saying about using a query for this purpose.  I believe it, if you both say that it's a better way of accomplishing this task, but could you explain a little more fully what I would have to do to that end?

As for right now, I have it such that when a Customer is selected from the Customer combo box, the P/Ns pop up in their text boxes because I set the Control Source to

=[Combo69].Column

but this prevents me from setting the Control Source to the columns from the Table, of course.

You really should be concerned about redundancies.  Their elimination is fundamental to good relational database design, and for good reason.  As far as I can see you have the form working exactly as it should be.  The flaw is in the underlying table design, and to correct it all you have to do is delete the redundant, and hence potentially dangerous, part number column from the form's underlying table.

As regards the use of a query, it's simply that by joining the form's underlying table to the part numbers table on the keys (CustomerID) you can return the part number in a column in the query.  You could base the form on such a query and bind a text box control to the part number column, but that has no real advantage over what you are doing currently via the computed text box.  Where such a query should be used, however, is as the RecordSource of a report.  Combo boxes and computed controls which reference a column of the combo box should only be used in forms, not in reports.

When you say "the form's underlying table", do you mean the Table that holds all of the recorded information on the form, or the Table from which I draw Customer names, part numbers, and program numbers, for the combo boxes?