Access Front End Bloating?

[twinnyfo]

(@niheel - I love the new UI!)

Friends,

I have a tiny little FE that manages some data updates that I receive from various places. Because anyone could use this FE from anywhere and access the files from anywhere, the FE needs to find the files, and then link the data tables to itself. All this work perfectly.

However, I have noticed that whenever the FE links the data tables, the FE itself (compiled as a .accde file) bloats. And, every time I re-run the FE, and tables are re-linked, it continues to bloat.

Now, because we are talking about a tiny file (it is 2.7 MB by itself) the amount of bloat seems extreme--it will grow to 8.9 MB the first go-round and then to 12.3 MB the second go-round.

While I know how to compact and repair an external .accde file, I don't know how to compact and repair the currently used .accde file whilst it is open.

I realize that I am not talking about huge files or any danger of reaching the 2 GB limit for an Access file, but it just seems strange, and a bit annoying that simply re-linking tables can create such bloat.

Any o' all y'all have any ideas?

Thanks for the hepp!

[isladogs]

Hi twinnyfo
MS removed the ability to compact the current database using VBA in Access 2010.
I think they did so due to corruption issues that sometimes occurred when running a C&R on an open database
The only way you might get it to work is by using SendKeys which I wouldn't recommend.

Form your explanation, I've got no ideas as to why you are getting file bloat.
It suggests there's something else going on that you've not mentioned. For example, importing to temporary staging tables...but if that were the case, I'm sure you wouldn't be asking the question

[twinnyfo]

IslaDogs,

The bloat definitely occurs during the table re-link process. During that process, I watch the file size grow, then during the other processes it runs, file size is perfectly stable.

This is the only DB I have running table re-linking after it is compiled. For others, I relink to a permanent location, then compact and throw up to the network.

Just very strange.

[isladogs]

It does indeed sound odd.
Other than the inherent changes to MSysObjects and other system tables caused by you relinking tables in an ACCDE, there seems to be no obvious reason why the file size would increase.

I have several commercial apps with ACCDE FEs where relinking is done by the client both on first use and whenever a new version is released.
Some have SQL BEs and others .are just Access BEs. In case its somehow relevant what is your BE?
I'll test and see if I get any significant bloat on relinking.

[twinnyfo]

There are three MS Access .accdb files, and there are also several raw text and .tsv files. I wonder if it has to do with the re-linking of text files?

Just a guess.....

Either way, it "works," but it's still annoying.

[isladogs]

I wouldn't have thought so, unless you do some processing of those text files.

One of my commercial apps for schools updates all staff, student and whole school data to a SQL BE from an external database each night.
That process is managed with a 'helper' app which firstly exports 30 CSV files from the external DB, then relinks to the latest copies of the CSV files, processes those using local staging tables before running the update procedures to the SQL database and then emptying the staging tables again.
The need for staging tables means the app bloats from about 15 MB to 120 MB each night.

However if you aren't doing anything similar, the relinking should have minimal effect, no matter whether its ACCDB, TXT, TSV, CSV, XLSX files or a mixture thereof.

You can always run compact on close...though if it was me, I would always run a backup first.
..

[NeoPa]

Access does things in your databases when it runs. Many of these things will cause it to increase in size. That's a fact of life when using Access I'm afraid.

Ways to get around this are :

1. C&R on close. Backup if necessary. Many FEs need no protection as there's nothing important in them except for the design & code.
2. Copy a new version of the master FE before every use.

Circumstances vary of course but I generally find the C&R option works well enough. If anything goes tit^H^H^HBelly-up they can easily get another copy of the master. I often consider that actually point #2 would have been a wiser approach all along. For my FEs at least, they are so small a copy would be barely noticeable.

[twinnyfo]

I will try the compact on close method first. If not, I'll just copy the FE each time.

Thanks for the hepp!

[isladogs]

I would definitely recommend running a backup before compact on close. Just as a precaution in case of corruption.

Are you able to upload an example dB with no confidential data that illustrates your issue?

[NeoPa]

My experience over the years leads me to prefer the simpler approach of copying the master every time unless you do or store anythything in the FE that would be lost. Every time Access is used and/or closed (particularly by users who may not close properly but just log off) there is a (albeit very) small percentage chance the FE will get a corruption of some sort. C&R can help with that but not as reliably as a brand new copy of a file you know to be clean and without issue.

As I mentioned earlier, I wish I'd followed that path earlier instead of having to deal with calls to handle problems where all they need is a new & clean copy of the FE.