BIG Tables Use expectations in the editors

Ask for Help
1

I converted a Google sheet to a BIG Table (2550 entries so not so big) but when I search in the Data Editor (ctl-f) I rarely get the correct search the first time or two or three. It seems that the BIG Table sync is very slow….like 10 seconds or more. Is this typical and is this what is expected in real-life App performance.

2nd issue/question: when I try to look at the row in the layout editor (click data in the lower left) I get no results. Is this expected? BTW..I searched the table for the row because it didn’t show up in the layout editor via the ‘data’ button. After 2/3 refreshes it appears the BIG data is cached since (ctl-f) searches are fast. But the layout editor still does not show any row data from the BIG table.

Thanks for any/all insights.

image
image873×148 9.51 KB

2

There’s also a chance the value isn’t loaded yet at that point, rows only get loaded when you scroll down further?

After 2 hours, have rows started to show up?

3

It did not show up….but here is my next test.

I have a table with Accounts. This used to be a google sheet and I moved it to a GBT in October. I was more worried about Queries and Calculated columns than seeing the data in the layout editor.

I just tried searching for an account (ctl-f) and it has not shown up. I scrolled through the list in the data editor and found the account and clicked on it.

I then did another data editor search (ctl-f) and found the account. Then I went back to the layout editor and the (data) click did not show the record in the layout editor….yet (ctr-f) found it in the data editor.

Glide cache/uncache seems to be VERY aggressive.

4

The reason big tables are fast is because they are not loaded in their entirety in your local cache. Only the data that is needed at the moment is loaded. Normal glide tables are cached in their entirety on the local device. That’s why there is such a tight row limit with glide tables. Things can begin to slow down when you store the entire database locally. Ctrl-F isn’t going to find something that is not there. When you scroll down, it’s dynamically loading the new data on the fly and unloading data that’s no longer needed.

5

Correct, but after it was ‘found’/cached in the data editor via (ctl-f); the layout editor couldn’t find the record when I checked with the (data) button.

Different caching/sync methods I suppose.

6

I was once told by somebody in Glide Engineering that the Data Editor and Builder Layout Editor each has its own independent connection to the Glide back end. That was a few years ago, so I have no idea if this is still true, and if it applies equally with GBT (I would assume it does).