Possible content loss in 1-item (not also bulk) item transfer to another db

[Spliff]

I don't know why this is so, but more often than not, in fact in more than 50 p.c. of cases, when I cut just ONE item from db a (^x), then paste it into db b (^v), the item's content is lost, i.e. the content pane remains empty. (I have observed this over many months.)

Thus, I have to visually check, then get the content from the discarded item in Recycle Bin of db a (^a, ^c), to put it "manually" into the target item in db b.

This prevents me from automating bulk transfer from my inbox db to the thematic target db's, fearing data loss; instead, I do it manually, then checking visually the first, the last, and some item in the middle of the bulk for data loss; on the other hand, this visual bulk check is always negative, i.e. in bulk transfer, I have never observed any data loss, just, and then regularly, with transfer of just a SINGLE item, from one db to another.

[kinook]

I tried several times but was unable to reproduce this behavior.

[Spliff]

There is an underlying problem; I hadn't make the connection up to this morning; there seems to be a more general UR clipboard delay problem with my UR installation.

(As said before, my UR DBs are on "WD Red Plus" HDD drive, with regular defrag (not of the whole drive, there is too much "traffic" to make that reasonable since it's, except for UR, my general "inbox", BUT regular defrag of the UR DBs (as said before, my O&O Defrag, and possibly some other defrag programs, make that possible; "Red Plus" means the HDD write the traditional way, so the HDD is not the culprit, and anyway, I have the problems described just in UR.)


A = the Above-mentioned (1-item transfer) problem

B = the above-mentioned Bulk transfer (seemingly no problem)

C = the (not-yet mentioned) systematic (sic! on my system) Content-copy/cut problem


A

Obviously, I do the ^x when tree has focus. Then, UR does not know if the transfer is made within the same UR db, to another UR db, or to a third-party program, so it has to put the whole data set into clipboard; obviously, this takes some time.

Of interest here: Whenever the transfer (cut-paste) of the item is done within the same UR db, the A problem doesn't occur: why? Obviously, because the (correctly existent or not correctly existent) clipboard content-pane data is not needed, but UR just triggers the necessary sql commands to update the parentage of the item in question, so even if the clipboard content is not correct, this doesn't show.

On the other hand, in more than 50 p.c. of the cases of A (= transfer to another UR db), the "Content" field content is lost; of course, in-between, I must change the db, by mouse click or by macro, but the macro doesn't involve any clipboard access.

Now it's possible - I'm not sure - that there is a delay problem: If after the ^x in the tree, I wait some seconds before changing the db, the results may be better than if I follow a regular workflow, meaning doing it "naturally", not "speedily" but not waiting on purpose (see C below to compare).

The amount of the content in that item seemingly does not play a role, i.e. the problem occurs independently of the content just being some words, some paragraphs easily readable on screen without scrolling, or more extensive content.

B

Since the problem seemingly does never occur in bulk transfer, I assume - I may be wrong - that internally in UR, the ^x in the tree, when more than just one item is selected, triggers another routine, NOT immediately putting all selected content into clipboard, but just "marking" the items for further processing; the same would be true for ^c, for both cases (= just one item, or multiple items).

Since then, when I press ^v within the target db, even whole sub-trees with dozens of items seem to be flawlessly copied / transferred, always, and which is obviously in contradiction with the A problem where such a transfer often isn't correctly done "even" for a single item.

Thus, I assume that bulk is not done by ^c/^x isn't done by putting the whole set into clipboard, then waiting for what may be wanted then, but it's the ^v only, in the target UR db, which then triggers the copying of the whole set.

As said, I may be wrong with that assumption, but whilst nobody would be surprised if it was the other way round: 1 item flawless, bulk = problem, the A problem (bulk flawless, but single items = problematic) is quite surprising indeed.

C

Not mentioned yet, but systematic (sic!) in my UR installation: Whenever I copy/cut something from another application TO the "current" content-field in UR, that's flawless, be it some words or some paragraphs... with the unique exception of "web import", where indeed, depending on the underlying source code of the page from which I do the select and then copy, the clipboard may indeed remain empty if I hadn't waited some seconds between the select (by mouse with shift), and then the ^c (in the browser); so these occasional web problems have nothing to do with UR indeed.

On the other hand, in any non-browser/web application, any text selection plus then ^c works instantly, be it just some words, be it several paragraphs, or more, there is no delay to be observed between the selection and the ^c, and then, after the ^c, the clipboard seems to be filled almost instantly.

Not so in UR: Whenever a UR content-field is my source, not my target, I systematically (sic! i.e. in all cases!) have to observe a wait of several seconds (3, 4) between the select (again by shift-mouse) and the ^c; if I do not observe that necessary wait, I can be sure that my ^v in the target application will either do nothing (= empty clipboard), or, according to the situation, will paste the previous clipboard content into the target (= clipboard content not being updated by the ^c in UR); the same is true is source AND target are the content panes of different items, be they within the same UR db, or in different ones.

Needless to say I thoroughly checked any possible macro interference, but there is none, I don't have any macro interception a ^c/^x, and when no script is running, it's the same delay I must observe in order to get, as said, even just some 2, 3 words of non-formatted text into the clipboard, from within UR.

I have come to live with that, but I'm not entirely happy with it. ;-)


Hence, comparing A, B and C, my assumption that A and C may linked by some underlying UR-to-clipboard problem, whilst B overrides that in some way.

[kinook]

Cut and copy in UR functions the same regardless of how many items are selected, and copying 1 item could not take longer than copying multiple. You can observe what is on the clipboard after cutting or copying from UR or another app using

https://freeclipboardviewer.com/

With that app running side-by-side with UR, I see the clipboard consistently and immediately being updated on cut or copy from the details of a text item, even when selecting and immediately copying or cutting.

[Spliff]

Thank you for the link, interesting find, really useful little tool indedd!

Made some ^c-tries within content panes, bits appeared in the viewer immediately, so the problem does not appear systematically but perhaps just after some hours of multiple UR DB's "running" - use it 10, 12 hours a day.

Then did ^c in the tree, for a single item (=not a parent of anything, no formatting of the item title in the tree) with just standard text (1 page)... and the viewer showed just the title (from the tree):

The viewer has "Preview", shows just the title(s) here, also for several items (several tries), and "Text" (ditto, here just the title(s) again, also in binary format (4C 69 65 etc etc); no content text to be seen.

Then they are multiple fields, "Locale Identifier", "OEM Text", etc., etc., with in some of them some scrambled text, and with the respective binary characters, but in none of them is the content text, in no format, i.e. already the length of the bits in those fields indicates the text is nowhere, and when I thoroughly check every field, I can't even see the beginning(s) of the content text(s); field "FileContents" (I don't know if that would be the field where the content text should appear) remains blank.

So I suppose the problem can not be identified, will have to live with it; as said, when I copy in bulk (i.e. multiple items), I have not encountered it yet.

[kinook]

The detail content isn't copied to the clipboard. When pasting, it loads from the source DB via the item IDs on the clipboard (UltraRecall:Items, UltraRecall:Filename formats, etc.).

So that tool seems to have some issues. This one worked better for me.

https://www.nirsoft.net/utils/inside_clipboard.html

You can check Options | Refresh on Clipboard Change to dynamically update.

I would need to be able to reproduce the behavior you're seeing in order to investigate. You might try starting Windows in Safe Mode to rule out any interfering applications.

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

[Spliff]

Thank you for the information. Have never used "safe mode", will No macro or script, no "clipboard manager" or something running.

1) ^x in tree is deemed, within UR (= target: same db or another db), to move the whole item (incl. content and other attributes); ^x or ^c in UR tree, with another application as target, is deemed to just copy/move the item title(s) - this is a big difference.

2) ^x in tree, from UR db to the SAME UR db, will not need to touch the content, but just reposition the item (ID) (^c is different here, content here will obviously have to be retrieved and rewritten to the new item(s), but I don't have experience with it)

3) Since UR doesn't know the target (same UR db, other UR db, external application) upon ^c/^x, all the necessary info is written into the clipboard, into those "codes": UltraRecall:Items, UltraRecall:TreeNodes, UltraRecall:ResourceLocatorW, etc. - all these are quite "cryptic" and, of course, your developer's secrets.

