Search problems [resolved]

[Spliff]

Please forgive my above error, I could have found it - and found it now - within the "Search Options" help: "Match anywhere in word by default ... Note that this does not use an indexed search and can be slow."

I obviously had not been aware of this, and with a database of 60,000 items, it's clear as day that this brought problems, unnecessarily indeed, since I don't even need this functionality.

Thank you very much again for your very kind help, and again, the Search has been working perfectly ever since! (Unfortunately, I can't change the thread title, but you could: > "Search problems (resolved)"!
__________

I would like to suggest implementing more shortkeys to the Search; these would be of tremendous help, some of them being of much more use to some users, others to others, and the implementation should not ask for much work I hope?

Please see below; according to your possible comments, or to comments of other users, I could re-think and come up with some other alternatives:

General Menu:
Alt-abefghiortvw = 12

Thus available for Alt-...: cdjklmnpqsuxyz = 14 (Total = 26)

currently used in "Search": Alt-l, n (in "Quick" only), s, u (in "Advanced" only)

("Stop" button does not need a shotcut, since it's also available by "Escape")

"Quick Search":


Fields:

"&Search for:"

Buttons:

Start (per "Enter")
Reset (why not Alt-z, similar to ^z "Undo"? could be written "Reset (&z)")
Copy (why not Alt-c?)
Adva&nced

Checkboxes:

Search titles only (I need to toggle this again and again; no "natural" Alt-key available here, but it would just be needed in "Quick"),
THUS, why not Alt-q (written as "Search titles only (&q)")
IF you are willing to change the &Limit search to selected item in Data Explorer pane to Alt-d ("&Data..."), the Alt-l would become
available for "Search tit&les only", but that's not really needed, I would be perfectly happy with "Search titles only (&q)",
the important thing is that there will be a shortcut, any shortcut, for this toggle
OR "Search titles only (&u)" if you don't want to change, in "Advanced", "Q&uick" to "&Quick", since any "Quick" shortcut will only
be used in "Advanced" and thus will be available for "Search titles only", a command only available in "Quick Search".

and, as in "Advanced":
Match whole words (why not Alt-m?)
&Limit search to selected item in Data Explorer pane (meaning the selected sub-tree, I also need to toggle this again and again)
Search only user-defined keywords (why not Alt-k?)
Include items in the Recycle Bin (why not Alt-y?)

"Advanced Search" (caption is always "Quick Search" though"):

Fields:

&Search for: (as in "Quick")

Buttons:

Start (as in "Quick")
Reset (as in "Quick") (see above)
Copy (as in "Quick") (see above)
Q&uick (Search) (could better be Alt-q instead, see "Store dates..." below)

Checkboxes:

Store dates relative to current date (suggested: Alt-u, i.e. c&urrent, with &Quick instead of Q&uick, is more mnemonic)
OR, if you don't want to change the Q&uick, Store &dates, i.e. Alt-d here

and, as in "Quick" (see above):
Match whole words (suggested as above: Alt-m)
&Limit search to selected item in Data Explorer pane
Search only user-defined keywords (suggested as above: Alt-k)
Include items in the Recycle Bin (suggested as above: Alt-y)

[kinook]

Many of these are already used. For instance, Alt+C is the default shortcut for Calendar, Alt+D for web address combo, Alt+Z to insert date/time, etc. And users can create other Alt+key shortcuts, which could conflict with search mnemonics.

[Spliff]

Sorry, I just discovered your answer now, my inadvertency.

I am aware of that, sorry for not commenting on this "problem" in my post above. But I think that within the special "context" of the Search Pane (not also: Search Results Pane) having focus - both user interface wise and technically (UR internals) -, the user would NOT be tempted to get to those functions, so their otherwise global shortcuts having another function within this special context would be acceptable; this being said, in order e.g. to toggle specific check-boxes there (e.g. "title only"), not only Alt-shortcuts would / could work, but also Control-shortcuts.

This being said, I suppose that with external macros, I could toggle "Button8" (for this "Search titles only" example), etc., will have to look into this; the latter not being a "general public" solution obviously.

[Spliff]

I would like to make a search scope suggestion.

When I am in a hoisted tab (i.e. 2 tabs, tab 1 comprising the whole tree, current tab 2 displaying a (in case, quite considerable) sub-tree), "Limit search to selected item in Data Explorer pane" does exactly that, so if I want to restrain my search to the hoisted sub-tree, I first must select the "source", the hoisted item for the items currently displayed, whilst the general search, even in the hoisted tab, works on the full, original tree, which in almost any use case is not what the user will want (I'm speaking for other users here, but I'm quite sure I'm not mistaken in that).

So my suggestion would be that general search within a hoisted tab should, "behind the scenes", apply the "Limit search to selected item in Data Explorer pane" functionality (= which is already there, so technically, it would be easy) to the source item of the hoisted tab, independently of which item in the hoisted tab currently is the current item.

Selecting the "Limit search to selected item in Data Explorer pane" would then, even in a hoisted tab, continue to apply to what it says, i.e. further limit the search scope to the current item and its sub-items.

And in the rare use cases where the user, from within a hoisted tab, would want to search by general scope, they would have to switch back to the un-hoisted tab, but then, if you want to work upon a search result beyond the scope of the current hoist, from within a hoisted tab, that causes problems anyway, so my suggestion would at least create a neat scope for the search results; currently, if you don't first select the source item before your "hoisted tab" search AND check "Limit search to...", you not only also get search results from outside of the hoisted sub-tree, but, even more of a problem, you cannot even identify those visually from those within the "hoist" (the possible column "Parent Title" just showing the immediate parent item, so it's rarely a reliable indication). Thus, I think that my suggestion will, after all, not harm any current use case but enhance the alleged "user experience" for any user.

EDIT: If really there was a risk that some users could not be happy about that change, there's always the possibility to create an option in Tools - Options - Search, "In hoisted tab, don't apply general search to the hoisted part only." or something like that... I'm sure nobody would check that option then. Or then the other way round, with everybody checking the option consequently.

Perhaps, and if an option really should be needed, a wording like "Search applies to full tree even in hoisted [better: "hoisting"?] tabs" would probably be best, with this option NOT being selected by default.

[Spliff]

"Perform phrase match by default" (in Tools - Options - Search" (set to ON)) is not always reliable.

I have got searches for "Art. 10" for example, any number here, "Art." short for "Article" but as "Art." in the text.

If I search for
"Art. 10"
I get correct results, but if I search for
Art. 10
(which, according to my option setting, should bring the same results), I get endless lists of items where just "Art. anynumber" occurs, AND where anywhere in the text, the number in question also occurs, so for
Art. 10
the option "Perform phrase search..." does not work.

The dot after "Art" may be the culprit here, haven't got the time to look deeper into this. Is there any known explanation, so that we can foresee the situations in which this will occur? Is the way the elements are indexed playing here?

As said, no problem with enclosing "".

[kinook]

I was unable to reproduce this behavior. Using the attached database, with 'Perform phrase match by default' checked, there are 3 results when searching on

Art. 10

(matching only items that have "Art. 10" in the item text) and 5 results with that option unchecked (also matching items that have Art. and 10 somewhere in the item text).

Please send the info from

https://www.kinook.com/Forum/showthread.php?t=3038

[Spliff]

Thank you for answering, Kyle! I must admit that after rising my main database's item count over 100,000 items (which caused real problems, see my thread "Reasonable database sizes"), and then setting it back to about 75,000 items (with the only (I thought) - persisting - problem left that after ^x, the item's icons are not greyed-out anymore - I decided I could live with that), I have NOT yet created a NEW main database, into which I then would have imported all my 75,000 items.

Thus, the behavior I described above, may be another "database having been too big" phenomenon indeed; before mentioning possible other glitches I may discover, I'll note them somewhere in-between, will re-create my main database, then check again if the problem persists, then only will mention it here in case!

(After the resizing back down to about 75,000 items, I obviously ran Tools - Compact and Repair - Enable enhanced full-text search features", so whilst this obviously - since you weren't able to re-create the phenomenon - is not an indexing problem (possibly connected to indexing of abbreviations and/or numbers); my command would have re-created the full index if I'm not mistaken), it should be connected to some "general instability residuals" after my blowing the database size up too much.)


EDIT: I now have created new databases, i.e. I copied most of my items from the "problem" database into a newly-created one, and some into another newly-created one, so my main database has got currently about 60,000 items. Since the flag formatting is database-specific, I also had to re-create the flag-formattings for both newly-created databases (I should perhaps create an empty database with those formattings, then copy that for filling it up with possible moves.)

Problem "^x will not grey-out the icon": Persists in newly-created main database with 60,000 item, does not persist in newly-created, tiny database. Thus: UR has problems with big databases in this respect; I can live with that, but it's useful to know about it. Obviously has nothing to do with previous over-resizing(s).

Problem "Default phrase search by option also finds the parts of the phrase": Is more general (in all three databases, the "source" one and the two newly created "target" ones): ANY phrase search gives unwanted results, any
wordone wordtwo
phrase (and, as said, "wordone wordtwo" works as expected):

Both parts are highlighted within result items, i.e. any occurrence of wordone, and and occurence of wordtwo, and even when wordone or wordtwo (I checked both) are in the middle of another word, e.g. abcwordtwoxyz, wordtwo in this example is highlighted.

On the other hand, it seems - I checked numerous such results - that in order to list an item as a search result, both parts, in correct order, have to be there as a phrase, i.e.
wordone wordtwo
exactly in this order, anywhere in the item in question; it's just that the part (and even within other words) are all highlighted this way then.

When I include the phrase within "", just the phrase occurrences are highlighted though, which is the expected behavior.

I can live with that, i.e. I just do phrase searches the traditional way, in "". (Here again, I had re-installed UR even before, so any trace of my "125,000 items in a single database adventure" should have been gone now. Perhaps it's "my system", in some way or another... as said, I can live with those glitches.