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

HELP! Why does my database keep corrupting?

P: n/a
I have a database split for back end and front end and my back end (my
data) has been corrupting like crazy lately. Today we have compacted
and repaired like 4 times within an hour. The database is not
experiencing a lot of bloat. We have had instances in the past where
the database has gotten up to 200,00KB before indicating it needed to
be compacted and repaired. After C&R it is usually at 31,700 KB.
Lately when it gets to about 40,000KB we need to C&R - that's not a
whole lot of bloat. Today it hasn't been able to get over 32,000KB
without corrupting. We are constantly getting messages of
"unrecognizeable database format". Does anyone have any insight? I
can't continue like this - it is a production support database. When
it is down we lose valuable time and money.

Thanks!

Pamela DeVries
Nov 12 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Check to see if any hardware change have been made to the network and see if
the timing of the change(s) tie in with the sudden increase in corruption
problems.

Terry

"PamelaDV" <pd******@steelcase.com> wrote in message
news:b6**************************@posting.google.c om...
I have a database split for back end and front end and my back end (my
data) has been corrupting like crazy lately. Today we have compacted
and repaired like 4 times within an hour. The database is not
experiencing a lot of bloat. We have had instances in the past where
the database has gotten up to 200,00KB before indicating it needed to
be compacted and repaired. After C&R it is usually at 31,700 KB.
Lately when it gets to about 40,000KB we need to C&R - that's not a
whole lot of bloat. Today it hasn't been able to get over 32,000KB
without corrupting. We are constantly getting messages of
"unrecognizeable database format". Does anyone have any insight? I
can't continue like this - it is a production support database. When
it is down we lose valuable time and money.

Thanks!

Pamela DeVries

Nov 12 '05 #2

P: n/a
Terry,

Thanks for the suggestion. There is a constant battle right now between
my department (Access Development Services) and the network team. They
insist nothing is wrong with the network. But I have taken this
database apart and put it back together again - trying to find every way
possible to streamline it and we still have problems like this as well
as "Disk or network error" messages all the time. My strategy thus far
has been to just keep a log of the instances and the problems we have
been having to give them hard evidence. But they just insist that it's
not a network problem - it's not a network problem, etc... UGH! I did
have the power users recently upgraded to Win2K (many in this company
still running Win95!!!!) in an effort to increase the speed at which the
client and the server communicate. That doesn't seem to have done
anything for anyone.

Pamela DeVries

"Problems cannot be solved at the same level of awareness that created
them."
--Albert Einstein
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 12 '05 #3

P: n/a
Pamela,
This is probably not the problem, but since you mention that your
network has a mix of Win9x and NT class machine, does the backend
reside on a Win9x machine accessed by the Win2Ks? If so then you
should move the share to one of the Win2K machines as that can
contribute to corruption.

Most likely a flaky network.

Also, see ...
http://support.microsoft.com/default...b;EN-US;303519

- Jim

On 15 Oct 2003 16:41:47 GMT, Pamela DeVries <pd******@steelcase.com>
wrote:
Terry,

Thanks for the suggestion. There is a constant battle right now between
my department (Access Development Services) and the network team. They
insist nothing is wrong with the network. But I have taken this
database apart and put it back together again - trying to find every way
possible to streamline it and we still have problems like this as well
as "Disk or network error" messages all the time. My strategy thus far
has been to just keep a log of the instances and the problems we have
been having to give them hard evidence. But they just insist that it's
not a network problem - it's not a network problem, etc... UGH! I did
have the power users recently upgraded to Win2K (many in this company
still running Win95!!!!) in an effort to increase the speed at which the
client and the server communicate. That doesn't seem to have done
anything for anyone.

Pamela DeVries

"Problems cannot be solved at the same level of awareness that created
them."
--Albert Einstein
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!


Nov 12 '05 #4

P: n/a
pd******@steelcase.com (Pamela DeVries) wrote in
<3f*********************@news.frii.net>:
There is a constant battle right now between
my department (Access Development Services) and the network team.
They insist nothing is wrong with the network.


For what it's worth, in all my years of Access work, I've never
seen corruption caused by bad network hardware. Others have
different experiences, but mine go back to 1996 or so and with a
variety of clients.

