When you run the command sqldiff a.db b.db, it creates a.db and b.db as zero-byte files if they aren't present.

That is now fixed for the a.db case, but fixing the b.db case is significantly trickier, so that quirk will be retained for the time being.

Explanation: sqldiff uses sqlite3_open_v2()¹ for a.db then ATTACHes b.db, and ATTACH behaves like sqlite3_open(), creating the db if it doesn't already exist. The workaround for that would be to transform b.db into file:b.db?mode=ro, but sqldiff cannot blindly do so because the user may have provided a URI-style name with their own arguments already, or may have had some weird (yet potentially valid) reason to use a non-filename like "" or ":memory:".

Alternative solutions for the b.db case will be thoughtfully considered provided they don't require adding lots of complexity to cover this rarely-triggered corner case.

---

1. ^{^} it used sqlite3_open() before this change.

Alternative solutions for the b.db case will be thoughtfully considered...

Dan came up with an easy way to do that, so that's now also fixed.

Thanks for the quick response! Clever fix indeed. Also noticed a different behavior in sqldiff on Windows and Linux.

• Linux: sqldiff file:a.db?mode=ro file:b.db?mode=ro works as expected;
• Win: sqldiff file:a.db?mode=ro file:b.db?mode=ro creates a file called 'file';

Is SQLITE_USE_URI not defined in Windows binaries?

Win: sqldiff file:...

It sounds like your Windows copy might not have been compiled with URI-style file names.

Yeah, I'm using binaries from sqlite.org. Not sure if this is the expected behavior, just noticed it.

The project-distributed binaries should be using the same set of options that determine functionality of the CLI, (excluding line-editing.) The behavior you have noticed is almost certainly an oversight rather than an intended one. Thanks for sharing your observation of this subtlety.