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'
I am following this tutorial (http://www.asp.net/mvc/overview/getting-started/database-first-development/setting-up-database) in order to create a database-first app with Entity Framework.
I hit "Run" and everything seems to be working, but in the next part of the tutorial (https://www.asp.net/mvc/overview/getting-started/database-first-development/creating-the-web-application), when I try to add a connection, it's not in the drop-down menu in the "Connection Properties" box under "Select or enter a database name".
Which server is the database on? I didn't specify anything about the server when I created the project for the first tutorial, and I figured that it would be on the default LocalDB that comes with Visual Studio (server name: (localdb)\MSSQLLocalDB), but the database isn't there. Any ideas where I should look or what to try?
Maybe use . (a dot) as Server Name?
Open your Web.config file and check your <connectionStrings> this is where the data source of the database will be. As shown:
However, which version of SQL Server do you have? As this can determine what the correct connection string will be.
Hit Windows+R. And run the following:
%LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB\Instances
You may have multiple instances, it would be worth checking each one. So it would be:
(localdb)(name of instance)
This article may also be of use to you:
http://rajchel.pl/2015/10/solving-connection-issue-with-sql-server-2014-localdb/
What could be the case is that you have to run the application you created, and then do something to touch the database like creating / registering a user. After registration you can find the database on the specified location in your web.config settings. This was the solution in my case.
I am taking over the maintenance of a website. Virtually no documentation. I hope that this kind of question is "ok" here ...
Right now, I am trying to locate/view the database but I can't find it.
This is the only connectionString in web.config:
<connectionStrings>
<add connectionString="Data Source=YPOC\SQLEXPRESS;Database=Marco;User ID=yyy;Password=xxx;" name="DefaultConnectionString" />
</connectionStrings>
QUESTIONS:
1) are these parameters equivalent?
a) Database=Marco
b) AttachDbFilename=|DataDirectory|\Marco.mdf
c) Initial Catalog=Marco
2) if the answer to #1 is "yes", then I should find a database file called Marco.mdf in the App_Data folder, right?
3) but #2 can't be correct, because I do not see a database file called Marco in the App_Data folder ... ;-x
4) where in the world is carmen sandi ... oops, I mean Marco.mdf ?!
RELATED QUESTIONS:
I had to copy all the files from a production server called YPOC. In the web.config, I think I need to change "Data Source=YPOC\SQLEXPRESS" ... my SQL Server Instance Name is "SQLEXPRESS" ... therefore, should I change the DS to "Data Source=.\SQLEXPRESS"?
In the App_Data folder, I found ASPNETDB.MDF ... in Server Explorer, I try to connect to view the tables, but I get an error message:
"...cannot open because it is version 661. This server supports version 655 and earlier"
I did some research and it appears that version 661 means that it needs SQL Server 2008 R2 ... but I have that installed already ... ;-(
I'm used to a shared hosting environment where the SQL Server DB is set up and it's easy to connect. Here, it is on a dedicated cloud server (unmanaged) and I'm been thrust upon new territory where I can't even find the database ... ;-(
Any help is greatly appreciated ...
nano
Stop, stop, stop, stop, stop using the User Instance and AttachDbFileName nonsense. Please. You will be much more sane if you forget they exist. I'm totally serious. The user instances feature has been deprecated for a reason.
Take your MDF file, which you can find by searching using Windows Explorer (if you've been using this user instance feature, you will probably find multiple, and I have no suggestions for determining which one is the right one). Once you've found the one you want to use, attach it to a proper instance of SQL Server using CREATE DATABASE Marco ... FOR ATTACH_REBUILD_LOG. Your connection string should then point to your server (yes, .\SQLEXPRESS should be fine if you are connecting locally), and should refer to your database by logical name (e.g. Marco, no path information to a specific MDF file).
Also you'll want to install Service Pack 1 for SQL Server 2008 R2. It seems like you created a database in a post-RTM build of SQL Server 2008 R2 (or in 2008 with SP2+).
"But how do I access this database from my dev computer when I don't know the SQL server address, etc?"
I found the Marco database. It is on SQL Server that is located on an unmanaged web server account. The way to access the database is to use a Remote Desktop Connection, then use SQL Server Management Studio that is located on the server (not my dev desktop). The SSMS then found the server/database and voila, connected ... my confusion was in trying to connect using SSMS from my dev desktop directly instead of using SSMS located on the server via RDC ...
I have switched over to the 64bit Windows 7 and created a simple web app to test the connection to the database. I am using VS 2010 - plain asp.net web project and I am running the application from within VS.
I am getting this error:
"ORA-12154 could not resolve the connect identifier specified"
I also have a sample console application that tests the connection to the database, and it works fine.
After googling it some, I found that a lot of posts online refered to permissions so I set my C:/Oracle permissions to read/write/execute for my ASP.net account, NETWORK SERVICE, COMPUTER NAME. That still won't solve the issue. I checked that my web app runs under my domain\username account and that this account that the rights to read/write/execute to the C:\Oracle folder.
I even re-installed my VS to make sure that it is in C:\Program Files rather than C:\Program Files(x86)
Any ideas to why my web app doesn't see the connection string? (while the console app does)
Not sure what else I can do.
I am going to assume you are using the tnsnames.ora file to specify your available database services. If so connection errors usually come down to two things.
The application cannot find the TNS entry you specified in the connection string.
The TNS entry was found, but the IP or host is not correct in the tnsnames.ora file.
To expand on number 1 (which I think is your problem). When you tell Oracle to connect using something like:
sqlplus user/pass#service
The service is defined in the tnsnames.ora file. If I attempt to connect with a service that is not defined in my tnsnames.ora, I get the error you get:
[sodonnel#home ~]$ sqlplus sodonnel/sodonnel#nowhere
SQL*Plus: Release 11.2.0.1.0 Production on Mon Oct 31 21:42:15 2011
Copyright (c) 1982, 2009, Oracle. All rights reserved.
ERROR:
ORA-12154: TNS:could not resolve the connect identifier specified
So you need to check a few things:
Is there a tnsnames.ora file - I think yes because your console can connect
Is there an entry in the file for the service - I think also yes as the console connects
Can the application find the tnsnames.ora?
Your problem may well be number 3 - does the application run as a different user than when you run the console?
Oracle looks for the tnsnames.ora file in the directory defined in the TNS_ADMIN environment variable - If you are running as different users, then maybe the TNS_ADMIN environment variable is not set, and therefore it cannot find the file?
Had a similar issue, only my web app was fine and it was SQLPlus that was giving me issues connecting, and the ORA-12154 could not resolve the connect identifier specified error. I had 11g and 12 Oracle clients installed. My environment variables were all set to point at my 12 instance:
ORACLE_HOME = C:\oracle\product\12
PATH = C:\oracle\product\12\bin;....
TNS_ADMIN = C:\oracle\product\12\network\admin
There is also a registry entry required at HKLM\Software\Oracle\KEY_OraClient12Home1, a string entry of TNS_ADMIN with the same path as the environment variable.
I have a tnsnames.ora at both C:\oracle\product\11\network\admin and C:\oracle\product\12\network\admin. As far as I know, both my web app and the 12 SQLPlus client I was using should have been using all 12 version variables.
My troubleshooting steps:
Change all environmental variables above from 12 to 11.
Connect with 11g's SQLPlus (worked!)
Change all environmental variables above back from 11 to 12.
Connect with 12's SQLPlus again (worked!)
So I don't really know what caused 12's SQLPlus to stop connecting, but this kind of reset may work for someone, so thought I'd document it here.
I have an Entity Framework web application that works on my local machine, but this error appears when pushed to another environment. There are other non-Entity Framework applications that work, and I'm able to connect with sqlplus.
Using sysinternals Process Monitor shows that tns names file is not being loaded correctly:
Following the documentation I tried to add a section giving the location of the tnsnames file like so:
<configuration>
<configSections>
<section name="oracle.manageddataaccess.client"
type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.122.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342"/>
</configSections>
<oracle.manageddataaccess.client>
<version number="*">
<settings>
<setting name="TNS_ADMIN" value="C:\Oracle\product\12.1.0\client_1\Network\Admin"/>
</settings>
</version>
</oracle.manageddataaccess.client>
<configuration>
However, this resulted in an immediate 500 server error.
Further investigation showed that the dll I was packaging with the web application was version 4.122.1.0, while the Oracle client environment installed on the machine was 4.121.2.0. As explained in the Oracle EntityFramework package documentation
Note: If your application is a web application and the above entry was added to a web.config and the same config section handler for "oracle.manageddataaccess.client" also exists in machine.config but the "Version" attribute values are different, an error message of "There is a duplicate 'oracle.manageddataaccess.client' section defined." may be observed at runtime. If so, the config section handler entry in the machine.config for "oracle.manageddataaccess.client" has to be removed from the machine.config for the web application to not encounter this error. But given that there may be other applications on the machine that depended on this entry in the machine.config, this config section handler entry may need to be moved to all of the application's .NET config file on that machine that depend on it.
I attempted to add a separate version section in the .NET machine.config without success (there existed a section for version 4.121.2.0 and I added a section for version 4.122.1.0). After I removed the "oracle.manageddataaccess.client" section from the machine.config, the above addition to the web.config resolved ORA-12154.
Solution #1 summary:
Remove "oracle.manageddataaccess.client" from .NET machine.config
Give TNS_ADMIN configuration setting in web.config as above
Solution 2
While researching this problem I found that the TNS_ADMIN environmental variable was not set. I created a new environmental variable called TNS_ADMIN and set the value to "C:\Oracle\product\12.1.0\client_1\Network\Admin". I removed the web.config changes, and removed the "oracle.manageddataaccess.client" section from .NET machine.config, but still received ORA-12154. Only after I restarted the machine did this resolve the issue.
Solution #2 summary:
Create a new environmental variable called TNS_ADMIN and set the value to "C:\Oracle\product\12.1.0\client_1\Network\Admin"
Restart machine
Solution 3
I added an entry for the correct version in the registry and this resolved the issue:
HKLM\Software\Wow6432Node\Oracle\ODP.NET.Managed\4.121.2.0
The name of the key is TNS_ADMIN and this points to the folder containing the tnsnames file:
C:\Oracle\product\12.1.0\client_1\network
Not the C:\Oracle\product\12.1.0\client_1\network\admin folder.
There can be so many issues but if you are using oracle 10g , uninstall oracle 10g and also remove the value from registry and install oracle 11g. But if you are using oracle 11g , first go and check on registry if it is pointing to right home. Sometimes there can be more than one home because you install sql developer again and again . In that case either you can remove unnecessary home registry value or you can add tns and sql.net file to all of those home, that might resolve the issue. I resolved mine in that way.
I had the same issue. In my case I was using a web service which was build using AnyCPU settings. Since the WCF was using 32 bit Oracle data access components therefore it was raising the same error when I tried to call it from a console client. So when I compiled the WCF service using the x86 based setting the client was able to successfully get data from the web service.
If you compile as "Any CPU" and run on an x64 platform, then you won't be able to load 32-bit dlls (which in our case were the Oracle Data Access components), because our app wasn't started in WOW64 (Windows32 on Windows 64). So in order to allow the 32 bit dependency of Oracle Data Access components I compilee the web service with Platform target of x86 and that solved it for me
As an alternative if you have 64bit ODAC drivers installed on the machine that also caused the problem to go away.
If you are using LDAP, make sure that the environment variable "TNS_ADMIN" exists and points to the folder containing the file "ldap.ora".
If this variable does not exist, create it and restart Visual Studio.
Another obnoxious error type I've encountered in Oracle 11: entries in tnsnames.ora that don't begin at the first column of the line (' XXX=(...)' instead of 'XXX=(...)') and are parsed together with the preceding entry, making it malformed.
Like replaced orr misplaced tnsnames.ora files, this type of problem is easy to diagnose with the tnsping command-line utility: you pass it the name of a tnsnames.ora entry and it gives the complete text of its definition.
Please let me repeat what Stephen said since I missed it the first time myself. The TNS_ADMIN environment variable and ORACLE_HOME is set to C:\instantclient_11_2 and th tnsnames.ora file is in there. Found the answer on this link.
This error (and also ORA-6413: Connection not open) can also be caused by parentheses in the application executable path and a bug in the 10.2.0.1 or lower oracle client libraries.
You should either upgrade your oracle client library or change the executable path.
Further details see:
http://blogs.msdn.com/b/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx
http://social.technet.microsoft.com/Forums/de-DE/ab662d63-6385-4f73-b27f-d526048f601f/connecting-to-oracle-on-64bit-x64-machine
use process monitor and search for name not found log for tnsnames.ora file.
check your environment variables. if not valid than uninstall all oracle client and reinstall.
I had this error in Visual Studio 2013, with an SSIS project. I set Project, Properties, Debugging, Run64BitRuntime = false and then the SSIS package ran. However, when I deployed the package to the server I had to set the value to true (Server is 64 bit Windows 2012 / Sql 2014 ).
I think the reasoning behind this is that Visual Studio is a 32 bit application.
This is an old question but Oracle's latest installers are no improvement, so I recently found myself back in this swamp, thrashing around for several days ...
My scenario was SQL Server 2016 RTM. 32-bit Oracle 12c Open Client + ODAC was eventually working fine for Visual Studio Report Designer and Integration Services designer, and also SSIS packages run through SQL Server Agent (with 32-bit option). 64-bit was working fine for Report Portal when defining and Testing an Data Source, but running the reports always gave the dreaded "ORA-12154" error.
My final solution was to switch to an EZCONNECT connection string - this avoids the TNSNAMES mess altogether. Here's a link to a detailed description, but it's basically just: host:port/sid
http://www.oracledistilled.com/oracle-database/oracle-net/using-easy-connect-ezconnect-naming-method-to-connect-to-oracle-databases/
In case it helps anyone in the future (or I get stuck on this again), here are my Oracle install steps (the full horror):
Install Oracle drivers: Oracle Client 12c (32-bit) plus ODAC.
a. Download and unzip the following files from http://www.oracle.com/technetwork/database/enterprise-edition/downloads/database12c-win64-download-2297732.html and http://www.oracle.com/technetwork/database/windows/downloads/utilsoft-087491.html ):
i. winnt_12102_client32.zip
ii. ODAC112040Xcopy_32bit.zip
b. Run winnt_12102_client32\client32\setup.exe. For the Installation Type, choose Admin. For the installation location enter C:\Oracle\Oracle12. Accept other defaults.
c. Start a Command Prompt “As Administrator” and change directory (cd) to your ODAC112040Xcopy_32bit folder.
d. Enter the command: install.bat all C:\Oracle\Oracle12 odac
e. Copy the tnsnames.ora file from another machine to these folders: *
i. C:\Oracle\Oracle12\network\admin *
ii. C:\Oracle\Oracle12\product\12.1.0\client_1\network\admin *
Install Oracle Client 12c (x64) plus ODAC
a. Download and unzip the following files from http://www.oracle.com/technetwork/database/enterprise-edition/downloads/database12c-win64-download-2297732.html and http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html ):
i. winx64_12102_client.zip
ii. ODAC121024Xcopy_x64.zip
b. Run winx64_12102_client\client\setup.exe. For the Installation Type, choose Admin. For the installation location enter C:\Oracle\Oracle12_x64. Accept other defaults.
c. Start a Command Prompt “As Administrator” and change directory (cd) to the C:\Software\Oracle Client\ODAC121024Xcopy_x64 folder.
d. Enter the command: install.bat all C:\Oracle\Oracle12_x64 odac
e. Copy the tnsnames.ora file from another machine to these folders: *
i. C:\Oracle\Oracle12_x64\network\admin *
ii. C:\Oracle\Oracle12_x64\product\12.1.0\client_1\network\admin *
* If you are going with the EZCONNECT method, then these steps are not required.
The ODAC installs are tricky and obscure - thanks to Dan English who gave me the method (detailed above) for that.
Use this link.on Microsoft Support
I gave permission to IUSR_MachineName user on oracle home folder and I was able to resolve the problem
If your password contains # then you have to change it, most of Oracle products don't accept the # character in password
In my case, the reason for this error was that I was missing the tnsnames.ora file under client_32\NETWORK\ADMIN
Go to Control panel -> search for 'Environment Variables' and click on 'edit the system Environment Variables for your account'
make sure it is not 'edit Environment Variables for your account'
Click on 'Environment Variables' button then on 'System Variables' list click on 'New'
Fill the boxes as following:
Name: TNS_ADMIN
Value: [path of tns file on your PC], ex: D:\app[userName]\product\11.2.0\client_1\Network\Admin
Restart You PC [Important to apply changes]
In my case, I changed the connection string from user/pass#19.168.x.x:portNum/SID to user/pass#alias where alias is the alias provided in the tnsnames.ora file and it worked.
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.