I just try to set up a database project in Visual Studio 2010. We have one database, that contains a lot of stored procedures. Unfortunately those procedures accesses quite a lot of other databases (30+), so I get a lot of "unresolved references" errors.
At the moment I see two possibilities to solve my problem:
Add database projects to my solution, till I have all the errors resolved.
Create a lot of schemas for all my databases and add them as reference.
Both possibilities are a lot of work, especially as there can come a lot more databases in the future. My dream would be, that I can just add the whole server as a reference. Is that possible somehow? Are there any other solutions I don't know of?
This might help you. I found a article about referring databases here and this explains how to add multiple database project here
Hope this helps
This might not be the answer you are looking for, but you could setup one database to carry the references to the other databases via. "Server Objects -> Linked Servers" and change the code for the sp's to run through the 4 name quantifiers.
This would give you the added benefit of having the databases you depend on not hard coded.
Hope this is usefull to you.
Related
I'm extremely new to programming. Just above school level. I created a project using EF Model First only to realize after I cannot get it to use SimpleMembership for Login, etc.
I wanted to try and solve this problem whilst remaining model-first as I asked here: https://stackoverflow.com/questions/36552439/could-someone-explain-this-code-to-me-ef-model-first-mvc
However, due to lack of response I'm considering just migrating the project to code first. I know that it is possible but I've been following tutorials online to no avail.
Could someone please explain to me how to properly move to code first. I'm even willing to recreate the program if necessary as long as it does not take too long.
I'd really appreciate some help.
Thanks
This really has been answered here.
I think you should really consider moving to ASP.NET Identity Membership, it's much more robust and has plenty of nice features without being difficult to manage. This is a really nice tutorial.
As for EF Code/Model first, you're thinking of them as something that defines your project; but really, they define a database CONTEXT. In other words, you can use both! Now don't get crazy, things can get sloppy quickly. But there is nothing that stops you from pulling in an existing set of tables and building models from them, but then adding another context to promote your classes into a database.
If you think of it as "switching" your project, you're getting it backward. And regardless, to get your models and database to sync, you need to either migrate your models or import your tables into EF. But it's a specific action you take, nothing happens magically. You COULD write your classes to perfectly mirror your database, create your EF models, and everything would work without you doing any direct connection (though you'd have a bit of a migraine afterward).
So don't worry about moving from one to the other. Just add a new context if you have a specific need to manage classes across different contexts.
But seriously, look at ASP.NET Identity to make all these problems go away...
Whenever I Import I find lots of errors that since the database hasn't been worked with this tool, we did not have to fight case sensitive issues, nor views with unreferenced tables and a lot of other stuff that didn't worry us when we were on DevEnv.
Beacuse of this, I resolved to try working somewhat disconnected as a transitional state. but without loosing the TFS code repo or issue tracker.
Is it possible to work on sqlprojects and be able to validate and deploy code without having to import the database into the proj?
If it is, how?
#Edit:
Ok, so I've been asked to maintain the self DB reference inside the queries from within SP's, since DTSs execute some of those SP's, and it should evaluate the references without error.
(I'll be posting more stuff.)
I'm fairly new with EF and got myself rather confused about what's going on with my solution.
I'm in the situation where my code appears to be working however the changes aren't being written to the database that I would expect.
I'm using Web Developer 2010 and SQL 2008, code first approach but choosing to make my own changes in the database and manually ensure my classes match correctly.
Things seemed ok until I came across an error where the db hash wasn't what entity framework was expecting, so I looked at modelBuilder.Conventions.Remove(); which wasn't available - it seems that's not around in the later versions. So, I figured if the later versions doesn't do this check, I'll go ahead and remove my reference to EF 4 and put the 4.3 dll in it's place. I think I also ended up deleting and renaming my database. That didn't work, so I followed up on something I found on Scott Gu's blog about naming your dbContext the same as the database, which seemed to help.
However I'm now getting the most bizarre scenario. My code is running, the data is saving, but it's not saving to my database. In fact I'm running a profile trace on the db and it doesn't even seem to be trying to connect. I can change my connection string to something invalid too, but my code will happily run, storing the data #somewhere#
Any ideas what's going on? Might it be using a local database or cache that I'm unaware of? Should I just start my small project again and pretend this never happened? That'd be the professional approach, right?
I would suggest to use Database first approach, if you have your Database set, or want to have maximum control over database.
When you use the Code First EF approach and just point to ./SQLEXPRESS, EF nicely builds your tables for you, defines all the fields, etc.
But it doesn't seem to work that way when you direct your connection string to add an .MDF file in /App_Data instead. Is that working as intended? The tutorials I'm finding on this, such as this one, show the tables in the .MDF being created by hand.
But I have not seen any documentation anywhere plainly state that Code First EF will build your tables one way but not the other, so I'm frankly just confused. Any illumination or advice on this would be greatly appreciated!
ETA: Okay, I see that this tutorial I linked is for the database-first approach, not code-first. In other places I'm reading that EF should, in theory, populate an App_Data/.mdf file the same way. But it still won't for me; if I give it an empty .mdf file to work with it refuses to add tables; if I don't give it an empty .mdf it tries to build one in my C:/Users/ directory.
I'm currently investigating ASP.NET MVC 2 and LINQ to SQL. It all looks pretty cool. But I have a few application and development lifecycle issues.
Currently, I design the DB in SqlServer Management Studio.
Then I update my DBML files by deleting and re-importing modified tables.
Issues:
I can't find how to simply update the whole DBML schema.
My DBML then loses some of the changes I made such as renaming relation members or mapping of some int to an enum.
If I want a SQL script to deploy my DB (or to keep the schema under source control), I need to go use the 'Genererate Script' SSMS wizard which would be cool if a) it could remember my settings and b) it could be automated.
Should I work the other way around (start from my DBML and generate the DB)? Should I go for some other framework (NHibernate? Can I use some Linq flavor with it?)
Also, I read that LINQ2SQL is already obsolete in favor of Linq to Entities. Does it mean that the ultimate tool supposed to make my life so much better will again make me lose time in the long term?
Thanks for shedding some light.
If you are starting your DB Schema from scratch you could consider "Code-First Development with Entity Framework 4" as outlined by Scottgu.
I have been using this on a new project and am finding it extremely beneficial - especially for testing.
I started with simple POCO classes representing my data, then as the project progressed I would allow EF4 to generate the schema to a "real" DB using my "in-memory" example data ... now I am using a mixture of both in memory POCO (for development and TDD) and auto-generated DB Schema (auto-loaded with more "realistic" data) for demonstrations etc ... so far I am very happy.
There is a lot of opinion over LINQ2SQL and whether it's 'obsolete' or 'discontinued'. But it is still in the .NET framework and a good tool, so if it suit your needs then you should use it. Frankly the Entity Framework is still not perfect and if you don't need the extra flexibility that it affords then it is not worth the pain. If I had a small to midsize project then I would definitely use LINQ2SQL again (and over EF).
As for your question, yes you'll lose any names or different type mappings when you remove and re-add a table. The options that I'm aware of are
Only remove / re-add the table that has changed (not all tables)
Try altering the DBML tables in place, rather than remove / re-add. You can add and remove columns, change column names and data types, add relationships all on the DBML.
I like JcMalta's suggestion of creating objects as classes before rendering into the database, but if you find SQL Studio to be quick to develop with then it might simply be quickest to create tables there are drop them into your DBML. It's a touch annoying to have to change something in a database and the push the changes into your code but the code-gen tools are quite good and take away most of the pain.
You can try CodeSmith/PLINQO to auto-sync DB/code:
http://plinqo.com/
As a follow-up, just wanted to say that I eventually found and fell in love with Huagati DBML/EDMX Tools.
To be totally honest, I must say that the price has significantly increased since I purchased it. I believe it is still worth the money anyway.
And for people who are looking for the same kind of tool for MySQL (or other), DevArt is your friend.