You don't mention it, but I assume that there's additional per-automobile information in each database record. I also assume that the "price range" is an enumeration. (I've been car shopping lately, and most sites seem set up that way.)

Conceptually, you'll be reading each of the 500 records, applying the search criteria, and then collecting up the matching records for display. Easy stuff, with many implementation options.

At an implementation level, you probably want to avoid reading the full record until you need to (assuming there's lots more stuff in the full record). This suggests splitting your data into two tables. The first would hold search criteria and the unique key. The second would hold the unique key and the remaining data.

You could put each table into a separate DBM file, or, if performance is a big concern, you could leave the "search criteria" file as a flat file. It would only be ~24K, assuming an average record size of 50 bytes and a 500 entry limit. It's going to be faster to suck a file of that size into memory and search it in-place than it is to read the same data record-by-record from a DBM.