View Single Post
  #12  
Old 06-28-2021, 07:58 AM
Spliff Spliff is online now
Registered User
 
Join Date: 04-07-2021
Posts: 72
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.

Last edited by Spliff; 06-28-2021 at 11:24 AM.
Reply With Quote