I have a Select query set as a table's Data source. I updated a record in that table (from a modal edit form) and refreshed the query which refreshed the table's data.
But .selectedSourceRow is still showing the old version. The table's .data property is correct.
If I select a different row and go back to the edited row, the correct data is now available.
Hi Bradly! Thanks for reporting. We currently update selectedRow and selectedSourceRow upon selection, so the properties won't update when the underlying data changes. Would referencing the data directly, e.g. table1.data[selectedDataIndex] work for your use case?
Thanks, I'll try that as a workaround.
In the old table, I never encountered any problem with selectedRow not being in sync the current data and I believe this is the expectation for the new table as well, so I highly recommend that all references to the underlying data be kept in sync expect where it obviously should not be like an unposted update.
Ok this does work, the correct way to use it seems to be: {{tblCustomers.data[tblCustomers.selectedDataIndex]}}
I have a View Details modal and now every reference would be:
{{tblCustomers.data[tblCustomers.selectedDataIndex].dba_brand}}
instead of
tblCustomers.selectedSourceRow.dba_brand
A syntax which doesn't roll off the tongue so to speak.
Thanks Bradly, agree that this can become a bit unwieldy! I'll pass along the feedback for selectedSourceRow to stay in sync with data updates.
I just ran across this bug and landed on a similar workaround after a bunch of head scratching, so I'd like to toss in my 2 cents:
It seems bizarre that it's expected behavior for the object to be out of sync with itself. That, combined with the fact that (as @bradlymathews points out) it's different behavior than the legacy table, in my mind would indicate that this is more than just a bit unwieldy, and should be categorized as a bug.
If selectedRow and selectedSourceRow don't reflect state accurately, then there's no point in using them -- it just introduces risk for the developer. I'd hate to lose the convenience, but if they're unreliable, I'll just ignore them moving forward -- it's not worth it to risk these subtle, unexpected, and tricky-to-track-down bugs.
Whew, I was experimenting with a table-upgraded version of one of our apps and could NOT understand why the selectedRow data was out of sync on the duplication action that I was testing seemed to keep duplicating "old" info. Reminder to self ALWAYS CHECK THE FORUM! Thank you @bradlymathews 
I agree, I don't remember this this being an issue in legacy table, so this is a significant departure from something that you would otherwise expect to behave as it always has.
The workaround sure works, and thank you for that, but that syntax, ew.
Thank you @Schteevynn and @Ben_Reece for the input!
We're working on a fix this week, so that selectedRow updates as expected when data changes. I'll update in the thread when this is available on cloud!
@Schteevynn @Ben_Reece @bradlymathews The fix for this has been shipped and is in cloud! Thanks again for the feedback, we appreciate it a lot.
Can we get an on-prem release that fixes this issue as well? In my case, I have a table which has no records for the current query, but selectedRow has the last-known row data (for index 0) and selectedDataIndex is 0 (should be null).
Hey @eidolon, this behavior should be fixed in for self-hosted versions 3.0 and higher. Let me know if you still see it after upgrading!
Hi Kabirdas! I have the same issue in self-hosted Retool version 3.0.1
.selectedRow is still showing the old version while table's .data property is correct.
Thanks for letting me know @Asrover! Can you try upgrading to 3.0.8 and let me know if it's broken there as well? Will keep following up on this!
Hi - chiming in here as well, I'm on v3.11.0-6b59f4b (Build 121298) and .selectedRow data is currently not updating if the underlying data changes, it only uses data from when it was initially selected. It updates when someone deselects the row and re-selects it, which is undesirable.
Hey @ZachNagengast! Would you mind sharing a screenshot of your table settings along with the query that's populating your table? A short clip of the behavior would be awesome. I tried reproing this with a couple teammates using the default table settings but things seemed to work but there are a lot of settings here so it could very well be that we're missing the thing that's broken for you 
I've found the bug only exists with multiple selection mode. Here's a simple example - I have a jsonEditor datasource for the top table, and the bottom table has the source of table.selectedRows. Now when I edit the datasource, the main table updates right away, but notice that the selectedRows data does not update. Sorry for the long gif
Ah thank you so much for that repro @ZachNagengast! I've filed a bug ticket and will report back here when there's a fix.
Hey @Kabirdas please let know when this is fixed too!
We have a multi-select table that, after table refresh, does not update selectedRow 
Hey @ZachNagengast and @tristdrum, as of Cloud version 3.22 this should be fixed for multiselect tables as well 
