Have you tried jdbc:sqlite::memory: as documented on that very page you quoted (https://www.sqlitetutorial.net/sqlite-java/sqlite-jdbc-driver/)?

Thanks for the reply!

jdbc:sqlite::memory:

is to connect to a brand new database memory. There is an example here to restore the database file to the database in memory:

restore from C:\\__tmp\\thing.sqlite

Unfortunately in my setup, there is no disk. So I can't use this either.

I think you will need to explain what a "file" is on your system before anybody can help figure out how to use the SQLite API for your problem. SQLite has been used on limited-resource platforms, but we need to know how limited yours is before suggesting a solution here.

The file is the SQLite database file. I have it in memory, not on disk.

There seems to be some confusion.

If you wanted to work with strings. You can work with strings inside files on disk. Or you can work with strings in memory. There is no such thing as working with strings in files in memory.

SQLite can keep data in a file on disk. Disks are organised with folders and files. In order to know which file to open, you specify the filename.

SQLite can also keep data in memory. Memory is not organised with folders and files. It's just one big thing. If you want to keep data in memory you tell SQLite to connect to memory. There's no way to specify a filename. That's why Keith specified a connection string which included no filename.

If you make have SQLite data in memory, and remove the last connection to that data, the memory is released and the data disappears.

Thanks for the reply! It sounds like my use case is not supported.

Thanks again!

If "the file" is a "file" in the usual sense of the term's usage among programmer's and computer users, then it will have multiple attributes which make it usable from an instance of the SQLite library running in a process: (1) It will have some kind of name by which other processes can open, read, write, and ultimately close the file; (2) the "file" behaves as a sequence of bytes which is the same across accessing processes, in some timeframe; and (3) a degree of persistence exists for that byte sequence. I cannot tell from what you have (cryptically) written so far whether your "file" is like that. Nor can I tell whether your "diskless" system has any persistent storage scheme exposed through an OS API resembling what most operating systems have to facilitate use of (real) files.

If your platform has fopen(), open(), read(), write(), fread(), fwrite(), close() and fclose(), then you need to use the SQLite API and one of its default file access VFS layers in order to keep your DB in a file.

Your in-memory DB is not in a file. It is in something that is made to resemble a file in limited respects by a VFS. On some platforms, it is possible to share an in-memory DB with other processes. Maybe that is true for your mystery platform. If not, you may need to implement a VFS to accomplish your ends.

Due to lack of information about what you are trying to accomplish and from what starting point, I have no idea how you need to proceed. Neither will anybody else until you are more forthcoming about those facts.

Appreciate the response! No, my platform doesn't have any of the file operations.

I think I got the answer. Thanks!