@samRowlands
There is no way to make a folder item from a memory block
An in memory db is your only resort here - but you have to “load it” with the data at startup/creation every time
That is exactly what I’m going to look into tomorrow. I know I can create a RAM backed volume (which is slow and banned from the App Sandbox), but I’m wondering if there’s a way I can trick the macOS (via it’s UNIX underpinnings) to think that the memory block is in fact a file on the disk (without it being on the disk) so I can open it and read the database…
If you need an SQLite database in a “memoryblock”. why not just create an in-Memory one, why go thru all the hoops to convert to a non-standard format?
I use in-Mem with the SQLIte Backup command to transfer from disk, work in-mem, and then put it back
Is there some reason you can’t just use the read-only version directly from disk in the resources of your app ?
Xojo fixed an issue that makes this work in newer versions
The data comes from a zip file, I’d really like to avoid extracting it to disk, then loading it, when I get the OS to extract the SQLdata direct into memory when the customer wants to read that file.
What I’m suggesting is DONT zip the darned thing and shove it in the built app and just read it from disk as it sits there
Is there a reason that wont work ?
I really doubt you’ll convince Xojo to handle anything in memory as a normal Folderitem like it expects which is what you need to make your plan work
Sorry if I wasn’t clear, it’s archived user data.
I’m not expecting Xojo to make changes for me. I was hoping was to find a way to skip extracting and writing to disk, to then read it into memory again, turns out I couldn’t sleep, so Imma explore what I can about creating a memory backed file, I mean if I can create a memory backed volume, maybe I can with a file…
Now I understand your answer better, can I use a blob of memory as a file, the answer is yes 
Will it work with Xojo, here’s where you mentioned the folderitem…
Looks like fcntl might help to get a path from the fileDescriptor, then the question will be, can Xojo open that path?
Lets see if I understand correctly
Use has some data - not IN the app bundle itself
This data is a sqlite database
This data is in a zip file
You want to read the zipped up file AS IF its a regular file - without having to unzip it first
Basically get a “folder item” that reads the zip file AS IF its a normal disk based file
Is that correct ?
Seems a plugin could make it possible to READ the zip file AS IF its a normal file
ie/a Folderitem subclass that is a zipfilefolderitem
I doubt this will work
Again it might require_ a plugin that can do this
Yearhup. Through several API I can access the contents of the Zip file, and decompress elements into memory (App Wrapper does this for reading the plist, when you Notarize a Zip archive not created with App Wrapper).
There’s Xojo plugin API that would help with this… Interesting…
I know an Icelander that might be able to offer a better opinion on such things 
I’ve asked
1 Like
How is this banned? (and why is it slow?) Is the RAM volume created outside your app’s memory space? If that’s the case, can you find a library (or source code to build your own) to create a RAM volume directly from within your app?
There’s also SQLite’s VFS - maybe there’s some way to leverage it, maybe with a plugin that wraps the SQLite library.