0

I inherited some projects in which apparently the VS application is using old EDMX. I don't recall having such a hard time with queries in the past, especially with figuring out parameters ..

As I step through the code I see various IQueryable<T> statements such as

IQueryable<BreakDomainModel> breakDomainModels = breakFactoryService.ReadBreakData();

Everyone seems to be so hidden that troubleshooting it becomes difficult.

Example of part of the SQL

CASE WHEN ([Extent2].[BreakId] IS NOT NULL) THEN [Extent3].[Name] ELSE @p__linq__0 END AS [C6], 
CASE WHEN ([Extent2].[BreakId] IS NOT NULL) THEN  CAST( [Extent2].[DateCreated] AS datetime2) END AS [C7], 
[Extent1].[ExceptionType] AS [ExceptionType], 
[Extent1].[LinkId] AS [LinkId], 
CASE WHEN ([Extent2].[BreakId] IS NOT NULL) THEN [Extent2].[Age] ELSE @p__linq__1 END AS [C8]

How can I step through the code and actually get the values of @p__linq__0 etc.. ?

I can provide more code if needed, but simply F11 and using watches is just not helping.

2 Answers2

0

You can register your own DbCommandInterceptor. Take a look at this article on EF logging. Note that in order to log the parameters you'll have to iterate over DbCommand.Parameters. A minimal solution to log the Select queries would be:

public class LoggingCommandInterceptor : DbCommandInterceptor
{
    public override void ReaderExecuting(DbCommand command,
        DbCommandInterceptionContext<DbDataReader> interceptionContext)
    {
        var parameters = command.Parameters.Cast<DbParameter>()
            .Select(x => $"{x.ParameterName}:{x.Value}");
        // It's up to you how you initialize the logger
        GetLogger().Debug($"Parameters: {string.Join(", ", parameters)}\r\n Query: {command.CommandText}");

        base.ReaderExecuting(command, interceptionContext);
    }
}

And then all you need to do is register that interceptor in your application startup code (global.asax/Startup.cs/etc):

DbInterception.Add(new LoggingCommandInterceptor());

If you care only about getting to the parameters when debugging just put a breakpoint inside the method, it'll hit every time EF accessed the database.

Please note that you'll have to override the other methods (NonQueryExecuting() and ScalarExecuting()) the same way in order to intercept the update/instert/delete queries as well.

Sam Arustamyan
  • 508
  • 3
  • 10
-1

It will probably be easiest to run a SQL profiler session to see the generated query.

See this answer for the better solution: View Generated Sql

michaelb
  • 149
  • 2
  • 11
  • 1
    Certainly seems like it, this is a nightmare. I forget how to use sql profiler - I wonder if I even have the permissions ! ugh –  Oct 01 '18 at 23:11
  • 1
    Not sure who downvoted you as its a valid way of doing it. I don't have the db permissions to even do the profiler - I just tried –  Oct 01 '18 at 23:19
  • I just added a link to another stackoverflow article with a solution. – michaelb Oct 03 '18 at 18:16