Have you thought about avoiding the problem altogether?
Instead of marking the objects and then needed to save them, write out a file
somewhere that identifies those objects, outside of core data.
Then, when your app is starting, check for the presence of the file before
anything else happens,
On Jun 8, 2010, at 1:24 PM, David Brown wrote:
> Have you thought about avoiding the problem altogether?
>
> Instead of marking the objects and then needed to save them, write out a file
> somewhere that identifies those objects, outside of core data.
>
> Then, when your app is starting, check
There's no error or log at all, unless I set the merge policy to the default,
in which case the error parameter contains what I expect it to contain: a
conflict list with the right objects and properties that I expect to be in
conflict. I understand the error coming back from the save, but not t
Is there anything in the log?
What does save's error parameter return?
atze
Am 08.06.2010 um 17:53 schrieb Hank Heijink (Mailinglists):
> Dear all,
>
> I've run into the following problem, and I'm a bit stuck - I wonder if you
> can shed some light on this. I have an iPhone app that u
Dear all,
I've run into the following problem, and I'm a bit stuck - I wonder if you can
shed some light on this. I have an iPhone app that uses Core Data, and the
problem occurs when the app terminates. I have an NSOperationQueue with
potentially several NSOperations that are cancelled in the
