Print Page | Close Window

Save failed - Eval error: unable to evaluate

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2009
Forum Discription: For .NET 3.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=3580
Printed Date: 31-Oct-2024 at 8:16pm


Topic: Save failed - Eval error: unable to evaluate
Posted By: b_redeker
Subject: Save failed - Eval error: unable to evaluate
Date 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.



Replies:
Posted By: kimj
Date 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.
 
 


Posted By: b_redeker
Date 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?


Posted By: kimj
Date 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 - http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-locking.html



Print Page | Close Window