Q: How can I get ADO's Find method to find records based on the values in two different columns?
—Ali Siasifar
A: Well, the short answer is that you can't. ADO's Recordset.Find method works on one column, and one column only. Having said that, you could use something like the code in Listing A, which finds all records in a hypothetical table where the City and Country fields are "London" and "UK," respectively. It does this by finding the first record where Country is "UK" and checking the City field to see if it equals "London." If it does, we have found one of the records we are looking for. If not, we look for the next record where Country is "UK" and try again.
I have to ask, though, why are you using Find? Although Find is appropriate in some situations, using it to locate records is generally very inefficient, both in terms of speed and memory use. Find works by examining each record in a Recordset for the criteria you give it after you have created the Recordset and retrieved all the data from your database. Retrieving lots of unwanted records, particularly down the wire from a server, when you are really interested in only a handful—or even worse, just one bit of data—creates a lot of unnecessary overhead. Unless you have a very compelling reason for using Find, I'd recommend using an alternative approach, like filtering your Recordset or using SQL, for serious performance gains.
Filtering
The Recordset.Filter method filters out records that don't match one or more criteria. You can specify multiple conditions in a filter by using and or or, so using Filter would allow you to check multiple columns. For example, suppose we open a Recordset and execute the following code:
rs.Filter = "LastName='Adams' and FirstName='Lamont'"
The Recordsetrs would then contain only records where the LastName and FirstName fields were Adams and Lamont, respectively. If no records existed that match these criteria, rs would be empty, with rs.EOF and rs.BOF both true. To remove a filter from a Recordset, set the Filter property to an empty string ("") or the constant adFilterNone.
Filter does have its drawbacks, of course. Filtering a Recordset requires the creation of a new cursor and makes the "topmost" record in the filtered set the current record. Like Find, a Filter occurs on the client side after the Recordset has been created and data retrieved from the database. So once again, you could be retrieving more data that you need. All these factors contribute to make filtering a Recordset fairly expensive.
Unlike Find, however, filtering does makes sense in some circumstances, such as when you’re working with a large set of data on which you expect to make quite a few filter operations. In situations such as this, the overhead involved in creating multiple Recordsets retrieving small amounts of data may be less than that involved in one trip and multiple filters.
Restricting the results with SQL
Your last option would be to use some kind of a SQL SELECT statement to ensure that the Recordset contained only records with the values you are looking for. SQL processing is done by the data provider and is generally the fastest way to retrieve a restricted set of data because the only real overhead is the opening of the Recordset, which you have to do anyway. Most database systems interpret SQL with blinding speed, at least until you throw multiple joins or subqueries into the mix, so any extra processing time is negligible. Also, by retrieving only the records you want, you cut the waste and overhead of retrieving an entire table of data and filtering or using Find to locate the desired records.
I don’t have space in this column for a class in SQL, but every developer should have at least a basic understanding of it. I will explain, though, just for clarity, that assuming a table name of Customers, the SQL equivalent of the Filter we performed above would be:
where cn is an open connection object.
rs.Open "SELECT * FROM Customers " _
& "WHERE LastName='Adams' AND " _
& "FirstName='Lamont';", cn
A picture is worth 50 records
Throughout this column, I've been stressing that ADO’s Find and Filter methods are inefficient compared to restricting your result set with SQL. But how inefficient are they, exactly? I did a little informal benchmarking on the performance differences of locating multiple records using Find, Filter, and a SQL statement. The results, shown in Figure A, provide a little concrete data to back me up.
| Figure A |
 |
| SQL outperformed Find and Filter in my informal benchmarking. |
The time results represent the average number of seconds needed to use a client-side, static cursor to open the Customers table in SQL Server's sample Northwind catalog and locate all records belonging to customers in London. I ran 50 trials using ADO version 2.6. These results will be a bit faster than real-world performance, since the data provider cached the same Recordsets that were opened, closed, and reopened in rapid succession for this rough test. But the differences in speed are still telling, particularly when operating over a network. Keep these results in mind the next time you need to find a few records and you're working with ADO.
It's easy to get sloppy on the grammar when you're chatting, but the Text Replacement plug-in's autocorrection macros seamlessly correct common typos on-the-fly. If you've got a particular grammar offense that's not included in Text Replacement by default, you can add your own corrections to the list. Wish you had this functionality in every program? Check out 
Keep your IM sessions secure without hassle with the 
The Autoaccept plug-in allows you to set rules for automatically accepting file transfers from specific users. As I pointed out in the 
The Guifications plug-in notifies you of user status and incoming messages with a small pop-up window in the corner of your screen, similar to how Growl works with Adium on the Mac. You can customize the look, location, and what events will trigger a Guification alert so you're only distracted by a Guification pop-up when you really want to be. 
Pidgin comes with a built-in History plug-in that automatically inserts your last conversation with the current contact in your new conversation—especially handy if you're rejoining a conversation and want to pick up where you left off (after restarting your computer, for example). If that's enough for your needs, just flip the switch on it and you're set with the default plug-in. If you want more functionality, like the ability to display anywhere from zero to 255 previous conversations or limit chat histories by how long ago they occurred, the non-default Enhanced History plug-in is for you. 
If you're terrible at setting your status or remembering to change it, let the MusicTracker plug-in update your status for you. The plug-in sets your status to whatever music you're listening to, works with tons of digital music players from iTunes and Winamp on Windows to Amarok and XMMS on Linux, and exactly what it displays is very customizable. 
Pidgin runs on both Windows and Linux using the GTK graphical environment, so theming Pidgin is as easy as using GTK's built-in theming tools. Here's how it works on Windows. 
