I tried to start the profiler but it is not working.

In startup.cs we used this code:

SD.LLBLGen.Pro.ORMSupportClasses.RuntimeConfiguration.ConfigureDQE<SD.LLBLGen.Pro.DQE.SqlServer.SQLServerDQEConfiguration>(
            c => c.SetTraceLevel(System.Diagnostics.TraceLevel.Verbose)
                  .AddDbProviderFactory(SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("application name",
                                    typeof(System.Data.SqlClient.SqlClientFactory)))
                  .SetDefaultCompatibilityLevel(SD.LLBLGen.Pro.ORMSupportClasses.SqlServerCompatibilityLevel.SqlServer2012));

            var wrappedType = SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("application name",
                                              typeof(System.Data.SqlClient.SqlClientFactory));

            SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("application name", wrappedType);

then in the code I have this usage:

var dataAccessAdapter = new BobyClock.LLBL.Organization.DatabaseSpecific.DataAccessAdapter(connStringBuilder.ConnectionString);

then started ORM Profiler and I pressed Start Recording and then running the application but no activity is recorded in the profiler.

I am using: netcoreapp2.2 SD.Tools.OrmProfiler.Interceptor.NetCore 2.0.2 SD.LLBLGen.Pro.ORMSupportClasses 5.3.0

Hi Iounut,

