Not valid notebook error suddenly appears (1 Viewer)

[rpadams]

I have a very stable (2 yrs) application running in Access97 on a 5 user network. Suddenly the front-end wouldn't compact and I see error messages "Not a valid Notebook" or that there are mulitple users doing the same thing. It looked like the typical hanging .ldb -- but it wasn't. The .ldb was erasing as normal. I am absolutely certain this was not the problem.

I tried to "Repair" the database and it seemed to work, but when I then tried to "Compact" it gave me a message that it couldn't be completed because the database was Read Only. It DID create a temp.mdb file (presumably not erased when the compacting aborted early) which I renamed to the original file and it WORKED and compacted with no problem.

My client is very nervous about the whole thing -- this is a mission critical application and I can't explain what happened. Could there be a hidden minefield in the temp file? Does anyone know what happened or has seen the same thing before?

 

[vandewi]

This type of corruption is usually caused by a bad shutdown of the database. The corrupt file is quite often a system file that is created when the database is created. There are two things that I would try:
Create a new, blank database, and import all of your objects into it. (This will recreate the system files)
Or....
Download JetComp.exe from Microsoft.com. (You can compact without opening the DB.)

 

[The_Doc_Man]

Also, is there a chance that someone somehow imported a spreadsheet as an OLE into the database?

 

[rpadams]

Still looking for answers

I used the JetComp.exe on the original file; it seemed to work but then still wouldn't compact normally. There is no way that a spreadsheet got imported. I am still concerned with the reliability of the temp.mdb that was created just before the compact operation failed. It SEEMS to be working perfectly. As to the cause of the initial problem, with a little prodding the client did recall a couple of power failures within the last 2 weeks!

 

[vandewi]

You may still have a system object that is corrupt. If I am understanding you correctly, it sounds like you just made a copy of the database and called it Temp.mdb. What you want to do, is to create a brand new, empty database. Import all of the objects (including links) to the new database. This will recreate all of your system files (which you would otherwise have no control of).. Compile and compact the new database.

If this DB is truly mission critical, you could suggest that they purchase UPS (Uninterruptable Power Supply) units for each of the systems that use the DB. At the very least, make sure that the server is on a UPS.

 

[rpadams]

Temp file not really a copy

The client already had a UPS -- in an unopened box. They will install it this week. In regards to the "temp" file -- I don't know if it IS just a copy. I didn't manually copy it, but it was present in the directory as "db1.mdb" when the compact operation failed.
It was smaller in size (2.6 meg vs 3.7meg). I then renamed and compacted this file. It compacted with no error message and stayed the same size (2.6). No other temp file was made (or more correctly, showed up) during this compact operation.

I guess I need a better understanding of the whole compact process and, in particular, what steps happen along the way.

I am making a new database and importing the objects as you suggest, just in case.