locked
ODBC: must the driver use SQLGetPrivateProfileString? RRS feed

  • Question

  • Hello, all

    Having found no section devoted to ODBC in general, I
    consulted at "Where is the forum for..." and decided to post
    my question here.

    Is an ODBC provider required to use the
    SQLGetPrivateProfileString function to acquire the
    connection parameters, or may it locate and read the
    odbc.ini file directly?

    The documentation for SQLGetPrivateProfileString 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

    It says that:

       Calls to GetPrivateProfileString that retrieve a profile
       string from the Odbc.ini file should be replaced with
       calls to SQLGetPrivateProfileString.

    Does the `should' indicate a recommendation rather than a
    requirement?  Am I asking this because I am having a problem
    the SAP HANA ODBC driver for Linux, which does not use
    SQLGetPrivateProfileString and reads odbc.ini 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, odbc.ini where the
    HANA driver expects to find it.  Antoher work-around is via
    the ODBCINI enviroment variable, which both driver manager
    and driver respect, but I prefer the to follow the standard.

    Since it is precisely the problem that
    SQLGetPrivateProfileString 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
    `odbcinst', which corresponds to libodbcinst.so 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 (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?


    Anton Shepelev via Community Forums NNTP Bridge

    Tuesday, March 5, 2019 5:15 PM

Answers

  • NALUTO:

    Your problem seems to have little to do with sql server

    Dedmon Dai:

    This forum is for sql server,ЪI suggest you go to the
    correct forum to ask questions.

    As I have said above, I failed to find the correct MSDN
    forum, and this one was recommended to me instead.  See my
    question at "Where is the Forum For...?":

    https://preview.tinyurl.com/y2c9ggbf

    If you know a better place for my question, I will be
    grateful for your advice.


    Anton Shepelev via Community Forums NNTP Bridge

    Wednesday, March 6, 2019 4:43 PM

All replies

  • I wrote:

    The documentation for SQLGetPrivateProfileString describes
    what it does but is silent as to whether it is the only
    legal way for a driver to read its DSN information
    [...]
    It says that:

      Calls to GetPrivateProfileString that retrieve a profile
      string from the Odbc.ini file should be replaced with
      calls to SQLGetPrivateProfileString.

    Does the `should' indicate a recommendation rather than a
    requirement?

    Please, ignore.  I misread the sentence.  It has nothing to
    do with direct access to odbc.ini from the driver.


    Anton Shepelev via Community Forums NNTP Bridge

    Tuesday, March 5, 2019 5:28 PM
  • Your problem seems to have little to do with sql server
    Wednesday, March 6, 2019 7:03 AM
  • Hi Anton,

    This forum is for sql server,  I suggest you go to the correct forum to ask questions.

    Best regards,

    Dedmon Dai



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Wednesday, March 6, 2019 7:28 AM
  • NALUTO:

    Your problem seems to have little to do with sql server

    Dedmon Dai:

    This forum is for sql server,ЪI suggest you go to the
    correct forum to ask questions.

    As I have said above, I failed to find the correct MSDN
    forum, and this one was recommended to me instead.  See my
    question at "Where is the Forum For...?":

    https://preview.tinyurl.com/y2c9ggbf

    If you know a better place for my question, I will be
    grateful for your advice.


    Anton Shepelev via Community Forums NNTP Bridge

    Wednesday, March 6, 2019 4:43 PM
  • I am  familiar with the sql server problem, sql server, I don't know much about your problem, so I can't provide a suitable forum.
    Friday, March 8, 2019 9:49 AM