New Posts New Posts RSS Feed: Save failed - Eval error: unable to evaluate
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Save failed - Eval error: unable to evaluate

 Post Reply Post Reply
Author
b_redeker View Drop Down
Newbie
Newbie


Joined: 16-Aug-2012
Posts: 2
Post Options Post Options   Quote b_redeker Quote  Post ReplyReply Direct Link To This Post Topic: Save failed - Eval error: unable to evaluate
    Posted: 16-Aug-2012 at 10:04am
Visual Studio 2008, .Net 3.5 SP1, DevForce object mapping tool 3.6.10, TortoiseSVN 1.7

Over the past couple years we intermittently get the above error. It's always a pain to get rid of it, and the forum has only 2 posts about it which are both not very helpful, so I decided to post my experience, hoping it'll help somebody some day.

Summary: after merging with TortoiseSVN, the ORM has double IDs. These cause a problem the next time the object mapper is run, and results in the above message. 

Description: We use TortoiseSVN for versioning. When 2 developers have both edited the same ORM, and these versions are merged, this often results in a clash, as both changes will use the same IDs. For instance, dev A adds a column Foo to table Employee, which gets new ID 42; at the same time, dev B adds a new relationship between Employee and Department, which also gets ID 42. When the 2 changes are merged, our version software does this but (obviously) doesn't change the ID's.

This sometimes results in a crash of the object mapper. The ID's are changed manually, and the ORM can be processed again. In other cases however, everything seems fine, until you edit the same Employee table. Now, suddenly the relationships are evaluated again, and now the error as mentioned in the topic appears.

Please note that this is an extremely unhelpful error message. Only the IdeaBlade own devs may be able to interpret this; as an external developer, this adds nothing.

Remediating the problem in this case however was easy. Remove the offending relationship, add it again (I saved and compiled in between) and the problem is solved. However, because of the unhelpful error message,  it took me 2 hours to get to the bottom of the problem and find a solution.

Request: maybe in a newer version this is already done, but
- change the object ID's to GUIDs, which are unique and will never clash in the above scenario
- change the error message to something more informative. It should at least indicate which table, property or relationship fails.

Thanks,

B.


Edited by sbelini - 16-Aug-2012 at 11:51am
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 16-Aug-2012 at 3:25pm
Sorry you ran into problems.
 
The .orm file generated by the Object Mapper has never been "merge friendly".  Doing a merge is essentially the same thing as editing the file directly, which is explicitly not recommended.   In general, the Object Mapper owns the .orm file, along with the EntityRelations class and *DataRow/DataTable classes, and these should never be modified by anything except the Object Mapper.
 
 
Back to Top
b_redeker View Drop Down
Newbie
Newbie


Joined: 16-Aug-2012
Posts: 2
Post Options Post Options   Quote b_redeker Quote  Post ReplyReply Direct Link To This Post Posted: 17-Aug-2012 at 10:31am
Yeah, but what when multiple developers each have to be able to change objects and relations? Do you have a recommendation for such a scenario? Do you have a recommendation for working with source control?
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 17-Aug-2012 at 4:00pm
This is unfortunately a problem with OM tools in general; the Entity Framework EDMX has the same issue.  There are a few policy options for your group to consider, but none is ideal:
 
- Allow only a single developer to make all changes to the model.
- Checkout the file(s) with an exclusive lock.  This is not standard behavior with Subversion, but here's more information on how to use it - http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-locking.html
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down