Yes… That is the plan!
But currently it’s in very early stages…
All counters then need to be local or synced or directly be auto generated by SQL…
To make it easy! I have given out the entry field…
I am sure phase 2 will be better once i fix all the loop holes and work on suggestions…
I just tried to search with an empty search and i had to wait for a few minutes before it returned nothing…
Is it possible to restrict that it shows an error if the search bar is empty?
Second question…
The App seems to take long to return searches…
My question would be, what would be the trade off between using glide tables as a database for a Pro App and then dealing with the lag that you normally get when you exceed the 25K row limit?
I guess my question is in its current state (Your App) what advantages does it offer compared to using glide tables (For public Pro) and dealing with the slowness after hitting the 25K rows and beyond?
This is not to take away from the great job you have done but just for information purposes or use case example.
This is more or less a proof of concept at this stage… I am sure Glide tables would be faster till 25000 rows…
But as i mentioned! My database currently holds more than 130K+ records and still has viable functionality… True this is slow today a bit…
And this currently is based on MySQL and Google scripts…
If we go with a stand alone server with a database connection on always and cached.
It may be a lot faster and alot of data can be handled simultaneously.
UI currently requires a lot of upgrade too, such as informing of no rows or loading icon as such.
This is phase 1 beta test and proof of concept… will be better with the next launch…
Good work although the delay problems were going to be obvious.
If you can run a Query from Glide directly by using an Experimental Code column, the reply could be faster but I think it isn’t something native or easy to implement in JS, right?
So, you can remove GS script from the middle of process and get faster replies.