I have an ASP.NET MVC 5 web app. I have connected to a database on localDB ("MyWebAppDatabase"), which already contains many tables. I am accessing this using ADO.NET Entity Framework, and this is all working great.
However, I would like to add a table which references users who use the website: I have a "Subscription" table and would like to associate it with an ApplicationUser. The problem is that the tables containing user information are stored in a separate database (which was automatically generated by the Visual Studio when I created the project under the DefaultConnection context), and I don't know how I can perform this association.
What is the best way to go about this? I thought the ideal solution would be if I could move the tables that ASP.NET automatically created for application users into MyWebAppDatabase - then I can easily update the database with the correct tables and foreign keys. Is this correct? If so, how would I go about doing this? I'm not entirely sure where the database is for the application users (I couldn't decipher it from looking at Web.Config and reading the DefaultConnection connection string) and I don't really understand how I would be able to migrate the tables.
Thank you all for your help!
Ideally if you can move the tables into a single database you will get the best performance, otherwise you will have to do all of the JOIN's in memory in the application. You can't make foreign key references across database unfortunately.
If you point the connection string for the ASP.NET Identity to the same database that your Subscription table is located in and run the application and create some users it should create those tables automatically.
Related
I know that each time a user registers in my ASP.NET MVC application the ApplicationUser class is used to create the new record and put it in the database.
I was wondering if it's okay to add properties to that class for example I want the model to have a column in the database for DateOfBirth. Then use that class(model) directly in my application when I have to do some business logic things, database queries and similar stuff. Or is it more correct to create a new table in the database called let's say ApplicationAccounts, that saves the general info about the account. Each ApplicationAccount will be associated with a ApplicationUser(1 to 1 relation) and be somewhat of a buffer in the communication with the real accounts. Does that make sense?
I would go with the second option : create your own table, link them up in a one to one relationship using the UserID as a unique foreign key and then go from there.
One note here, it is perfectly normal for the model you need for the views to be different from the database model, this is because your db model can hold a lot of data that your view doesn't actually need. You might want to consider having separate models and use something like Automapper for a quick translation from one to another.
I am trying to create a solution for a web application (that also contains the database as a database project) and then deploy it from TFS using web deploy for the application and DACPAC for the SQL database.
Unfortunately the database is referencing another database using 3-part names:
Select * From Database1.dbo.Table1
This forces me to import the referenced database as a project in the solution for the application that references it and set it as a reference in the other project, as seen in the picture below:
The problem is that Database1 is referencing Database2, but Database2 is also referencing Database1.
However when I try to do this I get the following error:
I have searched online for a solution and found two:
1) Using composite projects to create another 3rd project that contains the references between the two databases and then make this project reference the other two.
See this link: Composite projects solution
2) Replacing all the 3-part names queries to dynamic SQL, such as this:
EXEC('Select * From Database1.dbo.Table1')
None of this solutions is good for me as I don't just have two databases referencing each other, but many databases referencing a central database that references them back, as seen in the schema below:
The first solution would require that I import all the databases into the solution of each application (as they are linked to each other via the Central Database). Also there would be the circular reference error for each pair of projects (Database, Central Database).
The second solution would work as the queries would be seen as strings and would not require me to reference the Central Database in the solution, however I do not like the idea of having so many dynamic queries. Also it would be way to much work to replace all queries with dynamic SQL in each application database.
I would like to know if there are any other solutions beside the two I have mentioned.
The right way to solve the circular references problem is using the composite projects.
In general the "trick" consists to isolate all the shared objects (and the ones referenced by these; eg. a shared view and all the tables/functions used in its definition) in a composite project for each database.
In this way each database will be defined by a couple of database projects: one containing the objects used only inside it (base) and one containing all the objects to be shared with the other databases (shared).
Then you have to link a base database project with the shared one whose object are needed in its definitions.
One picture is worth a thousand words:
The dashed lines represent the "Same database" references (composite project). The solid ones are "regular" references.
I've updated my blog post with a generic case:
SSDT: How to Solve the Circular References Issue
You can also create a dacpac out of the existing database and add that dacpac as the database reference. We did that using a "Schema" folder to store all of the dacpacs and updated/referenced those as needed.
http://schottsql.blogspot.com/2012/10/ssdt-external-database-references.html
You can create another project that can be referenced Database1 and Database2 and this project handle calling between the two projects.
and let this project communicate with web application.
When I remove tables used in my Azure database (of course after removing the entities), I just use DROP TABLE TABLENAME. This has a bad effect. When I run the mobile service by just starting the browser, I get an Error 500 when I add a new record (of an existing table of course) with my TableControllers. Apparently, I did something wrong. It can be "solved" by creating a completely new database and use this one in my mobile service. The Seed method ensures that the right tables exist (and only the right tables) and everything works fine.
What is the best way (to prevent errors) when removing tables in a database used in Azure Mobile Services. Creating a completely new database seems to be a bit overdone and unneeded.
My first instinct is that it's an issue with Entity Framework. It doesn't generally play nicely with people touching the database. If you looked through your log, you'd probably see Entity Framework issues.
Take a look at this Azure Doc: http://azure.microsoft.com/en-us/documentation/articles/mobile-services-dotnet-backend-how-to-use-code-first-migrations/
It discusses how to enable code first migrations - I won't elaborate here because there are a couple of steps.
Essentially, the problem is that Entity Framework takes a number of dependencies and when those dependencies change, it just falls over on itself. Let me know if that doesn't help you.
I have started working on an existing frontend MS Access application built with VBA. It is linked to a backend Access database. So basically there are two Access databases - one frontend and one backend.
Because of the nature of the work involving vehicles, each user has their own copy of identical database with their individual data stored in backend. Constant Access to one backend db via internet is not really possible as the users are able to connect to internet (network) once a day only. Right now we just copy each backend database via ftp and store it as usr_backenddb_date.accdb
Backend databases contain around 16 tables with most of them containing an autonumber field as a primary key. Further tables are connected with each other referencing the primary key as a foreign key. I would ideally like to create a function in vba that lets me select the database and merge all the data from that database to an identical central database. For the initial part, I am thinking of doing something like this How to merge two identical database data to one? with possibly trying to cascade the change in autonumber field so the references remain intact.
I wanted to know if this approach is doable or if anyone has any other ideas and suggestion that I can look into.
Every now and then when I'm browsing data in a database, I get tired of writing ad-hoc queries to join in the various tables I want to see, and I go looking for an app that will:
Allow me to follow foreign key relationships
Automatically display tables in a tree-like format based on relationships
Compose views by automatically joining on foreign keys
I know this can be done because I wrote (and lost) such an app many years ago, but I can't seem to find anything out there. The closest I've seen is generated "scaffolding" such as RoR and MS Dynamic Data.
You could try the "Data Browser" included in the tool Jailer (Screenshots). It allows you to navigate through the database based on relationships.