I saw some of this discussed in another thread, one suggestion was to look at the Type for the System.Data.SqlClient I got the full name of the factory from this after the ORM is initialized. var factory = DbProviderFactories.GetFactory("System.Data.SqlClient");

Initialization is: SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("MYAPP");

The results are: SD.Tools.OrmProfiler.Interceptor.ProfilerDbProviderFactory`1[[System.Data.SqlClient.SqlClientFactory, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]

This appears to be correct, but the ORM Profiler is not showing any activity when I know that there is activity against the database.

After initialization, I checked the factory class again and the results are the same.

The web forms application is being run on the same machine as the profiler. I've tried running a unit test from the machine using the same initialization code as above in the test initialization and that works correctly.

Any other ideas of what may be going on. (FYI, this is a DNN website, however, I'm using the LLBLGen Runtime Framework to access the application database)

Thanks for your help.

Hmm, the only thing I can think of is that the DNN system already accesses the database before the ORM Profiler is initialized. As you've verified, the factory is wrapped in the DbProviderFactories table. When you use the SSMS profiler from sqlserver, just to see if that's the case, could you verify that?

I see the event in the SQL Profiler. Application name: .Net Sql Data Provider.

I use a separate database from the DNN database for the system. So DNN does not access the database.

SJSMWF wrote:

I see the event in the SQL Profiler. Application name: .Net Sql Data Provider.

I use a separate database from the DNN database for the system. So DNN does not access the database.

The thing is, when the profiler wraps the factory in the table, it might have already been read by our runtime so it won't use the wrapped factory. The provider table with wrapped factories is per appdomain. I don't know how DNN works internally. In any case, you could try the RuntimeConfiguration approach instead to register the factory and thus provide the wrapped factory to our runtime.

That's what I can think of why it won't work. In all other cases, I have no idea why the data won't arrive, the connection is over a named pipe which should work locally.