When writing to a datetime/datetime2 target, we use a fixed precision of three decimals to avoid needing to know the user-configurable precision of the datetime2 field.
However, when writing, we attempt to discover the target table column descriptions and pass these down to nanodbc via statement::describe_parameters. We do this to avoid (nanodbc) needing to call SQLDescribeParams for each of the individual columns/parameters when binding the data buffers.
If we already have the column descriptions, we could have nanodbc::statement expose these - see for example nanodbc::statement::parameter_size(int) that already does something similar. Then we can use this API endpoint in odbc_result to maybe deduce the parameter precision.
Related to: https://github.com/r-dbi/odbc/issues/790 https://github.com/r-dbi/odbc/issues/208 https://github.com/r-dbi/odbc/issues/130
When writing to a datetime/datetime2 target, we use a fixed precision of three decimals to avoid needing to know the user-configurable precision of the datetime2 field.
However, when writing, we attempt to discover the target table column descriptions and pass these down to
nanodbcviastatement::describe_parameters. We do this to avoid (nanodbc) needing to callSQLDescribeParamsfor each of the individual columns/parameters when binding the data buffers.If we already have the column descriptions, we could have
nanodbc::statementexpose these - see for examplenanodbc::statement::parameter_size(int)that already does something similar. Then we can use this API endpoint inodbc_resultto maybe deduce the parameter precision.