Count Records... come'on

[itognet]

You really need to fasten up your rutines, fx. the Count table rows because it is a joke (sorry).
Sometimes I have around 9000 rows needed to be counted....

Why the %/"*! do you use a "for start to end then count row"


Just retrieve the RowCount from the grid or from the dataset: DBGrid1.DataSource.DataSet.RecordCount


If you realllllly want to use the "for start to end" rutine then don't update the screen while counting - this will make 2000% faster. :-)

[Support Team]

Re: Count Records... come'on

The way the system works is that to gain performance on regular use (e.g. not when you decide to count to 9000) the system does not fetch all data up-front, so when you have 9000 records in your Accounts database, for example, the system does NOT fetch all 9000 records and brings them to the client. This would delay everything.

Now all this is completely transparent to the end user. Namely, if the user scrolls down the data is fetched behind the scenes in the background and it is displayed to the user as if we have fetched everything up-front.

Not to refresh the UI may help though, however, it might break the continuous-auto-fetch system we have in place to gain performance. We'll see.

Thanks for posting.

[itognet]

Re: Count Records... come'on

Or you can use the sql select count(*)

What I mean is:
When I count a table in list mode, I will get the result in 2-3 seconds.
When I count a table in list mode with details, I will get the same result after 1 minute and 40 secs (for 1300 records).

We use the count feature serveral times a day.

[Support Team]

Re: Count Records... come'on

So, you already have a workaround when needing to count thousands of records :-)
Thanks.

[lpopejoy]

Re: Count Records... come'on

Second the sql option here. Could count thousands of records in milliseconds.

I don't follow the logic on screen refreshes during a count.

Anyway, we don't use it much and when I have to do any crazy queries, I use sql anyway.