I've seen postings about this before, but we're seeing searches fail with the message "Sorry, we were unable to find a good answer for your question." even though the term being searched is present in countless places within the help.
To address this we have increased the java heap space, as advocated elsewhere and we are seeing the same intermittent problem. Digging into this further we've examined the SQL server logs and according to one of our engineers it appears that RoboHelp is occassionally passing invalid syntax as part of its search query, which causes the search engine (Lucene, I guess) to throw the error.
The pattern seems to be that a particular term or two will produce the "Sorry..." message for a week or so then another term or two will exhibit the problem and the original terms will work properly.
Here's another puzzing detail: if I right-click the body of the WebHelp Pro help page and cut the URL from the Properties dialog and then paste the same URL into a different browser page, log in past the Admin page, and perform the same search, then the search works fine.
Has anyone experienced this sort of behavior? Any ideas what might be going on?
Can you verify that in the Configuration Manager application (which is on the server machine) is set to "Reindex Documents at Server" is checked?
If you could zip up the Tomcat log file that would be helpful.
You'll find it on this path on the Server machine:
C:\Program Files (x86)\Apache Software Foundation\Tomcat 6.0\logs\robohelpserver.log
Send it to my email which you can find in my profile at right. I'll send that to an Adobe engineer and see if we can diagnose this.
BTW, did you finally get the issue resolved mentioned in this thread?
Adobe Certified RoboHelp and Captivate Instructor
Thank you! When I return to the office tomorrow I'll investigate whether or not this etting is enabled and also pull the log files.
As for the other thread, we worked around the issue by resurrecting the virtual machine image that contained our trial install, which had been working fine, and activated the expired trial install with our newly purchased license. For whatever reason, this seemed to work fine.
It's funny about the "reindex at server setting." We have three or four terms that fail the search in a predictable fashion: changing this setting from On to Off alters which of the group fails or succeeds when searching. For example, "On," results in terms A and B failing but C and D work whereas "Off" results in C and D failing but A and B work. This is repeatable.
Thanks for your help. I hope they find something in the logs.
Hi, Rocky. The Adobe engineers that I wanted to review your logs are returning from an extended holiday break. I will have an opportunity this week to raise this issue now that they are back.
As a follow up to folks following this thread: Adobe engineers identified Rocky's problem after looking at his server log files and it was successfully resolved. If anyone encounters a similar problem, post it here on the forum and we'll see if we can help.
Adobe Certified RoboHelp and Captivate Instructor
I looked into this thread, looks related, but you didn't tell how Adobe engineer solve this issue. I just posted
would it be related to this thread? if so, maybe you already have answer?
Adobe solved our problem by providing the patch "SearchUtils.class." Apparently, the problem was with certain combinations of characters in the search queries.
In response to your original issue, it didn't have any effect on differences between webhelp pro versus webhelp results. We've seen differences, but we're so happy to have searching working again that we're overlooking it.
Thank you very much for your reply!
we once turned on "reindex at server setting" and asked by adobe support to turn off. now we have " substring..." turned on in configuration manager. however, we still have inconsistent searching result for substring:
search term is vaccine, it returns the result, but if I enter vacci doesn't work, while vaccin works.
Do you think the patch "SearchUtils.class." will solve our problem? whom do you suggest we contact to so that we can get fix quickly?
Here’s a summary of what we’ve experienced:
Because we’d rather have the “display by file name” bug instead of the failed search bug that requires a help relaunch, we keep “Reindex documents at server” checked. This means that partial string searches is disabled for us.
I am having similar problems as stated above. We have 5 different RoboServer projects going and have identified different words in different projects that return zero results even with the word in the title. The words are "volunteer", "Bailee", "Fees", "Fee", "Mueller".. seems like we might be experiencing the same problem related to search queries containing some combination containing the letter 'e'.
We have RoboServer 9, the Search works perfect on those same words, in preview mode, just an issue when run on the server. Any chance I can get access to the SearchUtils.class patch?
We secured the file and applied the patch and I republished the project and am still experiencing the same problem. In terms of applying the fix, does it matter if the server option for Reindex documents at server is checked or unchecked? We currently have it off.
Europe, Middle East and Africa