I actually followed the same approach as described in the documentation article you linked. Please excuse me for the misunderstanding.
The work process I proposed should be independent of the hosting option you have chosen. Once the Telerik Data Access Service Wizard
finishes execution, it should have added a .svc
file in your project. This file contain a class that inherits from OpenAccessDataService
. This is the place where I have added the CustomersWithDetails() method. In order for this method to be accessible from a client I also added the following line in the InitializeService() of the same class:
If you have created a Service Reference
to a project and you would like to consume this method with a .Net Client
, you could invoke it using the Execute
method. For example:
var client =
var result = client.Execute<Customer>(
Yes, you were right - the implementation of the OpenAccessDataService
would use Reflection
to discover all IQueryable
properties of the context. When one is queried, the service implementation would actually invoke the GetAll<T>
method of the Telerik Data Access
context rather the the property itself. This is the reason why you could not change the behavior of the service by modifying the contexts' properties.
Generally speaking, to get access to the Request URI
you need to override the OnStartProcessingRequest
method in your service class. Still, according to this MSDN article
, query interceptors is applied to methods that must return Expression<Func<T, bool>>
. This is why such solution may not be applicable in this situation. Could you please share more on your idea?
I would recommend to use the dedicated method approach. Could you please try it and let us know how it works.
Should you have any further questions, please let us know.
OpenAccess ORM is now Telerik Data Access
. For more information on the new names, please, check out the Telerik Product Map