TCP/IP connection to the server failed
I've been trying to connect to SQL server located in my local pc (I'm using Virtual Machine for DSS), server name is PC-NAME, server type is database engine, I'm using SQL Server Authentification,login and password .
When Ive tried to test the connection between DSS and my dataset I got this error, anyone has faced this kind of error before ?
Best Answer
-
dima_naboka Dataiker, Dataiku DSS Core Designer, Dataiku DSS & SQL, Dataiku DSS Core Concepts Posts: 28 DataikerHi, first of all you need to make sure DSS VM can access Host with provided hostname. If you can’t “ping” DESKTOP-H6PRTQG you might want to try using IP address instead. If you are running VirtualBox with default NAT mode, it is likely that your VM IP is 10.0.2.15 and your host IP is 10.0.2.2. More on VirtualBox Network Settings hereOnce you made sure that host is accessible from VM you need to review SQL Server TCP/IP properties. By default, listening on static ports are not enabled afaic. You can enable one of IP0-IP9 listening ports or enable IPAll, click Apply and restart SQL Server SQL Server service to apply the change. More on that in Microsoft docs
Answers
-
I turned off the firewall on my Windows , and made sure the TCP port is 1433, still same error
-
I had to add an exception for port 1433 in inbound connections from firewall settings , thank you!
-
Also configured the VM network settings from NAT to Bridged adapter
-
tgb417 Dataiku DSS Core Designer, Dataiku DSS & SQL, Dataiku DSS ML Practitioner, Dataiku DSS Core Concepts, Neuron 2020, Neuron, Registered, Dataiku Frontrunner Awards 2021 Finalist, Neuron 2021, Neuron 2022, Frontrunner 2022 Finalist, Frontrunner 2022 Winner, Dataiku Frontrunner Awards 2021 Participant, Frontrunner 2022 Participant, Neuron 2023 Posts: 1,601 Neuron
For which firewall did you make these changes. The Hosting Operating System that had the SQL Server, or the guest operating system where DSS is hosted? Or was there some other Firewall involved in this setup.
My guess is that this was an inbound rule for the Host Operating System with the SQL server.
-
Your guess is 100% correct. it was the host's firewall (inbound rule) where SQL Server is running.