Indeed, the flow of execution of queries that follow the pattern:
var query = dbContext.GetAll<T>()
is exactly as the one you describe. Additionally, your suggestion about placing the call to the OrderByDescending() method before the call to the Select() method matches the recommended approach for composing this type of statements.
Regarding the issues in the SQL statements generated by the LINQ implementation of Telerik Data Access, I am sorry for the inconvenience caused, and let me assure you that the effort on our side towards improvement and introduction of new capabilities is constant. In fact, some of the problems you experienced are already fixed and available for download with our latest official release and others can be easily worked around with the help of the rest of the features of Telerik Data Access. Please kindly find the details below:
1. Wrong SQL generated with joined subqueries
In this thread, Telerik Data Access was producing an incorrect query for the given LINQ expression, which utilized a join
clause inside the where
clause. This post
suggest an alternative approach to the query composition that produces the needed SQL statement.
2. Invalid SQL generated for bool expressions
The issue reported in this thread is related to the generation of invalid SQL query based on a scenario which requires a cast from bool to bool?. The suggestion in it
involves a change in the configuration of the bool properties in the model (to avoid the cast) and a slight modification of the where clause of the query.
3. Exception when using local variables in LINQ
Here, the scenario required the usage of a local IQueryable<T> variable in a LINQ expression. At the time it was reported, Telerik Data Access was supporting it, but with versions Q3 2013 SP2 and later, the statement produces the needed result. The details are available in this post
4. Invalid SQL generated with navigation properties and DefaultIfEmpty
The issue experienced here is caused by the specific support for the DefaultIfEmpty() method on collection navigation properties. The default behaviour of Telerik Data Access in such situations is to perform an INNER JOIN between the main entity and the related one. At the time present, this continues to be a limitation on our side, but this post suggests a workaround, which utilizes our Fetch Plans
capabilities and as a result simplifies the LINQ expression. You can find the details here
5. Invalid SQL generated with OR and subqueries
The issue reported here, brought to our attention a bug in the SQL generation based on the Any() method in combination with OR in the where
clause. At the time of the report, this post
suggested a workaround, which suggests the usage of join statements. Currently, the issue is fixed, and the query that produced it retrieves the needed results. An additional fix is pending on our side, that will resolve the SQL generation in case Any() is combined with AND in the where
Do not hesitate to get back to us, in case you have questions or need further assistance.
OpenAccess ORM is now Telerik Data Access
. For more information on the new names, please, check out the Telerik Product Map