Settings and activity
18 results found
-
132 votes
Ed Morris
supported this idea
·
-
304 votes
Given the upcoming retirement of Azure Data Studio we'd be really interested to hear from our community about where you'll be moving your database development.
If you'd like to chat about your development workflow and hear about our roadmap plans drop me an email and we'll get something set up.
Thanks,
Tim
Ed Morris
supported this idea
·
-
530 votes
Thanks for this suggestion and for the many comments and upvotes. I realize that this is a pain point.
I have a few shorter-term workarounds to summarize as well as some information on the longer roadmap in this update. I know these shorter-term workarounds aren’t perfect (I summarize the pros and cons), but I’m posting them as they may help a few folks.
Workaround 1) When data changes to static data need to be made, use a “relink the table” pattern
One can “cleanly rescript” a static data table in SQL Source Control by:- Unlinking the static data table
- Committing
- Relinking the static data table
- Committing
Pro: This works with the GUI and requires no special knowledge or comfort with TSQL. This may help folks with just a few static data tables.
Con: This requires extra steps and results in extra commits in the history, which I realize can…Ed Morris
supported this idea
·
An error occurred while saving the comment -
21 votes
Kendra
responded
Thanks for this feedback.
We have quite strong support for this request in SQL Change Automation projects, which support multiple pre- and post- deployment scripts and which also have an option to “seed data” for larger tables which you would like to populate: https://documentation.red-gate.com/sca/developing-databases/concepts/data-population/strategies-for-data-population
For SQL Source Control, we now support pre- and post- deployment scripts, however you are limited to only one of each type. Additionally, the seed data methodology is not available in SQL Source Control.
Ed Morris
supported this idea
·
-
2 votesEd Morris
supported this idea
·
-
87 votesEd Morris
supported this idea
·
-
103 votesEd Morris
supported this idea
·
-
117 votesEd Morris
supported this idea
·
An error occurred while saving the comment Ed Morris
commented
The base support would be to push table changes that are made manually in the database - currently we receive the error 'You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels.' as the SERIALIZABLE transaction level is used. The desired support would be a way to identify replicated tables and provide a feature that pushes schema changes to all databases that are subscribed.
-
82 votesEd Morris
supported this idea
·
-
207 votesEd Morris
supported this idea
·
-
89 votesEd Morris
supported this idea
·
-
61 votesEd Morris
supported this idea
·
-
70 votesEd Morris
supported this idea
·
-
43 votesEd Morris
supported this idea
·
-
58 votesEd Morris
supported this idea
·
-
10 votesEd Morris
supported this idea
·
-
254 votes
Hi all. Thank you for your votes and feedback on this issue over the years. Here is our current guidance for this suggestion:
Post-deployment scripts give you flexibility for static data
With SQL Source Control, you can now use a post-deployment script to “dynamically” deploy static data based on a factor such as @@SERVERNAME or other query-able conditions.
SQL Source Control introduced pre- and post- scripts in v6.3.
An example post-deployment script which shows how to control deployment of static data by environment is 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 a preference to manage static data tables in dedicated post-deployment scripts - Allows approaches like bulk loading larger static data tables by supporting SQLCMD…
An error occurred while saving the comment Ed Morris
commented
Using the Static data link and Source Control is awesome however we immediately ran into an issue with this "static" data being environment aware - server names are different between Dev and QA for example. The concept to transform the data when being deployed is ideal, like this request!
Ed Morris
supported this idea
·
- Supports column filtered static data tables in the SCA plugin in SSMS
-
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…
Ed Morris
supported this idea
·
PLEASE DO THIS NOW!!! Merges are a nightmare in the db mostly due to this non-sense of not ordering by key.