Hi,

OrmProfiler (v2.0.1 from 9.2019) Latest LLBLGen + Nuget packages

been playing with a test solution to check out how much work is needed to move from full to core and noticed that queries are not always intercepted. Thought it was something with the projects, references, but it seems that it depends on which app runs first. I have 4.7.2 and 3.1 console apps. If I open OrmProfiler and run/stop/run/stop 4.7.2 app - queries are captured. Then if I set 3.1 console project as a start up and run it - nothing is captured, if 4.7.2 console app is ran again - it logs again. To intercept queries from 3.1 I need to restart the OrmProfiler and then start the 3.1 app first and because 3.1 was started first setting 4.7.2 app as a startup project and running it results in no queries being logged.

Thank you!

UPDATE: added entity update:

var q = qf.Test.Limit( 1 );

using (var scope = new TransactionScope())
{
    using (var adapter = new DataAccessAdapter( connString ))
    {
        var result = (IList<TestEntity>) adapter.FetchQuery( q );
        var group = result.SingleOrDefault();
        Console.WriteLine( group.GroupName );

        group.GroupName = group.GroupName + 1;

        adapter.SaveEntity( group );
    }

    scope.Complete();
}

Can see a SELECTs AND UPDATEs for 4.7.2 app, but 3.1 app shows only SELECTs for the most of the time, sometimes I do see an UPDATE, but it's not consistent, yet data is modified in db. 4.7.2 is using the old SQL client and 3.1 is using the new Microsoft.Data.SqlClient:

var t = typeof( Microsoft.Data.SqlClient.SqlClientFactory );
var type = InterceptorCore.Initialize( "appName", t );
bootstrap.Init.Initialize(type);

Hi Findev,

On the part you initialize your DQE configuration in .net core 2.0+, Did you use the wrapped type to pass it to the .AddProviderFactory method? See this.

Could you identify a pattern in the failed tests. Please test it more to see the explicit behavior so we can reproduce it over here.

daelmo wrote:

Hi Findev,

On the part you initialize your DQE configuration in .net core 2.0+, Did you use the wrapped type to pass it to the .AddProviderFactory method? See this.

Could you identify a pattern in the failed tests. Please test it more to see the explicit behavior so we can reproduce it over here.

In core project:

private static void Main( string[] args )
{
    var t = typeof( Microsoft.Data.SqlClient.SqlClientFactory );
    var type = InterceptorCore.Initialize( "appName", t );
    bootstrap.Init.Initialize(type);

bootstrap - is a separate .net standard library

public static class Init
{
    public static void Initialize( Type type )
    {
        RuntimeConfiguration.ConfigureDQE<SQLServerDQEConfiguration>
            (
             c => c.SetTraceLevel( TraceLevel.Verbose )
                   .AddDbProviderFactory(type ?? typeof( SqlClientFactory ))
                   .SetDefaultCompatibilityLevel( SqlServerCompatibilityLevel.SqlServer2012 ) );
    }
}

These projects are not test projects as in nUnit, xUnit etc. but more like a playground.

if you don't run the 4.7.2 app, does the .net app log everything?

Otis wrote:

if you don't run the 4.7.2 app, does the .net app log everything?

Reopened VS and Profiler, ran only .net core app. Ran 5 times - can see only SELECT being logged, but no UPDATE though data is being updated in db

So this matter is about updates in a .NET Core app, not a matter of capturing from 2 sources. I'll see if I can reproduce it.

(Edit) Unfortunately, I couldn't reproduce it. Using .NET Core 3.1 and using the following configuration:

RuntimeConfiguration.ConfigureDQE<SQLServerDQEConfiguration>(
                                            c => c.SetTraceLevel(TraceLevel.Verbose)
                                                    .AddDbProviderFactory(InterceptorCore.Initialize("northwind", typeof(Microsoft.Data.SqlClient.SqlClientFactory)))
                                                    .SetDefaultCompatibilityLevel(SqlServerCompatibilityLevel.SqlServer2012));

The ORM Profiler could successfully capture the Update commands as well as Select commands.

Well, not exactly. It wasn't capturing from both sources when sources were switched and also missing logs when .net core app was used though I did see UPDATE showing up, it's just that it wasn't consistent and in most cases only the SELECT was logged. What's also interesting is that some of those SELECTs don't have the "DB time" column values

UPDATE: as for not capturing: interceptor had different app names, didn't notice that profiler has tabs on the left so all is good here UPDATE 2: regarding missing UPDATE - it seems that app was terminating too fast. Added Console.ReadLine() and was able to see the logged statement. Not a big issue, but might require to remember to add some delay in the tests to be able to capture the entire trace.

the early termination! I should have thought of that, indeed that's it. I also saw that in unittests not reporting everything, and then I realized the statements were about to be written to the named pipe but the tests are then ending (so the app ends) and the data is never written. Apparently on .net full this takes just the right amount of time to get the data flushed through the named pipe

Otis wrote:

the early termination! I should have thought of that, indeed that's it. I also saw that in unittests not reporting everything, and then I realized the statements were about to be written to the named pipe but the tests are then ending (so the app ends) and the data is never written. Apparently on .net full this takes just the right amount of time to get the data flushed through the named pipe

Indeed I should have noticed that too