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.

[bhaveshk94]

Access files seem to grow at a rate that strikes as disproportionate to the amount of activity in the database, a phenomenon often referred to as “bloat”. If you allow bloat to continue unhindered, the performance of your database will deteriorate.

Thanks
BhaveshK

[twinnyfo]

A Compact and Repair on close did return the App to its original size, and I have great confidence that there will no be problems with this action.

However, because I trust NeoPa's years of experience, and because my FE is rather tiny, there is really neither harm nor risk in copying the FE everytime anyone uses it. In the grander scheme of things, this is probably the "best" way, and those who know me know that I would much prefer to do something better or best than half-way.

For any o' all y'all who are interested in how to copy the FE to the user's local directory each time it is opened, here is the Script I use.

@ECHO OFF
CLS
SET gSourceLocation=\\SERVER\DATABASE\
SET gAppFileName=DBUpdater.accde
SET sSourceFile=%gSourceLocation%%gAppFileName%
 
SET sUserProfile=%userprofile%
SET gAppDir=Documents\DBUser\
SET sDestination=%sUserProfile%\%gAppDir%
SET sDestinationFile=%sDestination%%gAppFileName%
 
IF NOT EXIST %sDestination% (
ECHO Making Destination Directory...
MKDIR %sDestination%
)
 
ECHO Installing latest Version of the Application to the Local Computer
ECHO Please be patient, this should take no more than 30 Seconds...
COPY %sSourceFile% %sDestinationFile%
 
START "MSACCESS.exe" %sDestinationFile%

Hope this hepps!

Thanks to all!

[NeoPa]

Nice post Twinny.

Corruption doesn't necessarily occur as part of the C&R but it sort of can at any point.

I like your script. Some good illustrations of environment variable usage. I hope you have it stored as CMD rather than BAT ;-)

OTOH. That Langley bit does rather blow your cover as a spook ;-)

[SwissProgrammer]

"whenever the FE links the data tables, the FE itself (compiled as a .accde file) bloats."

twinnyfo, your Access symptoms seem to me like during the first re-compile it might be adding a structure to hold a copy of the previous copy of what is being compiled. Then the next compile seems to be using that structure to add another copy of that previous previous copy of what is being compiled. The structure for holding the copies increases slightly. The copies themselves are added "as is" or with references to previous compiles. Thus, almost approaching, after enough re-compiles a graph of size might approach a trigonometric tangential curve limit [X] (from 0 to -Pi/2) first mirrored, and then the graph seen as the graph turned 90 degrees to the left. With the tangential limit being slightly uphill and not exactly horizontal.

If you record the change from each of 10 continuing re-compiles and map them I suspect that you will find a tangential curve approaching an almost incremental increase of the size of what is being copied.

You might have a setting in Access or in your operating system that is causing or allowing this.



I was re-reading your original post and I just now saw a test to make for potential interference from something entirely outside of your program.

On a laptop that YOU installed the operating system, under the following conditions, (and it was not any "telemetry" version of any operating system) non-network connected (not connected in ANY manner) (Any so-called "unused" wireless antenna was removed. Any so-called "unused" microphone and speaker was removed. All electric power supplied via an isolated battery backup with or without an isolation-transformer), create a mirror of what you are doing on the suspect computer. Then run it and compile, and re-compile, etc. and record what is happening. If there is no bloat then it seems probable that some idiots that think that they are smart are attempting to track you and are (instead of that) actually corrupting your running of Access. If that is the case, then I consider it probable that they have corrupted any or all of your other Access work and it might be invalid.

To recap:
I think that it might be either
(1) A setting in your Access or in your operating system that is causing it.
or
(2) Some dim-wit in management that told some dimmer-wit to track you and neither one knew how to track their own nose without breaking things on the way.

[twinnyfo]

@NoePa:

OTOH. That Langley bit does rather blow your cover as a spook ;-)

DUDE! Cover, totally blown! I meant to remove that before I posted it. Did someone say something about old age? That has been fixed.....

@SwissProgrammer:
Say what? If I could follow the first half of your post, I would probably agree with you--you appear much smarter than I. However, the bloat only occurs during the relink of an already compiled FE. Thus, I am not re-compiling, let alone re-re-re-compiling (etc.).

But, affirming your final thoughts, we do have some dim-wits in our IT management managing a bunch of dimmer-wits in the IT operations who all think the rest of us are living-in-total-darkness-wits. So, the challenges will continue. I don't think they are managing that aspect of MS Access (yet). This is the only DB that behaves this way, because this is the only DB I use that re-links tables after it is compiled.

But, your thoughts are always welcomed and always appreciated!

[NeoPa]

Hi Twinny.

Excellent. Your response amused me greatly and left me with a great big grin on my face.

Helpful info :

1. Did I ever tell you my user name came from my son who used to play online as Noe? I've taken a picture for after you do your retrospectives ;-)
2. Relinking tables always creates a bit of extra space in the database. The space used for the tables as previously linked is not released when new space is assigned and used for the new versions. That's just how it is I'm afraid. Access was never designed to release space as this is background work and Access isn't really an RDBMS (Relational Database Management System). It's simply an RDB program. The former has background threads responsible for maintenance tasks whereas Access doesn't. To get a thread to run such maintenance tasks and remove any unused space in your database in Access you have to run it specifically. It is actually the C&R process.

[isladogs]

@twinnyfo
Did I read you correctly. You spooks have a fix for old age...
Count me in... 😉

[twinnyfo]

IslaDogs,

I did a poor job of properly delineating my antecedents. I fixed the spook-link. THAT has been fixed. That old age thing--we're still working on it.....


;-)

[isladogs]

@twinnyfo
LOL. Sorry but I couldn't resist....😎

@NeoPa
Great typo. Shall I start calling you NoePa instead?

[SwissProgrammer]

My mistake. I thought that you were re-re-compiling and having that issue compounded.

After you explained that was wrong, I see that I was reading more into it than there was.

[NeoPa]

What can I say? NoëPa maybe? To rhyme with Noël - but different. That would make life complicated for everyone :-D

[jcoogan]

Here's another possibility that took me forever to discover. I am using Microsoft 365 subscription, ver 2302. Check menu: "File, Options, Current Database". Look for "Track name Autocorrect info" and uncheck it.

I >think< the idea behind this option is that Access will auto correct other instances of objects behind the scenes when you change an object name. Example: You have two queries that are linked and you change the name of one, then Access will automagically update the name change in the separate join query, preventing it from breaking. Pretty cool, but also possibly pretty expensive in terms of database bloat because Access has to write all these object references somewhere!

In my case I have a database with code only, data tables are in a separate linked database. The code database was bloating from 3000k to the 2gig limit in 20 min! My code database is doing a lot of database object and recordset object creation and deletion. When I unchecked the option named "Track name Autocorrect info" it resolved the issue and now the code database only grows by about 500k.

[NeoPa]

Indeed JCoogan.

Among the Access MVPs there are one or two who get very exercised about that little nugget. Most experienced developers recommend turning that off as soon as you can. Some suggest before making it on to solid food but others are more relaxed.