Important: The information in this document is obsolete and should not be used for new development.
Master/detail user interfaces do not necessarily delete objects.
In a master/detail user interface, the delete operation only removes objects from the relationship, they do not get deleted directly by the operation triggered through the display group/detail data source. Only if the relationship is set to Owns Destination, the objects also get deleted when removing them from the relationship.
This behavior can result in situations where objects that got temporarily inserted and removed afterwards are not visible in the user interface any more (and thus cannot be deleted), but cause validation errors during saves which prevent the save from succeeding.
Check whether your model should use the Owns Destination flag. If not, use a different kind of user interface, one where you have a separate display group and user interface for the object to insert and another one with an action insertion association to attach objects to the relationship. Or implement your own application logic (typically in an EOController subclass) to make sure objects really get deleted.
Cannot use shared EC on client side.
Using EOSharedEditingContext with JavaClient shows inconsistent behavior. This means that a client shared EC won't automatically be loaded from a server shared EC. Also, a client shared EC won't automatically be loaded when an entity's objects are marked as shared in an EOModel. But explicitly fetching objects into a client shared EC should mean that a shared EC's functionality will work on the client.
Explicitly fetch objects into a client shared EC to ensure expected shared EC functionality on the client.
Last updated: 2004-12-02