An exception was caught from the delegate of NSFetchedResultsController during a call to -controllerDidChangeContent:. Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (8) must be equal to the number of rows contained in that section before the update (8), plus or minus the number of rows inserted or deleted from that section (0 inserted, 1 deleted)

The Apple docs mention that NSFetchedResultsController is designed to respond to changes at the model level. E.g. you change the model, save it and then the view automatically updates.

However when you re-order something using the tableview methods the view is already correct (because you’ve dragged and dropped the cell there) and so when the delegate detects your index changes, it walks all over your view believing the cells to be in their original position. The trick is to ‘disable’ the UI updates with a boolean in your delegate methods. Set the boolean just before your re-indexing and unset it afterwards.

For an example, see this stack overflow link http://stackoverflow.com/questions/1077568/how-to-implement-re-ordering-of-coredata-records

For the Apple docs mention of user-driven updates, see this link http://developer.apple.com/iphone/library/documentation/CoreData/Reference/NSFetchedResultsControllerDelegate_Protocol/Reference/Reference.html#//apple_ref/doc/uid/TP40008228-CH1-SW14

Hope this helps, Richard

Thanks -Micah

Thanks, Clint. I’ll take a closer look when I get a chance. I can see what you’re saying. It seems your solution is fine, but there may be a better way. Will see what I can find.

Thanks again.

-Matt

This seems to be caused by -tableView:moveRowAtIndexPath:toIndexPath: assuming that the array of entities returned by [fetchedResultsController fetchedObjects] is always sorted correctly–it isn’t.

Re-executing the fetch before (or after) your move logic does resolve the issue (here’s a full example: http://pastie.org/1054504 but is it the best fix? Hopefully more experienced Core Data folk will chime in…

Anyways, thanks to you and Marcus for providing such an amazing resource for everyone else–keep up the good work!

good post. My preference is to lazily create the fetch request and the sort descriptors. Then when the list needs to be resorted, I will set the fetch request, sort descriptor, and then the fetchedResultsController to nil. The getter for the sortDescriptor then is setup depending on which ever property needs to be sorted. Then when the tableView or specific rows are reloaded the fetchedResultsController is reinitialized and the different sortDescriptor can be used.