Unexpected compound search results (with hints)

[Spliff]

One year ago, I hadn't been aware of "Nested Searches" in UR, users should open the "Advanced Search.urd" example db (C:\Users\YourName\Documents\Ultra Recall Samples\Advanced Search.urd) and read the comments in "Nested Searches" in there, as well as the search examples they describe: Just as in real SQL code, UR searches permit to search upon the result sets of "inner" searches, the latter to be written first, then to be referenced within the "outer" ones, so just as AutoHotkey is a wrapper to Windows internals, UR searches, combined, work as a wrapper to real, sophisticated SQLite selects, so using UR's nested searches will also introduce more clarity in case than trying to force the above-described "grouping by indentation" search syntax (which can bring unexpected results in case, as mentioned above).

Also, whilst it becomes evident that these nested searches in UR allow for just quite fine "project management", whatever those "projects" may be, part of the comments there

("A difficulty I have run into is that I also like to keep emails and other files related to a task (GTD support material) stored with the related task. The most convenient way to do this is for the support material to be included as a child item of the task. This has the advantage that when I remove or relocate the task item the attached child files are removed as well (great for filing, etc.).")

remind me of the newly-introduced, SPECTACULAR "Tree - Show - Level ..." expand commands group, and it should also become evident that precise (instead of "chaotic") "leveling" is BIG help in "project management" of any kind, since - just a reminder, not a critique -, that will visually preserve the tree indentation(s), and the (real) contexts (i.e. not "contexts" as that term has been denaturated in GTD)... both which (even the best) search can't provide (and which, at the end of the day, is the reason why we use UR, instead of just a "flat" SQLite db).

(As said before, nested searches should conveniently be constructed bottom-up, and of course you could use (i.e. reference) the same "sub-search" within several more global searches, e.g. write a multiple "OR" sub-search just for multiple variants of calendar dates, within the items you want to retrieve or to exclude... which re-arises the problem of - currently missing - quick specific-data change within UR's searches whilst in real SQL(ite)) code, you would do by (regex-) search-n-replace, but that's another subject: perhaps, it would be possible to make available some input field for real selects, i.e. for the necessary code, and which would then only processed if it contained sheer search, i.e. without "updates", etc, in order to prevent accidental db destruction?)

Oh, and just by accident, I discovered a simple way to trigger any search: Select the search item in the tree, then press {tab} two times "in a row".