It looks like it should work. Are you debugging or running a release package? (If so, please check that the necessary dlls are copied to the output folder.

Be aware that the data isn't send over the network, so the client has to run on the same machine as your app

I double checked and is running in debug mode, and also is on the same machine (development).

I am running from Visual Studio 2019, debug time. Running also everything as administrator. The profiler is silent and no activity recorded whatsoever. Clicked on the button "record to snapshot" but nothing happens.

Wondering if this is because I am using LLBL Gen Pro 5.3 and the Profiler is 2.0 ?

No it should work fine. It wraps the factory you specify and the runtime simply uses the wrapped factory. All activity on the objects is then send over a named pipe to the client. I don't think firewalls locally block named pipes.

If you create a simple console app with the same generated code and try to read an entity from the database using the same initialization code as your webapp, do you see activity then?

Thanks for the response. My agenda is full right now but when I will have time, I will be back to you with a simple console app.

Ok, no worries. I bet it's something simple

I'll close this thread for the time being, it will be automatically reopened when you post a reply. We'll be waiting for your repro.

Thanks.

Hello,

Same thing here, but with Profiler: v1.5 LLBLGen: v5.1 VisualStudio: 16.6.1 .NET: 4.5.2

Program.cs:

        static void Main()
        {
            SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("CATENA");

            //WindowsFormsSettings.ForceDirectXPaint();

            AppDomain.CurrentDomain.UnhandledException += AllUnhandledExceptions;
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
            Application.Run(new MainFormRibbon());
        }

Nu get package: SD.Tools.OrmProfiler.Interceptor.NET45, version: 1.5.20150715

And you're sure there's database activity? As that's not the whole program

No it is not the whole program and yes there is database activity!

I have to mention, I remember now, that we override DataAccessAdapter.

Could I give more information, please let me know?!

I'm not on .NET core, as the original writer is, I could make a new Issue if you like?

What changes did you make to the adapter? The main issue is that if the factory isn't wrapped, (which is done by the interceptor initialize), the original factory is used and therefore no calls are intercepted.

Also, as v2.0.2 of ormprofiler is free for you, could you try the v2 version and see if it fixes it for you?

Like to try the latest profiler, but where can I find it?

Meindert wrote:

Like to try the latest profiler, but where can I find it?

If you have a valid LLBLGen Pro license you should be able to download the latest ORM Profiler: Go to https://www.llblgen.com -> My Account -> Downloads -> OrmProfiler.

If you grab the SqlClient factory from DbProviderFactories: var factory = DbProviderFactories.GetFactory("System.Data.SqlClient"); and check the type (after InterceptorCore is called), is it a Profiler* type or is it System.Data.SqlClient.SqlClientFactory ? (please write out the type in full, as the tostring can be misleading)

If it's SqlClientFactory, the overwriting of the DbProviderFactory table hasn't succeeded, and the factory isn't wrapped (causing no data to be send). If the type is a Profiler* type, the factory is wrapped and the data might not be accepted by the client, which is the case if the client runs on another machine (as the connection is over a named pipe).

Other than that it's weird, as here everything works fine in that kind of setups.

Ignore this as it is working

SD.LLBLGen.Pro.ORMSupportClasses.RuntimeConfiguration.ConfigureDQE<SD.LLBLGen.Pro.DQE.SqlServer.SQLServerDQEConfiguration>(
            c => c.SetTraceLevel(System.Diagnostics.TraceLevel.Verbose)
                  .AddDbProviderFactory(SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("application name",
                                    typeof(System.Data.SqlClient.SqlClientFactory)))
                  .SetDefaultCompatibilityLevel(SD.LLBLGen.Pro.ORMSupportClasses.SqlServerCompatibilityLevel.SqlServer2012));

            var wrappedType = SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("application name",
                                              typeof(System.Data.SqlClient.SqlClientFactory));

            SD.Tools.OrmProfiler.Interceptor.InterceptorCore.Initialize("application name", wrappedType);

I am using LLBLGen 5.11.1 and ORM Profiler .nuget\packages\sd.tools.ormprofiler.interceptor.netcore\2.0.8\ VS2022 .NET8 Core project

Where to find the 'application name'?

How to conditionally run for DEV (when required only) and then turn off for DEV(when not required), PROD 'InterceptorCore.Initialize'?

Maybe with a preprocessor #if DEV ... #endif ?

Otis wrote:

Maybe with a preprocessor #if DEV ... #endif ?

Otis, thank you.

Many times it is not showing instantly any SQL in Profiler when running this code.

using (DataAccessAdapter adapter = new DataAccessAdapter()) { adapter.FetchEntityCollection(this, filterBucket, maxNumberOfItemsToReturn, sortClauses, prefetchPath, excludeIncludeFields); }

kakaiya wrote:

Many times it is not showing instantly any SQL in Profiler when running this code.

using (DataAccessAdapter adapter = new DataAccessAdapter()) { adapter.FetchEntityCollection(this, filterBucket, maxNumberOfItemsToReturn, sortClauses, prefetchPath, excludeIncludeFields); }

If this is in a unit test, it might be the process the query runs in ends before the actual data captured is sent to the client. I see this too in our unit tests, especially on .NET 6+. I tracked it down to that: the data is captured but as the process the capture code runs in is terminated as the test has been completed, the data is never fully sent and therefore doesn't arrive at the client

It is not running in UNIT test. It is runing in real code. Is there any setting to not generate and delay SQL in ORM?

kakaiya wrote:

It is not running in UNIT test. It is runing in real code. Is there any setting to not generate and delay SQL in ORM?

For testing, could you place a Thread.Sleep(1000); right below the closing } in the using statement? The problem shouldn't occur with code running in an app, but if the app is a webapp, the thread might have ended or at least the code that has to send the data isn't available anymore (cleaned up). The reason we found when it wasn't arriving at the client was when the unit test ended and effectively all objects were cleaned up already.

(the thread.sleep(1000) is of course not useful in production, but it's meant to make sure the thread running the code isn't cleaned up before the profiler code sends the data. We use a named pipe which is fed by a thread which receives the objects to send. When the objects involved in a query (connection, dbcommand etc.) have to send data, they'll produce a message object and this is appended to a queue. The named pipe thread will empty this queue every 100ms. So if the application is terminated within this 100ms nothing will end up in the client. To my knowledge the thread dealing with this queue should stay alive as it's started as a background thread. )

Hi Otis,

Thank you.