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

How to corrupt a MS Access database file in a 'normal' way?

P: n/a
Here is the situation: I wrote a VB programm, which stores all the
information in a single Access database file using jet engine. It
worked well, however one of my customs reported that there was some
problems with this programm. I checked, the log files showed that the
database was corrupted.

The customer told me that there no 'illegal' operation such as pull out
the plug, or kill the programm via task manager...

So is there any possible normal operation which could corrupt the
database? such as 'Weird characters' I guess? (The custom is from
Italy, is there any special Italian chars could do this?)

Of course it is possible that there are some bugs in the programm,
which possibly caused a error may corrupt the database file, but still,
how? The program wasn't stopped violently anyway ...

Anyone could give some idea about this? Since it is rather hard to talk
to Italians... So I can not completely investigate 'what they did about
the program'... I have to check the program and potential operations
which may corrupt the database.

Thanks a lot.

Jul 18 '06 #1
Share this Question
Share on Google+
17 Replies


P: n/a
shineofleo wrote:
The customer told me that there no 'illegal' operation such as pull out
the plug, or kill the programm via task manager...
Of course it is possible that there are some bugs in the programm,
which possibly caused a error may corrupt the database file, but still,
how? The program wasn't stopped violently anyway ...

Since it is rather hard to talk to Italians.
Did anyone head-butt the computer in involved?

Fifty per cent of the time people are unaware of illegal or violent
computer activity. The other fifty per cent of the time they lie about
it.

Jul 18 '06 #2

P: n/a
Lol, thank you for your humours reply.

Honestly, I do hope they didn't tell the truth, which is much easier
for me. In addition, this software has been used for a long time, and
there is no other customers who complained about this.

However, this time they said the similar problem repeated 4 times....
The first time I get the database file back, and tried to open it in
Access, it is said 'corrupted database file, do you want to fix it?' i
chose fix, then everything went back to normal. But 4 times... I
started to worry about if there is something goes wrong in my code.

Well, I don't think they would do the stupid thing 4 times... Or,
maybe... who knows...

But I just want to know the possible answer to this question, assuming
that the customers are telling the truth.

Lyle Fairfield :
shineofleo wrote:
The customer told me that there no 'illegal' operation such as pull out
the plug, or kill the programm via task manager...
Of course it is possible that there are some bugs in the programm,
which possibly caused a error may corrupt the database file, but still,
how? The program wasn't stopped violently anyway ...

Since it is rather hard to talk to Italians.

Did anyone head-butt the computer in involved?

Fifty per cent of the time people are unaware of illegal or violent
computer activity. The other fifty per cent of the time they lie about
it.
Jul 18 '06 #3

P: n/a
"shineofleo" <li*********@gmail.comwrote in
news:11**********************@35g2000cwc.googlegro ups.com:
So is there any possible normal operation which could corrupt the
database?
No, but bad versions of Jet on the machines using the VB app could
lead to significant risk of corruption. Jet 4 SP6 or SP8 is required
for reliable operation of Jet 4 (SP8 is the bug fix for the useless
SP7; SP7-8 add no real stability, only the security fixes to make
Jet less vulnerable to executing dangerous code).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 18 '06 #4

P: n/a
Thank you... But we deliver the whole PC to the customer... Now I am
trying to 'recreate' the bad result just like the customer, but no good
news... sigh....

David W. Fenton 写道:
"shineofleo" <li*********@gmail.comwrote in
news:11**********************@35g2000cwc.googlegro ups.com:
So is there any possible normal operation which could corrupt the
database?

No, but bad versions of Jet on the machines using the VB app could
lead to significant risk of corruption. Jet 4 SP6 or SP8 is required
for reliable operation of Jet 4 (SP8 is the bug fix for the useless
SP7; SP7-8 add no real stability, only the security fixes to make
Jet less vulnerable to executing dangerous code).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 18 '06 #5

P: n/a
The last time I got called out to a serious case of
database corruption, the users didn't realise that
having the computer stop and restart itself a couple
of times a day was anything worth commenting about.

