Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
For those who are interested in the Master-Details report scenario, please see this example illustrating the capability to adjust the XtraReport.FilterString property at runtime: How to implement a Master-Detail report by adjusting the FilterString property at runtime.
I'm not yet entirely familiar with the data binding situation. Would the following adapter help us enable design-time support? http://www.codeplex.com/L2EDataReaderAdapter
Hello Matthew,
We haven't yet tested whether the L2EDataReaderAdapter implementation allows handling Entity Framework relations, but we'll take this information into account.
Generally, our current implementation of retrieving property/field values is made to be compatible with the .NET data binding mechanism (the GetItemProperties method is called iteratively only for properties that implement the IList or IBindingList interface).
Please feel free to update this thread, if necessary. We greatly appreciate your effort!
Thanks,
Alex.
Hi Matthew,
I'm glad to inform you that our data binding methods can properly handle relations defined between Linq to Sql classes.
At present, no additional code is required when creating a Master-Detail report layout.
A sample project attached to this ticket illustrates this approach in action (How to use LINQ to SQL data source to create a Master-Detail report).
Please let us know if you find this approach appropriate or you need further clarification. Your feedback is greatly appreciated.
Thanks,
Alex
This example is correct. We currently use LINQ to SQL behind a number our reports.
The difficulty was in working with the report designer when using the Entity Framework. We found that it was not supported and were unable to adopt it.
Hi Matthew,
Thanks for the feedback.
Since the functionality suggested in this ticket (Relations support) is already available, I believe it's correct to close this thread.
I'm afraid we don't have any plans to provide Linq to Sql specific support in Report Designer, because our data binding methods aren't dependant on a particular data provider. However, there shouldn't be any problem to bind a report using the BindingSource component, as illustrated in the example I posted previously.
Should you need further clarification, feel free to ask. I'll be glad to help you.
Thanks,
Alex
It didn't appear that design-time relation support was available to the entity framework.
NB! Entity framework and Linq to SQL are distinct technologies!
We decided that it's better to register a separate suggestion regarding Entity Framework support. See:
Data Binding - Support for master-detail EntityFramework relations.