I have an app with core data and icloud to allow the user to use the same database on several devices. The sync works most of the time perfect, but sometimes it doesn't, i.e. some transactions are simply skipped.
When I check the console, I get the error message:
__45-[PFUbiquityFilePresenter processPendingURLs]_block_invoke(439): CoreData: Ubiquity: Librarian returned a serious error for starting downloads Error Domain=BRCloudDocsErrorDomain Code=5 "The operation couldn’t be completed. (BRCloudDocsErrorDomain error 5 - No document at URL)"
Funny enough this message appears even when the sync works.
The code fits to Apple latest version of " iCloud Programming Guide for Core Data".
The storeURL is coded as follows:
NSURL *documentsDirectory = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];
NSURL *storeURL = [documentsDirectory URLByAppendingPathComponent:#"iCloudSample.sqlite"];
The code for the options:
storeOptions = #{NSPersistentStoreUbiquitousContentNameKey: #"iCloudSampleStore" ,
NSPersistentStoreUbiquitousContentURLKey: #"iCloudSampleURL"};
The code for the store:
NSPersistentStore *store = [_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:storeURL
options:storeOptions
error:&error];
The merge policy (MOC is on the main qeue)
_managedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
[_managedObjectContext setPersistentStoreCoordinator:coordinator];
_managedObjectContext.mergePolicy = [[NSMergePolicy alloc]
initWithMergeType:NSMergeByPropertyObjectTrumpMergePolicyType];
As I understand the docs, there is not really much more to do(?).
But I guess I'm missing something, does anyone has an idea what to check, change, try?
Anyone who had the same problem? Any ideas are appreciated!
I have the same problem and solved it by removing the persistentStore and adding it again while the app is running. It is always the same problem when doing several changes in the first device, the second device doesn't get all the changes. I use the following code when applicationDidBecomeActive to remove the persistent store first:
var storeCoordinator:NSPersistentStoreCoordinator = persistentStoreCoordinator!
var store:NSPersistentStore = storeCoordinator.persistentStores[0] as! NSPersistentStore
var storeURL:NSURL = store.URL!
storeCoordinator.removePersistentStore(store, error: nil)
NSFileManager.defaultManager().removeItemAtPath(storeURL.path!, error: nil)
Following this I proceed to add the persistentStore again. Then I received all the notifications as it was the first run after installation but with the full data synched. it always works but I don't know if it is the proper way to handle the problem.
I believe that all the changes made in the first device always reach the second device but for some weird reason they don't merge completely with the local core data. I have made some weird observations about the iCloud-CoreData issue in:
https://stackoverflow.com/questions/32084952/core-data-to-icloud-doesnt-sync-all-changes
I hope it helps.
I found that when my store URL had .s in the path
(e.g. ---/com.companyName.project/---)
let applicationSupportDirectory = applicationSupportDirectoryURL.URLByAppendingPathComponent("com.companyName.project")
let iCloudStoreFileName = "iCloud.sqlite"
lazy var iCloudStoreURL: NSURL = {
return self.applicationSupportDirectory.URLByAppendingPathComponent(self.iCloudStoreFileName)
}()
When I enabled logging, by going to Edit Scheme... in Xcode for my project and adding:
-com.apple.CoreData.SyntaxColoredLogging 1
the log file in the debug window showed the path it was searching was
---/com~companyName~project/---
Core data had changed the .s to ~s. I eliminated the entire com.companyName.project from the URL and synchronizing seems to work better. But with core data and iCloud you never know - there's soooo much magic going on behind the scenes.
Related
I've kinda implemented a today view extension with CoreData sharing in my app, I have multiple problems (like only one object showing when I have three) and a big one, "Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0xd0000000001c0004". Now, this only happens when I have the application open in the background, which leads me to believe that my app is leaving the store in a bad state, but that really shouldn't be happening. I'm using Persistent Stack, external 'library' to manage all of the CoreData (instead of AppDelegate) which is readable on https://gist.github.com/mluisbrown/7015953
CoreData Fetching from TodayView Extension:
-(void)viewDidLoad{
self.persistentStack = [[PersistentStack alloc] initWithStoreURL:self.storeURL modelURL:self.modelURL];
self.managedObjectContext = self.persistentStack.managedObjectContext;
}
- (NSURL*)storeURL
{
//NSURL* documentsDirectory = [[NSFileManager defaultManager] URLForDirectory:NSDocumentDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:YES error:NULL];
// return [documentsDirectory URLByAppendingPathComponent:#"WhatIOwe.sqlite"];
NSURL *directory = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:#"group.com.bittank.io"];
NSURL *storeURL = [directory URLByAppendingPathComponent:#"WhatIOwe.sqlite"];
return storeURL;
}
- (NSURL*)modelURL
{
return [[NSBundle mainBundle] URLForResource:#"WhatIOwe" withExtension:#"momd"];
}
- (NSFetchedResultsController *)fetchedResultsController {
self.persistentStack = [[PersistentStack alloc] initWithStoreURL:self.storeURL modelURL:self.modelURL];
self.managedObjectContext = self.persistentStack.managedObjectContext;
if (_fetchedResultsController != nil) {
return _fetchedResultsController;
}
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription
entityForName:#"OweInfo" inManagedObjectContext:managedObjectContext];
[fetchRequest setEntity:entity];
NSSortDescriptor *sort = [[NSSortDescriptor alloc]
initWithKey:#"details.date" ascending:NO];
[fetchRequest setSortDescriptors:[NSArray arrayWithObject:sort]];
[fetchRequest setFetchBatchSize:20];
NSFetchedResultsController *theFetchedResultsController =
[[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest
managedObjectContext:managedObjectContext sectionNameKeyPath:nil
cacheName:#"Root"];
self.fetchedResultsController = theFetchedResultsController;
_fetchedResultsController.delegate = self;
return _fetchedResultsController;
}
As suggested, I've tried a merge policy in my persistent stack:
[self.managedObjectContext.persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:self.storeURL
options:#{ NSPersistentStoreUbiquitousContentNameKey : #"WhatIOwe",
NSMigratePersistentStoresAutomaticallyOption : #YES,
NSInferMappingModelAutomaticallyOption : #YES,
NSMergeByPropertyObjectTrumpMergePolicy : #YES}
error:&error];
Another observation, on configuring my NSManagedObjectContext, passing:
[psc addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:self.storeURL options:nil error:&error]; allows the extension to read the store (but still throw the error I'm having), but passing
[psc addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:self.storeURL options:#{ NSPersistentStoreUbiquitousContentNameKey : #"iCloudStore",
NSMigratePersistentStoresAutomaticallyOption : #YES,
NSInferMappingModelAutomaticallyOption : #YES,
} error:&error]; will result in the extension not reading any data whatsoever.
Side-note: psc is passed as
__weak NSPersistentStoreCoordinator *psc = self.managedObjectContext.persistentStoreCoordinator;
self.persistentStoreCoordinator = self.managedObjectContext.persistentStoreCoordinator;
What is happening here is that you have two different processes accessing the same Core Data store, each with it's own NSPersistentStoreCoordinator.
One process has modified the store - most likely a delete. The other process has no way of knowing that this delete occurred, and already had an object in memory that pointed to the now deleted data. When that process tries to access that object it must go to the store to get the data ("firing a fault"), which no longer exists.
Core Data is not designed for this kind of use, and the capabilities of extensions are very different than applications. If your extension is able to write to the same data that the application can you may reconsider your approach and make the extension only able to read the data, and never hold the data in memory for long. This will at least mitigate the most common ways to run into these problems.
Replying to above answer and the question:
"Core Data is not designed for this kind of use"
It totally is. The assessment is correct: Something has likely been deleted in the actual app, and the extension is not aware. Fortunately CoreData provides a way to deal with this case. Check out the stalenessInterval property of NSManagedObjectContext. It defines how long your in memory cache is good for. If you're having problems because your in memory cache goes out of date from disk store change because an external process is changing them, simply set the staleness interval to 0 in your extension, and that will tell CoreData to always fetch new values from the store and ignore the in memory cache.
If you're holding a reference to an object in memory, and that object is deleted in the store, you still may have issues, so always check to make sure the object you are accessing has not been deleted.
There are a few other options if you want to get more detail. You could send notifications from your main app to your extension when things get saved to provide a manual trigger for reloading your data. You could also send specific object ids across that have been deleted or modified and use the refreshObject... method to manually refresh. Or check out mergeChangesFromContextDidSaveNotification:. You might be able to manually serialize the dictionary that expects and then send it across.
You could also have the parent app handle all database accesses and send results back via notifications. This might be unnecessary.
All of this requires a bit of work, but you're going to run into that with any
database system where the database is being accessed across multiple processes, and there is caching.
There are multiple issues with your code which are likely leading to a confused Core Data state. I can't be certain that they're causing your problem, but at the moment things are messed up badly enough that trying to debug this specific error is getting ahead of things. These problems include:
Confusion about how you're sharing data between your app and the extension.
You can do this using iCloud, or you can do it by using an app group to share the persistent store directly. You appear to be attempting both, which is not just unnecessary but also likely to cause problems keeping the extension up to date.
If you use iCloud to share data, you do not need the app group, because both the app and the extension will get their data from iCloud. You don't share a local persistent store in this case, instead the data is transferred via iCloud.
If you use an app group to share the persistent store file, you have no need of iCloud. The app and the extension both access the same file, which is located in the group container. Each can both read and write it.
Conflicting iCloud setups. You're using different values for NSPersistentStoreUbiquitousContentNameKey in different places. Even assuming that iCloud is working properly, this is going to prevent you from sharing data. If the app and extension are going to share via iCloud, they need to access the same cloud store, but you seem to be directing them to use separate cloud data stores.
You're not actually using the merge policy you're aiming for. You're passing NSMergeByPropertyObjectTrumpMergePolicy as one of the options when adding the persistent store file, but this isn't actually a valid option there. I would have expected at least a console message about this, but if there isn't one then it means Core Data is just silently ignoring that key. You set a merge policy by setting the value of the mergePolicy attribute on your managed object context. With no merge policy, you're falling back on the default NSErrorMergePolicy.
Unusual, suspicious code when adding the persistent store. In most cases with Core Data you'd add the persistent store and then later on create one or more managed object contexts. You appear to be creating the context first and only later adding a persistent store. That's not necessarily wrong but it's very unusual. If I were working on this code, it'd be a red flag to look over the life cycle of the Core Data stack very carefully. Especially if, as your code comments indicate, you're not getting any data at all in some cases.
Again I'm not sure if the above is directly causing this specific error, but they're going to be causing problems of various types and it wouldn't be surprising if the resulting confused state leads to this error.
I'm trying to create a NSSQLiteStoreType with the readonly option (NSReadOnlyPersistentStoreOption). This fails if the sqlite file doesn't exist (see code below). If it does exist, the store is added without any errors.
The error I get is Cocoa Error 260:
NSFileReadNoSuchFileError = 260, // Read error (no such file)
So it looks like CoreData tries to read a file that doesn't exist, instead of creating a new one...
It seems that when adding NSReadOnlyPersistentStoreOption you can only open a previously existing store, but not create one. This doesn't make sense to me.
Is there any way to create a brand new readonly store in Core Data?
If not, is there some workaround?
// DB URL
NSFileManager *fm = [NSFileManager defaultManager];
NSURL *dbURL = [[fm URLsForDirectory:NSDocumentDirectory
inDomains:NSUserDomainMask] lastObject];
dbURL = [dbURL URLByAppendingPathComponent:#"store.sqlite"];
// Object Model
NSURL *modelURL = [[NSBundle mainBundle] URLForResource:#"Model" withExtension:#"momd"];
NSAssert([fm fileExistsAtPath:[modelURL path]], #"File not found");
NSManagedObjectModel *model = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];
// Store Coordinator
NSPersistentStoreCoordinator *coord = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:model];
// Add a readonly SQLite store
NSError *err = nil;
NSPersistentStore *store = [coord addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil URL:dbURL
options:#{NSReadOnlyPersistentStoreOption : #YES}
error:&err];
if (store == nil) {
// I get a Cocoa Error 260.
NSLog(#"Error: %#", err);
}
Creating a new, empty, read-only store makes no sense, and the results you're seeing are exactly what would be expected. By specifying read-only you are specifically indicating that no file should be written, so as a result.... no file is written.
It's hard to tell what you're trying to accomplish. If the file were created, you would not be able to use it, since it would contain no data and since the read-only flag would prevent you from adding any data. An empty file would be exactly as useful.
But no, there is no way to tell Core Data to create a new persistent store file but have that file be read only, mainly because such an operation would be nonsensical and useless.
If you have some reason to want a persistent store file which is both empty and unwritable (and if you do, please share), you would need to
Add the persistent store without the read-only flag
Call removePersistentStore:error: to remove that persistent store
Add the persistent store again, with the read-only flag.
You will now have a persistent store which contains no data, and which you are prevented from adding data to.
A simpler alternative that is just as effective is to not create the file in the first place. An empty read-only persistent store serves literally no purpose at all, so the easy approach is to just not bother creating it.
The Problem:
I've got some pretty simple code (below) that causes an exception during 'migratePersistentStore' with the error message
Exception:*** -[__NSArrayM replaceObjectAtIndex:withObject:]: object cannot be nil
The Code:
NSPersistentStore * oldStore = [_persistentStoreCoordinator persistentStores][0];
if (oldStore) {
#try {
[_persistentStoreCoordinator migratePersistentStore:oldStore
toURL:[self storeURL]
options: #{ NSPersistentStoreRemoveUbiquitousMetadataOption : #YES }
withType:NSSQLiteStoreType error:&error];
}
#catch(NSException* ex) {
NSLog(#"Exception:%#", ex.description);
}
}
Further Info:
It appears that if no data is present, the exception does not occur. Instead the same function sets an error, with userInfo "Can't add the same store twice".
I'm currently making a small simple project to try and replicate the problem, I'll post a link here once it's done.
Apparently, Core Data doesn't like migration when your iCloud URL and local URL are the same. I thought this shouldn't matter because really, iCloud data is stored in its own directory. BUT, it seems during migration, using the same name causes problems.
Easy fix - just do something like this:
- (NSURL *)storeURL {
NSURL * documentsDirectory = [[NSFileManager defaultManager] URLForDirectory:NSDocumentDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:YES error:NULL];
if (iCloudEnabled]) {
return [documentsDirectory URLByAppendingPathComponent:#"iCloudEventData.sqlite"];
} else {
return [documentsDirectory URLByAppendingPathComponent:#"EventData.sqlite"];
}
}
There really isn't enough information here to tell you the exact cause. As you may have guessed, CoreData is running into a problem where it is replacing an object in an array with a nil object. This can happen if your mapping models do not match correctly.
To troubleshoot your problem, you should do two things:
Remove that try/catch an instead set a symbolic breakpoint for all exceptions. This will cause the debugger to stop when it hits this exception, and you can see the stack trace and everything else that is going on in your application. Note that if CoreData runs into merge conflicts these are handled inside CoreData as exceptions and the debugger will stop on those as well. In that case, just continue until your array exception.
Set your application's launch arguments to turn on migration logging to see how it's getting to this point. In Xcode, edit your application scheme's Run task to pass -com.apple.CoreData.MigrationDebug. Note that the dash preceding the argument is important. CoreData will log what happens during your migration, which should help pinpoint the problem.
A random guess: do you have any NSManagedObject subclasses declared in your model that you've forgotten to include an implementation for in your build? In that case it's imaginable that the migration code might attempt to create an instance of the custom subclass, fail to do so, then fail to check that it succeeded before throwing the result into an array.
Run without a migration and perform something like this to check:
for(NSEntityDescription *entityDescription in model.entities)
{
NSString *className = [entityDescription managedObjectClassName];
Class class = NSClassFromString(className);
if(className && !class)
NSLog(#"An implementation of class %# is missing from the build",
className);
}
I'm trying to remove Core Data from iCloud using [NSPersistentStoreCoordinator removeUbiquitousContentAndPersistentStoreAtURL:options:error:].
But I get strange output:
__93+[NSPersistentStoreCoordinator removeUbiquitousContentAndPersistentStoreAtURL:options:error:]_block_invoke(1982):
CoreData: Ubiquity: Unable to move content directory to new location:
file:///private/var/mobile/Library/Mobile%20Documents/<UBIQUITY_ID>/
New: file:///private/var/mobile/Library/Mobile%20Documents/OldUbiquitousContent-mobile~C9439AD0-1E87-4977-9C68-0674F5E2E93B
Error Domain=NSCocoaErrorDomain Code=513 "The operation couldn’t be completed.
(Cocoa error 513.)" UserInfo=0x181ab790 {NSSourceFilePathErrorKey=/private/var/mobile/Library/Mobile Documents/<UBIQUITY_ID>,
NSUserStringVariant=(
Move
), NSFilePath=/private/var/mobile/Library/Mobile Documents/<UBIQUITY_ID>,
NSDestinationFilePath=/private/var/mobile/Library/Mobile Documents/OldUbiquitousContent-mobile~C9439AD0-1E87-4977-9C68-0674F5E2E93B,
NSUnderlyingError=0x181aab50 "The operation couldn’t be completed. Operation not permitted"}
What does it mean?
How to avoid it? I'm working on iCloud disable/enable feature. Details HERE
UPDATE:
NSDictionary *iCloudOptions =
[NSDictionary dictionaryWithObjectsAndKeys:kICloudContentNameKey, NSPersistentStoreUbiquitousContentNameKey,
iCloudURL, NSPersistentStoreUbiquitousContentURLKey, nil];
// self.lastICloudStoreURL stores NSPersistentStore.URL after stack setup
BOOL result = [NSPersistentStoreCoordinator removeUbiquitousContentAndPersistentStoreAtURL:self.lastICloudStoreURL
options:iCloudOptions
error:&error];
Normally (before iOS7), you take the ubiquitousContentURL value from [fileManager URLForUbiquityContainerIdentifier:nil];
and pass it as an option called NSPersistentStore UbiquitousContentURLKey, and this is how iCloud know where to keep all of your data in the iCloud account.
In iOS 7 and Mac OS X we don't need to pass a value for that at all, and Apple call URLForUbiquitous ContainerIdentifier automatically under the hood for you.
So the solution looks like this:
NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:kICloudContentNameKey, NSPersistentStoreUbiquitousContentNameKey, nil];
NSURL *storeURL = [NSPersistentStore MR_urlForStoreName:[MagicalRecord defaultStoreName]];
BOOL result = [NSPersistentStoreCoordinator removeUbiquitousContentAndPersistentStoreAtURL:storeURL options:options error:&error];
I suggest you to check WWDC 2013 session 207 to get this things clearly.
NSCocoaErrorDomain error 513 is defined in FoundationErrors.h as NSFileWriteNoPermissionError. You don't have the required permissions to write to the location.
This can happen if a managed object context is still using objects that are backed by this store. The context is actively using the file that is being moved, which results in a NSFileCoordinator conflict. Two things are trying to access the file with write permission at the same time.
The removeUbiquitousContentAndPersistentStoreAtURL:options:error: method deletes all of the user's local and cloud data—this is probably not what you want. Instead, migrate your store to a new location on disk and use the NSPersistentStoreRemoveUbiquitousMetadataOption option with the migratePersistentStore:toURL:options:withType:error: method.
See Disabling iCloud Persistence at Removing an iCloud-enabled Persistent Store in the iCloud Programming Guide for Core Data.
I am using a UIManagedDocument in iOS 5.0, running the app on the simulator, using XCode 4.2 under OSX 10.6. The code in question looks as follows:
if (![[NSFileManager defaultManager] fileExistsAtPath:[self.photoDatabase.fileURL path]]) {
// does not exist on disk, so create it
[self.photoDatabase saveToURL:self.photoDatabase.fileURL forSaveOperation:UIDocumentSaveForCreating completionHandler:^(BOOL success) {
[self setupFetchedResultsController];
[self fetchFlickrDataIntoDocument:self.photoDatabase];
}];
} else if (self.photoDatabase.documentState == UIDocumentStateClosed) {
// exists on disk, but we need to open it
// *** the following line generates the message ***
[self.photoDatabase openWithCompletionHandler:^(BOOL success) {
//[self setupFetchedResultsController];
}];
} else if (self.photoDatabase.documentState == UIDocumentStateNormal) {
// already open and ready to use
[self setupFetchedResultsController];
}
Running the marked line creates the following message on the log:
2012-01-10 22:33:17.109 Photomania[5149:4803] NSFileCoordinator: A surprising server error was signaled. Details: Connection invalid
After the message is sent, the UIManagedDocument may or may not work—I have not found the circumstances that determine this, yet.
I am pretty sure that the code is correct, as it's actually one of the code examples in the CS193p course from Stanford. The whole example can be downloaded at their website under
http://www.stanford.edu/class/cs193p/cgi-bin/drupal/
Direct link to the code:
http://www.stanford.edu/class/cs193p/cgi-bin/drupal/system/files/sample_code/Photomania_0.zip
Additionally, the code runs fine on the device itself, without generating the "surprising" message, and running all the code that comes afterwards just fine.
I have not found anything on Google, neither on the Apple Developer pages. Restarting the simulator, or XCode, or reinstalling both of them does not change the behaviour.
Any ideas?
I can only say that I've had this happen to me several times. For me, I'm lazy after I update my dataModel and so far, each time I've gotten this error it was because I had changed my data model. Usually, all I need to do is delete my app from the simulator and re-run it and it has always turned out fine. Hope this helps someone out there.
I think I have found the answer. It looks like the automatic saving for UIManagedDocument kicks in only after a few seconds on the simulator.
So I minimized the app on the simulator, by pressing the home button, and then clicked on the icon to maximize it again. And then I terminated the app in simulator.
When I re-launched the app, the database was loaded. The error still shows up - it comes because the document is in "closed" state (that's normal - that's why CS193P asked to call openWithCompletionHandler), but my data across launches is preserved. Unfortunately I have to do the minimize/maximize routine before terminating the app, or the changes are discarded at next launch.
Can you verify that this is the behavior you are able to recreate? At least for testing purposes this should be a good enough trick to use.
Try upgrading to the latest iOS 5.1. I don't think UIManagedDocument with iCloud works reliably in 5.0. This has been my experience.
I love the Stanford iTunes class. However, I think the sample code for using UIManagedDocument is wrong. In fact, he notes in the demo that he is only doing it that way because he wants to just fetch the information right then. In the code comments, he says not to use the auto-save features because the data will not be saved if the app quits. however, UIManagedDocument will save anything that's necessary before quitting. It has all pertinent handlers for quitting/multitasking/etc to make sure the data is saved.
So, if you are using that code as your example, here's a version that should work, and does not use saveToURL (I don't have a flickr account, so I didn't actually run it - but this is how the class is designed to work). Please let me know if it does not work.
- (void)fetchFlickrDataIntoDocument:(UIManagedDocument *)document
{
NSManagedObjectContext *ctx = [[NSManagedObjectContext alloc] initWithConcurrencyType: NSPrivateQueueConcurrencyType];
ctx.parentContext = document.managedObjectContext;
[ctx performBlock:^{
NSArray *photos = [FlickrFetcher recentGeoreferencedPhotos];
for (NSDictionary *flickrInfo in photos) {
[Photo photoWithFlickrInfo:flickrInfo inManagedObjectContext:ctx];
// Push changes to document MOC
[ctx save:0]; // propagates changes to parent MOC
// and tell the document it is dirty and needs to be saved
// It will be saved when the document decides its time to save
// but it *will* be saved.
[document updateChangeCount:UIDocumentChangeDone]
}
}];
}
Still had errors when the last path component for document file url was #"Database". Adding an extension #"Database.db" seems to have fixed it, everything running fine now. Have also upgraded to Lion though.
NSURL *url = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];
url = [url URLByAppendingPathComponent:#"Database.db"];