There has been a lot of discussion over whether to try to generate executable SQL as opposed to outputting the actual SQL that is sent. There are two approaches to executable SQL. The first is simple inlining of parameters. However, there is often value in seeing the parameters that are being used and it also could be confusing if we log different SQL than that which is actually sent. So we decided to not do this by default, but to instead create a different DbCommandLogger class that can be swapped in to do this.
(Another approach is to add comment lines that, when uncommented, would setup the parameters. This way you still get all the parameter information and the actual SQL that is sent to the database. However, this is not doable in a provider-agnostic way without considerable work, and may still not be possible for some providers. It would also produce very verbose output. So we are not doing this for now.)
(Another approach is to add comment lines that, when uncommented, would setup the parameters. This way you still get all the parameter information and the actual SQL that is sent to the database. However, this is not doable in a provider-agnostic way without considerable work, and may still not be possible for some providers. It would also produce very verbose output. So we are not doing this for now.)