Hopefully this will be an easy one.
I have several projects that use a Sql Server 2012 instance on one of our cloud servers. When I am developing on that server my connection string must be .\SERVER_NAME but when I am connecting to it remotely the connection string must be IP_ADDRESS, PORT_NUMBER. I sometimes forget to change the connection string from local to remote when I push to the production environment.
Is there a way to make both the local and remote connection string the same? Also is there a way to avoid having the port number in the remote address?
Any help would be much appreciated.
As for the port, the default SQL SERVER port is 1433, if that is the port you are sending then it isn't necessary. As for having one connectionstring or not changing the name you could do a couple of things I guess...
Here are some options:
Add a post deployment task where the correctly configured .config file is copied to the target.
Code machine specific connections, so both conn strings would be in the web/app .config and based on the runtime machine dictates what conn string you use.
Add an entry in your host file for the server, on dev it points to DEV Server while on the other sever it points to the other.
Not sure why you must use an IP address and not a name, you must not have any DNS?
Related
I am using SQL server express 2014. I used the below connection string as server name in SQL Express. but it failed.
[my servername],1433\SQLEXPRESS
In sql server 2012, I can connect the connection string in the format of [my servername],1433
Could you please anyone suggest how do I specify a port number in a connection string for SQL Express server?
First of all, if you did not change the port manually, SQLEXPRESS is NOT listening on 1433 that is reserved for default instance, it uses dynamic port that you can find in Configuration Manager or in SQL Server error log.
Here you can see both methods with pictures: Identify SQL Server TCP IP port being used.
Second, there is no need to specify instance name + port, in fact if you do it, instance name is effectively ignored, so when you use
[my servername]\SQLEXPRESS,1433
you'll try to connect to
[my servername],1433
That is because to connect to server you need to know it's address and port, so or you use
myServer,port
or you use
myServer\instanceName
In the first case the underlying network library has all information it needs to connect(IP + port). In the second case SQL Server Browser need to be started.
It's SQL Server Browser that will comunicate instance port given instance name.
When your connection string contains both instance name and port, only port is used and instance name is ignored, so if you use a wrong port, even with correct instance name you cannot connect.
put the port after the instance name, like:
[my servername]\SQLEXPRESS,1433
Have in mind that if SQL Express is the only SQL server in this PC you can also use:
[my servername],1433 or [serverIP],1433
I have two instances of SQL Server on my local machine. They both listen to separate ports. The first instance that I installed runs on the default port: 1433. I have set the other to listen to port 1434.
My application is using some old shared code that we have here to generate the connection string. So until now I didn't really know what was happening there. Due to a new requirement I found myself needing to examine the connection strings that I'm using to connect to the SQL Server.
What I found that was that for the connection string be built to connect to each of the SQL instances did not include Network Library, nor did they include the port number as part of the Data Source. The Data Source was just set to <Server Name>/<Instance Name>. I did find in the MS documentation that if the Network Library is not included then it is treated as (local), but it doesn't really explain how (local) is treated.
So my question is why is a connection string in this format able to connect to the SQL Server instance that runs on the non-default port? will this only work if the instances are on the local machine, or local network? Can I put <ip>/<sql instance> without the port if the server is remote?
I just need some clarity on how this works, and when is the port number needed and when it is optional as I'm trying to make my connection UI as simple as possible for our users.
There is such a thing called "SQL Server Browser Service":
http://technet.microsoft.com/en-us/library/ms181087(v=sql.105).aspx
It is intended to provide clients with information about sql server instances, ports. It actually listens on UDP port 1434.
With this service turned off you will still be able to connect to the instance, but you need to specify TCP/IP port.
I have two instances of SQL Server on my local machine. They both listen to separate ports. The first instance that I installed runs on the default port: 1433. I have set the other to listen to port 1434.
Just out of curiousity, why don't you just have them setup as named instances both running on the default of 1433 ?
As for why it works, if you search for SQL Configuration in your start menu, you'll find a screen similar to this.
Sql Server supports a number of different ways of connecting. TCP/IP is one way (ie IP addresses and ports) but it also supports a Shared Memory connection if you're on the local machine. that is, if you SQL Server executable, and management studio/client are also on the same machine.
At a guess I'd say it defaults to shared memory when you specify local and therefore you don't need to specify the port.
You could test this out by temporarily disabling shared memory in the above config, and see if your (local)\InstanceName stops working.
I'm new to SQL related matters so please bare with my lack of knowledge and asking a question which has been asked countless times before.
I have to connect to a SQL database server which is located at a remote location at xxx.xx.xxx.xx:3306, but every time I try to connect I get the same 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 - No connection could be made because the target machine actively refused it.)"
I get this same error whether I try to connect using SQL Server Management Studio or in a C# program via:
SqlConnection myConnection = new SqlConnection(...)
myConnection.Open();
I've tried it on two different computers, both on the same home network. I've had a look at the SQL server configuration manager on the computer which I installed SQL Server on, enabling TCP/IP and fiddling with the port values settings, but I'm guessing this is just for configuring an SQL server on my computer and irrelevant to connecting to a remote one. I shouldn't even need to install SQL server to do queries on a remote server anyway, right?
I've turned off my Windows firewall and my router firewall, though ShieldsUP still says
Port: 3306
Status: Stealth
Your system has achieved a perfect "TruStealth" rating. Not a single packet — solicited or otherwise — was received from your system as a result of our security probing tests. Your system ignored and refused to reply to repeated Pings (ICMP Echo Requests). From the standpoint of the passing probes of any hacker, this machine does not exist on the Internet. Some questionable personal security systems expose their users by attempting to "counter-probe the prober", thus revealing themselves. But your system wisely remained silent in every way. Very nice.
I read that this is irrelevant as well, since I'm not the one hosting the server, but when I was given the address, I was given the port as well, so I must have to do something with it. I'm just not sure what. My understanding of ports really is quite shaky.
I've been trying this for over a day now, and I can't think of anything more I can do.
EDIT: I fixed the problem. I had to use MySQL, not MSSQL. Doh. Sorry guys.
If you are sure the remote SQL Server is running on port 3306 (otherwise I'm not sure why you talked in the question about that port specifically), try the following connection string:
user id=username; password=password;
data source=123.45.678.90,3306;
initial catalog=dbname;
Network Library=dbmssocn;
I think without the port you'll have trouble if the other end has disabled the SQL Browser service. You should also make sure it isn't a named instance, in which case you may need:
user id=username; password=password;
data source=123.45.678.90\InstaneName,3306;
initial catalog=dbname;
Network Library=dbmssocn;
First of all the database is local or distant ?
The you have to ensure that your connection string is well written.
Here's an example of a valid connection string :
Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;
More about connection strings :
Connection Strings
Now if everything is set up correctly you have to enable remote connections to SQL Server on the host. To do so please refer to this article :
Enable SQL Server Remote Connections
Just go to ypur serveices and check whether your SQL Server (MSSQLSERVER) is running.Most of the time this error happens when SQL Server (MSSQLSERVER) is stopped.
Then select it right click and click start.problem solved !!!
I need to access an SQL Server that is on a machine behind a firewall and you access this machine using an ip address like 95.95.95.33:6930 (not the real ip address) ... But, you get my point that by accessing 95.95.95.33 on port 6930, the firewall routes the requests to that particular machine ...
My question is ... How do you construct a connection string to access the machine at address 95.95.95.33:6930 and then further access the SQL Server on port 1433 or maybe a different port like 8484 ???
Thanks
Mike
well, you build the connection string like this
"Server=95.95.95.33,6930;database=mydb;..."
the firewall/nat will have to route that to the correct machine/port of the SQL server for you.
All you should worry about is the public address and port number of the SQL server. It makes no difference to you to which internal machine and port number the connection is forwarded to.
You then build a connection string as described on connectionstrings.com:
Data Source=95.95.95.33,6930;Network Library=DBMSSOCN;Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;
DBMSSOCN=TCP/IP. This is how to use
TCP/IP instead of Named Pipes. At the
end of the Data Source is the port to
use. 1433 is the default port for SQL
Server.
I need to setup a JDBC connection string to SQL Server.
This question is similar to the the C# ADO.Net connection question. This one is specific to JDBC connection strings.
The usual format for the JDBC string is "jdbc:sqlserver://{host}:{port}".
Now, for a SQL server cluster I have a cluster name vvv\iii ({virtual server}{instance name}).
There's no problem setting up an ODBC connection through the "New Data Source to SQL Server" wizard when using the vvv\iii string as the server name. However it seems the JDBC connection string requires a specific host and port.
Is there a way to make a JDBC connect string to a SQL Server cluster?
it turns out that you can use the "instanceName" property within the JDBC string, as documented on the Microsoft Technet page in section "Named and Multiple SQL Server Instances". What worked in my case was the following string for virtual server vvv and database instance name iii:
"jdbc:sqlserver://vvv;instanceName=iii"
When using a SQL Server named instance in a cluster or stand alone environment each SQL Server instance is dynamically assigned a port number on startup. The SQL Server Browser server handles requests to each instance because each server restart could change the port number used by each instance. The first instance to start on a server reboot gets assigned 1433 but there is no guarantee if you have 2 instances that one of them will always get 1433. There are several veriables that affect the startup and recovery time it takes for an instance to start. This can change each time.
That being sad... when connecting to a named instance the jdbc connection string should look like this:
jdbc:sqlserver://server_name/db_name;instance=instance_name
rather than this
jdbc:sqlserver://server_name:1433/db_name;instance=instance_name
note that the default database "/db_name" is optional. If exclued the connection will use the default database assigned to the SQL Server login.
The cluster resource has a host name and a listening port. Use jdbc:sqlserver://{virtualserver}:1433 (or the appropriate listening port if not listening on the default one).
I'd comment Mark Stewart's remark, but the reputation is lacking. My source doesn't mention /db_name and I can't get it to work either. Maybe another case of confused instance names?
Make sure you leave the port definition off as the cluster determine this for you.
So my datasource definition looks like:
jdbc:sqlserver://sqlcluster_hostname\instancename;DATABASENAME=databasename;sendStringParametersAsUnicode=false;SelectMethod=direct
I ran into this issue while trying to setup a Railo datasource to connect to MSSQL cluster.
Slightly off topic ... The standard Railo datasource MSSQL driver option sets the port to "-1" if you leave the port field empty however if you set it to "0" then it removes the port definition altogether and then everything works. But the best way is to choose 'Other - JDBC Driver' to define the JDBC connection string in full as above.