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.
Related
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.
i'm currently working on a asp.mvc application with entity framework as db backend which will be running on ms azure platform.
on my development machine i'm running a sqlexpress instance which hosts my development database (like i said may app connects via entity framework to it).
deploying the database schema from my local sqlexpress to sql azure is pretty easy via the entity framework database generation wizard (for whatever reasons the wizard always wants to create some clustered indexes which i correct manually in the generated sql file).
but i can't figure out a way to keep my data! the auto generated sql script always dumps all my tables and creates new ones...thats ok for initial setup, but not to upgrade a existing database.
there must be a nice way to perform a schema update without dataloss...please help! i have already tried sql management studio (r2) and SQLAzureMW (available on codeplex)...but they don't do the job :(
please don't tell me i have to code my own tool to do that!
looking for your help
thx
Edit: here's how i do it now
I use the SQL scripts created by the EF migration wizard for my local SQL Express and modify them myself to be compatible with SQL Azure. Is less work that one might think and works perfect :)
Have you tried to use BCP to export and then import your data? I believe you should be able to use BCP to export data from your SQL Express instance into a file, and then import data from the file into SQL Azure. The SQL Azure team has a blog posting that describes using BCP with SQL Azure - Link.
Additionally, in the future, the upcoming release of SQL Azure Data Sync CTP2 might be able to help you out.
Out of curiosity, what problems where you having with SQLAzureMW?
RedGate is famous for SQL server synchronization and data synchronization for deployment purposes.
They have a v9 beta out of their DataCompare and SchemaCompare products that are compatible with SQL Azure. I've been using both successfully and like them alot.
They are pricey when purchased, if you are a small business.
http://www.red-gate.com/Azure
This sounds vary similar to this question, the only answer to which is "wait for the next version of entity framework". I'll admit that I don't use EF, but I make my changes to tables the old school way with SQL Server Management Studio and scripts. ALTER TABLE FTW.
EDIT: If you don't have access to SQL Server Management studio, the new version of the SQL Azure portal includes a Silverlight based application that allows you to run queries and scripts
I've been spoiled by ActiveRecords. So I'm on the lookout for migration system that can be applied to SQL Server, and either is executed as Java application, or a Win32 Executable. (Of course further compatibility with other DB's and host OS's is welcome.)
The real desire is having a clear schema change application with roll back, ideally in something nicer then SQL so it can be DB system agnostic.
The hitch I've found for alternatives that are Java based, is lack of clean support for the Microsoft JDBC.
Looking forward to any suggestions.
Check out Ben Sheirmans excellent post on the topic:
http://flux88.com/blog/net-database-migration-tool-roundup/
I tried Tarantino and it worked OK, but you're still locked to sql scripts for sql server.
/Anders
Try Mite. I wrote it and have been using it for years successfully.
https://github.com/soitgoes/mite
If you turn on "Auto Generate Change Scripts" then Sql Management Studio will generate the sql that you can save into your mite file. No more writing migrations just let Management Studio do it for you! Then if you ever need to custom craft something to alter data you can simply do that in sql and save it to a migration.
Let me know what you think.
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
I have been developing in VB.NET and SQL Server 2008 for a while now, but haven't got into live installs yet. In the database system I used be on it had the ability to archive multiple tables into a .dga file, as it was called. I could then restore the .dga file into another database or on another server.
I'm looking for the easiest way to accomplish something similar in SQL Server.
If you want to transfer specific tables, then using Data Transformation Services (right click on the database in SQL Server Management studio and select "Import Data" and it will bring the dialog up for it). Of course, this assumes that you have both databases available to you.
If you are comfortable with replacing the database as a whole, you can easily backup the database and then restore it into a new one through SQL Server Management studio (or through calling the appropriate SP).
I would go for one of the following :
From MS SQL Management Studio, right click on the database / Tasks / Generate scripts
From Visual Studio, in the Server Explorer tab, "publish to provider"
Both will launch a wizard allowing you to export the tables you want the way you want (including data or not, creation scripts or not, etc etc.)
If you want to move tabless without data, the simpliest thing is to script the tables you want and run the script.
We script all our db changes and commit them to subversion and then run them as part of the deplyment process.
If you want to put the whole database on prod including data (scrub out test records first!), then do a backup and restore onthe other server.
For future changes, wescript all our db changes and commit them to subversion and then run them as part of the deployment process. There also are tools that look at the structural differnces bewteen the two servers and creates scripts. REd-Gate's SQL Compare is really good for this.
In addition to HLGEM's suggestions, you can look into SSIS if this is an ongoing process.