Settings and activity
18 results found
-
130 votesEd Morris supported this idea ·
-
300 votes
SQL Prompt for Azure Data Studio is now in public preview!
The aim of this public preview is to learn from the ADS community about how SQL Prompt can enhance your developer experience, adding improvements and new features based on your feedback.
With SQL Prompt, you can use an extensive collection of code snippets to write your SQL code quickly and efficiently. You can also keep your code consistent using the powerful formatting capability, with the ability to customise the applied style to suit your preferences.
We’d love to hear your feedback. You can get in touch with the team either via the new SQL Prompt in ADS forum: https://forum.red-gate.com/categories/sql-prompt-in-ads or email us at sqlprompt.in.ads@red-gate.com.
Get started with SQL Prompt for Azure Data Studio now. Download it here: https://download.red-gate.com/EAP/SQLPromptADS.zip
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 votesKendra 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 ·
-
86 votesEd Morris supported this idea ·
-
105 votesEd Morris supported this idea ·
-
117 votesEd Morris supported this idea ·
An error occurred while saving the comment Ed Morris commentedThe 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.
-
79 votesEd Morris supported this idea ·
-
207 votesEd Morris supported this idea ·
-
92 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 commentedUsing 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.