Tag Info

Hot answers tagged

13

In a VS environment, I've always used database projects to implement the update scripts. I tend to use unimaginative names like "DatabaseUpdate17.sql" or "PriceUpdateFebruary2010.sql" for my scripts. Having them as database projects lets me tie them to Team Server tasks, bugs (and if we did code reviews, to them as well). I also include in each database ...


11

Red Gate SQL Server Source Control Visual Studio Database Projects Developer discipline


7

To use SQL Server Management Studio 2012 with Team Foundation Server (TFS) source control, you need to first install the Team Foundation Server MSSCCI Provider 2012 32-bit. Then you will be able to select TFS as one of the source control providers under: Tools > Options > Source Control > Plug-In Selection. Note that one of the pre-requisites to using the ...


7

If you've got access to the original database, I'd go with DBMS_METADATA.GET_DDL. You can script it with UTL_FILE so that it goes through each object (from USER_OBJECTS), uses the name and type to extract the object then write it to a file that has the appropriate naming convention. It will be a lot cleaner than trying to split a single file.


6

There are tools out there, such as this from Redgate, but I have always found that best is to save as SQL files, perhaps even in a Database Project (SSDT?) in your solution. Along with this, I suggest the following guidelines: Always assume the SVN version as the "current" / "latest" Ensure that every script you run has an appropriate "if exists then ...


5

Usual Database/Server projects in Visual Studio RedGate SQL Source Control both are compatible with TFS and SVN/Hg


4

Our team uses Visual Studio 2010 Database Projects. Most of our projects rely on MS Team Foundation Server for source control, which integrates seamlessly, but I found out recently it will work (with only a little pain) on other source systems. We have one such project on Perforce. The build and deploy features of VS2010 work very well and can be ...


4

This might be fine for one change per module, but imagine how your code will look like after severol years of development. Before version control was universally adopted, there used to be modules that were 95% history log and only 5% actual code. Fortunately version control automated out that inconvenience long ago. I would completely get rid of change ...


2

If you can see them in the .dmp file you should be able to extract them? something like: grep -a 'CREATE PROCEDURE' expdat.dmp alternatively perhaps the parameter SHOW can help you see the DDL


2

Another solution is to use something like PowerDesigner, ERWin, etc to design and manage changes to your database. We're starting to transition to a policy where databases are modeled in PowerDesigner. All changes to the database structure/code is done in the model, checked into source control and then change scripts are generated from the models to ...


2

Saving the SQL files in source control provides control over the SQL files only. It doesn't control the changes of the actual database objects, nor it prevents simultaneous changes of the same database object by multiple users (and I guess you would like to have that under control, too). What we use is a 3rd party tool (ApexSQL Version), it integrates both ...


2

Try Ankhsvn, highly recommended and free. From the homepage: AnkhSVN is a Subversion Source Control Provider for Microsoft Visual Studio 2005, 2008, 2010 and 2012. AnkhSVN provides Apacheā„¢ SubversionĀ® source code management support to all project types supported by Visual Studio and allows you to perform the most common version control operations ...


2

For SSDT, when you choose Publish to generate a script the advanced options include "Always re-create database". Untick that and you're good to go. Same option applies if you do a local debug build. Similar options buried in the old VS2010 Database Project options somewhere. To be honest, from the description of what you're doing SSDT and/or VS2010 ...


2

ApexSQL Version, supports Visual Source Safe, Subversion, Team Foundation Server, SourceGear Vault and MSSCCI compliant versioning systems


1

I have tried both RedGate and Visual Studio's database project and I prefer the storing the database definition in the database project. As soon as the database becomes part of the solution, you can use your preferred source control provider. Most have excellent Visual Studio integration. With the SSDT tools you have the 'lastest version' of the database ...


1

Having it in the body as well makes it easier for me to see the list of changes in one place instead of having to look at the procedure and cull the history from source control. So it has value IMHO, but whether it is worth double maintenance in your case, I don't think that's a question this site can objectively answer.


1

Red Gate has a product that does data comparing as well as schema comparing and will create scripts to merge content. I personally use Idera's schema / data compare tools. I am very happy with them as well. I only pointed you to Red Gate as you already use their source control product. I probably would have gone Red Gate myself as we use their backup ...


1

I know it sounds overkill to most DBAs: Have you considered using Ruby on Rails to track the Database changes (and only the DB changes). You don't need to run any app or write any ruby code etc. But I found the style of migrations (that's how they call it) is quite useful: http://guides.rubyonrails.org/migrations.html Sql Server is also supported, you ...



Only top voted, non community-wiki answers of a minimum length are eligible