Compacting error

[Jon Polish]

Here are the particulars. My database is almost 15GB and I decided to repair and compress it. I started this at approximately 8:00am. When I left work at 6:00pm, it was still running. The process completed sometime overnight with the confirmation that compact and repair completed. I cliick OK and then this comes up (see attachment). What happened here?

What a waste of time.

[Jon Polish]

OH GREAT!

I tried opening this file and I get a dialogue requesting my password. This was not password protected before the compacting process. Can you please explain why compacting failed and how can I get into my database?

Yes, I am aware of the external repair tool. I am using it now and will be able to report the results sometime in June.

For your information, no power saving features were active, so the computer did not shut down during the compacting process.

Thanks.

Jon

[kinook]

I don't know. I've never worked with a database that large, but SQlite supports file sizes into the terabytes. There are potential dangers when adjusting the database synchronous level which might be a factor if you've changed it.

Another possibility would be something like a bad sector on the hard drive. You might chkdsk and defrag your drive, but I don't think they can diagnose all issues -- something like SpinRite or Norton Utilities may be more comprehensive.

If the external repair tool doesn't help, restore from a good backup.

[Jon Polish]

A remaining question is why the file became password protected. Would the external repair tool resolve this? If not, I will abort because I will not be able to gain access.

Jon

[kinook]

If opening without a password fails (due to either being encrypted or if the database is corrupted -- the second possibility seems more likely in this case), UR will prompt for a password and then attempt to open encrypted.

[Jon Polish]

Are you saying that if the file becomes corrupt, then UR thinks it is password protected?

[kinook]

SQlite returns the same error code when opening an encrypted db (without password) or a corrupt db (technically, I don't believe there's any way for it to tell there difference -- part of the security design of an encrypted db). So if opening without a password fails, UR will prompt for a password and then attempt to open encrypted if a password is provided. This will succeed if the db is encrypted and the correct password is provided, and will fail if the db is not encrypted (i.e., is corrupted or is not a SQlite db) or the wrong password is provided.

[armsys]

Would it be possibly caused by the corruption of %userprofile%\Application Data\Kinook Software\UltraRecall.dat?

Armstrong

[Jon Polish]

Thank you for your help.

Why do you ask?

I have had no trouble with other databases. I just partially rebuilt the corrupted database and went through the compact and repair procedure both UR and using the external tool. No problems at all. I imagine that if the UltraRecall.dat file was the source of the difficulty, it would recur.

Jon

[armsys]

Jon,
Thanks for your feedback.
My last post was just an echo of http://www.kinook.com/Forum/showthre...threadid=3897. The difference is no password was asked in my case.
Armstrong

[Jon Polish]

Thanks. I must have missed that post. Useful information, but it does not seem applicable in my case.

Jon