The table already has an index.
Tables can (and often do) have multiple indexes. You don't want to go index crazy because modification statements, like Insert, update, and delete are slower when there are multiple indexes. In most cases, you'll never notice the difference in performance with the inserts, updates, and deletes. That is... until you continue adding more and more indexes.
In my database, I have approximately 300 tables. I have approximately 680 indexes. About 200 of my tables only have one index (for the primary key). My most heavily indexed table has 22 indexes (which is probably double the number that there should be). Usually, the larger the table, the more indexes you have because there are more queries run against it, and larger tables benefit more from indexes than smaller tables.
Regardless, I do encourage you to add the index that I suggested. I think you will be pleasantly surprised. It's not likely to add much to the size of your database. It's not likely to affect the performance of your updates, inserts, and deletes (to the point where you would notice it). It'll only make your query faster, at the expense of a little extra database size.
Other than making the query faster (which is my strong recommendation), you may want to think about persisting the data on the Access side. You could make a global recordset object that stores the results of the query. When your app starts, load the data. Whenever you want to use it, just use it. I am no Access guru (like I am with SQL Server), but I suspect it wouldn't be that difficult to persist the data in ram within your access app.
-George
Microsoft SQL Server MVP
My Blogs
SQLCop
twitter
"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom