That looks like the connection has timed out so the first thing I would do is check that the SQL Server is configured to accept connections from the host. It looks like you are using an instance name as well are you using full SQL or SQL Express? I know out of the box SQL Express doesn’t accept connections easily and you have to sometimes enable the TCP/IP setting in SQL Server Manager so that could be worth looking at as well.
Is there anything network wise going on? It is timing out after 15 seconds so it could be that it can’t find its way to the host or it is waiting for a response back.
There might be something in the console which you could see with the docker logs command, I do have a theory though if you are sure the network is all good the last 10% of cases I have seen over the years with that issue is down to the formatting for using an instance.
Just for fun can you try local_ip\\instanceName and also leaving the port empty and see if that works.
Everything looks fine in the compose file, What happened when you tried local_ip\\instanceName and an empty port?
I know you have said everything is correct and I suspect it probably is now, The connection is still timing out so it could still be that it is waiting for a response from the server or it can’t find the instance for some reason.
If you try with a hostname that is wrong or an incorrect username / password do you get a different error?
In the previous attempt, I left without the door, as you asked. This second screen with the door is from the previous attempt. But the first screen is without port set.
Empty Port and TDS to 7_4 instead of 7_3_B and see that does the job, I am working on setting up a SQL Server but the last one I tested on a few weeks back the node worked so I am fairly confident the node is fine.
What is really odd though is even with an invalid host you are getting the same error, I would have expected something like…
So is that 2019 and 2012 that fail and only 2008 that works? Did you try changing the TDS setting? I believe that option was recently added so that could be causing the problem.
Until yesterday we had no problems connecting from n8n to our SQL Server 2017. Then yesterday we upgraded n8n from 0.194 to 0.195.5. And our SQL Server connections are now not working anymore. After the timeout we get
ConnectionError: Failed to connect to 178.255.193.119:1433 in 15000ms
at /usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/node_modules/mssql/lib/tedious/connection-pool.js:78:17
at Connection.onConnect (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/node_modules/tedious/lib/connection.js:1051:9)
at Object.onceWrapper (node:events:628:26)
at Connection.emit (node:events:513:28)
at Connection.emit (node:domain:489:12)
at Connection.emit (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/node_modules/tedious/lib/connection.js:1079:18)
at Connection.connectTimeout (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/node_modules/tedious/lib/connection.js:1284:10)
at Timeout._onTimeout (/usr/local/lib/node_modules/n8n/node_modules/n8n-nodes-base/node_modules/tedious/lib/connection.js:1229:12)
at listOnTimeout (node:internal/timers:559:17)
at processTimers (node:internal/timers:502:7)
We had and still have TLS disabled. We connect to a server IP and port.
I’m not sure if OP still has problem, but it seems that something after 0.194 has caused SQL Server connections in some situations to stop working
Hi @christiaanwesterbeek, I just tried connecting to SQL Server 2017 without issues on both [email protected] and the current version 0.197.1 (I tried both hostnames and IPs). Is your firewall perhaps dropping these connection attempts? Are you using n8n cloud and have whitelisted its IPs on your end by any chance? If so, your whitelist might need an update (or better, replace it with other auth methods, see our docs for details).
Thank you. You maybe right since there was only 1 commit to the mssql node since 0.194 and that only changed the tdsVersion but the default isn’t any different than before.
It maybe so (I will ask) that our firewall only allows a few n8n IP addresses. That page you are referring to used to also present a range of IP addresses to whitelist, but that page is now updated and the range is gone. Google cache says:
Recommended practice is to whitelist 20.79.72.0/24 , but if more strict … 20.79.72.36 , and 20.79.227.226 must be whitelisted.
Short question, what range shall I ask the firewall guys to whitelist for n8n?
We just use the three IPs listed on the page, so need to specify a range. These IPs might change without notice though as n8n cloud scales up (and we can’t predict which IP a new NAT might get from Azure).