I think your expectation, that the sqlite3_db_filename() return for an in-memory database reflect its not-file-backed nature, is reasonable and supported by the 1st paragraph of the <u>[sqlite3_db_filename() doc](https://sqlite.org/c3ref/db_filename.html)</u>. Said doc also seems to promise that the return will be an absolute pathname if not null or the empty string (and the stock VFS is used.) I can see that the code clearly sets the filename kept internally to "x", which is not an absolute pathname on most platforms. For both of these reasons, I consider your post(s) to be a bug report and will create a ticket for it. Until this behavior is altered in the code, I suggest that you treat "x" as if it had been what you expected. That name is highly unlikely to collide with anything that could be correctly returned by sqlite3_db_filename(). Alternatively, assuming you would be ultimately persisting the DB known as "x" (rather than just fooling around with it), you could use the <u>[VACUUM INTO filename](https://sqlite.org/lang_vacuum.html)</u> statement to achieve that, and even then abandon "x" and open the newly saved DB which would then have the filename you gave it.