I want attach my local MS SQL db to www.godaddy.in server can anyone suggest me how i can attach my db. Or how i can connect my sql server 2008 studio management to www.godaddy.in server. when i'm trying to connect my sql server studio management to www.godaddy.in server it's not connect showing Error
(Provider: Named Pipes Provider, error:40, and microsoft sql server error 53)
https://social.technet.microsoft.com/wiki/contents/articles/2102.how-to-troubleshoot-connecting-to-the-sql-server-database-engine.aspx
http://blog.sqlauthority.com/2009/05/21/sql-server-fix-error-provider-named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server-microsoft-sql-server-error/
http://blogs.msdn.com/b/walzenbach/archive/2010/04/14/how-to-enable-remote-connections-in-sql-server-2008.aspx
https://stackoverflow.com/questions/11278114/enable-remote-connections-for-sql-server-express-2012
Short Answer
Check Firewall
Check Service is Running
Check TCP/IP is Enabled
Check SQL Server Properties "Allow Remote Connections"
Then Run these if Those Do not Resolve
Right-click on TCP/IP and select Properties.
Verify that, under IP2, the IP Address is set to the computer's IP address on the local subnet.
Scroll down to IPAll.
Make sure that TCP Dynamic Ports is blank.
Make sure that TCP Port is set to 1433.
If you have a named instance then you must have the SQL Server Browser Service enabled
The browser service runs on port UDP 1434 and this must be allowed through your firewall
Hail Mary Pass if this is Still not Resolved
Go to the client machine, and run cliconfg.exe If named pipes is listed first, demote it, and promote TCP/IP.
check if the firewall is blocking the named pipes port, which usually is 445
Related
We have setup where our applications are hosted in Azure Virtual Machine, and our Databases are hosted in SQL Managed instance. Both are in same region, same subscriptions, but different Vnet as is the requirement of SQL Managed Instance.
We have whitelisted the IPs, open the port on NSG of both VM and SQL Instance.
We are able to open SQL in SSMS, in the local machine as well as in the VM itself. But for some reason same server does not work when added in the connection string.
We have tried with both 1433 and 3342 ports.
We have tried proxy vs redirect
We have tried VNET Peering as well, But nothing seems to work, we always get below error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)'
Our applications are based on .Net.
We are moving our servers from on-premise to Azure.
Any help will be appreicated.
Thank you.
As both Virtual Machine and SQL managed instance are in different VNETs, we need to do VNET peering to allow the applications in the Virtual Machine to connect to SQL Server.
Now, we need to write NSG rules to allow Virtual Machine to connect to the SQL server through 1433, 3342 and 4022 ports.
Then your application in the virtual machine will be able to connect to the SQL server
To access the SQL server through public link, we have to whitelist the IP address of the virtual machine.
To access the SQL server through private endpoint, we need to host the private endpoint in the same VNET of the SQL server. Then through VNET peering, the application in the VM can access the SQL server.
I recently migrated a site to a new server and am now trying to replace the old domain by the new one using this tool suggested in the wordpress codex.
The SQL instance and the VM are both in the same region and are connected using a cloud sql proxy, however when I try and connect to the database via the searc-replace tool, I get connection refused:
EDIT:
The command used to start the sql proxy is the following:
localhost:/cloudsql/project-name:region:sql-instance-name
It is the same I use in the config file to connect the site to the db.
"Connection Refused" error occurs when an application attempts a TCP connection but there is either no service listening on the target address and port or a firewall rejecting the connection.
First, lets make sure you are connecting on the right port. Run sudo netstat -lntp and look for cloud_sql_proxy. For example you might see
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 71313/cloud_sql_pro
indicating cloud sql is listening on port 3306. If you saw this, you should change the port in your tool to 3306.
If netstat does not show any cloud_sql_proxy line, then it isn't listening on TCP. While TCP isn't always needed for MySQL, it looks like the tool your are using does need it. Make sure you start cloud_sql_proxy with -instances=<INSTANCE_CONNECTION_NAME>=tcp:3306
Second, lets make sure you are connecting on the right address. This should be localhost without :/cloudsql/project-name:region:sql-instance-name after.
If it still doesn't work after those two, use sudo iptables -L to look for firewall rules blocking the traffic. I believe it's unlikely that you have a firewall stopping local traffic, however.
An alternative to using the Cloud SQL Proxy is to connect directly to your instance. To do this:
Find the external IP address of the VM you are running the PHP tool on.
Grant access for that IP address to your SQL instance, with the instructions here
Because MySQL can have different username/password depending on where you connect from, ensure there is a username/password combo for host %. instructions here.
Use the tool, with the username/password from (3), port=3306 and host=the IP address of your SQL instance
When you are done, remove access from the IP address to your Cloud SQL instance.
I am communicating with a server behind Microsoft ForeFront and I am in need to connect to the Visual Studio Remote Debugger located on the server. My development computer is located outside of Microsoft ForeFront and therefor it is quite troublesome. So far I have managed to make the connection from Visual Studio on my machine outside forefront to the Remote Debugger on the server inside forefront. I can see in Remote Debugger Monitor that connection is successful. "DOMAIN\Jens connected" it says. The Visual Studio client is still waiting and after a while it complain "Unable to connect to the Visual Studio Debugging Monitor named Jens#SERVER. The Visual Studio Debugger on the target computer cannot connect back to this computer"
To set this all up so far I have tried to tunnel the remote debugger connection using Putty.
I have set up Putty to connect to a linux-server outside the Microsoft Forefront network. In Putty I have set up the following forwards (123.123.123.123 is the linux-server outside ForeFront):
4R123.123.123.123:135 localhost:135
4R123.123.123.123:137 localhost:137
4R123.123.123.123:138 localhost:138
4R123.123.123.123:139 localhost:139
4R123.123.123.123:445 localhost:445
This part works great. I can access all these ports from my development machine and as I wrote earlier Visual Studio can even connect. I have set up a local administrator on my development computer and on the server with the same username and password and I run both Visual Studio and the Remote Debugger using this user.
Now my theory here is that the Remote Debugger on the server wants to make a TCP connection back to my development computer to send a reply to Visual Studio and I guess my connections from visual studio to the remote debugger on the server would look like they have originated from localhost. I therefore guess that the Remote Debugger will try to connect to origin (localhost) and try to send the reply there.
Does this make sense? If so, is there a way I can spoof this connection as coming from the actual IP address of my computer? If that is possible maybe I can trick the Remote Debugger to connect to the right place?
If I have explained this in a bad way, please ask me and I will do my best to clarify.
Ok, I have now found a simple solution to this. I installed OpenVPN server on a VMWare virtual machine on my development box. So I now have tree machines.
My development machine
The server in need of debugging
A new OpenVPN server (virtual)
I then opened up port 443 in my firewall towards the OpenVPN machine and next I installed the OpenVPN client on both the server in need of debugging and on my development machine and connected both to the OpenVPN server.
I had to configure OpenVPN so that I had 2 different users (one for each client) and I also had to enable cross-user communication on the VPN. I just had to add the IP submet of the VPN to the allowed private network list.
One last bit was to add an entry in the C:\Windows\System32\drivers\etc\hosts file pointing the server name to the vpn ip address (you have to connect to remote debugger with correct server name)
I have SQL server running on a legacy Windows 2003 box on IP address 192.168.2.240. There seems to be a reference to the server with some old connection strings for a web application. I'm merely using it for comparison purposes because we just upgraded to Windows Server 2008, .NET 4.0 and Enterprise Library 5.0. The server is referenced with "SQL01" not the IP address. On the network where this IP address resides, I can ping "SQL01", but when I VPN to that network, I cannot. Why wouldn't this work over a VPN? This is a legacy server, and I don't know how it was setup. If anyone can explain where this name is configured, and how I can connect (or ping) "SQL01" instead of using the IP address, I'd like to be enlightened.
Try looking in your hosts file.
I'm trying to connect from my ms windows 7 via the odbc administrator to a remote
sybase sqlanywhere 11 database server.
But I get not connection, I'm not sure which configure option I have to specify.
server-name = ip address of remote database server?
startline ?
portnummer ?
Thank you, best regards, Alex
By default the SQL Anywhere server process dbsrv#.exe listens for incoming connections on port 2638.
Make sure your firewall allows outbound connections to that port.
Assuming you have a database running on your server as follows:
-x tcpip
-n my_server_name
"[DIR]\database_main_file.db" -n my_database_name
The server will broadcast on the tcp/ip layer on the default port (2638) under the name "my_server_name" and the database will be accessible under the name "my_database_name" via ODBC
Creating an ODBC entry for your new database to connect from a client (adjust for Windows 7)
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\myodbcentry]
"Driver"="C:\\PROGRA~1\\SQLANY~1\\Bin32\\dbodbc11.dll"
"DatabaseName"="my_database_name"
"ServerName"="my_server_name"
"LINKS"="TCPIP(IP=SERVER_IP_ADDRESS;PORT=2638)"
There are other parameters available for LINKS (HOST, etc). Take a look at http://dcx.sybase.com/index.html#1101en/dbadmin_en11/da-using-tcpip.html
I've seen some rare issues with UDP broadcast packets. See the docs at
http://dcx.sybase.com/1101en/dbadmin_en11/broadcastlistener-connection-conparm.html and check with your network administrator.
You can also use the dbping.exe utility to troubleshoot networking issues.
BTW, you may want to cross-post your question at http://sqla.stackexchange.com. It's full of SQL Anywhere buffs