Frequent database error when checking
I'm experiencing a strange thing that is also under investigation on C1 team.
Almost every time I check the catalog file the database check fails. Repairs works (but always the second time I apply the fix), but I'm asking myself if I'm loosing some work. Anyway also the catalog with errors seems to work as expected.
I've done a sqllite compare over the backup catalog and the fixed one and besides minor changes what is more concerning is the content changes in zimage table in the fixed one.
Any other is experiencing the same problem?
Thanks!
Almost every time I check the catalog file the database check fails. Repairs works (but always the second time I apply the fix), but I'm asking myself if I'm loosing some work. Anyway also the catalog with errors seems to work as expected.
I've done a sqllite compare over the backup catalog and the fixed one and besides minor changes what is more concerning is the content changes in zimage table in the fixed one.
Any other is experiencing the same problem?
Thanks!
0
-
I also keep getting database check failures.
Attempt 1
Select "Verify Catalog or Session".
Select the catalog file.
Select "Close & Check".
Database content error - Database check FAILED.
Click "Repair": Database repair OK.
Click "Verify": Database check OK.
Click "Close": Capture One reopens.
Attempt 2
Select "Verify Catalog or Session".
Select catalog file.
Select "Close & Check".
Checking Database Structure - Database check FAILED.
Click "Repair": Database repair OK.
Click "Verify": Database check OK.
Click "Close": Capture One reopens.
Attempt 3
Select "Verify Catalog or Session"
Select the catalog file.
Select "Close & Check".
.... Capture One takes a while to close this time ....
Checking Database Structure - Database check FAILED.
Click "Repair": Database repair OK.
Click "Verify": Database check OK.
Click "Close": Capture One reopens.
Attempt 4
Select "Verify Catalog or Session"
Select the catalog file.
Select "Close & Check".
Checking database... - Database check FAILED.
Click "Repair": The verifier is not instantiated - Database repair FAILED.
Click "Verify": Database check OK.
🤓 That is rather worrying - hope it hasn't damaged the catalog!
Regards,
Richard0 -
If I do a verify of the catalog that is open I will consistently get a "Database Checked Failed" message after doing a Close and Check. This happen even with a null catalog (no images ever imported). If I verify a catalog different than the one currently open (no Close and Check) I get a "Database Check OK" message. In other words all three of my catalogs pass the check as long as they are not open when I initiate the verification. Alternatively, all three fail if they are open when I initiate the verification. Looks like a glitch in the "Close and Check" step rather than an actual database error. 0 -
Thanks I'll try this asap to check if my problem is the same 0 -
I tried but the problem persist... Do you know if it's better to fix it every time or, withount having any appartent problem, it's better to leave it with error if checked? 0 -
[quote="marcoi" wrote:
I tried but the problem persist... Do you know if it's better to fix it every time or, withount having any appartent problem, it's better to leave it with error if checked?
With my system it appears the "Database Check Failed" report is frequently an error itself. I can open a catalog and initiate verification, do a "Close and Check", get the "Database Check Failed" report and then close out without doing a repair. I then open a second catalog and do a verification of the one that just failed (no "Close and Check" needed) and get a "Database Check Ok" report. It seems that when the verification runs properly a long list of test results are displayed. If at the end of those results the report is "Database Check Failed" it is likely an actual error and a repair is appropriate. Most of the time if I verify the currently open catalog I don't get the string of test results just the "Database Check Failed" report. That report (without the list of tests performed) seems to be in error.
I think it is best to verify only those catalogs that are not open. I have an empty catalog that I load in order to check my other working catalogs. That catalog has never had an image imported into it. If I do a verification of that catalog while it is open I can get the list of test run and the "Database Check Failed" report. It seems that the catalog is actually corrupted and will report as such until I do a Repair. This suggest to me that performing a Verify of the currently open catalog has the potential to cause catalog corruption.0 -
Luke, after several weeks I think I have found the root cause. It seems that when C1 exits it takes a while to write everything on the catalog file. So if I close C1 and immediately shut down the PC (which has an SSD drive so it's extremely fast to shut down) the opened catalog will become corrupted. The same thing happens if I try to verify an opened catalog: the shutting down of C1 an reopen the catalog cause a corruption. And, once the catalog is corrupted I remains in this state forever or until the repair. Hope this can help others 0 -
[quote="marcoi" wrote:
Luke, after several weeks I think I have found the root cause. It seems that when C1 exits it takes a while to write everything on the catalog file. So if I close C1 and immediately shut down the PC (which has an SSD drive so it's extremely fast to shut down) the opened catalog will become corrupted. The same thing happens if I try to verify an opened catalog: the shutting down of C1 an reopen the catalog cause a corruption. And, once the catalog is corrupted I remains in this state forever or until the repair. Hope this can help others
Sounds that it could be an issue with write cache enabled on your SSD. Maybe you can disable it with the hardware manufacturer's software.
Thanks for sharing anyway. Might help others.0 -
Thanks Paul, I'll check if the Samsung Magician SSD software has this cache enabled.
And thanks also for your extremely useful articles on your website: really great explanations!0 -
[quote="marcoi" wrote:
Luke, after several weeks I think I have found the root cause. It seems that when C1 exits it takes a while to write everything on the catalog file. So if I close C1 and immediately shut down the PC (which has an SSD drive so it's extremely fast to shut down) the opened catalog will become corrupted. The same thing happens if I try to verify an opened catalog: the shutting down of C1 an reopen the catalog cause a corruption. And, once the catalog is corrupted I remains in this state forever or until the repair. Hope this can help others
Modern database management systems are capable of handling this scenario gracefully. Database updates are grouped together in transactions, which will always leave the database in a consistent state if fully written to disk. If not the partially written transaction gets rolled back, thus ensuring the consistency of the database at all times.
It is thus highly unlikely that the C1 SQLite database gets corrupted because of a PC shutdown.
Cheers,
Mogens0 -
[quote="marcoi" wrote:
Thanks Paul, I'll check if the Samsung Magician SSD software has this cache enabled.
And thanks also for your extremely useful articles on your website: really great explanations!
Thanks marcoi for your encouraging comments. Let's keep the ball rollin'. More to come! 😜0 -
I had success fixing this after a transferred session wouldn't open:
Database verification FAILED
Repairing database…
The verifier is not instantiated
The database failed to repair.
The database failed to repair.
This occurred when I moved a Session folder from an old Early 2008 MBP to 2015 MBPr. So I tried verifying from a different catalog with no success. Of course this is a big no-no but while the session was transferring over Wi-Fi, without checking the status I opened up the session on the host computer. This must have caused the error above.
All I had to do to fix it was delete the .cosessiondb file from the receiving computer and transferring it again from the host computer, this time making sure the file was closed and stayed untouched. It now works perfectly fine and is amazing to see the difference between the two computers. Hopefully this helps CO or somebody else pinpoint or understand their problem.
-David0
Post ist für Kommentare geschlossen.
Kommentare
11 Kommentare