|
Thank you for the hint, Kyle, you're right again!
I had "overlooked", i.e. not cared about these, them being 32bit, but after all, UR is 32bit, so their 64bit .dll looked the "way to go"; I had wrongly assumed that .exe was an old one, but it's from May 6, 2022 indeed!
Of course, and as expected - I tried, in order to not spread fake news again -, it's not able to open .urd DBs, while they come with the .urd suffix, so this can't be used for some "quick change" while the db is open in UR.
And, obviously, the SQLite developers "update" all their stuff, including the 32bit .exe, regularly, so that whenever you, Kyle, update your special sqlite(32bit).exe version, it will not be up-to-date but for some weeks or months.
THUS:
Why not do it the other way round, here again: After UR's being able now to process generic signature sqlite DBs, why not also enable it to process them with the .db (or .db3) suffix?
The worst that could occur then, with a non-UR db: UR could crash (or even need re-install), and the (non-UR) db could become affected, too, BUT when we process a UR db with SQLite.exe or similar, we are deemed to know what we do, and when processing a non-UR db with UR, this should apply, too, i.e. non-"power-users" should be "protected" from such ab-use, here, too.
THUS: Why not do a REGISTRY entry with (default) 0 = no / yes = 1 for "Enable UR to open ".db" (or .db3", too, or only; I use ".db" currently, but we all could rename to ".db3", obviously), and THEN only, i.e. if the user manually changes that registry entry, UR will open those SQLite3-generically-suffixed UR databases?
Problem solved then, and we always could use the most recent sqlite.exe command line tool, without bothering you again - and for "regular" users, UR would continue to refuse to open non-".urd" DBs.
Btw, I really don't know what's their multiple problem(s) with their sqlite.exe versions (see the above-mentioned problems with the old version):
When I open a trial db with their latest sqlite.exe (which is deemed successful, with .open ..., and with or without .mode, .output), and then do
select "itemtitle" from "item" where "statusid" not null;
I invariably of "item" or "Item" and of quotes and double-quotes for the elements
(the correct SQLite syntax being identifiers in double-quotes, and strings/literals (values) in single-quotes),
I always get "Parse error: no such table: Item", whilst the same query in Navicat correctly lists the 311 results, and with äöü etc correctly displayed.
So this could be a WARNING that the intermediate use of ANY sqlite.exe upon a UR db could result in problems with the UR db in case.
It seems their sqlite.exe are NOT RELIABLE, unfortunately...
(By a quick switch between UR and sqlite.exe, in UR, it would be possible, for example, to "sort the immediate child items of the current (parent) item by some value of any other attribute", and then immediately, visually check the result, just for these siblings, thus avoiding, possibly unwanted, "global" sort results; such "minimalistic" proceeding is not realistic though if the user has to close the db in UR, open it in an SQLite front-end, close it in there, re-open it in UR, etc., etc. ...
The above sqlite(32bit).exe fault MIGHT be caused though by my using it in my 64bit W10 system, so that the use of their .dll then would be necessary now indeed and instead (and could possibly also used from the command-line).
|