(Quoting code fragments as context for response fragments:)
> ```
database.cpp file:(in constructor)
m_Main_Db_File = "file:\\Users\\David\\test.db";
```
It appears that you intend to use a URI database specification. This one is in good order. I prefer (single) forward slashes, as Windows has accepted them since the 16-bit codebase became history.
> ```
// Make the sqlite3 temp directory.
LPCWSTR zPath = ApplicationData::Current().TemporaryFolder().Path().data();
char zPathBuf[MAX_PATH + 1];
memset(zPathBuf, 0, sizeof(zPathBuf));
WideCharToMultiByte(CP_UTF8, 0, zPath, -1, zPathBuf, sizeof(zPathBuf), NULL, NULL);
sqlite3_temp_directory = sqlite3_mprintf("%s", zPathBuf);
```
If your DB file will be in a writable directory, there is no need (evident here to me) for setting a different temp directory. It's a complication at best.
> ```
int result = sqlite3_open(m_Main_Db_File, &ptrMain_Db);
```
You need to use [sqlite3_open_v2()](https://sqlite.org/c3ref/open.html) with a SQLITE_OPEN_URI flag.
> I moved the database file to my user folder which I should have full permission rights to. Now I get a hex E from result.
Getting a **different** result should be considered progress. That return is also known as [SQLITE_CANTOPEN](https://sqlite.org/rescode.html#cantopen). As the linked doc indicates, the open failure could be either the main DB file or one of the potential auxiliary files. Eliminating the sqlite3_temp_directory set would help distinguish cases here.
> Without the file:, single back slashes which Windows did not like, and forward slashes.
It is not Windows which disliked single backslashes. (It never saw them.) You should study what C/C++ string literal escaping conventions mean and do. A double-backslash becomes a single backslash in the compiled literal.
> This is different from when the database was in my project folder.
Yes, and with a little more information that will be a potent clue, I think.
At this point, I suspect your problem is that Windows, when given file:\\Users\\David\\test.db as a pathname, refuses to create a file object under that name. Telling SQLite to treat that text as a URI will keep the "file:" part from being passed to the OS file open API.
> In VS I have installed SQLite/SQL Server Compact Toolbox. From this too I can always access and modify any SQLite database. This is how I have been making changes to the database so far. Is this tool causing my problems?
I was unaware that the tool could deal with SQLite databases. (I'm skeptical that it can.) But if you are not keeping a SQLite database open in that tool, I highly doubt it will lead to the problem(s) you see now.