Comments
Sort by recent activity
Hi, We cover the answer to that in this documentation page: https://documentation.red-gate.com/sca/developing-databases/concepts/baseline Hope this helps, Kendra / comments
Hi,We cover the answer to that in this documentation page: https://documentation.red-gate.com/sca/developing-databases/concepts/baselineHope this helps,Kendra
Hi @pkettlew , Currently, External Tables are not supported by the SQL Compare Engine and they are not scripted out.
External Tables / External Data Sources / External File Formats are the main thing that has come up recently which are not scripted.
The main categories of other things which aren't scripted are database configuration properties and settings and instance-level things like SQL Server Agent jobs, linked servers.
There are some "dependency chain" scenarios which cause some objects to script as "unsupported", which is a slightly different scenario.
Work for adding support of External Tables is currently ongoing, and we expect support for External tables to ship this quarter (Q1 2021) in SQL Compare and its related tools (including SQL Change Automation). Creating External Tables in a pre-deployment script is the current workaround. Kendra / comments
Hi @pkettlew ,Currently, External Tables are not supported by the SQL Compare Engine and they are not scripted out.
External Tables / External Data Sources / External File Formats are the main thi...
Hi, The definition of the external tables and anything that the external tables are dependent on (ie the external data source) would need to be set up by the pre-script. Things that reference an external table, like views, procedures, etc, do not need to be modified in the baseline script (the baseline script is run *after* the pre-deployment script.) Hope this helps, Kendra / comments
Hi,The definition of the external tables and anything that the external tables are dependent on (ie the external data source) would need to be set up by the pre-script.Things that reference an exte...
Hi @pkettlew, The shadow database is where scripts are run locally -- more information on it is here: https://documentation.red-gate.com/sca/developing-databases/concepts/shadow-database Cheers, Kendra / comments
Hi @pkettlew,The shadow database is where scripts are run locally -- more information on it is here: https://documentation.red-gate.com/sca/developing-databases/concepts/shadow-databaseCheers,Kendra
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 ...