So let's start with when this should be used.  It is not uncommon at all on the forum to see when developers are trying to pull back tens or even hundreds of thousands of records to the local client so the end-user can pick them out of a list.  But let's be realistic, unless you are that robot from Short Circuit, there is absolutely no way that someone can deal with that many records at once.  Not only that, it is super slow to retrieve that many records making your end-user even more frustrated with this process.  So the solution...a threaded incremental search.

Solution
So the solution to something like this is an incremental search...not just any incremental search, a threaded incremental search.  This presents a fluid user interface to the end-user while presenting the user with only the information they have requested or for which they are looking.

So here are a couple of things that this sample shows:

1. Using a BackgroundWorker Thread.  To make this sample even more simple, I have used a BackgroundWorker class that comes standard with .NET.  For anyone who is new to threading, this will make this first step a little easier.
   
2. Only bring back a limited number of records.  This sample will never bring back more than 100 records.  You can manipulate this number to accommodate your needs, but I recommend never getting above 1000 as this can begin to really degredate performance.  You will see this in the query within the BO by simply adding the TOP 100 to the query.  This way if the end-user clears out the text field, it doesn't try to bring back every user in the database...that would be bad mojo.
   
3. Simple user interface, but solid performance.  You can get more sophisticated on more complex databases, but for this sample it is a very simple query just happening on a thread.  If you have massive databases, then it may be necessary to implement Full-Text Search on the SQL Server (or desired database and equivalent).  Just for reference, we have a drug database that we actually need to query between many different tables and adds up to millions of records...we use a similar approach to this sample, but Full-Text indexes are implement and a Stored Procedure is used.
   
4. One final thought.  When testing this sample, I was connecting to a remote SQL Server connection via a VPN at a remote office on limited bandwidth, and the results brought back were immediate and there was no sense of a pause when entering a search string.  This is because a combination of the threading and only bringing back a limited result set.