I appreciate the reply. But as I mentioned the concept of loading 12,000 or even 20,000 names into the Combo Box is NOT an issue at my other customer sites running TRUE 1GIG networks.

It is interesting how programmers always focus on the programming concepts and code re-writes. But this app has been around for 15 years, and users like it the way it is. Only if I can figure why at THIS particular customer site, it is acting this way?

Thanks Again.

>Cyrus,
>
>>>The Dropdown is the means to type in customer's Account number in an Order Entry form to locate the customer from the entire database. There is noway to limit that by indexing methods.
>
>If the customer table is a dbf, the faster sites are probably benefiting from VFP's local caching which is the reason you see OK performance. This particular benefit of VFP sometimes isn't appreciated/remembered by people using C/S backends. Perhaps you can figure out whether/why VFP caching is different on the slow machine?
>
>Even if you can, and realizing that this may be an established app that can be difficult to change: people here routinely pull customers from databases with millions of records with instantaneous performance. So I think people are disagreeing that the combo is the only way to achieve it. IMHO using the whole table every time will always create a risk of terrible performance, even in VFP, whereas a targeted query can continue to work fine across a 56K dial-up connection against any size database.
>
>Would it be possible to add code to perform a query based on user entry to populate the combo with a handful of possible candidates rather than the whole customer base? That should work quickly every time.