Thanks for your replies..i appreciate it.
Let me reply to each solution presented:
>Are the data in the combobox static? If so, you could pull all the data >across into a local cursor when your app starts and leave it there, ready to >be used in your form.
sorry, the data is not static.. ie if the client inputs a customer on another form and goes back to the already open DR form, she expects the newly inputed record to appear in the combobox..this is automatic in a non-client-server vfp app.

>
>If not, and you have to freshly query the backend for each incremental seek, it's more challenging. Some possible strategies:
>
>1. Re-query the backend after each keystroke. Probably slow, and likely not >necessary.
this is the direction i'm leaning towards, to what i have in mind.. but the query needs to be smarter, in that it need not query all 500 A's (if A is pressed) but only the first 20's since that is just what will visually fit in the list below the combobox..therefore it won't be slow at all..

>
>2. Employ a separate text box, where the user types in the "search" string. >Only after they leave that text box do you update the combo box contents. >Most efficient but adds extra controls to the form.

this is like google search, but as i've pointed out the client is insistent on an incremental search combobox..as in, press 'A', and list of all records with first letter A pops up in a list below the combobox.. press B and all records with AB's appears..

>
>3. Same as #1, except you implement a timer so that queries happen only if >the user pauses for "x" amount of time i.e. not while they are in the middle >of typing multiple characters.
Delay with appearance of the queried list is not acceptable, ie if A pressed then B, list of AB's must appear (and appear as fast as the user types the letters)

>None of these address the more fundamental issue of scrolling. For example, >suppose by default your combobox shows the first 20 items starting with "A". >If the user wants something they know starts with "B", some will just lean >on the down arrow and expect it to scroll down into the "B"s, rather than >typing incrementally. Unless you've loaded a big chunk of the data, you >can't please these people with less than a fully-populated combobox.

I think that if you have a very intelligent query that takes into account
that only a few records actually is visible at any time, one can have a very fast loading combobox (just loads the first 20 records at initialization), a fast refreshing combobox (just loads fist 20 records that matches the letters typed) and a very fast scrolling combobox (just loads the next 20 records when the user scrolls down, which may have to include records not matching the search string, such as the "B"s appearing after the typed "A" search char, as described above)... also at initialization this very smart combobox need to check the total records so that the vertical scrollbar will appropriately reflect the size of the record, so that the user can go to the middle or last record of the scrollbar in a zip, even thought the data is not yet pulled in. it just have to quickly refresh the visible list (just 20 records at any time, therefore very fast and almost as fast as the user moves the elevator)

I'm really surprised that the client-server world doesn't have this kind of combobox as standard, and everybody just makes do with asynchronously pulling in data which means a lot of waiting. And it's not just about this combobox but the way data is accessed in general. i mean if you open a remote view, and execute go bottom, you'll have to wait till the underlying query processes from top to the end of the record.. i mean i just need to see the last record and cant the computer figure that out?
Anyway, i do think there is a combobox already existing that i can download that fits the above description..