To implement Dragn ideas in the web, use the following algorithm:

1. User will type some first letters of customer name

2. If an attempt is move out from name field, a call to Webserver is made.
Sample of such call is at www.ashleyit.com/rs/rscookie.txt.
This call returns 30 matching customer names and customer IDs . Those names are displayed to
user in separate pop-up window. If user makes selection,
field contents should be replaced by customer name. Selected Customer ID must be saved to hidden form field.

3. If no match, an error message should be displayed and name field
will not lose focus.

>Bruce,
>
>Actually, this is not for me :) I like your and Dragan's ideas.
>
>>Nadya,
>>
>>If yours is a LAN app using DBFs on a file server, then incremental searching is viable, even against 250,000 plus rows, so long as you're indexed on the search field(s). I have done this with a quickfill textbox accompanied by a set of 3 grids showing related data from various tables. It ran quite fast, and showed lots of information to the users. Nick N's GridHighlighter class played a key role, too! I didn't perform any Soundex() functions, though!
>>
>>In the quickfill textbox's KeyPress(), I check for DnArrow. If they press DnArrow, I shift focus to the list/grid. That way, the user can type until they see the item they want in the list, then DnArrow he selection - without having to press the TAB key to move down to the list.
>>
>>If you're querying SQL-Server or over a web service or other "remote" data source where SEEK() can't be used, you could wait until the user types 4-5 characters before starting to search at all, then use SQL pass-through or a parameterized remote view to fetch, say, the TOP 25 rows matching their input so far. You could then display the fetched rows in a grid or listbox for viewing and selection. I haven't tried this approach, but it could work depending on how fast queries against your data source actually run. <g>
>>
>>The idea is that you could find some "in between" that's not as resource-hogging as searching on every keystroke, but OTOH doesn't require the user to fill in the entire text before beginning to search.
>>
>>Best of luck on you GUI search! <g>
>>
>>- Bruce
>>
>>
>>>Hi everybody,
>>>
>>>Suppose, I have a huge list of items, say, users - more than 10000. I need to design an interface with the ability to quickly find the necessary person. What kind of interface would be convenient for this task?
>>>
>>>Thanks in advance for sharing your ideas.