On 16/03/2006, at 4:41 AM, Chuck Hill wrote:
Now, that does not explain how this is happening on a newly inserted object. Hence, I will resort to wild speculation. ;-)
1) A snapshot for the object has been registered on the server under this temporary ID prior to this save and some server side code has changed some value and this change was not seen by the client. awakeFromInsertion? When the save happens the snapshot does not match what the client has
I think this is the closest because I have:
public void awakeFromInsertion (EOEditingContext ec) {
super.awakeFromInsertion (ec);
setCreation_date (new NSTimestamp ());
setModification_date (new NSTimestamp ());
}
in the Artifact class (parent of everything important) on both the client and server side. Of course I did turn off locking on all these attributes and the problem persisted. The other question is as to why it has worked for the last six months only to be triggered by the fetch spec? It did seem to me that the server and client dates could be different (although I'm just running development on a single machine). From memory of this really a-long-time-ago code, WO complained if the client did not set these dates because they are not null. However, I don't trust client machines to provide an acceptable date and time (since these can be used for problem logging fields).
It also occurs to me that if the modification_date is set on update, that this is the only field in the entire record that needs to be set for optimistic locking (except for the problems with locking on dates).
Thanks
Ian