Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Cannot Scroll Down Datagrid
- Thread starter moonbase
- Start date
Right - so you are not performing a visual check of the whole 100,000 records, which is what we quibbled. It now seems that you are moving to a specific point that you want to check (on the basis that you know approximately where it is because of the sort order) and then manually checking somewhere within a few hundred records - which is, of course, quite feasible (but immediately lends itself to the idea of using criteria as per SBerthold's earlier suggestion)
I still remain to be convinced that you can successfully review ALL 100000 in 'a few seconds'. Even with 100 records per page, as you indicate, that is 1000 pages you'd have to examine. Even to achieve a minute, you'd have to be viewing, registering and absorbing 16 - 17 pages a second ... even if you are simply trying to just spot gaps that seems quite a feat.
I still remain to be convinced that you can successfully review ALL 100000 in 'a few seconds'. Even with 100 records per page, as you indicate, that is 1000 pages you'd have to examine. Even to achieve a minute, you'd have to be viewing, registering and absorbing 16 - 17 pages a second ... even if you are simply trying to just spot gaps that seems quite a feat.
I know when I've eyeballed let's say 1000 rows in Excel it can take several minutes to do the visual scan, even if what I'm looking for stands out from everything else. You may only be searching through 100 records, but it's getting there that will take all the time. At "10000 records per inch" you will be constantly overshooting and undershooting, until you start getting close, at which time you will switch to "slow scrolling" to avoid overshooting the mark again.
But even if I take you at your word, it still seems to be a method much too vulnerable to human error. The "eyeball" approach has a remarkable ability to fail even with very small datasets and glaring errors (humans get tired or mark something valid just out of habit). Why not automate the search, i.e. simply query for the records that have gaps and display those? And then program it not to let you proceed until the gaps are filled in.
The automated way will work 100% of the time. The eyeball scanner, even if you are the best that ever was, will always have a higher percentage error rate.
I don't agree with SBerthold that the grid behaviour is a "bug". The grid designers had to make trade-offs between responsiveness of the grid with efficient use of resources. I think they wisely choose to only use up a limited number of resources at a time, as it would be a waste to load all records when 99% of them are not visible to the user at any time.
I think the reason it works the way you want in Access is because Access has to load all the records anyways. I.e. in order to apply the sort, it had to load all records, and therefore already has them available to put in the grid.
But even if I take you at your word, it still seems to be a method much too vulnerable to human error. The "eyeball" approach has a remarkable ability to fail even with very small datasets and glaring errors (humans get tired or mark something valid just out of habit). Why not automate the search, i.e. simply query for the records that have gaps and display those? And then program it not to let you proceed until the gaps are filled in.
The automated way will work 100% of the time. The eyeball scanner, even if you are the best that ever was, will always have a higher percentage error rate.
I don't agree with SBerthold that the grid behaviour is a "bug". The grid designers had to make trade-offs between responsiveness of the grid with efficient use of resources. I think they wisely choose to only use up a limited number of resources at a time, as it would be a waste to load all records when 99% of them are not visible to the user at any time.
I think the reason it works the way you want in Access is because Access has to load all the records anyways. I.e. in order to apply the sort, it had to load all records, and therefore already has them available to put in the grid.
>I don't agree with SBerthold that the grid behaviour is a "bug".
You don't have to...but it is indeed a bug.
>The grid designers had to make trade-offs between responsiveness of the grid with efficient use of resources
There were no "trade-offs" needed, (except the deliberate limitations in the MS Version), as seen by the full version product, which doesn't have the mentioned problem.
The Apex, (now ComponentOne) dbgrid/grid in VB 4/5/6 was "specially developed for" MS VB and limited in functionality and it seems some of the problems in the past could have been caused by the imposed limitations. The Apex True DB Grid didn't have this mentioned problem.
The Apex company does not exist any longer after a merger to ComponentOne.
If you want the full version of ComponentOne True DB Grid:
You don't have to...but it is indeed a bug.
>The grid designers had to make trade-offs between responsiveness of the grid with efficient use of resources
There were no "trade-offs" needed, (except the deliberate limitations in the MS Version), as seen by the full version product, which doesn't have the mentioned problem.
The Apex, (now ComponentOne) dbgrid/grid in VB 4/5/6 was "specially developed for" MS VB and limited in functionality and it seems some of the problems in the past could have been caused by the imposed limitations. The Apex True DB Grid didn't have this mentioned problem.
The Apex company does not exist any longer after a merger to ComponentOne.
If you want the full version of ComponentOne True DB Grid:
[LOL]
What I meant is that the MS version of the db-grid is not the same as the True db-grid version, but probably a downscale version of it, with errors caused by limitations, or it is just a separate (parallel) component developed with the same basic logic but with errors not initially recognized or corrected in it.
Things like this incorrectly documentented Font property:
are suspicious (a Column Font property was removed, or just never built in for the MS version, though in the True db grid version)
What I meant is that the MS version of the db-grid is not the same as the True db-grid version, but probably a downscale version of it, with errors caused by limitations, or it is just a separate (parallel) component developed with the same basic logic but with errors not initially recognized or corrected in it.
Things like this incorrectly documentented Font property:
are suspicious (a Column Font property was removed, or just never built in for the MS version, though in the True db grid version)
- Status
Similar threads
- Locked
- Question