ashish_me2
asked on
Reducing the time to populate ListBox Controls from database
Hi,
We have a Delphi 6 application that displays a DataGrid and a ListBox that are populated from a table of an SQL Server 2000 database. The DB table contains 1,55,567 rows and it takes about 4 secs to retrieve all rows from the DB.
Now, when we try to loop thru the recordset to populate the ListBox and DataGrid, it takes almost 3 minutes to get the data into the ListBox. I would like to know if there is an apporach using which this delay can be minimised as this is a client server application and the users get anxious about the delay that occurs in populating these controls.
Any help would be appreciated.
Thanx.
We have a Delphi 6 application that displays a DataGrid and a ListBox that are populated from a table of an SQL Server 2000 database. The DB table contains 1,55,567 rows and it takes about 4 secs to retrieve all rows from the DB.
Now, when we try to loop thru the recordset to populate the ListBox and DataGrid, it takes almost 3 minutes to get the data into the ListBox. I would like to know if there is an apporach using which this delay can be minimised as this is a client server application and the users get anxious about the delay that occurs in populating these controls.
Any help would be appreciated.
Thanx.
jpedef
Have you tried Datasets DisableControls, before starting to populate and EnableControls after populate?
ASKER
No, can you please explain about what this does.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It could be that I'm not quite getting it, but I don't think splitting information into pages is better then showing them as a whole. It still will be a lot of information. I'm with pritaeas here. if you really want to split those rows into multiple pages, a stringlist is quicker than a recordset.
In general, you should just limit the amount of data that you show to the user to something around 100 to 250 records. More than 100 is already quite a large amount, though. If there's more data to show than this, you have several options:
*) Show just a summary, grouping data and calculating totals.
*) Divide the data in multiple pages and allow users to jump to a specific page.
*) Provide the user a way to filter the data so the output is limited to what the user wants to see.
For example, say that you keep track of every phonecall made in your company. Your company has 5000 employees and half of them work for the helpdesk or are salespersons. You could imagine that this would be a lot of phonecalls. Now, after a year, you want an overview. How would you like to see it?
Would you like to see every phonecall in a grid? Let's hope not. Users are more interested in calculated results. E.g. a sum of call lengths per employee. Or the total number of calls per week. Maybe just an overview of all calls of Mr. X on date MM-DD-YYYY.
*) Show just a summary, grouping data and calculating totals.
*) Divide the data in multiple pages and allow users to jump to a specific page.
*) Provide the user a way to filter the data so the output is limited to what the user wants to see.
For example, say that you keep track of every phonecall made in your company. Your company has 5000 employees and half of them work for the helpdesk or are salespersons. You could imagine that this would be a lot of phonecalls. Now, after a year, you want an overview. How would you like to see it?
Would you like to see every phonecall in a grid? Let's hope not. Users are more interested in calculated results. E.g. a sum of call lengths per employee. Or the total number of calls per week. Maybe just an overview of all calls of Mr. X on date MM-DD-YYYY.
Comment only
Am I missing something here...
Quote:
'The DB table contains 1,55,567 rows and it takes about 4 secs to retrieve all rows from the DB.
Now, when we try to loop thru the recordset to populate the ListBox and DataGrid...it takes almost 3 minutes to get the data into the ListBox'
Why are you then putting them into another grid (if this is what you are doing)...
If you need to format them or add extra unbound columns - you should be using a datagrid and populating using unbound events...
Data grids call batches of items which is easy when you think about it (using Top and Bottom predicates).
I can't see a scenario where you would be putting very large numbers of items into a listbox as being realistic in interface terms.
Who could possibly make choices out of millions of items - it makes no sense to me - please explain further.
Voodooman
Am I missing something here...
Quote:
'The DB table contains 1,55,567 rows and it takes about 4 secs to retrieve all rows from the DB.
Now, when we try to loop thru the recordset to populate the ListBox and DataGrid...it takes almost 3 minutes to get the data into the ListBox'
Why are you then putting them into another grid (if this is what you are doing)...
If you need to format them or add extra unbound columns - you should be using a datagrid and populating using unbound events...
Data grids call batches of items which is easy when you think about it (using Top and Bottom predicates).
I can't see a scenario where you would be putting very large numbers of items into a listbox as being realistic in interface terms.
Who could possibly make choices out of millions of items - it makes no sense to me - please explain further.
Voodooman
As already stated a listbox is not suited very well for the job.
It needs to hold *all* rows even while displaying only a small amout of entries.
Using a control to handle a virtual list is the way to go.
Such a control stores only the displayed values. Mike Lischke's TVirtualTreeView is the most renowned control of that sort.
It needs to hold *all* rows even while displaying only a small amout of entries.
Using a control to handle a virtual list is the way to go.
Such a control stores only the displayed values. Mike Lischke's TVirtualTreeView is the most renowned control of that sort.