You always have to be aware that Access is uniquely
sensitive to faulty networks, you always have to
listen carefully to users, but never accept anything
they say at face value: they aren't computers, and
they aren't literal like a computer program.

(david)
"shineofleo" <li*********@gmail.comwrote in message
news:11**********************@35g2000cwc.googlegro ups.com...
Here is the situation: I wrote a VB programm, which stores all the
information in a single Access database file using jet engine. It
worked well, however one of my customs reported that there was some
problems with this programm. I checked, the log files showed that the
database was corrupted.

The customer told me that there no 'illegal' operation such as pull out
the plug, or kill the programm via task manager...

So is there any possible normal operation which could corrupt the
database? such as 'Weird characters' I guess? (The custom is from
Italy, is there any special Italian chars could do this?)

Of course it is possible that there are some bugs in the programm,
which possibly caused a error may corrupt the database file, but still,
how? The program wasn't stopped violently anyway ...

Anyone could give some idea about this? Since it is rather hard to talk
to Italians... So I can not completely investigate 'what they did about
the program'... I have to check the program and potential operations
which may corrupt the database.

Thanks a lot.

Jul 18 '06 #6

P: n/a
"LeonC" <li*********@gmail.comwrote in
news:11**********************@35g2000cwc.googlegro ups.com:
David W. Fenton ???
>"shineofleo" <li*********@gmail.comwrote in
news:11**********************@35g2000cwc.googlegr oups.com:
So is there any possible normal operation which could corrupt
the database?

No, but bad versions of Jet on the machines using the VB app
could lead to significant risk of corruption. Jet 4 SP6 or SP8 is
required for reliable operation of Jet 4 (SP8 is the bug fix for
the useless SP7; SP7-8 add no real stability, only the security
fixes to make Jet less vulnerable to executing dangerous code).

Thank you... But we deliver the whole PC to the customer... Now I
am trying to 'recreate' the bad result just like the customer, but
no good news... sigh....
Well, lots of the corruption problems will show up only in a
multi-user scenario, so you can't expect to be able to recreate it
in a single-user scenario.

Secondly, the corruption problems could be caused by the software
configuration of the *server* on which the shared data MDB is
stored.

I would assume, of course, that you're not sharing the front end
MDB.

Check out Tony Toews excellent corruption FAQ:

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

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 18 '06 #7

P: n/a
Thank you guys! It is quite helpful!

Now I have narrowed down the cause to some point. I created the
corruption by shutting down the windows (normal procedure i think) with
the program running. However it is not strictly repeatable, when I try
the second time, it is normal again...

Technically, when the program is called to be closed, firstly it will
delete some 'pre-tagged' records in the database. I guess the datadase
operation is not fast enough to be completed, before the windows is
off.

My problem is how to generate the corruption by common termination of a
program... Any idea?

David W. Fenton 写道:
"LeonC" <li*********@gmail.comwrote in
news:11**********************@35g2000cwc.googlegro ups.com:
David W. Fenton ???
"shineofleo" <li*********@gmail.comwrote in
news:11**********************@35g2000cwc.googlegro ups.com:

So is there any possible normal operation which could corrupt
the database?

No, but bad versions of Jet on the machines using the VB app
could lead to significant risk of corruption. Jet 4 SP6 or SP8 is
required for reliable operation of Jet 4 (SP8 is the bug fix for
the useless SP7; SP7-8 add no real stability, only the security
fixes to make Jet less vulnerable to executing dangerous code).
Thank you... But we deliver the whole PC to the customer... Now I
am trying to 'recreate' the bad result just like the customer, but
no good news... sigh....

Well, lots of the corruption problems will show up only in a
multi-user scenario, so you can't expect to be able to recreate it
in a single-user scenario.

Secondly, the corruption problems could be caused by the software
configuration of the *server* on which the shared data MDB is
stored.

I would assume, of course, that you're not sharing the front end
MDB.

Check out Tony Toews excellent corruption FAQ:

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

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 19 '06 #8

P: n/a
Personally I'd log activity.

