Question

So, at my workplace, they have a huge access file (used with MS Access 2003 and 2007). The file size is about 1.2GB, so it takes a while to open the file. We cannot delete any of the records, and we have about 100+ tables (each month we create 4 more tables, don't ask!). How do I improve this, i.e. downsizing the file?

Was it helpful?

Solution

well .. Listen to @Larry, and keep in mind that, on the long term, you'll have to find another database to hold your data!

But on the short term, I am quite disturbed by this "4 new tables per month" thing. 4 tables per month is 50 per year ... That surely sounds strange to every "database manager" here. So please tell us: how many rows, how are they built, what are they for, and why do you have to build tables every month?

Depending on what you are doing with your data, you could also think about archiving some tables as XML files (or even XLS?). This could make sense for "historic" data, that do not have to be accessed through relations, views, etc. One good example would be the phone calls list collected from a PABX. Data can be saved as/loaded from XML/XLS files through ADODB recordsets or the transferDatabase method

OTHER TIPS

You can do two things:

  • use linked tables
  • "compact" the database(s) every once in a while

The linked tables will not in of themselves limit the overall size of the database, but it will "package" it in smaller, more manageable files. To look in to this:

'File' menu + 'Get External data' + 'Linked tables'

Linked tables also have many advantages such as allowing one to keep multiple versions of data subset, and selecting a particular set by way of the linked table manager.

Compacting databases reclaims space otherwise lost as various CRUD operations (Insert, Delete, Update...) fragment the storage. It also regroup tables and indexes, making search more efficient. This is done with

  'Tools' menu + 'Database Utilities' + 'Compact and Repair Database...'

You're really pushing up against the limits of MS Access there — are you aware that the file can't grow any larger than 2GB?

I presume you've already examined the data for possible space saving through additional normalization? You can "archive" some of the tables for previous months into separate MDB files and then link them (permanently or as needed) to your "current" database (in which case you'd actually be benefiting from what was probably an otherwise bad decision to start new tables for each month).

But, with that amount of data, it's probably time to start planning for moving to a more capacious platform.

You should really think about your db architecture. If there aren't any links between the tables you could try to move some of them to another database (One db per year :) as a short-term solution..

Adding more tables every month: that is already a questionable attitude, and seems suspicious regarding data normalisation.
If you do that, I suspect that your database structure is also sub-optimal regarding field sizes, data types and indexes. I would really start by double checking those.

If you really have a justification for monthly tables (which I cannot imagine, again), why not having 1 back-end per month ?
You could also have on main back-end, with, let's say, 3 month of data online, and then an archive db, where you transfer your older records.
I use that for transactions, with the main table having about 650.000 records, and Access is very responsive.

A couple of “Grasping at straws” ideas

Look at the data types for each column, you might be able to store some numbers as bytes saving a small amount per record

Look at the indexes and get rid of the ones you don’t use. On big tables unnecessary indexes can add a large amount of overhead.

I would + 2^64 the suggestions about the database design being a bit odd but nothing that hasn’t already been said so I wont labour the point

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top