Having a SQL Server database under source control is rapidly becoming the norm vs the exception in many software development teams. Using any development model (dedicated or shared), requires the team to establish a workflow and a set of rules. The dedicated model, though, allows a developer to act as an independent part of the process mainly in case the central server/repository is down. In this case, the team can continue to work unhindered. This article will focus on using the dedicated development model for SQL Server source controlSeptember 17, 2015
In a multi-user database-development environment, avoiding conflicts and overwrites with edits, and ensuring all changes are audited and recorded is important. Until recently however, effective tools for SQL development management have lagged well behind their client developer equivalents, like Visual Studio. In this article, we will look on specific database source control challenges and a way to address them use new SQL developer tools that make meeting these straightforward and easyApril 22, 2015
Once become familiar with the source control basics (SQL Server Source Control – Part I – understanding source control basics), development client can be connected to both SQL Server and the version control system. This article will review 3 options: native support in SQL Server Management Studio, Visual Studio, and the 3rd party ApexSQL Source Control tool.March 25, 2015
SQL database scripting tool ApexSQL Script natively integrates with the Subversion, Microsoft Visual SourceSafe, Git, SourceGear Vault, and Team Foundation Server source control systems.
ApexSQL Script allows to export complete SQL database, or just a couple of its objects, to one of the mentioned source control systems.March 4, 2015
The goal of database source control is to propagate changes from a development environment, to test and production without issues and to fulfill the need to restore a database at any point in time, maintaining an audit trail, and to allow successful team collaboration during the project.February 3, 2015
Collaborating on database development introduces a series of challenges. For instance, having the development team change the tables, views, stored procedures and other objects in a single, shared database, although intuitive, can introduce severe issues down the road as valid changes can be lost or overwritten by an unsuspecting teammate. This issue might be mitigated by restoring a database backup – under the assumption a valid backup exists. Even if it does, overwriting the development database with a backup means losing all of the valid database changes that have occurred since the backup was taken; not to mention the fact that restoring a large backup can take time – during which none of the developers can work on the database being restored.April 4, 2013
One of the caveats of having your SQL database under a source control system, is the overhead when the time comes to deploy a new database build. Even if a single copy of the database isn’t shared among the developers, but rather each developer has its own local copy of the database objects’ scripts which are synchronized with source control on a regular basis, building a deployment SQL script may prove to be a rather challenging task.April 4, 2013
It’s quite common for developer teams to use database object versioning. The creation scripts for every table, view, stored procedure, and other objects in the database are added to a source control system. That way, everything is versioned and the team is safe.
Applying a specific version of a source control system to a database is not a problem and it can be done by using a source control client.April 4, 2013