Comments
Sort by recent activity
Hi Devware , Yes, you can output SQL Compare results to a script file when using the command line. Check out the ScriptFile command line switch, I believe that is what you are looking for. Hope this helps, Kendra / comments
Hi Devware ,Yes, you can output SQL Compare results to a script file when using the command line. Check out the ScriptFile command line switch, I believe that is what you are looking for.Hope this ...
Hi @skuhn , I know we do have many customers who include data update scripts in their SCA project. However, the folks who I have talked to about this are dealing with a much lower volume of them, such that they don't have the concern you have about noise. Can I ask what your desired process is for testing/ validating these data modification scripts? And whether it is helpful or desirable for these scripts to be run against any dev/test environments you have in your pipelines? Kendra / comments
Hi @skuhn ,I know we do have many customers who include data update scripts in their SCA project. However, the folks who I have talked to about this are dealing with a much lower volume of them, s...
Hi, Thanks for the extra info -- that makes sense. Putting these in a separate project, it seems like it will be tricky for you to do a full CI/CD process -- because to build the project you would need the schema of the database. You could do something like merge the schema in from the other project regularly -- but since you have ~12+ of these a week, that'd be really frequent and a lot of work. And it sounds like your testing requirements don't need that. Since your goals for this are really to version this and to automate execution, I would personally consider using Flyway for these kinds of scripts. Flyway doesn't support a full CI/CD process, and it doesn't help you author the scripts like SCA does for schema changes -- it's much more of a "script automation" tool. But in this case, that sounds like more what you need: https://flywaydb.org/download Kendra / comments
Hi,Thanks for the extra info -- that makes sense. Putting these in a separate project, it seems like it will be tricky for you to do a full CI/CD process -- because to build the project you would n...
@a.higgins Thanks for the further info. There might be a way to accomplish what you need. I think in your situation I might getting the latest copy of the code to a folder, and then use powershell or a similar scripting language to insert the needed USE database statements into the scripts before importing it into Erwin. They are simply stored as text files, so this may be possible to automate if it needs to be done on a regular basis. / comments
@a.higgins Thanks for the further info. There might be a way to accomplish what you need. I think in your situation I might getting the latest copy of the code to a folder, and then use powershell ...
Hi @a.higgins, I'm afraid this setting doesn't do what you are looking for by design -- the setting is around deployment scripts. The object definitions stored in SQL Source Control are often different from the deployment script (for example, the a whole table's definition is stored, if it's deployed to a database where the table already exists, but is different, the deployment script will be some series of ALTER commands, etc.). If we stored a database use statement at the top of the scripts in version control, then it might produce unexpected results for users in some cases -- for example, if the user wanted to deploy the schema to an empty database with a different name for validation purposes, the script might make changes to a different database than they expected on that instance. Cheers, Kendra / comments
Hi @a.higgins,I'm afraid this setting doesn't do what you are looking for by design -- the setting is around deployment scripts. The object definitions stored in SQL Source Control are often differ...
Hi @Maziar_Chitsaz, I am curious to know more about your use case. Is there a reason that you would not simply add new rows to the static data table in development? I am puzzled as to why you would ever update or delete rows in the dev environment if you always want to append in the deployment itself. You do have the option to manage static data tables with the "offline" method using a post-deployment script if you want a custom implementation. You could use this to make the static data only ever append in the deployment. Does this sound like it's of interest? I have just realized that we don't have an example script for the offline method available in our SCA docs, but this is something I can add. Cheers, Kendra / comments
Hi @Maziar_Chitsaz,I am curious to know more about your use case. Is there a reason that you would not simply add new rows to the static data table in development? I am puzzled as to why you would ...
Yes, that's correct -- the "offline" method is the approach designed for scenarios where you want the static data to appear different in the target rather than what is in version control in some way. Thanks for the additional detail on your use case. Another question -- if you had a rules engine that would allow you to alert on this type of mistake -- either at the point where the user is working, or during a build process (or perhaps both), would that be sufficient? / comments
Yes, that's correct -- the "offline" method is the approach designed for scenarios where you want the static data to appear different in the target rather than what is in version control in some wa...
Hi @HorstKlein , Currently with the SQL Source Control object history feature you can either:
View the history of an existing object
View the history of the database by commit message
You can find the history of a deleted database object via the second option, but it may be somewhat cumbersome/ tedious to find. I explain this to say that there is a solution for this, but it will generally only be efficient if you are looking for something that happened in a recent commit OR if commit messages can be relied on to indicate when drops occurred. I've searched our User Voice forum and I don't see that we've had this as a feature request before from folks. If you wouldn't mind creating an item there, it would help us to track the request. If you can describe how often you use the object history feature and if you have any policies/process/change requirements around dropping or renaming objects, that would also be really useful for us. Kendra / comments
Hi @HorstKlein , Currently with the SQL Source Control object history feature you can either:
View the history of an existing object
View the history of the database by commit message
You can find ...
Hi @michaelmm , Thanks for reporting this. I see why it seems like the history feature would solve this in SQL Source Control, but it doesn't. This is very helpful feedback for us in thinking through user stories for viewing version control history. I am not sure if you are using this in an automation context, but one other scenario we are currently working on is more flexible alerting of commands like DROP, TRUNCATE, RENAME in automation contexts-- say to possibly warn or fail on a build when these keywords are present. (I don't mean that would negate the value of viewing history to find when something was dropped or renamed, but it seems like a complimentary feature and both would be desirable.) Cheers, Kendra / comments
Hi @michaelmm ,Thanks for reporting this. I see why it seems like the history feature would solve this in SQL Source Control, but it doesn't. This is very helpful feedback for us in thinking throug...
Hi @rknight , Thanks for chiming in. We don't presently have this on the roadmap for SQL Source Control. I would be very curious to know:
Are you already an Azure Data Studio User? If so, how much do you use it vs SSMS approximately?
If SQL Source Control had a fast performing standalone tool that could work in tandem with either GUI, would this be of interest to you?
If SQL Source Control offered the ability to be used via the command line in some ways, would that be of interest to you?
Thanks in advance, Kendra / comments
Hi @rknight ,Thanks for chiming in. We don't presently have this on the roadmap for SQL Source Control. I would be very curious to know:
Are you already an Azure Data Studio User? If so, how much ...