You’re right it would be great if this was available more directly than it currently is.
You are right, you need to use a unique index to link tables, but you chose _id as the index, and you could have chosen Autonumber, which is also unique.
In some circumstances I could choose to use Autonumber, which has the advantage of being sequential by date created, but when you use a lookup field to find cells that are themselves linked to records what you get in the lookup field is _id’s and you’ve no control over that.
@Balanced_Kitchen You should also be able to access the properties by name like you would with any other object. You can use the get property of object block in the object section of the toolbox to get the values. Generating a JSON is certainly one purpose but it isn’t the only.
Thanks to @Tommaso we have identified the issue with switching screens and are working on a fix now.
I’ve seen your feedback regarding being able to get the ids of the rows. We will look into possible solutions.
1 Like
@shane.holohan1864qsw I put all the row IDs in a list variable upon row creation 
. It’s a lot more work for us this way because we have to maintain that list when we delete and add new rows, but it’s working pretty well. Whatever data I’m looking for in the table can be found using this block 
, and then I just use that to find the row id in my variable and add it to the table, like so:
I think this is basically what @actech is doing.
It will definitely be a lot less confusing for people if/when they add a little ditty of code to do this automatically for everyone upon row creation.
Thanks @Steven. I’ve looked at the get object block for the rows in the data source, but this requires you to know the row id to get the row id, so still not a great solution. I think it will be confusing for people until you just add the row id to the table upon row creation. Perhaps a simple solution for now would be to just copy the row id into a new column on row creation (similar to what I’ve done in my previous post). That may duplicate data for now, but would make it far easier for people to use these components.
when you use the search field to search for cells that are themselves associated with records, you get _id in the search field, and you can’t control this.
I’m sorry, but I didn’t understand this point. Can you give an example of such a request? What do you mean I can’t control it? I can control everything because I get records that have all the fields I need, including those that link to another table.
The many-to-many relationship occurs through the auxiliary table, where the indexes of both tables are used. How is it that I can’t get indexes when querying?
@actech my app is somewhat like a dating app, where people are matched using a double opt-in. If both users select one another a match is created. In this screen shot of the main Users table in my Airtable base, each user is listed in column “Name” and their matches in column “My Matches”. In Airtable these are shown as names but when the cell data is parsed in Thunkable what you get is the _id for the user’s row.
The selection ‘events’ which lead to the matches are recorded in a Matching Events table.
It is by looking up this table that the My Matches cell in the Users table is populated. My app writes to the Events table and reads from the Users table. All the calculations are done in Airtable.
Of course I could use a different unique identifier of each user, but Airtable will still return the _id when I lookup linked fields that link to each user and then read that into Thunkable. I could presumably convert the My Matches field data into a string of some other unique ID and read that, but that just seems to be adding complexity.
@athornock I use the spreadsheet component not the data viewer component because I find it more flexible, and because I can’t write to a linked field using the data viewer component (a known issue perhaps?). But otherwise I’m doing pretty much exactly what you’re doing - find a row using a cell value, use that list index to find the _id (from a list I’ve created) and then add/change data and update the _id list. It would be much easier if the _id was available in the way everyone it seems would like it to be!
Thank you, I understand. You chose the method using the Link field, which contains a list of IDs. You’re right. Since _id is used in this case and it is also easier to use _id to overwrite data in AirTable, you need access to this field and creating an additional field with the value _id is a good workaround.
1 Like
Hi @athornock,
I request a field in the “list of values …” block:
If there was a new filed like “ID” it would be easy to iterate over every row of the local data source and have the ID for linked database fileds.
You are right, that the ID in the “get object block” gives no new information, because we need the ID to feed into that block. But with the “list of values …” it should work?
1 Like
@shane.holohan1864qsw that makes sense. I tried using airtable for my use case too and I was having issues. I too found that I had to do a bunch of extra formula columns just to reference everything. It was a lot more work and complexity.
I found it funny that Thunkable decided to use row numbers for airtable, but row ids for it’s data sources component.
Ultimately, I decided I couldn’t use airtable because in my use case every user needed to have it’s own table and as far as I could tell it was difficult if not impossible to generate a new airtable table on demand through code. So I had to create local data sources anyway to accomplish it.
The other thing I was worried about was security in my use case.
1 Like
@Michael_Rogulla I totally agree. That would be the best solution and things will be confusing for people until Thunkable implements what you’re suggesting. As you can see from my example above, I basically did that on my own.
1 Like
This isn’t solved yet, right? I am having the same issues. My whole app is crashing because of this
I hope @steven or @wei could help us.
I reported the bug on the GitHub repository.
I tested it and it seems to work now! I can create new rows, watch them in a data viewer list, and there is also a new block “delete all”.
Perfect for me, many thanks to the thunkable team (@Steven … is there an @-adress for the team?)
My app still crashes whenever I open the data viewer list and then I make any changes to the data source, does this works for you?
yes, it works. Here is a sample app from me:
https://x.thunkable.com/projects/5f59e082c22d07967782afad/project/properties/designer/
@hernandezsilvaericko Please check that you’ve updated your Thunkable Live app (version should be 222) or, if you’re using a built app, please rebuild it and let me know if you’re still seeing the issue. It is possible there is another issue that we aren’t yet aware of that is causing your app to misbehave.
@Michael_Rogulla Glad to hear. I don’t think there is any way to tag the entire team but I’ll pass along your thanks! 
@Steven @Michael_Rogulla It is working now, but my built iOS app is totally blank when I open it. The backgrounds are not loading. Everything is OK on android.
Everything look fine in Thunkable Live, but when the app is published this happens.
How it should be displayed:
How it is actually displayed:
Thanks for following up. Just to clarify, you’re saying it works fine on Thunkable Live. It does not work on iOS when you’ve built the app. I’m not sure what you’re seeing on Android, does it work on Android when built?