Database Damage reported - Diagnostics fixes it

[Tveloso]

I believe that this is related to this bug fix delivered in IMatch 2025.2.2:

File Window Search #02750
Aborting a running search in the File Window Search Bar by pressing X, or aborting the search by switching to another folder while the search is still running in the background triggers IMatch to abort the search. This can result in a temporary table not being created (because it was aborted). Another part of the IMatch search engine was not aware of this, trying to access the non-existing table. This caused a (false) critical database error, a message about "physical damage" being shown to the user. Running the diagnosis "fixed" the non-existing error.

Related community topics: #15037, 15026

I had also reported something similar a few weeks prior to the topics referenced in that release note:

https://www.photools.com/community/index.php?topic=14962

...and after reading the above Release Note, I figured that my issue was essentially the same thing.

But it has happened here again.  I have found is that it's happening immediately after I run one of my Apps.  The App uses the v1/search/metadata endpoint, and I'm quite sure that when I posted topic 14962, I had also just run this App.

I use the App very infrequently, and this might be the first time I have used it since the above referenced bug fix was delivered (in mid-March).  While that bug fix corrected the issue for the search in the File Window Search Bar (which I'm guessing also uses the v1/search/metadata endpoint?), perhaps it can still manifest elsewhere in the code?...(and the way that my App uses the endpoint, causes it to still occur?)...

In my case it's also dependent on the number of files I select to run my App against.  I encoutered the issue with a scope of just 22 files (and could re-oroduce it with that scope).  But when I run the App for just a few files, the issue does not occur (I ran it with 6 files successfully multiple times).

With that scope of 22 Files, IMatch reports the Database Damage:

    You cannot view this attachment.

The first Database Diagnostics run also gives the error, but indicates that it may have been fixed, and suggests running another Diagnostics:

    You cannot view this attachment.

...and that second Diagnostics runs successfully without error:

    You cannot view this attachment.

I'll send a Debug log of an IMatch session where that happened, to the support email...

[Mario]

This sounds like the database returned a critical error at some time. IMatch remembers this to be able to inform the user and also for the next diagnosis (this is what produces the error message at the beginning of the diagnosis log).

And if the diagnosis fixes the problem (this also resets the "had error" flag IMatch maintains), there is no damage. 

I have have tried v1/search/metadata with various parameters and two different databases. It does not create a database error. What exactly does your app do? Which parameters do you use with search/metadata?

[Mario]

I think I've found it already. A race condition while dropping/creating a table for an in-memory database used to speed up queries. Multiple threads could compete for the cache, trying to create the same table at the same time. Because I forgot a ,1 in one place.

I'll doing some testing this evening, but I guess this is fixed.

[Tveloso]

Awesome!  Thank you so much Mario