Re: help with com.webobjects.eoaccess.EOGeneralAdaptorException
Re: help with com.webobjects.eoaccess.EOGeneralAdaptorException
- Subject: Re: help with com.webobjects.eoaccess.EOGeneralAdaptorException
- From: Timothy Worman <email@hidden>
- Date: Mon, 30 Sep 2013 18:06:47 -0700
I figgered it out. :-)
I WAS able to get it to run with id only as the lock attribute which told me that there had to be some discrepancy between my model and the db on modifyDate. And so it was. The db (OpenBase) had modify_date typed as a ‘timestamp’ instead of ‘datetime.’ That made all the difference - although I don’t know why it always ran locally.
Lock attributes in partials remains unsolved though - in case anyone is looking for a fun one!! I will get to it at some point.
Thanks Chuck!
Tim
On Sep 30, 2013, at 5:27 PM, Chuck Hill <email@hidden> wrote:
> You get all of the fun ones!
>
>
>
> On 2013-09-30 5:20 PM, "Timothy Worman" <email@hidden> wrote:
>
>> Folks:
>>
>> I have an issue where on saveChanges() I get a
>> com.webobjects.eoaccess.EOGeneralAdaptorException:
>> updateValuesInRowDescribedByQualifier. It¹s an optimistic locking problem.
>
> Always? Sometimes? Often? Rarely?
>
>
>> However, I don¹t have the issue in my dev environment - only in
>> deployment.
>
> Is anyone else or any other process using the database in your dev
> environment? What about in deployment? :-)
>
>
>
>> Same database server software locally and deploy. The copy I run locally
>> for dev is an exact export of the database running on the server. So, the
>> exact same actions run fine and save to the database without a problem in
>> the local environment.
>>
>> Only one entity seems to be causing the issue. I¹ve gone even further by
>> limiting the lock attribute to ONLY the primary key of the entity in
>> question. Under that scenario, I still get the above error in deployment
>> only. I don¹t have this issue with any other entity in the database. I¹ve
>> kind of exhausted my ideas for why this is happening. I don¹t see
>> anything strange in the generated SQL.
>
> So you have confirmed that the SQL being emitted is UPDATE FOO SET
> whatever = 3 WHERE pk = 147;
> And THAT SQL is throwing that exception? If the WHERE clause is just the
> PK the only way for that to happen is if some other process has deleted
> that row. Is the entity transactional? It is feasible that some other
> process has deleted this row?
>
>
> Chuck
>
>
> --
> Chuck Hill
> Executive Managing Partner, VP Development and Technical Services
>
>
> Practical WebObjects - for developers who want to increase their overall
> knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/gvc/practical_webobjects
>
> Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest
> Growing Companies in B.C!
>
> Global Village Consulting ranks 44th in 25th annual PROFIT 500 ranking of
> Canada¹s Fastest-Growing Companies by PROFIT Magazine!
>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden