Comments
Sort by recent activity
Glad that you're making progress. Baby steps is the best way, and thank you for the very kind words. / comments
Glad that you're making progress. Baby steps is the best way, and thank you for the very kind words.
You can pull out the script to create those objects from your baseline script. Once those are in prod, you can give the update.SQL script from the create release step to the DBAs to review and run manually. This will update the migration log as part of the script until you implement more automation / comments
You can pull out the script to create those objects from your baseline script. Once those are in prod, you can give the update.SQL script from the create release step to the DBAs to review and run ...
For me I'd start with a PoC. Changing your existing process and altering what works is hard. It's scary, and you might break somethign. What I'd do is create a new db in dev and a new one in prod (and QA/test/staging/etc). Put in a single table in each, so they're synced. Now, add a proc in dev, check into VCS. Set up CI/CD, and give the DBAs control over the release. Let them see what moves as you practice some small changes. Once you work out the best process for your group, with flow, timing, notifications, permissions, etc., you can talk about moving a prod db over. / comments
For me I'd start with a PoC. Changing your existing process and altering what works is hard. It's scary, and you might break somethign.What I'd do is create a new db in dev and a new one in prod (a...
You should not be moving branches often in SQL Source Control (SOC). This doesn't support things well, and it creates confusion. The preference for SOC is to assume your database is the source of truth. This means you get updates in either Commit or Get Latest that sometimes don't make sense. If you want to commit your source of truth, do that. If you don't, you might need to undo those changes. The fundamental issue is that we try to treat all objects the same, and for tables, this is a problem. We don't have an easy way to populate new columns or hold data from dropped columns when branches change. You ought to have a separate database per branch. Ideally, when you abandon a branch, you should drop that db, and then create a new one to reload from a new branch. If you're trying to determine what is different when merging two branches, this is better handled in a VCS tool (GitKrakken, SourceTree, etc). SOC doesn't handle this well and it gets confusing.
/ comments
You should not be moving branches often in SQL Source Control (SOC). This doesn't support things well, and it creates confusion. The preference for SOC is to assume your database is the source of t...
As Mikiel answered, you really want to more exhaustively test things. If you need to revert back a particular change that shouldn't go, issue 2. then you'll have to undo the change in your dev branch, and merge back that undo. This could be problematic, as the nature of database development is that the chronology of changes matters. If Issue 1 is a stored proc/view/function change and issue 2 is as well, this is easy. Revert back to the previous version of issue 2, then merge that in. If issue 2 is a table change, then this could be problematic if other work is built on top of this as you're not affecting data. There isn't a simple way to do this, as undoing table changes is much more complex and really is an "issue 3" change that you roll out. Having feature toggles/flags and rolling db changes out first are more helpful here if you need to undo something.
I'd also say that your branches ought to be very short lived (hours). If someone is working out things longer than that, they ought to pull from master to merge in other changes and be sure they aren't breaking thing. You also will want to ensure that developers working independently sync up and coordinate to be sure they're not working on dependent objects. If they are, they will potentially cause conflicts. If they edit the same object, it's like two people editing the same method. A recipe for problems.
/ comments
As Mikiel answered, you really want to more exhaustively test things. If you need to revert back a particular change that shouldn't go, issue 2. then you'll have to undo the change in your dev bran...
Merge to master. The Issue 1 Branch allows the developer to work and test without disturbing releasable software (in master). Once this is "done", then merge it into master. In this way, you have a merge point for Issue 1 and one for Issue 2, which should allow you to undo or revert work if needed. / comments
Merge to master. The Issue 1 Branch allows the developer to work and test without disturbing releasable software (in master). Once this is "done", then merge it into master. In this way, you have a...
The New-DatabaseReleaseArtifact takes an object that is a connection to a database. You would use New-DatabaseConnection to get that object. We don't use just parameters for many things, so you need to make a connection there. This returns an object. The path for output files is a parameter for Export-DatabaseReleaseArtifact https://documentation.red-gate.com/sca3/reference/powershell-cmdlets/new-databasereleaseartifact https://documentation.red-gate.com/sca3/reference/powershell-cmdlets/new-databaseconnection https://documentation.red-gate.com/sca3/reference/powershell-cmdlets/export-databasereleaseartifact / comments
The New-DatabaseReleaseArtifact takes an object that is a connection to a database. You would use New-DatabaseConnection to get that object. We don't use just parameters for many things, so you nee...
The code analysis should run as part of New-DatabaseReleaseArtifact (the PoSh cmdlet): https://documentation.red-gate.com/sca3/reference/powershell-cmdlets/new-databasereleaseartifact The release report from this cmdlet contains the settings and warnings. Or are you looking for something more consummable programmatically like an XML result?
You can add in a settings file, some of which is described here: https://documentation.red-gate.com/sca3/automating-database-changes/code-analysis Rules get configured with Prompt and then a settings file saved that you can reference. / comments
The code analysis should run as part of New-DatabaseReleaseArtifact (the PoSh cmdlet): https://documentation.red-gate.com/sca3/reference/powershell-cmdlets/new-databasereleaseartifactThe release re...
Can you show a repro of the code? I assume you removed the check constraint and then altered the function. Is that correct? There is a chronology here. In your production db, you'll need to do the same thing. When the build process works, it uses SQL Compare, which sees the function change, but isn't picking up the binding on the CHECK constraint. I think this is a bug, so I'll file this with a repro to see if they can correct this. For now, I'd say that you need a one time migration script, or pre/post scripts that remove the CHECK and add it back at the end around the alter function.
/ comments
Can you show a repro of the code? I assume you removed the check constraint and then altered the function. Is that correct?There is a chronology here. In your production db, you'll need to do the s...
In my repro, the build succeeds, as this should be to a blank db and the dependencies should be chained. Is this failing in build or some release/update? My release also succeeds, so I'd like to know what repro might work for me.
/ comments
In my repro, the build succeeds, as this should be to a blank db and the dependencies should be chained. Is this failing in build or some release/update?My release also succeeds, so I'd like to kno...