I'm new to SqlServer, right now I have SqlLocalDb installed to work locally. Good, but I can see two connection strings typically and both works:
Data Source=(localdb)\v11.0;Integrated Security=true;
and
Server=(localdb)\v11.0;Integrated Security=true;
What exact difference is there between the two?
For the full list of all of the connection string keywords, including those that are entirely synonymous, please refer to the SqlConnection.ConnectionString documentation:
These are all entirely equivalent:
Data Source
Server
Address
Addr
Network Address
... There is no difference between Server and Data Source as they represent the same thing for SQL Server : the full name of the SQL Server instance with the syntax "MyComputerName\MyShortInstanceName" , potentially including the port used by the SQL Server instance to communicate.
Reference: http://social.msdn.microsoft.com/Forums/en/sqldataaccess/thread/7e3cd9b2-4eed-4103-a07a-5ca2cd33bd21
They are synonymous - you can use either one.
That is - as far as the framework is concerned, they are the same.
My favorite set up is one that doesn't contain any spaces. In the simplest form, one has to provide four values - the URL, the container, the user and the credential.
server
database
user (or uid)
password (or pwd)
So a connection string looks like this.
server=stuffy.databases.net;database=stuffy;user=konrad;password=Abc123(.)(.);
Related
I don't know much about databases - Sorry if the question seems silly.
I have sql server 2012 on my machine and i create simple database table.
I want to connect to this database table thru C# code.
So, I need to know my ConnectionString.
I don't understand the parameters of the ConnectionString.
I try to google it - but still didn't find any good explanation.
Anyone can please explain the connectionString fields ?
How to define the connectionString that i will be able to connect the local database ?
thanks
Your connection string should be as simple as like below
Data Source=.;Initial Catalog=DB_NAME;Integrated Security=True"
Where
Data Source=. means local database
Initial Catalog=DB_NAME means the database it will connect to
Integrated Security=True means it will use windows authentication (no user name and password needed; it will use logged in credential)
Take a look Here
(OR)
Search in Google with key term sqlconncectionstring which will fetch you many help.
EDIT:
You are getting exception cause Initial Catalog=DB_Name\Table_001. It should be Initial Catalog=DB_Name (only database name). Provide the table name in sql query to execute. Check some online tutorial to get more idea on the same.
You use . in data source only when you are connecting to local machine database and to the default SQL Server instance. Else if you are using different server and named SQL Server instance then your connection string should look like
using(SqlConnection sqlConnection = new SqlConnection())
{
sqlConnection.ConnectionString =
#"Data Source=Actual_server_name\actual_sqlserver_instance_name;
Initial Catalog=actual_database_name_Name;
Integrated Security=True;";
sqlConnection.Open();
}
In case you are using local machine but named SQL Server instance then use
Data Source=.\actual_sqlserver_instance_name;
Initial Catalog=Actual_Database_NAME;Integrated Security=True"
using System.Data.SqlClient;
Then create a SqlConnection and specifying the connection string.
SqlConnection myConnection = new SqlConnection("user id=username;" +
"password=password;server=serverurl;" +
"Trusted_Connection=yes;" +
"database=database; " +
"connection timeout=30");
Note: line break in connection string is for formatting purposes only
SqlConnection.ConnectionString
The connection string is simply a compilation of options and values to specify how and what to connect to. Upon investigating the Visual Studio .NET help files I discovered that several fields had multiple names that worked the same, like Password and Pwd work interchangeably.
User ID
The User ID is used when you are using SQL Authentication. In my experience this is ignored when using a Trusted_Connection, or Windows Authentication. If the username is associated with a password Password or Pwd will be used.
"user id=userid;"
Password or Pwd
The password field is to be used with the User ID, it just wouldn't make sense to log in without a username, just a password. Both Password and Pwd are completely interchangeable.
"Password=validpassword;"-or-
"Pwd=validpassword;"
Data Source or Server or Address or Addr or Network Address
Upon looking in the MSDN documentation I found that there are several ways to specify the network address. The documentation mentions no differences between them and they appear to be interchangeable. The address is an valid network address, for brevity I am only using the localhost address in the examples.
"Data Source=localhost;"
-or-
"Server=localhost;"
-or-
"Address=localhost;"-or-"Addr=localhost;"
-or-"Network Address=localhost;"
Integrated Sercurity or Trusted_Connection
Integrated Security and Trusted_Connection are used to specify wheter the connnection is secure, such as Windows Authentication or SSPI. The recognized values are true, false, and sspi. According to the MSDN documentation sspi is equivalent to true. Note: I do not know how SSPI works, or affects the connection.
Connect Timeout or Connection Timeout
These specify the time, in seconds, to wait for the server to respond before generating an error. The default value is 15 (seconds).
"Connect Timeout=10;"-or-
"Connection Timeout=10;"
Initial Catalog or Database
Initial Catalog and Database are simply two ways of selecting the database associated with the connection.
"Inital Catalog=main;"
-or-
"Database=main;"
I'm trying to build a connection string for a test environment that will connect to the local SQL Server instance on different machines. The purpose of this is so that a developer can checkout the code from TFS, build it, and run the testcases, connecting to his local DB. The problem is that different developer's machines may have different SQL Server setups. In particular, some may be running the full server, others may be running SQL Server Express.
I'm trying to right a utility routine that will take template connection string (e.g., Data Source=(local); Initial Catalog= myDB; Integrated Security=SSPI;) and modify the Data Source to work with the local server.
I've tried using SmoApplication.EnumAvailableServers() (returns an empty table, regardless of whether I user true or false parameters), and SqlDataSourceEnumerator.GetDataSources() (returns 2888 servers from the network, but none on the local machine), SQLCMD -L (returns nothing).
Any suggestions?
In the alternative, is there an easy way to tell whether a particular connection string will connect to a server (without waiting for it to timeout if it doesn't). If I could find the answer to that, I could try the likely suspects until I got one to work.
you might try to get the connection string as following:
Create a new blank file and name it test.udl.
Double click on it, and a "Data Link Properties" dialog should appear.
On "Providers" tab, select "Microsoft OLE DB Provider for SQL Server" or "SQL Native Client"
On "Connections" tab, try various settings and use the "Test Connection" button to test them. Click "Ok" when it works.
Open the test.udl file in Notepad and copy the line that starts with "Provider=" into your Web.config "ConnectionString" value, BUT delete the little part that says "Provider=SQLNCLI.1;"
If you want each developer to work with their own local SQL server, then the ADO connection string should have the Data Source set to localhost
... ; Data Source=localhost; ...
Additionally, to get a list of current servers, go to the command line and run
osql -L
You can look in the registry to find all local SQL Server instances. This key contains the list: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL.
Each named instance will have a value in this key. For named instances the name of the value is the same as the name of the instance. For the default instance the value will be named MSSQLSERVER.
This will do the trick:
Data Source=.\SQLEXPRESS
I have a legacy VB6 app where the servername, databasename, username, etc are defined in an INI file, but the port number for the connection string (the default 1433) is hard coded in the app. It's being moved to a new sql server back end that runs off a different port number. I'm trying to avoid having to alter and recompile the application which entails signifigant retesting, documentation, etc. I tried altering the INI file so that for the new server I have put in: SERVERNAME\INSTANCE,NEWPORTNUMBER
This effectively builds the connection with Data Source = SERVERNAME\INSTANCE,NEWPORTNUMBER,1433;
This appears to work correctly as it connects to the database when I run the app. It appears to me that the ,1433 portion is being ignored. Is this a valid assumption or will this cause me some problem I'm not seeing here?
EDIT: The string way the connection string is built in the VB6 code is:
ConnectString = "Provider=MSDataShape;Trusted_Connection=Yes;Data Source=" & SERVER & ",1433;Initial Catalog=" & DATABASE & ";Data Provider=SQLOLEDB.1;Extended Properties=""Network=DBMSSOCN"""
with the SERVER & DATABASE values pulled from the INI file.
Port 1433 would normally override the INSTANCENAME. (MS blog Reference and another)
3 options I see:
The instance name is being ignored, and you're connecting to the default instance on port 1433
The named instance listens on port 1433
You have a client alias (not convinced about this one)
Can we see the code that creates the connection string?
Is there a network reason you need to use TCP/IP to connect to sql server?
My guess is that you just need to include a ; after the servername/instance name and just leave the port number out altogether. This will cause the port number to be extraneous data in the connection string. Which I think is just ignored. You can test creating an connection string yourself by creating a test.udl file and double clicking it - follow the wizard. After your done the connection string is in the udl file which you can view with notepad.
And of course if you are looking for the syntax for connection strings, you can look them up on connectionstrings.com
Download a free HEX editor
Save a copy of your original exe somewhere
safe
Open the exe in the HEX editor
Find the 1433 and change it to your
new port number
Once it works, you don't have to retest everything (like you would on a recompile)
If the new port number is not four digits it is trickier (path of least resistance: change it to a four digit port)
I have changed connection strings this way in the past.
A VB6 exe always uses DBCS so you may have to play with the hex editor until you figure out how to use the search feature in the right way.
If the port number is stored as an integer it may be trickier to find, but still possible (look for strings near it for your clues).
Apparently this app is quickly hacked together. Try to hack it back with a simple connect-string-injection like SERVER="{your_server},{your_port};FooBar="
I'm not sure that every library that uses the connection string would necessarily parse it the same way. I would think there could be one library that parses that connection string and just drops off the last port number and another that throws an error for an invalid port number perhaps. What libraries are using that connection string?
If you're using integrated security, then maybe you could set the Data Source in the INI file to say,
SERVERNAME,PORT; Password=
and let the SQL server ignore the Password key, which is unused with integrated security. That is if the code that constructs the connection string doesn't check for stuff like that. Oh, Will Rickards said this already also it seems.
Every SQL Server connection string I ever see looks something like this:
Data Source=MyLocalSqlServerInstance;Initial Catalog=My Nifty Database;
Integrated Security=SSPI;
Do I need the Initial Catalog setting? (Apparently not, since the app I'm working on appears to work without it.)
Well, then, what's it for?
If the user name that is in the connection string has access to more then one database you have to specify the database you want the connection string to connect to. If your user has only one database available then you are correct that it doesn't matter. But it is good practice to put this in your connection string.
This is the initial database of the data source when you connect.
Edited for clarity:
If you have multiple databases in your SQL Server instance and you don't want to use the default database, you need some way to specify which one you are going to use.
Setting an Initial Catalog allows you to set the database that queries run on that connection will use by default. If you do not set this for a connection to a server in which multiple databases are present, in many cases you will be required to have a USE statement in every query in order to explicitly declare which database you are trying to run the query on. The Initial Catalog setting is a good way of explicitly declaring a default database.
I need to convert a named instance of SQL server 2005, to a default instance.
Is there a way to do this without a reinstall?
The problem is, 2 out of 6 of the developers, installed with a named instance. So its becoming a pain changing connection strings for the other 4 of us. I am looking for the path of least resistance to getting these 2 back on to our teams standard setup.
Each has expressed that this is going to be, too much trouble and that it will take away from their development time. I assumed that it would take some time to resolve, in the best interest of all involved, I tried combing through configuration apps installed and didn't see anything, so I figured someone with more knowledge of the inner workings would be here.
I also wanted to convert a named instance to default - my reason was to access it with just the machine name from various applications.
If you want to access a named instance from any connection string without using the instance name, and using only the server name and/or IP address, then you can do the following:
Open SQL Server Configuration Manager
Click SQL Server Network Configuration
Click Protocols for INSTANCENAME you want to make available (i.e. SQLExpress)
Right-click TCP/IP and click Enabled
Right-click TCP/IP and go to Properties
Go to the IP Addresses tab
Scroll down to the IPAll section
Clear the field TCP Dynamic Ports (i.e. empty/blank)
Set TCP Port to 1433
Click Ok
Go to SQL Server Services
Right-click your SQL Server (INSTANCENAME) and click Restart
This will make the named instance listen on the default port. Note : You can have only one instance configured like this - no two instances can have same port on the IP All section unless the instance is a failover cluster.
As far as I know, no. One reason is the folder structure on the hard drive; they will have a name like MSSQL10.[instancename]
This is why a lot of companies store their applications' connection strings at the machine level instead of the application level.
Just take the connection string out of the source code entirely. Then have everyone put their connection string in their machine.config.
This has the added benefit of avoiding unnecessary app-specific environment logic, i.e. when you copy your application to the staging server, the staging server already "knows" what database to use.
The only way to change the instance name is to re-install - uninstall and install as default instance.
A lot of times I'll use client alias to point an application at a different sql server than the ones it's connection string is for, esp. handy when working on DTS or an application with a hard coded connection string. Have everybody use a commonly named alias, use the alias in the connection string and point the alias’s on each dev box to the to the different instances. That way you won't have to worry about if the server is the default instance or not.
You shouldn't ever really need to do this. Most software that claims to require the default instance (like Great Plains or Dynamics) doesn't actually.
If you repost with your situation (installed X, then Y, but need to accomplish Z) I bet you'll get some good workarounds.
I think you can migrate your data from Sql Server without having default instance installed. You can just specify the port number of your Sql Server instance in Oracle Sql Developer and you can connect just using the server name, not using the server name and the instance.
Like this:
connect to "MYSERVER, 1433"