Is this maybe a symptom of some kind of threading problem? The process that is running was recently updated but the older process was very similar and never exhibited this problem. I have never had an issue with the data in the database being different from what is logged out in the setters.
This process should probably be a long running task but I've never had it run that way before. It has generally taken 30-45 seconds to complete in the past. Tim Worman UCLA GSE&IS On Oct 22, 2010, at 7:46 AM, Tim Worman wrote: > Thanks Ken. No, all the relationships on both entities are allowed to be > null. I'm really at a loss to explain how I'm ending up with different values > in the database than I see going through the setters in the EO. > > Tim Worman > UCLA GSE&IS > > On Oct 22, 2010, at 7:33 AM, Ken Anderson wrote: > >> Do you have any mandatory to-one relationships? >> >> Whenever I have situations where data is not what it's supposed to be, it >> ends up that EOF created other objects for me because of mandatory to-one >> relationships... I don't know if this is still a problem, but it used to be. >> >> On Oct 22, 2010, at 10:30 AM, Tim Worman wrote: >> >>> I have a process that cycles through a bunch of EO's (foos), does some >>> math, creates related EO's (bars), and inserts the math values into the new >>> EO's. When I run this process and it cycles through all the foos but the >>> values that get inserted into bars are not correct. If I restrict the >>> process to only handling one foo instead of cycling through many, the >>> inserted values ARE correct. >>> >>> I've tried inserting some console messages to see what values are passed to >>> the setters in bars. When I do this they are always correct but what ends >>> up in the database is different. >>> >>> Anyone have any ideas what might be causing this and how I can better >>> diagnose it? >>> >>> Tim Worman >>> UCLA GSE&IS >>> >>> >>> >>> _______________________________________________ >>> 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/kenlists%40anderhome.com >>> >>> This email sent to [email protected] >> > > _______________________________________________ > 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/lists%40thetimmy.com > > This email sent to [email protected] _______________________________________________ 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]
