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 disproportionat e 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.....

@SwissProgramme r:
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!