Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Frequent database error when checking

marcoi
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!
0

Comments

11 comments

Date Votes
  • RichardT
    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,
    Richard
    0
  • Luke Miller
    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
  • marcoi
    Thanks I'll try this asap to check if my problem is the same
    0
  • marcoi
    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
  • Luke Miller
    [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
  • marcoi
    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
  • Paul Steunebrink
    [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
  • marcoi
    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
  • mli20
    [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,
    Mogens
    0
  • Paul Steunebrink
    [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
  • David Alfred
    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.

    -David
    0

Post is closed for comments.