I am excluding user error, of course (e.g., pulling the power plug
while a database is in use), and obvious things like unstable
workstations that are hosting the data file and crash while other
users are editing the data on the machine that crashed.

In A97, the only corruption I ever saw at all was in a replicated
back end and was caused by the application on the server where the
replicated data file resided of a Microsoft Exchange hotfix. The
corruption first happened within 2 hours of the application of the
hotfix and stopped as soon as we figured it out and backed out the
hotfix (it wasn't needed in the first place as Exchange was not in
use!).

In A2K, I've seen a lot more incidents of corruptions, all of which
were software issues for the version of A2K and the Jet db engine.
Once A2K was at SR1+ and Jet at SP6 on *all* workstations, the
problems went away *permanently*. I have been through this with at
least 4 clients that I can think of off the top of my head.

So, if it's A2K, before I went back to the hardware guys, I'd make
sure that 100% of the workstations are at SR1 or higher and have
Jet SP6 or higher. And it takes only *one* workstation out of 50 --
been there, done that.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #5

P: n/a
We had a similar problem develop on our little 5 user W2K network a few
months ago.
We could isolate it to one machine so in the absence of any other bright
ideas we re-installed MSOffice on that machine. It seemed to work???

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 12 '05 #6

P: n/a
Pamela DeVries <pd******@steelcase.com> wrote:
My strategy thus far
has been to just keep a log of the instances and the problems we have
been having to give them hard evidence. But they just insist that it's
not a network problem - it's not a network problem, etc... UGH! I did
have the power users recently upgraded to Win2K (many in this company
still running Win95!!!!) in an effort to increase the speed at which the
client and the server communicate. That doesn't seem to have done
anything for anyone.


Hmm, before you had the power users upgrade to Win2K were all the users running Win
95/98/ME? And it started corrupting when the first Win2K client was installed? If
so this is the OpLocks problem.

See the Access corruptions FAQ at my website for more info. Also see the
"Determining the workstation which caused the corruption" page.

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
Nov 12 '05 #7

P: n/a

Hi

You can do a very simple thing. On a Clean machine with a fresh
installation of MS Office do not C&R your database, instead create a new
one and Import the original database every thing.

I think this is happining because of somthing is missing in your MS
Office installation somewhere.

Regards,
--
Posted via http://dbforums.com
Nov 12 '05 #8

P: n/a
I wouldn't think the problem is with the network - it could either be
a mis-config'd workstation OR more likely to many people hitting the
same table to much. Do you have one table that is updated often by
different users?? Try to change the primary key to something unique
including the user ID.....
firasarramli <fr****@yahoo.com> wrote in message news:<34****************@dbforums.com>...
Hi

You can do a very simple thing. On a Clean machine with a fresh
installation of MS Office do not C&R your database, instead create a new
one and Import the original database every thing.

I think this is happining because of somthing is missing in your MS
Office installation somewhere.

Regards,

Nov 12 '05 #9

P: n/a
pd******@steelcase.com (PamelaDV) wrote in
news:b6**************************@posting.google.c om:
I have a database split for back end and front end and my back end (my
data) has been corrupting like crazy lately. Today we have compacted
and repaired like 4 times within an hour. The database is not
experiencing a lot of bloat. We have had instances in the past where
the database has gotten up to 200,00KB before indicating it needed to
be compacted and repaired. After C&R it is usually at 31,700 KB.
Lately when it gets to about 40,000KB we need to C&R - that's not a
whole lot of bloat. Today it hasn't been able to get over 32,000KB
without corrupting. We are constantly getting messages of
"unrecognizeable database format". Does anyone have any insight? I
can't continue like this - it is a production support database. When
it is down we lose valuable time and money.


It's the hardware. (1)

or

It's the software. (2)

or

It's imbecile users. (3)

My guesses would be in the order, (1,3,2), but you will get not much more
than guesses here. If you're losing valuable time and money why not hire
someone to check the hardware -> software?
(A high school student told me the librarians at his school have a simple
solution for all computer problems; they shut off the power for 30 seconds
and then reboot: no closing any programs, no shutting down the OS. What me
KNOW something about my JOB? You must be kidding!).

