468,113 Members | 2,060 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,113 developers. It's quick & easy.

Access Front End Bloating?

twinnyfo
3,638 Expert Mod 2GB
(@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!
3 Weeks Ago #1

✓ answered by 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.

20 4471
isladogs
225 Expert 128KB
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
3 Weeks Ago #2
twinnyfo
3,638 Expert Mod 2GB
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.
3 Weeks Ago #3
isladogs
225 Expert 128KB
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.
3 Weeks Ago #4
twinnyfo
3,638 Expert Mod 2GB
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.
3 Weeks Ago #5
isladogs
225 Expert 128KB
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.
..
3 Weeks Ago #6
NeoPa
32,023 Expert Mod 16PB
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.
3 Weeks Ago #7
twinnyfo
3,638 Expert Mod 2GB
I will try the compact on close method first. If not, I'll just copy the FE each time.

Thanks for the hepp!
3 Weeks Ago #8
isladogs
225 Expert 128KB
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?
3 Weeks Ago #9
NeoPa
32,023 Expert Mod 16PB
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.
3 Weeks Ago #10
bhaveshk94
1 Bit
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
3 Weeks Ago #11
twinnyfo
3,638 Expert Mod 2GB
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.

Expand|Select|Wrap|Line Numbers
  1. @ECHO OFF
  2. CLS
  3. SET gSourceLocation=\\SERVER\DATABASE\
  4. SET gAppFileName=DBUpdater.accde
  5. SET sSourceFile=%gSourceLocation%%gAppFileName%
  6.  
  7. SET sUserProfile=%userprofile%
  8. SET gAppDir=Documents\DBUser\
  9. SET sDestination=%sUserProfile%\%gAppDir%
  10. SET sDestinationFile=%sDestination%%gAppFileName%
  11.  
  12. IF NOT EXIST %sDestination% (
  13. ECHO Making Destination Directory...
  14. MKDIR %sDestination%
  15. )
  16.  
  17. ECHO Installing latest Version of the Application to the Local Computer
  18. ECHO Please be patient, this should take no more than 30 Seconds...
  19. COPY %sSourceFile% %sDestinationFile%
  20.  
  21. START "MSACCESS.exe" %sDestinationFile%
Hope this hepps!

Thanks to all!
2 Weeks Ago #12
NeoPa
32,023 Expert Mod 16PB
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 ;-)
2 Weeks Ago #13
SwissProgrammer
206 128KB
"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.
2 Weeks Ago #14
twinnyfo
3,638 Expert Mod 2GB
@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!
2 Weeks Ago #15
NeoPa
32,023 Expert Mod 16PB
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.
2 Weeks Ago #16
isladogs
225 Expert 128KB
@twinnyfo
Did I read you correctly. You spooks have a fix for old age...
Count me in... 😉
2 Weeks Ago #17
twinnyfo
3,638 Expert Mod 2GB
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.....


;-)
2 Weeks Ago #18
isladogs
225 Expert 128KB
@twinnyfo
LOL. Sorry but I couldn't resist....😎

@NeoPa
Great typo. Shall I start calling you NoePa instead?
2 Weeks Ago #19
SwissProgrammer
206 128KB
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.
2 Weeks Ago #20
NeoPa
32,023 Expert Mod 16PB
What can I say? NoPa maybe? To rhyme with Nol - but different. That would make life complicated for everyone :-D
2 Weeks Ago #21

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

11 posts views Thread by Gwindor | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.