Can I / How can I see the SQL generated for a SaveChanges() statement?

This is related to earlier posts...  How can I see the SQL generated for a call to SaveChanges()?  I tried this:

        static void Main(string[] args)
        {
            var context = new LightSpeedContext<HawkModelUnitOfWork>("default");
 
            using (var unitOfWork = context.CreateUnitOfWork())
            {
                unitOfWork.Context.Logger = new TraceLogger();
                unitOfWork.Context.VerboseLogging = true;
 

and this:

        static void Main(string[] args)
        {
            var context = new LightSpeedContext<HawkModelUnitOfWork>("default");
            context.Logger = new TraceLogger();
            context.VerboseLogging = true;
 
            using (var unitOfWork = context.CreateUnitOfWork())
            {

to no avail.  I get a bunch of useless "Loaded some assembly" information, then a statement of the exception thrown by the SQL engine (with even less information than I get from VS).

Ideas?

LightSpeedContext.Logger works for SaveChanges -- we use it all the time!

The "Loaded some assembly" info is coming from the VS debugger, with whom we are sharing the Output window: there's nothing we can do about that.  It may be that VS is stopping on the exception before it flushes the trace info to the Output window, though I don't recall having seen that happen -- if you allow the program to keep running after the exception, do you see the trace output?  Another possibility is that you have trace redirected in your configuration file, though this seems unlikely.

If TraceLogger continues to give you problems, you could try ConsoleLogger -- this also works nicely in NUnit tests.

Still no love here.  My coworker's application does the logging just fine (MVC app), but I can't get mine to log anything.  The console logger doesn't work either, possibly due to the fact this si a console-hosted WCF application at the moment?

Regardless, I can't get one byts of logging from LightSpeed to show up anywhere.  The WCF logger works, though, see below.

The app.config file has this for the system.diagnostics section:

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel">
        <listeners>
          <add name="xml"/>
        </listeners>
      </source>
      <source name="System.ServiceModel.MessageLogging">
        <listeners>
          <add name="xml"/>
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add name="xml" type="System.Diagnostics.XmlWriterTraceListener" 
           initializeData="C:\Logging\ProdMonTraces.svclog"/>
    </sharedListeners>
  </system.diagnostics>

BTW, I commented that all out thinking it was interfering, still nothing...

What happens if you call Trace.WriteLine directly from your code, just to display a dummy "HELLO WORLD" message?

That gets written to the Output window, just as expected.

Is / are there any switch or setting that may have been set incorrectly that your trace code mayu be dependent on?

I don't think so.  Here's the source code to TraceLogger in its entirety:

  /// <summary>
  /// An <see cref="ILogger"/> that logs to <see cref="Trace"/>
  /// </summary>
  public sealed class TraceLogger : ILogger
  {
    #region ILogger Members

    /// <summary>
    /// Logs generated SQL just before it is executed by LightSpeed.
    /// </summary>
    /// <param name="sql">The SQL to log.</param>
    public void LogSql(object sql)
    {
      Trace.WriteLine(sql);
    }

    /// <summary>
    /// Logs a debug message.
    /// </summary>
    /// <param name="text">The debug message to log.</param>
    public void LogDebug(object text)
    {
      Trace.WriteLine(text);
    }

    #endregion
  }

We're not doing anything special as you can see.

You could try pasting the above code into a custom logger class, setting a breakpoint in LogSql and seeing if it gets hit and if so whether there is a problem with the CommandLog object...  Could also try doing unitOfWork.Context.Logger.LogSql("Hello world!") to try to prove that it's specifically a SQL logging problem rather than a wiring-up problem...

Not too worried you're giving away trade secrets? :)

I tried both LogSql and LogDebug, and they spit out exactly what I told them to.  Guess I have gremlins.

I need to go home and noodle on this overnight, maybe the answer will pop into my head while I'm floating around in the pool. Thanks for the ideas!

Dave

Back for Round 2...

OK, so I created a CustomTraceLogger class as you suggested, inherited from ILogger in Mindscape.LightSpeed.Logging, and I still get nothing.  LogSql() and LogDebug() are never called.

Here's the system.diagnostics section from my app.config file (and I DO get more data than I can digest if I set the System.ServiceModel switches to Verbose), followed by the startup code from my ConsoleHost's Program.cs file.  I get the messages I specifically send to LogSql() and LogDebug(), and I get .NET's logging output, but nothing from the Mindscape.LightSpeed,Logging library.  The TRACE constant is defined in properties for every project in the solution.

Something is preventing your Logging library from calling LogSql() and LogDebug() -- any ideas?  What am I missing?

I will try getting the latest nightly build from your website, possibly I have a bad build?  I am currently running the 8/2 build.

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel">
        <listeners>
          <add name="xml"/>
        </listeners>
      </source>
      <source name="System.ServiceModel.MessageLogging">
        <listeners>
          <add name="xml"/>
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add name="xml" type="System.Diagnostics.XmlWriterTraceListener"
           initializeData="C:\Logging\ProdMonTraces.svclog"/>
    </sharedListeners>
  </system.diagnostics>

        static void Main(string[] args)
        {
            var context = new LightSpeedContext<HawkModelUnitOfWork>("default");
            context.Logger = new CustomTraceLogger();
            context.VerboseLogging = true;
 
            using (var unitOfWork = context.CreateUnitOfWork())
            {
                context.Logger.LogSql("Hello world, I'm still here!");
                unitOfWork.Context.Logger.LogDebug("Hello debug world!");     
            ....
            }
        }

> I will try getting the latest nightly build from your website, possibly I have a bad build?  I am currently running the 8/2 build.

Nope.  Still nothing.

Not even being called?  Breakpoints not being hit?

If LogSql is not even being called, I'm completely stumped by this.  The only conditional we have around whether to call LogSql is whether context.Logger is null.  And the call is in a finally block so you should definitely see the LogSql call even if there is a database exception.  I think you will have to send us a minimal repro project.

(Note: We shouldn't need to see the real model, so I'd suggest replacing it with a trivial single-entity model so as to keep the repro as minimal as possible.)

I'll work on that, but you won't see it 'til next week at this point.  Have a great weekend!

Dave