Would you consider two additional overloads for GetAsDataReader?

GetAsDataReader(IRetrievalQuery) <--transaction null and command behavior is close GetAsDataReader(IRetrievalQuery, CommandBehavior) <--this makes transaction null

These are just wrappers on GetAsDataReader(Transaction, IRetrievalQuery, CommandBehavior)

They're not there because they will lead to blocking threads at runtime if you're not careful. By having a transaction parameter in the signature, the user is confronted with the choice to pass one or not. this will limit the number of runtime-deadlocks when fetches are performed inside a transaction

blocking threads at runtime if you're not careful

Please explain. If it is not in a transaction, I am passing null as the first parameter. How can this cause blocking issues?

WayneBrantley wrote:

blocking threads at runtime if you're not careful

Please explain. If it is not in a transaction, I am passing null as the first parameter. How can this cause blocking issues?

If you pass null, you have decided not to use an active transaction, for example because there's none. If there's no parameter, you're not confronted with the parameter and therefore could accidently not pass the transaction. We've seen a lot of reports about deadlocks with for example typedview fetches inside transactions so we wanted to make it clear you've to decide what to do with these methods.