Link fields in other tables show up as options for a Lookup field, but not the link fields to the self-linking table. I see a feature request for Rollups on self-linking tables (Roll Ups for Fields Linked Within The Same Table). Is there no way to use the linked field within the table for Lookup at this time?
I’ve posted on this before. But seen no activity on it. I need this, soon if possible, because every single base of mine relies on this functionality.
I REALLY want a link-to-record within the same table to create another link column that auto-populates. Or a type that will.
I just spent all day trying to fudge around it, but it requires either (a) manual linking with every record, (b) at least two new columns on this and a completely separate table to copy/paste/formula, that requires basically a temporary duplicate entry and again, lots of manual entry. And this doesn’t update with new records.
I’d love a hierarchically-grouped view, but I could make do with just this one feature;
I want a second column to be created when I self-link a table!!
Does anyone have a self-updating workaround to this? Because for the life of me I can’t find one. And I don’t want to fiddle around with Zapier, either, because any solution I can think of with that requires a paid account.
Edit:
For now I’ve settled with putting each level of hierarchy on a new table, and I can sort of see them grouped in a hierarchical format.
With this (Probably the intended) use case, allowing lookups/rollups to pull actual linked records of linked records, so you can click through, would basically solve my problem.
Hi Jason,
What are you really trying to accomplish, not the technical, but the functional. From what I see, you’re trying to create a relationship or hierarchy within one table. Can you give more detail on the application and what you’re trying to accomplish from a functional perspective?
Seems like I’m missing something but could you just create a series of categories and then group on the categories? This would give you the visual drill down I think you’re looking for. The categories could be driven from other tables which are just summaries of the key table you’re talking about.
Please provide some more functional details.
Pierce
I have used series’ of groups as well as tables for this.
The use case tends to be where it’s a more specific type of the same kind of item, that has all of the same points of data. Either way above, this becomes quite a chore to ender data manually.
For example; For my art studies I have a list of animal types/species, and the variables I use to classify them are the same; but some are subspecies of others, or have very similar body types.
Similarly, I have a set of ‘aspects’ I can use that nest like that - for creation of fantasy creatures, etc.
Another list is of professions per time period to study; overlapping mediums, locales, roles, etc. are all ideal for tables. But nested by social rank, or specification, is more difficult.
Is there any other way of telling the data if a row has been outdated/obsolete by a new row, and witch row… or how else solve that problem?
In my db, i have a restricted membership, where you can only replace an old member leaving. I have no clue how to do this without the self-linking table and use it for a lookup…?
It’s not a perfect solution, but I often use a second linked table, typically with a single record, as an aggregation/calculation table to allow me to work around the restriction against lookups/rollups within the same table: Every row on table 1 is linked to the single record in Table 2. From Table 2, I perform rollups/lookups against Table 1; from Table 1, I lookup the desired value from Table 2.
While thematically and content-wise having little or nothing to do with your concerns, this base demonstrates the use of many-to-one links and the secondary calculations table.
Now you’re moving the goalposts. :slightly_smiling_face:
I would think the users-to-membership issue could be addressed by separating the definition of memberships from that of users, allowing a one-to-many link between the two tables – but the other issue you raise is a bigger deal.
You’re right: The current inability of allowing any sort of drill-through from a form to records linked from the initial table would be a show-stopper for you. (While I certainly understand the presumed reasons for that design decision, it doesn’t make it any easier to deal with.) I’m in the process of taking an app originally designed for use with a custom front end accessing Airtable data through API calls and converting it into a pure Airtable implementation, and the inability to address linked records through a form has given me the most trouble. At the moment, my best hope is to find a way to capture the data in a format that can be exported and manually re-imported later to create the necessary linked records – but, so far, the solution eludes me.
