Best Practices for Optimizing Large Datasets in MS Access

sandy_52

New member
Local time
Tomorrow, 00:02
Joined
Jun 10, 2025
Messages
1
Hi everyone, I’m working on a Microsoft Access project with a large database (100,000+ records) and facing performance issues with queries. What are your top strategies for optimizing table structures and queries to improve speed?

I’ve tried indexing and normalizing tables, but I’m looking for advanced tips like query optimization, VBA automation, or database splitting. Below are two images: one showing my current table structure and another of a slow query design. Any advice on tools, techniques, or common pitfalls? Thanks for your insights!

how_to_create_a_table_in_design_view_in_access_2016_4.png

how_to_create_a_simple_select_query_in_design_view_in_access_2016_7.png
 
Hi. Welcome to AWF!

Splitting the database is a recommended best-practice approach, so you should do it anyway. If your database is already split, another recommended approach is to open and maintain a persistent connection to the data. Can you show us the design view of the slow query and post its SQL statement?
 
Hi everyone, I’m working on a Microsoft Access project with a large database (100,000+ records) and facing performance issues with queries. What are your top strategies for optimizing table structures and queries to improve speed?

I’ve tried indexing and normalizing tables, but I’m looking for advanced tips like query optimization, VBA automation, or database splitting. Below are two images: one showing my current table structure and another of a slow query design. Any advice on tools, techniques, or common pitfalls? Thanks for your insights!

View attachment 120190
View attachment 120191
Can you upload a screenshot of your Relationship Window?
 
May want to look at
If you really want to get into the details
 
Your exhibit is mixed. We can see the navigation pane to the left in each case and those two displayed images don't come from the same database. How do they both relate to the problem you were describing, or are you asking a general question? In which case why two different DBs?
 
100k records isn't that many. What issues are you having, Mike?
 
In your city table, I would not store strings for the country. I would store a lookup ID to a country table.

Ah. I can see it's a query on top, and you have that structure. I'm not used to tabbed displays.
 
I agree 100,000 rows is an insignificant row count. It doesn't help us to see the results of a query, we need to see the schema and the SQL for the query.
 
Another link that may be helpful.
In this article, I tested the various optimisation techniques suggested by Allen Browne. Example database included


There is also a related video:
 

Users who are viewing this thread

Back
Top Bottom