Log when they start the app, log when they stop the app. If you have more
starts than stops then they aren't exiting cleanly.
--

Terry Kreft
"LeonC" <li*********@gmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
Thank you guys! It is quite helpful!

Now I have narrowed down the cause to some point. I created the
corruption by shutting down the windows (normal procedure i think) with
the program running. However it is not strictly repeatable, when I try
the second time, it is normal again...

Technically, when the program is called to be closed, firstly it will
delete some 'pre-tagged' records in the database. I guess the datadase
operation is not fast enough to be completed, before the windows is
off.

My problem is how to generate the corruption by common termination of a
program... Any idea?

David W. Fenton ??:
"LeonC" <li*********@gmail.comwrote in
news:11**********************@35g2000cwc.googlegro ups.com:
David W. Fenton ???
"shineofleo" <li*********@gmail.comwrote in
news:11**********************@35g2000cwc.googlegro ups.com:

So is there any possible normal operation which could corrupt
the database?

No, but bad versions of Jet on the machines using the VB app
could lead to significant risk of corruption. Jet 4 SP6 or SP8 is
required for reliable operation of Jet 4 (SP8 is the bug fix for
the useless SP7; SP7-8 add no real stability, only the security
fixes to make Jet less vulnerable to executing dangerous code).
Thank you... But we deliver the whole PC to the customer... Now I
am trying to 'recreate' the bad result just like the customer, but
no good news... sigh....

Well, lots of the corruption problems will show up only in a
multi-user scenario, so you can't expect to be able to recreate it
in a single-user scenario.

Secondly, the corruption problems could be caused by the software
configuration of the *server* on which the shared data MDB is
stored.

I would assume, of course, that you're not sharing the front end
MDB.

Check out Tony Toews excellent corruption FAQ:

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

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Jul 19 '06 #9

P: n/a

If you are running the backend off a server, a intermittent network
connection or flakey network card will cause corruption regularly.
Other applications seem to be able to live with a less than perfect
network connection but Access isn't so tolerant.

Hope this helps.

Jul 19 '06 #10

P: n/a
"Wayne" <cq*******@volcanomail.comwrote in
news:11**********************@h48g2000cwc.googlegr oups.com:
If you are running the backend off a server, a intermittent
network connection or flakey network card will cause corruption
regularly. Other applications seem to be able to live with a less
than perfect network connection but Access isn't so tolerant.
It can't be, given that all workstations have to monitor the same
file for record locking purposes.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 19 '06 #11

P: n/a
David, I'm not sure what you mean here. Are you saying that a backend
file can never get corrupted by a faulty network connection?

Jul 20 '06 #12

P: n/a
"Wayne" <cq*******@volcanomail.comwrote in message
news:11**********************@75g2000cwc.googlegro ups.com...
David, I'm not sure what you mean here. Are you saying that a backend
file can never get corrupted by a faulty network connection?
I've seen that happen.

Keith.
www.keithwilby.com
Jul 20 '06 #13

P: n/a
"Wayne" <cq*******@volcanomail.comwrote in
news:11**********************@75g2000cwc.googlegro ups.com:
David, I'm not sure what you mean here. Are you saying that a
backend file can never get corrupted by a faulty network
connection?
No. I'm only providing the explanation of *why* Access is more
sensitive to network issues than other applications.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 20 '06 #14

P: n/a
David, I understand the meaning of your post now. Is this the only
reason that Access is more susceptible to network issues i.e. several
workstations are using the same backend? If, for instance, only one
workstation was using the server backend at a given time, is that
backend just as susceptible to a bad network connection as it would be
if several workstations were connected to it?

I'm interested in this because I have had one nightmarish situation
where a backend was being corrupted on a regular basis. To the best of
my knowledge usually only one person was accessing the backend at any
given time. The problem was traced to one of the workstations that had
a bad network connection.

In another case the server backend that was being corrupted only had
one workstation connected to it. The problem ended up being a faulty
network wall socket on that workstation.

Any more info on this subject is appreciated.

Jul 20 '06 #15