They will be used when needed (partly from UR db to the same UR db, full throttle from UR db to another UR db), and discarded when not needed (from UR tree to another application).

Thus, at the "^v moment" in any UR db, the UR has to check, and recognize (sic!), if the clipboard content is "ordinary" clipboard content, from either some UR content pane or some other application, OR from some UR tree.


Possible causes for problems:

a) Necessary cryptic-data not always correctly retrieved upon ^x (If there was not enough time / wait before switching to the other UR db, that would occur even more often for bulk operations, whilst for them, it has never occurred) (a: incl. possible third-party app interference)

b) Necessary cryptic-data not always correctly processed upon ^v if ^v is triggered in another UR db (which are named .db, not .urd, but a problem caused by not systematic recognition of the target as also being a UR db should occur both for 1- and multiple-items pastes) (b: also incl. possible third-party app interference)


Will run "Free Clipboard Viewer" systematically, minimized

I have not being able to produce the phenomenon with my tries, so if the problem occurs again, it will show if a) is the problem, or if also the cryptic-data has correctly been put into clipboard, but b) the processing at ^v is at fault.

Will then report back. (No idea why in regular use, problem occurs in > 50 p.c. of cases, whilst now, not once... will check running programs then which might not run now indeed!)

[kinook]

Again, it does not place all of the item content on the clipboard, just the item IDs and filename. When pasting, the processing will be different if it's a different DB (copy the items and their content, then delete in source DB vs. move of the items within same DB), but the same clipboard data is stored on a cut in both scenarios (has to, because it doesn't know if the paste is going to be into a same or different DB), and the amount of data placed on the clipboard is small and would be fast, whether one or more items.