Log4net not logging to sql database on windows server 2008, but works on local machine

Question

I am using log4net in my solution. I have created the database, as described in this article.

Locally, I have set up log4net properly. I get plenty of logs in my DbLog table. The table is a table inside my normal database with other tables.

However, after deploying the table code to my Windows Server 2008, no logged are added to the database. I don't know why, and I have tried A LOT now.

I ran the exact same create script on locally as on my windows server, and the log table (DbLog) is called the same on both local and production.

I use same connectionstring on my local machine and my Windows server. This works fine for my database when using the entity framework, for all other logic in my application.

On the Windows server, the only user who has access is the NT AUTHORITY\Network Service user. This works fine for my normal database setup with the entity framework, but maybe log4net uses a different user?

My log4net web.config code:

<configSections>
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
  </configSections>

<log4net>
    <root>
      <level value="DEBUG" />
      <appender-ref ref="ADONetAppender" />
    </root>
    <appender name="ADONetAppender" type="log4net.Appender.ADONetAppender">
      <bufferSize value="100" />
      <connectionType value="System.Data.SqlClient.SqlConnection, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      <connectionString value="server=.\SQLEXPRESS;initial catalog=LetterAmazer;integrated security=true" />
      <commandText value="INSERT INTO DbLog ([Date],[Thread],[Level],[Logger],[Message],[Exception]) VALUES (@log_date, @thread, @log_level, @logger, @message, @exception)" />
      <parameter>
        <parameterName value="@log_date"/>
        <dbType value="DateTime"/>
        <layout type="log4net.Layout.RawTimeStampLayout"/>
      </parameter>
      <parameter>
        <parameterName value="@thread"/>
        <dbType value="String"/>
        <size value="255"/>
        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="%thread"/>
        </layout>
      </parameter>
      <parameter>
        <parameterName value="@log_level"/>
        <dbType value="String"/>
        <size value="50"/>
        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="%level"/>
        </layout>
      </parameter>
      <parameter>
        <parameterName value="@logger"/>
        <dbType value="String"/>
        <size value="255"/>
        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="%logger"/>
        </layout>
      </parameter>
      <parameter>
        <parameterName value="@message"/>
        <dbType value="String"/>
        <size value="4000"/>
        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="%message"/>
        </layout>
      </parameter>
      <parameter>
        <parameterName value="@exception"/>
        <dbType value="String"/>
        <size value="2000"/>
        <layout type="log4net.Layout.ExceptionLayout"/>
      </parameter>
    </appender>
  </log4net>

My SQL create script:

CREATE TABLE [dbo].[DbLog] (
    [Id] [int] IDENTITY (1, 1) NOT NULL,
    [Date] [datetime] NOT NULL,
    [Thread] [varchar] (255) NOT NULL,
    [Level] [varchar] (50) NOT NULL,
    [Logger] [varchar] (255) NOT NULL,
    [Message] [varchar] (4000) NOT NULL,
    [Exception] [varchar] (2000) NULL
)

Any ideas? :-)

Answer 1

I found the problem.

There is a buffer value in the web.config, which delays putting the data into the database. This works fine, but for testing, it provides a problem as you cannot see the changes right away.

Set the buffer to 1, and you will see the changes right away.

Remember to set it back to a reasonable value when you are live and in production.