I would have thought this is a common requirement but I just cannot seem to find any resources addressing this. I have several Entities defined along with Associations between them. They deploy without errors and I am able to create an External List against my primary Entity. We viewing (ReadItem) or editing a specific item (Update), the Association works and displays the "lookup" value instead of the foreign key value.

Obviously I need to extend this to the initial list of items (ReadList) but cannot seem to find any way to do this. Since Association values are found by executing separate queries, doing so for a single Entity does not cost much in terms of performance.. However, doing so for a list of items would be painful since you would have one query for the list and then (number of list items * number of associations) queries for the supporting values.

The usual way of solving this is to have the list query also perform LEFT JOINs to bring back all the data at once. Then instead of display say StatusId or ProductId you would display the actual Status value (New, Open, etc.) or the Product Name.

In essence you need to completely flatten the object returned by ReadList. Once the query is modified you can then add additional TypeDescriptors to represent the lookup properties. The problem is that while the ReadItem object can contain TypeDescriptors that other methods do not have, the opposite is not true. You cannot have TypeDescriptors in the ReadList method that do not also exist in the ReadItem method.

The only solution (that I can think of) to that is to flatten the model all the way throughout the Entity. So now all my methods (or at the very least ReadItem and ReadList) have both the foreign key Type Descriptor and the lookup value Type Descriptor. Obviously I do not want that displayed on the View Item and Edit Item views.

While I can set the Read-Only property of the lookup value Type Descriptor to True so it does not display in the Edit page I do not see any property to hide it on the View page. I am sure I can then use SPD to modify the page to hide the unwanted properties but this seems like a very convoluted and complex way of solving a very, very common requirement. (After all, I cannot think of any scenario where you define Associations between Entities but are ok with the not showing the Association on the List view.)

How is this normally dealt with?

Thank you.

  • I am running into this problem now, and the silence on this issue, both here and throughout the web, is not reassuring. For now I am handling this by defining my entities based on a view. This approach in turn creates new problems - now I have to define triggers to handle updates, deletes, and creates, and I am seeing all sorts of undecipherable errors at seemingly random points when testing. In addition I have the same problem with extra fields in the view/edit forms. Jason is right in saying this is a common use case that is completely ignored by BCS, unless there is something really obvious May 24, 2012 at 14:13

1 Answer 1


I ended up "flattening" my data model by returning an object that contained both the left and right sides of the foreign key. So, for example, I returned both the ProductId and the ProductName. The ProductName was used in the item list and the ProductId was used in the creation and editing of items.

The problem that this created was that the Edit and Create forms then had to be customized in order to hide the properties that were extraneous (like ProductName). Of course getting those customized forms into Visual Studio and deployed was another can of worms which I never worked out...the entire approach had to be abandoned.

Note that I also opened up a support ticket with Microsoft about this but another a week or so or "still researching" or "no solution yet" I gave up on them and cancelled the ticket...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.