UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Why Does My Fe (front End) Gets Bigger And Require Compacting?, Access 2007    
 
   
Lateral
post Feb 3 2018, 03:43 PM
Post#1



Posts: 143
Joined: 29-November 13



Hi Guys,

I have a FE/BE application that is working really well.

During development on the FE, I notice that the size increases from say 58,000kb (the base size after compacting) to around 90,000kb during a 2-3 hour development period...I have the following questions:

1. Is this normal?

2. If so, then what is actually causing the size to increase?

As always, thanks for your help.

Cheers
Greg
Go to the top of the page
 
RJD
post Feb 3 2018, 04:32 PM
Post#2


UtterAccess VIP
Posts: 8,083
Joined: 25-October 10
From: Gulf South USA


Hi Greg:

QUOTE
1. Is this normal?

Yes. While you are developing.

QUOTE
2. If so, then what is actually causing the size to increase?

As you create new objects or modify existing objects, Access increases the space in which it is working. When you save the object, the extra space remains until you Compact. So, when I am developing, I just (save and) Compact regularly when I am done with that development part.

Some folks use the Compact on Close feature, but I recommend against that. I have had and heard of some corruption issues with that feature. It's an easy task to just save and Compact when you are done with a development phase.

Oh, and you'll want to always Compact (and compile) before making an accde anyway - for distribution of the FE.

HTH
Joe

--------------------
"Each problem that I solved became a rule, which served afterwards to solve other problems."
"You just keep pushing. You just keep pushing. I made every mistake that could be made. But I just kept pushing."

Rene Descartes 1596-1650 (Mathematician and Philosopher)
Go to the top of the page
 
Lateral
post Feb 3 2018, 04:57 PM
Post#3



Posts: 143
Joined: 29-November 13



Thanks Joe for clear explanation.

The following is what I do before creating an "accde":

1. Open the VBA editor and compile.
2. If the "Debug\Compile" option is greyed out then I "trick" it into thinking that it needs to compile but adding a few "blanks" to the VBA code and then I compile it.
3. I then Compact the FE
4. Create an accde file for deployment


Am I doing everything in the correct order?

Cheers
Greg
Go to the top of the page
 
RJD
post Feb 3 2018, 05:06 PM
Post#4


UtterAccess VIP
Posts: 8,083
Joined: 25-October 10
From: Gulf South USA


Hi Greg: The order looks fine. But I would add a step, say 2.1, to save before compacting. My experience is that the compact very, very rarely goes wrong, but why take the chance when you've just invested your time to make mods (that you haven't completely documented and your brain may not fully remember!).

Regards,
Joe

--------------------
"Each problem that I solved became a rule, which served afterwards to solve other problems."
"You just keep pushing. You just keep pushing. I made every mistake that could be made. But I just kept pushing."

Rene Descartes 1596-1650 (Mathematician and Philosopher)
Go to the top of the page
 
Lateral
post Feb 3 2018, 05:55 PM
Post#5



Posts: 143
Joined: 29-November 13



Thanks mate

I currently regularly save backups/copies of me FE just in case something "silly" happens and will add a 2.1..

Thanks for your help

Cheers
Greg
Go to the top of the page
 
GroverParkGeorge
post Feb 3 2018, 06:08 PM
Post#6


UA Admin
Posts: 31,923
Joined: 20-June 02
From: Newcastle, WA


I would just add a couple of observations.

That "trick" about adding a couple of lines to force a recompile is something a lot of people use to recover from the rare, but not unheard of, problem of a "phantom breakpoint". This can happen when you put break points in your code during testing. Sometimes, for no reason I've ever been able to pin down, it gets stuck and the code module opens up to that point when a user tries to run the application. Embarrassing. This trick is how one recovers from that. Forcing the recompile clears that.

Also, it's possible interesting to go into how the Compact and Repair actually works (at least I think so).

When you do much of anything in Access, but especially during development, you create and delete objects. The "deleted" objects are only flagged to be deleted, but physically left in place in the file. The same thing often happens when you set up an import function that creates and deletes temporary tables, or which deletes and appends records to a temp table. Anyway, that bloats the file, as Joe explained.

The C&R process:

a) creates a new file in the same folder as the existing accdb. It's called "Database.accdb"
b) copies everything from the original accdb into this new one, EXCEPT for the objects marked for deletion. This is where the file size gets shrunk back down due to the abandonment of that detritus.
c) deletes the original accdb.
d) renames the new "Database.accdb" to the same name as the file it replaces, i.e. the one being C & Red.

I think it may be a bit more complex even than that, but that's the basic process.

And that, by the way, also explains a couple of other things.

One, doing a Compact on Close is dangerous because if it happens when another user has that same accdb open, the delete and replace process can't work on that opened accdb. One symptom of that problem is the presence of multiple files named, "Database.accdb", "Database1.accdb", "Database3.accdb" and so on, one for every failed C&R attempt.

Another problem is that doing this across a network, i.e. trying to do a C&R on an accdb out on a folder somewhere on a LAN risks having a network blip interfere with the process, leaving the accdb corrupted.

Now that's probably more than you really wanted to know....

--------------------
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    20th February 2018 - 06:45 PM