Tracking Access Corruption causes

[asparks]

We have a large DB with multiple users (20). The DB regularly gets corrupted
and needs repairing. I want to track the cause of the corruption, the last
table and enrty made etc to try to eliminate the problems. Is there a way of
doing this?
Thanks

 

[Albert D. Kallal]

I can't really think of much of a way.

however, have you gone this list of things to check for corruption:
http://www.granite.ab.ca/access/corruptmdbs.htm

 

[asparks]

Thanks - yep I've checked those things. I thimk there must be a way of
finding the last record written....which user/terminal was responsible for
the corruption....Anyone else?

 

[BruceM]

No thoughts on logging the corruption causes, etc., but if it gets corrupted
regularly it could be that a different approach will eliminate or at least
greatly reduce the problem. Is the database split?

 

[asparks]

yes it is split and regulalry maintained.....

No thoughts on logging the corruption causes, etc., but if it gets corrupted
regularly it could be that a different approach will eliminate or at least
greatly reduce the problem. Is the database split?

 

[asparks]

yes it is split and regulalry maintained.....

No thoughts on logging the corruption causes, etc., but if it gets corrupted
regularly it could be that a different approach will eliminate or at least
greatly reduce the problem. Is the database split?

 

[Fred]

This might be worthless or useful advice, but be sure to look at anything
that can mess with the back end file (besides the Access Front ends).
Backups, defrags, remote access etc. My last corruption was when my remote
access (combined with my greenness with it) misbehaved and overwrote the
master with a smaller defective file.

And a low tech way to narrow it down (or cause more problems )might be
to run a backup script that runs every few minutes and keeps a "sliding
window" set of the most recent 20 copies.

 

[Paul Shapiro]

You might add antivirus to that list of possible conflicts. I usually
disable scanning of .mdb's on both the server and the clients.

 

[asparks]

thanks all for your suggestions but non of these help me really. What I am
after is a way of creating a table or log file that lists all activity in the
DB - who is using it, what they have changed etc, then I can analyse the log
to see the last entry before corruption occurs.............

 

[Dirk Goldgar]

thanks all for your suggestions but non of these help me really. What I am
after is a way of creating a table or log file that lists all activity in
the
DB - who is using it, what they have changed etc, then I can analyse the
log
to see the last entry before corruption occurs.............

You could use something along these lines:

http://www.allenbrowne.com/AppAudit.html
Creating an Audit Log

You'd probably want to modify the code either to use a separate audit
database, or to write a text file instead of a database table.

 

[asparks]

thanks Dirk - but no good for me as we just use Access as the repository for
our data which is accessed via our own front end. We dont use Access Forms at
all, and the code you refer to is form based......

 

[Dirk Goldgar]

thanks Dirk - but no good for me as we just use Access as the repository
for
our data which is accessed via our own front end. We dont use Access Forms
at
all, and the code you refer to is form based......

You're not making it easy, are you? <g>

You can't make the back-end automatically log anything, and you won't
necessarily be able to tell from looking at the corrupted back-end exactly
what operation (or whose action) corrupted it. At least, I don't know how
to do that, and I suspect that the corruption itself might be as likely to
obscure that information as not.

All I can think of at this point is setting up a logging function in your
front-end. If it's not Access, then you can't use Allen Browne's code, but
that doesn't mean you couldn't modify the code in the front-end to log every
database action. I'd log it in a separate file, probably a text file, and
ideally one on a shared file server. However, I don't know if this will
necessarily allow you identify the "culprit" in your corruptions, since many
database operations may be able to continue even after some portion of the
DB has been corrupted.

 

[Fred]

Access back end, another app as a front end. That's a new one on me. Most
combos are the reverse.

But what you are asking for (if taken literally) sounds to me like it's
fundamentally impossible. If all of the brains, user log-ins etc. are in
your other unnamed front end application, and Access is just giving out and
receiving data, then it's not even being told who the user is.

 

[Larry Linson]

More than likely, you use a Jet database as the repository and Access is
nowhere involved. As the Jet .DLLs all run on the user machine... it's a
"file-server", not a "server" database... you have to do your logging from
there, and Jet does not provide built-in logging as many server databases
do.

Over half the Access clients to server DB back ends (MS SQL Server, Sybase
SQL Server, Sybase SQL Anywhere, Informix) that I worked on were set up that
way just for reliability (fewer opportunities, e.g., for a dropped network
connection to corrupt) and recoverability (built-in logging, backup, and
recovery). Relatively few were moved to Server back ends primarily to
maintain performance or support more users.

So, you may want to examine the option of changing to a server DB back
end... they range from modest to industrial-strength and from open-source
(free) to incredibly expensive. Installing and maintaining the server DB
will be the greatest cost -- you're already communicating with Jet in your
application as though it were a server.

Larry Linson
Microsoft Office Access MVP

 

[David W. Fenton]

We have a large DB with multiple users (20). The DB regularly gets
corrupted and needs repairing. I want to track the cause of the
corruption, the last table and enrty made etc to try to eliminate
the problems. Is there a way of doing this?

Are users sharing anything other than the back end?

Do all users have fully patched versions of Access?

Sorry, but I don't see corruption very often, so don't have much
more advice. You might try logging user logon and logoff and the
users who corrupted would lack a corresponding logoff.