I devote a lot of time to helping people learn how to use Access. Sometimes I have helpful examples I can post to illustrate concepts. Sometimes I can write snippets of code. But, when you're intent on creating a non-normalized solution which I would never do, I can only offer high level advice but nothing concrete.
A different way to approach this instead of using x columns that are filled with variable types of data depending on what type of part is showing, is to use an Entity-Attribute-Value model. That way, you have a "header" table with all the common fields. Then you have a child table which has a separate row for each of the variable attributes. You need a table that defines the attributes for each part type. I have an app I created using this model for an insurance company. Each type of policy has around 30 common attributes. Name, address, etc. And some number of variable attributes. When the user wants to define a new type of policy, he adds any new, previously undefined attributes to the fields table and then he picks all the variable fields for THIS policy type (think part type here). When the user is entering data for a new policy for a new customer, he chooses the policy type. When the header record is saved, the code runs an append query that selects all the fields for this policy type and appends a record for each to the child table that will hold the specific values for each policy. The point of the application is to ensure that all policy documents are consistent in the data values. Therefore, if the policy limit changes, you change the limit and reprint all the documents. Without this app, the user had to remember which documents had which fields and so which documents needed to be changed if any value in the agreement changed.
This an ultimately infinitely expandable solution. It doesn't matter how many policy types you end up having to define. It doesn't matter how many variable fields you end up with in total and it doesn't matter how many of these fields are required for each policy.
You can stick with your limited solution (which I don't recommend because it will require code maintenance whenever you add a new type of part which my Entity-Attribute-Value solution does not) if you are very sure you know the boundaries of your part type universe up front and you are positive you will never need more than 28 columns to handle all the variable values.
You can create a single form with 28 controls. The controls are bound to fld1, fld2, etc. When you go to a new record, you need to read the labels table and loop through the fields so you can set the caption property of the controls to fld1, fld2, etc. This makes the form look different but it will be a bitch to maintain. You won't be able to easily reorder the columns, when you add new ones, the always go at the end.
The other thing I did with my EAV model is create lookup tables to help me validate certain types of data.
Here is a picture of the data entry form. The fields in the header are fixed but the ones in the list are the variables. Notice that the yellow field has a dropdown for a combo. Because this field is several different stacked controls, when the field needs a combo, the appropriate one can be displayed for the particular field. As you click into each field, you will see a different value list. This is handled by having a column in the table that defines each attribute with a field to hold a query name for the RowSource. So, the code just sets the RowSource to whatever value is in the field.
