[Spliff]

My UR-SQLite problems have gone in its nth iteration it seems, none of my UR DBs opened in my SQLite frontend anymore, even after re-install of the latter (new Navicat vesion anyway, from 6.0something to 6.1). (Ditto for previous Compact-and-Repair, and then the necessary signature change, of course.)

So I re-installed UR, too (for the nth time), opened the DBs in UR, closed them again after some changes, i.e. after real "save": no chance.

BUT with the re-installed UR, AND after compact-and-repair (in that), then signature change of course, the same UR files opened in Navicat without any problem.

HENCE:

Something on my system obviously deletes / changes some dll or whatever file, so that UR will NOT save my UR files with a correct header, I suppose (my UR files' headers are much longer of course than just the signature); UR will then continue to open those UF files correctly, but the generic form of the header is gone, just my assumption.

Now for a possible culprit: I regularly use (paid and up-to-date) "WiseCare 365", in order to get rid of (each time) thousands of crap files and crap registry entries, and since there are so numerous, I really need that "cleaner" tool.

This is just an assumption of course, something other also could do the change / deletion which then makes that UR obviously does not store my UR files in the generic SQLite 3 format again, so probably this description could help you with identifying the UR problem? (Everything else always works as expected.)

Now for the header, the problem is, those headers are very different from one UR file to the next (except for the signature of course), so in theory I could copy some headers for non-working (= as SQLite DBs) UR files, and of the others that work; this would imply some effort but if that can be helpful I could try, even with the "same" files "before and after" the treatment with the fresh UR install; by my theory, the headers should be different, but since I don't know what those header hyroglyphes "mean", I could not say if the changes then just come from compact-and-repair, or from the alleged fact that fresh UR writes other, correct SQLite headers, than the allegedly incorrect ones non-fresh-UR may write.

But it seems obvious to me that very probably, UR relies upon some "external" dll or such, for writing the headers upon "save", and that some third-party thing in my system changes or deletes that.

For example, the similar tool "RightNote" is said - I have never used it, does not appear "good enough" to me - to write generic SQLite from start on, without the need to do the obvious changes in UR to that effect.

Of course, next time I run WiseCare 365, I'll try before and after, in order to exclude that, in case, but the fact that UR does not write generic SQLite but its own, somewhat different format, seems to be at the heart of the problem, since it then enables the secondary problems to appear.

To make this perfectly clear from above: UR-re-install does not help, Compact-and-Repair does not help, but UR-re-install and immediate Compact-and-Repair after that, with the fresh UR re-install, does help, i.e. does produce the UR file in a format which then, with the necessary signature change in-between, will open in SQLite frontends.

(Ditto of course for the SQLite command line tool, with the additional problem in there that, as explained above, it will not give an error message but will just open some "memory" db in which then the user's sql commands will generate multiple error messages and/or non-"finds".)

All this is of course absolutely awful, I really never know "before" if my UR db "accepts" SQLite commands or if it's "not an SQLite file" again, and again, and again... ;-)


EDIT:

I just tried, Wise Care 365 (WC) is not the culprit:

I made changes in 2 files, in UR, then ran WC while UR was running. I then opened the files in Navicat without problem.

I then made further changes in UR, then closed UR (with the files), then ran again WC, then again opened / run UR again, and opened the files in UR (which now might have been affected by the two WC runs), made changes, saved, closed UR; again I was able to open the files in Navicat without problems.

Hence: Something else running on my system (I don't use another "cleaning" tool though) "fiddles" with something UR reaches out to, and then UR writes its files not in the correct generic SQLite format anymore, and then fresh UR install AND compact-and-repair with that fresh UR install will be necessary, in order to get generic SQLite format again (after then-necessary signature change).

I ALSO want to clarify that the problem is not due to the Navicat installation since I FIRST re-installed the (also updated) Navicat version, without any "progress" in the above-mentioned problems, then only re-installed UR, and even then, the problems persisted (now with new and updated Navicat) for every UR file which I had not yet "compacted and repaired" with the NEW UR install. Thus, some third-party software seems to affect some external file UR seems to need, and without the UR routine making the call becoming "aware" of that change, causing the misfunction of what UR "writes" then, be it in the header or elsewhere... and without that affecting the internal UR processing of the UR files, they are just not generic SQLite anymore then.

TO CLARIFY what above is implied:

If you can give a list of files of which a probably change by third-party software probably might be responsible for the above behavior, I could then copy those files, after a fresh UR installation, into a "safe" folder, in order to then compare them daily with the possibly changed files in their original position.

It would then be of interest, after UR's expected "SQLite fail", to just copy / write those "saved" files back over the "changed originals", then check if UR's "SQLite fail" persists, without doing a complete UR re-installation; thus, we could identify the file(s) which are responsible for the above (and perhaps I could even identify the culprit third-party software which changes that file(s)).