We use VSTS Database Edition to version control our database schemas. I like the idea of how it is supposed to work but have a big issue with the Schema Comparison feature. I like to use it for my deployments to see what has changed in the project vs a target database. Unfortunately, it shows many changes for objects that have not been changed. That happens even if I do it immidiately after re-creating a db project from the database.
The differences it finds are mostly white space. Some are caused by a different representation of the same thing, for example default constraints, "DEFAULT ((0))" vs "DEFAULT (0)". While I can go ahead and deploy the changes anyway and it does not cause any problems, it is definitely not ideal because it is hard to find actual changes when at least 50% of all objects are shown as modified. Is there any way to make this work better?
The solution to this was upgrading to the Database Edition GDR R2 release, which was suggested by Mitch Wheat in his comment. I was using the standard version that came with VS2008 before. GDR release appears to have some nice usability features and it fixed all my problems with the Schema Comparison.
General info on VSTS Database Edition GDR: http://msdn.microsoft.com/en-us/magazine/dd483214.aspx.
Latest version download is here.
I keep hoping VSTS Database Edition will get more reliable. In the meantime, I still trust and use redgate's SQL Compare to diff databases. You can tell it how you want it to treat white space, comments, etc. on a very granular level.
I have been using SQL Compare around 5 years and it has always been very reliable. I have automated build scripts that use the SQL Compare engine APIs to diff our production and dev database and generate change scripts automatically.
PS. I am not affiliated with redgate. I am just stating my opinion based on my experience. Also, there is nothing wrong with rooting for the little guy.
Related
RedGate ReadyRoll is wonderful DB versioning tool which works like a charm. But the only one drawback - price.
I've researched what to use and found DBUp, Envolve... These tools are good but:
Doesn't have ability to define Up and Down scripts to be able apply and rollback migrations
Apply migration based on name ordering and not creation time. It's not big issue because developers could give the name based on the time but...
These tools doesn't allow to do development in different branches when developers uses not shared DB but their own and change DB schema separately. How to handle the issues when Team Lead have to switch between branches or when QA have to test feature before it goes to master - it's open question for me.
Using SSDT - as a case but it makes live very difficult if need do something with a DATA and not only with schema. What can be done very simple if use migration-based approach - becomes really big issue when try to do it with state-based one.
Can somebody suggest some tool for DB versioning with migration-based approach which can work with .NET stack and been free or paid but cheaper than RedGate?
Thanks
P.S.
What if use Entity Framework only for migrations? Without entities, etc. Create DB Context and do everything just to create migration files which has Up/Down and then write there scripts or define sql file to apply up/down migration changes. The only question - it's snapshots. How it will works with it.
Have somebody used this approach?
ReadyRoll also comes in a Core Edition, which is a free
entitlement if you also own a Visual Studio Enterprise license. I
admit this information isn't too helpful if you have VS Community or
Professional.
I'm updating this answer because Redgate no longer supports ReadyRoll Core edition. Instead Redgate's supported migrations tech is Flyway migrations, which comes with a free community edition.
We have decided to use EF Code First migrations to do what we need. If compare it with DbUp - EF Code First migrations contains Down script which allows us rollback DB to any target migration script.
Yes, it's not alternative for ReadyRoll and I have to accept that there are no any similar product which is surprised for me.
But it does what we need and after more than 1 month of usage I can say - it fit for our needs.
Because we we use EF Code First only for migrations scripts there is no issue with Team Collaboration described here because snapshot is always the same if your context doesn't have any entities.
Despite a few hiccups and a few workarounds, my MVC based Entity Framework (Code First) application is now complete and ready for deployment.
I originally tried developing through SQL Express, however, I had non stop problems with the Code First approach as I asked about here which made it completely unworkable.
So, in the end, I developed it following the majority of guidelines and used SQL Compact Edition. This has been absolutely brilliant for development - but - now it has come to deployment and I am stuck.
I have seen some people saying about generating the Schema from the .SDF file, however, there are differences and restrictions in Compact edition such as nvarchar being limited to a length of 4000, and I need max in my application.
So basically, what can I do?
In addition - but not essential - , I am going to be moving on to the next project shortly, It will involve heavy usage of items needing to be stored in a database that are longer than 4000 characters. Are there any better strategies now for development / Is it possible to use Code First with SQL Server Express or SQL Full (I have MSDN and willing to install/use anything that will help).
Here are my unofficial recommendations:
SQL CE is not a viable option for most production applications that are based on MVC (although I have used it in production services in rare cases).
I would try to avoid switching databases between development and production - i.e., don't test on SQL CE and deploy to SQL Express or something else.
I have never tried to open an MDF inside of Visual Studio - maybe I'm misunderstanding what you're saying here, but in general I'd recommend using the SQL Server-specific tools to manage databases: http://www.microsoft.com/download/en/search.aspx?q=sql+server+management+studio+express.
Regarding the other post, I would generally discourage using the AttachDBFilename portion of connection strings unless you need it for a specific purpose.
It sounds like you may want to review the available database initialization strategies: http://blog.oneunicorn.com/2011/03/31/configuring-database-initializers-in-a-config-file/.
There are lots of walkthroughs on our blog and the MVC MSDN site - if those don't work for you feel free to reach out to us from our blog and provide feedback on what we can do better!
Our blog: http://blogs.msdn.com/b/adonet/
MVC walkthroughs: http://www.asp.net/mvc/tutorials/getting-started-with-mvc3-part4-cs
On the one hand regarding deployment/migration you might want to take a look at http://exportsqlce.codeplex.com
On the other hand I've been checking Microsoft SQL Server Compact 4.0 Books Online and in principle there is no known issues with data types, although the limitation you mentioned for nvarchar is confirmed.
Finally in order to elaborate a strategy you might find interesting the Differences Between SQL Server Compact and SQL Server
You need to create a debug and a release specific web.config file:
In the release specific file you remove the connection string, so it creates a database for you.
In the debug specific file you keep the connection string.
However, I would suggest you to not use a connection string and use SQL Management Studio instead. Given that the Compact Edition does not support your requirement, this is a good time to switch...
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.
I have two SQL Server (2000) databases. Both are used for the same project, but different versions. Basically, the old database is from our TEST environment. The new database is from the DEVELOPMENT environment. We also have an ACCEPTANCE, PRODUCTION and MAINTENANCE environment and they all contain the same project. (It's our development street, moving versions from D to T to A to P and finally M.)
Now, the development database structure has changed. A few tables have been added, indices are added or removed, fields have changed in type and nullable fields have become non-nullable, things like that. The test database needs to be upgraded with the new structure but without any loss of data. Right now, I'm doing this with a lot of manual labor. I keep a list of structural changes and once everything is ready, I write an update script to patch the old test database.
But as a software engineer, I'm just lazy by design. So, is there some easy tool somewhere which will compare the two database structures and generate an update script by itself?
(Only to change the structure, btw. No data manipulation!)
Yes, the best one in my opinion is by Red Gate
The SQL Toolbelt they offer is very good, which includes a bundle of tools, or you can just get SQL Compare on it's own. Not free (except for 14 day trial I think), but well worth the money
Take a look at Red Gate's SQL Compare..a complete live safer
At work we've used a few tools; AdeptSql Diff and we were trialing Redgate-something-something.
AdeptSql was significantly cheaper than Redgate, and while Redgate had a lot of very nice bells and whistles, since we already owned Adept we decided to stay with it.
http://www.adeptsql.com/
I'm sorry that I don't know any free tools offhand; I know that Redgate at least has a trial period.
I have used a *nix command-line tool called sqlt-diff which uses Perl SQL::Translater (SQLFairy) to generate diffs between SQL database schemas.
https://metacpan.org/pod/distribution/SQL-Translator/script/sqlt-diff
This is a free open-source tool. I did manually edit the diffs generated to customize them slightly.
Interested if anyone has used VSTS Database Edition extensively and, if so, which features did you find the most useful over the standard Visual Studio database projects?
What are the most compelling features as opposed to alternative schema management options or tools like RedGate's SqlCompare etc?
Edit: Microsoft just released the RTM version of Database Edition (GDR) which adds support for SQL Server 2008 - link is here. I've previously blogged (briefly) about it here.
Has anyone had a chance to do any real work with the GDR? It looks like there are some real enhancements including refactoring support. I'd be really interested to hear if people are using it with SQL Server 2008...
Download From: [http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en]
We use the database edition functionality of Team Suite on Stack Overflow. As Vaibhav said, mostly it is useful because it gives you a one-click way to reverse engineer a database into source control, and keep it up to date.
Note that it also has decent Data and Schema compare tools as well. You can compare projects to physical databases and vice-versa. This makes it pretty easy to keep your database up to date, no matter where you make changes -- in the filesystem database project, or in the physical database itself.
If you compare it to tool like RedGates, that are specifically taylored for SQL Server, the benefits are that if you have the proper MSDN subscription you do not have to spend more money for other tools (but keep in mind that RedGate tools are much more mature) and it covers some points (like regression tests and unit tests at the DB level) that other tools do not cover and it make so in a integrate manner with other testing tool of VSTS, so that you can record results in Team System.
Compared to a tool like Embarcadero ErStudio (my solution of choice) it misses the cross database features, and this is a big problem, at least for me.
If you are a "all Microsoft" shop with the proper MSDN subscription it could be worth spending time on it.
We are currently using the GDR 2008 projects for managing our entire database development and deployment on a greenfield system. We use a TFS build script to call out to the MSBuild task for deploying the databases along with executing the data generation plans for pre populating the testing environment with data.
The key with the data generation plans was finding the build task to use which is :
TaskName="DataGeneratorTask"
AssemblyName="Microsoft.Data.Schema.Tasks, Version=9.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
All of this gdr project work has been unbelievably helpful and I think it is well worth the learning curve to get to know these project types. The value they provide is astronomical in productivity and visibility.
It allows us all to view the entire system in a single visual studio solution along with allowing us to start with a clean slate of our system at any point in time with either a click of the deploy command or a custom build configuration.
This blog
will help with getting the TFSBuild script to run if you're interested.
The VSDB test integration is so painful to configure that we abandoned it, and that's the only thing it's got that Red-Gate doesn't.
Red-Gate's tool is miles more useful. It does live DB and scripts in folders, but also has "snapshots." The aspect of Red-Gate SQL Compare that gives it the win is its Snapshot ability and the fact that your license allows you to deploy their assemblies and use them to perform database maintenance at customer run-time.
It has made upgrades in the COTS application that I develop a breeze. A Snapshot is a binary schema representation. You can package them as resources in an assembly, then use the snapshot in a customer run-time schema compare to bring an existing database up to the current rev.
Probably the best advantages are around being able to version control individual DB schema objects (which you could do with the older "Database Projects"), but have the power to "build"/deploy the project and convert those individual scripts into a complete database.
The ability to import scripts and have the Wizard covert individual schema items into separate files is very handy if you've inherited a DB schema.
Given that recently the licensing model changed, it makes it even more enticing because it's included with the Developer edition SKU. It also provised support for "Database Unit Tests" which might be useful.
From the 2008 GDR, I understand that they now support SQL Server 2008.
You can do database versioning for one. That is useful.
The other thing that is really useful is the ability to define type of seed data for testing. Through this Visual Studio will populate the database with random data and this is great for testing purposes.
There are other benefits as well of course.
It is always useful to put everything under the same source control, so your data-dude can be shelving, checking in, compare with history, and even resolve workitems and bugs using the same tools that other team members are using.
Also to be able to have one versionning mechanism across the whole application, in other words, it doesn't make sense to say that my source control has all the versions of my project while your database can't fit with any of these old versions, unless you take a backup or a snapshot of the database with each build.