.NET Core limitations of SearchPanes
.NET Core limitations of SearchPanes
Etilapu
Posts: 2Questions: 1Answers: 0
Hy!
I installed the Demo package -NET Core and expanded the sample database, ("users" & "datatables_demo" table to 10.000 rows). I didn't change the demo code, so I didn't upload a sample.
All examples work correctly (SSP is lightning fast!) except SearchPanes. All operations are very slow (paging, filtering 6-8sec!) and the response json (900-1000kb) contains big searchpanes { options{ ... }} section.
If I disable searchpanes option on "phone" field or more fields it will be significantly faster.
I also tried the client side method. After a long load (7sec), everything responds immediately.
I would like to know if this is a limitation or a bug?
Thank you in advance for your help!
This question has an accepted answers - jump to answer
Answers
Phone numbers are going to be more or less unique per user, so I think that would be a prime candidate column to turn SearchPanes off on. SearchPanes is really for columns that contain repeating data so you can quickly filter them. For something like a telephone number, you'd just use the global search box rather than scrolling through thousands of rows in that table.
It probably shouldn't be 7 seconds slow, but I'm not at all surprised that the response time is significantly longer and it has a lot of data to transfer - it needs to send details about each an every telephone number, which largely defeats what server-side processing is there for!
So yes, I'd turn it off on columns like that.
Allan
Ok, its clear. Thanks for your help!