Yes this is possible.
First you have to create a subclass of the SqlServerSpecificCreator, that's part of the SqlServer DQE. In that subtype you override public virtual DbCommand CreateCommand(DbConnection connectionToUse)
. First you call the base method to create the SqlCommand, then in your override you create the TraceableSqlCommand by passing in the created SqlCommand.
To use your custom SqlServerSpecificCreator, you have to create a subtype of the DynamicQueryEngine of the SqlServer DQE, and override the protected override IDbSpecificCreator CreateDbSpecificCreator()
method. In your override you create an instance of your custom SqlServerSpecificCreator derived class.
Last step is to make sure the system uses your custom DynamicQueryEngine type. If you're using Adapter, create a subtype of the generated DataAccessAdapter class and override the method protected internal abstract DynamicQueryEngineBase CreateDynamicQueryEngine()
. In your override create a new instance of the custom DynamicQueryEngine subclass you made.
If you're using SelfServicing, it's trickier, you need to adjust the template for the DAO classes (as they create the DynamicQueryEngine in their constructor).
An alternative route could be to wrap the DbProviderFactory class. This doesn't require you to derive any subtypes of our framework, you have to create a new DbProviderFactory deriving class which basically wraps the factory passed in (in your case the SqlClientFactory) and calls the wrapped factory's methods for e.g. CreateConnection and the like. For CreateCommand you return an instance of the TraceableCommand. I'd also wrap SqlConnection and return a TraceableCommand when its CreateCommand method is called. We use this method in our orm profiler interceptor.