Settings and activity
8 results found
-
636 votes
Hi everyone. I have merged some User Voice items on this topic of “filtered” static data, as there was significant overlap. I want to share our current guidance on handling scenarios where you need to version a subset of the columns and/or rows in the table.
With SQL Source control, the best option at this point is to use a post-deployment script for this purpose.
SQL Source Control introduced pre- and post- scripts in v6.3.
A post-deployment script gives you a good amount of flexibility over exactly which rows or columns of data you want to include in your project. Example post-deployment scripts for static data are here: https://documentation.red-gate.com/soc7/common-tasks/working-with-pre-post-deployment-scripts/static-data
If you make heavy use of Static Data, we have stronger support for this in SQL Change Automation.
SQL Change Automation:
- Supports column filtered static data tables in the SCA plugin in SSMS
- Supports multiple post-deployment scripts, in case there is…
Marcin
supported this idea
·
-
200 votes
Kendra
responded
While SQL Source Control does not currently provide a simple way to right click and ‘Undo’ static data changes on the ‘Commit’ screen as suggested, there is a workaround which may help some users.
If you wish to revert the static data in the table to a previous version which you have committed, you can do this by viewing the history of commits for the object in SQL Source Control, and then launching SQL Data Compare to update the database.
Please note that this workaround requires a license for Data Compare. More detail on how to do this are here: https://documentation.red-gate.com/soc/common-tasks/update-to-a-revision-from-source-control
Marcin
supported this idea
·
-
104 votesMarcin
supported this idea
·
-
35 votes
An error occurred while saving the comment -
17 votes
-
15 votes
-
10 votes
-
13 votes
An error occurred while saving the comment Marcin
commented
I have the same problem, but I could divide it on two topics:
First is connected with option "Force binary collation", if I switch off this option then comparison result is correct (although the data are identical)
Second is connected with some characters: #, $, + (these values are primary key values).
In such case a conflict is shown). Both comparison sites contain following statements:INSERT INTO <table1> (<columns>) VALUES (N'#', N'Hash', NULL)
INSERT INTO <table1> (<columns>) VALUES (N'$', N'Dolar', NULL)
INSERT INTO <table1> (<columns>) VALUES (N'+', N'Plus', NULL)(Database collation: SQL_Latin1_General_CP1_CI_AS)
This is not only problem of SQL Source Control, our build server uses SQL Comparer and SQL Data Comparer command line tools to build nightly our development server and it failed when I switch on the option "Force binary collation".
This issue is crucial for us because TFS server is located in another country then a developing team. Please give us a feedback when such functionality can be included in SQL Source Control.