[ 
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)

Reply via email to