The current workaround for this is to use copy and paste to move the desired data into the name column/primary field. More specifically, if you have an existing column whose position you’d like to swap with the primary field (and you still want to keep the data from the current primary field, you need to create a third blank column:
Copy/paste contents of old primary field to new blank column (make sure blank column is the correct field type)
Copy/paste contents of new primary field over old primary field data (again, make sure the destination column is the correct field type)
Delete the duplicate field of the new primary column’s data.
How would you envision a “change the name column” feature working? Would you imagine that those controls would be in the field configuration menu somewhere? If you were thinking to yourself, “I’m going to change the primary field,” would you first try controls related to the primary field to see if there were an option to change it there? Or would you try and go to the field you wished to turn into the new primary field? Or somewhere else entirely?
I would see it as simply as dragging the desired column all the way to the left, past the current name column. That way, the name column is always on the far left, without any confusion.
I also noticed that the column said it can only be a short text field, but I was able to change it to a barcode field. Do the “name” fields have to be text?
The name field doesn’t actually need to be text—it can be number, autonumber, a formula, a barcode, an email address… It will not support attachment, checkbox, single select, multiple select, rollup, lookup, and count type fields, or links to other records.
This confusion is actually one of the main reasons that we’re trying to phase out the use of the term “name field” in favor of “primary field.” :grinning_face_with_sweat:
I think that would be more familiar to users coming from other types of databases which use primary keys. But the ability to change the fields would seem like an improvement over other databases which can’t change the primary key. I believe this is because you generate a unique primary key for each record but leave it hidden.
Hi there, I hate to revive this old topic, but I was hoping you could explain why the primary field can’t be “single select”. I’m trying to reduce any input errors. Essentially, I would like this field to be multiple choice from a pull down.
For example, using the template Pet Medical History as an example, in the “Vet Visits” table, I would like the ‘name’ records to be chosen reasons from a pre-selected list (i.e. single select).
I’m planning on taking this template to organize the feeding rounds for the homeless dog population in my area in Thailand. I have many volunteers that will be entering data using forms and I need to limit their input to pre-defined choices. Thank you.
Hi Evan, the reason that the primary field can’t be single select is that (in theory) each of the records in a database should be uniquely identifiable by the value in the primary field. Now, in practice, it’s somewhat more complicated than “every record must be uniquely identifiable”—different records in the same table can have the duplicate values in the primary field. However, each record still has its own unique record ID, which is hidden from the user generally but can be surfaced by using the RECORD_ID function.
All of this is to say that it somewhat goes against the purpose of a database record for the primary field to be something that’s inherently a non-unique value—such as a single select field.
What I would do in your case is just make the primary field into a calculated field (autonumber is the easiest). If you look at the previous screenshot, there’s two calculated fields (autonumber in the primary field, and a formula for the RECORD_ID field), and one non-calculated field. Calculated fields don’t show up on forms, so if I were to make a form from the table shown in the previous screenshot, it would look like this:
Only one place for input, and all the input will limited to pre-defined choices. Whenever a new record is created, a new record (with a new autonumber identifier in the primary field) will be created.
Does that help?
Mostly yes, although I needed the “Reason for Visit” to be the primary field because it linked to another table. An easy enough solution was to just make a formula that referenced another field, in this case, the “Reason for Visit” field.
