Hello I'm new to MVC and have been looking for a solution to my problem for the last couple days with no avail.
I've created a simple blog engine using ASP.NET MVC, after installing it on IIS on my local PC, I quickly realized I needed a database for the login service to work.
So I elected to use LocalDB on a PC that I plan to use as a server. I moved my files over to the PC and installed everything I needed. As soon as I installed SQLExpress with LocalDB and reset the site, everything was working perfectly. However, I noticed some minor typos on a section of the site that's not easily edited. Stupidly, I reinstalled the website entirely from a new build instead of just updating the view that needed correction like a smart person would do.
Now every time I attempt to login to an excising account or create a new one I simply get the error
Cannot attach the file 'C:\inetpub\wwwroot\App_Data\aspnet-FacetBlog-20161020065352.mdf' as database 'aspnet-FacetBlog-20161020065352'.
From what I've learned, It's something to do with my LocalDB instance, but fixes I've found online seem to have no effect.
Admittingly, I'm pretty naive with it comes to SQL, so hopefully the fix is simple. If I've failed to provide vital information please tell me and I'll update the question. Additionally, an explanation of what exactly went wrong would be much appreciated. Thank you for your time.
When reinstalling your site, probably you had deleted database file aspnet-FacetBlog-20161020065352.mdf in your database directory. Since deleting MDF file doesn't affect registered SQL Express instance, SQL Express thinks the database still exists and trying to connect but failed.
First, try to attach the DB using SSMS query like this:
EXEC sp_attach_db #dbname=N'aspnet-FacetBlog-20161020065352.mdf', #filename1=N'App_Data\aspnet-FacetBlog-20161020065352.mdf', #filename2=N'App_Data\aspnet-FacetBlog-20161020065352.ldf'
NB: I assumed your MDF file location stands in App_Data directory, change it to your actual database directory.
If attempt to attach by query doesn't work, try these steps:
Stop IIS/IIS Express pool if it still running.
Open a Windows Powershell instance on your server PC (install it first if doesn't exist).
Run the following command:
sqllocaldb.exe stop v11.0
sqllocaldb.exe delete v11.0
sqllocaldb.exe start v11.0
Recreate the DB instance on your project, including data connection in Server Explorer (remove then create).
Re-run the project in development machine, then copy all required files to server PC. The database instance should be (re-)generated at this time.
Restart IIS/IIS Express pool on server PC.
Additionally you may run Update-Database command from Package Manager Console to ensure database integrity.
If those solutions still won't work altogether, simply rename your database files and attach it on your project, verify the connection string then retry step (5) and (6) above.
Related problems:
EF5: Cannot attach the file ‘{0}' as database '{1}'
Cannot attach the file ".mdf" as database "aspnet-"
Delete .mdf file from app_data causes exception cannot attach the file as database
Cannot attach the file 'C:\inetpub\wwwroot\MvcApplication10\App_Data\aspnet-MvcApplication10-20130909002323.mdf' as database 'aspnet-MvcApplication10-20130909002323'
Related
My database crashed unexpectedly as the containing VM was collapsed and in turn Weblogic server went down. Now I've installed database in new VM and recovered data into it. But now, I'm unable to start my Weblogic admin server. I guess it's unable to retrieve the data from OPSS tables. What should I do now to start my Weblogic? How can I make all the database related changes from old VM to new VM?
Depending on the state of your AdminServer after the crash, it may be that your server is still seen as 'running' by the NodeManager. Try the following:
In the [weblogic_domain]/servers/AdminServer/tmp folder check for an AdminServer.lok file. If this file exists and you are sure your instance isn't running (ie. Checked there are no JVM running) delete the .lok file and try to start the AdminServer.
If this still fails you can delete the entire contents of the tmp folder but also go to the [weblogic_domain]/servers/AdminServer/data/nodemanager folder and delete all the files there.
Try starting the AdminServer again.
If it still fails you'll need to review the AdminServer and nodemanager logs and post them here for further help.
I created website using asp.net MVC with Entity Framework Code First. It worked before on Windows Azure, the site was available publicly.
For some reason, I deleted database that was used to store data of my webpage. I created new one, similar to previous one.
I properly connected my site to database (in solution I clicked "Publish", in "Settings" there is place to type data about database, in "Destination Connection String" window I typed all needed data and clicked "Test Connection" - everything seems to be fine)
I published my site, the site works correctly, but when I go to page that gets data from database is see this error:
Invalid object name 'dbo.AspNetUsers'.
In Visual Studio in "SQL Server Explorer" I can see what is in my database. In fact, there is nothing inside (there is one table: "__MigrationHistory" and as I suspect this is created by default).
How can I generate all those tables again? It should generate database structure automatically.
PS: Accidentally I deleted "migations" from my project, do you think this is the cause?
This is not my projects blame, it works OK on localhost on my computer, when I delete localDB, it generates new one without any problem.
Yes, you need migrations. But you can always re-create them (well, if you removed them all it will be initial migration containing all of your previous migrations).
To quick fix you can backup and restore you database on the server. And if you need to re-create migrations do the following:
Backup all your data
Delete the entire database (local and remote), delete all migrations from code.
Create databases (local and remote one).
Run "add-migration Initial" command from PM console
Run "update-database" from PM console.
Upload your code to the server again. If database is empty, new initial migration should be automatically applied.
I'm using Code First concept in Entity Framework and I'm constantly getting the following exception while starting application:
Cannot attach the file 'C:\Users\Admin\Documents\Visual Studio 2012\
Projects\Pro\Pro.Web\App_Data\Pro.mdf' as database 'Pro'.
I've put this in Global.asax.cs but also without success:
Database.SetInitializer(new DropCreateDatabaseIfModelChanges<ProWebContext>());
var ctx = new ProWebContext();
ctx.Database.Initialize(true);
I've checked under App_Data directory and there no database created. Also, under Server Explorer there is nothing under Data Connections. Everything was working fine yesterday and today not working at all. I've tried to connect to LocalDB with SQL Server Management studio but it says it cannot connect to local database. Any ideas what could be a problem?
Thanks!
I found the solution. With newest SQL Server Management studio there is no problem in connecting to the local database. Connection needs to be established like this:
After logging in we can still see old database present even if there is nothing under App_Data directory and under Data Connections in Server Explorer in Visual Studio. When we delete that database from SQL Server Management studio and start application again there will be no more errors while attaching database.
I was facing the same error when I saw this but I couldn't delete the database using SQL Server Management Studio so I remembered IDatabaseInitializer.
Setting a database initializer for my Code First context solved the issue. In my case adding an initializer to always drop the DB worked (I added the code in the static constructor of my context, most people add it in Global.asax):
static SomeDbContext()
{
System.Data.Entity.Database.SetInitializer(new DropCreateDatabaseAlways<SomeDbContext>());
}
There are other initializers of course.
I just got into the same problem, and yet the answers above helped, the solution was different.
In my case, I was reusing a project that has already created it´s database. And since the name in the config was the same, it was throwing the exception, missleading the real solution.
It worth checking the database is not created and is different than the ones you used before. Change the name and go ahead.
I deleted the mdf file manually so the code will recreate it again, and had the same problem. I solved it by running update-database command in the package manager console.
I'm building a web application which soon I'll be promoting to production. This application has a login screen, as you know I used the integrated DB for developing. Now I want to move this database to a full SQL Server 2005. I'm using the aspnet_regsql.exe to create my membership tables and stored procedures in the SQL Server 2005 but I'm getting an error:
An error occurred during the execution of the SQL file 'InstallMembership.sql'. The SQL error number is 207 and the SqlException message is: Invalid column name 'FailedPasswordAnswerAttemptWindowStart'.
I google this for half of the day already and I can't seem to fine what's wrong, does anybody have ANY ideas on what am I doing wrong here? Any help will be really appreciate it.
The easiest way to deploy a brand new database to a remote server is to just publish the database from within Visual Studio. Once you do that you have the scheme and data all in one script. You then access your server either via a local SQL manager connection or a remote manager and run the script on your remote database.
The site 4GuysFromRolla has a nice little walk through with graphics which describe how to accomplish the publishing of your local database to your hosted one.
Good luck, and hope this helps you out some.
Go through the *.sql script file and see where that column reference is. Then you'll be able to see what exactly the script is doing to cause this error. My guess would be that it is getting caught up on referential integrity. If it is trying to create a foreign key constraint that that table/column does not exist then you'll see that error.
But back to the original question at hand. You don't need to recreate your whole database. That script file is to lay down the Membership for an empty database. If you have a working dev database you can just back it up and restore it to a production instance. No need to rebuild the membership database objects.
Since the answers did not really cover the problem, I posted this on ASP.Net and completly rephrased it. I will post the edited question here:
I have been using the attachDB connection string and I usually deploy to IIS. The site works fine, however, I made some changes to the database and the newest version would not copy as it said file in use.
I opened up SQL management studio and saw that it was mounted so I did a dettach.
I was then able to copy the new version without problem, however, when I next run the site, I get:
Unable to open the physical file "C:\inetpub\wwwroot\vs\App_Data\aspnetdb.mdf". Operating system error 5: "5(failed to retrieve text for this error. Reason: 15105)".
An attempt to attach an auto-named database for file C:\inetpub\wwwroot\vs\App_Data\aspnetdb.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
And, if I try to access .Net users or the other few options within IIS Manager, I get the following error:
.NET Users
There was an error while performing this operation.
Details:
A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)
OK
I have tried recycling the application pool, restarting the SQL instance and even restarting the computer.
Nothing helps and I cannot figure out what is wrong... Where does it remember where previous databases are connected and why doesn't it automatically reattach the database?... Someone said that they auto detach after 2 1/2 hours, however I waited 5 hours when a database wasn't in use and SQL Manager showed it was still attached.
When I manually reattach the database, everything works fine.
When you ask a database to be attached on-the-fly to a SQL Express instance using the AttachDBFileName connections string the application will not connect to the SQL Expres sinstance at all, but instead it will connect to a child instance, which is an new instance created specificaly for the user requesting the attach operation. See SQL Server 2005 Express Edition User Instances. This child instance will attach the database and will continue to run for up two one hour, after which it will shut itself down.
When you try to connect from 'enterprise manager' you will not be able to connect to the child instance (is realy complicated to connect explicitly to one, so you cannot accidentaly do it), you are connecting to the parent instance and messing with the database.
To summarize, either stick with the RANU model and use AttachDBFileName, or use a normal database operations mode and manage the database from the SSMS. Don't mix the two.
Are you certain there isn't already a database with the same name attached to the SQL Express instance you are pointing your site at?
Also, does the identity the site is running under when it attempts to attach the database have admin rights in SQL Express? If not, this command won't work (I'm not sure what error it gives in that situation, but "Access Denied" would sound reasonable).
The page "SQL Server 2005 Express Edition User Instances" seems to give a good overview of the issues and workarounds.
Edit to add
Could this be the issue:
An error will be generated if a log file exists in the same directory as the data file and the 'database' keyword is used when attaching the primary data file. In this case, remove the log file. Once the database is attached, a new log file will be automatically generated based on the physical path.
Taken from the documentation for SqlConnectionStringBuilder.AttachDBFileName Property
You'll need to delete the log file before you can re-attach the database through this method.