Renamed tables showing up under original names in lookup fields

[Elvin_Roest]

I’ve duplicated some tables and then afterwards renamed them. However, in lookup fields when selecting a table to lookup from the original name still shows up, which makes me have to guess which is the right one. Anyone experiencing this too and knows how to recache the table names or sth?

[Elvin_Roest]

I tried to add an image to illustrate but it is not working. To illustrate, here’s the steps to reproduce:

• Start with original table ‘Table 1’
• Duplicate table ‘Table 1’, resulting in ‘Table 1 copy’. Rename the table to ‘Table 2’
• Alternatively, import a spreadsheet into a new table. Rename it to ‘Table 3’.
• Now in ay table add a new lookup field and under the configuration part of the field definition select the table to lookup from. It will now show ‘Table 1 copy’ and ‘Imported table’ in the list, where I would expect ‘Table 2’ and ‘Table 3’.

Please do not I created the tables days (/weeks/months) ago so it’s not a matter of waiting for the names to refresh.

Thanks for you suggestions!

[Mike_McLaughlin]

The names are not going to ‘refresh’. Field names are static, but may be initially auto-generated based on factors such as the name of linked table.

The table being copied, ‘Table 1’ is linked to lets say ‘Table A’, when you copy ‘Table 1’, so ‘Table 1 copy’ will already have a link to ‘Table A’. As such, ‘Table A’ will auto name that field for the name of the linked table at the time it is linked - it is linked in the moment that you make the copy, so the field in ‘Table A’ will auto name to ‘Table 1 copy’.

When you create a new link, it will use automatically use the name of the linked table, but the name is static all the same.

I have many tables copied from a base table that I use, so I am accustomed to cleaning this up after the fact.

The short of it is that I would like this to be dynamic as well, it would save me some considerable housework.

[W_Vann_Hall]

I’m not able to duplicate the problem as you have described it; however, I think you may be describing a related but slightly different behavior.

• In your fourth step, are you linking from the main table – the table where you created the link — or from the linked table?
• If you are linking from the main table, is it the ‘Field on this table that links to the records you want to look up’ that still has the old value, or is it the ‘Tasks table field that you’d like to look up’?

Here’s why I’m asking:

When you create a linked-record field that points to a different table, Airtable creates a reciprocal link, and it gives the reciprocally linked field the same name as the table to which it links. That is, if I create a linked-record field in [Table A] that links to a record in [Table B], Airtable automatically creates a linked-record field in [Table B] that links to [Table A] and is named {Table A}.¹

If I change the name of [Table B] to [Table C] and look at the configuration of the linked-record field that originally pointed to [Table B], it will now show ‘Link to Table C’. However, the name of the linked-record field does not change. You don’t notice this because you’ve undoubtedly given the field some sort of meaningful name in context of your data — for instance, something like {Prospect} or {Next Task} — because otherwise it would have a default Airtable name of {Field ##}, with ‘##’ indicating the sequence number for that field.

If I have or create a lookup field in my main table, the ‘Field on this table that links to the records you want to look up’ value will show the original name of the linked-record field, the value of which now refers to a record in [Table C]. Again, though, this probably goes unremarked, because the name of that field most likely describes the relationship rather than the linked table.

Where this becomes an issue is when following a reciprocal link to a table with a changed name — for instance, if I change the name of [Table A] to [Main Table] and later try to create a lookup field in [Table B] (or, for that matter, [Table C]). While the configuration of my reciprocally linked field will correctly show ‘Link to Main Table’, the field’s *name" will still be {Table A}, so under ‘Field on this table that links to the records you want to look up’ I’ll only have {Table A} as a choice: There won’t be an option for {Main Table}.

Now, I’m not privy to Airtable’s rationale behind their architectural decisions, but I assume it was felt that automatically renaming reciprocally linked fields would cause more harm than good. As far as I know, there is no other situation in which Airtable automatically changes a field’s *name".² In addition, the possibility for confusion occurs only when the reciprocal link retains Airtable’s default name; if you’ve given the reciprocal link a name representative of its logical value, the name of the underlying table is unimportant. (Personally, I try to name both linked and reciprocally linked fields {Link2[Whatever]}, with [Whatever] indicating the meaning of the linked field. For instance, in a ‘ToDo List’ application, my linked field might be called {Link2SubTask} and my reciprocal link {Link2MainTask}. It means I have to remember to rename reciprocal links, which I don’t always manage, but it keeps later name changes from causing difficulties.)

The one place this is all falls down is when dealing with duplicated tables — you’re going to end up with confusing links. Even worse, should you decide v 2.0 of the table is the one you prefer (that is, the modified version of the duplicate), you’ll have to modify every field and formula that references a value in the linked table. And you’ll have to do so before you delete either the original linked table or the original linked-record field; other wise, you’ll be troubleshooting broken fields with no earlier context to guide you. Frankly, though, I’m not certain how this could be handled otherwise, given Airtable is not perfectly omniscient.³

Of course, if your original description was completely accurate, and your base is retaining the original table names, you’ve definitely uncovered a bug, and you should email support@airtable.com with a link to the base in question. (You can find info on how to report issues and share bases with Support here.)

---

1. In Airtable parlance, curly braces — ‘{’ and ‘}’ — are used to indicate fields; in my posts, I use square brackets — ‘[’ and ‘]’ — to indicate tables.
2. Although it does change references to a renamed field, as one would expect.
3. Of course, given some of the posts in the Product Suggestions forum, it appears perfect omniscience is a desired feature… .

[Elvin_Roest1]

Thank you for your elaborate answers all, apologies for not getting back to you before. Actually, I understand most of the comments but I think my issue is different. Does this screenshot illustrate my problem better? Again, the issue is that the table names appear under the name they were originally created under, not their current name.

paste.pics/f8675886633f8631060b938e6e555089

[Kevin_McCall]

I’m having the same problem. Here’s how I encountered it:

1. Create a new table, the Airtable app named it Table 6
2. Create fields in my new table, calling one Status
3. Rename the new table to something else, like “Customer”
4. In a previously existing table, add a Rollup field
5. Configure the rollup field to use the new table, but only the original name “Table 6” appears in the list of tables, but if I select “Table 6” I get an error and cannot save the rollup field.

[Denis_Filion]

I have this exact same problem.

[Elvin_Roest]

Is anyone aware of a solution to this? It seems years after the fact this is still the case..