Data viewer rows desapear


I’m new on thunkable, but studing hard to improve my skills on app development.

I just started my first project in the last 2 weeks, that will use Firebase + Local Datasource + Data Viewer List approach to show data to the users.

I took some time to understand the logic behind the sync in the “do” blocks, but now after hours and hours testing, changing, reading forums, I can’t solve the Data Viewer List problem that happens after I load the data from Firebase to show the data to the user (I read the data and create the appropriate rows in the local datasource).

The rows shows up in the screen after my loading process, but in fact, just the last is there… all the others are missing. If you pull down to refresh the DataViewer only the last row is keeped, without any specif block deleting (all) the other rows. Since I don’t have control over the Data Viewer List behavior, I don’t know what to do.

I’m not sure if the problem is in the local datasource that loose this rows or in the data viewer list itself, because there is no way to check the datasource content when the problem happens in execution time.

I see some posts from 2020 talking about a similar problem, with no solution until now. This is very frustrating!

Just to avoid waste the time I worked on the project, and because I liked the approach of Thunkable, I want to count on you to solve this issue, or give me another way to implement this. I was thinking to create Labels and Buttons “in the fly”, but I think this is not an “elegant” way to solve the problem.

Any help will be appreciated!

Thanks in advance!

1 Like

Can you show your code block?
It’s hard to answer just based on explanation.

Please note I review my post, so read again the description of the problem…

Below the blocks:

1 Like

Check this project. This demonstrates the problem you are facing.

You are basically trying to solve an asynchronous issue using a synchronous approach. It will not work.

I see the app… same behavior… the rows desapear…

But I need to delete all rows before reload the data source to start over with the Firebase updates. The only moment I see this possible is just before loading it (when the screen open).

What is the recommended approach? I have no idea how to solve this. :upside_down_face:

1 Like

I’m just starting a meeting in the next 10 minutes, so will explain later or over the weekend what can be done to avoid such a situation.

1 Like

Thank you @muneer !

I’m anxious to learn from you!

1 Like

I have updated the project to see the effect from having an asynchronous block inside another asynchronous block.

I have added a list which is a Synchronous block and also added a button to display the number of rows in the local table and the number of rows in the list.

Use the same project link I already shared.

Yes @muneer , it’s absolutely CLEAR that the numbers never match! :pensive:

So I’m realizing that is almost impossible to use DATA VIEWER LIST to sync with an external database with this approach… Any idea how to use Data Viewer List in this scenario?

I’m changing to use LIST VIEWER, the only issue besides the rework, is the poor layout of this component…

1 Like

This is not what I meant to say.

I was using the List Viewer as a synchronous component alongside the create row as an asynchronous component.

We have seen that the outer loop which contains an asynchronous block (Web API in this case) works as expected and fills the List Viewer with all rows. From this we come to the conclusion that the issue is with the amount if time it takes the create record to actually commit data to storage which is long enough for the outer loop to run again and overwrite the previous data of the local table.

So, the issue is all about timing. The solution is to introduce a delay in the outer loop to give the necessary time for the slower asynchronous block to complete its operation. This way we can avoid overwriting of the data.

See the updated project.

I have added a new variable stillRunning which is turned TRUE in the start of the loop and only turned FALSE after the create row is done.

I also introduced a while loop at the bottom of the main loop to delay the main loop enough time for the records to be written to local table.

Check and let me know.

1 Like

Hi! I too encountered a problem like this before, but after rigorous de-bugging I found out that hiding/showing the data viewer messed up the rows being displayed.

Instead of using -

image OR image,

Try this (below image), as it would make the list practically invisible.

Now, in order to make the list visible again, you can try this -

(If your list has width set to fill container, then set the item# in above list to 2, if fit contents, then item# 3. Mine had in percent, that’s why I have used item# 1.)

If this doesn’t solve your problem, don’t worry. Then it’s an actual bug for the Thunkable team to solve. But in my case, the above approach saved me. Thanks!


Thank you @kartik14 for sharing that. I will keep it in my bag of tricks. However, I have 2 points to comment on:

  • First, my sample code does not involve setting the Data Viewer List visible option to True or False and therefore should not be the source of the issue in my sample project which was actually shared by @darweeshworkqxl in a different post (I must add that he demonstrated a very good example with this project).

  • Second, this solution only works with StP UI and will not work with DnD UI as the latter does not have options for width management as (Percentage, Fill container, Fir contents).

Thanks again.


I found a satisfactory solution, let me explain what I changed in my approach to fill the data source / data viewer and avoid this data mismatch:

Instead to read Firebase for each line to fill my local datasource (using the “get” block and inside of it perform a “create row” block), I did a single get in Firebase with all information in Jason format, transforming this return in a LIST. So I loop this list to fill the data source that reflects ok in the Data Viewer. Problem solved! Now data viewer behavior is ok, no lines missing anymore due the syncing issue of the previous strategy.

For sure, the asynchronous reading of Firebase to fill the local data source is creating this “timing” issue. But as soon you have an “ended” source of data there is no issues. So to feed data sources the approach must to be input from values already “finished” in memory.

Thanks for all help, it was challenging to understand what happens, but after lots of tests trying different approaches I learned how to deal with data sources / Data Viewers when you have to read multiple sub-records from Firebase!

My suggestion is to the thunkable team create a video tutorial with a real example to illustrate this.


I’m glad you solved your issue.

With Firebase, the synchronous is not an issue because Thunkable provides the RealtimeDB blocks to access data which are asynchronous but they also provide the cloud variables which access the data in a synchronous way.

This option is not available in other asynchronous blocks.