[Spliff]

This morning, I tried with an ADMINISTRATOR command prompt:

c:\sqlite3.exe d:\ur\trial.urd
.mode line
.output d:\ur\trial.txt
select "itemtitle" from "item" where "itemtitle" like "a%";

The target file remains empty, be it an existant file, or a new file, to be written by Sqlite3.exe; ditto for
.mode csv
and (new or existant) files something.csv.

The same, with
.output stdout
displays the list of the respective item titles in the command window, in the form of
ItemTitle = Then the respective title
ItemTitle = and so on

The same, with
.output |clip
puts the same list (with not even 100 entries (i.e. the titles beginning with "A" or "a", so it's really not "big"), SOMETIMES, RARELY, into the clipboard, but most of the time, the clipboard remains empty (if I have emptied it before) or just contains the content from before; I leave the system (i7, 16GB RAM, of which more than 10 GB are free) alone many seconds, in order for sqlite3.exe to fill the clipboard, then only try to access the clipboard (by ^v into an editor).

In both success cases (always to stdout and rarely to clipboard), all the special chars äöü, etc., are rendered in the ancient ASCII way - can't say about file output since never successful.


This "special" version of SQLite3.exe not working as expected - even the clipboard output being totally unreliable, "working" perhaps in 1 case out of 10 -, why not UR leaving alone the generic SQLite signature if the user has changed it in a binary editor, once-and-for-all (!), to generic then:

Which would mean that the user could then close those UR files, just rename the suffix from .urd to .db, open the files within a RELIABLE SQLite frontend of their choice, rename them back from .db to .urd, and re-open them normally within UR, without having the binary change problem (not anymore back into UR but always) out of UR, for external opening;

with the non-expert UR user just opening their UR files within UR, whilst their .db or .db3 files would be refused by UR (as a persistent UR security measure), just as it is today?

(And as for internal SPECIAL SQLite3.exe version use from within SQL Razor, since this special SQLite3.exe version at the very least is to be considered unreliable in at least several respects, I suppose this special version will not behave any better from within SQL Razor... hopefully, the generic version will (?!), but with that one, SQL Razor doesn't present any advantages over Navicat, etc., with respect to UR files anymore...)

(As for the special chars, that problem might possibly be resolvable by changing the console code page - I haven't delved into this possible Windows 10 problem...)


EDIT:
To clarify: With UR leaving alone the generic SQLite signature, in case, there would be TWO security measures for the non-expert user, preventing changes outside of UR: the .urd suffix, AND the (persistent) UR signature; whilst for the expert user, ONCE they will have changed the UR signature, once-and-for-all, there will remain ONE security measure, the .urd suffix, which external SQLite frontends will reject.