[EDIT]
Maybe a more obvious solution than what I propose below would be to change from using an INSERT statement to using a database procedure to log. If you use a database procedure then you could handle the swizzling from empty string to null yourself. I don't know for sure that you can use a database procedure with NLog's Database target. Log4net supports it so my guess is that NLog does as well.
Here is one example (in the answer to the linked question) I found of the configuration from someone using NLog to log to a database using stored procedure.
http://nlog-forum.1685105.n2.nabble.com/Using-a-stored-procedure-for-the-DB-Target-td2621725.html
I see here:
http://nlog.codeplex.com/workitem/5418
A complaint that it doesn't work (at least in the NLog 2.0 beta).
One difference between the two examples is that the working example uses "exec LoggingProcedureName ..." while the nonworking one uses "LoggingProcedureName ..."
Hope this helps.
[End EDIT]
I can't comment on why NLog writes emptry strings rather than null or how to make NLog write null instead of empty strings, but I wonder if you could make this work they way you want through additional configuration?
When are the logging parameters optional? Are there certain places in your code where you ALWAYS log some values and other places where you NEVER log some values? Can you (as the developer) know which optional parameters are applicable in which sections of your application?
Could you configure multiple Database Targets, each with the "right" parameters specified? You could then point Loggers to the specific Database Target that is appropriate for the code location.
Say that your application is divided (b
answered 2011-01-28T22:52:41.367