I installed SSMS 18. I installed a new LocalDB instance by choosing it from the SQL Server Express 2017 installation as it is not yet included in the SSMS 18 installation.
After installation when I try creating a database with the SQL below.
CREATE DATABASE Test
I receive the following error:
Msg 5123, Level 16, State 1, Line 1
CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file 'C:\Users\brechtTest.mdf'.
Msg 1802, Level 16, State 4, Line 1
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
One thing I notice, but not sure is relevant, is that the filepath does not make sense at all. There is a backslash missing.
I bring up the server properties and try and add a backslash to maybe solve the problem.
But then this error hits me.
After which I try a hail mary and give everyone permissions on Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL14E.LOCALDB\MSSQLServer. That prevents the error from popping up when changing the directories in the server options. But it doesn't solve the original issue.
The weird thing is that creating a database via the GUI (like below) works without a problem. But I need CREATE DATABASE to work because I'm receiving errors with EntityFrameworkCore migrations utilizing this functionality.
As soon as I allow myself all permissions on "C:\Users" I can create databases with CREATE DATABASE, because the used filepath is "C:\Users\brechtTest.mdf". But that filepath makes no sense.
Some things I've tried:
Reinstalling LocalDB.
Running SSMS as administrator.
Configure SQL server service to use the local user.
Edit the Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL14E.LOCALDB\MSSQLServer keys to include a backslash.
How can I get this to function properly, i.e. how can I adjust the default path to include a backslash so that "C:\Users\brechtTest.mdf" becomes "C:\Users\brecht\Test.mdf"?
This error is due to a bug in the file creation path in SQL Express 14.0.100. Follow these steps if you are affected:
Close SSMS and any running instances of SQL Server in Task Manager >
Processes including SQL Server Telemetry and SQL Server Client NT
related tasks.
Navigate to %LocalAppData%\Microsoft\Microsoft SQL Server
Local DB\Instances\ in Windows Explorer.
Remove any local instances you installed like MSSQLLocalDB.
Open your favorite CLI (like Command Prompt) and use these sqllocaldb commands. If it says the commands cannot be executed because the instance MSSQLLocalDB does
not exist, continue to the next step.
sqllocaldb stop MSSQLLocalDB
sqllocaldb delete MSSQLLocalDB
Update your locally installed SQL Server with the latest Cumulative Update
https://www.microsoft.com/en-us/download/confirmation.aspx?id=56128.
You can see an overview of updates in the Update Center for
Microsoft SQL Server on Technet:
https://technet.microsoft.com/en-us/library/ff803383.aspx.
After a succesful update, use the sqllocaldb create command.
sqllocaldb create "MSSQLLocalDB"
Your CLI should prompt that it has created a
localdb with version 14.0.300 or higher:
LocalDB instance "MSSQLLocalDB" created with version 14.0.3223.3.
If you successfully updated the local db instance but you are receiving this error after: SqlException: 'Cannot create file 'C:\Users\%USERNAME%\Database.mdf' because it already exists., please remove the file in the specified path and try again.
I can't see the images due my shop's policies, but I think that you can achieve your goal in 2 ways.
In SSMS right click the server name and select properties, then go to "database settings" there's a section named "Database default locations" modify to meet your requirements.
As a second option is to specify the datafiles explicity like:
CREATE DATABASE [test]
ON PRIMARY
( NAME = N'test', FILENAME = N'c:\mypath\test.mdf' , SIZE = 8192KB , FILEGROWTH = 65536KB )
LOG ON
( NAME = N'test_log', FILENAME = N'c:\mypath\test_log.ldf' , SIZE = 8192KB , FILEGROWTH = 65536KB )
I'm new to altibase hdb. I was installed altibase hdb with the instructions from here:
http://support.altibase.com/manual/en/631b/html/Installation/index.html
after using the links guides I was able to start the server well but I could not create the database via the recommended command:
CREATE DATABASE mydb INITSIZE=10M NOARCHIVELOG CHARACTER SET KSC5601 NATIONAL CHARACTER SET UTF16;
after some manipulation I found out that the datafiles and anchorlog files were exist here:
$ALTIBASE_HOME\Altibase\altibase-HDB-server-6.3.1\logs
$ALTIBASE_HOME\Altibase\altibase-HDB-server-6.3.1\dbs
So I cleaned them and now I can use the command above to create the database. but if I just rename the databasename to forexample mydbb instead of mydb the command does not work and get me the following error:
Invalid Database Name. Check The Properties and retry.
So what's problem with the database name? what's the difference between mydb and mydbb????
Keep in mind that this same issue should occur even if you install ALTIBASE HDB on Linux.
If you are going to change the database name using the "CREATE DATABASE" command, you must also change the DB_NAME property in your $ALTIBASE_HOME/conf/altibase.properties file to match.
Once you do so, the command you specified should work fine.
I want to install DB2 UDW in my machine for learning purpose but I am having a hard time configuring the local instance. Any help would be highly appreciated.
I installed DB2 express edition -c . I have selected all the default choices. I am trying to connect using IBM data Studio 4.1, In the "DB2 first Steps" GUI I have chosen to create SAMPLE Database. I am getting the below error
Creating database "SAMPLE" on path "C:"...
Existing "SAMPLE" database found...
The "-force" option was not specified...
Attempt to create the database "SAMPLE" failed
'db2sampl' processing complete.
I tried connecting from Data Studio using the following options
Database- SAMPLE
Port- 50000
host - localhost
Error I am getting
Explanation:
An attempt was made to access a database that was not found, has not been started, or does not support transactions.
User response:
Ensure that the specified database name exists in the system database directory. If the database name does not exist in the system database directory, either the database does not exist or the database name has not been cataloged. If needed, issue a db2start command and then resubmit the current command.
SQL4499N A fatal error occurred that resulted in a disconnect from the data source.
SQLSTATE: 08004
Problem is I am having zero knowledge in DB2. If I need to run db2start command from where I should run this? Please help
Probably the instance is not started.
Once you have installed DB2, you need to have an started instance in order to use any database. The instance could be created at the same time of the installation. You can verify which instances exist in your computer by issuing:
/opt/IBM/db2/V10.1/instance/db2ilist
The output should give you a set of users, where an instance has been configured.
You can change to that user and start the instance. For example if the user is db2inst1
su - db2inst1
db2start
Once the instance is started, you can now create a database and then connect to it.
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.
Full error below:
Error 1 SQL01268: .Net SqlClient Data Provider: Msg 1834, Level 16, State 1, Line 1 The file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\testdatabase.mdf' cannot be overwritten. It is being used by database 'testdatabase'. SchemaCompare5 25 0
I read about this on some forums and quite a few people were getting this and supposedly for some it had to do with parameterising the file path name to the db etc. or ticking "ignore file names and path for files and log files" prior to doing the comparison - this I have tried to no avail.
Someone else who has the same/similar issue: http://social.msdn.microsoft.com/Forums/en/vstsdb/thread/5a8b8c52-adb4-4a5a-95ed-09ad22bacf60
Basically for me I seem to get this error irrespective of which databases I am using for target and source. Say even if I create a new database with one table and another database with no tables and different name and try to update the schema of the database with no tables using the db with the single table it still gives me the error. Almost like SQL server express has gone nuts. I remember using the schema comparison tool before with no trouble. All db connections were created, tried many ways to do this to no avail ie: pointing to copy of *.mdf db in another folder or deleting things from the DATA folder in mysql directory in program files etc.
Also believe I read someone had solved a similar issue be deleting some files the scheme
comparison tool creates, think they were *.sql type not sure which ones though.
The problem arises because the database files already exist.
Try the below within the Visual Studio database project.
Create the schema comparison.
Go to menu: Data > Schema Compare > Export to > Editor
Once the script has been created delete the alter database commands that add the physical files. Then create a connection, switch to SQLCMD mode (making sure you have focus on the script) and execute the script.
To switch to SQLCMD mode access: Data > Transact-SQL Editor > SQLCMD Mode
If the target DB already exists, just delete through Management Studio first before you deploy for the first time.
I had already created the database manually through SQL Server Management Studio when I was establishing the original connection when creating the Database Project via the SQL Server 2008 Wizard in VS. It wouldn't allow me to continue until it could detect that the database existed. Then once I got to the Deploy step for the first time, it threw the same error as above. I just went into Management Studio and deleted the DB, then tried to deploy and it worked fine. Interestingly, it's deploying every time now without me having to go in and delete it every time.
RESTORE DATABASE B FROM DISK = 'A.bak'
WITH MOVE 'DataFileLogicalName' TO 'C:\SQL Directory\DATA\B.mdf',
MOVE 'LogFileLogicalName' TO 'C:\SQL Directory\DATA\B.ldf',
REPLACE ---> Needed if database B already exists