Placing Database under Visual Source Safe Source Control

I have been trying to evaluate how SQL Server 2005 integrates with VSS. The only thing I can find is the ability to place a database 'solution' under source conrtol and that basically puts create scripts and change scripts under source control.

Ultimately that is nearly worthless. What I would really rather do is place the DATABASE under source control so that a user would have to check out a table if they wanted to make a change.

I would love it if SQL Management Studio worked like this product (and maybe it does but there is squat for documentation about placing SQL Server 2005 under source control): http://www.skilledsoftware.com/features_sourcecontrol.htm

I fully understand that 'in the background' the above product is simply managing the create and change scripts for you and placing them under source control but it is the cleanest SQL to VSS implementation I have seen. The problem is they do not offer a 2005 edition of the software.

Please point me to the right direction so that I could get this functionality out of SQL Management Studio and SQL 2005!

Thanks,
David Sandor




Answer this question

Placing Database under Visual Source Safe Source Control

  • ChrisKinsman

    Here is some free software that will script out all objects in your database, with a separate file for each. It's useful for getting all your objects into source control if they aren't already. The source code is freely available. get it here:

    http://www.elsasoft.org/tools.htm

    Also there's a .bat file in the download that will execute all the generated scripts to generate a fresh db. You can use it in conjunction with a task that monitors your source control system to autobuild your scripts whenever there is a change and find build breaks early.

    hope it helps!


  • RayinSpain

    DB Devs and DBAS have been wanting "true" change control for some time, the flavor you mention above. In a production database I must somehow "check out a table" before I can run alter table against it even with permissions that allow me to do so.

    But SQL Server 2005 VSS integration is much better than what we had in SQL 2000!


  • mtfck

    I struggled to find more information and was happy to find this thread.

    I completely agree with the previous posters. The current source control mechanism makes it easier to bypass it than to use it. It protects files, but not the database objects themselves. Not even the stored procedures. I was disappointed about that. I will try a diy approach or go to a 3rd party solution, but I was expecting MS to have a tool for me. Will the new Team Foundation do it better

    Thanks for the mention of the third party software!



  • Nimrand

    "Ultimately that is nearly worthless.  What I would really rather do is place the DATABASE under source control so that a user would have to check out a table if they wanted to make a change.  "

    I totaly agree.  Please add this functionality.


  • Manish 3177

    I'm sorry, but I'm going to have to agree with everyone else on the uselessness of the existing source control integration in the SQL Management studio.

    At least in Visual Studio 2003, we had the ability to put the stored procedures under source control. Now in Visual Studio 2005, we even lost that ability! VS 2003 was at least on the right track, although the implementation was far from what developers really needed. VS 2005 seems to have dropped that entire direction and forced us to maintain a separate script file. What a useless waste of time!

    In order to source control a stored procedure in the new Management Studio, we have to complete 12+ steps...

    1. Open the stored procedure for modification.
    2. Go to the script in the solution and check it out.
    3. Open the script that we just checked out.
    4. Copy the contents of the script.
    5. Paste the contents into the editor window.
    6. Make the changes we need to.
    7. Save the changes and test functionality.
    8. Copy the contents of the editor window.
    9. Paste the changed code back into the script in the solution.
    10. Check the changes back into source control.
    11. Close the script file.
    12. Close the editor window.

    YUCK! I'd rather brush my teath with steel wool!

    What SHOULD be required is about 5 steps...

    1. Open the stored procedure for modification.
    2. Begin to make edits and select "Check Out" when the system prompts us.
    3. Save the changes and test functionality.
    4. Close the editor window.
    5. Check the object back in.

    This is the standard process that is currently followed when editing other files in the Visual Studio 2005 environment which are source controlled.

    This doesn't even speak to the fact that you can not easily add database objects to source control. You have to script them out to the clipboard, then create a new script file, then paste the script into that file. This clumbsy process makes adding an existing database to source control, extremely time consuming.

    Further more... All of this should be possible from WITHIN the Visual Studio interface. When we are in the middle of making edits to application, which requires simultaneous changes to database objects, we should be able to perform both operations from within one interface. I completely understand that there is a need for a stand-alone product for "database only" type personnel, but the same tool functionality should be made available as an add-in to Visual Studio.

    Additionally... All changes to database objects (except for data itself) should be capable of being tracked in source control. Schema, Indexes, Constraints, Triggers, Defaults, User Defined Functions, Stored Procedures, etc.

    Now... I'm not saying that the current Source Safe integration is entirely useless. It =IS= of course very usefull for managing scripts which do not directly correlate to database objects. So it has it's place. Just not for managing things like stored procedures, user defined functions, table schemas, indexes, constraints, triggers, etc.

    Regardless, the current Management Studio implementation falls far short of anything that is usefull in a real development scenereo. I've been doing some research over the past couple of days and had already stumbled across the alternative tool referenced above prior to finding this thread. However, I've uncovered a few others and I figured I would post them here for everyone's benefit:

    ApexSQL: http://www.apexsql.com/sql_tools_edit.asp

    SQLSourceSafe: http://www.bestsofttool.com/SQLSourceSafe/SSS_Product_Info.aspx


  • Arindam Sen

    David,

    Your assesment of the VSS support in management studio's capabilities, is correct, it is limited to files/solutions. Now I understand this does not meet your requirements, but I disagree with your assesment of its value

    To protect objects in the database I recomend implementing some sort of DIY solution using either DDL triggers or permissions.

    However you are not the first person to ask for this so it will be looked at again, please make sure and vote for any existing feature request on the product feedback centre and if there is not already one then please submit one, we constantly review those entries.



  • LisLis

    I know it's been awhile since the last post but this is still a very valid issue. We are currently using Visual Studio 2005 for Database Professionals along with TFS 2005. This combo gives great source control over our SQL objects. However, developers can still use Management Studio to modify SQL objects outside of source control via the object explorer. The object explorer within Management Studio should have source control integration so no matter what IDE a developer chooses, you will always have a protected database.

    Visual Studio 2008 was just released but not SQL Server 2008 so I don't know if this issue will exist in a future version of Management Studio.


  • Placing Database under Visual Source Safe Source Control