Unable to compact & Repair

[cdacey]

I am unable to compact & repair my database. The process bar seems to just stop midway and brings me back to the database window, but the bar is left at 50% progress. It does generate a new a Db1 file, but file file size is identicle to the original database.

Any Thoughts ?

Thanks Chris

 

[The_Doc_Man]

Well, this is a nit-pick. Perhaps you should repair first, THEN compact. But if that is what you are doing already, then I read more into your words than was there.

If the DB1 file is being created correctly, the next question is whether this DB is on a local or shared drive. If it is shared, then you lack some particular permission that you need to do the file rename. Usually that means the ability to write to the directory, but at least in theory it could be something else, too. Particularly since you created the DB1 file.

If it is local, I haven't got a clue without an error message to give me a lead on what is failing.

Is the DB shared?

Is the DB on a disk that is nearly full?

How big a DB are we talking here?

Have you tried setting up the compact operation and letting the program just RUN for a while? Like, overnight maybe? I have a DB that likes to stop for a long time during some compacting ops. After a while it picks up again.

How long have you had to wait before giving up? If that number is fairly short, maybe you are just being impatient.

 

[cdacey]

Doc-Man
Thanks for the reply. I am trying to compact on a local server, although it is a shared database. I do first check to make sure there is no .ldb file so nobody is logged in.

The database size is 94Mb
The weird thing is that the progress meter literally freezes about 50% through, and the database window reappears. Now maybe I need to just leave it alone at that point for a while. At that point, it has only taken maybe 15 seconds. I assumed that because the database window reappeared it was through it's process. But even with the database window reappearing, you can still see the progress meter at 50%. Also it does create a Db1 file, rather then the actual database name, which would usually tell me there was some problem. I try to compact & repair the Db1 database, and the same thing hapens, and it creates a Db2 file.

I think I will try your suggestion on repairing first, and see how that goes.

Thanks Very Much !

Chris

 

[The_Doc_Man]

For a database of that size, depending on the speed of the disk, the speed of the CPU, and the amount of memory in your server, I would advise that you should leave it alone for a while.

I think that what is happening is that the first pass of the compaction finds everything that needs to be transferred and re-sizes it. Once that pass is done, the db1.mdb file can be created at the right size. But now, of course, it has to be populated.

That is where a second pass occurs. The first action of the second pass is that all the silly little pointers that make up the uncompressed database have to be sorted so the table components and module parts and stuff can be put into some semblance of order. This is a HUMONGOUS sort that might take a while. The more fragmented your db is, the longer this will take.

Now, as to why the screen comes back, I believe that the moral equivalent of a DoEvents call occurs sometime between the two passes. (Look that one up in the Help files.) This would allow a repaint of the db window.

 

[ghudson]

Have your tried the free Microsoft Jet Compact utility? Click on the link below for the version of Access you are using. For more details, search the Microsoft Knowledgebase for Jet Compact. I have had a lot of success using Jet Compact to repair a db when I thought it was corrupted and Access could not repair itself.

Access 97: Updated Version of Microsoft Jet 3.5 Available for Download

Access 2000: Jet Compact Utility Available in Download Center

Access 2002: Jet Compact Utility Available in Download Center

HTH

 

[cdacey]

Thanks

Thanks Guys, Very Chris