Thanks for following Wendell.

I will certainly review the references you have provided.

Much has transpired since my post.

I was never successful with a pass-through query since they are not updateable.

For several reasons, I am unable to create an indexed view.

1) My view joins a "main" table which has all of the updateable columns in it to several "reference" tables which allow me to get the attribute names for the lookup values in the main table. Several of these lookups are optional values i.e. they are not required. Because of this, the joins to these are left joins. It turns out that you can not create an index on a view which has left joins. I tried to use subqueries in the view. Turns out you can't do that either...

2) I use some functions to calculate values which need to be in the grid of the split form (yes, still using split grid). Turns out that you can't put an index on a view which uses functions....

So, where I'm at is that in order to quickly deploy a solution in the near term which performs better than what users have now, I've converted the solution to a .adp. I'm using stored procedures as the source for the forms as well as for the combo boxes (lovin' using stored procedures! I can use both, functions and subqueries.). Using strored procedures is also something that I can't seem to do with a .accdb file (Its possible that I haven't figured out the mojo for that yet but it wasn't immediately evident to me).

The .adp (ADO) based solution is WAY faster than the same same solution in .accdb (DAO). It would be an interesting exercise to see if anyone could make the .accdb solution perform as quickly as the .adp. I freely confess that I'm an Access novice and am almost certainly doing something (probably a bunch of things) wrong.

Once I get an adequately performing solution in the hands of users it will buy me time to figure out how to deploy it as a sustainable (read; not deprecated by Microsoft) solution. My current thinking is either;

1) refactor the solution to use DAO efficiently. This will likely take some significant redesign. A refactoring may make it possible to use an indexed view.

2) use ADO within a .accdb. This will require a fair amount of coding - manually declaring recordsets and such.

Finally;

At the moment, each user has their own copy of the Access file which they are running from their own computer and which connects to the database. Another option available to us, which would also have some other benefits, is to deploy it to a Citrix environment. We haven't pursued that yet.