Use source Safe for SQL Server to troubleshoot database versioning issues (reproduced)

Version control is a well-known concept in the software development process. Because a project may require the involvement of different actors, using version control software allows people of different roles in the project to participate in the project in parallel. Source code control allows code to exist in multiple versions without confusing the codebase, typically including bug fixes, adding new features, versioning, and more.

Although version control software at the development level is already very mature, there is currently no version control software specifically targeted at the database level to help people of different roles perform team collaboration at the database level, change code management, and view and compare changes to the database. The lack of version control tools at the database level may occur in the following scenarios:

• Team collaboration at the database level is not possible: developer A's modifications to stored procedures cause the stored procedures created by developer B to be overwritten so that they cannot be compared and tracked
• Developer-Dev dba-testers are hard to collaborate: SVN and other version tools are file-based and difficult to version control at the database level
• Database changes are difficult to track: existing technologies cannot track who, when, what has been modified on the database, and when errors or performance degradation occurs due to a database, it is difficult to troubleshoot
• Process assets for database changes cannot be logged: History of database changes only database operators understand that these process assets are difficult to inherit when the relevant person leaves or is redeployed
• It is difficult to audit the database: The existing database audit function often relies on the log, which has a great impact on performance.
• SQL scripts cannot be managed effectively: the existing practice is often to save SQL as a file and not to effectively manage and share
• Unable to view the encrypted database object: When you need to modify an encrypted database object, you must override the object definition if the original record cannot be found
• SVN build and use complex: SVN usage process is too cumbersome for database personnel, adding extra work burden to database personnel

Because the database is the core of the entire business application, the above problems, whether in the development environment or in the production environment if not effectively resolved, will lead to low productivity, the process assets can not be managed, database review cannot be carried out, difficult to troubleshoot the problem caused by database changes and so on.

Here's how source Safe for SQL Server solves this kind of problem.

installation of software

The software's official website after downloading the source Safe installation package All the way next, after the installation is complete, open management Studio, in the need to join the source controller of a database server right-click on the pop-up menu, select "Add Database to Version control", 1.

Figure 1: Adding a database to version control

Then set the relevant options, as shown in 2.

Figure 2: Adding Database-to-version control-related settings

Now again, the entire database is already under version control, as shown in 3.

Figure 3: Viewing a versioned database

At this point, Source safefor SQL Server is complete with the installation configuration.

Typical application Scenarios

Source safe resolves the following issues:

Development team for version control

In a development team, each change to a database object automatically overwrites the previous version, resulting in the loss of the previous version object definition. For example, developer a creates the stored procedure "Proca", then developer b modifies the stored procedure "Proca", and the stored procedure created by developer A will be overwritten by the modifications made by developer B, resulting in the loss of the previously defined stored procedure and the inability to rollback. This type of problem can be easily resolved with source safe.

With Figure 4, we see that the stored procedure "Proca" has been created by the developer "Jack", and the developer "Careyson" has modified it, and the Source safe can fully record who, at what time, what modifications were made.

Figure 4: View the history of the stored procedure "Proca" being modified

Figure 5: Viewing the differences section of the stored procedure "Proca" two versions

Development Milestone Marker

During the development process, it is often necessary to iterate over the development milestones, and the database object changes resulting from each development milestone can be recorded and documented completely.

Figure 6. Milestone version and the object changes involved

Production environment Change Management

In a production environment, program upgrades, programs, or human changes to database objects can cause problems with the database, such as application errors or degraded database performance. With SourceSafe, you can quickly troubleshoot errors and ensure that the database continues to run stably by rapidly comparing the parts of the database that are different from the previous version and the current database definition, and rolling back the objects that cause the database to be problematic, depending on the situation. As shown in 7.

Figure 7: Selecting objects that require a version comparison

Common script Management

Both the developer and the operational personnel of the database will have common scripts that need to be saved. In the past, it was often the case that SQL code was saved as a file, which was neither convenient nor convenient for classification management. With the code management capabilities of source Safe, it is convenient to seamlessly integrate the management of SQL code into SQL Server Management Studio. As shown in 8.

Figure 8, SQL Management using the Script management feature of Source Safe

In addition, the Source safe specifically sets the default folder "toolbar Shortcuts", where users can place frequently used SQL code, and scripts in that category automatically appear in the Management Studio toolbar, shown in 9.

Figure 9, placing common scripts in the toolbar shortcuts

To categorize the selected objects by version

Although source safe generates a change-based version number after each synchronization, additional tags are required in certain special cases, such as the need to manage certain changes in the library and categorize the versions in the library. As shown in 10.

Figure 10, using tags to mark the database objects involved in a business version

Seamless integration with SVN

SourceSafe's version content and history can be exported directly to SVN, TFS, and VSS, thus opening up database versioning and existing SVN systems. In the database we are on the stored procedure dbo. TestProc made three changes, as shown in 11.

Figure 11:3 Changes to the stored procedure

Next, export the history as shown in svn,12.

Figure 12: Export SourceSafe records to SVN

After the export is completed, the SVN client software can see the corresponding SQL files in the database corresponding to the three changes in Figure 10, as shown in 13.

Figure 13. SVN corresponds to 3 changes in SourceSafe

Download the software

Software downloads can be downloaded from the software's website, please click here (http://www.grqsh.com/products.htm?tab=sourcesafe-for-sql-server).
Reprint Address: http://www.cnblogs.com/CareySon/p/3700601.html

Use source Safe for SQL Server to troubleshoot database versioning issues (reproduced)