How to create default instance after creating a named instance? - sql-server

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.

Related

Can't connect MS Access front end to SQL Server back end

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.

SQL Server [Express] Instance name mapping?

Is it possible to map a sql server instance name to something else? Not asking about changing the name of an instance, simply, re routing a requested name to the actual name, sort of like a name-value pair.
I have a sql express installation with a machine_name\SQLEXPRESS naming convention, but I want 'localhost' to work. I don't want to uninstall and reinstall.
Create Aliases to your instance in sql server configuration tool. See detail in link below.
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/29e88414-265e-4912-a8e5-04bda99528fc/cannot-access-local-sql-server-2008-instance-via-localhost-?forum=sqltools

How do I change "Database default locations" for LocalDB in SQL Server Management Studio?

Connect to LocalDB in SSMS
Open Server Properties -> Database Settings
Change Data/Log/Backup locations -> click OK
When I click OK I get this error:
Found some blogpost and changed this in regedit but it didn't help.
Anyone got any other ideas I could try?
I do not believe that these default paths for SQL Server LocalDB are changeable. This is quite unfortunate due to what appears to be a bug with SQL Server Express 2017 LocalDB ** (fixed as of CU 6 for SQL Server 2017), as per this question (and my answer to it) on DBA.StackExchange:
LocalDB v14 creates wrong path for mdf files
HOWEVER, you do not need to use the default paths. Those are used when you create a Database without specifying the physical locations. If you specify the physical location, then you should be able to create the files to any folder / directory that you have read / write access to.
After making that change in the registry try restarting the sql instance.
Also I would make sure that the account running SQL Server has the ability to write to that folder.
for an easy test you could go to the folder properties -> security then add the account 'everyone' then give them full control. then try making that change. If it works it was a permissions issue to that account. Accounts generally don't have access to other users accounts without some level of admin.
After 10 years this is still an issue for the current version(15.0) of Microsoft SQL Server Express.
After a bit of investigation I discovered, there is an issue with permission inside the registry. The process sqlservr.exe cannot create entries in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15E.LOCALDB\MSSQLServer.
On my computer this process is running under my account, so I opened regedit and gave myself Full Control permission to this key. And it worked like a charm. I hope this will help you as well.
Changing these paths in RegEdit or SSMS doesn't work, SQL LocalDb won't respect these values for existing databases. One has to move the databases manually. Here is the reliable way to change a database location for any LocalDB instance.
First, make sure you work with a correct instance of SQL Server LocalDB. In command prompt enter:
sqllocaldb info
It will show the LocalDB instances you have on your machine. Let's assume that the instance name is MSSQLLocalDB.
Next, execute this script on your database (let's call it TestApp), using SqlCmd tool or SSMS:
alter database TestApp
modify file (name = TestApp, filename = 'C:\NewDataLocation\TestApp.mdf');
go
alter database TestApp
modify file (name = TestApp_log, filename = 'C:\NewDataLocation\TestApp_log.ldf');
go
Now, stop the SQL LocalDB instance, in command prompt:
sqllocaldb stop MSSQLLocalDB
Move the database files to the new location that you specified in the script. From %UserProfile%\TestApp.mdf (which is where they are located) to C:\NewDataLocation\TestApp.mdf, same for LDF file.
Start the SQL LocalDB instance again:
sqllocaldb start MSSQLLocalDB
Now your database is working from a new location. Repeat the steps for any other databases.
Paths Cannot Be Changed in SQL Server LocalDB "Automatic Instance" Types
In case anyone in 2023 finds out they cannot change their default database file storage paths, this article is for you!
This error applies to Microsoft SQL Server not being able to allow you to change the default file folder location on your PC where the SQL Server Database Files are saved (database and logs files, .mdf and .ldf).
Most developers often need control over where local database files are saved. Most prefer to store them in a central location, another drive, or simply the main SQL Server database repository inside the C:\Program Files\Microsoft SQL Server\{sql version name}\MSSQL\DATA, since that is where system data storage goes. One example of the problem of not being able to customize database file storage might be using Entity Framework Core, which runs "migration" scripts that create databases in SQL Server. When it does so, where those scripted databases get stored is heavily dependent on SQL Server's default file path settings. When the location of those EF code-first database files using LocalDB is locked down, developers are stuck with SQL files in multiple locations on their PC's.
THE PROBLEM
Apparently, when Microsoft installs SQL Server / SQL Express on your device, it attempts to install a default instance of the server as a specialized type called a "LocalDB Automatic Instance". They do this to get the user up and running fast with a "LocalDB" sql server instance, which is a one-time, "light", custom created server running as a public instance, complete with default settings which are customized for the user (or developer) so he can get up and running fast. The automatic type has the advantage that its granted permissions to the user as administrator in SQL, as well as granting all applications on the user's device public access to the server instance. (You will notice that IIsExpress works this way using ApplicationPools as dummy Windows User Accounts, creating default accounts next to your User Account in Windows to run app pools in IIS.) These SQL Server LocalDB binaries do not run as a service but on-demand. But only one of the "automatic" types may be installed per version per device. The other SQL Server LocalDB type is the named instance and is not as restricted as the automatic one, apparently.
The problem is, when they create this special LocalDB automatic instance, it locks down certain settings and applies certain permissions and settings that are unique just for this instance. This then limits what the user can do as far as customizations, one of which is the "Database default locations" in the Properties dialog box that appears when you right-click your sql server instance and choose properties.
Anyone using the full SQL Server version, or who has created a new instance of LocalDB, deleting the old one, will not experience this issue, so most of those people are scratching their heads.
But for local developers, what this means is your Sql Server LocalDB databases running under this instance of the server will typically store their databases under a locked down path...either the path you chose on install or default to the user-friendly account paths under C:\Users\{YourName}.
When users attempt to change the path in the properties box for the instance, many users online the past 5-6 years have noticed a nasty RegCreateKeyEx() returned error 5 Access is denied that would appear when saving a default path. Microsoft doesn't bother to tell you, but that is intentional. They don't expect to allow you to save paths to the registry for the instance, and assume everyone is ok with the default path.
You can fix the key error by going into your registry and changing permission on the Microsoft SQL Server registry keys, assigning the "Everyone" group account to the registry node managing these keys. In the Registry, add Everyone group account to this node below then try and save a new default path in the properties box for your sql server localdb instance:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server
The location of the default database file path keys (2019) in the Registry in Windows for an instance of the localdb server of are located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15E.LOCALDB\MSSQLServer
You are then able to save the new default paths in SQL, and the error goes away. Saving your default path in the Properties box works now, and the new values appear in the registry.
Even though you can change these paths, they will not stick, however, and reset back to the User Account Path, by default. Even if you save a new default sql path for your databases, when you create a new database it still reverts to the old path. Again, this applies ONLY for users who are running under the default "Automatic" LocalDB instance created on install of SQL Express.
So even after restarting SQL, restarting your PC, or restarting the SQL Service, those registry values will still not pull the registry keys into the SQL Server instance settings for Default file paths.
As proof, run these two scripts below in your SQL Server LocalDB instance. The first one returns the actual LocalDB default file paths SQL Server stores internally. The second script returns what is stored in your registry for the LocalDB default file path. If you saved new default path registry keys, they should be the same and shown in SQL Server instance properties, but they are different! That means Microsoft has decided not to allow you to change them for those running the "automatic" instance type of LocalDB on install. Below is the T-SQL to run to test this:
-- GETS THE PATH STORED IN SQL SERVER FOR "DefaultData" path
SELECT
[Value] = 'DefaultData',
[Data] = SERVERPROPERTY('InstanceDefaultDataPath')
-- DefaultData C:\Users\YourAccountName\
-- GETS WHATS IN THE REGISTRY FOR "DefaultData" path
EXECUTE [master].dbo.xp_instance_regread
N'HKEY_LOCAL_MACHINE',
N'SOFTWARE\Microsoft\Microsoft SQL Server\MSSQLServer',
N'DefaultData'
-- DefaultData C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA
-- Note: If the second one returns `NULL` it just means you
-- have not yet tried or succeeded in saving a new file path
-- to your registry.
Why isnt SQL Server LocalDB pulling in the registry values?
What this means again, is sorry you can't change these default paths. Your best bet is to simple "detach" your databases, copy the .mdf and .ldf files to your new prefered folder, then reattach. When you create new databases, the console allows you to change the database file path there, as well. There are also some elaborate SQL scripts you can run to set paths before saving files.
But just know this is by design.
I think one of the purposes of LocalDB is that it is very convinient in bundling a demo database along with the source files of an application. The database file and its log, of course, are somewhere in the source file directory.
Take a Visual Studio solution for example, in web.config or app.config, you can see something like this:
<connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Initial Catalog=aspnet-XXXXXX-20140609153630;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnet-XXXXXX-20140609153630.mdf" providerName="System.Data.SqlClient" />
Now that the location of every LocalDB is specified in the config file, I don't think "default location" makes much sense.

Is is possible to run multiple instances of SQL Server on the same machine

Is is possible to run multiple instances (installations) of SQL Server databases on the same machine (assuming the machine is not virtualized)
Yes, you can give the installations different names. I think you have to choose "advanced options" on installation to be able to set the name.
yep, they need to be named instances though. Run the setup but when you get to the instance name - add a new name for the instance.
Yes, we can use multiple instance of SQL Server of same machine/server.
All instances of the database engine other than the default instance are identified by an instance name specified during installation of the instance.

Change my local named SQL Instance from 'localhost\sql05' to just 'localhost'

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.

Resources