I have done some tests, doing a navLast after the first navFirst cause the reading of the entire table's rows, with 5000 rows, on my machine is about 10s, with 10000 rows is 20s and so on. I don't think that reading an entire dataset is a good solution. This is my issue.The major concert about whereClause is (for me) correlated with my major concern about the new navigation system, in which, (as I understand) you fetch all records systematically, this may cause problems using very large tables.
Why is this a problem? I do filtering in my applications to get small
resultsets and use the new navigation to display them. IMHO a resultset returning a lot of records are not very interesting. On the
other hand, retrieving the data is only a problem of memory - not more. And
IMHO memory is just an hardware problem.
The new navigation system gets only the records you need to display, e.g. if you have a resultset of 1000 records and looks only at the first 100 only 100 records will be fetched.
I think that we have to find a cleaner solution, but fetching entire tables in memory is not a better way to solve this.
For this reason only I like the idea of a filter that could be implemented leaving the way to get back to page navigation using a where clause (in the next days I will try to analyze more deeply the problem of the navigation).
Using sql for page navigation seems to be very, very difficult and hard to implement. Therefore the new system,
cheers, Sergio Moretti
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ DbForms Mailing List
http://www.wap-force.net/dbforms
