I have, admittedly, done very little searching on my own, so feel free to insult and/or harass me.
I have two databases that I use, one for development and one for production. In Visual Studio 2010, I have simple overrides that change the connection string based on whether I'm building for Debug or for Release.
Right now, I manually change the database schemas when needed. I've thought about creating scripts, but I'm wondering if there is a better way? Can I create a DB in Visual Studio on my local computer, migrate those changes to the development SQL and then, finally, migrate up to Production so that the schema version matches the release?
Thanks in advance!
.NET 4 | Visual Studio 2010 | MS SQL Server 2008
Are you familiar with Visual Studio Database Edition? It's reason for being is to help you with what you just described. Not only does it allow you to version control your database schema, it allows you to build deployment T-SQL scripts to update a database from one version to another. It has built in schema compare and data compare. I highly recommend it. We use it to version control our database schema and to do deployments. I would never attempt to update database schemas by creating manual scripts anymore.
This used to be a pain in the ass for me. Then I bought this: http://www.red-gate.com/products/sql-development/sql-source-control/
Which, providing your're using a compatible Source-Control solution (such as SVN), you can make changes in one database, commit them, and then update other databases with the same structure.
As Randy mentions, the Database Edition of VS.NET will do this.
I use SQL Delta. It's a third party tool and very well priced for what it does. I've used it for a number of years on extremely large projects (that is the database has hundreds of tables and thousands of stored procedures) and it has never failed us in what it does.
The way I used it is this.
I get it ot produce a blank database
schema as per the development
database.
Move this database over to
the production server
Sync the production database with this database
You can also produce scripts and run the scripts and all of this can be automated.
Related
I have an ERP system which I maintain with a team of people. However lately we seem to be loosing track of who's changing what and we need a solution to be able to control these changes. We are looking into the enterprise version of GIT as all our software development and web development would work perfectly with it. Not to mention I have some experience with GIT already.
The problem is we need the version control to extend to our SQL Server which we use SQL Server Management Studio to maintain. We have thousands of tables in 6 main databases which have a lot of stored procedures which are being changed.
It's not so much we want to control the source as in, permissions and refuse changes by people. It's more, we need a way of tracking changes and attaching explanations to help our future selves.
Does anyone know any solid solutions which would fit our purpose?
Assume the cost isn't a main factor.
I was using RedGate tool. It can integrate with Git.
RedGate SQL Source Control
I have been asking myself this question once. So I've found following solution which I can suggest you to use.
It is a SQL Server Data Tools that solves the problem.
The tools include SQL server database project for visual studio. This project will store your database structure. You can just add it to you solution. Then run a schema comparison with your database to take a snapshot of your current database state. You can choose what objects to compare. Since this moment your have all your changes being tracked by your VCS. Every change is documented now.
You can make changes in DB project and when you are done just run schema comparison, get the update script and apply those changes to your SQL server database. It is really not that hard to work with your schema from DB project as it provides intellisense, syntax validation. Also it is possible to write and execute SQL queries against you database.
I'm using microsoft SQL Server Data Tools (SSDT), in my projects to try to keep everything in order.
I was wondering if anyone know how to store the Database Diagram into SSDT Project, in order to don't lose any work and keep this model updated with my team?
I tryed to compare it using schema, but it didn't exists.
I also couldn't find any Database Diagram in Visual studio 2013.
Am I wrong to try to use this model type? Are there better ways to do it?
Also, Is it possible to create Jobs throught SSDT?
Thank you very much,
The database diagrams are stored in internal tables so you could add their definitions and include the data in a post deploy script but you would end up deploying to all your environments which is unusual (I don't know your circumstance so I won't say wrong!).
Unless you particularly needed the diagrams in ssms I would look to something else, redgate have a database diagramming tool, I prefer to keep a copy of Visio 2010 pro to generate them, the vsd files can then be added to the project and shared between the team.
I assume it is to help document your databases but If you wanted the editing and designer support from diagrams you get that other ways with ssdt.
Re: jobs, there is no native object but you can create them in pre/post deploy scripts.
We are starting a new BI project in our company. We have at least three developers working with database design and development. Our tools include Sparks EA, SQL Server 2008 EE and undetermined reporting tools. What kind of tools one can use for database version control in SQL Server? What kind of version control systems there are available for database development (managing versions of database schema, tables, stored procedures etc.)?
Visual Studio Team System includes the Database Edition features for database source control, deployment, schema comparison and more. You don't necessarily need a tool to do database versioning but if you do want a tool then VSTS is one option.
Often it's easier to export a set of scripts that would create your database from scratch, and put those in version control instead.
Then, if you want to upgrade a database to a "version" from source control, you could use a tool like SQL Compare or "Data Dude" to compare two databases (or creation scripts and a database) and apply the changes from one to the other.
We create all database changes in scripts, never use the GUI. Then save the scripts in folders that are part of our Subversion store just like any other piece of code. Since our configuration management people will not push to prod without a script, we have no rtrouble at all enforcing this. The beauty is that you have all the scripts you need for a particular change located together and those in another change not yet ready to go to prod are not pushed by accident.
We store all our SSIS packages as files as well and we store our configurations in sripts as well and push them the same way.
Should you want to do a comparison between databases to make sure nothing was missed, I highly recommend SQLCompare by Red-gate.
After creating a SQL Server 2008 database, I made a Linq-to-SQL schema in Visual Studio. Next, in the .dbml visual editor (in Visual Studio 2010), I added PK-to-FK and PK-to-PK associations to the schema.
How do I copy those associations that I created in Visual Studio over to the database? In other words, how do I sync with the DB?
Linq-to-SQL is a great tool, but never ever rely on it to update the schema. Always apply schema changes through upgrade SQL scripts that use DDL CREATE/ALTER/DROP statements to change the deployed schema from the on-disk version to the current version. This way you keep all you schema changes under version control as source text files, you can upgrade from any past version to the current application version and you can easily test all your upgrade paths, including upgrading deployments with very large tables.
The far worse alternative is to use SQL compare tools that can diff your desired schema from your deployed schema, like vsdbcmd. This may work on trivial deployments, but copying and renaming tables of millions of records will quickly show it's ugly downside.
What you absolutely cannot do is rely on the .dbml file as the 'master' copy of your schema. This is a little detail usually omitted by the Linq-to-SQL advocates, one that you discover usually when you attempt to deliver v2 of your application and realize you have no upgrade tool set.
I'd like to have all DB DDL code under CVS.
We are using Subversion for our .NET code but all database code remains still unversioned.
All we know is how important DB logic can be. I've googled but I've found only few (expensive tools). I believe there exists other (cheaper) solution(s).
What approach do you advise to follow? What tools are most appropriate?
SQL Server 2005, VS 2008 TS, TSVN
UPDATE
Our coding scenario is that developers cannot access to PROD DB directly. It is changed only by scripts (so this is not a problem)
I'm mostly interested in the DEV environment where all of developers have full access.
So it happens that a developer overwrite USP previously changed by another.
I'd like to have the possibility to restore lost version / compare USPs revisions etc.
UPDATE-2
To create deployment script we are using Red-Gate SQL Compare.
Works perfectly - so deployment scripts are not a case.
If you haven't already read it, Martin Fowler's article Evolutionary Database Design is a great place to start.
The article is hard to summarize, but it describes how his team dealt with database versioning in a rapidly changing development process. They created their own tools to facilitate things: scripts to bring users up to the current master, to copy any version of the schema so users could debug one another's working copies, etc..
For a solid low-tech solution, I've found it helpful to keep two kinds of DDL scripts in source control:
A master version that can create the database objects from scratch.
'Version upgrade' scripts for each development iteration.
They're redundant to a degree, but extremely useful (particularly when it comes to deployment).
If you haven't already looked at the Visual Studio Database Edition GDR (a.k.a. "Data Dude"), you should definitely download it and try it out:
http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en
Among other things, the GDR will facilitate team development by making it easy for each developer to maintain their own local copy of a database, version scripts, create deployment scripts to move a database schema to a new version, and even support database rollback.
It's free if you are using team system developer edition. Check it out.
If you are using Visual Studio Team Suite or Visual Studio Developer Edition, you are entitled to a copy of Visual Studio Database Professional. This is designed to do exactly what you describe, and much more. We use it to manage our database schema (code).
Randy
We use Subversion for all our database code as well. Since nothing is allowed to go to Prod unless it is in a script, there seems to be no porblem with getting people to put all the scripts into subversion. We tend to write alter table scripts to change tables with existing data and then recreate the whole table structure in case we need to create a new database from scratch (we often have the same database structure on multiple servers as some of our clients are very large and do not want their data accidentally available to the competition and so pay for separate servers and therefore may need to create the whole database again with no data.) For objects that don't directly store data we drop the orginal object and recreate it with a create statement. Each project has it's own home inthe repository and each database does too, so the script may be in more than one place to facilitate deployment.
But the real key is that no one can load to Prod without a script. We don't give our devs direct rights to prod, so they have no problem doing things in scripts as opposed to using SSMS.
I wrote SMOscript which generates a CREATE script for each object in a database.
Use this tool to generate into a directory covered by CVS, and update your repository.
Finally I found this tool and approach extremely useful and very easy to introduce
(at least at the beginning - where no versioning solution on the place):
http://www.codeproject.com/KB/database/SQLScripter.aspx
You can run it out of the box.
For final solution I'd incline to GDR.
This also sounds interesting:
Freeware:
http://dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133
Commercial:
http://www.nobhillsoft.com/Randolph.aspx
You should use Management Studio (SSMS) and place the .sql under source control, possibly separate schema objects under folders.
Hope this helps
See if Wizardby fits your needs.