Wish I can help further. I know my apps are all sandboxed on the Mac App Store and they all create the temp file without any problems. It is weird that it lets you create the real db, but doesn’t let you create the temp db.
[quote=32921:@Thom McGrath]Looks like NSFileCoordinator was designed for this sort of thing. Sam, any experience with this class?
https://developer.apple.com/library/mac/documentation/Foundation/Reference/NSFileCoordinator_class/Reference/Reference.html#//apple_ref/doc/uid/TP40010585[/quote]
No, I haven’t - Just had a quick look at the documentation… Interesting…[quote=33233:@Nona Suomy]Wish I can help further. I know my apps are all sandboxed on the Mac App Store and they all create the temp file without any problems. It is weird that it lets you create the real db, but doesn’t let you create the temp db.[/quote]
When you use the SaveAsDialog, you’re allocated access rights for the file returned by the dialog. I suspect that the databases temporary file is a different name, and therefore your application doesn’t have any access rights for it.
Ok, now I’m almost sure that THIS is the source of the problem : creation of temporary tables.
I visited many forums on SQLity and sandboxing and it seems to be a recurrent issue… I tried one solution but with no success, I put this code line just above my function of database creation :
#PRAGMA journal MEMORYI was thinking to change to path for the temporary tables creation file, but I didn’t find any way to do it in XOJO 
I have the same issue as you Sbastien.
I’m currently looking into using a bundle as the file that will contain the actual SQLite database as Thom suggested above :)[quote=32875:@ThomMcGrath]
2) Switch your document to a bundle and store your database inside the bundle. When the user selects a file, you’ll actually have permission to the entire folder and you can write whatever you need anywhere inside the bundle.
[/quote]
Don’t have my Developer certificate yet so I can’t test it on a Sandboxed app until I do sometime next week 
How do you make a file/folder a bundle?
This is something that I have tried to find for a while. Is there a declare or something within MBS?
I’m looking into that. I think you just create a folder and assign a FileType to it.
Then you need NSTypeIsPackage=1 in your Info.plist file for your FileType. I’m using App Wrapper Mini for that.
This results in a file that you can right click on and get “Show package content”.
Then again I’m just experimenting. If this is way out wrong, let me know 
[quote=33302:@Albin Kiland]I’m looking into that. I think you just create a folder and assign a FileType to it.
Then you need NSTypeIsPackage=1 in your Info.plist file for your FileType. I’m using App Wrapper Mini for that.
This results in a file that you can right click on and get “Show package content”.
Then again I’m just experimenting. If this is way out wrong, let me know ;)[/quote]
hmm, after some testing this does still not seem to work correctly.
File shows as a folder…
EDIT:
Created a new thread for this so I don’t steal this one
https://forum.xojo.com/4823-create-a-bundle-from-your-app
The more I look at this Stack Overflow question, the more confident I am that NSFilePresenter and NSFileCoordinator are exactly what we need to figure out. I’m trying to see if I can 1) solve this guy’s problem and 2) port this into Xojo. But I’ll be honest, I’m not great at porting this much code. Give me a few methods to call, no problem. Creating a class that conforms to a protocol? Beyond my skills (at the time being). We may have to ask for help from the macoslib maintainers.
For my product, moving or bundling the sqlite file just isn’t an option. So I have to get this figured out.
Oh, and MBS already has these classes supported. Personally, I’d like to avoid the plugin route though. Still, I’m going to try that first to at least get a grasp on the concept and ensure it works.
And my last reply in a row (I promise):
NSFilePresenter is not the solution. At least not a good one. The coordinator is meant to be kept around only as long as a file operation is in progress. So, for example, you would create the coordinator, read the document(s), destroy the coordinator. This won’t work for a database, which will have operations going very frequently.
Now, it doesn’t say you cannot retain the coordinator for a long period of time, only that you shouldn’t. There is also the very real possibility that these classes are intended only for use with iCloud, which means the whole concept is dead in the water.
AH!!! Good news and bad news folks. From https://developer.apple.com/library/mac/documentation/security/conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html
That explains why I don’t see the problem myself. This guide does say NSFilePresenter/NSFileCoordinator will work for our scenario, but is only necessary on 10.8.1 and lower.
If I understand correctly, that says that with my version 10.8.4 I shouldn’t have this issue?
That’s exactly what it means. Obviously, something isn’t quite right for you. I’m still researching and experimenting.