Using TFS files in comparison

asentellasentell Posts: 42
edited October 15, 2010 1:45PM in SQL Compare Previous Versions
We are implementing Team Foundation Server for database source control and will be using SQL Compare to produce database comparison reports since TFS does not have this functionality.

Question #1:
I seem to be able to use the database scripts generated by TFS to compare against my target database. Are there any caveats or gotchas I should be aware of in doing this?

Question #2:
TFS creates a dbschema file that functions much the same as SQL Compare's database snapshot file. Is there any way I can use this as my source when comparing to a target?

Thanks,
Aaron
· Share on Twitter

Comments

  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    1.
    Yes, there are caveats. Although SQL Compare works in many cases when using it against a VS database project, it isn't a supported scenario, although we have future plans in this area. It will be more successful if you are just reading the scripts into SQL Compare, but I would recommend against trying to synchronize back to your project from SQL Compare.

    2.
    If we choose to support the database project, it's something we would look at.

    SQL Compare fully supports Red Gate's SQL Source Control, so using this instead would be our recommendation.

    Kind regards,

    David Atkinson
    Product Manager
    Red Gate Software
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • asentellasentell Posts: 42
    Thanks David.

    Where would I officially submit a request to allow SQL Compare to utilize TFS's dbschema file in comparison scenarios?

    I just completed the SQL Source Control (SSC) demo, and it looks pretty nice. Does SSC assume that each person has their own dedicated development database?

    Aaron
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    I'll note your request for the dbschema support. Over the coming months we'll be working with Microsoft to decide the best way to collaborate in this regard.

    SQL Source Control can be used in a shared or dedicated development environment. There are clearly benefits if you have your own sandbox, but there are also justifications why a shared environment might make sense. Which would you want to use and why?

    David Atkinson
    Red Gate Software
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • asentellasentell Posts: 42
    Our databases are too large for every developer to maintain on their laptop.
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    Why not put the database on a central SQL Server instance that all developers have access to, rather than each laptop?

    Is it then a requirement for you to develop on an environment that has all the data? Or can it just be a small amount of test data?

    How are you currently using TFS? This uses an offline model that requires you to deploy to a database. Are you deploying to a shared database that has the large amount of data?

    We have a product called SQL Virtual Restore that might be able to help you. This lets you compress a backup of your database, and create mount points, one for each developer, allowing each developer their own development space, but not requiring duplicate storage requirements.

    David
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • asentellasentell Posts: 42
    We can go back and forth on email all day long (and probably all week) I'm sure. Can I speak with someone about this on the phone?
    · Share on Twitter
Sign In or Register to comment.