I currently have a SQL Server 2005 instance installed on my local machine, and at the time of installation I named the instance 'localhost\sql05'
Can I easily change this to just 'localhost'
From what I can tell, the best option is to simply install the instance with the name you would like, move the DB's over, and then remove the instance you want to replace. While the link to CodeJournal seems promising, I don't believe it will yield positive results.
http://www.coderjournal.com/2008/02/how-to-change-instance-name-of-sql-server/
Also see this post (duplicate here on SO)...
https://stackoverflow.com/questions/907851/change-sql-server-instance-name
The only way to rename an instance is to uninstall it and re-install it under the correct instance name. Tricks that try to work around the name like creating an alias or making the named instance listen on the default port but they sometimes work sometimes don't, and they can fail in seemingly random manner, eg. due to the SPN (Service Principal Name) requested by the client during authentication.
Related
I have imported data to SQL Server Express from MS Access and have tried to link to the data from an Access front end file.
I have tried several different login types, but each gives me the same error:
Error Locating Server/Instance Specified
Please help.
Assuming a local instance of SQL server?
The default is usually YOURCOMPUTERNAME\SQLEXPRESS.
But, you can use a "." (dot) in place of your computer name.
So, the server name should be .\SQLEXPRESS
A few things:
When you setup and attempt to connect? Always create a FILE dsn. The reasons for this are many, but one really nice reason is that then Access will by default create a DSN-LESS connection. This approach is preferred since then Access remembers the settings, and no external settings (such as registry or even a file (dsn) is used or required. And if you connect to a SQL server on your network? Well then you can distribute the access application to each workstation, and it will "just work" - all without you having to setup a DSN or do anything with the ODBC manager on each station. So, a great tip and habit. So, use a FILE dsn (and if you follow the default prompts when linking tables, a FILE dsn is the default anyway).
Next up:
Make sure the sql server browser service is running. In the past this was often not required, but now it is recommended. That service is this:
Once you sure that service is running?
Make sure that you enabled named Pipes - in fact I would also enable TCP/IP. That is found here:
Ok, now the next question:
Are you using SQL server logons, or Windows authentication?
For now since this is your local stand alone machine? lets go with windows.
As noted, if you have SSMS installed, then see if it can connect. This not only is a quick + easy fast test but it will also tend to give you the hints as to what the server name connect is. (this helps you when you attempt to connect with Access - you can see what worked with SSMS - and better is SSMS does usually figure out the correct computer name for you.
So, from Access, you now choose from ribbon "External" data, and then import and link group - choose ODBC.
the wizard to connect will start. choose "link to the data source".
At this point, the panels that start to launch are the same one you see if you try to use the ODBC manager from the control panel - but in most cases this road is better, since Access will correctly launch the x32 or x64 bit ODBC manager (it makes this correct decision for you).
So you be at a DSN name, but just hit new. Now you have to choose a ODBC (for sql server) driver.
For now, I would try "SQL server". You can choose SQL Server Native Client 11 (or later if you see). Either one is fine. Just keep in future mind that SQL Server driver choice exists on all computers - so for future distribution to other workstations, this is a good choice. The native 11 (or later) driver is NOT installed by default, and you have to install this on other workstations if you want to use that driver if you move or distribute your application to other workstations.
Next, and now you can enter a name for this connection (myTestcon or whatever). Hit finish.
You should now see/be at this screen:
The dropdown for the server name SHOULD appear and work (it make take 30 seconds). So, it should show you a server name, and a sql instance.
Next, and now you have to choose the type of logon
Because this is a local stand alone computer? Well, you can choose windows logons, or sql logons. Being a local computer - choose the default - windows auth.
Next.
NOW VERY VERY important - make sure you change/select the correct database here - SO MANY skip or miss this - and that's painful!!
This one:
So make sure you select/change the default from "master" to your database you created when you sent the data to sql server.
Next - (you can try the test data source). "ok".
Now you are back to the VERY same starting panel. Your "name" should be defaulted for the file connection. This:
So, now just click ok.
You can then select the tables you want to link to.
This seems to be a fairly common question, but none of the answers I've seen have been particularly satisfactory. I want to get a list of the names of the MS SQL Server instances installed on the local machine, regardless of whether they're started or not. For the purposes of this discussion, I'm OK with just finding instances of SQL 2005 and newer; I can handle 2000 and earlier using "legacy" methods (i.e., look in the registry). What I do require is that it not be dependent on the SQL Server Browser service (it's disabled by default nowadays), and that 64-bit instances are returned even when the app is 32-bit.
Suggestions I've seen:
Dig through the registry: Supposedly Not recommended due to the registry entries being undocumented; MS may change them in the future. More importantly, as far as I can tell, 64-bit instances of MSSQL go in the 64-bit HKLM\SOFTWARE\Microsoft\Microsoft SQL Server InstalledInstances, and 32-bit instances go in the 32-bit one, so a 32-bit app won't see any 64-bit instances.
Use the SQL WMI Provider for Configuration Management mentioned in the previous blog post. This seems to be the closest, but despite the author's admonition to avoid using the registry because it might change, it turns out the WMI namespace changed between SQL 2005 and 2008: in 2005, it's root\Microsoft\SqlServer\ComputerManagement, but in 2008 it's root\Microsoft\SqlServer\ComputerManagement10. Will it change again in the future? That said, it's probably not a huge issue if I have to update my app for a future version of SQL.
The problem I have with the WMI method is that the SqlService class returns a list of the service names, whereas I want the instance names. E.g., instead of MSSQL$INSTANCE, I just want INSTANCE. Stripping off the "MSSQL$" is trivial, as is handling the special case of the default instance, but is it reliable? AFAIK, there's technically no reason why the service couldn't be renamed, while keeping the instance name the same. That said, unless someone has a better method, I think I'll go with that (get the service names and strip off the MSSQL$). The ServerSettings class returns the instance name, but it doesn't see a 64-bit instance of SQL 2008 R2 Express that I have installed on my machine.
Use SmoApplication.EnumAvailableSqlServers(true): this seems to depend on the SQL Server Browser service. It works great if the Browser service is started, but if it's not, I just get a single row with the computer name as the server name and a blank instance name.
Use System.Data.Sql.SqlDataSourceEnumerator.GetDataSources(): same problem that it depends on the SQL Server Browser.
So, are there some other methods that might work better?
I am able to see both 2005 and 2008 SQL Server instances on my laptop using Powershell:
Get-Service | Where-Object {$_.Name -like 'MSSQL$*'}
Other possibilities to explore include enumerating through the RegisteredServers namespace.
From a command prompt (cmd.exe):
sc query|findstr "DISPLAY_NAME"|findstr /C:"SQL Server (" > myfile.txt
FOR /F " tokens=2 delims=()" %i in (myfile.txt) do #echo %computername%\%i
I know this is an older post, but I did come to this post today looking for a way to find installed instances of SQL Server. Although the two answers given are helpful, I think they only pertain to installed and running instances of SQL Server. If SQL Server Configuration Manager is installed, all installed instances should be listed under the SQL Server Services node. Here you might find an instance that is installed, but not running. You can right click the instance and start it. I am sure there are other ways to do this; it is just a way that came in handy for me today and I thought I would share it.
The SQL Browser service (if active) speaks SSRP/MS-SQLR on UDP Port 1434.
It is the component which is used for remote discovery of instances (and also determining their port). It helps also discovery in a network.
It is however disabled by default (good thing for surface reduction).
This might be helpful , i have tried this in Sql Server 2008 :
select * from sys.servers
This seems to be a fairly common question, but none of the answers I've seen have been particularly satisfactory. I want to get a list of the names of the MS SQL Server instances installed on the local machine, regardless of whether they're started or not. For the purposes of this discussion, I'm OK with just finding instances of SQL 2005 and newer; I can handle 2000 and earlier using "legacy" methods (i.e., look in the registry). What I do require is that it not be dependent on the SQL Server Browser service (it's disabled by default nowadays), and that 64-bit instances are returned even when the app is 32-bit.
Suggestions I've seen:
Dig through the registry: Supposedly Not recommended due to the registry entries being undocumented; MS may change them in the future. More importantly, as far as I can tell, 64-bit instances of MSSQL go in the 64-bit HKLM\SOFTWARE\Microsoft\Microsoft SQL Server InstalledInstances, and 32-bit instances go in the 32-bit one, so a 32-bit app won't see any 64-bit instances.
Use the SQL WMI Provider for Configuration Management mentioned in the previous blog post. This seems to be the closest, but despite the author's admonition to avoid using the registry because it might change, it turns out the WMI namespace changed between SQL 2005 and 2008: in 2005, it's root\Microsoft\SqlServer\ComputerManagement, but in 2008 it's root\Microsoft\SqlServer\ComputerManagement10. Will it change again in the future? That said, it's probably not a huge issue if I have to update my app for a future version of SQL.
The problem I have with the WMI method is that the SqlService class returns a list of the service names, whereas I want the instance names. E.g., instead of MSSQL$INSTANCE, I just want INSTANCE. Stripping off the "MSSQL$" is trivial, as is handling the special case of the default instance, but is it reliable? AFAIK, there's technically no reason why the service couldn't be renamed, while keeping the instance name the same. That said, unless someone has a better method, I think I'll go with that (get the service names and strip off the MSSQL$). The ServerSettings class returns the instance name, but it doesn't see a 64-bit instance of SQL 2008 R2 Express that I have installed on my machine.
Use SmoApplication.EnumAvailableSqlServers(true): this seems to depend on the SQL Server Browser service. It works great if the Browser service is started, but if it's not, I just get a single row with the computer name as the server name and a blank instance name.
Use System.Data.Sql.SqlDataSourceEnumerator.GetDataSources(): same problem that it depends on the SQL Server Browser.
So, are there some other methods that might work better?
I am able to see both 2005 and 2008 SQL Server instances on my laptop using Powershell:
Get-Service | Where-Object {$_.Name -like 'MSSQL$*'}
Other possibilities to explore include enumerating through the RegisteredServers namespace.
From a command prompt (cmd.exe):
sc query|findstr "DISPLAY_NAME"|findstr /C:"SQL Server (" > myfile.txt
FOR /F " tokens=2 delims=()" %i in (myfile.txt) do #echo %computername%\%i
I know this is an older post, but I did come to this post today looking for a way to find installed instances of SQL Server. Although the two answers given are helpful, I think they only pertain to installed and running instances of SQL Server. If SQL Server Configuration Manager is installed, all installed instances should be listed under the SQL Server Services node. Here you might find an instance that is installed, but not running. You can right click the instance and start it. I am sure there are other ways to do this; it is just a way that came in handy for me today and I thought I would share it.
The SQL Browser service (if active) speaks SSRP/MS-SQLR on UDP Port 1434.
It is the component which is used for remote discovery of instances (and also determining their port). It helps also discovery in a network.
It is however disabled by default (good thing for surface reduction).
This might be helpful , i have tried this in Sql Server 2008 :
select * from sys.servers
when installing SQLServer2005 developer edition (not express) I created a named instance:
MYSERVERNAME/MYINSTANCENAME
Is it possible to
1) change the name of my named instance to default:
MYSERVERNAME
OR
2) create a new default instance (MYSERVERNAME as above).
any help would be appreciated!
Hm, when I use the "Change" button in Add/Remove Programs, SQL Server 2005 setup offers me the instance selection screen, and even allows me to list the existing instances. (I'm running XP SP2, by the way.)
I selected the "To install a new component, click here" link in the setup program, then selected SQL Server Database Services on the "Components to Install" screen to arrive at the instance selection screen that allows me to install a new default instance.
A default instance has a default instance name, but captures the computer's name, and uses it as an alias. Even if you change the computer name, the default instance will capture the new computer name, and use it as its alias. But the default instance name remains the same (like MSSQLSERVER).
This is why a default instance cannot be renamed. The default instance name is fixed, and it captures the computer name and uses it for its alias. Thus, only one (1) default instance can exist on a computer, because the default instance has a fixed name, and it always captures and uses the computer name for an alias. In other words, the default instance name is joined at the hip with the computer name (as an alias). Neither can be changed programmatically. Changing the computer name simply changes the alias attached to the default instance name.
If a default instance already exists, all other SQL installations on that computer will be forced to use a named instance (an alias, which cannot be the computer name).
Now in your case, during your first SQL installation, you chose to install it as a named instance, not a default instance. Thus you had no default instance, and thus you used an alias that was different from the computer name. You've never installed a default instance, therefore the installation did not capture the computer name for its alias.
The major thing about default instances is that they capture and use the computer name as an alias, and there is absolutely no way to programmatically change a default instance name. However, you can change its alias by changing the computer name. But the computer name is still joined to the default instance name.
An alias simply points to an SQL installation, so that the alias may use its engine. If the installation was not designated as a default instance, it simply means the installation is not attached at the hip with the computer name as its alias.
I hope this helps, but if this is clear as mud, please forgive me.
Going off of Alan's answer, when you install a new instance as the default instance, take note of the directories it is using to store data and log files (or create a default location like D:\MSSQL\Log and D:\MSSQL\Data).
You can then detach the databases from the named instance and move the files to the new data and log directories and re-attach them in SSMS.
Thanks. This worked for me with sql server 2008 r2 express as well.
I had a default instance of 2005 installed, and only a named instance for a subsequent install of 2008.
I uninstalled 2005 (Important: Copy any 2005 databases to a separate folder first).
Then I reinstalled 2008. You can get the installation exe from microsoft if you don't still have it.
Start installation and select "new installation or add feature".
Select option button for "new installation or add feature".
Accept default instances feature. NEXT.
Select default instance option. NEXT. (note instance ID is MSSQLSERVER).
Continue to accept defauls unless you have a reason not to.
If you have installed a named instance. You cannot change the name to default. You can however:
* make the named instance listen to the default port.
* OR create aliases (with name like MSSQLServer or the IP address, as a trick) to make your clients work.
* If this workaround doesn't help then your best bet is to uninstall SQL Complete and re-install again but chances are that the new installation might take the named instance's name again even if you selected 'default instance'. You can verify this in the SQL services to see if it is still taking the old name.
In this case, the best way (which worked for me) is to install a new instance with the explicit name of MSSQLServer which is known to be the default instance name.
Keep in mind also that SQL takes the computer name and uses it as an alias.
I recently deploy one web application in one of my development servers. I'm using oracle, asp.net and c#. When I run the application in the server everything works fine, but when I try to run the application outside of the server (using my pc, for example) i get this error:
ORA-12154: TNS:could not resolve the connect identifier specified
If i run the application in my pc with visual studio it works fine.
Oracle is installed in Server "A" and the application is in server "B". Server "A" is in one domain and server "B" is in other domain.My pc is in the same domain has Server "A".
In my pc I can find the file tnsname.ora in C:\oracle\product\10.2.0\client_1\NETWORK\ADMIN, but in Server "B" i can´t find it anywhere
any idea?
Thanks for the help.
Have you tried this yet? (from http://ora-12154.ora-code.com/)
ORA-12154: TNS:could not resolve the connect identifier specified
Cause: A connection to a database or other service was requested using a connect identifier, and the connect identifier specified could not be resolved into a connect descriptor using one of the naming methods configured. For example, if the type of connect identifier used was a net service name then the net service name could not be found in a naming method repository, or the repository could not be located or reached.
Action:
- If you are using local naming (TNSNAMES.ORA file):
Make sure that "TNSNAMES" is listed as one of the values of the NAMES.DIRECTORY_PATH parameter in the Oracle Net profile (SQLNET.ORA)
Verify that a TNSNAMES.ORA file exists and is in the proper directory and is accessible.
Check that the net service name used as the connect identifier exists in the TNSNAMES.ORA file.
Make sure there are no syntax errors anywhere in the TNSNAMES.ORA file. Look for unmatched parentheses or stray characters. Errors in a TNSNAMES.ORA file may make it unusable.
If you are using directory naming:
Verify that "LDAP" is listed as one of the values of the NAMES.DIRETORY_PATH parameter in the Oracle Net profile (SQLNET.ORA).
Verify that the LDAP directory server is up and that it is accessible.
Verify that the net service name or database name used as the connect identifier is configured in the directory.
Verify that the default context being used is correct by specifying a fully qualified net service name or a full LDAP DN as the connect identifier
If you are using easy connect naming:
Verify that "EZCONNECT" is listed as one of the values of the NAMES.DIRETORY_PATH parameter in the Oracle Net profile (SQLNET.ORA).
Make sure the host, port and service name specified are correct.
Try enclosing the connect identifier in quote marks. See the Oracle Net Services Administrators Guide or the Oracle operating system specific guide for more information on naming.
Resolving TNS errors can be a real pain. A few things to keep in mind.
Most development environments (like visual studio) keep their own copy of the TNS connection information, and do not use the TNSNAMES.ora file. The file where this information is kept does not have to be called TNSNAMES.ora, that's just the default name. Which may be the reason you can't find it on Server B.
If you have the oracle client software (or an oracle database) you can use tnsping to check if your TNSNAMES.ora file is configured correctly.
The most frequent problems with a TNSNAMES.ora file configuration are using the wrong service name and/or using the wrong host name. You may need to change the "ODB_A" to "ODB_A.WORLD" or vice versa, depending upon the SQLNET settings. For Oracle 10, the latter is the default SQLNET setting. For the latter, you need to use ping to see server "A", and know if you need to use "SERVERA" or "SERVERA.DOMIN.COM" or an IP address.
Do not put # in the password you are setting or remove it from the password.
I was also getting the error and after changing it, the error got resolved.
Guess: An oracle client is not installed on Server B.
If you do have an oracle client installed then you can still put a tnsnames file in any location (Such as a directory on a network share). In order to do this, set a TNS_ADMIN system variable (System Properties->Advanced->Environment Variables on XP) to the directory containing your tnsnames files.
For me for example I have a system variable: TNS_ADMIN - C:\oracle\ora92\network\ADMIN
Is ORACLE_HOME set on server B?
It seems you need to install Oracle Client on "Server B" (the application server), and configure it's TNSNAMES.ORA file. This is required since otherwise, the running code will have no idea where to look for the database you use in the application (probably you're configured a data source in web.config or hard-coded something).
Remember - you cannot access Oracle (easily) without Oracle Client.
Had the same problem. Turns out the TNSNAMES.ORA in out deployment environment had a different ADDRESS_NAME and SID/SERVICE_NAME ,and the application was configured to use the SID - which caused the problem.
Your connection string must contain the ADDRESS_NAME and not the SID
Possible Resolutions -
Verify that the TNSNAMES.ORA exists and is accessible.
Make sure that there are no syntax errors in TNSNAMES.ORA.
Verify that the connection string is correct.
Verify if there are any DNS issues.
If the problem is while connect to server using PL sql developer client.try to install SQL developer within Program File instead of Program Files(x86)'s
Add the environment:
Variable Name: TNS_ADMIN
Variable Value: (YourDrive):\app\(UserName)\product\11.2.0\dbhome_1\NETWORK\ADMIN
I had faced the similar issue. The below code was working in my system but was not working in another server even though I had added a tns entry in tnsnames.ora file.
con = new OracleConnection();
con.ConnectionString = "User Id=username;Password=password;Data Source=uit45";
con.Open(); // throws error here
After digging and digging, I found out the solution for this. We need to ignore the entry in tns file and can be given tns entry as connection string, which worked fine for me. Try the below code.
con = new OracleConnection("Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-uit45.xxx)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SID=uit45)));User Id=username;Password=password");
con.Open();
Note that you need to give the associated values, especially for HOST,PORT,SID,User Id and Password.