| Ok great, thanks for that. What you say makes sense. And yes, I am using Timestamp data types so that is probably where the problem is arising.
Thanks again to all,
Regards, David. On 12 Sep 2006, at 19:12, Robert Walker wrote: Dave,
Are you using the TIMESTAMP data type for any of your date/time fields. If you do this in MySQL this is a problem. If you have mapped any date/time fields as an Entity attribute then use DATETIME an not TIMESTAMP. If you really want the behavior of TIMESTAMP over DATETIME then you must remove this attribute for locking in the model. It's good practice to NOT do locking on DATETIME also.On Sep 12, 2006, at 12:32 PM, David Griffith wrote: Hi Paul,
Yes there is indeed a date field with locking switched on. Not deliberately, but it was like that by default and I didn't change it. I don't see how it affect referential integrity but I'll give it a go :-)
Thanks, Dave.
On 12 Sep 2006, at 14:51, Paul Lynch wrote:
On 12 Sep 2006, at 13:00, David Griffith wrote:
ec.saveChanges(); >-- saves the record to the database, assigns the primary key myEOObject.setAccountNumber(myEOObject.pkID().toString()); ec.saveChanges();
Obviously I am accessing the primary key via an accessor method of my custom class using the EOUtilities framework.
Anyway, the problem is that occasionally (maybe 10% of the time) the row fails to update and generates an exception stating 'failed to update row in database'. Everything is saved fine, the primary key is assigned, but after the second ec.saveChanges() is where it fails.
Does anyone have any idea why that might be? Is it perhaps because it is trying to update the database too quickly after a previous update?
Guessing: does your eo have another field with the locking property set? In particular, a time field that could have resolution problems? If so, make any date fields non-locking.
The general problem is that this breaks relational integrity (inventing jargon here), but it sounds like an ideal candidate for a trigger - does MySQL support triggers now? :-)
Paul
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
_______________________________________________ Do not post admin requests to the list. They will be ignored. Help/Unsubscribe/Update your Subscription:
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
