Support for updating a Visual Studio Database Project(s) instead of updating the db directly with an ad-hoc file.

Currently 4.0 allows us to generate our database schema from the model but its capabilities are limited and destructive:
unique keys – no support
schema generation – destructive

Database Projects for Visual Studio has already matured and more importantly has the capability of updating schemas without being destructive to the data. It would be nice to see the next designer integrate fully with this product rather than re-invent the wheel. For those of us that manage our databases using Database Projects this will also reduce the amount of steps needed to get our database schemas checked into source control.

Current State:
Generate schema -> update live database schema -> import schema from database into VS DB Project -> check-in

Future State:
Update VS DB Project -> update live database schema -> check-in

When doing "Model First" development THERE IS NO BACKING STORE. I don't want to create a phony one. I don't want a store or any mapping to one ... period. I'll deal with that when the time comes. But I should be able to model away w/o a map or store.

Ok ... you should provide a warning ... as you do. during validation I get a raft of 11007 and 11008 "errors" and a 2062 error during compilation.

But I should be able to suppress those warnings and errors as well.

In Model First you do NOT specify mapping or backing store. All you want is the conceptual model. I understand perfectly well that EF will not be able to perform any persistence operations until I map to the store. I appreciate that it wants to tell me that I will not be able to work with a backing store until I map the conceptual model.

Thank you, EF. Now shut up about it. I want to tell EF that I no longer want to be bothered with its complaints.

The fact is, these "errors" are ONLY errors if I use EF for persistence services. But the Conceptual Model is supposed to be independent of that purpose.

Trust me, I'm getting plenty of good use from the model without asking EF to persist or retrieve anything.

EF should have the ability to automatically create basic CRUD stored procedures for every table. These basic CRUD stored procedures will only focus on a single table and all it's columns.

An advanced feature would be the ability to auto generate CRUD stored procedures that take into account parent and child tables or many to many scenarios, etc.

Other features would be to create stored procedures that allow for paging and streaming of large amounts of data. Say you have a web page that list contacts and you want ot show the 10th page. It would be ice to autogenerate GetAllCustomersByPage (10).

When generating the EF model from the SQL database, it sets the code generation property to none and generates two tt files automatically.
Could there please be an option for the code generation to set to default instead?
I know there is a work-around by deleting the tt files and manually setting code generation to default, it would just make life a little easier if there was a setting to do this.
We are working on a fledgling project with many aspects that are not decided yet and therefore we make a lot of DB changes and the workaround gets a bit annoying.
Thank you.