You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Davyd McColl (Jira)" <ji...@apache.org> on 2022/08/01 07:46:00 UTC

[jira] [Commented] (LOG4NET-686) AdoNetAppender not working over SQL server

    [ https://issues.apache.org/jira/browse/LOG4NET-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573618#comment-17573618 ] 

Davyd McColl commented on LOG4NET-686:
--------------------------------------

[~le_dragon] you can currently work around this by specifying a size for the utcdatetime parameter (default for datetime is 8, but datetime2 can have different sizes configured at the database, so I don't see how to automatically determine this. I now have to install pgsql because the change was made since pg apparently always failed with the old logic. Swapping the order of preparation (cmd, parameters vs parameters, cmd) makes sql server happy again, but I expect it to make pg fail again. I don't have an all-encompassing solution as yet.

> AdoNetAppender not working over SQL server
> ------------------------------------------
>
>                 Key: LOG4NET-686
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-686
>             Project: Log4net
>          Issue Type: Bug
>          Components: Builds
>    Affects Versions: 2.0.14
>         Environment: Windows 10 Pro N, 21H2
> .NET framework 4.7.1
>            Reporter: Hugues Stefanski
>            Priority: Major
>         Attachments: Log4NetTest.zip
>
>
> Hello,
> Following an update of our dependencies, I noticed that my log traces are not getting output to SQL server anymore. I created a test project (attached to this issue), with the same configuration, using v2.0.12 and v2.0.14, and confirmed that 2.0.12 worked as expected, while 2.0.14 does not write anything.
>  
> Checking the release notes, I stumbled on [PR 77|https://github.com/apache/logging-log4net/pull/77], which I guess might be related (but that's just a wild guess)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)