A while back I wrote about a Inner Join technique using a date range. (You can find that post here.)

Today I’m going to take it a step further and discuss using inner joins to another query and conclude with an issue in Access you may shed some light on.

MS Access Report Generator

Access can work great in large companies, call us to discuss

Using Queries as Inner Joins

For the longest I’ve been using make table queries to calculate totals and percentages, then linked the tables in secondary queries to perform updates. For example, take a look at the following tblWidgetImport table:

The table displays the total production by WidgetTypeID per week. What I needed to do was calculate the percentage of each Widget’s total for the week, and then update the PercentWeeklyWidget column.

I can calculate totals by week using the following query:

Which produces the following results:

Now that I have my summary query figured out I used it in an Inner Join query with the original table to calculate percent of each WidgetTypeID:

The query above will produced the following result set:

Nice! I now have a query that will calculate percent of each widget type by week without using a temporary table! Now I just have to insert this query with the original table to update the WeeklyWidgetPercent column, what could go wrong?

Something Went Wrong

I created the following query to update the original table using the two queries above:

When I try to execute this query Access returns “Must use an updatable query.” Ben helped me with these complex joins and says that of all RDBMS out there, Access is probably the most stingy whenever it comes to executing an update query using a summary query. As soon as a query includes a source that’s non-updatable (e.g. aggregations), the whole query is non-updatable even though we aren’t trying to update the aggregated query but a base table using values from aggregated tables. Luke Chung has a great white paper on this issue here.

In this situation, we have two choices; export the query result into temporary table as I’ve always done or wrap the query into a VBA function which Access will allow.

Where GetWeeklyPercentByType() is a VBA function that uses a DAO.OpenRecordset. It would work but since we’d be opening recordset for each row, it would be slower than just making tables and linking them.

Taking your inner join queries to the next level will require you to invest more time, but will provide you with faster results and less clutter in your database.