Filter hanging

[hamishr]

I made the mistake of trying to filter all my records (over 300 000) without testing the filter first. I set up a value filter for Lifetime ID where it then tried to list all files, which made IMatch hang. I should have selected to search for a particular number. It would be useful to know how to break out of a filter that is making the program hang. Where there is a list, is it possible to limit the number listed, or list them in groups?

What I was actually trying to do is find the file number referred to in a warning from a Diagnosis Log File. What variable do I use (I now know it is not Lifetime ID)?

Thank-you

[Mario]

Use the File Finder app and enter the file oid:



Which filter did you use, with which settings? And a scope of 300,000 files in the File Window?

[hamishr]

Thank-you Mario, I did not know about the file finder app and it has done what I needed it to do. 

I listed all my 312 000 files because I was trying to find a particular file referred to in the log file, incorrectly trying to use the Lifetime ID but as you have shown, the file finder app, using OID is the best solution. IMatch was trying to list in a filter window ever single file in my database so that I could select the ones I wanted. This resulted in IMatch hanging. In general, it would be useful to find a way of stopping the filter trying to list too many files in a selection window. I could find no way of breaking out of the filter-induced hanging, other than breaking out of IMatch entirely. When I got back into IMatch it started trying to list the files again in the selection window, but I managed to stop it (I am not sure how).

[Mario]

When you use the Value Filter and enter a tag, the Filter Panel analyzes the current scope to fill the list with all unique values.

For a scope with 300,000 files, each having a different value for the tag by the nature of the tag, this will take a long time or probably just crash the Windows list control while blocking IMatch entirely. The database query is performed in a background thread, but filling the list box with the results must be done by the main (application) thread, due to how Windows controls work. And this is probably where all the time is spent.

I don't know if I have any safety measures in place in case a user tries such a worst-case combination. It's hard to foresee any possible user action when designing and planning features like this.

[hamishr]

OK, thanks. It would be great if there were some safety measuring to prevent hanging.