Recently at work, I was tasked with implementing a URL shortener for my department to use internally. We're largely a ASP.NET MVC shop (whenever possible), so naturally I gravitated towards the open source http://shrinkr.codeplex.com/. However, Entity Framework is foreign to me and I have no idea how to actually get this up and running. I've created a SQL08R2 database for it, and passed it (what should be) a valid connection string:
<add name="Shrinkr" connectionString="Data Source=sql08r2.myFQDN;Initial Catalog=Shrinkr;Integrated Security=True" providerName="System.Data.SqlClient" />
Building and running it in Debug mode yields the following error:
Of course, my database is empty and has no table structure. I just can't figure out how the heck to get the database populated with the correct initial schema. I've heard that EF can autogenerate the database, but I'm not sure if that applies in this case. If there is a SQL file in the Shrinkr release to get the DB up and running, I sure as heck can't find it. I've been banging my head against my desk for a few days now on this and I can't figure out what I'm missing!
I just downloaded the source, and there is a create.sql script in the Database folder. Sounds like that is what you're looking for.
Related
I'm getting this error please help me :(
The context is being used in Code First mode with code that was generated from an EDMX file for either Database First or Model First development. This will not work correctly. To fix this problem do not remove the line of code that throws this exception. If you wish to use Database First or Model First, then make sure that the Entity Framework connection string is included in the app.config or web.config of the start-up project. If you are creating your own DbConnection, then make sure that it is an EntityConnection and not some other type of DbConnection, and that you pass it to one of the base DbContext constructors that take a DbConnection. To learn more about Code First, Database First, and Model First see the Entity Framework documentation here: http://go.microsoft.com/fwlink/?LinkId=394715
Here's my connection string:
connectionString="metadata=res://*/dbEspesyalTea.csdl|res://*/dbEspesyalTea.ssdl|res://*/dbEspesyalTea.msl;provider=System.Data.SqlClient;provider connection string="data source=tcp:[hidden].database.windows.net,1433;initial catalog=dbET;persist security info=True;user id=[hidden];password= [hidden];MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient"
This is an application configuration problem.
The exception is telling you that that
connectionString="metadata=res://*/dbEspesyalTea.csdl|res://*/dbEspesyalTea.ssdl|res://*/dbEspesyalTea.msl;
is not your connection string. And somehow you've configured the deployed application to use a plain SQL Server connection string and not an "entity connection string" (ie with the edmx file locations).
So double-check and then log the connection string your deployed application is using.
I've recently been placed on a project using EF 6.0 and Code First principles. The ApplicationDbContext is loaded from this connection string:
name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Integrated Security=True" providerName="System.Data.SqlClient"
As you can see there is no specified Initial Catalog, and yet the data is being stored SOMEWHERE? I have searched the LocalDb instance through the file system, MS VS 2013 and SQL Server Management studio.
The problem is the current devs have created a substantial amount of dummy data we don't want to lose. Does anyone know where this data is being stored and/or how it can be retrieved?
Many thanks.
When a user opens a connection without specifying the DB (aka catalog), it gets a connection to his default DB.
If you have not changed the configuration it will most probably be the master DB.
You can confimr this using SSMS. Connect to your server, go to Security > Logins, choose the login used to connect to the DB (as you're using Integrated security it must be the user which starts the app, or the application pool user if it's a web app), right click, choose "Properties", and, in the General panel, at the bottom, you'll see what the default DB is.
NOTE: perhaps I'm not using the exact wording, as I have a localized SSMS, and I am supposing what the translation is.
I am trying to upgrade a slightly modified version of aspdotnetstorefront from 9.0.3 to 9.3.0.0. I have installed the store on my local machine (Win 7, IIS 7.5, SQL Server 2012).
When I run the site, I note 1) that there are missing product images on the home page and 2) if I click to go to a category or product I get the InvalidRequest page.
When I run Debug on the site using Visual Studio 2012, I see the error causing the invalid request is "Could not find stored procedure 'dbo.aspdnsf_GetMappedObject'." (I was going to post a screen grab here, but I don'e have enough reputation points.)
If I look at the Database it self, I see that the stored procedure does in fact exist. (Same here no screen as I'm not allowed.)
The above makes me suspect that my data base connection is incorrect. It is as follows:
<add key="DBConn" value="data source=localhost;initial catalog=505916_adn_upgrade;user id=XX;password=XXXXXX;persist security info=True;packet size=4096" />
however, I also have a 'clean' install that seems to work, it's database connection is the same with exception of the database name, user, password, which makes me think the connect ion IS correct?
I am pretty much a newbie to ALL of this stuff, so any suggests woul dbe most appreciated.
I finally gave up and rebuilt the entire database - I had added the missing stored procedure only to find that there were MORE missing stored procedures. Obviously, something went wrong when the database was set up. It is working locally now.
I've been trying to create an ASP.net - MVC app that uses entity framework to connect to an Azure database.
I used a database first method to try and create the Model, I was able to connect to my azure database and successfully create the model.
Everything was working perfectly and I was able to retrieve my values from my azure database then I tried to publish the website to an Azure website. The website works fine and I have the website registered as able to use the azure database. When I click on the button that hits the controller to access the database I then get "Sorry, an error occurred while processing your request."
When I looked into this a bit more I seen that when I created my Entity Data model using the wizard it created a connection string to a local db for my entity connection settings. I'm guessing this is saving some entity framework settings but my problem is obviously when I publish the website to Azure it can't access this local db.
Any suggestions on how to either get this DB onto Azure or avoid using this extra database?
Thanks
This is the best tool to migrate your local database to Azure. Before publishing your site change the web.config to point to the Azure database. It will solve your problem.
Like you already explained, it seems that you web.config still points to your local database. Try to look at your web.config and see if you have connection strings pointing to .\SQLExpress, localhost\SQLExpress, ".", ...
Then, like Geenthanga's explains, you need to modify this value before deploying (it should point to your SQL Azure database instead). But you shouldn't do this manually! Instead, consider using web.config transformations, as explained here: Web Deployment: Web.Config Transformation.
This way you can have 2 web.config transformation files:
Web.Debug.config: This file would contain the transformations to add the connection string pointing to your local database.
Web.Release.config: This file would contain the transformations to add the connection string pointing to SQL Azure.
I am looking to reference my database file in my unit test project. This is an ASP.NET MVC app.
Please note: I know I should not be accessing the database in my unit tests but this is for a quick fix on one test that I need to have pass just now.
After the next milestone I will be mocking the database access methods etc.
So here is my connection string in my mvc app web config and the unit test ap.config files
<add name="DBConnectionString" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\DB.MDF;Integrated Security=True;User Instance=True"
providerName="System.Data.SqlClient" />
When I run the test I get an error:
Test method
ED.Tests.Controllers.CandidateControllerTest.PersonalDetailsStepPostShouldRedisplayIfNoSurnameSupplied
threw exception: System.Data.SqlClient.SqlException:
An attempt to attach an auto-named database for file C:\Users\Desktop\ED\TestResults\LAPTOP-D 2009-07-22 18_16_20\Out\DB.MDF failed.
A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
It seems to me the connection string is wrong but I'm not sure how to set the path properly. I have tried adding \..\.. and the directory names etc.
MSTest will run your unit test assembly in a completely different folder on every test run. The idea is that each run is a completely isolated case from previous and subsequent runs. It's actually kind of a pain to tell it to copy data files along with the rest of your application. You need to right-click on your solution (not your project), choose add, create a new test run configuration. Then you need to edit the test run configuration and specify which files will be copied to the test execution folder. There should be a sibling directory to your solution directory called TestResults which contains the folders used for each test run.
you can simply reference localdb like this:
<add name="DefaultConnection"
connectionString="Server=(localdb)\v11.0;Database=WebPortalDb" providerName="System.Data.SqlClient"/>
where WebPortalDb is your database name.
Comment to Craig's answer: It shouldn't be a pain to deploy extra data files for unit test execution. You can use DeploymentItemAttribute (Microsoft.VisualStudio.TestTools.UnitTesting) at class or method levels to specify which files need to be copied prior to running those tests.
The best answer is not to connect to a database at all with some Unit Tests, and instead mock the database. However, you may need to refactor existing MVC code to get to a point where you CAN mock a database dependency, and you should never refactor until your code is wrapped in some tests. So in that situation, yes - you'll probably need to connect your test project to the database, at least for a while until you decouple everything enough to enable mocking.
So in my instance I was using ASP.Net MVC 5. This meant I could get the necessary Entity Framework config added to the Unit Test Project's app.config file simply by Right-Clicking on the Solution file, Managing NuGet for Solution, and adding EF to the test project.
Then adding the connection string from the MVC project's main Web.config file NEARLY worked, with the minor tweak that I had to remove the final part of the string that said:
AttachDbFilename=|DataDirectory|<<MY_DATABASE_NAME_AND_ID>>.mdf
As I say, creating 'Unit' tests that connect to a database is not the way to go, so this will only be a temporary measure. But the code needs refactoring to get it to a mockable state, and (s)he who refactors without at least a few tests to prove the refactoring hasn't broken everything is cruising for a bruising.