This should not be happening. There is a problem and the problem is
repairable.

Software: I would say, "No" before my daily read of this group, and "Yes"
after my daily read of this group. It's amazing what many people do and try
to do.

My experience: it's ALWAYS hardware except when it's imbeciles.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #10

P: n/a
Me****@ComputerSOSNJ.com (MeadeR) wrote in
<32*************************@posting.google.com> :
I wouldn't think the problem is with the network - it could either
be a mis-config'd workstation OR more likely to many people
hitting the same table to much. Do you have one table that is
updated often by different users?? Try to change the primary key
to something unique including the user ID....


I've never seen Access corrupt a Jet database just because there
were lots of people hitting it.

Do you have any documentation for this assertion, which is, on the
face of it, pretty ridiculous? It sounds to me like nothing more
than an unimaginative variation on the "Access is a toy database"
canard.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #11

P: n/a
Mi************@Invalid.Com (Lyle Fairfield) wrote in
<Xn*******************@130.133.1.4>:
Software: I would say, "No" before my daily read of this group,
and "Yes" after my daily read of this group. It's amazing what
many people do and try to do.

My experience: it's ALWAYS hardware except when it's imbeciles.


It's amazing how we can live on the same planet, use the same
software and come to exactly opposite conclusions.

I would put imbeciles second, like you, but software first.

Software is also the easiest to remedy, and that's another reason
for addressing it first. That is, you don't have to open up a
machine or run diagnostic tests. All you do is make sure that all
workstations are upgraded to the appropriate versions (in the case
of A2K, SR1+ and Jet SP6+), and if that doesn't fix the problem,
then you move on to something else.

I've never had a case where I had to move on to hardware diagnosis
when I did exactly this. Indeed, I've wasted a lot of time with
trying hardware diagnosis first before eliminating software as the
issue.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #12

P: n/a
Sorry, no documentation, just experience on having many users update a
table that is not properly clustered. Overall I think MS Access is a
GREAT RDBMS - it has it's limitations just like all the other
workstation based and/or C/S based RDBMS.....

The one thing I do know is that developers always blame hardware and
the network people always blame the software......in my experience
it's mostly the software.

dX********@bway.net.invalid (David W. Fenton) wrote in message news:<94***************************@24.168.128.78> ...
Me****@ComputerSOSNJ.com (MeadeR) wrote in
<32*************************@posting.google.com> :
I wouldn't think the problem is with the network - it could either
be a mis-config'd workstation OR more likely to many people
hitting the same table to much. Do you have one table that is
updated often by different users?? Try to change the primary key
to something unique including the user ID....


I've never seen Access corrupt a Jet database just because there
were lots of people hitting it.

Do you have any documentation for this assertion, which is, on the
face of it, pretty ridiculous? It sounds to me like nothing more
than an unimaginative variation on the "Access is a toy database"
canard.

Nov 12 '05 #13

P: n/a
Pamela DeVries <pd******@steelcase.com> wrote:
Thanks for the suggestion. There is a constant battle right now between
my department (Access Development Services) and the network team. They
insist nothing is wrong with the network.
Standard stuff.
But I have taken this
database apart and put it back together again - trying to find every way
possible to streamline it and we still have problems like this as well
as "Disk or network error" messages all the time.
"Disk or network error" in my experience have always meant hardware problems.
However I would work on the OpLocks change first.
My strategy thus far
has been to just keep a log of the instances and the problems we have
been having to give them hard evidence. But they just insist that it's
not a network problem - it's not a network problem, etc... UGH! I did
have the power users recently upgraded to Win2K (many in this company
still running Win95!!!!) in an effort to increase the speed at which the
client and the server communicate.


Upgrading the power users to Win2K was the cause of your problem. Presumably until
then all your users were running Win 95/98/ME. The OpLocks problem starts occurring
as soon as one workstation in the network has Win NT 4.0/2000/XP installed.

For more info see the OpLocks section at the Access Corruptions Causes page at my
website. Also see the Determining which workstation caused the corruption page to
help pinpoint which workstation(s) is the problem.

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
Nov 12 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.