database disappears on compact

[PatHartman]

My client installed an .mde which is set to compact on close and when she
closed the database, db1.mdb appeared in the directory and the .mde was
gone. I watched this happen with GoToMeeting!!!! I have heard reports of
this error with A2007 but not with A2003 and I have not found any
explaination or solution. The Dec 2007 hotfix
http://support.microsoft.com/kb/945674 may sove the problem but it doesn't
say so specifically. As with much of corporate America, she doesn't have
admin control of her PC so I don't want to push the issue of the hotfix
unless I know that it will solve the problem.

 

[John W. Vinson]

My client installed an .mde which is set to compact on close and when she
closed the database, db1.mdb appeared in the directory and the .mde was
gone. I watched this happen with GoToMeeting!!!! I have heard reports of
this error with A2007 but not with A2003 and I have not found any
explaination or solution. The Dec 2007 hotfix
http://support.microsoft.com/kb/945674 may sove the problem but it doesn't
say so specifically. As with much of corporate America, she doesn't have
admin control of her PC so I don't want to push the issue of the hotfix
unless I know that it will solve the problem.

Don't know if that fix will work, but there's apparenly a newer download that
should fix it:

http://blogs.msdn.com/access/archiv...r-might-delete-your-database-access-2007.aspx
http://support.microsoft.com/?kbid=950812

 

[PatHartman]

Hi John,
Thanks but the client is using A2003 and the other hotfix is for A2007. We
were lucky. The db1.mdb file didn't get deleted so we didn't actually loose
the database. I had the client rename the file and try the app again. She
was able to open the app, modify data, and compact on close without a
problem so I asked her to distribute that copy of the database rather than
the .mde from the installation CD.

My client is beside himself with worry over this issue since this is only
the second sale of the product and we have encountered a serious problem
with Access. He is beginning to question the decision to use Access at all.
I don't have the resources to test the app in different environments so I am
also worried about this. If the client's IT staff is willing to try the
hotfix, I'll report back on the results but since we got past the immediate
issue, I don't know how much time they will be willing to invest in tracking
down Microsoft's issue.

 

[David W. Fenton]

My client installed an .mde which is set to compact on close

Turn off COMPACT ON CLOSE, which is a useless and downright
dangerous feature that nobody should ever use under any
circumstances.

 

[David W. Fenton]

My client is beside himself with worry over this issue since this
is only the second sale of the product and we have encountered a
serious problem with Access. He is beginning to question the
decision to use Access at all. I don't have the resources to test
the app in different environments so I am also worried about this.
If the client's IT staff is willing to try the hotfix, I'll
report back on the results but since we got past the immediate
issue, I don't know how much time they will be willing to invest
in tracking down Microsoft's issue.

This is clearly pilot error, given that you set COMPACT ON CLOSE.

Turn that off. It is a huge mistake and should never be used under
any circumstances. That you don't understand it well enough to
realize that it's useless and dangerous suggests to me that your
client's misgivings about you and your product are well-founded.

 

[PatHartman]

You obviously don't know to whom you are speaking.

 

[PatHartman]

The client applied the hotfix today and we repeated the steps which
previously caused the .mde to disappear. We got no error messages and the
database compacted correctly.
Hope you're still enjoying Paris.

Hi John,
Thanks but the client is using A2003 and the other hotfix is for A2007.
We were lucky. The db1.mdb file didn't get deleted so we didn't actually
loose the database. I had the client rename the file and try the app
again. She was able to open the app, modify data, and compact on close
without a problem so I asked her to distribute that copy of the database
rather than the .mde from the installation CD.

My client is beside himself with worry over this issue since this is only
the second sale of the product and we have encountered a serious problem
with Access. He is beginning to question the decision to use Access at
all. I don't have the resources to test the app in different environments
so I am also worried about this. If the client's IT staff is willing to
try the hotfix, I'll report back on the results but since we got past the
immediate issue, I don't know how much time they will be willing to invest
in tracking down Microsoft's issue.

 

[David W. Fenton]

