Divide File Size By 4096

[DS]

I was told in an earlier post that you can tell if a mdb. file is corrupt by
dividing it by 4096.
I tried it but 'm not sure what the answer is suppose to be? Any direction
is appreciated.
Thanks
DS

 

[DS]

Ok My DB is 50,424 KB.
So if I take 50,424 and multiply it by 1024 I get 51634176 then divide by
4096 I get 12606.......
Which means what? Am I way off base? Close? Any help is appreciated.
Thanks
DS

 

[Damon Heron]

Don't use divide. To test this, select your Windows calculator in
Scientific view, and enter 51634176 MOD 4096 =.
Result should be zero, which means that there are no "stray bits" floating
around in your file to indicate corruption.

Good Luck
Damon

 

[missinglinq via AccessMonster.com]

Damon's response is the easiest way; you could also place debug.print
51634176 MOD 4096 in the Immediate Window. The answer to your actual question
is that you're looking for the answer, which is 12606 in this case, to be a
whole number, which it is. The 4096 is the size of a data page in Access.

 

[Damon Heron]

Use this subroutine to get the file size of another db:
(Call it with the mdb address like this)

ShowFileSize ("C:\your folder\DemoV4.mdb")

Sub ShowFileSize(filespec)
Dim fs, f, s
Set fs = CreateObject("Scripting.FileSystemObject")
Set f = fs.GetFile(filespec)
Debug.Print f.Size Mod 4096

End Sub

Damon

 

[DS]

Great Thank You....but just how did you get 51634176 ?
Also I need to do this in Access to check an external mdb file.
Thanks
DS

 

[Guest]

You said the size of the file is 50,424 KB
1 KB is 1024 B
Therefore
50424 * 1024 = 51634176 B

Now, even if you get 0 using the MOD function or a whole number using
division, that does not necessarily mean there is no corruption in the
database.

 

[DS]

So In other words if a whole number is returned then the file is good. As
opposed to if a decimal is returned then its no good?
Thanks
DS

 

[Damon Heron]

Seems fine, but why is the line repeated? In my original example, you would
call the sub from a command button or other, and give the file name in the
calling line. The filespec is the address you interested in.

As Klatu said, this doesn't mean your db is not corrupted in some other way.
This is just one test.

Damon

 

[DS]

OK I put this in a Module

ShowFileSize ("C:\PROSERV\DB\TaxRateNew.mdb")
Dim fs, f, s
Set fs = CreateObject("Scripting.FileSystemObject")
Set f = fs.GetFile("C:\PROSERV\DB\TaxRateNew.mdb")
Debug.Print f.Size Mod 4096

And I put it on a Command button on a form....

ShowFileSize ("C:\PROSERV\DB\TaxRateNew.mdb")
Dim fs, f, s
Set fs = CreateObject("Scripting.FileSystemObject")
Set f = fs.GetFile("C:\PROSERV\DB\TaxRateNew.mdb")
Debug.Print f.Size Mod 4096
I get a stack routine error code, I'm probably doing something wrong!
Thanks
DS

 

[DS]

Ok This seems to work, It's on a command button on a form..

Dim fs, f, s
Set fs = CreateObject("Scripting.FileSystemObject")
Set f = fs.GetFile("C:\PROSERV\DB\TaxRateNew.mdb")
Set f = fs.GetFile("C:\PROSERV\DB\TaxRateNew.mdb")
If f.Size Mod 4096 <> 0 Then
MsgBox "BAD"
Else
MsgBox "GOOD"
End If

What do you think?
Thanks
DS

 

[John W. Vinson]

So In other words if a whole number is returned then the file is good.

NO.

If the size is not divisible by 4096 then the file is certainly bad.

If it is divisible by 4096 then it MIGHT be ok, and it might not!

This is - as several of us have been yelling at you all day - *only one minor
test*. It *IS NOT* the answer to your problem.

Sorry! But it's *just not that simple*.

John W. Vinson [MVP]

 

[DS]

Just a typo! Boy what a can of worms I opened! I thought that it would be
simple! I'm just trying to protect myself from saving a bad file and
thinking I'm protected in essence I am not!
Thank you once again.
DS

 

[DS]

Your right! As a number of members have pointed out. I had no idea it was
this complicated, but I'm on the so to speak! At least I have one test.
How many more can there be? Does anyone do this at or on some level?
Thanks
DS

 

[DS]

Thanks John.
I appreciate the input. Holy Smokes I guess I have a lot of research!
DS

 

[Guest]

What kind of problems are you having that leads you to suspect corruption?

 

[bootybox via AccessMonster.com]

Hi,
I don't really have any corruption problems, yet.
I just want to always have a safe backup copy on hand. So I thought by
checking the file for corruption before I delete the old info, I will be safe.
This seems like it's a whole other program that needs to be written and a lot
of time!
Thanks
DS

What kind of problems are you having that leads you to suspect corruption?

Your right! As a number of members have pointed out. I had no idea it was
this complicated, but I'm on the so to speak! At least I have one test.

[quoted text clipped - 37 lines]

 

[Guest]

I understand, but basically, if you are diligent about keeping regular backup
copies, that should be all you really need.
If you want to know more about how to identify and recover (sometimes) from
corruption, search for posts here for dealing with it You also will find info
in the MSDN knowledge base articles.
--
Dave Hargis, Microsoft Access MVP

Hi,
I don't really have any corruption problems, yet.
I just want to always have a safe backup copy on hand. So I thought by
checking the file for corruption before I delete the old info, I will be safe.
This seems like it's a whole other program that needs to be written and a lot
of time!
Thanks
DS

What kind of problems are you having that leads you to suspect corruption?

Your right! As a number of members have pointed out. I had no idea it was
this complicated, but I'm on the so to speak! At least I have one test.

[quoted text clipped - 37 lines]

Thanks
DS