Can't open lib 'SQL Server Native Client 11.0' upgrading to 2.2.0

[flaviodelgrosso]

Hi, I'm on macOS 11.4 ARM64 and noticed that upgrading to version 2.2.0 when I try to connect it returns the following error:

ConnectionError: [unixODBC][Driver Manager]Can't open lib 'SQL Server Native Client 11.0' : file not found

Using the 2.1.0 I've not this problem. Anyone can suggest how to solve it?

Thanks in advance

[TimelordUK]

Can you try changing connection string so it is correctly named data source

Driver={ODBC Driver 17 for SQL Server}

We now communicate via ODBC manager so the driver must be exactly as installed

Sent from my iPad

On 6 Jun 2021, at 23:52, flaviodelgrosso @.***> wrote:

 Hi, I'm on macOS 11.4 ARM64 and noticed that upgrading to version 2.2.0 when I try to connect it returns the following error:

ConnectionError: [unixODBC][Driver Manager]Can't open lib 'SQL Server Native Client 11.0' : file not found

Using the 2.1.0 I've not this problem. Anyone can suggest how to solve it?

Thanks in advance

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[flaviodelgrosso]

Can you try changing connection string so it is correctly named data source Driver={ODBC Driver 17 for SQL Server} We now communicate via ODBC manager so the driver must be exactly as installed …

Thanks for you reply! @TimelordUK

I tried to use actually this:

const pool = new ConnectionPool({
        driver: 'ODBC Driver 17 for SQL Server',
        server: host,
        user,
        password,
        port: parseInt(port, 10),
        options: {
          enableArithAbort: true,
          trustedConnection: winauth === 'Y',
          trustServerCertificate: true,
        },
      });

If the driver key/value is syntactically correct, it's not working for me. It returns the same error.

[TimelordUK]

are you using node-mssql? if you are i think it places the Driver={SQL Server Native Client 11.0} in the connection string - this will no longer work.

you can try importing the library directly in a test program such as

const query = 'SELECT * FROM syscomments'

sql.open(connectionString, function (err, con) { if (err) { console.log(failed to open ${err.message}) } let d = new Date() con.query(query, function (err, rows) {

On Mon, 7 Jun 2021 at 09:31, flaviodelgrosso @.***> wrote:

[flaviodelgrosso]

are you using node-mssql? if you are i think it places the Driver={SQL Server Native Client 11.0} in the connection string - this will no longer work. you can try importing the library directly in a test program such as const query = 'SELECT * FROM syscomments' sql.open(connectionString, function (err, con) { if (err) { console.log(failed to open ${err.message}) } let d = new Date() con.query(query, function (err, rows) { On Mon, 7 Jun 2021 at 09:31, flaviodelgrosso @.***> wrote:

Yes I'm importing node-mssql as const { ConnectionPool } = require('mssql/msnodesqlv8');

So the problem is related to this actually. Thanks for your explanation

[TimelordUK]

you could try configuring a new source named the missing driver as above but pointing to odbc17 - I have not tried this but should work ok. ODBC manager simply needs to map the name given in driver to the shared library to load. It needs to know how to map the 'SQL Server Native Client 11.0' which could be added into data sources

[flaviodelgrosso]

you could try configuring a new source named the missing driver as above but pointing to odbc17 - I have not tried this but should work ok. ODBC manager simply needs to map the name given in driver to the shared library to load. It needs to know how to map the 'SQL Server Native Client 11.0' which could be added into data sources

Yes that's working, thank you!

[SixBytesUnder]

@flaviodelgrosso I'm having the same issue, can you share how you fixed it? Everything worked just fine when I was on a version 2.0.5. few days ago I updated to 2.4.0 and suddenly I'm getting ConnectionError: [unixODBC][Driver Manager]Can't open lib 'SQL Server Native Client 11.0' : file not found. I'm on CentOS 8 using Node v12.18.3

How do you configure a new source and what do I enter as value for "driver"?

  const config = {
    user: process.env.AX_USERNAME,
    password: process.env.AX_PASSWORD,
    server: process.env.AX_SERVER,
    database: process.env.AX_DATABASE,
    driver: 'msnodesqlv8'
  };
  sql.connect(config).then((pool) => {
    ...
  });

Above worked fine in 2.0.5, but fails in 2.4.0

$ odbcinst -j

unixODBC 2.3.7
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/ecom/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8

$ cat /etc/odbcinst.ini

[ODBC Driver 17 for SQL Server]
Description=Microsoft ODBC Driver 17 for SQL Server
Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.8.so.1.2
UsageCount=1

EDIT: For anyone who has the same issue, I was able to resolve this by simply duplicating the contents of the /etc/odbcinst.ini file and just changing the name in brackets to the value the error message quoted. My end file looks like this:

[ODBC Driver 17 for SQL Server]
Description=Microsoft ODBC Driver 17 for SQL Server
Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.8.so.1.2
UsageCount=1

[SQL Server Native Client 11.0]
Description=Microsoft ODBC Driver 17 for SQL Server
Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.8.so.1.2
UsageCount=1

And everything works as normal again.

[TimelordUK]

thnaks for update I will add to the Wiki - preveiously msnodesqlv8 linked directly to the MS driver, now we link to ODBC which manages all communication to the database, hence ODBC does need this entry mapping. Exactly as you worked out above.

[TBG-FR]

I tried updating /etc/odbcinst.ini with a duplicate entry as shown above, and now I got a Segmentation Fault everytime my program tries to call the driver...

Debian 10 (Docker) with Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.9.so.1.1

[TimelordUK]

If you run a little test node program via gdb

Gdb open node Run test.is

and look at full backtrace

you will likely find it fails in ssl.

This is due to version of ssl installed not working correctly.

There are other issues raised on this

I have found if I install the brew versions and ensure they are loaded instead of default installed it will work but first we need to see if core dump stack trace is indeed ssl I seem to remember it is in open invoked by the ms driver.

[TimelordUK]

something along these lines

cd /usr/lib
sudo rm libssl.so.1.1
export LD_PRELOAD=/home/linuxbrew/.linuxbrew/opt/[email protected]/lib/libssl.so.1.1
sudo ln -s /home/linuxbrew/.linuxbrew/opt/openssl@3/lib/libssl.so  libssl.so.1.1
ls -l /lib/x86_64-linux-gnu/libssl.so.1.1
cd /lib/x86_64-linux-gnu/
ls -alrt
sudo rm libssl.so.1.1
sudo ln -s /home/linuxbrew/.linuxbrew/opt/openssl@3/lib/libssl.so  libssl.so.1.1
ls -l /lib/x86_64-linux-gnu/libssl.so.1.1