This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Rebuild of Quickfinder-Index with error F041 for one user

GW8 POA 8.03 12-03-14 (on Windows)

This POA is used as dedicated Quickfinder-Index-Machine.

Background: One user found the search function in the client running well for old e-mails. The search result window shows them at once, but then stays running and takes nearly forever trying to find more recent e-mails. As the e-mails of this user are sorted in the cabinet by folders (... 2013, 2014 and 2015) focusing the search on one of these folders 2014 or 2015 works perfect again. Due to this the decision was made to delete and rebuild all quickfinder-indices.

After this run in the log-file following entry was found for a different user: "database function 87 reported error F041 on userxxx.db". After some reading in the forums this different user was treated from standalone-gwcheck with "structural rebuild" and "database analyze and fix", which both went trough without major problems. Afterwards the delete and rebuild of all quickfinder-indices was done again with the same outcome (function 87 and error F041).

The search-function for the user it all started with is still hampered, but much more important for me is this F041-error and how to get rid of it.

Any hints on the further procedure are highly welcome.

Sincerely

Karl

Tags:

Parents
  • 0
    Hi Karl,

    Typically a F041 error on indexing means that said user has an attachment that is very large and contains the same word too many times - I'm not sure what the "too many times" limit is!

    With regards to the user who is having issues, you may want to rebuild just their indexes. Perhaps this TID is of some use: https://www.novell.com/support/kb/doc.php?id=7012997

    I would also suggest that you double-check your QuickFinder indexing settings. The first thing that I do is set, in the POA startup file, the qflevel 999 switch which forces the POA to index absolutely everything instead of the default, which I think is just the first 1000 messages. Next, after ensuring that the full index has run through to completion, I set the process to run at least every four hours in order to keep the indexes up to date. I'm not sure what you have set your dedicated indexing POA to, but perhaps check this?

    Please do let us know how it goes.

    Cheers,
  • 0 in reply to 
    Hi Laura,

    first I did another GWCHECK-run, which came out fine.

    Then I limited the Quickfinder to the one user with the error by adding qfuserfidbeg/end-tags in the poa-config-file.

    But when indexing this one user the problem persists ending with the followin log-snippet:

    14:26:33 0BC8 QuickFinder: 12020 items indexed
    14:26:33 0BC8 Indexing on attachment (00000001.Disk Day.32.224.txt)
    14:26:33 0BC8 Indexing on attachment (gwcheck.log)
    14:29:38 0BC8 The database function 87 reported error [F041] on userhi9.db
    14:29:38 0BC8 Error updating QuickFinder indexes: [F041]
    14:29:42 0BC8 QuickFinder indexing thread finished
    14:29:42 0A1C Scheduled Event: QuickFinder Indexing completed schedule

    From my point of view the indexing for this user is not finished, it just stopped. Probably there is an attachement or something like this, which causes this error. I would like to delete this E-Mail, but I do not know, how to find it.

    Any suggestions?

    Sincerely

    Karl
  • 0 in reply to 
    Hi Karl,

    Just a stab in the dark here....

    14:26:33 0BC8 Indexing on attachment (gwcheck.log)


    The above attachment appears directly before the error. Perhaps it's this attachment causing the issue?

    Please let us know how it goes.

    Cheers,
Reply Children
  • 0 in reply to 
    It is the admin´s mailbox. That is full of these gwcheck.logs. That would be quite a huge darkness to run into and test around.

    What does the indexer do with this zip-files? There is one e-mail with some whopper size of 73.535.817 kb with a zip-file as attachement.

    Should I try to config the POA for avoiding those files just as a test? From the log there is a 3-minute-gap before the error, what could be an hint on a longer lasting and therefore much bigger file.

    Would that make sense?

    Sincerely

    Karl