HCL Domino Ideas Portal
Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Splendid, thank you!
Ok, thank you. We can work with that. I created SPR JCUSBKSN4Z so you can track it. At this point, targeting 11.0.1
Here's the error message we get:
10/01/2020 14:57:56 Error full text indexing document NT00000000 (rc=3859) Database is currently being indexed by another process
Thank you, we much appreciate your suggestion. We'll do some tests with our application, by calling UpdateFTIndex just before calling FTSearch. If there are serious problems, we'll open a case with support. This problem we already experienced in R8 or R9, see http://ideajam.net/IdeaJam/P/ij.nsf/0/C84C6E5E7D6DCF224A2579AB0060FE1F?OpenDocument . Now testing with the brand new V11. We're hopeful!
Ok, the problem statement behind the idea is that there are documents newly updated that have not been full text indexed yet. And you have experienced difficulty keeping indexes current, though you haven't indicated how the "server complains heavily when the application requests the Indexer to be started too often". There are calls update the full text index in every API we offer. If those are not working, or you're persistently getting an error state, please open a case with support. We'll fix it.
This is provided by properly maintaining the FTIndex. please have a look at the DBMT documentation for refreshing an FTIndex on a regular basis.
Sorry, but that's just one of the many "technical reasons" that do not hold any ground IMHO. What you mention is what I simply call it bad maintenance. Of course there is an optimum for every database, and it could even be automatic.
Our technical reason that this doesn't work for us is that the server complains heavily when the application requests the Indexer to be started too often, e.g. while it's already running. Therefore, unindexed documents are inherent to full-text indexing, there is no way to guarantee that the index is up to date.
What is so wrong about the idea that FTSearch does what any nincompoop would assume it should do: search the flipping database (or view) and find all the documents matching a query? Or do you have any good logical reason for the behaviour you defend?
An FTSearch that fires against a database that has not been indexed in days will NOT perform. And the streaming required without indexing is expensive and slow. It is better to push unindexed documents into the index then do a regular FTSearch. Then all other threads and users benefit.