If you select a table-type recordset with an index, you can use the Seek method to position the cursor against any criteria that are stored in that index. This will always be the fastest possible way to find a particular piece of data. Even though Find will use indexes where possible, because it is based on a dynaset or snapshot, the overhead of that mechanism will always be somewhat greater than the equivalent Seek.
Be careful about giving in to the temptation of indexing all the fields so that you can seek on any criteria. Unless the table data is purely read-only, the overhead of maintaining indexes will erase the gains of using seek on an obscure column once in a blue moon.
Multi-field indexes can be used with Seek even if you don't want to match all the fields. The one restriction is that you have to provide any field preceding the other fields in the index. For example, if you have an index on Part#, Cust# and Emp#, you can search for a Cust# as long as you have the Part#. Similarly to find an Emp# you must have a Part# and Cust#. Of course you can also use this index to search for a Part# alone.
One of the obstacles to using Seek is that you cannot open attached tables as table-type recordsets. Tip #3 shows how you can look inside the connection information for an attached table and use that information to open the database and hence the table directly.
This tip cannot be used against ODBC data sources because they cannot be opened as tables directly. This is an inherent architectural limitation of the way client-servers work.