SQL Server [Express] Instance name mapping? - sql-server

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

Related

How to Use Same SQL Connection String After Server Name Change?

We have a set of over 10,000 Excel files that were all created from a template (don't ask). They all use the same connection string to connect to a SQL Server database. Now the name of the server is changing and there is no simple way to globally replace it in the connection strings of all 10,000+ files. Is there any way to keep the same connection string and still have the files be able to connect?
The server name is changing from "ABCNT3" to "ABCSQL16P1", so I need a way for the line "Data Source = ABCNT3" to still connect to ABCSQL16P1. Really hoping it's possible.
Disclaimer: This is a little hackish, which will make it difficult for another person to maintain this after you. However, considering your (already) bad situation, this will solve your current problem until you can determine a more-permanent solution.
If you don't already have SQL tools installed, you will need "SQL Server Configuration Manager". I installed it as part of admin tools for SQL 2017 (SSMS).
Run it from the machine with all of your Excel files.
Once it opens, pick the last one from the list, named "SQL Native Client ##.# Configuration". Expand it and choose "Aliases".
Create New.
Alias name = "ABCNT3", Server="ABCSQL16P1".
Your Excel will believe that the new server is the old server. It is pretty seamless.

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.

How to override or workaround compiled DB connection info

I've faced a bit strange problem. There is a site client would like to duplicate on another domain name. Site is built on ASP(yes, old v1 ASP :( ) with SQLServer. Problem is that all the database operations, including connection information is compiled into a DLL library.
Is there a way to some how intercept, override or workaround this?
Platform:
Windows 2000 Server
SQLServer 7
ASP v1 (VisualBasic)
What a nightmare...
If you have control over the new database server, and the connection string references the database server by name, you could add a line in the hosts file which points the name of the old server to a new ip address. Then you still have to create a user with the same password on the new database server.
Yes! However, your new database name MUST be smaller or equal to the length of your old one. Simply open up the vb6 .dll in any Hex Editor and search and replace. Make SURE you do not change the length of the DLL or shift any bytes around.
Failing that, add a hosts entry to windows to redirect the connection.
Could it be that the application uses a DSN definition for the connection?
In Control Panel -> Administrative Tools open ODBC Data Source Administrator. Have a look at the System DSN tab. Does there seem to be anything listed there that is related to the application?
Before you hack your DNS or rename the server, be aware that the SQL Server client supports aliases specifically for this scenario: How to: Create a Server Alias for Use by a Client.
The SQL 2000 tool for configuring an alias is the Client Network Utility.
Do you have any configuration options at all from asp? Even dbname or the such? If so you might be able to use two separate servers for IIS and use a single db server. I'm afraid you might need to find the source or the guy who wrote it.
If you could figure out the connection string or DNS you might be able to do something.
You could write your own passthrough ODBC provider.

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.

Force ##Servername to return something else in SQL Server

DISCLAIMER: While I'm trying to do this to fool a license enforcement scheme, the company is out of business and I'm only setting up a test server. I don't consider this stealing (as a developer that sells software myself, I wouldn't do that) since I can't pay for another license if I wanted to. However, if the community disagrees, please vote to close this question. Just want to be upfront about this.
We use a server app that, as part of its license enforcement, confirms that "SELECT ##SERVERNAME" matches the license installed on the server. I'm setting up a test instance of this application, but since the license I have is locked to a particular servername, I'm stuck.
Is there a way that I can fool ##SERVERNAME into returning something else? Change the internal name of the server to something different than the DNS name? I know there are SQL Server problems if you rename a server, and maybe I can exploit this to accomplish what I need to (rename the server to the licensed name, install SQL, then rename the server so it doesn't conflict with our production server).
If there is another, non-hacky way to accomplish this (set up an isolated domain, use a virtual server with no network connection, etc), I'd entertain those options as well. What does the community think is the easiest way to get this done?
It actually looks possible to set the server name property.
SQL 2000: http://msdn.microsoft.com/en-us/library/aa933172(SQL.80).aspx
SQL 2005: http://msdn.microsoft.com/en-us/library/ms174411(SQL.90).aspx
SQL 2008: http://msdn.microsoft.com/en-us/library/ms187944.aspx
I'd probably set up a separate machine or a virtual machine named after what the license manager was expecting. A bit tedious to set up, but it would probably get the job done quicker than looking for hacky solutions. Of course, while the install was running I'd still be looking just in case...
You might try using the sp_addserver stored proc on your test server to tell SQL Server that the server name is the one the license is looking for.
From the MS docs,
SQL Server Setup sets the server
name to the computer name during
installation. To change the name of
the server, use sp_addserver, and then
restart SQL Server.
Drop the 'local' linked server, then add it back with the name you want. sp_addserver 'foobar', 'local' will make ##server to return 'foobar'. See kb 303774

Resources