You obviously don't know to whom you are speaking.

All I know is that you've distributed an app with a "feature" turned
on that no competent developer (which means one who has taken the
time to understand what that "feature" does) would ever turn on.

I don't need to know anything else about you to know that you're not
a developer that I'd hire to work on my Access projects. My clients
expect and deserve a higher level of professionalism than that.

 

[PatHartman]

Rather than directing your venom and distain at me, perhaps you should be
directing it at Microsoft. It is THEIR product that has the bug, not mine.
The fact that the hotfix solved the problem is evidence of that. In my 16
years of working with Access, I have never encountered this problem nor
heard of anyone else encountering it until A2007 was released. Apparently
whoever put the bug in A2007 put the same bug in A2003 with service pack 3.

The compact on close is a very useful feature that has proved completely
reliable in the past unlike Name Autocorrupt. It is the type of feature
that is a catastrophe if it is not properly tested. Users get really upset
if your software clobbers their data. On the other hand, users of retail
software cannot be relied upon to compact on a regular basis so you have to
do what you can behind the scenes. And who is to say that the same problem
wouldn't have happened the first time they elected to manually compact the
database? If it had to happen, I am very happy that it happened the first
day they used the software when they were just working with test data.

If you are hoping to be "noticed" by your peers or Microsoft and nominated
as an MVP, think again if they come across this post. Rudeness such as
yours is intolerable in a community such as this where the majority of
posters are newcomers. You set a poor example.

 

[Guest]

You obviously don't know to whom you are speaking.

 

[David W. Fenton]

The compact on close is a very useful feature

No, it's not. You are completely wrong on that. The reasons are the
following:

1. no properly-designed Access application is distributed as
anything other than a split design. Thus, the end user is only ever
opening the front end. Since the front end has no data in it, it
doesn't experience bloating, and thus has absolutely no need to be
compacted.

2. some forms of corruption in an MDB will allow the data to remain
accessible *until* a compact. Once a compact is completely, that
data can be lost irrevocably. Since COMPACT ON CLOSE cannot be
cancelled, it is thus much, much too dangerous to ever be used on an
MDB with data in it.

So, it's useless because of #1 and dangerous because of #2.

Anyone who gave it any thought whatsoever would have to conclude
that this is so.

But, as I said, MS could redeem the danger aspect of this "feature"
by having it prompt the user with a Yes/No/Cancel dialog.

Since they have chosen not to do so, its use by anyone shows that
they are really not qualified to be selling their Access development
services professionally.

 

[David W. Fenton]

If you are hoping to be "noticed" by your peers or Microsoft and
nominated as an MVP

I'm not. I'm posting in the hope of stopping the stupidity of using
COMPACT ON CLOSE.

 

[Rick Brandt]

No, it's not. You are completely wrong on that. The reasons are the
following:

1. no properly-designed Access application is distributed as
anything other than a split design. Thus, the end user is only ever
opening the front end. Since the front end has no data in it, it
doesn't experience bloating, and thus has absolutely no need to be
compacted.

2. some forms of corruption in an MDB will allow the data to remain
accessible *until* a compact. Once a compact is completely, that
data can be lost irrevocably. Since COMPACT ON CLOSE cannot be
cancelled, it is thus much, much too dangerous to ever be used on an
MDB with data in it.

So, it's useless because of #1 and dangerous because of #2.

Anyone who gave it any thought whatsoever would have to conclude
that this is so.

But, as I said, MS could redeem the danger aspect of this "feature"
by having it prompt the user with a Yes/No/Cancel dialog.

Since they have chosen not to do so, its use by anyone shows that
they are really not qualified to be selling their Access development
services professionally.

I completely agree with David on this. Frequent (and prudent) use of
Compact is a good idea *for the developer* as he is doing things during
development that warrant it. Compacting should not be required that often
for the user, has the potential to do damage, and to do so on every close is
just insane.

The fact that in any proper distributed app (split) Compact On Close
compacts the wrong file anyway just makes it all the more obvious that it's
not a good idea.