Possible Problem with <Letters><Numbers> Terms

[sizbut]

Ray,

My site supports products with names like "D100" and "ETR34".

Previously that hasn't been a problem (ZoomSearch 6 and, as far as I can tell from digging old material from my recent backups, ZoomSearch 7 Build 1001). However, with ZoomSearch 7 Build 1013 to which I upgrade back in December, its just been spotted that any search for terms consisting of letters followed by numbers as a single work returns no matches.

[I can apply a crude workaround using synonyms such as 100=D100 but naturally the results for 100 include a lot of other things that are nothing to do with D100].

Any ideas?

Regards,

Mark

[David]

It is a bug we accidentally introduced in build 1013 when trying to improve the splitting up Japanese hiragana and katakana characters into words.

It will be should be fixed up in the next patch release.

[sizbut]

Phew,

A stressful Friday afternoon trying to validate that it wasn't something I'd done and that it really was happening the way I thought (don't worry, I have to do the same sort of work on our own products at times).

Fortunately thanks to recently reimplementing "report.php" usage I think I spotted it before most site users. The synonym workaround at least gives a partial temporary solution and I'll give enabling substringing a go to see how that helps.

Thanks by the way for answering at the weekend, above and beyond as usual. I'll keep telling myself relax and wait for the next build*.

Cheers,

Mark

*(by the way just realised I've been quoting build numbers without saying which platform even though they vary between platforms - sorry about that).

[Ray]

This should be fixed in V7 build 1014 now
http://www.wrensoft.com/zoom/whatsnew.html#windows

[sizbut]

Thanks guys,

Downloaded. I'll hopefully get to test it by the end of the week. (I see it also fixes the odd crash when quitting the indexer after changing synonyms (annoying but not fatal so I hadn't mentioned it)).

Regards,

Mark

[David]

We're happy to hear about any crash issues you have.
If you are seeing it, then it is likely that a dozen other people are seeing it was well.

Trouble is that many big software companies ignore fault reports, so people have become rather apathetic about reporting problems, because they think no action will be taken. So we probably only hear about 10% of the problems people have.

[sizbut]

On the score of feedback I got to do some testing today. Sadly I have to report that I think Windows build 1014 has a big problem with categories.

When enabled most results show no title and no URL. About 1 in 6 will show a title and URL but the URL will be wrong in some way. A scattered few results will actually work. Some results also show as being in multiple categories even though the categories were all set to exclusive and by their nature (.pdf and .htm) shouldn't result in the same file in more that one category.

Turn categories off and everything is fine.

Testing included creating a new search from scratch and using the search.php with no adjustments.

Regards,

Mark

[Ray]

Mark -- confirmed the bug. We made a big change in the index format in the last build, and this got affected unfortunately.

It's fixed now and the patch build 1015 is now available:
http://www.wrensoft.com/zoom/whatsnew.html#windows

Let us know if you have any other trouble.

[sizbut]

Cheers,

Downloading 1015 now. Will let you know how it goes.

Regards,

Mark

[sizbut]

Thank you guys, all looking good. Thanks for the quick responses.

In more than 6 years of using ZoomSearch this is the first time I've hit a problem that wasn't my own fault (either something that I'd done in the configuration or in customizing the PHP script). A sterling piece of software backed by sterling support.

Regards,

Mark

[sizbut]

Busy day republish the searches for the different language sections of my site.

At least one unintended benefit (apart from helping you maintain the great product that I love) is that the auto-complete feature I was adding to the English language searches has now been implemented in all 14 languages I support since I was having to republish them anyway (along with search term logging for each language). And I've also enabled date based sorting for the PDF only variant of my searches - very simple but very nice as all good features should be.

So the end users have ended up benefiting (if they notice). Off for a beer, a weekend away from computer screens, and to mull whether to add date range searching to one particular area!