I am going to try and explain this issue as clear as I can.
I start with two projects:
Project One: Data model
A repository class that wraps a DbContext that has a single DbSet: RentalListings
This DbContext uses the default settings, so that when I save changes it saves to local DB.
Project Two: Console App
Contains a console application that when runs, instantiates an instance of the repository class.
Then it creates multiple "RentalListings" and saves them to the repository.
So far so good. After running the console app I check the local DB SQL object explorer, and my repository class has successfuly saved to this db.
Now, I want a way to access this inserted data via a Web API. So I add:
Project Three: Web API
I create a new controller class and add a single GET action method to fetch all listings.
When I run the API project, I can hit the action method, which looks like:
[HttpGet]
public IEnumerable<RentalListing> GetAllListings() {
StatsRepository repository = new StatsRepository(new StatsContext());
return repository.GetRentalListings();
}
via the correct URL. However I am getting the following error returned:
Unable to complete operation. The supplied SqlConnection does not specify an initial catalog or AttachDBFileName.
Now, from searching the web I think the issue is that it doesn't know how to access the database??? And that I should specify a connection string in the Web.config file in my Web API project.
Questions:
1) How did my console app, that doesn't specify a connection string, create a mdf database using my repository class?
2) Why doesn't the same work for my web api project? can't it just use the repository to fetch the database, just like the console app did?
Look forward to hearing the replies, thanks in advance!
Q :1. How did my console app, that doesn't specify a connection string, create a mdf database using my repository class ?
A :1. It is by default.If you didn't specify the connection string on console app then it uses your context class namespace plus name of the context class to create a db.
e.g.
Context class namespace = MyDbContextNameSpace
Name of the context class = MyContext
Then your DB name will be like this : MyDbContextNameSpace.MyContext.
Note : If SQL Express is installed then the database is created on your local SQL Express instance (.\SQLEXPRESS). If SQL Express is not installed then Code First will try and use LocalDb ((localdb)\v11.0).
You can read more about it here : Building an Initial Model & Database
Q :2. Why doesn't the same work for my web api project? can't it just use the repository to fetch the database, just like the console app did?
A :2. When you talk to EF through Http/s,you have to provide the connection string on web.config file. Otherwise EF doesn't know how to do that.That is by design.
e.g.
MyContext.cs
public class MyContext : DbContext
{
public MyContext() : base(“name=MyContextConn”)
{
}
public DbSet<Blog> Blogs { get; set; }
}
web.config
<connectionStrings>
<add name=“MyContextConn“ connectionString=“conndetails”
providerName=“System.Data.SqlClient“ />
</connectionStrings>
The DbContext class can definitely be responsible for 'specifying a connection string', as you put it, but the reason it is most commonly found in a config file is so that different connection strings can be specified for different configurations. For example, your Web.Debug.config connection string might point to an instance of SqlExpress that you have installed on your development box and the Web.Release.config connection string might point to a Sql instance contained in Azure.
Specifying a connection string in your config file isn't necessarily going to fix the issue. The connection string can specify a username and a password. If you put those in to the connection string then it will most likely work. For example <add name="DefaultConnection" connectionString="Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;" providerName="System.Data.SqlClient" />
The issue you are experiencing is most likely due to the fact that the console application is running under the context of the Windows user launching the application. It is using those credentials to connect to the database. I'm assuming that your console, webapi app and sql are all installed/running on the same machine and that your user is the only one that you use to log in to sql(again assuming you are using SSMS). The web application though is most likely being run through IIS or IISExpress which is run under a different context by default(I believe IUSR for IIS). If you would like to have your connection string use integrated security(to keep your username and password out of your configs -- which is generally considered a good practice) like this: <add name="DefaultConnection" connectionString="Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=True" providerName="System.Data.SqlClient" /> then you would want to setup the context that the application is being run under by updating the user the apppool is running under. You would do this by updating the app pool identity and then making sure that the web application is using that app pool.
Hope this helps.
Related
I've been looking through questions on here but have yet to come across anything that deals with my problem, apologies if this is a duplicate and I've missed something.
I have an ASP.Net MVC project with Entity Framework Code First.
In my Dbcontext I have;
public Context() : base("DatabaseName")
{
System.Data.Entity.Database.SetInitializer(new MigrateDatabaseToLatestVersion<Context, Configuration>());
}
In my web config I have;
<connectionStrings>
<add name="DatabaseName" connectionString="connsection string is here"/>
</connectionStrings>
When my application is deployed, I get the error
'CREATE DATABASE permission denied in database 'master'.' as soon as
it tries to access the Context for the first time.
What I don't understand is how to stop it trying to create a database and just use the connection string that I have given it. The database already exists (It's on shared hosting so I don't have much control over it) and I know the connection string is correct as I have Hangfire installed in the same application, using the same connection string and it has successfully created the tables but for some reason EF doesn't create the tables in the database and instead tries to create one, which it cannot do.
Entity Framework is installed in the same project as the config file, in fact, it's a single project application.
I've tried creating another database and adding a second connection string in case Hangfire was preventing EF from using it but had the same issue. I've also tried putting the full connection string directly into :base("") on the context, but it has no effect.
try getting connectionString by name
public Context()
:base("name=DbConnection")
{
}
in Web.config file add
<connectionStrings>
<add name="DbConnection" connectionString="Data Source=serveraddress;Persist Security Info=False;User ID=usename;Password=pass;Initial Catalog=databasename" providerName="System.Data.SqlClient" />
</connectionStrings>
I'm new to SQL Server and I'm trying to learn MVC for some school projects. I have a program that creates a DB with Code-first approach in Entity framework. But when I tried to find it in my SQL Server Management Studio I didn't find it. So I checked in Visual Studio 2013 "SQL Server Object Explorer" and find that I have 2 SQL Server instances. Since I'm only writing to one SQL Server instance I decided to delete the one at the top. But as soon as I restart my program it's there again. How can I only have 1 instance to write to ? The DB I'm writing to is the one at the bottom "TestDB".
Edit
Adding DB Context by request
In Your code currently EF not use at all ConnectionString you expecting.
This is how this should look like:
<connectionStrings> <add name="UserContext" connectionString="Server=.\SQLEXPRESS; User Id=Seeya; Password=;Initial Catalog=CodeFirstTest; Integrated Security=True" providerName="System.Data.SqlClient" /> </connectionStrings>
and now Your Context:
public class UserContext : DbContext
{
public UserContext()
:base("UserContext")
{
}
//REST OF YOUR CODE
}
The other instance is because EF craeted SQLCompact, when nothing was given as parameter to base method of Context.
After I deployed my mobile service to Azure, calls to the service fails because of this error:
No connection string named 'ApplicationEntities' could be found in the application config file.
The error only occurs on Azure side. When I test the service locally, the connection to the remote database works without a problem.
I separated my solution into several projects:
Web Api
Business Logic
Data Access (contains the DbContext, database first)
Common (contains the entities generated by EF)
As I always do, I copied the connection string generated in my app.config of the DataAccess Assembly into the connectionStrings-Element of my web.config (Web Api project).
<connectionStrings>
<add name="ApplicationEntities" connectionString="<the connection string>" providerName="System.Data.EntityClient" />
</connectionStrings>
In the web deploy settings, I selected the connection string for "ApplicationEntities". I tested it with and without the option "Use this connection string at runtime (update destination web.config). I always get the same error.
Then I got curious and logged the connection strings available via the ConfigurationManager with something like this:
StringBuilder sb = new StringBuilder();
for (int i = 0; i < ConfigurationManager.ConnectionStrings.Count; i++)
{
sb.AppendLine(ConfigurationManager.ConnectionStrings[i].ConnectionString);
}
trace.Info(sb.ToString());
I got two connection strings:
data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true
Data Source=theserver.database.windows.net;Initial Catalog=thedb_db;User ID=theuser;Password=thepassword;Asynchronous Processing=True;TrustServerCertificate=False;
The username and password is strangely different from the username and password stated in the management portal.
Also the EF-Metadata information get lost.
I get this connection strings when testing locally:
data source=.\\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true
metadata=res://*/DataContext.ApplicationEntities.csdl|res://*/DataContext.ApplicationEntities.ssdl|res://*/DataContext.ApplicationEntities.msl;provider=System.Data.SqlClient;provider connection string=\"data source=theserveraddress,1433;initial catalog=thedb_db;persist security info=True;user id=theusername;password=thepassword;MultipleActiveResultSets=True;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;App=EntityFramework\"
I expect to get the same connection strings when running on Azure. Any idea what's going wrong?
Update:
I just went for remote debugging the service (see here). As I opened the downloaded publish-profile in my text editor, I discovered that there is an attribute SQLServerDBConnectionString - containing the connection string that always gets forced when deployed - with the same username and password I'm not aware of that it exists.
I tried to overrwite this connection string but it did not help. That connection remains the active.
Update 2 / May 29th 2014:
Seems that in the meantime the error has been fixed by the azure mobile team. Still running the same code using the database first approach and it's working now. Thanks a lot!
I have myself tried using DB first approach with dot net backend mobile services & ran into same sort of problems as you. Digging around further, following is my observation :
The azure mobile service with dot net backend must use code first approach only. This generates a specialised connection string with metadata (starting with res:)
The name of the connection string has to be the same as it is when you download the default sample todo app I.e. Ms_TableConnectionString.
There is an option in azure websites to select custom SQL provider to help make a custom connection string, this option, however, is not available for dot net backend mobile service in Azure Management portal.
P.s. Posting as answer because I don't have a enough points to comment..
Just wanted to give an update that I have been looking at this for some time and think I for the first time see it too. I don't know what is going on but wanted to let you know that we are indeed looking at it.
Henrik
(I don't have enough points to comment so having to do this as an answer)
Henrik, I have this same problem. If I ftp on to the box I can see that the web.config has the correct connection string but it fails as trying to use the username in the SQLServerDBConnectionString property (OoWUqr****Login). Is it possible you could let me know in what order it is looking for connection strings and where?
And if it can't stop it using the other user is there a way I can permission them for the correct database through mobile services?
Thanks
F
I have gone through the steps to publish my web app using database first on the azure portal.
However, when I publish I get this error message:
Code generated using the T4 templates for Database First and Model
First development may not work correctly if used in Code First mode.
To continue using Database First or Model First ensure that the Entity
Framework connection string is specified in the config file of
executing application. To use these classes, that were generated from
Database First or Model First, with Code First add any additional
configuration using attributes or the DbModelBuilder API and then
remove the code that throws this exception.
My connection string in the web.config after it has been modified by publish:
<add name="MySiteEntities" connectionString="metadata=res://*/MySite.csdl|res://*/MySite.ssdl|res://*/MySite.msl;provider=System.Data.SqlClient;provider connection string="data source=tcp:**********.database.windows.net,****;initial catalog=MySite;user id=username#**********;password=*******;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
My context (generated by edmx):
public partial class MySiteEntities : DbContext
{
public MySiteEntities()
: base("name=MySiteEntities")
{
}
...
I am very confused becuase it seems like entity framework is trying to use code first rather than database first.
UPDATE:
I just tried using the same connection string locally and the web app seems to run fine. The web app does connect to the remote database fine. It is only when I publish to azure it fails.
Read my answer to a similar question at Entity framework work locally but not on azure.
If you made the same "mistake" I did, this is what's happening ... the Azure-deployed app isn't finding your connection string "MySiteEntities" inside your web.config. Instead, at the time your created your Azure Web Site (or Cloud Service or whatever), you created an associated Azure SQL Database and gave its connection string the exact same name, "MySiteEntities". This latter connection string is a "plain" connection string without Model/Database-first metadata references, and so is being treated as a Code-First connection by EF, which then complains about the conflict. See Code First vs. Database First for an explanation of this distinction.
It should be:
<connectionStrings>
<add name="MyDatabaseModelEntities"
connectionString="metadata=res://*/MyDBModel.csdl|res://*/MyDBModel.ssdl|res://*/MyDBModel.msl;
provider=System.Data.SqlClient;
provider connection string="
Data Source=<provideServerName>.database.windows.net;
Initial Catalog=MyDatabase;
Integrated Security=False;
User ID=<provideUserID>;
Password=providePassword>;
MultipleActiveResultSets=True;
Encrypt=True;
TrustServerCertificate=False""
providerName="System.Data.EntityClient"/>
</connectionStrings>
I changed connection string to remote (Azure) on my local web.config, then remove all set connection strings during publishing and publish web.config. It rewrites remove web.config. Then return connection string on local web.config to local connection. It works fine now.
I have a database and a C# class library which acts as a repository for accessing objects from the database using Entity Framework. When trying to use this repository assembly in other projects I am running into difficulty; My working assumption is that this it due to the Connection String as I am getting the following error:
The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.
I have added an App1.config file to the project and added the same connection string I had successfully used when creating the database:
<add name="EDSEntities" connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SQLite;provider connection string='data source="C:\Documents and Settings\hmay\My Documents\My Projects\Timetabler\DataSets\EDS.db";foreign keys=true'" providerName="System.Data.EntityClient" />
.... but it doesn't work. I don't understand the connection string very well and wondered if there is something else here I might need to tweak?
Regards
Adding app1.config would not do anything. App.config and web.config are specially named files and they need to be named exactly that. However if you use your library in multiple apps i would refactor it.
Change the DbContext class to have a single constructor that takes a connection string and push the responsibility for creating the connection string into the app rather than the library. It is not good to have a class library that expects your app to have a particular named entry in the connection strings section of its config.
try trimming metadata references to metadata=res://*