Antonius222
Technical User
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:
Am I asking this because I am having a problem the SAP HANA ODBC driver for Linux, which does not use SQLGetPrivateProfileString and reads [tt]odbc.ini[/tt] directly. The unixODBC driver manager, however, stores odbc.ini in a directly that the HANA 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 HANA 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 unixODBC, 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:
It may come from any vendor (unixODBC, iODBC, HANA, Microsoft...), 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:
Am I asking this because I am having a problem the SAP HANA ODBC driver for Linux, which does not use SQLGetPrivateProfileString and reads [tt]odbc.ini[/tt] directly. The unixODBC driver manager, however, stores odbc.ini in a directly that the HANA 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 HANA 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 unixODBC, 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:
It may come from any vendor (unixODBC, iODBC, HANA, Microsoft...), and if its name differs from the standard one, a symbolic link should be created.
Am I right or SAP support?