Access specifications
https://support.microsoft.com/en-gb/office/access-specifications-0cf3c66f-9cf2-4e32-9568-98c1025bb47c

Thanks Alex for quick reply. I see the maximums now. I guess 16 joins is the most important bit of information there. 50 levels of nested queries? that's not too bad ;)

Break it up into several queries that have been tested, and combine as needed.  John

Bartek   What makes it "acceptable" or not is *performance*.  If a query has 12 tables and runs fast, it is acceptable.  If a query has only 6 tables but runs slowly, it's not acceptable.  The number of tables in a query does not always determine performance.  Table design, indexing, and the number of records returned are also factors.  Also, "fast" and "slow" are often subjective.  A query that takes 6 seconds to run may be acceptable to some users, but not to others.

I will say that in my years of building queries, I've never needed more than 5-6 tables or other queries in a query. If it gets more complicated than that, I try to build a second query. If you try to make one query too complicated, it just causes us problems.

Richard  In the 90s when computers were super-slow, query complexity (and many other things) would cause noticeable effects on performance, making optimization top priority.  Nowadays, the bottleneck is Internet speed.  If we run anything that involves online data, we need the same kind of diligence in optimization as in the 90s.