P: n/a
"Wayne" <cq*******@volcanomail.comwrote in
news:11**********************@h48g2000cwc.googlegr oups.com:
David, I understand the meaning of your post now. Is this the
only reason that Access is more susceptible to network issues i.e.
several workstations are using the same backend? If, for
instance, only one workstation was using the server backend at a
given time, is that backend just as susceptible to a bad network
connection as it would be if several workstations were connected
to it?
Yes, because the single workstation doesn't know there's only one
user. That's the point -- there is no central authority managing
connections to the database, so every workstation has to be have as
if it's sharing the file with other users.
I'm interested in this because I have had one nightmarish
situation where a backend was being corrupted on a regular basis.
To the best of my knowledge usually only one person was accessing
the backend at any given time. The problem was traced to one of
the workstations that had a bad network connection.
The file has to be opened and edited across the network. If there's
a problem in the network, it doesn't matter if it's one user or two
hundred.
In another case the server backend that was being corrupted only
had one workstation connected to it. The problem ended up being a
faulty network wall socket on that workstation.

Any more info on this subject is appreciated.
Well, just think about the way Jet works. It's a file server
database engine, with the workstations cooperating in allowing
edits. Each workstation has to check to see if the records are
available. COnsider also the refresh interval for showing changes
made by other users (I think it's 1 second?) -- that means your
workstation has to check for changes 60 times a second. This is
completely different from how Word would work -- Word isn't even
editing the original file, but a temp file, and it's the only user.
The only time there's network traffic is when you retrieve and save.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 20 '06 #16

P: n/a
Thanks for the info.

Jul 20 '06 #17

P: n/a
You can use 'exclusive links' if you relink using code -
the relink wizard does not support this option.

If you use exclusive links, the BE database is opened
in exclusive mode.

If you open the BE database in exclusive mode, you
would expect it to be cached locally in the network
client cache, reducing network traffic.

Even if you open the BE database in shared mode, you
would expect it to be cached locally in the network
client cache if you are the only user. This is what
'opportunistic' locking does: opportunistically, when
you are the only user, it upgrades shared locks to
exclusive locks, enabling the system to cache the file
locally in the network client cache.

There were a series of bugs found in the caching and
opportunistic locking code of Windows 2000 (as evidenced
by multiple announcements that it had been fixed).

In fact, while you might expect local caching to reduce
network errors, it appears that historically, local
caching has always been worse, with logic, code, or network
errors causing cache corruption. Of course, most of these
errors are cache errors when you have multiple connections,
not cache errors in exclusive mode. The simplistic
explanation of the opportunistic locking problems was
that they happened when a share lock request was received.
In any case, turning off file caching (and opportunistic
locking) has always been a good idea when you get file
corruption.

The Jet database engine is a distributed database engine,
with the physical record locking semantics provided by
the file system. In a network file system the file system
is a distributed database, with the server represented by
a network client 'file redirector', which uses Server
Message Blocks to communicate with the file service on
the server.

Any network errors are effectively errors inside the database
engine, and in any case the SMB protocol does not appear
to be robust: if there was adequate error handling network
errors should not cause errors in the record handling.
However, I haven't seen inside: perhaps the Jet engine
just ignores errors which were not in the original DOS
file system and network redirector it was built to work
with.

(david)

"Wayne" <cq*******@volcanomail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
David, I understand the meaning of your post now. Is this the only
reason that Access is more susceptible to network issues i.e. several
workstations are using the same backend? If, for instance, only one
workstation was using the server backend at a given time, is that
backend just as susceptible to a bad network connection as it would be
if several workstations were connected to it?

I'm interested in this because I have had one nightmarish situation
where a backend was being corrupted on a regular basis. To the best of
my knowledge usually only one person was accessing the backend at any
given time. The problem was traced to one of the workstations that had
a bad network connection.

In another case the server backend that was being corrupted only had
one workstation connected to it. The problem ended up being a faulty
network wall socket on that workstation.

Any more info on this subject is appreciated.

Jul 21 '06 #18

This discussion thread is closed

Replies have been disabled for this discussion.