Comments
Sort by recent activity
Thanks Kendra, The current process that we use is that we test/validate the scripts against our Training database which is a copy of Production taken once a day. Once confirmed then we will run the script against Production. Applying the script to Production is a manual process that we would like to automate. Additionally we don't put the scripts in source control currently but rather get saved to a network share. So we definitely want to get them into source control as well as automate deployment. Since these scripts are very much dependent on the state of data and since our dev and test environments are typically stale from a data perspective, running them in dev and test as part of the pipeline wouldn't work well. What we might do is have a two stage pipeline for these scripts that just includes our Training and Production environments. Our we can run them through our normal pipeline but include conditional logic based upon environment, or even data state. Scott / comments
Thanks Kendra,The current process that we use is that we test/validate the scripts against our Training database which is a copy of Production taken once a day. Once confirmed then we will run the ...
Thanks again, it does appear that flyway suits our use case. / comments
Thanks again, it does appear that flyway suits our use case.
I resolved this by writing a powershell script to fix the line endings on the generated stored procedure files and then applied those changes back to my development database. After that the Refresh / Verification step completed successfully. I'm still not certain how the stored procedures were originally deployed without a linefeed on some lines. / comments
I resolved this by writing a powershell script to fix the line endings on the generated stored procedure files and then applied those changes back to my development database. After that the Refres...
Hi Neil,
Yes, that solved my problem. Thank you very much for the quick response!
Scott Kuhn / comments
Hi Neil,
Yes, that solved my problem. Thank you very much for the quick response!
Scott Kuhn
Hi Brian,
I've used the Red Flag debugger before. I generated a trace/debug file this morning if you want to send me instructions on how to send it then I will.
Basically all I did was open a project and run the compare. I did not have any differences so I just stopped there and closed SQL Compare. However, it was still running in the background. I detached the debugger at that point and saved the file.
Thanks,
Scott / comments
Hi Brian,
I've used the Red Flag debugger before. I generated a trace/debug file this morning if you want to send me instructions on how to send it then I will.
Basically all I did was open a proj...
Thanks David,
Okay; that confirms for me that the cross branch migration script won't work, and I understand why. We'll be looking forward to this being supported at some point in the future.
For now, I think we can "cheat" by resetting the version extended property to the version that the development branch started with, or removing it entirely, which seems to work. / comments
Thanks David,
Okay; that confirms for me that the cross branch migration script won't work, and I understand why. We'll be looking forward to this being supported at some point in the future.
For ...
Thanks for clarifying David.
Our situation is that we have a Production branch that reflects what we currently have in production and we branch from that to create a development branch when we begin working on a new release. During development we use a development database linked to the development branch. Since our development may take some time, we could have some changes required to our production database that must go into production before the release will. As a result, the production branch has progressed at the same time as the development branch. (This could also happen if we had two distinct releases in development at the same time.) Either way we need to resolve this. Typically we would make the same change to the development branch that we applied to the production branch. This is very common for us.
Ultimately, when development is complete and we are ready to deploy we could take one of two approaches:
1. Using the source control tool (vault in our case), merge the development branch to the production branch and then deploy to the production server from the production branch -OR-
2. Deploy to the production server from the development branch and then subsequently bring the changes into the production branch either through merge or through linking in SQL Source Control and committing changes.
This is our first time working with SQL Source Control so it is entirely possible that we are trying to use the tool incorrectly or in a way that was not intended or thought of. / comments
Thanks for clarifying David.
Our situation is that we have a Production branch that reflects what we currently have in production and we branch from that to create a development branch when we begi...
We are having similar issues with items like Show History and just trying to see the Commit Changes tab. Sometimes we get errors, which I've sent to Red Gate using the automated process, but have not heard anything back yet. / comments
We are having similar issues with items like Show History and just trying to see the Commit Changes tab. Sometimes we get errors, which I've sent to Red Gate using the automated process, but have ...
Wait, I apologize, we were choosing the source control location incorrectly when SQL Compare did not recognize the need for a migration script. We figured that out. Again, sorry about the additional question. / comments
Wait, I apologize, we were choosing the source control location incorrectly when SQL Compare did not recognize the need for a migration script. We figured that out. Again, sorry about the additio...