I encountered a similar problem related to the use of a keypath
predicate in combination with CONTAINS. When I replaced CONTAINS with
LIKE the problem went away.
I guess I should have given an example of a predicate that is
generating the error:
changedRating == 1 AND onlineID != 0 AND ANY collections.name !=
"SearchCache"
->Ben
On Dec 18, 2007, at 3:16 PM, Ben Lachman wrote:
After digging a bit more both issues seems to have to do with
predicates that include the ANY key in the fetch request. My
understanding was that you can have only 1 ANY/ALL/IN per predicate
for SQL stores but that was my only limitation. Are there any
other predicate guidelines for executing fetches on SQLite stores
that I'm not aware of?
Thanks,
->Ben
On Dec 18, 2007, at 1:59 PM, Ben Lachman wrote:
I just moved my CoreData store from XML over to SQLite and started
having some problems:
1) Sometimes when I do a fetch request I get this database corrupt
error:
NSError "The file could not be opened because it is not in the
right format." Domain=NSCocoaErrorDomain Code=259 UserInfo={
NSUnderlyingException = Fatal error. The database at /Users/
ben/Library/Application Support/CDApp/CDApp.mydb is corrupted.
SQLite error code:1;
}
It always happens for the same fetch requests, but doesn't happen
for all fetch requests. Anyone have any ideas why this might be
happening?
2) Sometimes I get an "ALL modifier is not implemented" exception
when doing a fetch request using a template from my managed object
model. However the templates don't use all. They use NOT ANY
toManyRelationship.var == "someString". I'm assuming this is
getting optimized into "ALL toManyRelationship.var !=
"someString". Anyone know of a work around that doesn't use ALL
(or NOT ANY I guess).
_______________________________________________
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
