By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,492 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

Advice on when to compact a back-end file

P: n/a
I'm writing code to backup the back-end file from my front-end. The code will
automatically run the routine when the main app is closed and when certain
critieria are met.

The question is: What are those criteria??

I've seen a number of posts and experienced it myself that compacting can
occassionally cause corruption. So I don't want to compact unnecessarily.
My thinking is as follows:

1) When the back-end file is compacted from the front end, write the "after-
compact" file size of the backend file to a table.

2) Then when the app is closed in future sessions, run code that compares the
current back-end file size with the file size of the back-end file the last
time it was compacted. If the current size is XX% greater than the last-
compact size, compact the back-end file.

If this seems like a reasonable approach, what should the value of XX be?

Comments, suggestions on this approach.

Thanks.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200611/1

Nov 12 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On Sun, 12 Nov 2006 04:44:09 GMT, "rdemyan via AccessMonster.com"
<u6836@uwewrote:

Compacting doesn't cause corruption, it reveals it.

A good backup schedule will allow the user to revert back to a "before
corruption" version should the need arise.

-Tom.

>I'm writing code to backup the back-end file from my front-end. The code will
automatically run the routine when the main app is closed and when certain
critieria are met.

The question is: What are those criteria??

I've seen a number of posts and experienced it myself that compacting can
occassionally cause corruption. So I don't want to compact unnecessarily.
My thinking is as follows:

1) When the back-end file is compacted from the front end, write the "after-
compact" file size of the backend file to a table.

2) Then when the app is closed in future sessions, run code that compares the
current back-end file size with the file size of the back-end file the last
time it was compacted. If the current size is XX% greater than the last-
compact size, compact the back-end file.

If this seems like a reasonable approach, what should the value of XX be?

Comments, suggestions on this approach.

Thanks.
Nov 12 '06 #2

P: n/a
Thanks,

I'm still not going to compact the back-end files every time a user closes my
app. Instead, I'll stick with my plan and look for an increase in size of
either 10 or 20%, probably 20%.

Tom van Stiphout wrote:
>Compacting doesn't cause corruption, it reveals it.

A good backup schedule will allow the user to revert back to a "before
corruption" version should the need arise.

-Tom.
>>I'm writing code to backup the back-end file from my front-end. The code will
automatically run the routine when the main app is closed and when certain
[quoted text clipped - 19 lines]
>>
Thanks.
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200611/1

Nov 12 '06 #3

P: n/a
rdemyan via AccessMonster.com wrote:
<snips>
I've seen a number of posts and experienced it myself that compacting can
occassionally cause corruption.
I've seen the posts but I've never seen the corruption. IMO if this
actually ever did happen it's likely the reason was database suicide
prompted by embarassment upon being required to face up to
self-ugliness. I suppose someone will post a link to a compiled
error-free mdb which corrupts on compact to show me up as wrong. YYSSW!

<snips>
If this seems like a reasonable approach, what should the value of XX be?
It seems unreasonable to me; regardless I suppose XX should be zero or
more than zero or less than zero, somewhere in that range. If you're
worried about corruption why not just make a copy of the damn thing
before you compact, or do the compact to a new db, and then rename the
old and the new?
Comments, suggestions on this approach.
It's posts like this that contribute to the considerable body of Access
superstition that is alive and well and slopping back and forth like
bilge water in CDMA.

Nov 13 '06 #4

P: n/a
And here I had thought you had forgotten about me :).

Nobody is responding to my post on a custom "Please wait" message that I'm
trying to display when closing my app. Would appreciate it if you would take
a look at it. Thanks.

Lyle Fairfield wrote:
><snips>
>I've seen a number of posts and experienced it myself that compacting can
occassionally cause corruption.

I've seen the posts but I've never seen the corruption. IMO if this
actually ever did happen it's likely the reason was database suicide
prompted by embarassment upon being required to face up to
self-ugliness. I suppose someone will post a link to a compiled
error-free mdb which corrupts on compact to show me up as wrong. YYSSW!

<snips>
>If this seems like a reasonable approach, what should the value of XX be?

It seems unreasonable to me; regardless I suppose XX should be zero or
more than zero or less than zero, somewhere in that range. If you're
worried about corruption why not just make a copy of the damn thing
before you compact, or do the compact to a new db, and then rename the
old and the new?
>Comments, suggestions on this approach.

It's posts like this that contribute to the considerable body of Access
superstition that is alive and well and slopping back and forth like
bilge water in CDMA.
--
Message posted via http://www.accessmonster.com

Nov 13 '06 #5

P: n/a
Lyle Fairfield wrote:
rdemyan via AccessMonster.com wrote:
<snips>
I've seen a number of posts and experienced it myself that compacting can
occassionally cause corruption.

I've seen the posts but I've never seen the corruption.
I haven't seen that happen since Access 95.
It's posts like this that contribute to the considerable body of Access
superstition that is alive and well and slopping back and forth like
bilge water in CDMA.
Improbability is not reason enough to doubt rdemyan's experience :-).
I compact to a separate file, then compact back over the original file.
I back up both copies to a separate machine on the network and one to
DVD and both to my local machine. Call me superstitious if you'd like.

James A. Fortune
CD********@FortuneJames.com

I lived in Spain for a month when I was 19. While in Madrid a young
man asked in English if I could help him solve a math problem. He was
staying at a hotel built around the 15th century. When we arrived at
his room he pulled out a Calculus book and showed me where he was
having trouble. I helped him, then asked, "How did you know I knew
Calculus?" He replied, "You looked like you know Calculus."

Nov 13 '06 #6

P: n/a

"rdemyan via AccessMonster.com" <u6836@uwewrote in message
news:693b44a16c4e6@uwe...
And here I had thought you had forgotten about me :).

Nobody is responding to my post on a custom "Please wait" message that I'm
trying to display when closing my app. Would appreciate it if you would
take
a look at it. Thanks.
Lyle, if you search the newsgroup to find rdemyan's post, which he/she did
not identify by link, or by subject, or by date and time, in order to "take
a look at it," please post back here and let us know. :-)

rdemyan, if you want help, you need to make it easy (repeat _easy_, repeat
_EASY_) for people to help you. There are thousands, multiples of ten
thousands, of archived posts for this newsgroup that can be searched at
http://groups.google.com but most of us aren't reading and responding there.
Referring to "my post on a custom... message" doesn't make it easy. For good
suggestions on effective use of newsgroups, see the FAQ at
http://www.mvps.org/access/netiquette.htm.

Larry Linson

Nov 13 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.