Comments
Sort by recent activity
Hi Peter, The first thing I should validate is to make sure that a deployment has happened via SQL Change Automation to the production database in the past. (The drift is since the last deployment -- so there's never a drift report on first deployment.) If this one is the case then it's possible to use SQL Compare to compare your project to the database to identify any key differences before first deployment. If that's not it, then my second guess is that the option "DriftFiltering" on New-DatabaseReleaseArtifact may be playing a role here. The default value for it is ModifiedObjectsOnly. With this default... Under this default behavior, the drift report will not include objects that exist in the target database but do NOT exist in the SQL Change Automation project. One possibility is that if the changes were to new objects that were created in the target which aren't in the project, these wouldn't show up as drift. If this might be the case, you can set -DriftFiltering to "AllObjects" to consider objects added to the target database as drift. Could this be what is going on? Kendra / comments
Hi Peter,The first thing I should validate is to make sure that a deployment has happened via SQL Change Automation to the production database in the past. (The drift is since the last deployment -...
Hi Yan, Apologies that you hit this error. I suspect that the error text bubbling up here may be misleading. The actual issue may be that the SQL Server can't resolve that specific login name. This can often happen if the production environment is in a different domain and than development. There are two things that you might wish to configure when creating the new project, before creating the baseline script: 1. Do you wish to include users (and related logins) in the project? If you do have some segmentation between your domains and the users and related logins which are being scripted aren't valid everywhere, then you probably wish to filter these out. To do this, when creating a project, on the "Options" screen there is an opportunity to specify a filter file that excludes users from the project. This filter file can be created and saved using the SQL Compare GUI.[image] [image] (Screenshot at the bottom of this post) I created a filter file excluding users and popped it in this Gist. More information is here on how to do this in case you'd like to do this yourself, or you want to create a more complex filter that also excludes other things. 2. Do you wish to include any permissions outside of role based permissions in the project? Sometimes permissions have been granted to individual users inside the database on specific objects. Often if you want to filter out users, you also want to change a comparison option so that only role-based permissions are included. To configure this, on the options tab when creating the project, hit the "Edit comparison options" button. This is right below where you configure the filter. Select "Users' permissions and role memberships" (screenshot below). Hope this helps! Kendra ----- [image] [image] / comments
Hi Yan,Apologies that you hit this error. I suspect that the error text bubbling up here may be misleading. The actual issue may be that the SQL Server can't resolve that specific login name. This ...
Hi @Sean_Lively, We don't currently have separate documentation for the YAML task. I wasn't sure how many of our customers were interested in YAML pipelines in Azure DevOps and created that page as a first step, so I'm glad to hear that you found it and are interested in this! I used our graphic CI/CD plugins to help write the YAML there -- I think they would help you configure LocalDB as well. In the video linked at the bottom of that page I show what I did at around this point: [image] https://youtu.be/oXampkDWcC0?t=405 Hope this helps, Kendra / comments
Hi @Sean_Lively,We don't currently have separate documentation for the YAML task. I wasn't sure how many of our customers were interested in YAML pipelines in Azure DevOps and created that page as ...
Hi @bkillen, SQL Source Control isn't designed for this use case-- the files committed to the repo are designed to be purely the object definition rather than a deployment script. Can I ask more about the use case / why this is important for the team? Cheers, Kendra / comments
Hi @bkillen,SQL Source Control isn't designed for this use case-- the files committed to the repo are designed to be purely the object definition rather than a deployment script.Can I ask more abou...
Ah, I see. With SQL Source Control, the behavior is that it provides a standardized way of committing the files. But these are not designed to be deployment scripts -- for many object types (tables, etc), that wouldn't work at all. There are a few options to configure deployments for SQL Source Control projects. I don't know if your app development team holds licenses for SQL Compare or any other Redgate products, but if they do then there are options for them to create deployment scripts which include those re-runnable headers in them -- but this does require having SQL Compare or another tool to create those deployments. Happy to help give more detail on those if that would be helpful. Cheers, Kendra / comments
Ah, I see.With SQL Source Control, the behavior is that it provides a standardized way of committing the files. But these are not designed to be deployment scripts -- for many object types (tables,...
Hi Peter, We do support the same project being worked on in both plugins. The SSMS plugin has no concept of a solution and creates a fairly minimal project -- just what SCA needs to get things done. If you create a project in SSMS and commit it, then open it in Visual Studio, Visual Studio will add some extra files to source that it will want to commit. These shouldn't create a problem when working with the project in SSMS, however. I believe this is the main difference. Cheers, Kendra / comments
Hi Peter,We do support the same project being worked on in both plugins.The SSMS plugin has no concept of a solution and creates a fairly minimal project -- just what SCA needs to get things done. ...
Hi Peter, Aha, I see! So to make this work, I believe you would need the ability to have Azure Active Directory authentication on the build task. We do support Azure Active Directory password authentication on building, but currently this option isn't available in the graphical plugin in Azure DevOps. If you are open to switching that step to a powershell step to do the build, you could test it out that way. The powershell build would use New-DatabaseConnection to specify the authentication when connecting and pass this connection into Invoke-DatabaseBuild. Then you'd need to call New-DatabaseBuildArtifact followed by Export-DatabaseBuildArtifact. Is that of interest to you? Totally understand if you decide to go with plan b instead. For longer term, we do have a prioritized ticket open to add Azure Active Directory Password authentication to the Azure DevOps build task itself based on a separate customer request. I added a comment to the ticket mentioning that you are an additional customer who would find this useful. Cheers, Kendra / comments
Hi Peter,Aha, I see! So to make this work, I believe you would need the ability to have Azure Active Directory authentication on the build task. We do support Azure Active Directory password authen...
And sorry, reading this I see that it's EXTERNAL USER and not external tables. I clearly have external tables on my mind! I think overall the general notes /approach is the same. It might be complex if those user accounts own objects, but otherwise might be relatively simple. / comments
And sorry, reading this I see that it's EXTERNAL USER and not external tables.I clearly have external tables on my mind!I think overall the general notes /approach is the same. It might be complex ...
Hi @gail123, We are looking to improve on this functionality and make the ability to deploy from SQL Source Control via migrations much smoother. Would you be open to me emailing you about possibly participating in a preview of a new tool? Cheers, Kendra / comments
Hi @gail123,We are looking to improve on this functionality and make the ability to deploy from SQL Source Control via migrations much smoother.Would you be open to me emailing you about possibly p...