Ultrawingrid Progress 10.2B

[konfuncio]

Hello:

We are using Progress Architect to take adventage of .NET programming and try to modernize our application.

However, when we load an ultrawingrid with only 40.000 rows we are experiencing a very slow performance when using filter options (supposedly on client side).

Please let me know if it is clear enough or you need more information.

Kind regards and thanks in advance.

Alberto.

 

[tamhas]

*Only* 40,000 rows? That is a lot of data to send to the client. Have you considered batching? There are batching discussions on PSDN.

 

[konfuncio]

Yes, it´s a lot of data, but we guessed grid should be able to move them. Moved them slowly, but not so much!

We tried batching mechanisms, for exemple for 100 rows (that makes the first load of the grid quite fast), but the problem there is when the user selects filtering before scrolling down the grid, then of course he will only obtain a filter result for these 100 rows. As far as we know, the solution consists on programmatically develop all the filter options directly in the grid events (and there are a bunch of them), assuming that it is entirely possible. Unfortunately, we can´t take this amount of work in our project.

I certainly rewied psdn forums for filtering/batching issues and didn´t find another way to get what we need without involving so much development. This is why I started this post.

Kind regards.

 

[GregTomkins]

Our app is based around the assumption that you never want to send more than 100 records across the network at a time. 40,000 rows? I would think that even on a super-fast local network, the time do do that would be unacceptable.

We do all our filtering server-side; the client passes the filters across and then gets back the first 100 records that meet those criteria, and can request the next 100 by scrolling down and so on.

One flaw with our approach is that you can't do little tricks like click on a column and have it instantly resort dynamically, the way some mostly-desktop-only apps (like MS Outlook) do. That kind of thing is tough when you are looking at tables with 10-20 million records, being accessed across a network, though.

 

[konfuncio]

Ok, thanks for the repply. Now I understand better how the filtering works.

Currently, we have several .w programs that retrieve large amounts of data (like these 40.000 rows). We have implemented some filters by executing open-query statements and the result is fine (queries processes data almost instantly). Our aim was to move our app to this new environment using the most of the new .NET capabilities the better. Filtering seemed to be a very powerful tool we wished to take it for our scenario, but after your explanation that seems impossible.

Now comes up a question: if the filter is an option to manage small amounts of data (100 records), in what scenario is it useful? If I have a grid with 100 records, I can work fine only by scrolling up and down. From our point of view, filtering is useful with many rows in client side; for a few rows involved, it simply becomes a funny tool to play with the data.

Kind regards!

 

[Marian EDU]

ultragrid filtering is done client-side, meaning it will filter out rows for what it was loaded (simply hide them)... what you probably need is to replace this with server-side filtering, something like when a filter is applied to the ultragrid control instead of doing what it knows (filtering the rows that were loaded) it will send a filter request on the back-end and get a fresh new batch of records filtered as per client criteria.

anyway, don't make the confusion between client-side and server-side filtering... ultragrid is a nice component but the default client-side filtering is less than useful as you've find out for yourself

 

[GregTomkins]

In our situation, client-side filtering is rarely useful, because in our app, the user almost never has more than a tiny fraction of the entire potential result set.

I have thought about (a) enabling client-side filtering only when the client scrolls down enough to get all the records, or (b) enabling filtering in areas of our app where the nature of the data is that the # of results will never be very big.

I think that would be inconsistent and confusing though, so we don't do it so far.

In our case this same general thought process applies to client-side data handling in general. We also don't (generally) allow client-side Search or Sort, for the same reasons, though in a few cases it would be useful and sometimes I think we are throwing the baby out with the bathwater.

 

[konfuncio]

Excuse me Greg, when you say 'our application', what do you mean, exactly? OpenEdge .NET? Your own customer application?

Sorry, but I don´t quite understand what are you talking about exactly. Maybe I still need another cup of coffee, but what is what you don´t do it so far?

As far as I understand, filtering isn´t much more than a dressing issue, and that is quite disappointing to me because it could be a powerful tool for application development, indeed.

Many thanks again for your quick responses.

Kind regards.

 

[GregTomkins]

'Our application' is mostly a Progress WebClient app that does not use any .NET controls and relies primarily on the Progress browse widget. But I don't think that makes any difference whatsoever to this discussion.

'What we don't do so far' is any kind of client-side filtering, sorting, or searching. We do (almost) everything server-side. That's because the # of records we are dealing with is typically in the 10's of millions, and we have 1000's of users accessing data from the West Coast that resides on servers on the East Coast.

I'm sure there are apps where client-side filtering makes sense, but for us, and I daresay most apps with large potential data sets and remote databases, it's mostly useless.

 

[konfuncio]

In this case (progress browse widget instead ultrawingrid control) there is no problem. We can manage 40000 records without problem. Our trouble is when we try to pass this functionallity to then new .NET based environment. So it does make a different to our discussion xD.

Anyway, now I am getting clear that I have to forget about client-side filtering, because as you said, it is confusing (also for us) making available client filtering for some apps and don´t do it for others.

Kind regards!