Will,

set soapbox on

It's sorta silly to give the user a 22,702 item long cbo in the first place.

Why would the user want to interact with your system like that anyway? Your cbo is populated with employee numbers which makes that the incremental seek value. Why not develop a much faster UI that uses two textboxes, one to enter an employee number and another to allow them to enter a last name. Get the "key" data from them and then present them a candidate list to select from if there is more than one match? ie they type "smith" in and you let them pick the one smith they really want. If they type in a employee number you go directly to that employee's record.

Your network admins will be happier with your app because you'll stop slogging so much data down the wire, your server admins will be happy about the reduced load on your file server and your users will be happy because they don't need to wait for huge cbos to be constructed chewing up megabytes of memory.

Besides what happens to your app in VFP7 when the 32,501st employee is hired?

>Wow, that's a pretty BIG BUG and certainly enough to stop me from working in VFP 8.0 since my framework uses the same approach for all comboboxes. The code ran fine when testing with 8.0 Beta. What's worst functionality that worked in Beta in now doesn't or advertised functionality that never worked?

>>>My problem is a "larger-than-preferred" dropdown consisting 2 fields from a 22,702 record table. This calculates to 45,404 elements which is under the 65,000 Maximum # of elements.