After creating filetable I've got a shared folder
\\<my domain>\mssqlserver\<filestream directory>\<my table>
I've made all nesessary settings in SqlServer Configuration manager to make it available and added couple of files with database stored proc.
I made virtual folder for my web site
http://localhost/<my ewb site>/<virtual folder>/
referencing shared table folder.
When I try to get file from folder I get en error:
HTTP 500.19 - Internal Server Error
Code 0x80070032
I found something in answer of this question
Access Denied when inserting file into Sql Server 2012 FileTable using File.CreateFile in ASP.NET website
But it's only a database part of configuring.
I don't understand how to configure IIS and virtual folder to grant access to shared folder.
Not sure if this is relevant to your situation, but I came across the same problem. 2 out of 3 sites that I setup worked fine with the UNC path virtual directory pointing to the SQL filetable share, but the 3rd site got the error above. The reason was because this site was had both IIS and SQL on the same server, and using the server name in the UNC path was causing a reparse and checking for directory change notifications, which mentioned in the comments above aren't supported by SQL. So I changed the UNC path to use localhost instead of the server name and it worked! So, instead of:
\\<my domain>\mssqlserver\<filestream directory>\<my table>
use:
\\localhost\mssqlserver\<filestream directory>\<my table>
For reasons not worth going into, I had to rename a Microsoft SQL Server database that an ASP.NET MVC project was using. I thought that, on the MVC side, this would be something as trivial as changing the connection string in the web.config. Alas, no.
The database name went from myproject.MODELS.OSESDBCONTEXT to myproject.
So, I changed the default connection block in the web.config to reflect that, all else being equal:
<defaultConnectionFactory
type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
<parameters>
<parameter value="Data Source=machine.company.com;Initial Catalog=MyProject;User ID=someuser; Password=somepassword#;MultipleActiveResultSets=False" />
</parameters>
</defaultConnectionFactory>
It seems to be failing to connect to the database, but since it can't find the database it is attempting to create a new one but it fails because the .mdf file is already present. However this isn't the issue, it should be connecting to SQL Server.
This is the error I get when running the web page:
Cannot create file 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\MyProject.Models.OSesDBContext.mdf' because it already exists. Change the file path or the file name, and retry the operation.
You might be able to accomplish what you're after by doing a database attachment.
Can you try to reattach it via SQL Server Management Studio or through T-SQL?
First, copy your mdf and ldf files to something new (name them relative to a new database you'll attach them as).
Then in the Attach Databases screen:
Enter your new name for the database in the Attach As field in the top frame
In the bottom frame, browse to both the new mdf file and the new ldf file you just created.
You should then have a newly attached database.
I don't think database name should be specified in defaultConnectionFactory - it seems like it's about server in the first place.
Database name should be specified elsewhere, e.g. see the possible options here https://msdn.microsoft.com/en-us/data/jj592674.
I can only suspect the old database name is still somewhere in the places mentioned above. Have you tried to search for the old name in the sources?
SQL Server 2008 R2 stopped all of a sudden due to (maybe) Power Fluctuation.
I tried all the possible ways to restart the it but every time it is failing with the error
The request failed or the service did not respond in a timely fashion.
Some of the ways I tried are
Making the SQL Server to log On as "Local System" instead of "NetworkService"
Replacing of Master.mdf and mastlog.ldf files from the "Bin/Templates" folder
Disabling "VIA" (which was already disabled)
But all in-vain :(
On checking further I noticed that both the data files i.e. mydb.mdf and mydb.ldf of my database are not there in the DATA folder and instead there are mydb_1.ndb and mybd_2.ldf files.
How to recover mydb.mdf file and to restart the SQL Server?
Thank you.
sql data files can be named anything so the mydb_1.ndb could be your data file.
If that's true you should be able to recover the data by:
Install a new sql server (sql express would work if the DB is < 10GB)
move the mydb_1.ndb and mybd_2.ldf onto that server
Use "Attach..." from ssms to add the database to the new server
If you are lucky and that ndb is just a differently named mdf file you should be able to access the data.
Then you can repair your existing server (reinstall will be easier than messing with the master database unless you've got other dbs on there) and move the database back over i.e. do the same attach... method
Oh - and start backing it up :)
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.
If I create a new MVC4 Web Application with the Internet Application project template (which uses forms authentication) then, when I run it the first time and click on Register, the call to context.Database.Exists (in the InitializeSimpleMembershipAttribute filter) correctly detects that the database file does not exist, and ObjectContext.CreateDatabase is called, creating the dbf and ldf files in the App_Data folder.
If I then delete the dbf and ldf files and run the app again, the call to context.Database.Exists returns true, despite the fact that the database file is gone. This behavior seems to be persistent: Once ObjectContext.CreateDatabase has been called, some magic seems to remember that the database "exists", even if the physical file is gone and even if I restart the PC.
Ok, so I assume that something in SQL Server is remembering the existence of the database. So I've installed and run SQL Server Management Studio. But the only thing that appears under the Databases folder under the \SQLEXPRESS node is the System Databases folder. I see no sign of my database file connection.
What's this all about? Why does context.Database.Exist return true, and how can I convince it to return false if the database file is gone? And why don't I see some evidence of the database connection in SQL Server Management Studio?
Bob
You can remove the database by deleting it from your LocalDb instance. Using SQL Managment Studio connect to "(LocalDb)\v11.0".