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.
|