Very slow input in desktop version but works great in mobile version.

[Boleslav]

I have a column card number (HID) which ref to another spreadsheet with 50000 rows and 2 columns HID and CSN (unique card number). In desktop version any action on the HID field is delayed for 5-10 sec. For example, I clicked on a HID field and need to wait 10 seconds for it to load, entered a number and need to wait 10 seconds for it to show the options. If I work from a computer in the Appsheet editor in the window with the mobile version everything works fine and shows the options immediately without delay, from a smartphone in the application everything works fast. If I open in a browser on my smartphone in the mobile version everything works fast, but as soon as I switch to desktop version in the same browser everything works again with a delay of 10 seconds. I used chrome and opera browsers. Data in appsheet database, in google spreadsheeets same result. No formulas used anywhere, no virtual columns, this is a test application that is set up only to test this function. I wanted to know up to how many rows can be used type ref.

I don't know how to make it public for editors.  Here's a link to the app. https://www.appsheet.com/start/262632d1-85b9-4347-9630-b7da1c20fca9

[Joseph_Seddik]

Does the user really have to choose one of 55K+ sequential values in a dropdown column every time he needs to edit or add a new row? Can't you have a way of segmenting your data or reducing the options to choose from based on other column values? I tend to think you might have better ways of remodelling your data. 

[Boleslav]

This option just makes it more convenient, we have about 50k employees and students in the database with unique numbers, not all employees and students remember their numbers correctly and seeing the person's name can help. It's also handy that you can add a new customer from the same form. Yes I can do it differently, I'm curious why it works in mobile version but not in desktop version. The app is just for testing features and to see what are the limits on the number of rows for ref type. I don't need to get around the problem I know how to do it. I just need information if it's normal that it doesn't work in desktop version.

[Joseph_Seddik]

What I know from experience is that a table with 50K rows is well beyond the practical limit of a spreadsheet-based table. I don't know about the difference between mobile vs desktop behavior. Normally you'd approach your app with optimization's best practices in mind for every step; so for example limiting students to student data, employees to employee data, segmenting them in departments, sections, etc. 

[Boleslav]

However 50 K rows works great in the mobile version even in a browser. I understand this beyond the practical limit, but I have no way to split some of the data. I don't have reliable criteria I can use to do this, the incoming data I have imposes limitations. And I can't change them. Employee, student, and alumni numbers are no different. Sometimes students are also employees, sometimes employees don't know the name of the department they work in. It is difficult to separate them and in the database the positions are not always correctly selected. I just need to load the first name last name from the database and I can do that through formulas in and it works fine. But it's inconvenient to add a new customer. I am now planning to test type ref with SQL database. I don't think it will make a difference, it looks like this delay is not related to the database. But it's interesting to test.

[Joseph_Seddik]

Use Security Filters to segment your data according to whatever criteria you have, even if not perfect, work on the existing dataset to clean it and organize it as much as possible (this is also your role), provide the organization an easy way to further organize the data and assign people to different categories through your app, work with them on a data management plan, and implement restrictions to avoid future inconsistencies and data duplication. You should know how to take chaos from different sources (e.g different sheets each with a different format), clean it, normalize it, model it correctly then load it into your app. This is the real value you'd bring to the organization, not merely making an interface, and you should really spend time and effort first on this task. 

[Marc_Dillon]

---

@Joseph_Seddik wrote:

What I know from experience is that a table with 50K rows is well beyond the practical limit of a spreadsheet-based table.

---

I would disagree with that. I've seen several apps with that approximate amount of records working just fine. Especially since in this case it's only a 2 column table. There's so many different factors that affect performance, but in a vacuum, 50kx2 should work fine.

[Trevwiller]

One thing that could help make this faster is using databases if you have access to them. They are not perfect but are faster. I do agree with Josepgh_Seddick. You have to split those down into separate organizational units this will limit the amount of data the app has to read through to find your input. Also if your organization continues to grow the time it takes to load will increase.

[Boleslav]

I tried the Appsheet database, it didn't make any difference. I will try SQL database but I need time to set it up. It seems to be a delay due to the interface. If the problem was in the database there would be a delay in the mobile version too, but in the mobile version everything loads in less than a second. I thought that the app was caching the information and because of that it works faster, but from the browser it works just as fast. And if I switch to desktop version in the same browser, there is a delay of 10 seconds. It doesn't seem to be a database problem otherwise the delay would be in both cases since the database is the same.

[Marc_Dillon]

That's odd. Are you using the new desktop preview version? Either way, this seems like something you should be reporting to support.