Settings and activity
18 results found
-
137 votes
An error occurred while saving the comment -
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
Robert supported this idea · -
14 votesRobert supported this idea ·
-
12 votesRobert supported this idea ·
-
86 votesRobert supported this idea ·
-
20 votesRobert supported this idea ·
-
46 votesRobert supported this idea ·
-
1 voteRobert shared this idea ·
-
37 votesRobert supported this idea ·
-
104 votesRobert 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…
- Supports column filtered static data tables in the SCA plugin in SSMS
-
89 votesRobert supported this idea ·
-
168 votesRobert supported this idea ·
-
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…
Robert supported this idea · -
212 votesRobert supported this idea ·
-
344 votesRobert supported this idea ·
-
480 votes
Thank you everyone for your comments and votes on this over the years. While I don’t have a 100% full resolution for this suggestion, I can sum up our current recommendations here. Continued feedback is very welcome.
Our current recommendation is to use the post-deployment script feature of SQL Source Control (released in V6.3) to manage SQL Server Agent jobs.
An example script for this is here: https://documentation.red-gate.com/soc/common-tasks/working-with-pre-post-deployment-scripts/create-sql-server-agent-job
As some commenters in this thread have alluded to, it is possible (and sometimes very common) for SQL Agent jobs to have steps that touch multiple databases on a single SQL Server Instance. For this reason, some customers prefer to create a separate database for instance-level management and objects (sometimes named DBA or similar) and choose to manage things like linked servers and SQL Agent jobs with the post-script associated with that database.
This separate-database architecture also makes sense if the jobs…
Robert supported this idea · -
215 votesRobert supported this idea ·
please, check out (it's for SQL Prompt=: https://redgate.uservoice.com/forums/94413-sql-prompt/suggestions/32271289-support-for-microsoft-sql-operations-studio