• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data: I/O Error No Such Column
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data: I/O Error No Such Column


  • Subject: Re: Core Data: I/O Error No Such Column
  • From: Nick Shore <email@hidden>
  • Date: Sun, 24 Jul 2011 19:12:58 +1200

Well, great success - I think I've finally figured out what's wrong.

I have an entity, MyEntity. I have two other entities, Foo and Bar, that both have many to many relationships with MyEntity.  MyEntity has relationshipFoo and relationshipBar. Both Foo and Bar have a relationship called relationshipMyEntity. This causes Core Data to append a number to the end of the relationship, 1 (as in my error below) and 2. It looks like between 10.6 and 10.7, how these numbers get assigned is swapped. So Core Data is looking for Z_3RELATIONSHIPMYENTITY1 in Foo, but 10.6 has built that as Z_3RELATIONSHIPMYENTITY2, and vice versa for Bar.

If I rename my relationships to be relationshipMyEntityA and relationshipMyEntityB and rebuild on Lion, then this problem goes away - because they no longer have clashing names which are getting their index appended in a different order. "Simple" as that, problem solved.

Obscure!  Pretty sure I haven't read in the docs anywhere that you should have unique relationship names between entities, so I hope this helps if anyone runs in to the issue.

Cheers,
-nick


On 23/07/2011, at 11:49 AM, Nick Shore wrote:

> I'm getting the following error in my application:
>
> CoreData: error: (1) I/O error for database at /Users/nick/<library path>/blah.sqlite.  SQLite error code:1, 'no such column: t1.Z_3RELATIONSHIP<ENTITY>1
>
> This error only occurs if I build the project in Xcode 4.1 on Lion. If I build the same project on Snow Leopard in Xcode 4.0.2, then it runs as expected. If I launch the code built on 10.6/4.0.2 then it also runs as expected on 10.7. I've narrowed it down to only many-to-many relationships that are causing the issue, too. If I comment out anywhere that accesses [someObj mutableSetValueForKey:@"relationshipKey"] in code and disconnect the relevant bindings in my XIBs, then the application loads and displays the rest of the data fine.
>
> The other interesting thing is that if I delete my application data and launch the code built on 10.7/4.1, then it runs as expected - data is saved/loaded correctly.  Traditionally I've built against the 10.5 SDK as I supported Leopard, so the database was originally created and managed during the Leopard days. Creating a fresh one on Snow Leopard triggers the same issue. I've tried building on SL for 10.6 and it works fine too.
>
> I've searched high and low for others with this issue - I've only found a couple of similar hits, both on cocoa-dev, but unfortunately with no replies:
>
> http://www.cocoabuilder.com/archive/cocoa/275386-10-6-2-core-data-incompatibility.html
>
> And this one, which seems like a pretty similar issue:
> http://osdir.com/ml/cocoa-dev/2009-09/msg00709.html
>
> So it seems like there is some kind of difference in how many-to-many relationships work somewhere along the line, triggered based on whether I build on SL/4.0.2 or L/4.1. Has anyone encountered this before? I did contact both the posters of those previous threads but unfortunately it didn't lead to a solution. Of course I could stay using 10.6/4.0.2 forever, but that's not ideal.  :)
>
> This is the stack trace from where I attempt to access a value from one of these relationships, though it's about what you'd expect given the error:
>
> 	0   CoreFoundation                      0x9b466e77 __raiseError + 231
> 	1   libobjc.A.dylib                     0x9b25e149 objc_exception_throw + 155
> 	2   CoreData                            0x9233814b -[NSSQLiteConnection prepareSQLStatement:] + 1435
> 	3   CoreData                            0x9235f2d0 -[NSSQLChannel selectRowsWithCachedStatement:] + 80
> 	4   CoreData                            0x923562eb newFetchedRowsForFetchPlan_MT + 875
> 	5   CoreData                            0x923423d5 -[NSSQLCore newRowsForFetchPlan:] + 325
> 	6   CoreData                            0x9239b2f4 -[NSSQLCore newFetchedPKsForSourceID:andRelationship:] + 2644
> 	7   CoreData                            0x9239a235 -[NSSQLCore newValueForRelationship:forObjectWithID:withContext:error:] + 981
> 	8   CoreData                            0x92399e4e -[NSPersistentStoreCoordinator(_NSInternalMethods) newValueForRelationship:forObjectWithID:withContext:error:] + 78
> 	9   CoreData                            0x92399db2 -[NSFaultHandler retainedFulfillAggregateFaultForObject:andRelationship:withContext:] + 898
> 	10  CoreData                            0x923995da -[_NSFaultingMutableSet willRead] + 250
> 	11  CoreData                            0x923994a3 -[_NSFaultingMutableSet countByEnumeratingWithState:objects:count:] + 35
> 	12  CoreData                            0x923ba469 -[_NSNotifyingWrapperMutableSet countByEnumeratingWithState:objects:count:] + 57
>
>
> Cheers,
> -nick
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Core Data: I/O Error No Such Column (From: Nick Shore <email@hidden>)

  • Prev by Date: Re: drawRect not getting called when needed under OS X
  • Next by Date: does core data always call through the setPrimative methods?
  • Previous by thread: Core Data: I/O Error No Such Column
  • Next by thread: Error Message in 4.1(Lion)
  • Index(es):
    • Date
    • Thread