access database needs to be repaired or isn't a database file

[John]

Shut down my computer on friday and I was unable to open a
file on monday. The file was stored in same place on a
running server for the past 2 years. All other Access
database files work just fine.

Access warnings shown below:

"The database hirschdatabase.mdb needs to be repaired or
isn't a database file" You or another user may
haveunexpectedly quit Microsoft Access while a Microsoft
Access database was open. Do you want microsoft to attempt
to repair the database? YES or NO

I select yes to have Access attempt repair, then.

"you do not have the necessary permissions to use the "
object. Have your system administrator or the person who
created this object establish the opriate permision for
you." We all have permission!

"The database hirschdatabase.mdb can't be repaired or
isn't a Microsoft Access database file."

"you do not have the necessary permissions to use the "
object. Have your system administrator or the person who
created this object establish the opriate permision for
you."

I give up!
Please help.

 

[Van T. Dinh]

See Tony Toews' comprehensive article on corruptions:

http://www.granite.ab.ca/access/corruptmdbs.htm

 

[Tony Toews]

From what I've been able to learn,
you need to make sure that you have the latest SP on
Windows and on Access for all comuters using the db.

Not necessarily for Windows but yes it's important to make sure the
users are on the same Jet SP and the same Office SR.

Our
Netadmin wouldn't load the W2K SP4 (said there were
problems with it)
Understandable.

but agreed to load the Jet 4.0 SP7 which
is supposed to help.

AFAIK there's nothing about SP7 helping with corruptions. And some
people are reporting problems with SP7 in their environment.

I think oplocks should also be
disabled, but our netadmin refuses to do that.

Uh oh. This is a major cause of corruptions. And is the first thing
anyone experiencing frequent corruptions should change. Print off
the corruption causes page at my website and show your netadmin that
this is the top item on that page.

There are
many instances where records can't be edited, even though
other records on the same form can be edited.

Can you edit these records later?

My netadmin told me that the real
problem is that the db was written in Access, so he's
probably not going to be able to get it to work
correctly.

Your netadmin is an arrogant *ss. Many people are running 15-25 users
all day long into an Access MDB.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Tony Toews]

"The database hirschdatabase.mdb needs to be repaired or
isn't a database file" You or another user may
haveunexpectedly quit Microsoft Access while a Microsoft
Access database was open. Do you want microsoft to attempt
to repair the database? YES or NO

See the Access Corruptions FAQ at my website for things to try.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[glenda]

Have you already deleted the locking file that is
associated with the database? Prior to access being able
to repair your "hirschdatabase.mdb", you must delete the
locking file and nobody else can have the database open.
This always seems to work for me.

 

[Claude]

just for info : check your permissions (or ask your administrator) on the
shared directory where the access mdb resides.
Access need to create a new file in the same location as the currupted DB
when repair and/or compact must occur, and if you (the domain user) don't
have the necessary credentials on the shared directory, it cannot create the
temporary files.

Try the following : copy the MDB in a local directory, open it and make the
repair, then copy back the repaired mdb on the network.

Claude

 

[Donna Thornhill]

Yes, eventually the lock on the record is released and the
record can be edited. Had a meeting this am with netadmin
who still won't disable oplocks. He is moving db to a
server where oplocks is already disabled as a test to see
if it helps. I have 9 copies of this db, one for each
campus (we are a charter school organization); six are on
networks, 2 on stand-alone and one not implemented. No
problems with standalone versions as they are on
workstations and not even shared out. The network
versions are crashing 1 to 4 times a day (each).

Is there anything on the workstations that we should
change? (I saw your info about possible need to disable
oplocks at the workstation but figure this isn't worth
fighting until we can get it disabled on the server.) IT
has some sniffer tools. I volunteer to go over printouts
from each server and find each user's Office SR and Jet SP
if they'll run the reports, so I can make sure everyone is
using the same versions. If I understand what you said,
it probably only takes one user with a different version
to mess it up for everyone using that db.

When we first implemented, we had a few instances where
user2 couldn't get in and got message that user1 was using
it exclusively. We had user1 exit the program, then user2
could get in and user1 could also get back in. I found
the settings under the Advanced tab and set Default mode
to "shared," Default record locking to "no locks" and made
sure Open database with record-level locking was unchecked
but apparently this is for each workstation only. I asked
IT if they could push this out to the workstations and
they said yes if I could give them the reg entries. I
finally dug out the reg entries and then they said they
wouldn't do it because it was under the user profile
instead of the machine profile. (I don't understand what
difference that makes.) Should I try again to get them to
push these settings out?

One thing I noticed a couple of times. After getting
the "needs repair or not an AC db" message, I had to wait
a long time because I have to get IT to remove the share,
delete the lockfile, and reshare so I can get back on to
do the repair. I checked back and found the lockfile gone
(without IT intervention). When I started it, it opened
just fine with no repair. I'm not convinced that the db
is actually getting corrupted in these situations.

Sorry this is so long. Being concise is not one of my
strengths. Also, I'm not a programmer in case you
couldn't tell. I do badly need any assistance you can
give. Thanks!

 

[Tony Toews]

Yes, eventually the lock on the record is released and the
record can be edited. Had a meeting this am with netadmin
who still won't disable oplocks. He is moving db to a
server where oplocks is already disabled as a test to see
if it helps.
Good.

Is there anything on the workstations that we should
change? (I saw your info about possible need to disable
oplocks at the workstation but figure this isn't worth
fighting until we can get it disabled on the server.)
Agreed.

IT
has some sniffer tools. I volunteer to go over printouts
from each server and find each user's Office SR and Jet SP
if they'll run the reports, so I can make sure everyone is
using the same versions. If I understand what you said,
it probably only takes one user with a different version
to mess it up for everyone using that db.

Correct. You can also check for the correct versions
programmatically which is how I've done things.
www.ganite.ab.ca\access\verifyjetsp.htm

When we first implemented, we had a few instances where
user2 couldn't get in and got message that user1 was using
it exclusively. We had user1 exit the program, then user2
could get in and user1 could also get back in. I found
the settings under the Advanced tab and set Default mode
to "shared," Default record locking to "no locks" and made
sure Open database with record-level locking was unchecked
but apparently this is for each workstation only. I asked
IT if they could push this out to the workstations and
they said yes if I could give them the reg entries. I
finally dug out the reg entries and then they said they
wouldn't do it because it was under the user profile
instead of the machine profile. (I don't understand what
difference that makes.) Should I try again to get them to
push these settings out?

This may have been more of a permissions problem. Users have to have
read, write, change, delete permissions to the directory as the LDB
lock could be created, updated and deleted by any of the users.

One thing I noticed a couple of times. After getting
the "needs repair or not an AC db" message, I had to wait
a long time because I have to get IT to remove the share,
delete the lockfile, and reshare so I can get back on to
do the repair. I checked back and found the lockfile gone
(without IT intervention). When I started it, it opened
just fine with no repair. I'm not convinced that the db
is actually getting corrupted in these situations.

This correlates with a few other postings I've seen recently. Don't
know for sure what is causing all this.

Sorry this is so long. Being concise is not one of my
strengths. Also, I'm not a programmer in case you
couldn't tell. I do badly need any assistance you can
give.

Too long is much better than too short. The more details like this I
see I can correlate things better from other posters and see what
might be really happening.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm