Must the driver use SQLGetPrivateProfileString?
Must the driver use SQLGetPrivateProfileString?
(OP)
Hello, all
Is an ODBC provider required to use the [tt]SQLGetPrivateProfileString[/tt] function to acquire the connection parameters, or may it locate and read the [tt]odbc.ini[/tt] file directly?
The documentation for [tt]SQLGetPrivateProfileString[/tt] describes what it does but is silent as to whether it is the only legal way for a driver to read its DSN information:
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetprivateprofilestring-function
Am I asking this because I am having a problem the [i]SAP HANA ODBC driver[/i] for Linux, which does not use SQLGetPrivateProfileString and reads [tt]odbc.ini[/tt] directly. The [i]unixODBC[/i] driver manager, however, stores odbc.ini in a directly that the [i]HANA[/i] driver does not search, so they don't work well together without such dirty tricks as having an extra copy of, or a symbolic link to, [tt]odbc.ini[/tt] where the [i]HANA[/i] driver expects to find it. Antoher work-around is via the [tt]ODBCINI[/tt] enviroment variable, which both driver manager and driver respect, but I prefer the to follow the standard.
Since it is precisely the problem that [tt]SQLGetPrivateProfileString[/tt] is intended to solve, I have reported it as bug in the driver, which SAP support refuse to acknowldge, on the ground that, to avoid dependency on [i]unixODBC[/i], their driver cannot link with any installer DLL. Whereas my understanding is that such a link introduces no such dependency, but only a contract enforced by the ODBC standard, because the installer DLL is specifed to be [tt]odbcinst[/tt], which corresponds to [tt]libodbcinst.so[/tt] on Unix, and must implement the installer DLL API:
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/installer-dll-api-reference-function
It may come from any vendor ([i]unixODBC[/i], [i]iODBC[/i], [i]HANA[/i], [i]Microsoft[/i]...), and if its name differs from the standard one, a symbolic link should be created.
Am I right or SAP support?
Is an ODBC provider required to use the [tt]SQLGetPrivateProfileString[/tt] function to acquire the connection parameters, or may it locate and read the [tt]odbc.ini[/tt] file directly?
The documentation for [tt]SQLGetPrivateProfileString[/tt] describes what it does but is silent as to whether it is the only legal way for a driver to read its DSN information:
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetprivateprofilestring-function
Am I asking this because I am having a problem the [i]SAP HANA ODBC driver[/i] for Linux, which does not use SQLGetPrivateProfileString and reads [tt]odbc.ini[/tt] directly. The [i]unixODBC[/i] driver manager, however, stores odbc.ini in a directly that the [i]HANA[/i] driver does not search, so they don't work well together without such dirty tricks as having an extra copy of, or a symbolic link to, [tt]odbc.ini[/tt] where the [i]HANA[/i] driver expects to find it. Antoher work-around is via the [tt]ODBCINI[/tt] enviroment variable, which both driver manager and driver respect, but I prefer the to follow the standard.
Since it is precisely the problem that [tt]SQLGetPrivateProfileString[/tt] is intended to solve, I have reported it as bug in the driver, which SAP support refuse to acknowldge, on the ground that, to avoid dependency on [i]unixODBC[/i], their driver cannot link with any installer DLL. Whereas my understanding is that such a link introduces no such dependency, but only a contract enforced by the ODBC standard, because the installer DLL is specifed to be [tt]odbcinst[/tt], which corresponds to [tt]libodbcinst.so[/tt] on Unix, and must implement the installer DLL API:
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/installer-dll-api-reference-function
It may come from any vendor ([i]unixODBC[/i], [i]iODBC[/i], [i]HANA[/i], [i]Microsoft[/i]...), and if its name differs from the standard one, a symbolic link should be created.
Am I right or SAP support?