Settings and activity
7 results found
-
19 votes
An error occurred while saving the comment 
Jimbo
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.
An error occurred while saving the comment Jimbo
commented
2024 dawns and still no resolution for Azure AAD support....
Only workaround I've seen posted by Redgate is to move to Flyway!
Well Redgate I'm perfectly happy with Source Control and have been using it since 2014.
I've looked at Flyway and it is a completely different source control product and not suitable for my needs at all.
Most of the other Redgate products are now Azure login compatible. My company and others are still paying good money year on year for support of Redgate Source Control. It's not a lot to expect that some development time be put into bringing Redgate Source Control up-to-date with regards Azure login support.
This issue was under review in 2020 and still no hint of work starting!
Not good enough Redgate.
Jimbo
supported this idea
·
An error occurred while saving the comment Jimbo
commented
So this request was first raised in 2016!!!!
Nearly 6 years on and still no resolution.Redgate is becoming a company that is out of touch with its userbase and is quite happy to carry on collecting the money for Source Control but not add any new features that its developers actually want.
There are alternatives to look at now and I shall be advising my company to look at them.
-
4 votesJimbo
shared this idea
·
-
74 votesJimbo
supported this idea
·
An error occurred while saving the comment Jimbo
commented
Should also search for server attribute of synonym as well. Times I've been caught out when looking for synonyms that are referencing objects on a particular server
-
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…
Jimbo
supported this idea
·
-
193 votesJimbo
supported this idea
·
-
151 votesJimbo
supported this idea
·
Redgate's idea of listening to the customer is to keep telling them that SQL History is a much better replacement for Tab History.
Even though enough people have complained and stated quite clearly that it is NOT a better replacement in any sense of the word.
Bring back Tab History and stop being so stubborn about the issue and show a bit more respect for your paying customers!