Comments
Sort by recent activity
Hi @mirving , Presently the experimental method you're referencing in the article is the only way to use SQL Source Control in Azure Data Studio. Thank you very much for the feedback on it, it's incredibly useful for us to hear that. I am interested in learning more about how you use feature branches in general, if you don't mind sharing:
Are there times when you want to make a change in the database and commit this into more than one feature branch? If so, how do you currently go about this?
If I run through a scenario like you're describing -- add a table in my database and commit to BranchA, then switch to BranchB, SQL Source control will list the table in the 'Get latest' tab and essentially suggest 'undoing' the change in the database. Do you tend to use that?
Do you have other comments or feedback about your biggest pains or wishes for working with branches?
Cheers, Kendra / comments
Hi @mirving ,Presently the experimental method you're referencing in the article is the only way to use SQL Source Control in Azure Data Studio. Thank you very much for the feedback on it, it's in...
Hello, Thank you for confirming. With SQL Source Control, I believe that the setting you are looking for is called "Ignore users' permissions and role memberships". You set this on the "Setup" tab under "Comparison Options." You may also find some additional information useful in this article on Source Controlling Your Database Permissions, which is specific to SQL Source Control. Hope this helps, Kendra / comments
Hello,Thank you for confirming. With SQL Source Control, I believe that the setting you are looking for is called "Ignore users' permissions and role memberships". You set this on the "Setup" tab u...
Hi there, To clarify your setup, which tool are you using to commit changes to your project? Are you using SQL Source Control to do this? Or SQL Change Automation? Thanks, Kendra / comments
Hi there,To clarify your setup, which tool are you using to commit changes to your project? Are you using SQL Source Control to do this? Or SQL Change Automation?Thanks,Kendra
Hi @Koenraad.Dendievel, Thanks for letting us know about your use case. This enhancement is up for consideration and I've updated the request with the use case info you provided. It's just up for consideration and not something we're actively working on presently, but understanding customer impact definitely helps us. Kendra / comments
Hi @Koenraad.Dendievel,Thanks for letting us know about your use case. This enhancement is up for consideration and I've updated the request with the use case info you provided. It's just up for co...
And I've just found that I can answer this more fully before knowing which "authoring" tool you are using. There is a way that you can skip the build process if desired, by using the New-DatabaseProjectObject powershell cmdlet. Some notes on this:
You would implement this using a PowerShell step in Azure DevOps, instead of the graphic plugin. The documentation page linked above has examples for doing this (one example is for a SQL Source Control project, one is for a SQL Change Automation project)
The build process adds some additional value in terms of validation. It also creates a snapshot of the desired target schema which is used for things in the "Create Release Artifact" process, such as the changes report and the drift report. That means that if you skip the build process, you'll still have the ability to deploy, but won't have these extra features.
As mentioned above, this also skips the validation process.
I think that what you are mentioning above is that you might have more than one kind of build pipeline, and only run the "full" build when you are generating a NUGET package that is planned to be deployed to production? I'm not entirely sure what your branching strategy and development database workflow is, but combining the two approaches might work, and then you would still get the changes report, the drift report, etc for your production release artifacts. Cheers, Kendra / comments
And I've just found that I can answer this more fully before knowing which "authoring" tool you are using.There is a way that you can skip the build process if desired, by using the New-DatabasePro...
Hello, Sorry for the slow response, and thanks for the information that build time sounds like it is a pain point. Can I ask if you are using SQL Change Automation to deploy a SQL Source Control project, or is it a SQL Change Automation project that you are deploying with SQL Change Automation? Thanks, Kendra / comments
Hello,Sorry for the slow response, and thanks for the information that build time sounds like it is a pain point.Can I ask if you are using SQL Change Automation to deploy a SQL Source Control proj...
Hello, Yes, the build process creates a database for validation purposes. If you skip this step, you would lose assurances that the code you have committed is valid SQL that is suitable for a deployment. You have the option to have the build dynamically create the database for this purpose and drop it after, or if it is more convenient you can hardcode a name for the database and reuse an existing database for each build. (The database will be "cleaned" so validation can succeed.) Can you explain why you would like to skip this step? Is there some barrier preventing you from using a database for this purpose, or some problem that you are hitting? Cheers, Kendra / comments
Hello,Yes, the build process creates a database for validation purposes. If you skip this step, you would lose assurances that the code you have committed is valid SQL that is suitable for a deploy...
Hello, In order for changes to be detected in the data inside the table, you need to add the table as a "Static Data Table". This indicates that you'd like to version control the data. This can be done in either Visual Studio or SSMS. This article shows how it works in SSMS and also links to some helpful resources: Using SQL Change Automation in SSMS to Track Static Data Changes - Redgate Software (red-gate.com) Hope this helps, Kendra / comments
Hello,In order for changes to be detected in the data inside the table, you need to add the table as a "Static Data Table". This indicates that you'd like to version control the data.This can be do...
One follow up on this -- if you're having issues getting this set up, consider opening a ticket with our support team. They're excellent and if you hit some hurdles, opening a ticket with them can help you move forward quickly. More info on contacting them is at Support (red-gate.com) -- scroll down and there's a gray bar with all the contact methods. / comments
One follow up on this -- if you're having issues getting this set up, consider opening a ticket with our support team. They're excellent and if you hit some hurdles, opening a ticket with them can ...
Hello, To deploy a SQL Change Automation project, the process we recommend flows like this:
Run a successful build for the code you want to deploy. This outputs an artifact in the form of a NUGET package.
Deployment is a two step process:
A. Create a release artifact using the NUGET package from the build and setting the target database. This looks at what has been deployed so far to the target database and also can evaluate things like whether drift has occurred since your last deployment.
B. Deploy the release artifact to the target database. If you are sure that all target databases will be the same and are not concerned about drift, it is possible to create a release artifact against one database, and then deploy it to as many target databases as needed.
All of the steps above can be done using PowerShell. (References here have good examples: New-DatabaseReleaseArtifact, Use-DatabaseReleaseArtifact) To dig into your question, the NUGET package from the build does essentially contain a copy of the migration files from the project. So this process is, essentially, moving the migration files for you. But it also adds significant functionality on top of that, like checking which migrations have already been run against the target, running the migrations in the same order as has been tested in the verify and build process, etc. Hope this helps, Kendra / comments
Hello,To deploy a SQL Change Automation project, the process we recommend flows like this:
Run a successful build for the code you want to deploy. This outputs an artifact in the form of a NUGET ...