Corrupt Access File

[DS]

Is there a way to tell if an Access mdb file is corrupted before you save it
as a backup?
Thanks
DS

 

['69 Camaro]

Hi.

Is there a way to tell if an Access mdb file is corrupted before you save
it as a backup?

Other than checking the file size and finding that it's not a multiple of
4,096 bytes, or the database is not already acting bizarre, or the database
is not giving "Access has encountered a problem and must close" error
messages repeately, no.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[DS]

So that file size thing seems interesting...is there a way to divide the
file size by 4096 from access or a batch file?

Me.TextBox=filesize/4096

If Me,Textbox=a whole number then
Its Good
Else
Its Bad
End if

just some thinking off the top of my head.
Thaks
DS

 

[John W. Vinson]

So that file size thing seems interesting...is there a way to divide the
file size by 4096 from access or a batch file?

Me.TextBox=filesize/4096

If Me,Textbox=a whole number then
Its Good
Else
Its Bad
End if

If filesize MOD 4096 <> 0 Then
<you have problems>
Else
< you might still have problems but not this one>
End If

John W. Vinson [MVP]

 

[John W. Vinson]

Thanks John but how is this used....?
I just want to see if the file I just wrote to is good or not.
This divide by 4096 is seeming to be a tuff nut to crack. I've looked all
over the internet!

Ummm....

You don't need to divide by 4096.

You need to find out if the remainder after dividing by 4096 is zero (it
divides evenly) or not.

My expression does just that.

You would get the filesize, and use the expression below to see if it's zero
or not.

As Gunny says, that is *one* way to detect corruption, it's still quite
possible for a database to pass this test yet be corrupt. There *is* no easy
way, that I know of, to automagically wave a wand over a database and see
whether it is corrupt.

I'm basically appending my current info to an external History.mdb and after
I send the info I want to make sure that the History.mdb is not corrupted so
that if I have to use it for whatever reason I'll know that it's good!
Thanks
DS

John W. Vinson [MVP]

 

[DS]

Thanks John but how is this used....?
I just want to see if the file I just wrote to is good or not.
This divide by 4096 is seeming to be a tuff nut to crack. I've looked all
over the internet!
I'm basically appending my current info to an external History.mdb and after
I send the info I want to make sure that the History.mdb is not corrupted so
that if I have to use it for whatever reason I'll know that it's good!
Thanks
DS

 

[DS]

OK, Thanks John. You said there is no easy way. Is there a hard way?
I tried this but the If part gets error message 6

Me.TxtGood = FileLen("C:\ProServ\DB\TaxRateNew.mdb")

Me.TxtNum = Me.TxtGood * 1024

If Me.TxtNum Mod 4096 <> 0 Then
MsgBox "BAD"
Else
MsgBox "GOOD"
End If

So what exactly does this not check for?

Once again thnak you John. This is very important to me.
DS

 

['69 Camaro]

PMFBI:

You said there is no easy way. Is there a hard way?

Yes. Can you program binary, and do you have the specifications for the Jet
database file format so that you can check each bit for what it's supposed
to be? The "hard way" is fairly difficult and time consuming, and just not
worth it. If database corruption is common enough in your environment, then
you need to address what is causing the corruption and eliminate it or else
migrate to a more robust database, such as Oracle or SQL Server.

And determining that the file size isn't a multiple of 4,096 bytes (the size
of each data page) is only one determiner of file corruption, and not a very
common one at that. It happens when the database file has been saved in
another file format by a different application and certain data is
reformatted, removing some of the bytes from what was intended to be a
complete database page in the Jet file format.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[DS]

PS,
John Do I leave the FileSize in there or do I have to replace it with a
number?

If Filesize Mod 4096 <> 0 Then
MsgBox "BAD"
Else
MsgBox "GOOD"
End If

Thanks
DS

 

[John W. Vinson]

OK, Thanks John. You said there is no easy way. Is there a hard way?

I'm bowing out of this conversation; Gunny knows a heck of a lot more about
this than I do (I wasn't even aware of the size issue until I read Gunny's
post).

John W. Vinson [MVP]

 

['69 Camaro]

Hi, DS.

Do I leave the FileSize in there or do I have to replace it with a number?

If Filesize Mod 4096 <> 0 Then
MsgBox "BAD"
Else
MsgBox "GOOD"
End If

I see you've opened another thread and already received a working code
procedure, so we'll leave this question alone.

But I'd like to reiterate that focusing on the file size as the "only way to
determine whether the file is corrupted" is likely to disappoint you. It's
fairly uncommon these days, since most folks have been warned not to open
Jet database files in Word or other applications that automatically save the
file in their own formats. If you're appending records to a table in
another database file from within Access, then you shouldn't be worrying
about a data page arbitrarily becoming smaller than it should be. You're
not using an external software application. You're using Jet, a database
engine that knows how to append records in its native file format.

I would normally have zero worries if I were in your shoes, because you make
backups. However, if you have found corrupted files backed up and are
concerned about future corrupted backups, you need to address what's causing
the corruption, and checking the file size would be one of the last things
on my list. Check for a flaky network (your users aren't using wireless,
are they?!!), opportunistic locks on the network server, users hitting the
workstation's power switch at the end of the day while the Access database
is still open and writing to file, et cetera.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[missinglinq via AccessMonster.com]

As no one's addressed it yet, I will! The simplest thing you can do, if
you're so concerned about corruption, is what you learned in Programming 101:
Back up frequently! If you copy and paste to the same folder, within Windows
Explorer, the pasted files will bear the names

Copy (2) of YourDatabaseName
Copy (3) of YourDatabaseName
Copy (4) of YourDatabaseName
etc...

I do this and transfer the copies to a separate folder weekly, so I always
have my data thru the past week in a working database! It's a low tech answer,
but it works!

 

[DS]

Thanks,
That explains alot. No corruption isn.t a big problem, I'm just trying to
protect myself down the road. So where can I find out about all of the
different file corruptions and how to read for them> Is there a utility
program or a program that will do it? Thanks for the ton of info!
DS

 

['69 Camaro]

Hi, DS.

So where can I find out about all of the different file corruptions

Microsoft Access MVP Tony Toews has a comprehensive list of links to
information about database corruption. Please see the following Web page:

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

and how to read for them

You can't really "read" corruption, unless you built a special tool that
checks the Jet architecture byte by byte for any anomolies. Good luck with
that. ;-)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[bootybox via AccessMonster.com]

I'm sort of trying to do this. So you have one week at a time, after which
on the 2nd week you delete or overwrite the day from the previous week? This
is all well and good but my fear is what if you are saving corrupted versions
of your database and you don't find out until....it's to late!
Thanks
DS

 

[bootybox via AccessMonster.com]

Thanks, this is all very useful and I will take note of it. So you feel that
since I am backing up I should be OK. I'm using RAID 5, with daily back-ups.
Also I'm trying to figure out how to back-up on a transaction to transaction
basis. Like a bank does. So if I go down, I don't loose anything. Also I'm
using unbound forms with SQL statements, strating with an empty transaction
table everyday and have usually 7-10 users on the network signed in but only
maybe 2 or 3 using the network at the same time, very seldom all users will
be on at the same time. BTW this is for a restaurant so it's not constantly
being used.
Thanks
DS

Hi, DS.

Do I leave the FileSize in there or do I have to replace it with a number?

[quoted text clipped - 3 lines]

MsgBox "GOOD"
End If

I see you've opened another thread and already received a working code
procedure, so we'll leave this question alone.

But I'd like to reiterate that focusing on the file size as the "only way to
determine whether the file is corrupted" is likely to disappoint you. It's
fairly uncommon these days, since most folks have been warned not to open
Jet database files in Word or other applications that automatically save the
file in their own formats. If you're appending records to a table in
another database file from within Access, then you shouldn't be worrying
about a data page arbitrarily becoming smaller than it should be. You're
not using an external software application. You're using Jet, a database
engine that knows how to append records in its native file format.

I would normally have zero worries if I were in your shoes, because you make
backups. However, if you have found corrupted files backed up and are
concerned about future corrupted backups, you need to address what's causing
the corruption, and checking the file size would be one of the last things
on my list. Check for a flaky network (your users aren't using wireless,
are they?!!), opportunistic locks on the network server, users hitting the
workstation's power switch at the end of the day while the Access database
is still open and writing to file, et cetera.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[David W. Fenton]

I'm using RAID 5, with daily back-ups.

RAID has *nothing* to do with backups. It is designed to minimize
data loss from disk failures. That is all.

No form of RAID (even RAID 0, or disk mirroring) is a backup
strategy.

 

['69 Camaro]

Hi, DS.

Also I'm trying to figure out how to back-up on a transaction to
transaction
basis. Like a bank does. So if I go down, I don't loose anything.

Whoa! Whoa! If you can't afford to lose a transaction, then this database
application constitutes a "mission critical" application. You should not be
storing mission critical data in Access. Upgrade the back end to a
client/server database, which will safeguard those transactions with a
transaction log, so that failures can be rolled back or rolled forward to
always maintain the data in a consistent state.

And it doesn't have to cost beaucoup bucks to upgrade, either. If your data
will fit in a 2 GB Jet database file, then the data will fit in one of the
free express editions of SQL Server, Oracle, or DB2, or even in the free
MySQL database -- with plenty of room to spare. Please see the following
Web page for links to descriptions and downloads for these free database
engines:

http://www.Backends.QBuilt.com/

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[DS]

OK Great this sounds super! I'm using unbound forms in Access with SQL
codong, and my database will be split. So is this going to be easy? Is it
or will it be just tables will be in My SQL?
Thanks
DS

 

[DS]

You are absolutly write! I'm using it to keep the system running if a
disk goes down. I also know that I need a transaction to transaction
backup. And I would like to know if a file is corrupt before it is backed
up. I think that will cover all of the bases!
DS