I enjoy using SQL Server Management Studio for change and updating my database. Its easier, faster, and safer than writing changes myself.
I was looking into using some sort of version control for databases and read about using a SQL Server Database Project in Visual Studio 2010.
I scripted out an existing database and imported it into a new SQL Server Database Project. Now, from what I can tell, there is no GUI to edit the database; I can't add columns, change datatypes, or edit existing data without scripting it myself. For instance, in SQL Server Management Studio I can right click on a table-name and select "Design" and then add/edit columns, change datatypes, etc from there.
While Visual Studio's Database Projects has some features SQL Management Studio does not have I don't think I can live without a "table designer".
Is there a table designer built into VS's Database Project I'm just not seeing?
No, there's no table designer.
If you're starting to think about version controlling your database, you ought also to be thinking about writing actual SQL to implement your database objects. That's the route that the Database Projects force you down. If you can't write the SQL for your database changes, how are you going to be able to review and appreciate a diff between how a table was 6 months ago, and how it currently is in your project?
I've been using VS2008 Database Projects for about 10 months now for our version control. Every now and then I do still use the table designer, it is a quick and easy tool. I believe the majority of your question centers around workflow as this is what I found to be the most challenging part about development in a version controlled environment. I would recommend continuing to design your objects in Management Studio or however you're comfortable and then do a create script and import that script into your Database project. There are some quirks when doing this, you'll need to always script the create statement even if you're performing an alter in your environment. As well you'll need to remove any USE statements for your database as the context in which you're importing your scripts will always be in the project you're importing to.
We have found that a successful workflow for us to facilitate code deployment is to have a production branch which is branched to a Main (development branch) and then to test. All new development is done in Main and merged by changeset to each other environment as required.
You can import your scripts from your development environment by right clicking in the solution and clicking import scripts. I recommend that you check all the options to overwrite objects that exist, import extended properties and import permissions.
After changing your DB schema using SSMS's GUI tool, you can use Database project's Schema Compare tool to update your project files (set the source to be your database and target to be your project). This way you can keep using GUI tool to manage the schema and the database project will manage the versioning.
There is no visual table designer in Visual Studio 2010 Database Project. But, concerning version control for databases, there is a workaround - you can use SQL Server Management Studio together with Red Gate's SQL Source Control. It costs some money but definitely is worth it.
Related
I have problem that is all my team members are altering the Sps and functions and
some conflicts occurred through the development
is there anyway or tool to store and get all version of them ?
the problem is before releasing the new version, i don't want a tool to compare difference between two databases like what Red gate SQL_Compare
thanks in advance
You may make use of the features in Visual Studio and TFS(or any other source control mechanisms). All that you need to do is to
Create a SQLServer DB Project in Visual studio and configure it to
your desired database.
Bind the project to a source control (TFS,
SVN etc.,)
Every time you have a change in DB, you can just compare the changes using .scmp file and click update.
You may refer this post for more information:
http://candordeveloper.com/2013/01/08/creating-a-sql-server-database-project-in-visual-studio-2012/
I have an existing database (SQL Server 2008 R2), and my goal is to have a project that can install the same database as I already have.
i.e the project will read the schema and the data, and will be able to duplicate the existing data and schema.
This tool needs to save the database information to disk so I will able to install the database on different machines.
Can I do it with Visual studio 2010 database projects?
Is it a simple task?
(The reason I am asking is that I already have such a project that installs my database, but this tool is very old(~2000).
That old project is one big mess, it has C#, java, sql, batch files and some 3rd party tools and has many more capabilities than I need for my current product..)
Thanks.
Use SQL Server Management Objects (SMO) to create a snapshot of your source db and then restore it to the target server.
More on SMO here: http://msdn.microsoft.com/en-us/library/ms162169.aspx .
A nice tutorial here: http://www.codeproject.com/KB/database/SMO_Tutorial_1.aspx
The easiest way is to backup using SQL server management studio. Then move the backup file to the second server and there restore it with SQL server management studio. If you need SQL code to do it (instead of GUI way), just drop a comment...
This codeplex project has a basic library that does that if you like to roll your own and has two sample projects for migration/comparison tasks.
http://dbschemareader.codeplex.com/
Also the commercial option is to use Sql Redgate's tools. They are expensive but worth every penny if this is a mission critical database. On the otherhand, if you are just using a db as an alternative to a file, say in a embedded scenario, it might be hard to justify such an expensive tool.
Have you tried DBSourceTools ? http://dbsourcetools.codeplex.com
It is an open-source database versioning tool that will script out all database objects and data to disk, and then re-create the database on another machine.
It has all of the features that you are looking for.
I'm working on a project which relies on the presence of a number of tables, views and stored procedures. Until now I have built these all in SQL Server Management Studio.
Now I would like to continue to work on them inside of Visual Studio. This will provide the benefit of version control (along with a number of other benefits hopefully).
I have added a new project to my solution and started working on one of the views. When I tried to build the solution it failed as the new project didn't have a server/database associated: Error 1 SQL03006: View: [dbo].[vw_Test2] has an unresolved reference to object [EV870_ACCT_MASTER].
I was able to overcome this by
-creating a dbschema dump using vsdbcmd.exe
-adding the dbschema dump as a reference to my database project
Is this the correct approach?
Now i can see the schema (tables, views, sprocs etc) in the Schema view (I had to enable display of "external elements") and the error message has gone away. Note: I had to reference like: [$(SQLDatabase)].[dbo].[EV870_ACCT_MASTER]
Now I want to know how I can work with these objects that i've scripted. I don't know how to use the new tables, views, sprocs etc (I want to use LINQ). Do i have to run the scripts first? How then if they are "CREATE OBJECT" scripts, will they run in future (presumably they'd fail as the object already exists in the database). Will my project/solution know which objects need updating and update them?
Ultimately want to take it a lot further- my aim is that the solution will be portable and a the server/database will be configurables. Then my tables, views and stored procedures will be created or amended if they don't exist or are out of date. Is this possible?
When I then start working with the views etc using LINQ I want those server/database references to remain dynamic?
I know there are quite a few questions in there but i'm hoping someone will be able to point me in the right direction- there doesn't seem to be much useful documentation online (or that i've stumbled across so far).
Thanks
Lee
Where I work (and the last place I worked) we distribute the sql scripts to create the database along with the app. In sql a version number is stored and when the app is run it checks to see if its version is newer than the number stored in the database. If so then it knows it may need to run some new sql scripts in case there were any schema changes. When this happens, we just run through all the scripts because they are written in a way that running them multiple times won't hurt anything... this way we don't have to worry about tracking which scripts are the new ones. Just check the version number and that's it.
As far as working with this stuff in Visual Studio instead of Management studio, I'm not sure why anyone would want to do that. Depending on what you use for source control you may be able to get hooks for Management Studio, but even if not that doesn't stop you from keeping your sql scripts in source control. And I wouldn't switch from working with my sql files in management studio to visual studio for the benefit of having built in source control any day.
I have Visual Studio 2010 Beta 2 and SQL Server 2008 installed. I'm working with a populated database and want to modify various column types. SQL Server Management Studio requires me to drop tables to do this, and get pretty finicky given my moderate level of knowledge of SQL Server.
However, I heard the new database project type supports changing the database schema to the desired format and it will handle creating and running all the scripts to implement the changes.
I've created a VS2010 database project using the existing database as the source, but so far haven't had much luck figuring out the appropriate method to make the changes without getting an error.
As a result, I'm looking for any reference info I can find on using VS2010's capabilities in this area. Any suggestions?
write scripts instead of using the gui. You can use alter table for instance to change a column. Never use a GUI of any kind to create a change to a database table.
Here's a walk through of the new VS2010 "Deploy-SQL" tab in the properties page of web application projects.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Stored procedures/DB schema in source control
What's the best way to version control my tables, views, sprocs, etc? Preferably automated or at least semi-automated :)
Thanks
I asked this one yesterday and got some nice responses:
Stored procedures/DB schema in source control
The articles from K Scott Allen say it all:
http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx
Write migration scripts for all db changes and keep them in a repository. Enforce a policy of making all changes to the db only by running a script; that way there is a record of what has been done, and a way to revert it. Investigate whether there's a migrations framework available for your favorite language/db combination.
I use Visual Studio 2008 Pro create Database projects (Other project types -> Database). We already use SVN as a code repository, so a project with a bunch of .sql files representing your stored procedures is just another thing to put in the repository - you can see diffs/history etc. This works the same with VSS or any other repository you use.
The nice thing about Database projects is that your project will remember your connection string, and all you have to do is right click on a .sql file (or select all of them at once!) and select run to update it in the db. This makes it easy to update your .sql files from the repository and run them all to update all your stored procedures, verifying your database is updated in seconds.
You can also select create a LINQ project (Visual C# -> Database) and store all your LINQ code in your repository.
Hope that helps!
If you were super lazy you could use the SMO (SQL Server Management Objects) or if using SQL Server prior to 2005 the DMO (distributed managmeent objects) to script out all tables/views/stored procedures daily and then compare the script to the script in source control and if there are any changes check the new version in. You won't be able to necessarily have as pretty of a script as if you just created all db changes in scripts, but at least you can recreate all tables/stored procedures/views. For example, in my table creation scripts there are often comments.
Here is an article to get you started on scripting: http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated.
Again, this is mainly if you are too lazy to bother with version control and it won't help if you change something twice in one day. Also any data migration scripts still have to be saved and checked in because this won't pick up ad hoc SQL, only database objects.
I have written a DDL trigger which logs all the changes done to the definition of SQL objects (triggers, tables, SP, view etc). I could very well invoke extended SP from the trigger and store the details in another Database and use that as repository.
But if your team is really disciplined any source control should do the trick. The trigger is used as an audit mechanism and it's ideal for teams which are geographically scattered.
Try Randolph, One of the best SQL Version control tools I know.
I'm using Visual Studio Database edition which can export the schema from SQL Server in to a Visual Studio project. This is then stored in Source Control and can be deployed where ever needed. The VS Database project is just a bunch of scripts though and it's a clunky way of working.
A more robust method would be to use a database migration framework and if you're working with .Net check out this blog post for a good description http://flux88.com/NETDatabaseMigrationToolRoundup.aspx.
Update
As mentioned in the comments, this page is no more. So here is the last known snapshot from wayback machine http://web.archive.org/web/20080828232742/http://flux88.com/NETDatabaseMigrationToolRoundup.aspx