The parameter encoding of the function dbConnect() is currently described as:
The text encoding used on the Database. If the database is not using UTF-8 you will need to set the encoding to get accurate re-encoding.
See iconvlist() for a complete list of available encodings on your system. Note strings are always returned UTF-8 encoded.
However, the encoding is actually the one used by the odbc driver (via nanodbc) for communication, and is therefore independent of the database. More precisely, since in this package nanodbc was compiled without the flag NANODBC_USE_UNICODE, all connections are established in A mode and not in W mode. Thus, the encoding is almost entirely dependent on the client OS.
I would therefore suggest changing the documentation to:
The text encoding used by the odbc driver. If it is not using UTF-8 you will need to set the encoding to get accurate re-encoding.
The chosen encoding depends on the system locale. See iconvlist() for a complete list of available encodings on your system.
Note strings are always returned UTF-8 encoded.
In addition, I would suggest giving the parameter encoding a default of the form
if(.Platform$OS.type == 'windows') 'Latin-1' else 'UTF-8'.
The parameter
encodingof the functiondbConnect()is currently described as:However, the encoding is actually the one used by the odbc driver (via nanodbc) for communication, and is therefore independent of the database. More precisely, since in this package nanodbc was compiled without the flag
NANODBC_USE_UNICODE, all connections are established in A mode and not in W mode. Thus, the encoding is almost entirely dependent on the client OS.I would therefore suggest changing the documentation to:
In addition, I would suggest giving the parameter encoding a default of the form