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.
Currently, as a workaround you can use the approaches described in the following issues:
OBSOLETE - How to use an associated IList collection for a Many-To-Many relationship to avoid performance problems when working with large collections.
OBSOLETE - How to create a wrapper around a Many-To-Many relationship to avoid performance problems when working with large collections.
See Also:
Datalayer.Performance - Provide a way to avoid performance problems when working with large Many-To-Many collections without creating an intermediate class
Solution from the S30962 suggestion - Collections are not visible in reports.
How to use server mode with "How to: Filter Lookup List Views - Scenario 4 - Custom Lookup Property Data Source"
Thanks,
Dennis
We have implemented this feature in the upcoming 12.1 version.
Starting from this version, the UseServerMode option set in an application model for a required nested or lookup ListView node will be in effect.
Take special note that the global UseServerMode option (under the Options element in the application model) will NOT automatically propagate its value to the respective local UseServerMode property value for all nested ListViews only. This was done intentionally, because the server mode per se is not designed to be used for each and every ListView without a real need for it. Generally, we recommend you use the server mode only when you really require it, for instance when a ListView is supposed to display thousands or millions of records. Also, refer to this help article to learn more on some server mode limitations that logically arise because of data processing on the server side. However, the global UseServerMode option will affect lookup ListViews as it was already done for the root ones by default.
We think that the way we implemented it is the most correct and safest variant, but, as always, we look forward to hearing customers feedback on this and can adjust this behavior in the future.
Thanks,
Dennis
News, tips & tricks and other interesting information about DevExpress Application Framework and ORM