I doubt that lockObject() code in EOF has been run in... maybe forever. It is highly possible that it is causing EOF to get confused and resulting in the errors below. Get rid of the lockObject() calls and see if the problem below goes away.
Chuck On 2015-01-23, 7:01 AM, "OC" wrote: Hello there, there's third weird problem in my current log -- I've got the EODatabaseContext delegate call databaseContextFailedToFetchObject; the arguments were gid: _EOIntegralKeyGlobalID[DBAuction (java.lang.Integer)1000409] object: <DBAuction@1174723668 PK:1000409 Title:'Dodávka plynu v rámci sdru?en?ch slu?eb dodávky plynu' /EC:165037464> Actually I am sort of flabbergasted -- seems I do not get the databaseContextFailedToFetchObject delegate metod meaning; I thought it gets called when the target object is not available, and "object" contains a generated placeholder. Self evidently not -- DBAuction@1174723668 is the right and proper object with PK 1000409?!? Why do I get databaseContextFailedToFetchObject? Anyway, I return false from the databaseContextFailedToFetchObject delegate method, and saving did suceed. Shortly later though, in a subsequent R/R loop, I did *not* get the databaseContextFailedToFetchObject call, but instead an exception === Caused by: com.webobjects.eoaccess.EOObjectNotAvailableException: prepareForSaveWithCoordinator: Cannot save the object with globalID _EOIntegralKeyGlobalID[DBAuction (java.lang.Integer)1000409]. The row referenced by this globalID was missing from the database at the time a fetch was attempted. Either it was removed from the database after this application got a pointer to it, or there is a referential integrity problem with your database. To be notified when fetches fail, implement a delegate on EODatabaseContext that responds to databaseContextFailedToFetchObject(). at com.webobjects.eoaccess.EODatabaseContext.prepareForSaveWithCoordinator(EODatabaseContext.java:5657) at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:370) at com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3192) at er.extensions.eof.ERXEC._saveChanges(ERXEC.java:1179) at er.extensions.eof.ERXEC.saveChanges(ERXEC.java:1102) ... === Now, I am pretty sure that the database row did exist all the time -- it does exist in the DB now. Its creation date (which I set up in awakeFromInsertion) is the original one. There were successful UPDATEs before (a number of them) AND one later, too! There's no DELETE at all. Note: this auction is the very one which failed to lock (see please my mail "locking with more coordinators causes an exception?" above). Nevertheless, after the fail-to-lock and before this problem there was a couple of successful UPDATEs on the object, so it does not seem the fail-to-lock would be the culprit. Does anybody see any method in this madness? Thanks a lot, OC _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com This email sent to ch...@gevityinc.com<mailto:ch...@gevityinc.com>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
