The fact that Chuck didn't come up with this makes me doubt my memory,
but...
It seems that when I've run into this in my applications, it usually
means that between the time the EO was read out of the database, and
the time it is written back in, something in one of the locking fields
changed, or the field isn't "locking-friendly" in that WO has a
difficult time reading the datatype of the DB field and converting it
into the requested Java datatype and then converting it back and
coming up with the original value. I know with MS SQL Server that long
text fields are a problem.
I _believe_ (please correct me if I'm wrong) when EOF does an update,
it does it along the lines of "UPDATE TABLE WHERE ATTRIBUTE_1 = x,
ATTRIBUTE2 = y, etc" where the attribute values are from the original
reading of the record.
The problem is that the UPDATE can't find any records matching the
original attributes, and therefore didn't "select" any rows for
updating.
Dave
On Apr 1, 2008, at 6:06 PM, Johan Henselmans wrote:
Error:
com.webobjects.eoaccess.EOGeneralAdaptorException:
lockRowComparingAttributes --
com.webobjects.jdbcadaptor.JDBCChannel: lock operation failed to
select any rows
_______________________________________________
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:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
