Kristy - Not in the TechHelp videos.  Richard does cover Record Sets starting in Access Developer 16 quite extensively.

How many procedure codes are you talking about?  Record sets might be a bit of overkill for a look up.

There are tons of recordsets in the developer lessons. Go HERE for the Access Index. Do a CTRL+F and type in recordset, lots of videos there.

@Scott, there could be as many as 20 codes that the user needs to look up rates for. Ideally, I would love for them to enter them all at once, but sun it, and get all of the rates. Right now, the user has to look them up one at a time. It works, but I think I can do better. Typically, there are anywhere from 1-5 codes for each case. The query is complex, because there is a lot of information that goes into determining a rate. This takes access some time, even for just one code. Im wondering if because of its complexity, it may be best to search one code at a time, even if it can be cumbersome.

Press submit* not but sun it :)

Just throwing it out there but if it's something used as much as pricing (which you should be using almost every record), you may want to consider breaking the rules and storing the calculated value in your table if it's taking access "some time" to figure out the numbers. This is one of the cases where it may be doing more harm then good to do calculations in a query.

So these are actually Medicare rates for procedure codes. Medicare rates are determined by the zip code of the service location and the licensure level of the provider. The zip codes are a huge reason it takes so long to calculate the rates.

I would probably try using a recordset then, and run the calculation inside of the recordset if that's an option. So you can limit the recordset as much as possible with the zip code already filtered before it starts and it doesn't have to do very many records. Rather than load in the entire query and run through it.

However I'm not able to advise any further than that, there's too many unknowns without knowing the calculation or your fields/setup. If you want to Image Uploads all of that, I may take a shot at it.

If you're just looking up rates in a table, you could probably just use DLookup. You may need multiple parameters, but it would be easier than a recordset.

Sorry to be a bit getting back to you.  I took off a couple of days but it looks like the guys have helped in my sted.

Something that none of the other guys mentioned that you should look into is some judicious use of carefully constructed indexes. You don't want too many but the right Indexes can and will help Access speed up your queries and reports as far as look-ups are concerned.

The down side is that if you are doing lots of data entry the overhead of an index can impact the performance of a db.

Sorry to say I don't have a good reference to provide you.  I don't believe this is a subject that has been covered extensively.  
RICHARD CAN YOU COMMENT ON THIS?

As I suggested before, why not just DLookup each rate as the code is entered? Without knowing a lot more about this, including the criteria for determining each rate, I really don't see the benefit of using recordsets here.