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 votes
Ed Morris
supported this idea
·
-
87 votes
Ed Morris
supported this idea
·
-
103 votes
Ed Morris
supported this idea
·
-
117 votes
Ed 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 votes
Ed Morris
supported this idea
·
-
207 votes
Ed Morris
supported this idea
·
-
89 votes
Ed Morris
supported this idea
·
-
61 votes
Ed Morris
supported this idea
·
-
70 votes
Ed Morris
supported this idea
·
-
43 votes
Ed Morris
supported this idea
·
-
58 votes
Ed Morris
supported this idea
·
-
10 votes
Ed 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
-
633 votes
Hi,
We just added this capability to Flyway, which is our x-database, x-OS cloud- and Git-first Database DevOps solution for versioning and deploying database changes. You can learn more about this feature in Flyway at https://documentation.red-gate.com/fd/working-with-data-138347109.html#Workingwithdata-Controllingstaticdata.
You can also import your SQL Source Control repos into Flyway while keeping your Git history. Learn more about moving to Flyway and importing your project at https://documentation.red-gate.com/fd/transitioning-from-other-redgate-tools-164167855.html.
If you have any questions, please comment below or reach out to us at DatabaseDevOps@red-gate.com.
Thank you!
Stephanie Herr
Product Manager - Database DevOps
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.