I am currently manually filling a grid, but for over a thousand items, it is very slow (tens seconds perhaps to fill, but feels ages). I have a filter mechanism such that it can be restricted to matches, but that then has to delete and refill. Filters are faster because less to do, but then you clear the filter and it takes ages again.

So I need to be able to filter much more rapidly. I could fill a database table or whatever it is that stores the data, and apply that to the grid? The grid is quite customised at run-time as I have about ten variations of the data to be displayed. But I could probably have a single table spec, and empty rows as appropriate.

But can I filter that table for display into the grid any faster? Or would I copy from one table to another? How fast is that? All items have a GUID for their ID, if that helps or hinders.

Is the grid "virtual" from a database table? That would probably resolve most of the issues.

Any suggestions welcome.

--

Matthew Jones

Will any user want to actually scroll through and work with 1000+ items though?

Web based solutions are better served from short trips to the server for small amounts of data rather that hosting 10,000 records in the client side (and filtering over and over.....really... why?) - I think a redesign is in order here..

Just my 2 cents.

Walter

Mark Brooks wrote:

> Will any user want to actually scroll through and work with 1000+ items though?

LOL. Two responses basically the same. The simple answer is yes. My existing solution does filtering, does aim to reduce display, but yes, this is something that the customer wants, so the customer needs to have it.

--

Matthew Jones

"Matthew Jones" wrote:

>>LOL. Two responses basically the same. The simple answer is yes. My existing solution does filtering, does aim to >>reduce display, but yes, this is something that the customer wants, so the customer needs to have it.

Ok, given you have a customer demand, next proposal is paging, implemented server-side

Matthew

<< Or would I copy from one table to another?>>

Have you considered using views rather than copying tables?

Also, if you use scalar queries in the column list, you can make the view sensitive. For example,

CREATE VIEW "StudentMaxResults1" AS
SELECT
   FullName,
   Score AS MaxScore,
   CourseID,
   (SELECT CourseName From StudentCourses SC2 WHERE SR0.CourseID = SC2.ID) AS Course
 FROM StudentResults SR0
 WHERE
  <more>

Richard

<Mark Brooks> wrote:
> "Matthew Jones" wrote:
>
>>> LOL. Two responses basically the same. The simple answer is yes. My
>>> existing solution does filtering, does aim to >>reduce display, but
>>> yes, this is something that the customer wants, so the customer needs to have it.
>
> Ok, given you have a customer demand, next proposal is paging, implemented server-side
>
>

Getting the data takes moments. It is the grid specifically that is the
problem. Let’s focus on that!

--
Matthew Jones

Matthew Jones wrote:

<Mark Brooks> wrote:
> "Matthew Jones" wrote:
>
>Getting the data takes moments. It is the grid specifically that is the
>problem. Let’s focus on that!

BeginUpdate
...
EndUpdate


That way you aren't redrawing the grid constantly, just after ALL the updates are done.

Erick
--
Matthew Jones
http://www.erickengelke.com

erickengelke wrote:

> BeginUpdate
> ..
> EndUpdate

Already active...

--

Matthew Jones

Richard Harding wrote:

> Have you considered using views rather than copying tables?

I was thinking in the EWB layer, not on the server.

--

Matthew Jones