Settings and activity
4 results found
-
215 votesJennyfer Rusnak supported this idea ·
-
285 votes
Thanks to everyone for submitting feedback on this in the form of both voting and comments.
Currently, SQL Source Control does not have strong support for Azure SQL Database: as folks have noted in this item, AAD support, particularly with multi-factor authentication, is desired. Currently SQL Source Control does not work at all with Azure SQL Database with MFA enabled.
An additional issue worth mentioning is that pains with SQL Source Control performance may be worse than interacting with Azure SQL Database due to latency.
We would like to improve the user experience and support for Azure SQL Database, and doing so almost certainly involves addressing both of these issues. This is an area we are beginning to investigate more fully.
Jennyfer Rusnak supported this idea · -
8 votesJennyfer Rusnak shared 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…
Jennyfer Rusnak supported this idea ·