I think I might have found the problem. I'm checking my EOModel and I notice that all of my boolean fields are set as Custom Data Type with NSNumber Value Class. Any time I set the Data Type to Boolean and save, as soon as I re-open the EOModel, it is changed back to NSNumber. I know that FrontBase saves the values as TRUE/FALSE, not 0/1. I tried using the Boolean prototype from Wonder, but that doesn't work either because it says that the ValueOf method is not part of java.lang.Number.
I've tried all of the suggestions, and short of just using FBManager to change the field values via SQL, I'm not seeing any patterns or useful exceptions. That is why I think it is just a conflict between the EOModel and the DB.
Is there any reason why EOModeler is converting my Booleans to Custom / NSNumber?
Thanks,
Ken
From: Amedeo Mantica < email@hidden> Date: Thu, 21 Apr 2011 13:27:43 +0200 To: Ken Anderson < email@hidden> Cc: WebObjects-Dev Mailing List List < email@hidden> Subject: Re: Session EC Exception
On 21/apr/2011, at 10.14, Philippe Rabier wrote: EOF can't update a user because it's likely that the same user has been updated by another instance between the moment where the user has been fetched and the moment where is's saved. You should see that if you set EOAdaptorDebugEnabled to true (log4j.logger.er.transaction.adaptor.EOAdaptorDebugEnabled=DEBUG).
First don't call editingContex.save() at the end of the merge but in your loop, for example every ten users modified. The very crap but quickest way to solve : relaunch your app and merge again (it's very dirty, I know).
+1
you could also try to fix it directly with SQL in database, is a to-one relationship so you have just to update the id ( a search/replace )
update TABLE_NAME set FIELD_NAME = NEW_ID where FIELD_NAME = OLD_ID;
DO A BACKUP FIRST ! you could also create a new column in the database and copy all relationships IDs before touching it, so you have a quick restorable backup (remember to allow null values, otherwise you will get in error adding a new row)
Regards Amedeo
Better way: use ERXFetchSpecificationBatchIterator. You don't waste memory usage and if the batch size is small, statistically, the problem will raise less often. And you have to deal with this exception, aka invalidate the user. If you have an instance dedicated to the merge, you won't have any issue otherwise it can be tricky if the same object is modified in another editing context, the modifications are lost (read Practical WO again and again).
The best solution is to avoid the problem during record imports, isn't it?
Philippe On 21 avr. 2011, at 04:39, Ken - Watermark Studios wrote: So, I have over 4000 user objects related to about 20 country objects. I had a few duplicate countries in the country table because of record imports. So, I wrote a quick direct action that allows me to merge the countries. Basically, there are two drop-down lists, each with the full country list (including duplicates). I can select two different country objects and the page moves all users of the first selected country to the second selected country.
Here's the problem. I've been successful merging almost every country to the appropriate country. The successful merges have had between 1-500 user objects to move. When I was trying to move USA related users to United States, 900 records successfully move, but I get the following error for over 200 records.
"er.transaction.adaptor.Exceptions - Database Exception occured: com.webobjects.eoaccess.EOGeneralAdaptorException: updateValuesInRowDescribedByQualifier -- com.webobjects.jdbcadaptor.JDBCChannel method failed to update row in database updateValuesInRowDescribedByQualifier -- com.webobjects.jdbcadaptor.JDBCChannel method failed to update row in database"
Where should I start looking to resolve? I've compared the data from objects that successfully transferred against those that didn't transfer and I'm not seeing a clear pattern.
Thanks,
Ken
|