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.