Settings and activity
5 results found
-
4 votes
An error occurred while saving the comment -
31 votes
An error occurred while saving the comment 
Kendra
commented
An update on this "classic" request -- I realize that it has been some time since this has been suggested!
We have started to see more and more users in the Microsoft Data Platform world show an interest in Linux, as well as a desire from many users to have a more cross-platform experience which also includes non-Windows OSes.
I am happy to say that we do have items on our roadmap now in this area: https://www.red-gate.com/products/redgate-deploy/roadmap
-
17 votes
For clarification for readers, this request is specific to SQL Source Control projects which are deployed by SQL Change Automation. Comments in the item give more detail.
An error occurred while saving the comment Kendra
commented
Apologies for the late follow up on this one, but posting some additional information in case it helps other readers.
This issue is specific to SQL Source Control projects which are deployed with SQL Change Automation.
If you are using a SQL Change Automation project to author your version control changes, it will deploy pre- and post- scripts on every deployment, regardless of whether there is a change to the migrations, or a change to the pre-and post scripts. (This supports scenarios where the database may have drifted and you want to re-apply pre- and post- scripts.)
As alluded to in the suggestion, there is a workaround to force a deployment of a SQL Source Control project, such as adding or updating a lightweight item such as an extended property.
I totally understand that the suggestion is to not need to have that workaround and I see the value in that -- I just wanted to add detail on that for anyone who is curious about what someone might do if they didn't want to edit a procedure, etc.
Thanks for this suggestion and also thanks to those who commented and voted this up.
-
1 vote
An error occurred while saving the comment Kendra
commented
Hi.
Thanks for this suggestion. I have myself managed to confuse myself by pushing without committing, and then being confused by the empty branch at the origin.
This is an interesting one to think through, because it is possible that changes might be committed to the current branch outside of SQL Change Automation. It might be changes to application code, or example. Running "Git Push" in SQL Change Automation, like any Git client, would still push these changes.
I am curious if you think this would matter, or if it would be enough to simply surface when a "Git push" doesn't find anything to push (committed by any Git client to the local git repo)?
-
1 vote
While this item isn’t specifically on our roadmap at this time, we have plans to improve and evolve the hybrid model in our offerings in 2021, and this will be a good candidate for consideration.
An error occurred while saving the comment Kendra
commented
Thank you for this suggestion.
Static data is a popular feature for our users and I agree that this would improve the hybrid model.
While this item isn't specifically on our roadmap at this time, we have plans to improve and evolve the hybrid model in our offerings in 2021, and this will be a good candidate for consideration.
Hi Alex,
I am curious how often you need to do this task / what the workflow is with your static data tables is that makes this useful?
I think typically "static data" has a bit of a one-way flow, and simply gets added to the development database, committed, and deployed from there.
But it sounds like you have a case where the data may be added to other databases in your environment, and then needs to get added back into the static data table in the development environment after? Almost like a kind of static data drift that needs to be handled?
I'd love to learn more about the scenario to understand it better.
Kendra